Use contracts to store large preimages about cannon HOT 5 CLOSED

Axiom: All blocks have a single canonical MIPS run that's runnable on chain.

They produce either 0 (very rare "weird block") or 1 output state root. From the above axiom, it's clear they can't produce two.

Also from the above axiom, if they produce 0 (with a timeout for the halting problem), they provably produce 0. So with a little effort to deal with censorship, you don't need all state transitions to produce 1, you just deal with the 0.

The difference between all MIPS transitions and not is whether it provably produces 0 or not. Provably producing 0 is so much easier to deal with externally, and I doubt you need all to produce 1 (which is the not x proof discussed yesterday)

This was my bad trying to weasel out of keccak :)

from cannon.

I don't actually need to store the whole thing, I'm only going to store the specific 4 bytes needed for the transition (still need to check the whole thing though). So I think this is moot.

Also, after rereading my contract you are in luck! There's a specified 8M per tx gas limit on the MIPS transitions, so you'll get the large preimage keccak fix for no additional charge. My plan is just to write piecewise keccak on chain. While I didn't think I'd have to write this, I did agree to it, so it's on me.

You raised a good distinction yesterday between MIPS and block transitions. While there may possibly be unprovable block transitions, and this is quite hard to combat, there shouldn't be unprovable MIPS transitions, of which this large preimage is the only one I can think of. I was trying to argue that it has the same outcome, but that isn't exactly true,, see next paragraph.

This will also allow provable detection of "weird blocks", which should allow you to design the system around it such that unprovable blocks won't be a problem in practice (you can detect bad exit codes, and you can get around the halting problem with a crazy high instruction count limit), and won't have to resort to governance.

from cannon.

I don't actually need to store the whole thing

Ahhhh, great idea. That is a much better optimization, I'll close this ticket.

with a little effort to deal with censorship

This is a great point; I'll reflect somewhere that we want a way to guarantee that users can "get their own block to themselves" somehow. (outside of cannon's scope obviously)

Glad we're on the same page with the rest -- that axiom is right on the money and likewise why I was focused on keccak :)

from cannon.

Actually, now I'm not sure -- how will you run the off-chain MIPS in EVM without storing the full thing? You only need one step during the fraud proof, but if you don't have that luxury in mipsevm. Won't this still help in that case?

from cannon.

Ah, I missed this.

from cannon.