The "RISC-V" proposal recently launched by Ethereum founder Vitalik Buterin has attracted the attention of the crypto community and sparked debate among core ecosystem developers. However, for most users, they do not understand how RISC-V can be reformed on Ethereum. What kind of progress can Vitalik's proposal bring to Ethereum?
In order to answer this question, Dynamic Zone interviewed an old OG "Ni Lin Zhi Long" who has been developing the core ecology of Ethereum since 2016. He explained to us the detailed process of the "RISC-V" revision and the possible short-term negative effects in the future, and reminded all Ethereum investors that they should pay close attention to the follow-up of this proposal.
How to modify RISC-V
Ethereum is different from other PoS chains in that the Ethereum client consists of two parts: the "consensus layer" and the "execution layer". The consensus layer is responsible for packaging equity voting, and the execution layer is responsible for processing transactions. Therefore, the execution layer client that executes the smart contract code is actually run by the node computer. It runs the code by capturing transaction broadcasts and writes the results of the "consensus layer" voting on the public ledger.
The only way to upgrade the current EVM environment to RISC-V is to upgrade by updating the "execution layer client" of the node client. This is different from the hard fork method used in the past to change the Ethereum block and the corresponding node version. This is only a software-level fork.
According to Vitalik Buterin's paper, ideally, if all node clients have RISC-V executables, the new version of the protocol and zk proofs can achieve a theoretical performance nearly 100 times higher. However, it must be noted that this is calculated on the RISC-V version of the smart contract and the RISC-V client, as opposed to the EVM smart contract format executed on the EVM client.
What is special about the RISC-V proposal is that it will directly modify the execution layer client and will not involve the hard fork. I don’t like this very much, but it can be seen that Ethereum is moving in a new direction. This may be a double-edged sword. In the past, Ethereum might choose to implement this level of change together with a hard fork because it may be a safer approach.
Correspondence between current situation and old contracts
After understanding the theoretical performance, let’s look at the current situation. The current situation is that the entire Ethereum ecosystem and all EIP practices are successfully executed through EVM smart contracts and EVM clients. If RISC-V will have an EVM translator as Vitalik Buterin said, then the actual future situation may be divided into the following situations
- EVM smart contracts run on EVM clients (old EIPs are fully compatible, but new EIPs require two corresponding versions)
- EVM smart contracts run on RISC-V clients through the RISC-V EVM translator (new and old EIPs require extensive testing and debugging to resolve)
- RISC-V smart contracts run on RISC-V clients (all old EIPs need to be retested, but new EIPs should be perfectly compatible)
In summary, considering the theoretical performance of 100 times the running efficiency of smart contracts in the future, only the third state is applicable. For the second situation, it is particularly dependent on the Ethereum core team's optimization of the translator, as well as all past EIP upgrades and smart contracts. This means that in order to achieve the theoretical performance improvement, Ethereum needs to pay a very high optimization cost, and it is uncertain whether the efficiency optimization of the old EVM code executed through translation on RISC-V is absolutely greater than that of the native EVM environment.
In fact, after hearing what Vitalik said, I guess many core developers must feel desperate. In the past, developing on EVM and solving the implementation and testing of each EIP were already a huge workload, because Ethereum is a community that likes to test open answers in a very open environment.
But now that it has become a RISC-V environment, I am very troubled by the testing period of the transition. The core problem is that during the testing period, you may not be able to run at an efficiency that is 1 to 5 times greater than the original environment. Therefore, I guess this testing period will be continuously extended many times, just like the Ethereum Merge in the past. In this way, there is a lack of concrete results in the early stage, and it is difficult to attract external ecosystems to deploy on the test network and submit feedback.
I can only say that Vitalik has great ambitions, but I am not very optimistic about the execution. At least I think more than half of the core developers may not be very happy. If they insist on changing to RISC-V, Vitalik and the Ethereum Foundation will need to spend a lot of effort to inspire the core developer team and ecosystem.
Ecosystem issues related to RISC-V
The Dragon of the Reverse Scale mentioned that the biggest problem with the RISC-V proposal may come from the support and correspondence of the private project ecosystem. In the existing open source ecosystem, the components that can be used are very limited. Therefore, the slogan of EVM to RISC-V translation proposed by Vitalik Buterin may have many doubts and problems in the short term.
For example, in the existing ecosystem of Ethereum, there are EVM projects and contracts that originally had no problems. Under the premise of EVM to RISC-V translation, the state may be missing or the operation may be terminated during the execution of the contract at the execution layer. This means that even for old EVM projects that have never had any problems in the past, when using EVM to RISC-V translation, tokens may not be withdrawn, or may be accidentally burned or locked.
Such examples are very likely to make the ecological project team, in some cases, unwilling to allow users to use the EVM to RISC-V translator to run old EVM smart contracts. In addition, in order to avoid related risks and keep up with Ethereum's new technologies, the best way for the project ecosystem is to write new RISC-V version contracts for all smart contracts, and the connection between old contracts and new contracts is solved through asset bridging.
In fact, the way to achieve compatibility is very easy to go wrong, but if the foundation is willing to spend a lot of money to solve the General solution, then 99% of the compatibility problems may be solved, but the problem lies in the remaining 1% and the security trust of ecosystem developers.
If you ask Ethereum project developers now, I guess they are not so confident about the EVM translation to RISC-V. If large-capital technology companies want to deploy their own customized systems or chips from start to finish, they may not choose RISC-V. Because although this architecture is open source, compared with mainstream architectures such as ARM and X86, RISC-V ecosystem support is very limited, and there is no related development of blockchain. This means that Ethereum has to carve out a niche for itself with bare hands.
If security and ecosystem support are taken into consideration, wealthy projects that want to be safe can build a bridge between the old and new contracts themselves, which can easily cost hundreds of thousands to millions of dollars. Rewriting all EVM smart contracts of the protocol app to the RISC-V version is an even bigger project. Companies that are not well-capitalized may not be able to afford these additional costs.
I’m not sure whether Vitalik has thought about small-scale ecological projects. Maybe after seeing the RISC-V proposal, he is waiting to see whether to leave the Ethereum ecosystem. If it is a small project with a valuation of less than 10 million US dollars, I think it is better to move it directly to Solana. There is no need to spend money and wait for Ethereum to slowly develop, which may not necessarily succeed.
Ethereum is now using technical terms to meet the expectations of engineers and technology geeks, but in order to balance this with reality, I think Ethereum needs to give the community and developer ecosystem a balanced answer in the RISC-V proposal.
Client fragmentation effect, concerns about discontinuation of updates
To implement the "RISC-V" proposal, the Ethereum client brand is crucial, but unlike in the past, the client was only responsible for maintaining the EVM version, and the workload under the current "RISC-V" proposal has directly doubled, which is bound to affect the time of each EIP and client revision, and will make the overall revision cost of Ethereum higher and more cumbersome.
The inequality in the number of smart contracts in the early EVM and RISC-V formats on the chain may also cause each client to be "biased" towards one side of the development, which means that the client may be friendly to EVM and have a poor translation to RISC-V, or vice versa. This may result in the client adopting different policies to reallocate users when facing different customers and different entity needs.
The "eclipse" problem that may occur in the market is certainly not necessarily the same as what the Ethereum Foundation expects. The Ethereum Foundation will inevitably have to provide more funding and intervention in the RISC-V client to formulate existing specifications. However, today's client funding has long been sourced from major commercial users (such as Coinbase, etc.), and the Ethereum Foundation's financial intervention and participation may not be as crude and effective as before.
Finally, there is the issue of maintenance period. Just like when the mobile phone system stops updating, if the "RISC-V" proposal goes ahead, everyone should be able to foresee that within a foreseeable period, the EVM client may gradually withdraw from the market when the RISC-V client is improved. Before that, can we try our best to make all smart contracts compatible with RISC-V? Or will it happen that because of the lack of participation in blockchain activities during this period, customer assets will be lost in old and unexecutable EVM smart contracts? This may affect users' confidence in Ethereum.
In fact, if you see slogans like "EVM and RISC-V will run on dual tracks", and you believe that this will continue, I would think you are very stupid. Because all software has a maintenance cycle, when a new version comes out, the old one will be eliminated sooner or later. This is the law of technology. So I think the launch of the RISC-V revision means that one day, someone will be unable to withdraw the assets in the EVM contract.
But I don’t think the same situation will happen with Bitcoin. Until now, the earliest Bitcoins in p2pk format can still be received. I think it is very important for blockchain to provide security and commitment to users.
In the past, I thought that if you put your assets on smart contracts, as long as you hold IOU tokens, even if the old contracts are no longer maintained and Uniswap has reached V4, you can still retrieve your assets from that year on V1 or V2. This is what I think the blockchain promise should be fulfilled, and it is also the function and value of blockchain that this society needs. But if Ethereum really launches the RISC-V version and announces the abandonment of native client support for EVM contracts within its lifetime, I will be disappointed with this public chain and community.
