News

Ethereum co-founder Vitalik Buterin pointed out in an article that the current mainstream "token voting controls treasury" model of DAOs suffers from inefficiency and is prone to manipulation, failing to address human political weaknesses. He believes that DAOs are still necessary mechanisms for oracle design, on-chain dispute resolution, project initiation, and long-term maintenance. He suggests using ZK technology to ensure privacy and leveraging AI to alleviate governance fatigue. In addition, Vitalik emphasized the importance of communication platforms in the DAO stack, calling for the "communication layer" and "consensus tools" to be core construction goals in governance design.

Jinse Finance reported that Vitalik Buterin posted on X, stating, "I am now more inclined towards native rollups than before. One important reason I was previously opposed is that native rollup precompiles must choose between 'zk mode' or 'optimistic mode.' ZK-EVM is still not mature enough under zk mode, so if we provide L2 with two options: 'use proofs fully endorsed by Ethereum, but withdrawals require a 2–7 day wait,' or 'instant withdrawals, but you have to handle the proofs yourself,' L2s usually choose the former. This is very detrimental to Ethereum's composability and leads to the adoption of more multisig bridges, among other issues. But now it seems that Ethereum's full acceptance of zk on L1 and the realistic timeline for adding native rollup precompiles actually match, so this problem is solved. In addition, I see more and more work taking synchronous composability as one of the core value propositions for doing L2. I have also proposed a method: https://ethresear.ch/t/combining-preconfirmations-with-based-rollups-for-synchronous-composability/23863, which combines based rollups with L2 low-latency preconfirmations (preconf) to achieve synchronous composability. So it feels like this is the right direction for development. I think we shouldn't be lazy and need to spend more effort figuring out the best way to implement this precompile. One key property I want is: if you make a rollup that is 'EVM + some new features,' you should be able to use the native rollup precompile for EVM, while using your own prover to handle your added features. You can consider using a lookup table to standardize the connection between the two."

According to Odaily, Vitalik Buterin stated in a post that he is now "clearly more inclined to support native rollups" compared to the past. Vitalik recalled that a major reason for previously opposing native rollups was that their precompile schemes had to choose between ZK mode or Optimistic mode. At that time, ZK-EVM was still immature, and L2s often chose the latter option—"relying on Ethereum security but requiring a 2–7 day withdrawal period"—over "fast withdrawals but bearing proof risks themselves." This weakened Ethereum's composability and promoted the popularity of solutions such as multisig bridges. Vitalik pointed out that the situation is now changing: the timeline for Ethereum to fully embrace ZK at the L1 level is gradually aligning with the practical progress of introducing native rollup precompiles, and the core obstacles mentioned above are expected to be eliminated. He also mentioned that the community is increasingly viewing "synchronous composability" as one of the core values of L2s and is exploring the combination of rollup-based solutions with low-latency pre-confirmation mechanisms. In addition, Vitalik emphasized that the design of native rollup precompiles should not be hastily advanced in terms of specific implementation. He proposed that, in the future, there should be a property such that if developers are building a rollup that is "EVM with a small number of extended features," they can directly reuse the EVM part of the native rollup precompile and only introduce a custom proof system for the new features, connecting the two in a standardized way.