Today we’re discussing a new concept and extension proposal for Bitcoin called Fractal Bitcoin. It has been jointly launched by well-known organizations including the Unisat team, BSF, Uniworlds, and Asset Bridge. Currently in the testnet phase, the mainnet is expected to launch in September. How does it differ from traditional Layer 2 solutions? The key difference is that Fractal Bitcoin expands the network by adding fractal layers to the Bitcoin mainchain. These fractal layers allow the Bitcoin network to process more transactions without modifying the original code, maintaining compatibility and security with the mainchain. In contrast, traditional Layer 2 solutions are independent networks built on top of the Bitcoin mainchain, functioning more like additional channels. While they can also speed up transactions, they are often more complex to use and may require cross-chain operations. Importantly, Fractal Bitcoin does not compete with the Bitcoin mainnet for liquidity.
Fractal Bitcoin is a self-replicating method that uses virtualization to recursively expand the Bitcoin network. Its main goal is to extend the entire Bitcoin system using existing Bitcoin engineering constructs since 2009, without introducing additional blockchain constructs.
Fractal Bitcoin is not a fork; it processes Bitcoin-like transactions across multiple levels. Each layer of Fractal Bitcoin uses Bitcoin’s implementation, highlighting its unique fractal characteristics.
A fractal is a pattern that remains consistent at every scale and repeats over time. Through this fractal structure, the system can achieve unlimited processing capacity by continuously expanding to new levels.
Bitcoin’s value as a single blockchain stems from its wide recognition and solid engineering foundation. Therefore, when expanding Bitcoin from a single blockchain to a multi-layer system, it’s crucial to maintain the native engineering constructs as much as possible.
The first step is to fully virtualize Bitcoin Core. This involves encapsulating the entire Bitcoin Core into a deployable and runnable blockchain software package, called the Bitcoin Core Software Package (BCSP). By doing so, one or more BCSP instances can be run independently on the Bitcoin mainnet and recursively anchored.
In the evolution of operating systems, virtualization has become a trend. Running multiple guest operating systems on a main operating system provides isolation, flexibility, recoverability, and reusability. Modern virtualization achieves efficient hardware performance sharing through containerization, allowing multiple instances to run with minimal overhead on the main system.
By using Bitcoin Core as a stable main chain, blockchain virtualization can be achieved by customizing different parameter sets for multiple client chains.
Compared to typical Ethereum Layer 2 solutions, this form of virtualization has both similarities and differences. The similarity lies in achieving computational scalability beyond the main chain through an additional abstraction layer. However, the difference is that Layer 2 solutions are usually independent of the main chain, while Bitcoin virtualization essentially maintains consistency with the main chain without establishing a new consensus mechanism.
Over the past 15 years, the development of Bitcoin Core has demonstrated stability and continuity, building credibility over time. This credibility is similar to the trust gained in the operating system virtualization process. Trust in Bitcoin Core also effectively extends to its BCSP instances.
Unlike historical Bitcoin forks, BCSP implementation is based on reusing existing code rather than divergence. Over the years, the Bitcoin network has grown from a single node to thousands of nodes, making it more robust. Similarly, as the number of Bitcoin virtualization instances increases, consensus will become even more solid.
By instantiating BCSP multiple times on a single blockchain, multiple virtualized instances can coexist, communicate, and coordinate. Furthermore, the virtualization process can be recursively applied to any instance, enabling infinite scalability both horizontally and vertically. This approach maintains structural balance and engineering simplicity throughout the process.
Due to consistency with Bitcoin Core, existing infrastructure (such as wallets) can be easily extended to support these new virtualized instances. This is similar to how Ethereum infrastructure can easily support networks like Polygon and BSC.
Another benefit of recursive use of BCSP is that when there’s a high demand for on-chain interactions, these demands can be selectively delegated to deeper levels. This dynamic balancing capability of the system helps avoid overcrowding at specific levels.
Similar to Bitcoin’s early days during the Satoshi era, newly created virtualization instances will experience a period of vulnerability in their initial stages. Therefore, providing some form of direct or indirect protection during the startup phase is crucial. When launching a new instance, operators can choose to set specific block heights for protection until the instance reaches a secure and healthy state. In the future, miners with significant computing power can allocate resources to different BCSP instances, thereby enhancing the overall robustness and resilience of the system.
Additionally, merged mining can be used to some extent, such as merged mining for 1/3 of the blocks for specific instances, to help protect the network against potential 51% attacks.
A distributed network composed of multiple BCSP instances can be established, surpassing the computational efficiency of a single virtualized instance. Through inter-instance communication, effective synchronization can be maintained when necessary.
Distributed BCSP differs significantly from sharding on a single blockchain. Sharding is typically part of the original blockchain, operating under centralized scheduling, and cannot run independently or exist physically separately. However, BCSP offers the flexibility of independent deployment and monitoring.
Compared to on-chain sharding, distributed BCSP demonstrates significant cohesion and integrity. Sharding essentially transforms a single main-line structure into a multi-line collaborative structure, requiring adjustments to the consensus mechanism. In contrast, BCSP’s on-chain consensus is derived from Bitcoin and remains unchanged when organized into a distributed system, thus requiring no reconstruction.
To improve the response speed of block processing, BCSP’s block confirmation time has been reduced to 60 seconds or less, which has proven effective in modern blockchains.
Rapid confirmation increases the available storage space for each instance by tenfold, thereby simplifying application development.
Cross-Layer Bridging: Elevator-Style Cross-Layer Transfer
By creating a universal asset transfer interface, direct and consistent transfers between layers can be achieved. If Bitcoin on the main chain can be conditionally locked and unlocked (particularly suitable for discrete logarithm contracts), the same control mechanism can be used for assets at different levels. This enables seamless asset transfers between any two layers without additional relays. This consistent and direct cross-layer transfer is referred to as an “elevator”.
Asset transfer between Bitcoin and existing blockchains remains an important topic. Various teams are actively researching different methods, which involve trade-offs between decentralization, trustlessness, and efficiency. With conditional locking methods such as Discrete Log Contracts (DLC), there is an open attitude towards other solutions to meet various needs.
When deploying BCSP, there are multiple methods to anchor it to higher levels. One common approach is to use a single transaction on the main chain as a carrier. This transaction stores the Merkle root of aggregated transactions, allowing verification of any specific transaction. In this case, BCSP itself validates transactions according to inherited rules.
Another viable option is to compile this information into a series of inscriptions on its main chain over time. When necessary, the existence and validity of this information can be verified through external inscription indexers. L2O-A is a typical example of a Layer 2 blockchain deployed on Bitcoin that submits new block results and proofs. Considering the modular architecture, it can be reorganized to ensure compatibility with Ordinals and BRC-20.
In the context of operating system virtualization, generating system snapshots enables quick availability. Similarly, the ability to take snapshots of specific instances and selectively load and execute them at designated levels makes it possible to reuse functionality at different levels of detail.
The total token supply is 210 million, with 80% allocated to the community and only 20% to the team and contributors (with a lock-up period) to ensure continued support and stability. Of this, 50% will go to PoW mining, 15% to core contributors, 10% to community rewards, 5% to advisors, 5% to pre-sale, and 15% to ecosystem rewards.
To summarize this project, it’s currently in the testnet phase, with some projects already running on it. The mainnet is set to launch in September. However, participating in the testnet is quite challenging for now, and ordinary users might need to invest considerable time. Mining on the testnet likely won’t be convertible to the mainnet, though there might be some rewards. Given the current timeline, it might be too late to fully engage, so it’s probably best to wait for the mainnet launch to participate in mining. As for how this Fractal Bitcoin actually performs, I don’t see much difference from L2 solutions, except for the use of virtualization concepts. The main challenge lies in data synchronization between multiple chains, which will require time to test. Nevertheless, it represents a new direction and concept, which capital is often eager to follow.
This article is reproduced from [There is a big cake house in the book], the original title is “Bitcoin L2 Expansion New Plan - Fractal Bitcoin Technology Explanation”, the copyright belongs to the original author [Teacher Zhu 123], if you have any objection to the reprint, please contact [Gate Learn Team] (https://www.gate.io/questionnaire/3967, the team will handle it as soon as possible according to relevant procedures.
Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.
Other language versions of the article are translated by the Gate Learn team, not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.
Today we’re discussing a new concept and extension proposal for Bitcoin called Fractal Bitcoin. It has been jointly launched by well-known organizations including the Unisat team, BSF, Uniworlds, and Asset Bridge. Currently in the testnet phase, the mainnet is expected to launch in September. How does it differ from traditional Layer 2 solutions? The key difference is that Fractal Bitcoin expands the network by adding fractal layers to the Bitcoin mainchain. These fractal layers allow the Bitcoin network to process more transactions without modifying the original code, maintaining compatibility and security with the mainchain. In contrast, traditional Layer 2 solutions are independent networks built on top of the Bitcoin mainchain, functioning more like additional channels. While they can also speed up transactions, they are often more complex to use and may require cross-chain operations. Importantly, Fractal Bitcoin does not compete with the Bitcoin mainnet for liquidity.
Fractal Bitcoin is a self-replicating method that uses virtualization to recursively expand the Bitcoin network. Its main goal is to extend the entire Bitcoin system using existing Bitcoin engineering constructs since 2009, without introducing additional blockchain constructs.
Fractal Bitcoin is not a fork; it processes Bitcoin-like transactions across multiple levels. Each layer of Fractal Bitcoin uses Bitcoin’s implementation, highlighting its unique fractal characteristics.
A fractal is a pattern that remains consistent at every scale and repeats over time. Through this fractal structure, the system can achieve unlimited processing capacity by continuously expanding to new levels.
Bitcoin’s value as a single blockchain stems from its wide recognition and solid engineering foundation. Therefore, when expanding Bitcoin from a single blockchain to a multi-layer system, it’s crucial to maintain the native engineering constructs as much as possible.
The first step is to fully virtualize Bitcoin Core. This involves encapsulating the entire Bitcoin Core into a deployable and runnable blockchain software package, called the Bitcoin Core Software Package (BCSP). By doing so, one or more BCSP instances can be run independently on the Bitcoin mainnet and recursively anchored.
In the evolution of operating systems, virtualization has become a trend. Running multiple guest operating systems on a main operating system provides isolation, flexibility, recoverability, and reusability. Modern virtualization achieves efficient hardware performance sharing through containerization, allowing multiple instances to run with minimal overhead on the main system.
By using Bitcoin Core as a stable main chain, blockchain virtualization can be achieved by customizing different parameter sets for multiple client chains.
Compared to typical Ethereum Layer 2 solutions, this form of virtualization has both similarities and differences. The similarity lies in achieving computational scalability beyond the main chain through an additional abstraction layer. However, the difference is that Layer 2 solutions are usually independent of the main chain, while Bitcoin virtualization essentially maintains consistency with the main chain without establishing a new consensus mechanism.
Over the past 15 years, the development of Bitcoin Core has demonstrated stability and continuity, building credibility over time. This credibility is similar to the trust gained in the operating system virtualization process. Trust in Bitcoin Core also effectively extends to its BCSP instances.
Unlike historical Bitcoin forks, BCSP implementation is based on reusing existing code rather than divergence. Over the years, the Bitcoin network has grown from a single node to thousands of nodes, making it more robust. Similarly, as the number of Bitcoin virtualization instances increases, consensus will become even more solid.
By instantiating BCSP multiple times on a single blockchain, multiple virtualized instances can coexist, communicate, and coordinate. Furthermore, the virtualization process can be recursively applied to any instance, enabling infinite scalability both horizontally and vertically. This approach maintains structural balance and engineering simplicity throughout the process.
Due to consistency with Bitcoin Core, existing infrastructure (such as wallets) can be easily extended to support these new virtualized instances. This is similar to how Ethereum infrastructure can easily support networks like Polygon and BSC.
Another benefit of recursive use of BCSP is that when there’s a high demand for on-chain interactions, these demands can be selectively delegated to deeper levels. This dynamic balancing capability of the system helps avoid overcrowding at specific levels.
Similar to Bitcoin’s early days during the Satoshi era, newly created virtualization instances will experience a period of vulnerability in their initial stages. Therefore, providing some form of direct or indirect protection during the startup phase is crucial. When launching a new instance, operators can choose to set specific block heights for protection until the instance reaches a secure and healthy state. In the future, miners with significant computing power can allocate resources to different BCSP instances, thereby enhancing the overall robustness and resilience of the system.
Additionally, merged mining can be used to some extent, such as merged mining for 1/3 of the blocks for specific instances, to help protect the network against potential 51% attacks.
A distributed network composed of multiple BCSP instances can be established, surpassing the computational efficiency of a single virtualized instance. Through inter-instance communication, effective synchronization can be maintained when necessary.
Distributed BCSP differs significantly from sharding on a single blockchain. Sharding is typically part of the original blockchain, operating under centralized scheduling, and cannot run independently or exist physically separately. However, BCSP offers the flexibility of independent deployment and monitoring.
Compared to on-chain sharding, distributed BCSP demonstrates significant cohesion and integrity. Sharding essentially transforms a single main-line structure into a multi-line collaborative structure, requiring adjustments to the consensus mechanism. In contrast, BCSP’s on-chain consensus is derived from Bitcoin and remains unchanged when organized into a distributed system, thus requiring no reconstruction.
To improve the response speed of block processing, BCSP’s block confirmation time has been reduced to 60 seconds or less, which has proven effective in modern blockchains.
Rapid confirmation increases the available storage space for each instance by tenfold, thereby simplifying application development.
Cross-Layer Bridging: Elevator-Style Cross-Layer Transfer
By creating a universal asset transfer interface, direct and consistent transfers between layers can be achieved. If Bitcoin on the main chain can be conditionally locked and unlocked (particularly suitable for discrete logarithm contracts), the same control mechanism can be used for assets at different levels. This enables seamless asset transfers between any two layers without additional relays. This consistent and direct cross-layer transfer is referred to as an “elevator”.
Asset transfer between Bitcoin and existing blockchains remains an important topic. Various teams are actively researching different methods, which involve trade-offs between decentralization, trustlessness, and efficiency. With conditional locking methods such as Discrete Log Contracts (DLC), there is an open attitude towards other solutions to meet various needs.
When deploying BCSP, there are multiple methods to anchor it to higher levels. One common approach is to use a single transaction on the main chain as a carrier. This transaction stores the Merkle root of aggregated transactions, allowing verification of any specific transaction. In this case, BCSP itself validates transactions according to inherited rules.
Another viable option is to compile this information into a series of inscriptions on its main chain over time. When necessary, the existence and validity of this information can be verified through external inscription indexers. L2O-A is a typical example of a Layer 2 blockchain deployed on Bitcoin that submits new block results and proofs. Considering the modular architecture, it can be reorganized to ensure compatibility with Ordinals and BRC-20.
In the context of operating system virtualization, generating system snapshots enables quick availability. Similarly, the ability to take snapshots of specific instances and selectively load and execute them at designated levels makes it possible to reuse functionality at different levels of detail.
The total token supply is 210 million, with 80% allocated to the community and only 20% to the team and contributors (with a lock-up period) to ensure continued support and stability. Of this, 50% will go to PoW mining, 15% to core contributors, 10% to community rewards, 5% to advisors, 5% to pre-sale, and 15% to ecosystem rewards.
To summarize this project, it’s currently in the testnet phase, with some projects already running on it. The mainnet is set to launch in September. However, participating in the testnet is quite challenging for now, and ordinary users might need to invest considerable time. Mining on the testnet likely won’t be convertible to the mainnet, though there might be some rewards. Given the current timeline, it might be too late to fully engage, so it’s probably best to wait for the mainnet launch to participate in mining. As for how this Fractal Bitcoin actually performs, I don’t see much difference from L2 solutions, except for the use of virtualization concepts. The main challenge lies in data synchronization between multiple chains, which will require time to test. Nevertheless, it represents a new direction and concept, which capital is often eager to follow.
This article is reproduced from [There is a big cake house in the book], the original title is “Bitcoin L2 Expansion New Plan - Fractal Bitcoin Technology Explanation”, the copyright belongs to the original author [Teacher Zhu 123], if you have any objection to the reprint, please contact [Gate Learn Team] (https://www.gate.io/questionnaire/3967, the team will handle it as soon as possible according to relevant procedures.
Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.
Other language versions of the article are translated by the Gate Learn team, not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.