ZKP Applications in Orbiter Finance
At the forefront of Ethereum’s infrastructure, Orbiter Finance has harnessed the power of ZKP to achieve scalability and trustless. Recursive zero-knowledge proofs as emerging cryptographic primitives are pertinent to Orbiter Finance’s use cases.
Use Case 1: ZK-SPV
As elucidated within the Security Mechanism section above, the transaction procedure within Orbiter Finance, ZK-SPV based on the specific rollup mechanism serves to authenticate the validity of designated transaction execution timing, transaction amount, and adherence to the Maker-defined service conditions. This extends to the identification of cross-rollup transactions, with ZK-SPV maintaining stringent constraints to proactively curtail any potential malicious actions initiated by the Maker. The operational process of ZK-SPV in a transaction procedure can be better understood by consulting the diagram provided in the Security Mechanism section.
Use Case 2: ZkProver
Our transactional prowess revolves around the seamless facilitation of transfers between two externally owned account (EOA) addresses, thereby ensuring exceptional efficiency and cost-effectiveness in cross-rollup transactions.
Nonetheless, it is prudent to recognise that when juxtaposed with EOA transactions, Account Abstraction (AA) technology brings forth plenty of advantages. AA offers users a versatile array of features including flexible signature verification, gas abstraction, session keys, social recovery, and multi-factor authentication. Moreover, EIP-4337 account abstraction on the Ethereum mainnet foreshadows AA's burgeoning significance as a pivotal activity carrier within the Ethereum ecosystem in the near future. As AA is integrated into the network through smart contracts, users can relish enhanced operational flexibility.
While the advent of AA bestows convenience upon users, it concurrently entails heightened usage costs primarily attributed to the relatively higher gas fees incurred by the increased logic of AA smart contracts.
To expedite the mass adoption of AA, zkProver is devised with the ultimate objective of mitigating usage expenses and optimising gas consumption. With the application of Zero Knowledge (ZK) technology, this initiative is dedicated to user-friendly deployment on the Ethereum ecosystem, aiming to achieve ease of use, fairness, decentralisation, and safeguarding user privacy. With zkProver, our unwavering pursuit is to forge a path towards a future where the benefits of Account Abstraction are harnessed seamlessly and efficiently. Furthermore, despite the strides made by EIP-4337 towards cross-L2 compatibility, it has not yet achieved complete cross-L2 friendliness. There's still a need to enhance instantaneous communication and interoperability among all L2 solutions. However, this challenge can be overcome with the implementation of zkProver. Through zkProver, users will eventually gain the capability to effortlessly traverse various L2 environments within the Ethereum ecosystem. This will enable rapid and seamless transfers of both assets and operational accounts, granting users the convenience of engaging with diverse computations across different Layer 2 networks simultaneously. This holistic approach not only guarantees limitless scalability but also provides users with a smooth experience, exemplifying Ethereum's ultimate scaling potential.
Architecture of zkProver
Gas Analysis in Comparative Setting
Within the realm of the EIP-4337 account abstraction contract, an aggregation of transaction signature verification, nonce value updates, and gas fee calculations culminates in a heightened gas consumption compared to average transaction execution.
In the context of an ERC20 token transfer instigated by an EOA address, the signature and nonce verification are validated by the RPC node before being submitted to the chain protocol for final inclusion. Gas primarily comprises the foundational gas amount of 21,000 alongside the gas expended for the smart contract transactions — approximately 34,330 gas when utilising the OpenZeppelin ERC20 template.
Conversely, when a transfer originates from an AA account, signature validation, nonce update verification, and gas fee settlement transpire on-chain, resulting in a gas tally of 57,135.
Should we deviate from Ethereum's ecdsa signature and adopt a non-EVM built-in algorithm like BLS, the gas consumption skyrockets to 148,123.
We then devised a bundler service with functions listed below rooted in the zk environment architecture to address high gas consumption challenges.
Verification of user Tx signature accuracy.
Maintenance of the nonce value and Gas balance of the AA account through a Merkle world state tree.
By updating the Merkle Root within the Ethereum mainnet's EntryPoint contract and aggregating multiple transactions and equitably distributing zkp verification gas, these approaches lower the threshold for AA usage while preserving their flexibility in L1 transactions. Remarkably, a standard ERC20 transfer can ultimately economise 30% of gas. The average gas expenditure after aggregating 128 transactions stands at 23,843.
Workflow
Drawing inspiration from the architecture of EIP-4337, we have devised a framework akin to zkProver. Illustrated in the flowchart below, the work flows are as follows:
The process begins with the Bundler collecting verified signatures from transactions.
The Bundler then aggregates these transactions, creating a consolidated batch.
The aggregated batch of transactions is then passed to the EntryPoint contract.
The EntryPoint contract validates the signatures and updates the nonces of the AA accounts.
However, within the construct of our zkProver architecture, the Bundler's role is redefined. It now gathers the already-verified signatures of these aggregated transactions before subsequently submitting them to the EntryPoint contract.
With two distinct architectural approaches, Account Abstraction presents significant enhancements in the operational flexibility of user accounts; however, this convenience comes at the cost of increased gas consumption. Recognizing this trade-off, we thus conducted a thorough analysis of gas-intensive processes and consequently devised zkProver, centred around zero-knowledge proofs (zkp), to effectively address this challenge.
Meanwhile, the architectural framework of zkProver aligns well with the insights shared by Vitalik Buterin in his article, available at https://vitalik.ca/general/2022/09/17/layer_3.html. In this article, the substantial benefits of aggregated proofs are expounded, showcasing their capacity to curtail the verification costs associated with zero-knowledge proofs (zkp). Moreover, the article underscores how the aggregated proofs contribute to the simplification of user interactions, thereby reducing the complexities inherent in interchain interoperability. The synergies between the principles outlined in the article and the concepts of zkProver underscore the shared commitment to enhancing efficiency, reducing costs, and fostering enhanced user experiences within the realm of Ethereum.
This convergence of ideas further solidifies our conviction that zkProver is not only a strategic pursuit but a genuinely transformative endeavour, poised to establish itself as a foundational infrastructure capable of facilitating real-time communication and inter-chain scalability within the Ethereum ecosystem.
Anticipating its unveiling, zkProver is set to make its debut in Q4 of this year, and we are eagerly looking forward to sharing its advancements with the community.
Vitalik stated that "everyone will transition to rollups," indicating that there is a strong trend towards a scaling roadmap centred around rollups for Ethereum. We are now heading to the final stages of this journey, where we have proposed a protocol for interchain messaging and developed an aggregated middle layer for zk rollups. Our goal is to enable cross-rollup transactions, thereby enhancing the inter-chain interoperability of Ethereum and ensuring that rollups remain synchronised with the main network in real-time. Our Future for Ethereum Layer 2 Infrastructure Awaits.
Last updated
