Going to add more color to the work in progress, what’s taking the time to getting to a decision of what the updated ETA is, where next steps are heading, and why.
TL;DR: The offline prover system was vulnerable to a specialized spam attack that could dramatically bloat storage space, which could at a minimum take nodes offline from their prover rings, at a maximum increase stored data to where generational issuance for the network is effectively stopped. Some solutions are being considered with various tradeoffs, each with their own impacts.
Problem: MPC-in-the-head is a really powerful form of proof, because it shares the MPC technique we use for performing compute on the network, which reduces overall dependencies and thus is a net benefit for security (fewer moving pieces = fewer attack vectors). MPC-in-the-head proofs, however, have the tendency to be quite large. We considered the tradeoff of large proofs to be fine contrasted against the fact our global state is maintained with single slot finality, so we can drop proofs which are no longer needed (e.g. A → A’ → A’’ → A’‘’, we only need the latest for A’‘’). As a consequence of runaway proof sizes relative to stored data, these proofs were a factor in overall network state size measurement, and therefore consequentially impact the issuance rate of the network. Due to their size, this could not be decoupled. For expected initial behaviors (mostly QUIL movement) on the network, the impact of this inclusion in calculation is negligible. An attacker on the other hand, could construct a clever attack which drastically bloats the proof size relative to data impacted, in such a way that the ratio of proof to data it altered is astronomical. In traditional computer attack terms, this is the proof size equivalent of a zip bomb. Over the past few days, I have been cycling through and evaluating options (many thanks to the cryptographers over the past few days who have lent their advice and expertise on alternative routes). I’d like to take a moment to present what those options are, what their advantages and disadvantages are, and what the most pragmatic route to wrapping up 2.0 will be.
Option 1: MPC for online, Risc0 for proofs
Advantages
- Battle tested prover system
- Switches target language for development from bespoke golang subset to broader rust subset
- Brings us closer, faster to supporting all EVM targets for trustless bridging
Disadvantages
- Harder to develop for
- Most substantial change and impactful to timeline
- Prover times are awful on commodity hardware, this would centralize provers immensely and run afoul of our intended outcome of easy and fair participation
- Instruction sets are not aligned, would require work to align MPC compiler to work with RV32IM
Option 2: MPC for online, SP1 for proofs
Advantages:
- Roughly the same advantages as Risc0
- Faster proof times than Risc0 (still slow)
Disadvantages:
- Roughly the same disadvantages as Risc0
- no support for continuations or parallelization
Option 3: Keep full prover system as is, find solution for reducing size of proofs through a recursive compression technique
Advantages:
- Obscenely faster than the above two.
- Fits in nicely with the tools already at our disposal
- I have found zero literature on this, solving this would be greenfield, but not impossible
Disadvantages:
- We have taken conservative stances to avoid completely novel cryptography, e.g. is why PCAS signing is shelved until peer review
Option 4: Impose a tx fee system from day one, rather than optional, proof size counts towards this, and institute a per-tx execution cap.
Advantages
- Immediately stomps on the attack with having an upper bound
- Expensive compute becomes expensive outright (the data greedy model remains default, but miners get a bonus of tx fees on top)
- Is the fastest route to getting 2.0 out, and we can work towards Option 3 as a milestone to lower fees.
Disadvantages
- Has impacts on execution (streaming MPC would necessarily be dead in the water for now, full circuit garbling must be upfront)
- Fee markets would necessarily become a part of protocol instead of out-of-band, but are constrained to shards
Concluding Remarks
At this time, options 1 and 2 have been evaluated, and they simply are not fast enough for general purpose. Option 3 remains an open question, and is left as a milestone objective following Option 4. Option 4 from these choices appears to be the fastest path forward, and will require the addition of three protocol changes, in order of time cost from greatest to least:
- Dynamic fee markets
- Fee market competition in prover ring precedence (to avoid squatted/monopolized rings)
- Incorporating domain separation of the proof outputs of a given prover (previously constrained only to domain separation of the choice of prover) to later support compressed outputs from the prover
I am scoping the work required to complete these features, and will issue an updated ETA for 2.0 rollout following this. I have received a tremendous amount of support, understanding, patience, and grace from most of the members of the community in this process, and I am eternally grateful to you all. For folks who are focused strictly on “wen”, I understand the frustration, and encourage you to invest the time constructively by investigating solutions for Option 3 so we can accelerate through future milestones more rapidly. Crypto is a deep, dark, forest, and as evidenced in the past two months alone, millions of dollars have been hacked in projects who have had multiple audits from credible auditors, rushing carelessly to a finish line for the sake of “wen” is a surefire way to end up another tombstone in the history of projects.
I am going to review this in deeper detail on the scheduled stream to be simulcasted on Twitch and Unlonely at 2024-09-09T01:30:00Z to walk through the problem in depth, plus a deeper dive on developer information and integration.