SATPORT Docs
  • 1 Introduction and Background
  • 2 Limitations of BTC and BTC-pegged Assets
    • 2.1 Limited Empowerment of BTC Native Assets
    • 2.2 Weaknesses of BTC-pegged Assets
  • 3 Overview of SATPORT
  • 4 SATPORT Technical Architecture
    • 4.1 Hyper-Scalability Solution: zk-HSS
      • 4.1.1 Private Key Sharding
      • 4.1.2 Asset "peg-in" Solution
      • 4.1.3 "Peg-In" Process
      • 4.1.4 Asset "Peg-out" Mechanism
    • 4.2 SATPORT's Dual Security Mechanism
  • 5 satBTC
  • 6 Ecosystem Development Plan
  • 7 Exploring the Integration of ZKP with BTC Use Cases
    • 7.1 Research Direction and Planning
    • 7.2 Applications of Chain State Proofs
  • 8 RaaS Strategy
  • 9 Conclusion
Powered by GitBook
On this page
  1. 4 SATPORT Technical Architecture
  2. 4.1 Hyper-Scalability Solution: zk-HSS

4.1.3 "Peg-In" Process

Previous4.1.2 Asset "peg-in" SolutionNext4.1.4 Asset "Peg-out" Mechanism

Last updated 1 year ago

The process for asset "peg-in" within SATPORT can be divided into four main steps:

  1. 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.

  2. 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.

  3. 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.

  4. 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.