🤖Hybrid Consensus Protocol

The core of Hibit's innovation is the Hybrid Consensus Protocol (HCP), which seamlessly integrates smart contracts on TON Layer-1 and a proprietary blockchain system on Layer-2. Each HCP Node on Layer-2 functions as a self-contained blockchain system. By transferring the consensus of Layer-2 blockchain systems to TON Layer-1, Hibit achieves transaction processing capabilities exceeding one million transactions per second (TPS). This scalability not only sets Hibit apart from other decentralized exchanges (DEXs) but also empowers TON in the DeFi landscape.

Architecture

Consensus

HCP adopts an innovative hybrid consensus protocol. The separation of consensus and transaction processing responsibilities is achieved by assigning the consensus role to Layer-1 smart contracts and the transaction processing role to Layer-2 nodes. In common blockchains like Bitcoin and Ethereum, nodes are responsible for both transaction processing and consensus. And nodes need to communicate with each other multiple times to complete the entire consensus process. The separation of responsibilities in HCP allows nodes to fully utilize their computational resources for transaction processing. This innovation avoids delays in transaction processing caused by information exchange among nodes during consensus. After independently processing transactions, each node forms an independent block. By submitting block headers to Layer-1 smart contracts and reaching consensus through a simple majority vote, HCP achieves consensus. Therefore, the transaction processing speed of HCP nodes can reach the same level as CEX (1m+ TPS) through the memory level acceleration.In conclusion, Hibit's innovation in HCP significantly increases the speed of node transaction processing without reducing decentralization. This Hybrid Consensus Protocol provides excellent support for large-scale transaction processing in various domains, including financial transactions, social software, games, and other specialized areas.

Block Header

Block Header includes the Blockhash of the previous block, the Merkle root of the transaction list, the Merkle root of state changes, and the Merkle root for the integrity verification tree of shard data, etc.Copy

/// Block header
pub struct BlockHeader {
    /// Block version
    pub version: u8,

    /// Height of the block
    pub height: BlockHeight,

    /// Previous block hash
    pub pre_block_hash: BlockHash,

    /// Mrkle root of transactions
    pub tx_root: MerkleRoot,

    /// Merkle root of state changed
    pub state_changed_root: MerkleRoot,

    /// Merkle root of data integrity
    pub data_integrity_root: MerkleRoot,
}

Block Body

Copy

pub struct BlockBody {
    pub txs: Vec<EncodedTransaction>
}

Asset Custody

HCP, as a complete blockchain system, hosts its assets entirely in a decentralized manner on chain (Layer-1) within smart contracts securely and transparently. Based on TSS (Threshold Signature Scheme), the smart contracts in HCP Layer 1 hold keys in ECDSA/EDDSA formats. These keys are generated based on the node's root key shard and derivation path. The node's key is generated through DKG (Distributed Key Generation) involving multiple nodes. As a result, no single node or individual possesses the complete key. Only after signing by multiple nodes and collecting a sufficient number of signatures by validating nodes can the signatures be combined into a valid signature. Based on TSS, this approach enables contracts to achieve secure and reliable decentralized asset custody.