Skip to content

Instantly share code, notes, and snippets.

@Dexaran
Last active November 18, 2024 01:40
Show Gist options
  • Save Dexaran/9bd90c1885b4818573368ad02b784125 to your computer and use it in GitHub Desktop.
Save Dexaran/9bd90c1885b4818573368ad02b784125 to your computer and use it in GitHub Desktop.

Poloniex exchange was just hacked.

A hacker made this transaction https://etherscan.io/tx/0xc9700e4f072878c4e4066d1c9cd160692468f2d1c4c47795d28635772abc18db

And the tokens got permanently frozen in the contract of GLM! This shouldn't have happened if ERC-20 GLM token would be developed with security practices in mind. But ERC-20 still contains a security flaw that I discloser multiple times (here is a history of the ERC-20 disaster).

You can also find a full history of my fight with Ethereum Foundation over token standards since 2017 here https://dexaran.github.io/erc223/

The problem is described here.

Here is a security statement regarding the ERC-20 standard flaw: https://callisto.network/erc-20-standard-security-department-statement/

As of today, about $90,000,000 to $200,000,000 are lost to this ERC-20 flaw. Today we can increase this amount by $2,500,000.

The problem with ERC-20 token is that it doesn't allow for error handling which makes it impossible to prevent user errors. It was known for sure that the GLM contract is not supposed to accept GLM tokens. It was intended TO BE THE TOKEN, not to own the tokens. For example if you would send ether, NFT or ERC-223 token to the address of the said GLM contract - you wouldn't lose it.

Error handling is critical for financial software. Users do make mistakes. It's a simple fact. Whether it is misunderstanding of the internal logic of the contract, unfamiliar wallet UI, being drunk when sending a tx or panicking after hacking an exchange - doesn't matter. Anyone could be in a position of a person who just lost $2,5M worth of tokens to a simple bug in the software that could have been easily fixed.

I would use an opportunity to mention that ERC-223 was developed with the main goal of preventing such accidents of "funds loss by mistake: https://eips.ethereum.org/EIPS/eip-223

What is even worse - EIP process doesn't allow for security disclosures now. There is simply no way to report a security flaw in any EIP after its assigned "Final" status.

I'm proposing a modification to EIP process to allow for security disclosures here: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265/12

There are ongoing debates on submission of an informational EIP regarding the ERC-20 security flaw: https://github.com/ethereum-cat-herders/EIPIP/issues/293

And the Informational EIP pull request: ethereum/EIPs#7915

We've built ERC-20 <=> ERC-223 token converter that would allow both standards to co-exist and eventually prevent the issue of lost funds https://dexaran.github.io/token-converter/

Also my team is building a ERC-223 & ERC-20 compatible decentralized exchange that will also remove such a weird opportunity to lose all their life savings to a software bug from users: https://dex223.io/

If you are rich and worried about ERC-20 security bugs dealing damage to Ethereum ecosystem and ruining users days - welcome to our ERC-223 family. We stand for security. We don't let our users funds to be lost by mistake.

@Dexaran
Copy link
Author

Dexaran commented Nov 12, 2024

@u59149403 thank you for your comments.
I've started working on ERC-7417 and Dex223.io decentralized exchange for ERC-223 tokens a year ago. As we are already building the infrastructure for ERC-223 tokens I think it's not acceptable to develop any "backwards-compatible" (or I would say "backwards-insecure") standard at the moment.

I think this situation will develop in the following way: some big player will eventually lose a huge amount of funds, which exceeds the costs of suing the parties responsible. I think that if a fund would lose like $100,000,000 worth of tokens and it wouldn't be recoverable - they would start looking for the reasons of why all that happened. I believe that by using inherently insecure standard (while knowing that users may lose money) ERC-20 token developers become responsible for these losses. Once the precedent would be settled - the ecosystem will restandardize.

@u59149403
Copy link

@Dexaran

ERC-20 token developers become responsible for these losses

This is highly unlikely.

I think native tokens (EIP-7809) is way to go (yes, I changed my opinion on native tokens). Native tokens have many advantages over ERC-223 tokens, and thus native tokens actually have chance to become widespread. And native tokens solve problems, which ERC-223 intends to solve.

  • First of all, if native tokens are implemented in EVM, then they will be considered "official" by everyone and everyone will support them
  • Native tokens implemented directly in nodes, and thus they are very cheap in terms of gas
  • As I said above, native tokens will be "official", and thus they will be supported in Solidity. So, you will be able to write payable functions in Solidity, which accept tokens. Thus you will not have double ABI encoding problem of ERC-223, i. e. you will not need to encode arguments to bytes data. You will get clean type safe experience. (Unfortunately, as well as I understand, EIP-7809's Solidity fork doesn't implement payable. I think this is a mistake.)
  • Node implementations can "see" native tokens, and thus nodes can implement optimizations, which are impossible with ERC-20 and ERC-223 tokens. For example, balance can be stored in owning account (in implementation), not in token contract. This will cause major efficiency gains, because ERC-20 tokens are responsible for huge share of Ethereum state (see figure 2 here: https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1 )
  • When you do ERC-223 transfer, you call untrusted transfer function, which then calls untrusted tokenReceived function. This is bad for security, and opens door for reentrancy attacks and other attacks. And you cannot be sure that transfer will actually execute tokenReceived. You cannot be sure that token contract will not take some fee. With native tokens transfer is implemented directly in nodes, transfer causes execution of receiving function, but it does not cause execution of untrusted code of token itself. Thus, security is improved. Moreover, if you transfer tokens to EOA, then no external code is executed at all!

Also, I propose alternative solution to stuck ERC-20 tokens problem: let user show cryptographic proof of transferring these ERC-20 tokens. I wrote about this here: ethereum/ERCs#658 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment