Bridge DA to Ethereum (with Succinct SP1)
Last updated
Last updated
Note: Thanks to your contributions, cycle I of our TestNet Phase 3 journey has officially wrapped up! Now we're one step closer to onboarding the world to Bitcoin. Stay tuned for the next steps!
In a nutshell, for each newly generated Nubit DA block, we have its correctness proved by zero-knowledge (ZK).
Succinct provides the light service that proves each newly generated Nubit block and submits the proof to a contract. Hence, each block generation is proved and the proof is publicly verifiable. This further enhances our Nubit DA chain, providing a more trustless and secure DA with strong data integrity and unforgeability.
The underlying technique is the SP1 zero-knowledge virtual machine (zkVM), developed by the Succinct team.
Different from application-specific zero-knowledge circuits, SP1 provides general-purpose zero-knowledge. Namely, for any application logic that can be programmed via canonical programming languages (like C, Rust, etc.), its compiled bytecodes could be taken as inputs to SP1, and has its ZK circuit generated instantly and autonomously. Powered by this primitive, customizability, flexibility, and convenience are brought about to the web3 ZK ecosystem with strong security and trustlessness. In short, compared with composing ZK circuits manually, proving block transitions by SP1 is merited for the following benefits.
(1) Easier circuits.
SP1 enables easier ZK circuit composing. Manually writing the ZK circuit is costly and incurs an excessive workload even for professionals. By leveraging SP1, logic to be verified can be programmed in traditional programming languages without involving any domain-specific language (DSL) or ZK-specific library.
(2) Easier updating and testing.
Despite the difficulty, we could have composed the ZK circuit manually, however, it is hard to update or test the logic even if the underlying verification logic is slightly changed. The hardness originates from the nature of existing ZK DSLs. However, by SP1, we could easily update the logic by revising a traditional code block. Also, we are allowed to compile the same code block into executable files (simultaneously into ZK circuits) and test the revised logic with classical code testing techniques.
(3) Strong security.
Merited from the soundness property of the underlying ZK proofs, nobody could forge a valid proof for a “wrong” block. This means that, as long as valid proof is obtained and verified, the block could be viewed as correct. This further guarantees the trustlessness and security of our Nubit DA network.
Based on this technique, the ZK circuit generated from SP1 verifies the following logic for each block transition. To facilitate descriptions, for each block transition, we refer to the earlier block as the pre-block and the latter as the post-block.
(1) Validator set.
Validators are the nodes operating the consensus scheme, which is the kernel of secure chain growth and liveness for any blockchain. A correct validator set of the post-block should be delivered to the proof machine as a witness. This validator set could only differ from the pre-block one slightly according to the set switchover rule.
(2) Block consistency.
The block transition should be semantically correct. For instance, the block height of the post-block should be greater than the pre-block by one. Also, the pre-block, which is inputted to the proof machine, should be verified as a valid historical block to guarantee unforgeability.
(3) Commitment verification.
Finally and most importantly, the commitments, signatures, and other auxiliary block information should be verified against the aforementioned validator public key set. This allows for block verifications and further provides non-repudiation in case of validator misbehavior (extremely unlikely to happen though).
Seemingly, this is a large ZK circuit to prove. However, the proof is extremely friendly to lightweight clients! Technically, SP1 proves by STARK and has the STARK proof wrapped by SNARKs with a shorter proof size. Hence, our ZK not only enjoys the efficiency of STARK proof generation but also has an extremely short proof size and fast proof verification. As a result, proof generation is efficient and the verification only involves constant computation on a proof with a short and constant size.
The block transition proofs, delivered to layer-1 smart contracts in the settlement phase, can be efficiently verified by lightweight users via triggering a verification smart contract and can be aggregated by recursive proofs. The proofs provide trustless and safe block headers for all users, even lightweight clients. Along with the data inclusion proofs, whose verification takes block headers as public inputs, the Nubit DA layer offers completely trustless and secure data retrieval for any node. This means that, with our proofs for each block transition, layer-2 application users are allowed to safely obtain Nubit DA block data without trusting any third-party data provider.
Thereby, layer-2 project teams no longer have to maintain their data. They only need to send data to Nubit DA and users can obtain the data safely and verify the data by layer-1 smart contracts without assuming the honesty of any node.
Deploy and Verify Contract
Export Contract Address
Logs should be displayed, indicating that proofs are being generated for newly assembled blocks.
