Why Sealer Network?

1. Why Now? A new era of Bitcoin Ecology is coming

Bitcoin Taproot has redefined the way assets are issued, and various assets represented by Bitcoin ecological protocols such as Ordinals, Atomics, and Rune have swept the market. The Bitcoin ecosystem is ushering in a big explosion.

Problems with the current Bitcoin ecosystem:

1. Data is indexed off-chain by centralized operators, raising concerns about decentralization.
2. Interacting with the system is tedious without third-party tooling, potentially complicating tasks like checking balances, transferring, and exchanging

2. Why Sealer Network?

Sealer Network nodes support both EVM and WASM virtual machines. The WASM is mainly utilized for maintaining and upgrading inscription verification contracts, while the EVM primarily ensures compatibility with the DAPP ecosystem, thereby reducing development costs for developers.These nodes are developed based on the Cosmos SDK, employing a POS+Tendermint Validator mechanism for consensus.

Within the Sealer Network nodes, a built-in Bitcoin light client is integrated. This client is used to verify the authenticity of inscription transactions through Tx and Proof, which are submitted by Relayers.Additionally, the Sealer Network nodes feature an inscription verification engine. This engine is tasked with validating the effectiveness of inscription transactions.

Relayers play a crucial role, akin to that of carriers. They are responsible for transporting various inscription transactions to the Sealer Network using the SITP protocol.Furthermore, Relayers also function as cross-chain bridges. They facilitate the transmission of BRC20 cross-chain transactions through the SITP protocol.

3. Workflow of Sealer Network

Here's a coherent translation of the main process using Ordinals as an example:

1. The node's light client synchronizes the block header state data from the Bitcoin network.

2. Relayers parse the block data, filtering out Ordinals transactions (such as Inscriptions, Deploy, Mint, Transfer, NFTs, etc.).

3. Relayers then package these inscription transactions into the SITP protocol and submit them to the node.

4. The node's Bitcoin light client verifies the authenticity of the Ordinals transactions.

5. The node's verification engine validates the effectiveness of the Ordinals transactions, based on the rules of the Ordinals protocol.

6. The node activates its parallel execution module and stores the state data related to Ordinals.

4. QA

Q1: How is it ensured that relayers submit inscription transactions to the Sealer network in order?

A1: Relayers are off-chain programs used for submitting inscription transactions. To join the network, they must stake a certain amount of platform tokens as a cost. When submitting inscription transactions to the blockchain, they need to carry proof data. If a relayer acts maliciously after on-chain proof is completed, their staked tokens will be penalized, and they will be expelled from the Sealer network.

Q2: How does Sealer handle a Bitcoin block reorganization?

A2: Sealer adheres to Bitcoin's consensus mechanism, which considers six confirmations as final. In the event of a Bitcoin block reorganization, the corresponding verification contract's state data will be altered according to the longest chain principle. Inscription transactions that haven't reached six confirmations are marked and recorded in the dirty cache module for potential rollback, while those that have reached final confirmation are recorded in the persistence module.

Q3: Given the complexity of the inscription protocol, how is the execution efficiency of verification contracts ensured?

A3: Verification contracts are written using precompiled contracts and WASM. Precompiled contracts mainly handle Bitcoin operation codes and verification logic, while WASM contracts deal with inscription protocol-related logic. The state of confirmed inscription transactions is cached for quick retrieval of UTXO sources. Parallel execution is used for different inscriptions and BRC20 transactions.

Q4: In the event of an upgrade or critical flaw in the inscription protocol, how is the safety and availability of Sealer ensured?

A4: Verification contracts support a pause function to halt the verification of new inscription transactions, ensuring data safety. They also support an upgrade feature. During the upgrade, the availability of inscription transaction data is ensured, and after the upgrade, new inscription transactions are accepted.