Crosschain Escrow on L3 <> L1 Validity Rollups

Crosschain Escrow on L3 <> L1 Validity Rollups

Native zkRollups utilizing a L3-Architecture based on Polygon's zkEVM to solve the interoperability between networks through a common state on L2. Exemplary app: Multichain Escrow between L1 and L3.

The problem Crosschain Escrow on L3 <> L1 Validity Rollups solves

Our project was inspired by this blog article:

As Polygon's zkEVM Beta got live this week, we thought it would be cool to get their zkEVM running locally and putting it on top of the L2 zkEVM, to have a super simplistic L3 architecture.

The trend seems to go towards a multi-layer architecture in future, such as L3's potentially for cross-chain compatibility, or L4's for privacy. Although, L3's might solve the interoperability issue between L3's and above, we might still have interoperability issues between lower layers.

Thankfully, really smart people developed somewhat resilient bridges, LayerZero, Cosmos, Polkadot & others that get better every day. Nonetheless, going from L3 to L1, might require multiple steps.

So we thought having a simple use case such as an Multichain Escrow between L1 and L3 could be a very interesting thought-model to exchange assets between networks that are not directly connected to each other such as L1's and L2's.

Considering the nature of Validity rollups and it's finality characteristics in contrast to optimistic rollups, it should not make that much of a difference if someone uses validity proofs between L1 & L2, or L1 and L3 as long as the single layers are Validity rollups.

Challenges we ran into

Our project had a strong infrastructure component and app-layer component. As a consequence some of the challenges we faced include setting up the Polygon zkEVM stack with a mocked L1, their L2 and then putting their L2 as L3 on top of their current stack. We had to try several different approaches to accomplish this, but in the end we just went for a solution that involves two computers to keep keep the changeset small.

Another challenge we faced was when building the L1<>L3 Multichain Escrow with Bonsai and sending a dynamic payload from the Smart Contract to the Guest Code, as it required a length parameter that had to be calculated in a dynamic fashion onchain and needed to be directly encoded into the payload.

Further issues, include integrating Bonsai's Guest Code with Web3 libraries to verify that the payment had been made. The problem was that some libraries don't seem to be compatible as a simple import for certain libs made the Guest code crash.