Architecture

Summary

Our solution for Horizontal Scaling Bitcoin through an extension (layer 2) network incorporates an infrastructure to spin off tailor-made subnets for specific cases on top of it. It builds on the architectural principles of IPC but adapts them to Bitcoin's unique characteristics. By integrating Fendermint, ABCI++, and a modular VM layer, this architecture achieves scalability, security, and developer flexibility while leveraging Bitcoin's trust model through the settlement process.


Validator Nodes

Subnet operators are required to run a full validator node for both the parent and child subnets. This ensures that the subnet's checkpointed states are securely stored and synchronized with the parent network at the right time. Requiring parent node participation enhances security by maintaining a clear and trusted link between the child and parent subnets.

Components of a Validator Node

  1. Tendermint (Fendermint?)

    • Tendermint Core is a byzantine fault tolerant (BFT) consensus engine for blockchains. It acts as a generic state machine replication (SMR) in a subnet, talking to other Tendermint instances and ensuring a consistent ledger is maintained across validator nodes. It talks to the Application in the node via ABCI++.

  2. ABCI++

    • The ABCI++ interface is implemented to handle the IPC ledger logic and transaction handling. The ABCI can pass checkpointed headers to the parent and use the ledger to gather relevant signatures. In our case on the Bitcoin network, it can be seen to deliver the following:

      • ABCI++ facilitates checkpointed state headers to be passed to the parent Bitcoin network.

      • It uses the ledger to aggregate validator signatures and manage inter-subnet communication.

    • It also interacts with Bitcoin transactions and manages UTXO-based logic, replacing the reliance on Ethereum-style smart contracts.

  3. Bitcoin Subnet Manager

    • The Subnet Manager oversees the creation, operation, and termination of subnets. It supports Bitcoin-native functionalities such as collateral management, validator onboarding, and checkpointing.


Smart Contract Layer (Transaction Execution)

While Bitcoin does not natively support smart contracts in the same way as Filecoin or Ethereum, our architecture emulates similar functionalities for transaction execution and logic.

  1. Custom Virtual Machine

    • Instead of the Filecoin Virtual Machine (FVM) or Ethereum Virtual Machine (EVM), a lightweight VM layer handles transaction throughput and application logic on the subnet.

    • This layer enables developers to deploy scalable applications, even if their throughput requirements exceed Bitcoin's mainnet capabilities.


Cross-Subnet Communication:

When it comes to cross-subnet communication, we have three main principles that explain all of the possible ways of facilitating communication between subnets:

  • Bottom-up communication - ensures fault tolerance and secure state propagation up to Bitcoin.

  • Top-down communication - maintains a unified network state, promoting consensus and consistency through a top-down message passed from Bitcoin to all the participants.

  • Horizontal cross-subnet communication - enables interoperability and complex interactions, expanding the network’s use cases.

To explain the cross-subnet communication logic, we will first explain the concept of checkpointing:

  • Checkpointing is a critical component for ensuring recoverability and synchronization across the network. By storing checkpointed states of their child subnets, parent subnets provide fault tolerance, guaranteeing that a child subnet’s state can be recovered in the event of a failure. This process also facilitates state validation, as validated states are propagated upward through the hierarchy to Bitcoin, creating a secure and reliable record of the network’s state. In the event of a fault, checkpointing enables rollbacks, allowing a child subnet to retrieve its last valid state from the parent subnet and adopt it as the new state. This minimizes disruption and ensures the stability and reliability of the network.

Additionally, we will explain the concept of root network and Fendermint consensus:

  • The root network is the foundational layer in a hierarchical blockchain system. It is the ultimate source of truth and security for all interconnected subnets. Bitcoin operates as the root network in our solution, providing a secure and decentralized foundation for the entire ecosystem.

    • As the root network, Bitcoin aggregates validated and checkpointed states from child subnets, holding a comprehensive and unified view of the network hierarchy that all subnets can reference.

    • Bitcoin’s consensus mechanism ensures that checkpointed states stored on the root network are immutable and universally accepted, becoming the definitive and trusted version of the network state once finalized.

    • By broadcasting finalized states back to subnets, Bitcoin enforces a unified consensus, ensuring consistency and synchronization across the entire network. It enables fault recovery by storing checkpointed states, allowing child subnets to retrieve their last valid state in the event of a disruption.

  • Fendermint consensus is the backbone of cross-subnet communication and interoperability within our Bitcoin scaling solution. This lightweight implementation of the Byzantine Fault Tolerant (BFT) consensus mechanism ensures fast and reliable transaction finality within subnets, enabling secure state validation and synchronization across the network. By standardizing how subnets reach consensus, Fendermint provides a unified framework for communication between subnets with diverse workloads and performance needs. It facilitates seamless interoperability by ensuring each subnet can validate and propagate states to its parent and interact with other subnets through consistent and secure message passing.

In general, Fendermint is tasked to facilitate interoperability between subnets, acting as the intermediary for state, data, and asset exchanges, eliminating the need for direct and potentially insecure bridges.

Checkpointing

  • IPC on BTC utilizes a checkpointing method to better serve the demands of today's blockchain ecosystem. This approach aids in tolerating failures that might otherwise require a lengthy application to restart from scratch. Simply put, checkpointing ensures that the child subnet's state remains recoverable and synchronized with the parent, providing a security layer against data loss or mismanagement.

Bottom-up communication

  • Bottom-up communication entails validating states by child subnets on a local basis, followed by submitting checkpointed states to their parent subnet for storage and verification. Within the child subnet, validators achieve consensus regarding the state at regular intervals, thereby creating a checkpoint that accurately reflects the current state of the subnet. This checkpoint is subsequently submitted to the parent subnet, where it is incorporated into the parent’s state. The checkpointed state attains validity only upon the parent subnet reaching its finality; for subnets that directly interact with Bitcoin, finality is attained upon Bitcoin confirming the checkpoint. This hierarchical scaling process progresses upward, with each subnet submitting its validated states to its parent, ultimately resulting in the root parent (Bitcoin) possessing the complete and finalized state of the entire hierarchy. This methodology ensures fault tolerance, as checkpoints stored within the parent network enable child subnets to recover or roll back their state in the event of failure. Furthermore, only finalized states are propagated, ensuring the network's integrity and reliability.

Top-down communication

  • Top-down communication involves the root parent, Bitcoin, broadcasting a unified and valid state of the entire network hierarchy to all subnets. Once Bitcoin finalizes the states of all child subnets through checkpointing, it holds a complete and comprehensive view of the network. This unified state is then disseminated to all subnets via message passing, ensuring that every subnet receives the updated network state. Each subnet subsequently updates its internal view to align with this unified state, achieving a shared consensus across the entire network. This process ensures a consistent and synchronized network view, reducing discrepancies and maintaining operational order. By serving as the root parent, Bitcoin guarantees that the network state is secure, universally agreed upon, and trusted by all participants.

Horizontal cross-subnet communication

  • Horizontal (on the same hierarchy level) cross-subnet communication enables direct interaction between subnets, facilitating operations such as fund transfers, state sharing, and transaction execution. Several primitives support this communication.

  • For fund transfers, users can move assets between accounts in different subnets by burning tokens in the source subnet, transferring the equivalent BTC to the destination subnet, and minting wrapped tokens in the target subnet. State sharing allows subnets to access checkpointed states stored in the parent network to validate cross-subnet operations, ensuring consistency and accuracy. Additionally, subnets can execute transactions based on inputs or events from other subnets, enabling seamless interoperability and complex workflows.

  • Relayers play a crucial role in cross-subnet communication by passing messages between subnets and ensuring compatibility between differing consensus mechanisms and block structures. They validate cross-subnet transactions and maintain data integrity throughout the communication process. This approach provides seamless interoperability, enabling smooth asset and data transfers without requiring custom bridges. Moreover, it offers flexibility, supporting diverse use cases such as token transfers and sophisticated cross-subnet application logic.

Last updated