A pre-consensus mechanism to secure instant finality and long interval in zkRollup

This is not strictly true. A new ZK rollup block is invalid without data availability, which requires whoever is using the ZK rollup to know the data is available. Simply verifying the ZKP off-chain is insufficient to be sure the ZK rollup actually progressed. Assuming a majority of Ethereum miners are honest and that no light-client proof from Ethereum is invalid, you can proof that an event log happened on Ethereum (e.g. a commit was made along with some data being made available), but this assumes a majority of miners are honest. Which is strictly stronger assumption that ORUs make. If you don’t want to make that assumption, you need to make sure the data is available (on Ethereum this requires running an Ethereum full node which involves downloading all block data) as you verify the ZKP.

Not really. When I created the optimistic rollup design paradigm, I did not include the notion of a distinct third-party with powerful compute that must be relied on to verify anything. Everything can be done with full nodes for the rollup, just like we do it at L1. No one calls full nodes “verifiers.” Even when introducing incentivized third-parties and analyzing their incentives and guarantees, there is no distinct “verifier” (i.e. someone that verifies and maybe has some incentives). Rather, it’s “liquidity providers” (i.e. someone that is doing something and also verifies).

1 Like