GoPlus Security 🚦 (@GoPlusSecurity): Lean #Ethereum — Ethereum’s third major upgrade in history shows that #ETH is seriously rethinking its underlying technical architecture. Recursive ST…

Lean #Ethereum — Ethereum’s third major upgrade in history shows that #ETH is seriously rethinking its underlying technical architecture. Recursive STARKs, privacy, formal verification, and quantum security are finally being placed where they belong. However, the challenge is also clear: if new kinds of state are not handled properly, the improvements in scalability may come with increased complexity and security burdens shifted to the application and infrastructure layers. From a security perspective, we are particularly focused on the following points: 1. Whether new state types will introduce new composability risks. Changes in state type consistency, visibility, ordering semantics, and proof costs may lead to a new wave of security vulnerabilities and attack vectors in the future. How these risks can be identified, prevented, and mitigated as early as possible will be critical. 2. Preparation for post-quantum security. Three to four years may not be a long time for protocol evolution, but for cryptographic migration, it is definitely not a short window. Quantum security is not a “feature launch” problem, but a “full ecosystem coordinated migration” problem. The later the preparation begins, the greater the friction during future transitions. It is recommended to define compatible layers, transition layers, and replacement paths that can be implemented early. 3.Regarding the “new VM”, if Ethereum is truly going to be rebuilt around recursive proofs, verifiable execution, and stronger privacy capabilities in the future, relying solely on today’s EVM is clearly unrealistic. Introducing an execution model better suited for proof systems is a natural direction. But how should paths such as Cairo, RISC-V, and leanISA be chosen? We believe that an execution environment designed to be ZK/STARK-friendly is indeed more aligned with long-term development logic than continuing to build endless compatibility on top of existing abstractions. However, this cannot be evaluated solely from the perspective of “better performance”. Migration costs, developer learning curves, audit ecosystem maturity, and most importantly, the social acceptability of protocol governance must also be considered. The technically optimal solution is not necessarily the one that can be most easily adopted at the system evolution level.