Brian,
I just finished reading the whitepaper. I am still confused about the servers. The servers act as a node like in bitcoin. Are these servers run by people are are they all owned and operated by factom. Also I read somewhere that there is a limit on the total number of federated servers. I am assuming a federated server is like a dedicated server, just bigger. And is there a factom rich list?
1. By M3, who is a Federated and who is an Audit servers will be voted for by users of Entry Credits. It could end up being you or me. M3 will make it a decentralized system. M2 will be centralized and Factom appears to be choosing who is running those servers.
2. I suspect initially a Federated or Audit server could be run on a VPS. I also suspect, in time, Federated and Audit servers will require MUCH MORE computing power as use of the protocol grows.
This is pretty much right, but a few details need correcting. Think of the Federated servers like you think of bitcoin mining pools. They are the authorities of how transactions get ordered in the system. They all work together to build the blockchain. There can be thousands of bitcoin nodes in the system, that also see all the data. The bitcoin nodes see all the pending unconfirmed transactions, then after the miners order the transactions, all the nodes save the block which sets the ordering. It is similar with factom. All the nodes will see all the data, just like bitcoin. Unlike bitcoin, the authorities are known in advance, so the order can be determined in real time, instead of probabilistically after the fact. This gives faster response time. Like the bitcoin miners, the servers will run the same code as all the other nodes.
Unlike ethereum or even bitcoin, factom nodes & servers do very little validation. All that is checked is if data was paid for before putting it in the blockchain. This is in contrast to something Turing complete, or even with a simple script like bitcoin. All the validation for an application will be done on the client side, rather than on the servers. Here is a comparison of the approaches:
https://www.youtube.com/watch?v=naKvYfYsBQo&feature=youtu.be&t=3476Even with a very high transaction usage, the bandwidth required will be about that of a High Definition movie or two.
https://bitcointalksearch.org/topic/m.13588841When the system starts to process more transactions than the average node bandwidth can handle, that is where the p2p network sharding comes into effect. Since all entries in the system need to declare a ChainID, then there is room for lots of parallelism. We are anticipating this. For example, Identities are a big part of how the servers will be chosen and managed. They are forced to start with 0x888888 to be valid by using brute force hashing. https://github.com/FactomProject/FactomDocs/blob/master/Identity.md#factom-identity-chain-creation This will put all identities into an easily identifiable network shard. Since most people won't care about other people's applications, they only join the network shard that handles their application. The shard is there for real time communication. After the blocks are made, everyone needs the directory blocks, but you would only download the entry blocks and entries related to your application. For now everyone downloads everything.
Myfarm's conclusion about the federated servers being more powerful than nodes will come about if they span different network shards.
We will have 32 federated servers for M3. More than that and we probably would have coordination issues.