The document titled \'Zeko: Fractal scaling of ZK applications using a Shared Sequencer L2 Stack\' proposes a ZK rollup architecture for the Mina blockchain. Key points include:- Zeko aims to increase Mina's throughput, enable new dApps possibilities, implement reusable rollup architecture, and improve UX with faster block times.- It uses a Data Availability (DA) layer to store and propagate data since Mina L1 has limited on-chain storage. The initial DA implementation will be an Ethermint chain.- The ZK rollup supports L1->L2 and L2->L1 bridging of assets. L1->L2 is asynchronous while L2->L1 is synchronous. - The L2 uses the same execution environment as L1, enabling developers to reuse existing tools and contracts.- Transaction fees are expected to be in the single digit cents range, cheaper than other rollups like Optimism.- Future development includes decentralizing the DA layer, L2 token staking, safe L2->L1 exits without sequencers, interoperability with other L2s, upgradability, and connecting to Mina bridges.- The security model assumes a partially synchronous network, slowly adaptive adversaries, and rational actors. Key desired properties are liveness and secure bridging.In summary, Zeko proposes a modular ZK rollup architecture for Mina using a DA layer that aims to enable scalability while preserving compatibility with the Mina ecosystem. The long-term vision is to enable easy creation of multiple interoperable L2s.
Zeko: Recursive zero-knowledge applications, at scale The major negative of this approach is that if for some reason sequencers are offline, the transfer request never gets relayed to the DA layer (due to software error or malicious action), or the only online sequencers are malicious, then the user may end up with their funds stuck with no recourse (users will also be able to re-submit their transfer request inputs to the sequencers via the bridge zkApp frontend, however this is merely a good stop-gap, not a perfect solution). As such, especially when entering into a future with a multi-sequencer setup with open membership, it will be important to implement a timeout protocol which specifies that any L1L2 bridge transfer request is only able to be fulfilled if it is included in a new batch within X hours (X being measured as a predefined number of blocks that is universal for all requests).
id: c45c85852d7fc871876ab9c99ddaee7c - page: 10
6.2 Local Pending Transfer Queue Each sequencer builds their own local viewith queue of which L1L2 transfer requests in the pool are still pending. This is required due to two primary vectors: 1. Mina L1 can rollback, meaning previously confirmed bridge transfer requests can be reverted back into a pending state. 2. Individual sequencers can potentially go rogue and post fake (never included on Mina L1) or previously valid (requests submitted before a rollback) transfer requests which are not valid currently. Because Mina L1 does not have deterministic finality, we cannot guarantee a 1-to-1 correspondence of submitted bridge transfer requests and bridge transfer requests posted in the DA layer pool. There is the possibility of rollbacks taking place which suddenly makes previously confirmed bridge transfer requests be put back into pending or potentially even invalid state (because the L1 was rolled back to before the bridge transfer request was posted at all).
id: 2939f77594c1765078711b44afc518a1 - page: 10
As such we cannot treat the pool as a pure source of truth, meaning that sequencers must always reference Mina L1 to verify that said transfer requests were indeed posted/are currently pending. Of note when a sequencer posts a batch to the Mina L1 rollup contract, it will check the receipts to ensure that the bridge transfers are indeed valid, thereby preventing incoherent states from being reached (tokens being sent in the L2 without depositing them on the L1). Even though this check is in place to keep things secure, the sequencer still needs to know which requests are indeed valid when building their batch (so that they dont do wasteful work in aggregating proofs and submitting their batch to the DA layer just for it to get rejected because of invalid L1L2 transfer requests). This is why the local pending transfer queue is required.
id: b61fed22546295634d6601554e48c58b - page: 10
6.3 L1L2 Receipts To reiterate, receipts are a piece of data which get bundled together with batches which specify which transfer requests were included inside of the batch. From the L1L2 bridge perspective, receipts allow us to: 1. Ensure that each batch posted to the Mina L1 rollup contract only include valid (currently pending) L1L2 bridge transfer requests. 2. Update the state of a bridge transfer request on the L1 to be explicitly fulfilled (required when request timeouts are implemented in the bridge). As such, receipts guarantee that the L1L2 bridge maintains coherency, while also ensuring that every bridge transfer request will terminate, either as fulfilled or redeemable. Redeemable requests will be processed by sequencers and not by users as allowing users to redeem directly would lead to problems arising from concurrent contract modification which would slowdown the rollup.
id: 3958cdacf06c891c64b2843429b308f3 - page: 10