Testnet
ZK-IBC 2.0 is live on testnet and you can check out the explorer here - https://testnet.zkibc.com/. To kick things off, we are aggregating Celestia, Osmosis, DyDx, and Injective right now. We will continue to add more Cosmos chains going forward, eventually aggregating all of Cosmos.
Merklization
In ZK-IBC 1.0, we proved a single light header inside the circuit. This enabled us to reduce the information to be posted on-chain to a single hash string + the zk-proof itself.
With ZK-IBC 2.0, we are going one step beyond, rather than posting one hash string for each block of a chain, we create a merkle tree out of the individual hash strings from each chain, creating one superhash for all cosmos chains.
The merkle tree structure that we follow is below -
Hence, if you look at the on-chain data for the smart contract at any time you will see it storing a superhash string on-chain. In order to check the underlying data under any superhash, one can simply pull the blockheader info from RPC's and check the merkle path.
A new incoming superproof simply updates the current superhash to a new one, thereby updating the on-chain light client state for each chain. Our on-chain light client proceeds from one superhash to the next as below -
As an example, let's look at Superproof #122 and the Ethereum transaction that verified it. If you look at the state change brought abt by this transaction, we can see the "Before" and "After" strings which correspond to the previous and the new superhash.
Testnet Genesis State
When instantiating our on-chain light clients, it would be overkill to start from the genesis of each chain. Instead, we start from a recent blockheight. We have used the following blockheights as the genesis point of our on-chain ZK light clients.
| Chain Name | Genesis BlockHeight of the on-chain ZK Light Client |
|---|---|
Celestia | 901623 |
Osmosis | 14076604 |
DyDx | 9805955 |
Injective | 62075732 |
We consider Superproof #26 as the first proof for our network. Hence the genesis blockheights from the above table should be the starting state for superproof#26, which is indeed the case if you see the previous state column at https://testnet.zkibc.com/?superproof_no=26
As discussed in previous section, we do not store these heights or the blockhashes directly on-chain, but rather their merkle root. Our on-chain light clients builds on top of the genesis state as new superproofs roll in.
Frequency of Proof generation and submition to Ethereum
Right now, we are generating and submitting proofs to Ethereum at a frequency of 1 proof per ~60mins. Since our network is under prototypical stage, we have chosen to keep the frequency low. We target 2 mins per proofs (or lower) over time.
The skipping light client mechanism of the tendermint consensus allows light clients to skips many blockheaders without losing sync and maintaining the full security properties of the light consensus. This is valid as long as the two blocks being proven are within the validator un-stake period of each other (~14 days for most chains). Our superproof submission frequency (~1hr) is well within than window.
Inside a Superproof
Let's take a look inside superproof #122 as given here - https://testnet.zkibc.com/?superproof_no=122 Let us try to understand the different fields on this page.
Total Proof Verification Cost: 361788 gas ($113.03) This is the total cost of the superproof transaction, which includes the superproof verification, and superhash state update)
Proof Verification cost per cosmos chain: 90447 gas ($28.26) Given there are 4 chains being aggregated, this means that the Total Proof Verification Cost is divided by 4.
Individual Chain Details -
Previous State: Corresponds to the last height of the on-chain light client of each chain before this superproof was submitted
New State: The updated state post superproof submission
Proof Generation Time: As show in the next section, we have a 4 machines that run in parallel to generate individual proofs for each chain. This is the time taken by each of those machines.
Total Proving Time: This is the end-to-end superproving time. This includes multiple sub-steps which are explained in the next section.
Network Upgrade points
Our network went thru upgrades at the following superproof numbers - <add>
<add Ethereum superproof verification contract address, add the entry point>
Last updated
