search

risc0 / zeth

A "Type 0" zkEVM. Prove validity of Ethereum blocks using RISC Zero's zkVM
Apache License 2.0
382 stars 68 forks source link

feat: Provably build derived op blocks #78

Closed hashcashier closed 9 months ago

hashcashier commented 10 months ago

This PR amends the optimism block derivation process to verifiably build (using composition) the block associated with each batch before choosing whether to drop or adopt the batch as the new op head. The transaction data extracted during derivation is used directly as input for the block building process, which is executed as its own zkvm session whose receipt is pulled as an assumption for derivation in via composition.

intoverflow commented 10 months ago

Do we want to execute Op transactions in the derive process? I was thinking that we'd use Zeth for that, as described here.

hashcashier commented 10 months ago

Yeah I don't think that the derive process makes sense on its own without checking for a valid execution as otherwise it could adopt a batch with an invalid chain state/transaction list, violating the spec here. Deferring that check to another program would add complexity imo.

But actually, now that I think about this a bit more in terms of the spec section above and using it as a fraud/validity proof, this needs some changes. It should immediately drop bad batches instead of the post-derive validation it does now.

intoverflow commented 10 months ago

Here's my only hesitation:

The derive process (without tx execution) is very expensive. In the linked Op Rfp comment, running derive for 10 blocks is >1B cycles. It's expensive for two reasons:

  1. It must read a bunch of Eth blocks, and
  2. Batch data tends to be "clumped up:" you can have several Eth blocks in a row with no useful data, then suddenly a bunch of batches all appear at the same time.

Because of this, it makes sense to derive several blocks in the same proof (as this re-uses the work needed to read so many Eth blocks).

But if the derive process also executes transactions, we run into problems with having several blocks derived in 1 proof. (At least, that's what happened when we tried this a few months ago; I will try again with this PR to see if the situation has changed.)

Tldr: including the tx execution in the derive process might increase our total cycle count, since it might restrict us to only deriving 1 block per proof, which prevents us from being able to amorize the costly derive process across several blocks.