Insights and Infrastructure Path Ahead

Orbiter Finance’s Evolutionary Voyage

Standing on the shoulders of giants, it becomes apparent to us that Ethereum's evolutionary path has been shaped by three crucial technical advancements: privacy enhancements, Layer 2 scaling solutions, and smart contract wallets. These transformations have played a pivotal role in transitioning Ethereum from its initial experimental stage to a mature technological ecosystem, enabling users to enjoy a genuinely open, global, and permissionless experience. Vitalik has illustrated these interdependent elements in a triangular graph in his post titled 'The Three Transitions,' highlighting their simultaneous and indispensable nature.

We won't delve into exhaustive discussions of the significance of these three Ethereum transformations individually. They are not ‘good to have’ enhancements for protocols, rather, we firmly believe they represent fundamental building blocks for interactions within the Ethereum ecosystem.

Scalability serves as the lifeblood of Ethereum, and Layer 2 scaling solutions have played a pivotal role in mitigating Ethereum's scalability challenges. These solutions, including rollups, have facilitated faster and more cost-effective transactions while upholding the security of the Ethereum mainnet. The advent of Layer 2 scaling has ushered in new opportunities for DApps, enhancing their accessibility to a global user base. Having been landing in the Layer 2 ecosystem, Orbiter Finance recognised that as Layer 2 adoption becomes more widespread, users will hold assets across various Layer 2 networks. Among these Layer 2 users, the majority rely on EOAs, whose addresses essentially consist of a hash of the public key used for signature verification. This means that the user experience remains consistent between Layer 1 and Layer 2. However, for users employing smart contract wallets, maintaining a single, unchanging address poses complexity. The keys required to access different accounts may change over time, rendering old keys obsolete. This situation necessitates a solution that enables users to efficiently manage their keys across diverse networks.

To tackle the challenge of changing access keys, Vitalik once proposed "asset/keystore separation architecture" as an emerging solution. Inspired by this architecture, we found out that each user possesses a keystore contract located in a single location, which could be either on the mainnet or a specific Layer 2 network. Users maintain addresses on various Layer 2 networks, with the verification logic for each of these addresses pointing to the keystore contract. To spend from these addresses, a proof is required to be submitted to the keystore contract, demonstrating the current or very recent spending public key. The graphic below presents how this works.

We shall refrain from delving into detailed intricacies concerning the diverse architectural implementations under consideration. One particular approach aligns with Orbiter Finance's overarching principles, accentuating the virtues of minimised systemic complexity and the judicious economisation of keystore updates. Within this paradigm, each transaction necessitates the presentation of a cross-chain proof, elucidating the current status of the keystore key. While this method offers certain merits, it necessitates a formidable engineering undertaking to render cross-chain proofs economically tenable. This approach, as previously asserted, is characterised by its cost-intensive nature per transaction and its relative incompatibility with the current ERC-4337 standard, which regrettably lacks support for the cross-contract inspection of mutable objects during the validation process. Orbiter Finance's technical geeks have identified that this proof could potentially be implemented using ZK-SNARKs. This would reduce data costs by employing a ZK-SNARK of a Merkle branch instead of the entire branch. Furthermore, off-chain aggregation techniques (e.g., built on top of EIP-4337) could be used to have a single ZK-SNARK verify all cross-chain state proofs within one block. Aggregation here refers to combining all proofs submitted by users within each block into a large meta-proof that encompasses all of them. This approach becomes worthwhile as the scheme gains a substantial user base, making it a realistic choice for the previously mentioned approach. It's here that Orbiter Finance realised that by adopting ZK-SNARKs, we could aggregate users' AA transactions to save gas, potentially reducing ERC-20 transaction gas consumption by up to 20% to 30%. This, in turn, constitutes a pivotal facet of the overarching infrastructure.

Another postulation, as previously articulated by Vitalik, posits that if Layer 2 serves as the scaling for Layer 1, there may well exist yet another layer above Layer 2 poised to further enhance scalability and TPS metrics. As in the realm of Layer 2 solutions, we embark upon an inquiry to ascertain whether there exists another scaling solution capable of augmenting Ethereum's overall performance. Nonetheless, current scaling solutions such as rollups, represent a fusion of diverse approaches aimed at mitigating the bottlenecks scalability: computation and data. The inherent nature of data renders it resistant to repeated compression, while distinct rollup implementations exhibit unique characteristics, each entailing specific trade-offs in terms of security, speed, and cost. Consequently, the conception of another layer for scalability is not always a feasible or stackable proposition. This contemplation also leads us to ponder whether the endeavour to construct an infrastructure encompassing all Layer 2 solutions remains prudent, given the possibility that a rollup atop another rollup or the introduction of a Layer 3 may introduce complexities beyond the initial assumption. In such a scenario, we have explored alternative avenues.

Orbiter Finance has consistently pursued the goal of enhancing interoperability among Ethereum rollups, recognising that seamless communication between these rollups requires a robust infrastructure. Achieving smooth interoperability is a significant challenge for Ethereum's scalability. We are currently exploring the idea of a super Dapp, similar to AA, which could leverage the unique characteristics of various rollups to address specific use cases. To complete a final transaction, it is essential to depend on transactions from numerous previous rollups. However, implementing this requirement in the current rollup architecture would result in high gas costs and delays, rendering it impractical for real-world usage across all rollups. Rollups could opt to wait until there is a batch of L2 transactions worth 10 million gas to submit, but this would lead to extended verification times. In our proposed approach, ZK rollups would accept a message from a batch verifier contract, confirming the verification of a batch of statements, each following a similar pattern as the previous ones. This batch proof could be constructed using a recursive SNARK scheme. Building upon our research, we have developed an open protocol known as the Aggregated zkProver, which allows all ZK rollups to participate. This protocol aggregates proofs from any compatible ZK rollup and they are entitled to receive turnovers coming from transaction fees. The batch handler contract would verify the proof once and then send a message to each rollup, containing a triple in the same format as that rollup's requirements. The fact that the triple originated from the batch handler contract would serve as evidence of the validity of the transition.

This scheme's cost structure offers significant savings for each rollup and effectively serves as an infrastructure for balancing the trade-offs among all ZK rollups. Notably, Vitalik mentioned a similar concept of the Aggregated zkProver in his post about “Layer 3”. He highlighted the advantages of a simplified and highly specialised middle layer, which is more likely to be secure, built without the need for additional specialised tokens, and resistant to frequent governance changes.

Please refer to the chapter below to learn more about how Aggregation and ZK technology is applied in Orbiter Finane’s infrastructure construction.