My thoughts in EOS blockchain vs Ethereum and Hyperledger
When I heard that EOS is the current competition of Ethereum in forums I just immediately went to coin market capitalization website of cryptos and couldn't believe it was already in the fourth position. I have been following the market since September 2018 and remembered that EOS didn't even exist in the top 10. Then I started reading the white paper to find why everyone was crazy about this technology, especially after the success of Steem.io application. Daniel Larimer, the founder of BitShares and Steem also set up the company that developed EOS.
After reading the white paper I found some of the elegant promises it offers. Among them, the main one is the use of Delegated Proof of Stake(DPoS) instead of Proof of Work(PoW).
Here are my thoughts on the benefits of the features of EOS white paper. For this post, I am referencing this youtube video. I think it can speed up the learning curve of newcomers to know the best parts.
PROOF OF STAKE
I have heard critics overt this consensus solution. Most critics argue it could limit the fairness of the system because the reduced number of peers(block producers) gives up decentralization. Additionally, a transaction is confirmed with 99.9% certainty after 0.25 seconds from the time of broadcasting. Additionally, BFT/Byzantine Faul Tolerant is added to the consensus by allowing producers to sign all blocks as no producers sign two blocks with the same timestamp or block height.
SCALABILITY
0.5 seconds is the timeframe of block production, which is so way slower than 12 seconds in Ethereum. Blocks are produced in rounds of 126(16 blocks each, times 21 procedures). The block procedures are chosen by the preference of votes cast by token holders. Moreover, if a blockchain fork with more producers grows in length faster than with fewer producers, the system follows this path instead since more producers will experience fewer missed blocks, solving the forking problem as in Bitcoin.
CONCEPTS OF ACTIONS
Smart contracts as in Ethereum, are Actions in EOS.
EOS aims for Parallel execution of Actions(Smart Contracts), which run in Accounts(such as EOA External Owner Accounts in Ethereum). Parallel Execution means that when a script generates a new “Action”, it is not delivered immediately but is scheduled to be delivered in the next cycle. Ultimately, the terminology of “Actions” is more appealing than Smart Contracts when Role Based Permissions features.
ROLE-BASED PERMISSIONS
This is a concept I learned with Hyperledger Composer, a framework that works on top of Hyperledger Fabric. The NodeJs SDK gives the environment to develop different “roles” by accessing instructions over different applications.
In EOS the role-based permission management involves determining whether or not an Action is authorized. Each account(hash) is controlled by a combination of other accounts and private keys. In my experience, this concept although very simple was not that intuitively in Hyperledger Composer since the abstraction fades the underlying principles of decentralization customization. Hyperledger Fabric is more customizable but the learning curve is slower. Hyperledger Composer lacks customization in role-based management due to its abstraction.
Ultimately, EOS offers combinations of keys or accounts that can send a particular Action. Therefore, validation of permissions is possible without using costly application logic. Consequently, security increases when other accounts demand identification in the case of an attack.
MODULARITY
In EOS, Actions defined by other applications are safely ignored if the application never depends upon the state of another contract. I experienced this feature with the Business Network Definition(.BNA file) in Hyperledger Composer. The .BNA file has an identifier for the application, which is used to communicate with other applications with the right permissions. For example, some transactions could be readable and editable for some applications but not for others. In my experience, Hyperledger Composer offers an easy way for developers to connect different applications since it works as a URL of applications.
CALCULATION OF COMPUTATIONAL RESOURCES
This feature is a wall of security. If the blocks detect an account or transaction is using an unusual amount of resources, the block producers can reject the transaction. This feature is very similar to the Gas Limit threshold in Ehtereum to prevent DDoS attacks. The calculation of the computational resources is done subjectively by the block producers. Therefore is not necessary a deterministic measure and then some optimization is improved.
There are three main classes of resources that are consumed by applications and those resources create the tokenized environment.
- Bandwidth and Log Storage(Disk)
- Computation and Computational Backlog(CPU)
- State Storage(RAM)(Information that is accessible from application logic)
SEPARATION BETWEEN TRANSACTION COST AND TOKEN VALUE
This is a key feature that really solves a problem of adoption. Bitcoin, Ehtereum and other blockchain are affected by the price since the users slow or speed up the efficiency by participating more or less in the transaction throughput according to the price of the cryptocurrency. The price of EOS token doesn't affect the performance of the blockchain since the number of blocks produces is deterministic. For example, if an application owner holds a relevant number of tokens on an EOS blockchain software, the application can run smoothly within a fixed state and bandwidth usage. Therefore, bandwidth, computer, and storage increase independently from the token value.
GOVERNANCE
Prior blockchains based in ad-hoc, informal and controversial governance processes, often result in unpredictable outcomes. Governance is crucial in future blockchain projects. Therefore, Token holders can vote upon handling suspicious block procedures. Moreover, if Actions(Smart Contracts)behave in suspicious behavior, the accounts are frozen and subjected to a 15/21 vote from producers.
Ultimately, the concept is the Constitution in EOS enables the establishment of peer to peer terms of service agreement or binding contracts to the user accounts. The terms and conditions can be forced by code. An example of the implementation is the inclusion of a hash as part of the signature of the user accounts.
That is everything for this post. I hope you guys liked it and if any of these reviews make no sense, please let me know, everyone is trying to understand the design of the next Internet.
…
If you want to know more about me and my projects follow me in my social media:
