JAM Services for Ethereum Optimistic Rollups and Ethereum

[sourabhniyogi]

JAM’s mission as a rollup host can be extended from validating Polkadot rollups to validating Ethereum optimistic rollups (ORUs) as well as Ethereum itself.

We outline a design for a JAM Service to validate ORUs + Ethereum using a similar approach to Polkadot rollups anticipated in the CoreChains service. The design involves verifying state witnesses against account balances, nonces, code, and storage, and then using this state to re-execute block transactions, all within the service's refine operation; then, these validated ETH L1+L2 blocks are solicited for storage in JAM DA on-chain in the service's accumulate operation.

This JAM service is readily implementable with already available tools that fits seamlessly into JAM’s refine-accumulate service architecture:
(a) Geth’s Consensus API, which outputs state witnesses for Ethereum and its dominant ORU ecosystems (OP Stack and Arbitrum Nitro), and
(b) Rust-based EVM interpreter revm that should be compilable to PolkaVM with polkatool.

This allows Ethereum+ETH L2 ORU users to benefit from JAM’s high computational and storage throughput. The JAM service enables rollup operators to choose JAM Services over other rollup service providers or to enhance their use of Ethereum for improved Web3 user experience, ultimately to provide validity proofs faster.

Furthermore, Ethereum itself can be validated by the same JAM service, providing additional verification for ORU L2 commitments posted to Ethereum across all Ethereum forks.

This is an attempt to accommodate feedback from everyone on #127.

[burdges]

Afaik, there is still zero relationship with the JAM changes here, becuase the accumulate is exactly the parachain accumulate. And hyperbridge should be a bunch of parachains in particular.

There maybe ORs whose blocks come somewhat unordered, which seemingly motivates this being a JAM service, not just a parachain. It's odd if that's true, since ORs have a stagering intershard latency problem. It anyways would not stop hyperbridge from waiting until the OR sequences, or maybe pre-processing with an artificial ordering, and reimposing the OR sequence later.

Are we concernned about transaction throughout? Apepars no: Arbitrum One had a peak transactions per day of 5 M in late 2023, so 60 tps or 350 per 6 second RC block, easily doable without elastic scaling. Arbitrum might've many tiny blocks, but we need those bundled up into full size parachain blocks, not pushed through individually. Arbitum might've higher speed bursts, but we do not care if Hyperbridge Arbitrum lags Arbitrum by even several minutes because Arbitrum has terrible latency to other chains.

[sourabhniyogi]

@rphmeier @burdges The cost of this Succinct Labs SP1 solution to actually finalize any ORU (or Ethereum) with ZK proofs appears economically viable, with claims of $1K-3K/mo fixed proving costs and very reasonable costs per transaction.

If this rsp is production-level, we can certainly have JAM DA hold Succinct (and other prover networks) generated ZK finality proofs, verified in refine and stitched together in accumulate at ETH finalized checkpoints into a chain of ZK finality proofs. How would you see it differently? Is it "vapourware" to you?

[burdges]

I've forgotten why they're reinventing snowfork there, maybe it gives lower latency than the delay method used by snowfork. Anyways, I'd guess the ETH bridges wind up merged eventually after everyone agrees upon which tech to use, just because running them gets expensive, and treasury won't pay for two ETH bridges.

There is no independent reason for a DA layer here, because the only data in the ETH bridge is the validator keys. ETH needs some trick like a SNARK or sampling to track the polkadot validators and prove thewir signatures.

All the OR blocks do end up in polkadot's availability, but that's because they're turnned into parachain blocks.