4.1.2 Asset "peg-in" Solution

Trust-Minimized Asset "peg-in" Solution Using Zero-Knowledge Proofs

1) Efficient Source Chain Transaction Verification with ZK Technology

SATPORT currently employs ZK technology to implement block header state proofs. This approach enables the prover to highly compress critical transaction data, block header information, difficulty coefficients, and other essential details from the Bitcoin chain into verifiable Zero-Knowledge Proofs (STARKs). ZKP verification simplifies the state validation process, making it lightweight and reducing computational costs.

Within the SATPORT chain, smart contracts are introduced to construct on-chain light clients. By validating these STARKs proofs, users can efficiently and conveniently verify transaction data from the Bitcoin chain on the SATPORT chain without relying on third-party intermediaries. SATPORT's objective is to extend the application of ZK technology to a wider range of use cases, replacing traditional peer-to-peer validation with verifiable proofs of the latest chain state. This approach aims to bring the validation process closer to the security level of full nodes.

Validation through SATPORT's on-chain light clients differs from LayerZero's proposed super-light nodes. LayerZero's super-light nodes only verify whether the data relayed by the relayers matches the data provided by the oracle, without directly verifying on-chain transactions. Consequently, LayerZero's super-light nodes possess privileged roles and inherently rely on trust that the relayers and oracles will not collude maliciously, failing to achieve full decentralization. In contrast, SATPORT's on-chain light clients determine the validity of Bitcoin source chain transactions by verifying the ZKP proofs provided by the relayers.

Operating Principle of Light Clients

Within the Bitcoin network, each block possesses a block header containing a pointer to the previous block and the Merkle root hash of all transactions within the current block. The pointer to the previous block ensures the integrity of transaction data in the preceding block. Meanwhile, the Merkle tree within each block's header encompasses all transactions in the current block. The root hash value of this Merkle tree allows for the verification of all transactions within the block.

In the given diagram, performing hash operations on transactions L1, L2, L3, and L4 results in Hsh0-0 = hash(L1), Hash0-1 = hash(L2), Hash1-0 = hash(L3), and Hash1-1 = hash(L4).

For the light client to obtain the root hash (Top Hash), it only needs to perform the following calculations:

Hash0 = hash(Hsh0-0, Hash0-1)

Hash1 = hash(Hash1-0, Hash1-1)

Top Hash = hash(Hash0, Hash1)

Hash operations are one-way, meaning you can calculate Y = Hash(X), but you cannot calculate X from Y. Therefore, the light client only needs to synchronize the root hash values within the block and request the path hash data from full nodes to verify the authenticity of transactions.

To verify the transaction L1, the light client with the root hash value and Hash1 can follow these steps:

1. Calculate Hash0-0.

2. Using the synchronized Hash0-1 and the calculated Hash0-0, compute Hash0 = hash(Hash0-0, Hash0-1).

3. Calculate the root hash RootH = hash(Hash0, Hash1) based on the received Hash1 and calculated Hash0, and compare it with the light client's synchronized Top Hash. If they match, it confirms that the L1 transaction is indeed on the chain and unchanged.

The entire blockchain achieves trustworthiness for light clients through this method.

ZKP Optimization for Traditional Light Clients

Light client verification involves substantial computational processes from consensus, and performing all these calculations on-chain would result in high gas costs, limiting scalability. SATPORT introduces zero-knowledge proof technology to offload these consensus-related computations to a trusted off-chain environment, generating succinct ZKP. SATPORT's on-chain light clients require only a minimal amount of gas to verify the authenticity of source chain transactions.

2) Trustless Implementation of "Peg-In" Mechanism with ZKP Technology

When conducting cross-chain operations, trust in the consensus mechanisms of both the source and target chains is fundamental to ensuring the smooth execution of cross-chain operations. However, excessive reliance on a single entity or organization's trust can compromise the security of assets. Therefore, to achieve higher levels of security and credibility, the ideal goal of cross-chain operations is decentralization, ultimately leading to trustless operations.

One effective approach to achieving trustless cross-chain operations is to establish the underlying trust mechanism for cross-chain interoperability protocols using ZKP technology. SATPORT achieves this trustless operation in the asset "peg-in" process through such a design. The SATPORT "peg-in" mechanism involves three core participant roles: Prover, Relayer, and Verifier.

Prover:

The Prover is responsible for monitoring the state of the source chain and generating zero-knowledge proofs using source chain data. ZKPs can prove the authenticity of specific transaction activities without revealing actual data.

Relayer:

The role of the Relayer is to transmit the generated zero-knowledge proofs to the target chain. They act as messengers in cross-chain operations, ensuring secure and accurate transmission of cross-chain data.

Furthermore, Relayers are trustless and have no special privileges; they are only responsible for relaying the ZKPs from the source chain to the target chain.

Verifier:

Verifiers receive the ZKPs from Relayers and verify them on the target chain. By validating the validity of the ZKPs, they confirm the authenticity of cross-chain transactions initiated from the source chain.

In this mechanism, Relayers have no privileged role, and whether to adopt ZKPs is entirely determined by SATPORT's on-chain light clients. As long as a single honest Relayer submits a correct proof, the effectiveness of the "peg-in" process can be verified.