4.1.3 "Peg-In" Process
The process for asset "peg-in" within SATPORT can be divided into four main steps:
Initial Setup: SATPORT's on-chain lightweight client obtains the source chain's continuous consensus state for verifying Bitcoin's ZK proofs. This process includes retrieving the current consensus state of Bitcoin, such as block height and block header hash. This initial setup is a one-time operation and updates automatically with cross-chain operations.
Proof Generation: After Bitcoin generates a new block, SATPORT's chain needs to synchronize relevant information, including the previous block's state, block producer selection, and legitimacy of signature nodes. For consensus mechanisms with non-instant finality, a redundant block count is set to prevent fork issue. The Prover employs ZK proof technology to compute ZK proofs offline, which are then synchronized to the SATPORT chain.
Proof Verification: SATPORT's on-chain lightweight client verifies the ZK proofs submitted by the Relayer. Upon successful verification, the client returns verification results and updates the consensus state information of Bitcoin within the SATPORT chain.
Interoperable Contract Invocation: Following the verification of Bitcoin's consensus by SATPORT's chain lightweight client, participants can initiate cross-chain contract interactions, facilitating cross-chain exchanges.
For instance, in an asset "peg-in" scenario, participants submit Bitcoin chain transactions (TXS) along with corresponding Merkle tree proof paths. Leveraging the existing Bitcoin consensus information available to the SATPORT chain's lightweight client, contracts can easily verify the authenticity of transactions.
Last updated