TomoChain vs EOS.IO: The battle of PoSV vs DPoS or just some coincidence of design philosophy?
Proof-of-Stake (PoS) has been rising as one of the sexiest techniques for replacing Proof-of-Work (PoW) currently used in mainstream blockchain technologies such as Ethereum and Bitcoin. The objectives of PoS-based blockchains such as EOS.IO and TomoChain are not only to eliminate the PoW-related electricity consumption but also to provide a scalable solution to tackle the transaction processing performance problem in Ethereum and Bitcoin. The latter can only process around 10–15 transactions per second, which is not comparable to Visa and MasterCard.
In this post, we analyse in depth and compare in details the similarities and differences between TomoChain and EOS.IO. This post is the continuum in the series of technical posts aiming for comparing Tomochain and some notable PoS-based blockchains, including EOS.IO, Casper FFG, Cardano, and Tendermint.
The CAP theorem and the blockchain’s trilemma
The classic mathematically proven CAP theorem says that a distributed system cannot together guarantee all three requirements: consistency (C), availability (A), and partition tolerance (P).
- Consistency means that the results of reading some data on any node of a distributed system are either the most recent result or an error.
- Availability requires that every request to read receives responses without guarantee that the received results are the most recent ones.
- Partition tolerance is inherent in the distributed system meaning that “the system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes”.
Since partition tolerance is the nature of distributed systems, many system designs have to choose either consistency or availability while sacrificing the other requirement. Blockchains, which run in a distributed environment, also cannot break out of this loop. Everyone wants to get the most recent result right after a read request to any node (availability), but that would lose the system consistency since there is block propagation latency that makes the data in different nodes be not the same.
Even though the CAP theorem is not obviously visible to users of blockchains, blockchains have their own trilemma where three requirements, namely decentralization, security and performance/scalability, are difficult to guarantee a convergence into the same blockchain. Bitcoin and Ethereum are good at decentralization and security but offer a very poor performance.
Security seems the obviously visible and sensible requirement required by users. Losing money or double-spending should not happen. Many blockchains are trying to balance the trade-off between decentralization and performance, by reducing the number of block producers in the network. A lower number of producers means quicker network propagation, thus quicker consensus between block producers.
EOS and TomoChain are both trying to improve their performance, while the differences between them lie in their consensus details and the decentralisability they sacrifice for the performance gain.
EOS at a first glance
Started its yearlong ICO in June 2017 and ended recently with almost 4 billions of dollars is raised. EOS is, however, still a relatively new project compared with Bitcoin and Ethereum. EOS inherits the Delegated Proof-of-Stake (DPoS) invented by Dan Larimer from its application-specific ancestor blockchains, namely Bitshares and Steemit, and generalizes multiple features from these ancestors. Similar to other blockchains, EOS presents some security features such that the system can be fault tolerant if no more than 1/3 total of nodes are attackers. On the other hand, in the impossible triangle of blockchain where decentralization, security, and scalability cannot be done all together, EOS sacrifices decentralization for scalability. Therefore, only 21 block producers can be elected and create blocks by being elected, but block time can be decreased down to 500ms.
“Consensus is the heart and the soul of any decentralized blockchain system”. It is the main actor who drives the different requirements of the system, including decentralization, security, and performance.
EOS.IO and Bitshares both use a new PoS-based consensus algorithm called Delegated Proof-of-Stake (DPoS). In this latter, instead of miners, as in Bitcoin and Ethereum, who participate into a race of hashing operations, block producers in EOS, namely witnesses or block producers, are elected through a voting system. The witnesses are stakeholders who are the most voted by other stakeholders: the stakeholders delegate the block production ability to the witnesses.
In both EOS and TomoChain, the ability to produce blocks is the responsibility of the most voted nodes, either witnesses in EOS or masternodes in TomoChain. This responsibility is dispatched equally to these block producers so that every block producer can and must create blocks. The set of the block producers is fixed within a period, called epoch, but can be changed dynamically for every epoch. There is a pre-determined order of block producers, each of which produces blocks.
EOS employs what we called single validation to validate blocks while TomoChain has designed a double validation technique. Then, what is the point of doing double validation?
To understand that, let me show the differences between these two validation techniques as follows (readers are encouraged to refer to the TomoChain technical paper for more comparison details):
- In single validation, each block is created by one block producer and asynchronously validated by other block producers. The next block producer in the pre-determined order then validates that block and builds another block on top of it.
- In double validation, another layer of block validation is added in the way that a created block must be validated by another randomly selected block producer, namely block verifier, before the next block producer lengthens the blockchain from that block.
What this means is that, if, in EOS, there is no order of which block producers should sign off the block after its creation. TomoChain with its double validation technique requires that the second masternode who signs off on the created block must be the block verifier, that is randomly selected. If this block verifier detects the abnormality in the block, it rejects the block and all other masternodes will soon reject it as well.
An epoch is measured by the maximum number of blocks that can be created within that period. In EOS, an epoch is equivalent to 126 blocks (each block producer creates 6 blocks in each epoch), while this epoch is 900 blocks in TomoChain.
At the end of each epoch, block producers are rewarded within a reward block. In EOS, a block producer is rewarded for the successfully validated produced blocks that it created for that epoch, while the reward of each successful block in TomoChain is shared equally between masternodes who validate and sign the block to finalize it.
TomoChain requires 3/4 of the masternodes to sign a block in order to finalize it. Once 3/4 of the signatures of the masternodes are available for a block, the latter is finalized meaning that it will never be modified later by any means.
EOS aims to provide zero fee transactions but it is not zero in reality. This idea of ‘zero user-fee’ is disingenuous because it suggests that economic incentives are no longer required to maintain the network. EOS does indeed have fees, but they are hidden in the form of inflation.
Decentralisation and voting
“The key impetus behind the interest in blockchains is decentralization of power among entities with minimal trust relationships. But, there’s a fundamental tension between scale and decentralization. While we know how to get scale, scaling solutions may require compromising the decentralized nature of blockchains”.
EOS only allows for 21 block producers to be able to produce blocks in each epoch in order to ease the consensus and minimize network propagation latency between the block producers. On the other hand, that number of masternodes in TomoChain is 150, thus more decentralized in this term.
EOS and TomoChain have their governance application that allows stakeholders of their network to vote for block producers or masternodes. EOS stakeholders use eosauthority or eosportal for voting while TomoChain supports TomoMaster. The details of how voting weight is computed are different from each other.
In EOS, as well as in Lisk, voting weight is based on the total asset that a stakeholder owns in his wallet. What this means is that “if you have 100 EOS in your wallet, your voting weight/power is 100, regardless of the number of vote casts you make”. Each holder can cast a maximum of 30 votes for block producer candidates. We actually see this voting style very often in reality, where every one goes to an election, chooses a number of candidates they want to vote for, and casts the vote for them. However, every vote in a democracy election has the same weight.
TomoChain’s voting weight is based more on investment decision instead of asset. Every vote cast has different weights and the weight is computed by the number of TOMO tokens a stakeholder puts into a smart contract in order to vote for a masternode candidate. The stakeholder then cannot use the amount of tokens they vote for candidates, unless an unvote decision is made. Furthermore, there is no limit on the number of candidates a stakeholder can vote for. If we consider a masternode candidate as an enterprise, the amount of voted tokens can be seen as an investment to the enterprise and the voters get incentives every epoch based on the business result of the masternode candidate, if the latter is among the top 150 of most voted candidates.
As in Lisk, EOS block producers can freely decide how many percents of their revenues to distribute to their voters. In TomoChain, however, every voter is explicitly rewarded based on the amount of voted tokens at the end of each epoch if their voted candidates are selected as masternodes in that period. Furthermore, every masternode signing a successfully finalized block receives the same amount of tokens as reward.
TomoChain stakeholders should carefully choose which masternode they vote for in order to maximize their profit. We can say that, a token voted for the most voted masternode will receive less reward than a token voted for the least voted masternode. Knowing that, wise voters wanting to maximize their profits from investment should consider the least voted masternodes, even the candidates ranked just right after the 150 most voted candidates. Eventually, every candidate will have chance of becoming a masternode, thus gradually shift the decentralization level to a balance point. By this way, we believe that TomoChain decentralization with its TomoMaster governance voting system and incentive mechanism will avoid the “Mafia coalition” problem as in Lisk.
There are multiple aspects related to security that will be analyzed in the followings.
If there’s a fork in the chain, the optimal strategy for any validator is to validate on every chain, so that the validator gets their reward regardless of the outcome of the fork. Attackers can create multiple forks and block producers will sign every block in every fork in order to get incentives regardless of which chain will win. An attacker then takes advantage of this security hole by making a transaction for paying something on one chain and another transaction sending the same money to his controlled account, thus double-spending occurs.
EOS and TomoChain both choose to down-vote the block producers who sign multiple chains, instead of having slashing punishment as in Casper. Moreover, having the order of block producers to create blocks also provides a means of defense to this problem, though not all cases. Look at the following figure, the next block producer A would create a block adding after the blue and then propagate its newly created block to its neighbours. But, a subset of block producers would not receive that newly created block on time, thus believe that A has missed its turn of block creation, and then validate either the 104 green or red.
The network might converge to the blue chain since it is longer than the other chain that missed a slot of block time. But, if the blue chain misses a block time caused by either its block producer being on the other chain or an attacker subjectively missing a block time, thus resulting in two chains with equal length, therefore having nothing-at-stake, which chain should go for all block producers?
TomoChain provides more protection on this problem by having double validation. The blue chain can continue running when the block verifier signs the 104 blue. On the other hand, for the other chain to continue, it needs both block creator and block verifier on that chain separated from the blue chain, which is unlikely to happen.
Both EOS and TomoChain can defend against long-range attack by block finality and the order of block producers who can create blocks at a specific point in time. Therefore, there is no chance for one malicious block producer to create a longer valid chain because other block producers will refuse it.
“If blockchain platforms do not provide censorship resistance — i.e. they rely on a set number of trusted actors to produce and validate blocks — then we have simply returned to legacy database systems, albeit at the expense of the efficiency that legacy systems like Amazon Web Services provide”.
Both EOS and TomoChain are trying to reinforce the censorship resistance through the voting system, where malicious nodes can be voted out of the block producer list by the stakeholders and the set of block producers is dynamically changed through the voting preference for every epoch. Moreover, because any nodes have to stake a significant amount of tokens in order to become block producers and then can be rewarded for their honest behavior of work, therefore, they are financially disincentivized from acting maliciously.
Censorship attacks can happen if 2/3 in EOS or 3/4 in TomoChain of block producers are controlled, thus requiring an enormous amount of money staked, turning the system into a plutocracy, where no one wants to use it, therefore reduce the token price, which is not wanted by the attackers.
Compared to EOS, TomoChain’s censorship resistance is seemingly stronger since (1) TomoChain has 150 masternodes compared to 21 block producers of EOS, and (2) stakes of TomoChain masternodes are locked in smart contracts that will only unlock after one month. If any masternode misbehaves, it will be voted out and its stake cannot be used in any way for a long month.
It is clear that EOS has better performance in terms of block time (500ms) than what TomoChain targets (2s) since only 21 masternodes would reduce some issues related to network propagation and synchronisation. EOS also has better transaction confirmation latency which is approximately less than 1 second (0.5 second of block time + 0.25 second of finality + some time for sending the transaction) as what their team expected.
In my opinion, with a block time of 0.5 second, EOS is trying to put a lot of expectations on the network bandwidth and propagation. A block producer must verify the transactions which are included in the previous block, create another block with another set of verified transactions, and quickly send the created block to the next block producer in the order so that this next block producer does not consider it as a missing block.
On the other hand, TomoChain tries to be more secure by providing the double validation technique, which neatly requires some additional latency to get the block verifier reached and signed on the block so that other masternodes can accept it.
More on performance, EOS is itself designed as an operating system-like construct that can schedule transactions and what are called “actions”. Independent actions can be scheduled to execute in parallel. TomoChain, however, has a different vision on improving its performance.
In EOS, smart contracts are written in C++, instead of EVM smart contract languages such as Solidity used in TomoChain since the latter aims for providing an EVM-compatible platform, thus puts the focus on the portability of EVM smart contracts currently running on Ethereum.
TomoChain Team is currently researching on two orthogonal directions for increasing its performance. One is state sharding and the other one is EVM parallelization.
State sharding divides the network into groups of masternodes, each of which helps maintain a portion of the blockchain, called shards. The assignment of masternodes to specific shards is based on a uniform distribution and publicly verifiable decentralized randomization in order to secure the network since one node cannot determine itself to assign to a specific shard to avoid shard attacks where all attacking nodes will actively join the same shard. Each shard will then process a set of non-overlapping transactions in parallel with other shards, thus increase the whole throughput of the network. More on sharding can be found in our sharding proposal.
EVM parallelization scaling aims to improve the performance of smart contract processing by making multiple EVM instances run on multiple machines connected to a masternode. In other words, EVM parallelization is trying to schedule smart contracts and outsource their executions to other machines in order to increase the performance of each masternode.
EOS started the development in summer 2017 and had its minimal viable test network in the fall of 2017. In June 2018, the EOS mainnet has been launched after receiving enough votes (more than 15% of total EOS token) for mainnet launch. Only one thread is enabled for each block producer in the current mainnet. The parallelization mechanism of EOS is still under development and optimization and will be probably released in the fall of 2018.
Founded later than EOS, TomoChain started its development in spring-summer 2018, after its successful ICO. TomoChain had released its testnet 1.0 in April, testnet 2.0 in August. TomoChain mainnet with its newly designed Proof-of-Stake Voting Masternodes consensus will be officially launched on 14th December 2018 as stated here.
In my opinion, both EOS and TomoChain are hardworking to bring the best products to their community, and even founded later, TomoChain Team is catching up EOS and other Ethereum-based initiatives such as Casper.
Many DApps have been developed and are about to run on the EOS blockchain. Readers are kindly invited to check for the list of these DApps here.
For these DApps and the strong community of EOS after its mainnet launch, I put EOS over TomoChain. But, remember that, if EOS has already developed a strong community, even with its C++-based smart contract programming language, TomoChain also has a lot of potential in building a strong ecosystem because it is EVM-compatible. Therefore, any DApp running on the current Ethereum blockchain can be ported to run on TomoChain without any struggle.
If the DPoS-based Lisk project has been criticized for the formation of Mafia coalition where a set of block producers control the network and the transaction processing, EOS and TomoChain are trying to avoid that by providing almost zero-fee transactions (to encourage users in voting) and censorship-resistant consensus mechanism (double validation in TomoChain).
Both EOS and TomoChain sacrifice the decentralization for the transaction processing performance. If EOS only allows for 21 block producers (less than 150 block producers of TomoChain) to be able to produce 1 block every 0.5s, TomoChain seems to balance the trade-off between decentralization and performance, by allowing 150 masternodes to create blocks but increase the block time to 2 second. This two second block time also allows TomoChain to improve the security of the blockchain by providing the double validation mechanism.
EOS has its parallelisation architecture and mechanism for processing potentially millions of transactions per second. TomoChain, on the other hand, is working on both sharding and EVM parallelization targeting to raise the TomoChain’s performance to many thousands of transactions per second.
EOS has accomplished its mainnet, which is one step over TomoChain, and also has a strong ecosystem with many potential DApps. TomoChain, on the other hand, is focusing on the development of its EVM-compatible blockchain, enabling thousands of DApps currently running on the Ethereum blockchain.
I won’t say which one is the blockchain winner for the moment (even though we all know EOS has a better community and a strong ecosystem) since it is unfair for TomoChain because it was founded quite later than EOS but it is moving up towards very quickly. Thus, I will let the time answer and the users decide on it.