Ethereum "Modified RISC-V" scares off developers? OG warns: ETH ecosystem will be redistributed, small projects will leave Solana

Ethereum founder V God proposed to replace "RISC-V" with Ethereum in the execution layer to replace the past EVM, which caused some developers to be suspicious, and in 2016, Ethereum developer OG believed that this would make the Ethereum ecosystem face redistribution and be very unfriendly to small capital projects. (Synopsis: Ethereum's handling fees hit a five-year low, and the community set off the "L2 poison theory": there are no cars on the road, and V God is still laughing and building highways) (Background supplement: Dismantling Vitalik's strategic ambition to reconstruct Ethereum's executive layer with "RISC-V instead of EVM" ) Ethereum founder V God's recent "RISC-V" proposal has attracted the attention of the crypto community and caused debate among core ecosystem developers, and for most users, most of them can't understand RISC-V How to reform Ethereum, and what kind of progress can V-God's proposal bring to Ethereum? In order to answer this question, we interviewed an old OG "anti-scale dragon" who has been developing the core ecology of Ethereum since 2016, and he will answer the detailed process of "RISC-V" revision and the short-term negative effects that may occur in the future, reminding all Ethereum investors to pay close attention to the follow-up of this proposal. How to revamp the RISC-V situation Ethereum is different from other PoS chains in that the Ethereum client is composed of two parts, the "consensus layer" and the "execution layer", and the consensus layer is responsible for packaging stake voting, and the execution layer is responsible for processing transactions, so the code that executes the smart contract is actually an execution layer client run by the node computer, which runs the code by grabbing the transaction broadcast, and writes the results of voting through the "consensus layer" on the public ledger. The only way to upgrade the current EVM environment to RISC-V is by updating the "execution layer client" of the node client, which is just a software-level fork, unlike the usual hard fork in the past to change the Ethereum block and the corresponding node revision. According to the content description of V God's paper, ideally, if all node clients have RISC-V executors, then the operation of the protocol for the new version and the operation of the zk proof can achieve nearly 100 times the theoretical efficiency, but it must be known that this is calculated on the smart contract for the RISC-V version and the RISC-V client, relative to the EVM smart contract format executed on the EVM client. What is special about RISC-V's proposal this time is that he is directly revamped on the executive-layer client and will not use the hard fork part, which I don't like very much, but it can be seen that Ethereum is moving in a new direction, which may be a double-edged edge, and this level of change in the past Ethereum may choose to be implemented with a hard fork, because it may be a safer approach. Correspondence between the current situation and the old contract After understanding the performance of the theory, let's look at what the current situation is, the current situation is that all of Ethereum's ecology and all EIP practices are successfully executed through EVM smart contracts and EVM clients, if as V God said that RISC-V will have an EVM transpiler, then the actual future situation may be divided into the following situations EVM smart contracts run on the EVM client (the old EIP is fully compatible, but the new EIP needs to correspond to two versions) The EVM smart contract runs on the RISC-V client through RISC-V's EVM transpiler (the old and new EIPs need to go through a lot of testing and debugging to solve) The RISC-V smart contract runs on the RISC-V client (the old EIP will all be retested, but the new EIP should be perfectly compatible) In summary, considering the theoretical performance of the future smart contract operation efficiency of 100 times, only the third state is applicable, and for the second case, In particular, it relies on the Ethereum core team's optimization of the transpiler, as well as all EIP upgrades and smart contracts in the past, which means that Ethereum needs to pay a very large optimization price in order to achieve theoretical performance improvement, and it is uncertain whether the efficiency optimization of the old EVM code through translation on RISC-V is definitely greater than that of the native EVM environment. In fact, V God said this, I guess there must be many core developers feel very desperate, in the past on the EVM development, to solve each EIP implementation and testing, the workload is already very large, because Ethereum is a community that likes to test open answers in a very open environment. But now when it becomes a RISC-V environment, I just think about the test period of transformation, which is a very headache, the core problem is that you may not be able to run more than 1~5 times more efficient than the original environment during the test period, so I guess this test period will continue to be extended many times, just like Ethereum Merge in the past, so that there is a lack of concrete results in the early stage, and it is difficult to attract external ecosystems to deploy on the testnet and submit feedback. I can only say that V God has great ambitions, but I don't think the implementation is very optimistic, at least I think more than half of the core developers may not be very happy, if they are determined to change to RISC-V, V God and the Ethereum Foundation need to spend a lot of effort to encourage the core developer team and ecology. The problem of ecological correspondence to RISC-V The dragon mentioned that the biggest problem of the RISC-V proposal may come from the support and correspondence of the private project ecology, in the existing open source ecosystem, the components that can be used are very limited, so the slogan of EVM to RISC-V translation proposed by V God may have many doubts and problems in the short term. For example, the existing ecosystem of Ethereum, such as EVM projects and contracts that have no problems, under the premise of EVM to RISC-V translation, there may be a lack of state or termination of operations in the process of executing the contract at the execution layer, which means that even old EVM projects that have not had any problems in the past, in the case of using EVM to RISC-V translation, there may be tokens that cannot be proposed, or accidentally burned or locked. Such an example is very likely to make the ecological project team, in some cases, unwilling to open up users to use the EVM to RISC-V transpiler to run legacy EVM smart contracts; In addition, in order to avoid related risks and follow up with Ethereum's new technology, the best way for the project ecosystem is to write a new RISC-V version of the contract for all smart contracts, and the connection between the old contract and the new contract is solved through asset bridging. In fact, the way to engage in compatibility is very easy to package, but if the foundation is willing to scatter money to get the general solution, then it may solve 99% of the compatibility problems, but the problem lies in the remaining 1% and the security trust of ecological developers. Now you ask the project developers of Ethereum, I guess I will not be so confident in the part of EVM translation RISC-V, big capital technology companies want to belong to their own custom systems or chips from beginning to end, they will not necessarily choose RISC-V, because although this architecture is open source, compared to mainstream architectures such as ARM and X86, RISC-V ecological support is very limited, and there is no related development of the blockchain, which means that Ethereum has to open up a world with bare hands. If in the exam...