Forum
Finance
Specials
On-chain Eco
Entry
Podcasts
Activities
OPRR
Electron Labs New Proposal: Integrating IBC into Ethereum
Original title: "Bringing IBC to Ethereum using ZK-Snarks"
Original author: Garvit Goel, Jinank Jain, Electron Labs
Original compilation : Uncle Red Army, IBCL
This is an article on how to bring IBC to Ethereum. The purpose of this article is to outline the technical details of the project and gain support from the Ethereum community. Let's dig into it.
IBC stands for Inter Blockchain Communication - Cosmos Cross-chain standards in the ecosystem.
Problem Background
IBC follows the principle of light client and needs to integrate the source blockchain and The light client of the target blockchain is implemented as a smart contract to verify cross-chain transactions.
This means that in order to connect IBC to Eth, we need to run a smart contract on Ethereum Tendermint Light Client (run the Tendermint light client on Ethereum as a solidity smart contract).
But this process consumes gas expensive, because it needs to verify hundreds of ed25519 signatures in Solidity, and ed25519 is precompiled in ether Not available on the market. An ed25519 requires 500K gas.
This means that validating a complete light client header will require at least 50 million gas fees (100 validators), for larger ones with 1000 validators The Cosmos chain is as high as 500 million gas.
Therefore, in order to verify signatures more cheaply on Ethereum, we need new methods.
Solution
We achieve this by taking inspiration from zk-rollups. Instead of verifying ed25519's signature directly on Ethereum, (and performing the curve operation inside a solidity smart contract), we construct a zk proof of the validity of the signature and verify that proof on-chain.
At Electron Labs we built a circom-based library that allows you to generate zk-snark proofs for a batch of Ed25519 signatures. Check out the full implementation here .
How to participate in the experience?
We have deployed a server with an endpoint that allows you to submit a batch of signatures and get a zk-proof in return. You can now test using the API reference given in our documentation.
Mathematical implementation details
Creating a ZK proof for ed25519 is a hard problem.
This is because the twisted Edwards curve of ed25519 uses a larger finite field than the altbn128 curve (used by zk-snarks). Performing large finite field operations within smaller fields is difficult because some basic operations such as modulus and multiplication can become very inefficient.
In order to solve this problem, we can find 2^85 as the base to define the curve operation of our twisted Edwards curve. Since the ed25519 prime p=2^255-19 is an approximate multiple of 2^85, we are able to come up with efficient elementary operations for numbers in base 2^85, such as multiplication and modulo (under the 25519 prime).
Next, we use these custom operations to define curve operations in the ZK circuit, such as point addition, scalar multiplication, and signature verification.
It's hard to do justice to the mathematical details behind this in this documentation, see our Detailed document explanation .
Performance of Single Signature Proof
Thanks to the above optimizations, we are able to achieve for a single signature The performance data is as follows:
All metrics are measured on a 16-core 3.0GHz machine with 32G memory (AWS c5a.4xlarge instance)
Batch Prover Performance
To understand system level performance we need to look at 3 parameters-
Proof generation time per signature ~ 9.6 seconds (average)
per batch/ Number of signatures for proof = 100 (maximum)
Time to generate zk-proof for batch = 16 minutes (based on 100 signature batches)
p>
Proof generation time is (almost) linear with the number of signatures per batch. We can increase/decrease the number of signatures per batch and the proof generation time will change accordingly.
Prove that production time will appear as a delay. To reduce this, we can put a smaller number of signatures in a zk proof. However, this means that the same batch size (or per light client header) will require more proofs, which will increase the gas cost of validating the batch.
Therefore, reducing latency increases gas cost.
Below we list the expected cost of validating a Tendermint Light Client (LC) header on Ethereum in terms of latency and the number of validators participating in that universe chain .
We can let users/cosmos chains decide what latency and gas fee options they want to use.
< /p>
Based on the gas price on August 5, 2022
Here we choose 200 validators and 50 signatures as the basis for proof analysis.
Relayer infrastructure cost
Since the Tendermint block generation speed is ~7 seconds, it proves is 8 minutes, we will need multiple validators in parallel to keep up with block production.
Number of parallel machines required = 8 minutes * 60 / 7 seconds = 69 machines
So the cost of this infrastructure = $1.536*69 = $106/hour
Machine Cost per Light Client Header = 106/3600/7 = $0.206
Estimated Total Transaction Cost
Based on assumptions of 8 minute latency and 200 validators.
Total cost of on-chain light client verification = 0.206 = $18.1
Let's Assume a worst case (from transaction fee perspective) where there is only one cross-chain transaction in a block. The full cost of validating the LC header is then borne by the transaction. With some overhead costs, it's about $20 to verify a cross-chain transaction.
Assuming the optimistic case of 10 transactions per block, this cost would be about $2, which is similar to the cost of a Uniswap transaction on Ethereum.
How to reduce gas cost and latency (using recursion)?
In order to reduce the latency to a few seconds and reduce the gas cost per transaction to a few cents, we are working on recursive proofs b>Technology. This will allow us to generate multiple proofs in parallel and then recursively combine them into one proof.
We are evaluating various recursive libraries available in the market, such as plonky2, as well as works from Mina, Aztec and Starknet teams. We invite anyone working on recursion to contact us.
By using recursion and hardware-based acceleration, we believe we can achieve sub-5 second latency for cross-chain transactions.
In the future, we can even combine multiple light client headers in one proof, each proof costing only $4.5, and each cross-chain Transactions can cost less than $1.
System Design Overview
Current IBC Design (Simplified)
New proposed IBC design
Proposal Design Points
1. The interface of IBC remains constant. This makes adoption very easy as no new development documentation and developer re-education is required. Existing codebases will also be used as-is.
2. No governance update required on appchain
3. Ethereum Two changes are required for IBC on :
a.Relayer will now only submit its validity proof instead of the full light client header.
b. The on-chain light client module on the Ethereum side will include a zk-proof validator instead of ed25619 signature verification.
The next step?
We invite the Ethereum and ZK communities to provide their input and help us gather support to make this proposal a reality.
Execution Plan:
Phase 1: Integration of my ZK engine with IBC
Phase 2: Reduce latency to ~5 seconds with recursive proofs and hardware acceleration.
Stage 3: Deploy a demo application chain connected to Ethereum via zk-IBC.
Phase 4: Run the setup of the demo application chain, conduct extensive testing, and enable the community to test transactions.
Phase 5: Security Audit
Phase 6: Mainnet Deployment
Original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
