Hybrid Consensus Mechanism
Last updated
Last updated
exSat employs a hybrid consensus mechanism to decentralizely import Bitcoin blocks. By combining PoW and PoS, exSat ensures that the imported Bitcoin blocks are both decentralized and trustworthy.
The process of importing Bitcoin block data into exSat involves the following steps:
Uploading Bitcoin Blocks Synchronizer retrieves the latest Bitcoin block, splits it into slices (default: 256 kB), and uploads the data to the exSat contract. The uploaded data includes:
Block height
Block body
SegWit data
Verifying Block Data Synchronizer ensures that the uploaded data is consistent with the block hash. Verification includes:
Verifying the block header:
Ensuring the previous block hash matches the hash in the block header.
Confirming the correctness of mining data, including nonce and difficulty , which is calculated according to Bitcoin network rules.
Verifying transaction data: Reconstructing the Merkle tree for transactions and ensuring the merkle root matches the transaction tree root in the block header.
Verifying witness data: Reconstructing the Merkle tree for witness data and verifying it matches the witness merkle root stored in the Coinbase transaction.
Reach consensus on Block data
Each BTC Validator and XSAT Validator independently retrieves the latest Bitcoin block header and submits the block hash they consider valid to the exSat network. BTC Validators and XSAT Validators establish consensus independently. This means that:
If at least two-thirds of all BTC Validators submit the same block hash, referred to as Hash_BTC, the BTC Validators reach consensus and determine that the current Bitcoin block hash is Hash_BTC.
Similarly, if at least two-thirds of all XSAT Validators submit the same block hash, referred to as Hash_XSAT, the XSAT Validators reach consensus and determine that the current Bitcoin block hash is Hash_XSAT.
If Hash_BTC equals Hash_XSAT, it is considered that all Validators have reached unified consensus, confirming the current Bitcoin block hash as the agreed-upon value.
If the Bitcoin block hash agreed upon by all Validators matches the block hash submitted and verified by the Synchronizer, it is considered that the entire exSat network has reached consensus on the current Bitcoin block data. This data can then be used to parse and update the UTXO index.
Due to the possibility of forks and reorganizations in Bitcoin, a block is only considered finalized after consensus has been reached and the block has received at least six confirmations on the Bitcoin network.
Parsing Transactions and Updating UTXO Data Synchronizer processes Bitcoin blocks that have reached consensus by sequentially parsing each transaction. It removes spent input UTXOs and adds newly created output UTXOs to the UTXO database.
UTXO data is maintained in two separate databases:
Irreversible UTXO database: Contains UTXOs from blocks that have become irreversible.
Pending confirmation UTXO database: Holds UTXOs from blocks that are not yet irreversible.
As new blocks reach consensus, earlier blocks transition to an irreversible state, and their UTXO changes are migrated to the irreversible UTXO database.
DApps can select to use either the irreversible UTXO data or the pending confirmation UTXO data based on their risk tolerance and user experience needs.
Synchronizers: These are well-established Bitcoin mining pools with an extremely low likelihood of malicious behavior.
Consensus not reached: Consensus maynot be reached if the Bitcoin chain forks or if the number of nodes not participating in voting, or voting inconsistently, exceeds one-third. In such cases, Validators cannot internally achieve consensus.
Discrepancy Between BTC and XSAT Validator Consensus: A mismatch between the consensus results of BTC Validators and XSAT Validators may occur during a Bitcoin chain fork or in cases of coordinated malicious activity. This leads to inconsistencies between the two groups' agreed-upon Bitcoin block hashes.
Unstable Validator Nodes Unstable Validator nodes, such as those frequently offline, may fail to participate in voting. If the number of non-participating nodes becomes significant, it can prevent that type of Validator (e.g., XSAT Validators) from reaching consensus. If a node fails to submit votes for M consecutive blocks, it will be temporarily excluded from the consensus process (its votes will be allowed but not counted toward consensus) until it has consistently participated in voting for M consecutive blocks (where M is configurable through community governance). This mechanism ensures that only stable nodes contribute to consensus, while allowing excluded nodes to rejoin once their reliability is restored.
Malicious Validator Nodes Malicious Validator nodes may abstain from voting or cast votes with incorrect block hashes. This could result in failed consensus within their Validator group (e.g., XSAT Validators) or produce a consensus result inconsistent with the other Validator group.
In such cases, the exSat network must wait for consensus to be reached before proceeding. However, if more than two-thirds of any kind of Validator nodes behave maliciously, they can continuously disrupt the process, halting consensus progression.
The key to resolving this issue lies in determining the set of Validators eligible to vote for the current block. Under normal circumstances, the eligible Validator set for a block is recorded at the start of its voting process and remains unchanged throughout.
When malicious activity prevents consensus, it becomes necessary to adjust the eligible Validator set to ensure that honest nodes form the majority. This adjustment is initiated by the Synchronizers. If Synchronizers detect a failure in consensus, they can propose a re-vote for a specific block height, allowing new Validator nodes to join and participate in the voting.
Why Must BTC Validators and XSAT Validators Reach Independent Consensus, and Why Is Agreement Between Both Required for Network Consensus?
By requiring BTC Validators and XSAT Validators to independently reach consensus and validating only when both groups align, the exSat network achieves a fair and decentralized approach to determining the hash of a Bitcoin block. This dual-consensus mechanism balances the influence of a small number of institutional participants with that of the broader community, making it significantly harder for consensus to be manipulated or for collusion to lead to incorrect results. This ensures the security and reliability of exSat’s consensus, providing a robust and trustworthy foundation of Bitcoin data to support the growth of the Bitcoin ecosystem.
Under What Circumstances Could exSat Reach an Incorrect Consensus?
Consider the following conditions:
At least one Synchronizer (Bitcoin mining pool) engages in malicious behavior by uploading incorrect Bitcoin block data for the block it mined on the Bitcoin network (If a block is mined by a pool not participating in exSat, that synchronizer could also engage in malicious activity.).
At least two-thirds of BTC Validators collaborate in malicious activity and reach consensus on the incorrect block hash.
At least two-thirds of XSAT Validators participate in the malicious activity and reach consensus on the incorrect block hash.
All three conditions must be met for exSat to produce erroneous data for a Bitcoin block. This would require the collaboration of mining pools, the majority of institutional BTC staking nodes, and the majority of community-based XSAT staking nodes, making this scenario extremely unlikely. Therefore, the likelihood of exSat generating incorrect Bitcoin block data is nearly zero.
PoW: Bitcoin mining pools that have mined at least one block in the lastest 432 blocks (approximately 3 days) can act as , uploading Bitcoin blocks to exSat.
PoS: Users who stake at least 100 $BTC or 2100 $XSAT can become and participate in voting on the hash of new blocks.
BTC Validators: The threshold for becoming a BTC Validator is significantly higher, limiting participation primarily to institutions or large BTC holders. The substantial cost of BTC staking greatly reduces the likelihood of malicious actors gaining control of more than two-thirds of the nodes. Additionally, these participants typically have professional engineering teams managing their , ensuring more stable and reliable client operations.
XSAT Validators: The requirements for becoming an XSAT Validator are relatively lower, resulting in a larger pool of XSAT Validators, which may include more community participants. Since XSAT Validators are more likely to consist of individual users, the stability and continuity of their may not always be guaranteed. Additionally, the lower entry threshold increases the risk of attackers potentially gaining control of a portion of the XSAT Validators.
A is triggered when more than half of the Synchronizers request it for the given block height. During this process, the foundation and community can rally honest participants to run nodes and join the consensus, enabling the network to achieve the correct consensus and resume operations.
