Shadowed advantage of EOS that you might not know: it is not burning its customers funds unlike Ethereum
Article credited to Dexaran and provided by EOS GO
The main advantages of EOS that got critically undervalued
-
Communication model. Secure ecosystem. No more lost tokens and burned funds.
-
On-chain address assignment and recording. No more crosschain collisions and sending into non-existing addresses.
-
Upgradeable contracts. No more unresolvable smart-contract hacks like TheDAO and Parity Multisig hacks.
Looks obvious but 99% of crypto community does not understand
I've observed a number of Daniel Larimer's comparisons of EOS vs ETH. He was highlighting the lack of migration plan for ETH 2.0, scalability of EOS and some other aspects. However, it seems that most of users and developers do not understand the advantages of EOS design and structure in practice.
What will you first think about if you ask yourself what are the advantages of EOS over Ethereum? Scalability, performance, human-friendly addresses, free transactions, gambling Dapps, upgradeablie contracts, ability to schedule transaction for future?
All of this is important, of course, but there are a few points that it is important to know about Ethereum to understand why it will never become widely adopted.
Let me reveal some facts: Ethereum is burning its customers funds. I'm not talking about transaction fees, trading disadvantages or something like this. Here I'm talking about the wide adoption of insecure standards and the mentality of Ethereum developers.
It is really bad if customers lose their funds when using your project.
Here is the comparison of Total world wealth VS crypto. It is no secret that the crypto industry is young and far from perfect. It's still in active development stage. Its evolving quickly.
We all love to dream about how the world will change when the universal adoption of cryptocurrencies comes but let me open your eyes and highlight some real aspects of the current situations. None of the large companies or serious businesses will ever use a platform that can accidentally burn their funds. Decentralization is good, blockchain is good, hype is good, easy fundraising is good but it is not enough to outweigh a risk of losing everything as a result of a single mistake.
Companies don't want their users to lose funds because of whatever (and it does not matter if its "user mistake" or something else
Governments don't want citizen to lose their funds. Its a primary goal of financial structures, departments and organizations to make sure that citizen can not use a system that will burn their funds with ease.
In our industry, many people forget about what such systems are intended for. Many accuse users of irresponsibility and simply dismiss design flaws. Its a norm for crypto industry that a user can send Bitcoins to the wrong address and lose all his life savings because of a single mistake. Its a norm here that users can simply forget their private keys and lose their funds.
Developers tend to blame the victim by saying "not a bug, user mistake".
Let me remind you: we work with funds here. We claim the title of financial system. I'm absolutely sure that we must take it seriously and we must take the responsibility of providing SECURE solutions for our customers.
How Ethereum will burn your funds if you are a mere user.
ERC20 tokens are insecure by default. All of them.
ERC20 token standard lacks event emitting/handling mechanism. It is described here and here.
It should be noted that event handling is a standard practice in programming. This is what is called communication model in EOS.
The lack of event handling causes serious problems. I would say that it could be fine for a social media app or a computer game. The consequences will not be disastrous if you have liked someone else's post and your like was not counted.
However, in the case of ERC20 tokens, this is a critical issue that already leads to the loss of millions of dollars. The amount of "lost" funds is growing every day. There were $3,200,000 lost in 7 of ERC20 token contracts at 27 Dec, 2017 (watch the EIP-223 discussion for proofs). At the moment, the Ethereum ecosystem totals dozens or maybe even hundreds of ERC20 tokens so it is just a small part of the global problem.
This is not a problem of Ethereum as a software because neither Geth or Parity enforce the use of ERC20 tokens in their default implementation but it is a problem of Ethereum as a project because users are constantly losing their funds.
ERC20: the problem
Lack of event handling leads to the fact that contracts can not respond to token transfers. There are two main problems: (1) those contracts that ARE NOT intended to work with tokens can not reject incoming tokens and (2) those contracts that ARE intended to work with tokens can not register tokens in case of a user picking the wrong function to perform a transfer.
In first case contracts at the whole Ethereum ecosystem become potential "token traps" that can receive tokens but can not send them back if the special emergency extraction function was not implemented.
In second case exchanges, DApps or other contracts that must receive tokens fail to credit them to the user who sent them.
Oddly enough, this does not apply to Ether. If you attempt to send Ether to the contract that is not intended to work with Ether then the transfer will be caught by the fallback function and the transaction will be reverted.
Some could say that this is not a security issue but a user mistake. This is not true because this is definitely a design flaw of the token standard. The reliance on an assumption that no one will ever make a mistake is not applicable for financial solutions and mass adoption platforms.
I have proposed a solution, the ERC223 token standard. There were some other solutions as well, but the adoption of ERC20 token was immense. For example, there is Vitalik Butern's comment regarding this issue.
Consequences
This leads to significant losses for many Ethereum token holders. The amount of lost tokens is growing every day and users keep losing their funds right now but no one cares and no one can recover these funds because contracts are not upgradeable on Ethereum.
ERC20 token standard became the most adopted and supported standard at Ethereum. This means that it is really easy to convince exchanges to list your token if it is ERC20 but it will be way harder to get listed if you are using alternative standards for your tokens. As the result, most of ICO developers keep using ERC20 because it is easier to rise funds quickly. The power of mass adoption is great and exchanges play big role here with their influence.
There are many developers that keep using the ERC20 standards knowing that it will result in financial losses for their users. I can quote the response of the STORJ co-founder here: "We decided to err on the side of well-tested code"
For many projects, it turned out that they use bad standard for their tokens after they launched. They could have fixed the problem but the contracts (and tokens) are immutable on Ethereum and there was no way to implement a hotfix. Most of them decided to stay with the current implementation. This could be addressed with upgradeable contracts. Upgradeable contracts are critically important for the security of the ecosystem.
Example: $436,000 lost in BNB smart-contract
Here is the BNB ERC20 token smart-contract.
The contract owns 23,458 tokens on 10/22/2009. It can be seen that users have transferred tokens into the contract accidentally. The contract is not intended to hold tokens and it can not operate with the tokens that it holds. There is no way to withdraw tokens from the contract. This tokens are simply lost because the contract was unable to reject them due to the lack of event handling mechanic in the ERC20 standard.
BNB is just a small part of the problem. There are many more ERC20 tokens that got "stuck" inside contracts. There are millions of dollars lost already.
Here is another documented example of how a user sent tokens to a contract and lost them due to a described flaw in the standard: a user has lost $130,000 because of lack of the event handling in ERC20
It should be noted that this is a very common user mistake but users do not have any reason to deposit tokens into the token contract. However, the situation changes when we take a Decentralized Exchange contracts into account. Depositing your funds into an exchange is a standard practice in crypto industry. All traders deposit their funds into a given address generated by exchange when they want to get funds credited to their balance.
This would be a good idea to credit tokens to the "sender address" for an exchange but it is impossible with ERC20. This means that all the ERC20 token exchanges are giant token traps that fail to credit deposits when users pick a wrong function.
It is absolutely impossible to build a fully decentralized ERC20 token exchange on Ethereum. The exchange must have a token extraction function that will make owner able to withdraw "stuck" tokens. Otherwise the exchange will not be safe to use.
On-chain address assignment
In Ethereum addresses are derived from the private key. Here is a simple example that will illustrate that you can derive an 'Ethereum address' from any sequence of 64 symbols: key generator.
This approach is simple and it allows to create an address for free. However this has two critical problems:
-
Addresses that are not owned by anyone are still valid
-
Crosschain collisions
Sending into a wrong address
The ability of a user to send his funds into an address that is "valid" but is not controlled by anyone is considered a norm in most protocols like Bitcoin, Ethereum and many others. However, if you look at it from a critical point of view, we will conclude that this is not how the mass adopted financial system should work.
The inconvenience of generating EOS addresses is a problem but it is a reasonable price that must be paid to resolve even greater problem. The problem of paid addresses is resolvable. For example some party can establish a certain amount of funds to generate addresses for users. This is what Wombat wallet is doing now.
The problem of recovering funds from non-owned addresses and the problem of identifying which addresses are owned and which are not owned but "valid from cryptographical point of view" are not resolvable in legacy blockchains.
Crosschain collision
The way of deriving Ethereum addresses assumes that the one private key is valid for the same addresses at the different chains (aka forks or sister chains). One address that is valid in one chain is also valid for all the alternative chains that rely on similar address generation scheme.
This is especially relevant for Ethereum and Ethereum CLassic. The issue affects contracts mostly. As it was described above the contracts are intended to handle incoming transactions. Contracts reject incorrect transactions. For example if a user will send ETH to the contract that is not intended to receive payments then the contract will reject the transaction and the tranfer will not happen.
However, if a user attempts to send his funds to the same address at some of the alternative chains then the transfer will happen because there is no contract at this address at the alternative chain. Example:
-
A contract is deployed on ETH chain
-
Whenever a user is sending ETH to the contract the transaction is rejected
-
Whenever a user is sending ETC, UBQ, EXP, CLO, MUSICOIN or other fork-coins to the address of the contract then the user is losing his funds permanently
-
Bonus: whenever a user is sending ERC20 tokens into the contract on any chain then he is losing his token permanently as well
While it may look like a stupid theoretical issue this is a real problem that have to be addressed. We have a real example: $58,000 were lost in GNT contract on ETC chain.
There is a solution - the contract developer must deploy a dummy contract to any of the fork chains. This contract must also contain the ERC20 extraction function. In reality, this is unlikely to happen, and users will continue to lose money due to crosschain collisions. As shown by the GNT example, even if developers want to solve a problem, they may not be able to.
This became obvious that this approach of address generation is not viable for any system that is designed with inter blockchain operability in mind.
EOS states that it is designed with the interoperability in mind and the architecture of EOS addresses some important issues regarding this.
Upgradeable contracts: the most reasonable thing you could ever imagine
Upgradeability is of critical importance for security.
It is impossible to make sure that your software is bug-free:
Writing bug-free code is impossible. The best developers focus on making code that is reliable and maintainable, but anyone who says a piece of code is bug-free has not done their research.
SpaceX experienced bugs in its software, Mariner-1 that costs $18.5M crashed due to a software bug, Gavin Wood the creator of Solidity programming language has developed a Parity Multisig smart-contract so that it was hacked twice, here is another example of how a bug took 10 years to fix it finally.
Even the most competent developers make mistakes sometimes. Even the most competent auditors fail to find mistakes sometimes. As a software security auditor I can say that it is impossible to guarantee that a software is bug free. It is way better to design the software to make it fault-tolerant and minimize the consequences of an error if it will occur.
None of formal verification, better programming languages, automated anomaly detection systems, automated tests or security audits can ensure that the software is bug free.
Immutable programs are a myth. A bug may be revealed years after the launch of a software. This is a major security flaw that renders immutable systems impossible to use. This is not applicable in financial systems where the consequences of a bug are truly terrible.
McAfeeDEX security audit showed that Ethereum does not fit developers needs to build a decentralized p2p exchange
I was personally engaged in the security audit of McAfeeDEX recently. The DEX is a Dapp that is intended to be built on Ethereum. You can find the audit reports here.
There are numbers of Ethereum problems that affect the audited DEX:
-
The lack of event handling at ERC20 is the greatest problem.
-
The crosschain collisions are also a problem.
-
The impossibility to halt or upgrade the contract is already a problem for this exchange.
McAfeeDEX is based on EtherDelta code. I can conclude that EtherDelta and all the Ethereum token exchanges are prone to this issues.
Some could argue that this is not the problem of this exchanges or Ethereum but the fact is that users will lose their funds if they will use this exchanges while they will not lose funds if they will use EOS exchanges, so I have no other option rather than to recommend EOS to be used.
The developers will automatically eliminate all this issues if they will build their software on EOS instead.
I was an Ethereum contract developer and auditor since the very first days and I know it from inside. It is obvious for me that Ethereum is not viable and I have clearly stated it long time ago.
Conclusion
EOS has a number of fundamentally important protocol features such as (1) communication model and secure token standards, (2) on-chain address assignment, (3) upgradeability of contracts. These may seem to be "small cosmetic advantages" for a mere user but it is much more sophisticated in reality.
Each of these features addresses an important problem that could lead to the disastrous consequences otherwise. All this features are absolutely necessary for the mass adoption financial system that is intended to be as fault-tolerant as possible.
Ethereum and many other Ethereum-like protocols lack this features unfortunately. This renders them unsuitable for a wide variety of use cases.
Disclaimer: The views expressed by the author above do not necessarily represent the views of EOS GO. EOS GO is a community where EOS GO Blog being a platform for authors to express their diverse ideas and perspectives. Any referral links present were placed directly by the author, from which EOS Go does not derive any benefits. To learn more about EOS GO and EOS, please join us on our social medias.
EOS GO is funded by EOS ASIA and powered by YOU. Join the community and begin contributing to the movement by adding eos go to your name and joining the EOS GO telegram group.