Replies: 1 comment
-
|
Relevant, from Polymer: https://polymerlabs.medium.com/zkmint-the-first-zk-friendly-tendermint-consensus-engine-116000b9d4f9 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
This is a porting of discussion originally initiated by @p4u from the legacy repo: tendermint/tendermint#9735
Originally posted by p4u November 21, 2022
There are currently some approaches to implement zkBridges among different chains. That's a trust-less manner to bring messages from one chain to another, using zkSnark Proofs.
This Berkeley group implemented a zkBridge between Cosmos and Ethereum: https://rdi.berkeley.edu/zkp/zkBridge/zkBridge.html
The main idea is to create a Circuit able to verify the signatures of the validators over a batch of block headers, in order to proof the correctness of the State root hashes.
The validity proof together with the last or multiple state roots can be sent to any blockchain capable of verifying zkSnarks.
Once the state root is verified by the destination chain, any standard merkle-proof of the state tree (not zkSnark required) can be sent onchain in order to proof any data stored as a leaf of the state tree.
This mechanism might also be useful for light clients.
In order to facilitate this process, the Tendermint validators should be able to use a Snark friendly elliptic curve, such as bn254 (also available as precompiled within Ethreum).
The block header might also be modified in order to include a Snark friendly merkle root of a merkle tree containing the list of validators for the next block.
The circuit can be written using Gnark (a GoLang framework by Consensys), which supports bn254, Groth16 and Plonk.
The approach seems quite feasible to implement in short time since it does not require big changes on the tendermint protocol and the circuit is not very complex.
We at Vocdoni want to have this feature so we might push its implementation. But collaboration from Tendermint core would be very appreciated. Specially if you find it interesting and want to make it available for any Tendermint based blockchain.
I think this should be possible without breaking backwards compatibility. Thoughts?
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions