Factom Bridge

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
Hi Matthew,

Thank you for your submission. I direct my questions to you, but of course they are for your team. Sorry for the amount of questions beforehand ;)

I start of with some general questions before going into technical questions based on your submission. Most of the questions will be in separate posts.

The funds from one or more Authority servers will be used to support those servers, but also to
implement various mesh instances and some compensate personnel for their time. More than
one Authority server will allow for quicker, more comprehensive mesh implementations and full
time development staff."
1)
"Implement various mesh instances". I am reading this as running mesh nodes on other networks to support the bridge(s). Later in your submission this seems to be validated. Is that the correct interpretation? If yes, could you give us some really rough estimates what that exactly means in terms of mesh nodes for instance?

2)
Am i reading it correctly that you would like to fund the development of the mesh project integrations from node income and that the speed of development depends on the total node income (you mention "more than one" node)?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
What has your team done to ensure a proactive approach to managing the financial aspects of your business?
Up front costs are covered. The first block rewards not left in the Grant Pool or set aside for staking are to be set aside for 12 months of expected expenses
3)
You mention expected expenses without qualifying them. Could you elaborate?

In a perfect world, any large persistent mesh network will have one or more factomd followers .
Some initial Authority reward will be used for buildout with this in mind.
4)
Could you explain that a little more (both sentences)?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
Block Rewards will be used in 4 areas:
-Authority Server Maintenance and overhead.
-Support mesh net factomd followers and possibly to participate in those networks.
-Reserve for the above
-Personnel compensation
5)
Could you elaborate on the "Reserve for the above" part?
You mentioned "compensate personnel for their time" before. Here it is mentioned last as well below the reserve part. Am I reading it right that "Personnel compensation" is not included in the reserve part then?
From this I would infer that the "Personnel compensation" is not fixed. Is that correct? Could you please elaborate?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
What vision do you/your entity have of the future of Factom?
The Factom blockchain is heading towards being wildly pervasive in many industries. Someone is going to have to make sure sharded data doesn't get lost and access confined to a few power players. So, decentralization.
6)
Are there any potentially goods or bads at being an employee of Factom Inc that one might take into account?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
The more technical part

Network setup for initial launch will consist of:
1 Authority Server
2 Guard Servers
2 Followers - (possible load balancing if usage needs arise. Not on day 1)
1 Public Courtesy factomd instance
1 Internal factomd instance
7)
Can I read the arrows in you Architecture image as main connection entry points? So the followers connect to the guards that connect to the Auth node?

8)
Could give some numbers like the above when 2 auth nodes would be awarded?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
Could you elaborate on the production servers your team has managed (amounts, OS-types, purpose)?
In recent years most production and non production servers have been virtual. Previous years have been colocation or server rooms. Typically Linux and windows.
9)
The question mentioned amounts and purposes specifically. Could you elaborate? Both of your supplied backgrounds are in software development what about the system administration part needed for node administration?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
How are you going to make sure you are able to respond quickly?
We have multiple people with node monitoring. We can log in with ssh and a physical key
10)
How many people would be operating the Factom software and OS in case of an emergency?
 

Niels Klomp

BI Foundation
Core Committee
Governance Working Group
I saved the probably hardest technical questions for last of course ;)

You are talking about possible load balancing. The picture you included took that into account as it seems, so you must have given that some thought.
12)
There are 4 followers in the picture, whilst you mention 2 above. Is that included in your financial calculations?

13)
How would you technically envision load balancing? Which ports/protocols would you balance? What kind of load balancing algorithm would we be talking about? Would these be dedicated load balancers?

14)
What is the reason you placed the loadbalancers in front of the follower nodes? The picture has load balancers in front of followers, but the application talks about guards. Which is it or perhaps both?

15)
You seem to make a distinction between the two loadbalancers. One serves the internet. One serves "Internal systems". Could you elaborate?

16)
Why would you do loadbalancing?
 
Last edited:

David Chapman

Factomize
C. Based upon your stated Efficiency of 30% (with one server) and your estimated expenses, at what USD price does FCT need to be for your Authority Node operation to break even on a monthly basis with one server?
 
Last edited:
Hi Matthew,

Thank you for your submission. I direct my questions to you, but of course they are for your team. Sorry for the amount of questions beforehand ;)

I start of with some general questions before going into technical questions based on your submission. Most of the questions will be in separate posts.


1)
"Implement various mesh instances". I am reading this as running mesh nodes on other networks to support the bridge(s). Later in your submission this seems to be validated. Is that the correct interpretation? If yes, could you give us some really rough estimates what that exactly means in terms of mesh nodes for instance?

2)
Am i reading it correctly that you would like to fund the development of the mesh project integrations from node income and that the speed of development depends on the total node income (you mention "more than one" node)?

1-
Hi Matthew,

Thank you for your submission. I direct my questions to you, but of course they are for your team. Sorry for the amount of questions beforehand ;)

I start of with some general questions before going into technical questions based on your submission. Most of the questions will be in separate posts.


1)
"Implement various mesh instances". I am reading this as running mesh nodes on other networks to support the bridge(s). Later in your submission this seems to be validated. Is that the correct interpretation? If yes, could you give us some really rough estimates what that exactly means in terms of mesh nodes for instance?

2)
Am i reading it correctly that you would like to fund the development of the mesh project integrations from node income and that the speed of development depends on the total node income (you mention "more than one" node)?


I kept mixing answers, so I am going to respond to both as one. Part of developing the bridge to the Factom Blockchain is having those access points available. I plan at least a small area of mesh availability around data center access. That will involve at least some hardware. I would not propose city wide access based on Node income. A seed for the mesh network(s) is what would be enabled there. Getting others to expand it from there would be the intent.

If there are other established Mesh networks running, bringing up a Factom Node in that network would not be out of scope.
 
Hi Matthew,

Thank you for your submission. I direct my questions to you, but of course they are for your team. Sorry for the amount of questions beforehand ;)

I start of with some general questions before going into technical questions based on your submission. Most of the questions will be in separate posts.


1)
"Implement various mesh instances". I am reading this as running mesh nodes on other networks to support the bridge(s). Later in your submission this seems to be validated. Is that the correct interpretation? If yes, could you give us some really rough estimates what that exactly means in terms of mesh nodes for instance?

2)
Am i reading it correctly that you would like to fund the development of the mesh project integrations from node income and that the speed of development depends on the total node income (you mention "more than one" node)?

I kept mixing answers, so I am going to respond to both as one. Part of developing the bridge to the Factom Blockchain is having those access points available. I plan at least a small area of mesh availability around data center access. That will involve at least some hardware. I would not propose city wide access based on Node income. A seed for the mesh network(s) is what would be enabled there. Getting others to expand it from there would be the intent.

If there are other established Mesh networks running, bringing up a Factom Node in that network would not be out of scope.
 
3)
You mention expected expenses without qualifying them. Could you elaborate?


4)
Could you explain that a little more (both sentences)?

Money is on hand to purchase the hardware and cover a couple months of data center cost. Data center costs are the primary expenses expected. Enough to cover 12 months of the fixed costs will be set aside.

If we discover a persistent mesh network, we MAY bring up a follower in that locality.
 
5)
Could you elaborate on the "Reserve for the above" part?
You mentioned "compensate personnel for their time" before. Here it is mentioned last as well below the reserve part. Am I reading it right that "Personnel compensation" is not included in the reserve part then?
From this I would infer that the "Personnel compensation" is not fixed. Is that correct? Could you please elaborate?

"Reserve for the above" is similar to the last questions. We would like to add a 5th item. Staking. Neither of our members is depending upon block rewards for our primary income. Much of it will end up Staked instead of sold, but we do not wish to have personal financial issues or delay a useful project due to funds or opportunity cost.
 
6)
Are there any potentially goods or bads at being an employee of Factom Inc that one might take into account?
Since Matthew works at Factom there is the possibility of an appearance of ... maybe not impropriety, but centralization. There is not an issue there, but appearance means something. Also, he has spent the last 2+ years thinking about uses for the blockchain and implementing some that are within Factom, Inc's business plan. The mesh integrations are not in Factoms current business plans (That we know of)
 
The more technical part


7)
Can I read the arrows in you Architecture image as main connection entry points? So the followers connect to the guards that connect to the Auth node?

8)
Could give some numbers like the above when 2 auth nodes would be awarded?
7 - Yes. followers talk to the world as courtesy nodes on one side and internal (and mesh) servers along the other path.
8 - The same setup would be in both data centers.
 
C. Based upon your stated Efficiency of 30% (with one server) and your estimated expenses, at what USD price does FCT need to be for your Authority Node operation to break even on a monthly basis with one server?
While it would not catch up with sunk costs, a $3.00 price will cover the data center costs. As long as it does not happen in the first six weeks, the funds will already be available for 12 months of service.
 
10)
How many people would be operating the Factom software and OS in case of an emergency?
As of today, two of us (will) have access and the ability to update and maintain the servers. We are both on the alert list and will have installed and updated our data center setup. In addition to the two of us, these server are located in data centers with 24-hour physical support access. If there is a case of needing physical access, it does not depend on us being physically present.
 
11)
And why?
I run the Factomize Everything processes. This means I have kept up to date servers running for the last 24 months for these data entry processes. When I say I have run them, I am specifically refering to followers, not Federated servers. Noone has run federated servers except possibly Brian.
 
I saved the probably hardest technical questions for last of course ;)

You are talking about possible load balancing. The picture you included took that into account as it seems, so you must have given that some thought.
12)
There are 4 followers in the picture, whilst you mention 2 above. Is that included in your financial calculations?

13)
How would you technically envision load balancing? Which ports/protocols would you balance? What kind of load balancing algorithm would we be talking about? Would these be dedicated load balancers?

14)
What is the reason you placed the loadbalancers in front of the follower nodes? The picture has load balancers in front of followers, but the application talks about guards. Which is it or perhaps both?

15)
You seem to make a distinction between the two loadbalancers. One serves the internet. One serves "Internal systems". Could you elaborate?

16)
Why would you do loadbalancing?

12 - I believe you are talking about the public facing follower and internal facing one. We are treating the load balanced servers as a single server. Followers are generic factomd servers that are simple to cleanly load balance and treat as 1. Yes, their cost has been accounted for. From one of the responses, it was pointed out the follower load balance will be added as needed. The internal load will not be necessary on day 1.

13 - Load balancing will be only for factomd API calls (8088). They will most likely be using a round-robin scheme in the initial release until an automatic failure detection notice in place. Right now this will come from the stalled flag in the current-minute API call.

14 - Guards have special config documents and relationships. Load balancers are cleaner at the generic follower level. There was also some talk about Guard nodes also being private as opposed to those being the public servers. Depending upon the resolution to those conversations, the followers may go away and just having load balanced guards may be the final architecture.

15 - One of those load balancers is meant to be a public courtesy node. factomd instances CAN (or could a year ago) be flooded to the point of dropping entries. This didn't affect the network, only the node. As Federated servers are being incentivized, it is not too much to ask to make available access points. The internal load balancer is for internal use. Monitoring, putting data into the blockchain through our own processes and mesh access is the current plan. Until mesh networks go live, the 'internal' load balancing is not going to be necessary in production as we will have control over that load.

16 - single instances of factomd can be flooded without flooding the network. If we are going to put courtesy nodes out, the ability to expand their capacity will be necessary if they become commonly used.
 
Top