### **[Current zkVM design](https://hackmd.io/@pse-zkevm/B1kPQYQe1e)**
### **[First release](https://github.com/privacy-scaling-explorations/ceno)**
### [zkVM & The Ethereum Roadmap](https://hackmd.io/dR4V2ZJmSfC4VNFob_2lRA?view)

Notes:
- Fulfil the original mission: zkEVM
- But now we are approaching incrementally: build a RISCV zkVM framework first -> use it to build 2 purpose-built snarks with it -> final act: zkEVM (entire nodes inside the zkVM after it has been battle-tested on those purpose-built snarks and all the "optimization juice" has been squeezed out. Niciety: zkVM upgrades completely decoupled from base-protocol changes because riscv
- Timing wrt to [Ethereum upgrading epochs](https://x.com/VitalikButerin/status/1588669782471368704): now is the time to start
- Edu/Ali/Ming: time is now (discussed on sync Oct 18 2024)
- Temp check this with core eth researchers if this is the time
- Gen-compute in ZK mature enough, we know the good and bad design ideas, we know all the "nice to haves" (eg quantum safety, by-passing need for verkle given bin-trees+zkps, ..)
- The Verge can proceed in parallel to remaining tasks of Merge, Surge, Scourge. Work on the Verge doesn't alter the others and vice versa.
- Verify this further and identify and [points of overlap](https://vitalik.eth.limo/general/2024/10/23/futures4.html#2) here
- Approximate which future hardforks to aim towards for each of our milestones

- Timeline (very rough):
- Building the zkVM is the easy part, all opcodes were done in ~2 months
- Optimizing is the main focus after (eg hybrid binary & goldilock fields)
- Putting ourselves on the spot: 1st SNARKified component of Ethereum on testnets in 2025
- When the 1st SNARK is in audit / client test phase, we start parallelizing and adding members if needed:
- Core: continue to optimize the zkVM itself
- Front: work on the next SNARK
- zkVM is decoupled from Ethereum base protocol changes, so no distruption from there, which is nice
- 2025: 1st SNARK to eliminate consensus committees (least risky)
- Should include state proofs, "this merkle root is part of the latest finalized block", unless we are changing state to verkle or binary, then wait on this
- could aim for testnet by end of 2025, even if (re-re-..)auditing still ongoing
- 2025-26: work starts 2nd SNARK, sig-aggregation (hash-based recursion-based)
- 2026-27: identify how much optimization we want/can do, then start the push to the endgame: zkEVM atop our by-now-hardened-battle-tested zkVM

#### Resources

- No extra members needed in the near future, Even just joined to support R&D (R: hybrid fields, D: precompiles composed from primitive circuits, no DSL)
- When 1st SNARKs is ready and exceptional performance-wise:
- All about Auditing, internal and external
- We have clearer picture of whether and what other resources needed; we will be at a stage where we know how to approximate needs better
- Purpose-specific SNARKs will mostly be in vanilla rust, with some boosters imported as libs, hence accessbile to none-zk devs -> overtime parallelize into Core (arithmetization and prover backend) and Engineering (code proven in the zkVM, starting with SNARK 1/2) subteams
- How much of the auditing we will want to do internally influences the need for zk-security person(s). Longterm, good to have at least 1 exceptional zk-secuity person, also helps in scrutinizing and validating external audits.

- [ ] Ali or Edu to ping Han if he has interest in zkVM