EOS: Follow-Up Analysis, Pt. 1
Following the release of the research conducted on the EOS system by our team here at Whiteblock, we’ve received a lot of questions and comments requesting a further level of explanation for our reports and conclusions. (To all those who have given the long test report a read, we thank you for your time!)
We felt it would be productive to answer some of those questions and comments here, so we’ve broken it down into a series for easier access.
Here are some of the subjects we will be addressing in relation to our research of the EOS system:
- EOS’ lack of Byzantine Fault Tolerance (Part 1)
- The definition of a blockchain (Part 2)
- Transactional throughput (Part 3)
Byzantine Fault Tolerance
Background
In 2008, Satoshi Nakamoto published Bitcoin: A Peer-to-Peer Electronic Cash System, a paper which presented an innovative solution to the Byzantine General’s Problem in relation to the transfer of digital assets across the inherently adversarial space that is the public Internet.
The anonymous entity known as Satoshi Nakamoto was presumably a product of the Cypherpunk movement which attempted to address issues such as privacy in an open society.
Although Nakamoto’s solution may not have been the first of its kind, the concept of Bitcoin helped introduce blockchain technology and cryptocurrency to a global stage. The ability of this system to eliminate the need for trust when communicating across inherently adversarial environments addressed the distinct need for self-sovereign digital identity within an increasingly digital age while presenting a novel solution to the Byzantine General’s Problem.
The concept of Byzantine Fault Tolerance was originally presented in a research paper called The Byzantine Generals Problem, written by Leslie Lamport, Robert Shostak, and Marshall Pease in 1982. The issues outlined in this paper and the best way to address them has been the subject of much debate within the field of distributed computing.
Since this paper was published, systems which present a high degree of tolerance to the failure of primary network components or the dissemination of invalid information within that network are described as displaying Byzantine Fault Tolerance.
BFT In Relation To The EOS System
Delegated Proof of Stake
Delegated Proof of Stake (DPOS) was popularly defined and presented by Dan Larimer in BitShares, the first system he developed, and this same consensus algorithm has been applied to the EOS system. For the sake of brevity we will avoid providing a general definition of the concept and instead focus on the aspects that directly relate to the subject at hand.
https://www.youtube.com/watch?v=Xs1dyZFhIr4
In order to function properly, the DPOS process depends on the cooperation of token holders to cast votes for the block producers they are electing to act on their behalf. This function of voting extends network function to include anyone who owns EOS tokens since these token owners perform logical functions the system requires in order to properly operate and maintain a certain degree of security.
According to the actual definition of Byzantine Fault Tolerance, as presented in the original paper which has been historically accepted as canon, an oral message is one whose contents are completely under the control of the sender, so a traitorous sender can transmit any possible message.
“Such a message corresponds to the type of message that nodes normally send to one another.”
According to the aforementioned description, EOS token holders should be considered nodes within the network. If one assumes that 250,000 accounts are present within the EOS network, this would further imply the presence of 250,000 nodes within the network. Since activities between any number of these nodes must be communicated via block producer, similar to the description of an oral message in the original BFT paper, 100% of the network is controlled by 21 block producers — a population of 0.0084%.
As far as block producers are concerned, consensus cannot be achieved without the unanimous agreement of 15/21 of the block producers. This is a logical fallacy. 2/3 must be “honest” for the system to be considered BFT, but extending this to 15/21 (or 2/3 + 1) won’t actually present any further optimizations to security. What’s most important in this context isn’t the minimum number of honest nodes needed in order to enforce BFT, but the minimum number of dishonest nodes needed to negate BFT. By raising it to 15/21, a bad actor now only needs to collude with 28.24% (6/21) of the 21 block producers in order for its cartel to control the entirety of the network.
Game Theory
The unique value of traditional blockchain systems presents in the intersection of computer science and applied game theory which presents a demonstrable and mathematical method of eliminating the need for trust, since these mechanisms are algorithmically and cryptographically enforced.
By requiring a single node within the network (the token holder) to rely on the good intention of another node (a block producer), these functions now rely on human behavior and a certain degree of good faith — completely eliminating the characteristics which have defined blockchain technology and a viable and unique solution for the same issues that good faith simply cannot address by its own merit.
Under these assumptions, block producers should be considered equivalent to dishonest generals. Since there is no mathematically enforced protocol implemented to ensure that block producers are acting honestly, one could logically assume that any of them can act dishonestly should they so choose, which in and of itself negates the entire premise of the system’s design and the intent of blockchain technology.
Conclusion
These critiques should not be evaluated in relation to Bitcoin, Ethereum, or any other system since this research was conducted to focus on EOS. This is not investment advice. This is an objective and scientific overview of a system. Analysis such as this is imperative to the ongoing efforts of presenting blockchain as a viable, everyday solution that holds practical real-world value. In order to build higher-performing, optimal systems, we must view results such as these in an unbiased light, free of emotion or be doomed to fail. There is no EOS vs. Ethereum. There is only blockchain proponents and those in support of a decentralized world versus those who would rather see this movement reduced to a bubble and likened to tulip mania. Whose side are you on?
If you have any questions or comments about this article or blockchain testing, feel free to reach out to us at hello@whiteblock.io. Check out our channel on Telegram and join our group for more discussion about blockchain performance and engineering.
