7.1 Research Direction and Planning

The attainment of chain state proofs is a complex undertaking, which SATPORT's official team has divided into four successive stages for gradual implementation. Up to the present moment, the team has completed prototypes for the initial two stages.

6.1.1 Block Header Proof

Similar to Simplified Payment Verification (SPV) for light clients, block header state proof solely verifies block headers, proof of work, and difficulty adjustments. Additionally, it enhances the block header chain by constructing a Merkle tree over all block headers, streamlining inclusion proofs for all blocks and transactions. This state proof is relatively simple, lightweight, and incurs low computational costs.

Specifically, upon receiving a block header, the target chain's light client performs the following checks according to Bitcoin's consensus rules:

1. The block hash must be lower than the current target value—a numerical representation of a hash with a certain number of leading zeros, closely related to block difficulty.

2. The encoded previous block hash of the current block is indeed the hash of the preceding block.

3. The block's timestamp must not be earlier than the median timestamp of the previous 11 blocks, nor exceed the network time plus two hours.

4. The correct target is encoded in the block. If a retarget occurs, the new target must be correctly deduced from the timestamp epoch.

To generate proofs for multiple consecutive block headers, their validation can be batched together in a single process, utilizing a mechanism known as recursive proofing. Aggregating the recursive proofing process for multiple block headers significantly reduces the costly STARK proof verification burden on validators.

6.1.2 On-Chain Light Node Witnessing Scheme

SATPORT's second-stage implementation of the on-chain light node witnessing scheme adapts to various homogeneous/heterogeneous chains without introducing additional trust assumptions. It involves off-chain generation of zero-knowledge proofs and on-chain verification, significantly reducing on-chain computational and storage costs. This approach features characteristics such as trustlessness, permissionless operation, scalability, and efficiency.

Light nodes (or light clients) are a type of node within a blockchain network that stores less data compared to full nodes. They retain only block headers rather than the entire blockchain history. Using lightweight smart contracts, they verify transactions across different chains, enabling cross-chain operations. When specific transactions need to be verified, light nodes employ block headers and Merkle paths for Simplified Payment Verification (SPV), avoiding the need to download the entire block, thus enhancing verification efficiency. In summary, light nodes achieve effective verification and participation in blockchain transactions with lower resource consumption.

In this witnessing mechanism, Relayers monitor the source chain's blocks off-chain and forward this block information to the target chain. The forwarded information includes not only block headers but also validity proofs (ZKP) generated using the ZK-SNARK algorithm. On the target chain, the role of light nodes differs from traditional verification methods. Instead of directly calculating and verifying transaction validity based on block headers, they employ on-chain validity proofs (ZKP) for verification, effectively reducing computational overhead.

6.1.3 Assumed Valid State Proof

This step emulates Bitcoin Core's "assumevalid" option. It verifies all Bitcoin consensus rules except for transaction signatures. More precisely, all witness data is assumed to be valid. Additionally, this proof employs Utreexo to enhance the commitment of the UTXO set on-chain.

The assumed valid blocks are an optimization technique designed to accelerate the synchronization speed of Bitcoin full nodes. This technique allows nodes to skip signature verification for certain blocks during the synchronization process, conserving significant computational resources and time.

6.1.4 Full State Proof

This proof verifies all Bitcoin consensus rules, including all witness data. Building upon the assumed valid state proof, it verifies all witness data. From a computational standpoint, this is the most resource-intensive proof, requiring substantial optimization of the proving process to make it feasible. This will be the final piece to become production-ready, involving significant optimization efforts for the prover.