Between 2013 and 2014, Vitalik Buterin introduced the Ethereum whitepaper, proposing to store programs on the blockchain. Users can call these programs on nodes, allowing the programs to automatically execute transactions as agents for their creators without human involvement. This is what we know as smart contracts. Buterin believed this mechanism was secure enough to conduct programmatic transactions safely. However, this was a billion-dollar mistake. In just 2020 alone, security issues with smart contracts led to the evaporation of $90 billion worth of crypto assets.
In Ethereum and many of its imitators, each smart contract manages its own ledger of issued tokens. This means that there is more than one ledger on these blockchains. The native coin has one ledger, and each token has its own ledger. Are these decentralized ledgers? The ledger for the native coin is undisputed, but when it comes to the ledger for tokens, we need to consider what truly makes a ledger decentralized.
Decentralization refers to each bookkeeper (miner) independently deciding the contents of their ledger, rather than mechanically copying someone else’s ledger. This independence includes determining if each transaction is legitimate and should be recorded. As long as the network does not favor fraudsters, this method can prevent illegal transactions from becoming the consensus of the blockchain network, thereby safeguarding asset security. If miners in a blockchain lack the ability to independently decide the legitimacy of each transaction, then the blockchain is not decentralized. Miners must rely on a centralized authority to determine the legality of each transaction, meaning all ledgers are controlled by a single entity, jeopardizing security for users. In Ethereum’s smart contract transaction model, token ledgers are managed by the contracts themselves, not the miners. Each contract is released by a single project party, and while miners record the data generated by the contract, they do not understand the data. They simply record what the contract instructs them to. This turns all miners from bookkeepers into pencils, with the project party controlling them. Therefore, these token ledgers are not decentralized but centralized, making them very unsafe.
The smart contracts in Ethereum cannot even be considered contracts. Yes, contracts can be executed by programs, but not every program execution constitutes a contract. Additional conditions must be met for a program’s execution to be considered a contract. For a blockchain that serves as a decentralized ledger, it is crucial that transactions are verified. As Satoshi Nakamoto stated: “Don’t trust, verify.” This is the golden rule of blockchain, and violating it at any point will inevitably lead to security issues. However, Ethereum does not verify the transaction results of smart contracts but only validates the execution process of these contracts. When users call smart contracts in Ethereum, nodes execute these contracts, and as long as the contract returns successfully, the node deems the transaction legitimate and records it. What is the issue with this model? After all, smart contract calls are initiated by users, so shouldn’t they accept the results of these calls? This is the mindset of Ethereum.
Legally, a contract is only valid when both parties agree. The parties involved in a contract must reach a consensus on the contributions and benefits of each party for the contract to be established. Therefore, what do users agree to when calling a smart contract? Do they agree to accept any results generated by the smart contract, or the results claimed by the contract issuer? Most users are not programmers and cannot predict how a program will run, so they agree to the results claimed by the contract issuer. However, Ethereum cannot verify if the execution results of smart contracts match the user’s expectations (i.e., the results claimed by the contract issuer) because Ethereum nodes do not have this information. Therefore, every recorded smart contract transaction in Ethereum only proves that “the smart contract produced such results” rather than “both parties agreed to these results.” Confusing these two can have fatal consequences.
What’s even worse is that Ethereum stores the transaction results of smart contracts as the contracts’ data. In other words, the assets users receive from smart contracts are recorded in the contracts’ ledgers, not the public ledger. Ethereum nodes do not validate the transfer of these assets; the smart contracts handle and verify them. Users cannot directly control these assets; the smart contracts control them. This is essentially inviting theft. As a result, Ethereum users are at the mercy of smart contracts, with no security guarantees. There is no transaction security because Ethereum cannot ensure that the contract execution results meet user expectations, and there is no secure value storage because smart contracts can transfer user assets without their consent.
Therefore, since its release, Ethereum has experienced multiple security incidents related to smart contracts. In contrast, Bitcoin has never had any security issues. It is widely believed that the security problems with smart contracts stem from developer errors and negligence. Therefore, the industry has made significant efforts to standardize the smart contract development process, formally verify smart contracts, conduct security audits of code, and develop secure smart contract languages. However, the security issues with smart contracts fundamentally arise from the industry’s incorrect understanding of decentralized contracts since Ethereum’s release and the inappropriate transaction models that result from this misunderstanding. Resolving these issues can eliminate most of the security issues associated with smart contracts to date. Without addressing these problems, all current efforts will ultimately fail to eliminate the security risks associated with smart contracts.