Grail Bridge - Proofs Used

Two types of proofs are used in the Grail bridge to support its operations:

1. Proof of transaction inclusion on the Bitcoin network

2. Proof of state transition of the bridge smart contract on the L2 side

For both types, a zkSNARK Groth16 proof is generated and verified. Proof recursion is expected to be supported, allowing proofs from other systems, such as Plonky2 and STARKs. In other words, a zkSNARK proof can be used to verify another proof.

Proof of transaction inclusion on the Bitcoin network

Given a transaction hash, a proof that the transaction has been mined on the Bitcoin network is generated by combining the following conditions:

• Proof that the transaction was included in a particular block

• Proof that a predefined number of blocks were confirmed afterward

• Proof that a known accepted block is present in the chain

Proof that a variable on the bridge smart contract reached a particular state

Proofs of the bridge smart contract state are used in two cases:

• To confirm that a UTXO has been assigned to an operator for withdrawal

• To confirm that a stake has been released after an operator has resigned

Depending on the design and security assumptions of the rollup, the proofs can be constructed as follows:

• Proof of transaction inclusion on the Bitcoin network — provided that the rollup is committing transaction information to the Bitcoin network as a data availability layer and that the rollup has a dispute mechanism to reject invalid state transitions (i.e., proving that the rollup has posted a transaction on the Bitcoin network).

• Proof of storage state on the rollup’s smart contract — alternatively, it can be shown that a target variable with its value has been included in the smart contract storage when calculating the rollup’s block hash. This would allow significant scalability in terms of reducing verification burden via BitSNARK.