EOS is a very interesting blockchain implementation. Unlike other blockchain implementations, the creators of the EOS blockchain software, block.one, are not actually implementing the EOS blockchain software. They are just releasing the open source code, which anyone in the world can implement themselves.
The EOS ICO is the longest running ICO in blockchain history. The EOS ICO, is being run on the Ethereum network over a 350 day period (July 2017 to July 2018). During each new day, two million EOS tokens are made available to buyers over a 23 hour purchasing period. The EOS tokens are purchased directly on the Ethereum network using the Ethereum cryptocurrency, known as ETH.
The allocation of the total 1 000, 000, 000 (one billion) EOS token supply, is as follows
- 100, 000, 000
-
One hundred million EOS tokens are reserved for the creators of the EOS software (block.one). These one hundred million tokens can not be traded or transferred on the Ethereum network
- 700, 000, 000
-
Seven hundred million EOS tokens are being split evenly into the 350 consecutive 23 hour purchasing periods
- 200, 000, 000
-
Initially, two hundred million EOS tokens were distributed during a 5 day period beginning on June 26 2017 and ending on July 1 2017.
As mentioned previously, block.one, the creators of EOS are not implementing their EOS blockchain software. Instead they are releasing the software which anyone can implement. The software launch, originally scheduled for June 2nd 2018, will open the flood gates for users from around the globe to download, configure and deploy the production ready blockchain software.
At the time of launch, the 1 billion EOS tokens residing on the Ethereum network will be frozen. The execution of this snapshot will completely prevent users from transferring tokens on the Ethereum network. After the snapshot, the entire record of EOS’s Ethereum ERC20 token ownership will be migrated to an EOS compatible snapshot. This EOS snapshot will be part of the genesis state for any and all future EOS blockchain implementations. What this means is that every EOS blockchain implementation, deployed after the EOS software launch date will carry the full 1 billion tokens.
By default, the Ethereum blockchain has no way of figuring out which EOS users (those who have EOS private keys) own EOS tokens. At the simplest level, the Ethereum blockchain only knows which of its Ethereum users purchased EOS tokens during the ICO. This information is not transferrable or useful to the EOS blockchain in its native state. EOS tokens, which were purchased on the Ethereum network as part of the EOS ICO, will only exist after the snapshot if they are registered to an EOS private key. This registration process must be performed by the person who purchased EOS tokens in the ICO and this registration must be performed before the snapshot/freeze. The registration process is performed by running the "register" function which resides inside EOS’s Ethereum ERC20 token contract.
You may be wondering quite a bit by now. For example, if anyone can deploy the EOS software won’t there be more than one chain? Who is going to mine all of these blockchains? How can a cryptocurrency exchange cope with trading EOS tokens given that the company block.one, who created the ICO, is not implementing a blockchain?
You may be asking deeper questions such as the following. What if nobody in the community implements EOS at all? What happens if a user does not register their EOS tokens before the snapshot? What if 2 or more competing software developers each deploy an outstanding EOS blockchain implementation? Can there actually be more than one EOS blockchain implementation? If so, how will the cryptocurrency exchanges maintain liquidity in the event that there are multiple EOS blockchains which all carry the snapshot of EOS tokens onboard.
Firstly, as mentioned above EOS is quite unique from most of the other blockchain implementations, which are currently in production. For example, unlike Bitcoin and Ethereum which use the Proof of Work (PoW) consensus algorithm, EOS uses its own Delegated Proof of Stake (DPoS) consensus algorithm. We will cover this in detail soon, but for now let’s answer a few more broad questions to set the stage.
Only one of the EOS blockchain implementations, deployed by the global community, will become EOS. The theory behind the community driven nature of EOS is that the world’s most talented software developers will organically gravitate towards the best EOS blockchain implementation. That is, developers will want to be a part of the blockchain implementation with the most chance of success and will therefore converge.
Launching an EOS blockchain implementation is only half the battle. In order for a single EOS blockchain implementation to even be a valid contender, 15% of all EOS token holders (within the global community) have to cast their vote together on that single chain. In addition to this, the implementor of the EOS blockchain software must create a constitution which will replace the default constitution. If neither of the above points are achieved the blockchain implementation will not be valid. We will discuss the constitution and governence in detail soon.
Only 34.3% of EOS tokens have actually been registered (as at 19th May 2018). This statistic, gathered less than two weeks before the EOS software launch, could be an indication that token holders from around the globe may struggle to reach the 15% voting threshold on a single EOS blockchain implementation. This would especially be the case if there were many EOS blockchain implementations to choose from, and say perhaps users were loyal to EOS implementations in or around their geographical location etc. The rate of EOS token registration does not seem high, given that around 13% of EOS tokens were registered an or around 1st April 2018. That is only a registration rate of around 20% per month, with less than two weeks remaining.
An EOS token holder may experience delays when calling EOS’s Ethereum ERC20 "register" function on the Ethereum network. Etherscan shows between 500 and 700 pending EOS transactions at any given time. The congestion, for the register transaction, on the Ethereum network may be due, in part, to the fact that the register function is of little use to Ethereum’s PoW mining community. The register function sends 0 ETH yet provides a naturally fair and conservitive amount of gas rewards, by default, to the miners. These pending transactions, experienced with other ERC20 tokens as well, may increase as more and more users attempt to register at the last minute.
As previously mentioned, we will be covering the DPoS consensus mechanism soon. However, just briefly, it is worth mentioning that Bitfinex is one of the EOS Block Producer Candidates (codename Frog) for which EOS users can vote for as part of the DPoS ecosystem.
EOSGo recently reported that the cryptocurrency exchange Bitfinex will support EOS voting. A draft proposal of the Bitfinex open-source voting tool and an online statement (by the moderator of r/bitfinex and r/ethfinex) reveals that the aim of the voting tool is to ensure integrity and verifiability with regards to the origin of funds used for the EOS Block Producer vote - "Bitfinex users will be free to vote for block producers as they wish, in a verifiably transparent manner."
Voting for block producer candidates is an important and complex task. As we will cover shortly, the block producers chosen by EOS token holders will be the parties literally responsible for producing "the blocks in the EOS blockchain". The criteria required for block producer candidature is involved and as such the voting process is potentially onerus. An independant EOS community is developing an EOS voting portal. The group of developers are asking the EOS community for help. The Etherem donation address and the Go Fund Me page are accepting monetary contributions which will go towards the community EOS voting portal, designed to streamline the BP evaluation and voting process.
Block producers are not required to stake tokens. Moreover, block producers can not be directly rewarded in relation to staking tokens only. Block producers are rewarded for producing blocks. Block producers are voted into their positions based on a rigorous and comprehensive set of criteria, which they respond to publicly. It is important to note that the EOS software and economic models are constantly changing. For example, as Thomas Cox revealed the block producer pay model changed 6 times during a 3-4 week period.
The EOS software blocks are produced exactly every 0.5 seconds The EOS.IO software blocks are produced in rounds of 126 (6 blocks each, times 21 producers) At the start of each round, 21 unique block producers are chosen by preference of votes cast by token holders A block producer schedule (order) is agreed upon by 15 or more producers From this point onwards exactly one block producer is authorized to produce a block at any given point in time If that particular block producer is unable to produce their block then there is a 0.5 or more second gap in the blockchain For this reason it is important that a block producer’s system is free from Distributed Denial of Service (DDoS) attacks.
If a producer misses a block and has not produced any block within the last 24 hours they are removed from consideration until they notify the blockchain of their intention to start producing blocks again. No block producer should be producing blocks on two forks at the same time. A block producer caught doing this will likely be voted out.
Perhaps the most significant difference between the PoW and DPoS consensus mechanisms is that of competition vs cooperation. In the PoW consensus ecosystem miners compete for rewards, racing to mine blocks in the blockchain
Merkle proofs provide a mechanism to prove that data exists.
The earliest production instance of Merkle proofs was in Bitcoin’s Simplified Payment Verification (SPV). The SPV mechanism is able to prove the existance of a particular transaction in the Bitcoin blockchain. For example, if the particular transaction is in one of the Merkle trees and that Merkle tree’s root is in a block header for the main chain, then the transaction exists. This Merkle proof implementation allows light clients to confirm the existence of a transaction. This works well in the Bitcoin system of Unspent Transaction Outputs (UTXOs) but is limited when it comes to wanting to know the global state of a blockchain.
Ethereum contains more than just a transaction Merkle tree root in its block headers. Ethereum contains a tree for Transactions, a tree for Transaction Reciepts and a tree for the blockchain State. Further, Ethereum does not use binary Merkle trees. The binary Merkle tree is an excellent choice a) when the query requires a binary response i.e. does the data exist? and b) when the data in the tree is never changed e.g. transactions in Bitcoin are never reversed.
Unlike Bitcoin’s UTXO system, Ethereum stores much richer information such as account balances, which are likely to continually change over time. For this and other reasons Ethereumm uses a Modified Patricia Merkle Tree (as apposed to a binary Merkle Tree). More information can be found in this article which discusses Bitcoin’s UTXO system vs Ethereum’s global state.
Let us consider the ever changing account balance. A light client might like to query the account balance to ensure that the user has enough money to perform a transaction.
All transactions have an expiration time after which they may no longer be included in the blockchain. Once a block with a block_header::timestamp greater than expiration is deemed irreversible, then a user can safely trust the transaction will never be included.
The EOS network resources available to an EOS user are directly reflected by the amount of EOS tokens that the user owns. For example, a user with 5% of the global EOS token supply will have 5% of the EOS network resources available.
To support parallel execution, each account can define any number of scopes within their database. The block producers will schedule transaction in such a way that there is no conflict over memory access to scopes and therefore they can be executed in parallel. The following nested diagram shows which components of the EOS layers can be run in parallel.
Blocks:: The EOS.IO software produces blocks in the EOS blockchain
Cycles:: Each block is divided into cycles (sequential)
Shard:: Each cycle is divided into shards (parallel)
Transaction:: Each shard contains a list of transactions (sequential)
Action:: Each transaction holds one or more actions for delivery (sequential)
Receiver and/or notified accounts:: Each action has a receiver and notified accounts (parallel)EOS Factory is to EOS what Truffle is to Ethereum
Block producer candidate voting portal
TODO This version of the EOS white paper shows that EOS does actually use sequential numbering to ensure actions/transactions were executed in order and that there was no actions/transactions missing https://github.com/EOSIO/Documentation/commit/c36ffeb47863b925b7f24d02cdd959a15f2301df There seems to be a data access section in the data which shows this. I will need to look into this further as well as how EOS specifically handles replay and double spend (it seems that this sequence is for interblockchain communication which is improved if finality can be achieved/proved more quickly).
data_access:[
{"type":"write","scope":"inite","sequence":1},
{"type":"write","scope":"inita","sequence":0}
]
----