To start off, if we need EVM on Bitcoin, why not just use Ethereum?
Of course, this is a bit cheeky, but the core reason is that the EVM is not decentralized enough. There are also some fundamental design differences that limit its application on Bitcoin. Let me explain this in detail.
First off, there’s a fundamental difference in the account model. The UTXO model and the Ledger model are fundamentally different. The Ledger model needs to maintain a global state at all times, and while Ethereum’s Merkle Patricia Tree has made significant improvements, this inherently means Ethereum can’t achieve Bitcoin’s SPV (Simplified Payment Verification). Bitcoin could simulate a Ledger model, but it doesn’t need to and shouldn’t. From a decentralization standpoint, not every node needs a global state. In this sense, or even radically speaking, from Bitcoin’s fundamentalist perspective, SPV is clearly the better choice.
So, how does this relate to the EVM? The relationship lies with storage slots, which play a crucial role in the EVM. This data model heavily relies on a global state. While it seems that only a couple of opcodes are involved, the entire EVM operation is built upon them, and Solidity’s syntax is also based on this model. We could simulate a similar model on Bitcoin, but it’s fundamentally different from designing it that way from the start, both in efficiency and scalability.
Another related factor is the presence of opcodes like Address, Balance, and SelfBalance in the EVM, which are designed with Ethereum’s balance model in mind. This includes operations like transfers.
Although these could be simulated, when compared with Bitcoin’s simple and efficient UTXO design, they become quite incompatible. This also extends to a common critique of the EVM: Token balances are not first-class citizens. ERC20/721 token balances are just field values in a data table, meaningless outside their contracts. While I personally don’t see this as a big issue, it does create inconsistencies between ETH and token balances, and you can look into the history of WETH for more on this. Of course, this also brings other issues, which we won’t dive into here.
Lastly, let’s talk about sharding and concurrent execution technologies. From the beginning, the EVM has not considered parallel execution. It’s not that it can’t or won’t, but achieving high concurrency requires significant modifications. Otherwise, Aptos wouldn’t need an entire paper to discuss this.
Are there any other limiting factors? Yes, there are, such as the closed nature of Solidity and limited cryptographic algorithm support. However, these can be improved. The core factors mentioned earlier, though, fundamentally limit its application on Bitcoin.
Undoubtedly, EVM is a great innovation. EVM compatibility may offer some benefits in terms of interoperability and developer familiarity, and it has proven to be successful. But eventually, the EVM was designed for Ethereum, not for the Bitcoin world.
