How secure is Fractal? Can it withstand a 51% attack?

Common forms of a 51% attack include:

  1. Hidden blocks + empty blocks/exclusion of specific transactions.
  2. The pool exploits delayed difficulty adjustments to aggressively generate blocks.

Can Fractal be understood as a parallel chain to Bitcoin?

To some extent, this understanding is also correct. Fractal indiscriminately supports and is compatible with all protocols on the main chain (such as Ordinals and brc-20) and runs in parallel with the main chain at a different settlement rate. At the same time, Fractal optionally retains the ability to settle and anchor on the mainnet through inscriptions (which allows the Bitcoin mainnet to confirm the existence and validity of every Fractal transaction when needed, a typical L2 feature). This settlement can be high-frequency or low-frequency; real-time or asynchronous, depending on actual business needs.

With improvements in Fractal implementation, we will continuously optimize it while maintaining 100% compatibility. This includes making inscription transactions more compact and improving UTXO management, allowing Fractal to gradually become an organic extension of Bitcoin.

Comparison with EVM-based solutions

EVM-based solutions essentially create more scenarios by integrating Ethereum's well-established mechanisms, whereas Fractal prioritizes addressing congestions on mainnet systematically.

Fractal operates within the established framework of Bitcoin without introducing additional constructs. Therefore, we contend that Fractal serves as an native scaling solution compared to EVM-based solutions.

Has anyone done something like Fractal before?

As far as we are aware, the strategy of homogeneously extending Bitcoin through virtualization isn’t seen before, making Fractal innovative in its approach to scaling Bitcoin.

Previously, several approaches have been attempted to extend the scalability of Bitcoin:

  1. Increasing block size: This involves enhancing the processing capacity of individual blocks to boost transaction throughput while maintaining a consistent block time.
  2. Forking: Introducing new consensus mechanisms through forks, such as Litecoin's adoption of the scrypt mining algorithm (a code-level fork) and Bitcoin Cash's implementation of the Difficulty Adjustment Algorithm (DAA) (a blockchain-level fork).
  3. Lightning Network model: This model prioritizes real-time transaction processing in the memory pool, albeit at the expense of eventual finalization.

In contrast, virtualization presents significant differences from the aforementioned methods. Virtualized instances maintain relative consistency with the host chain consensus at the protocol level while being liberated from the physical constraints and historical burdens of the mainnet. We believe that this approach offers long-term potential to transform Bitcoin into a more versatile and resilient system.

How is virtualization specifically implemented?

We've made tailored modifications to Bitcoin Core, enabling rapid customization and deployment, drawing from reasonable customization directions and perspectives learned from some certain modular blockchain solutions. Given Bitcoin's extensive development history, we've pruned obsolete code that no longer serves practical purposes. While ensuring complete consensus, we've streamlined the system's implementation, resulting in a more concise and more lightweight version known as BCSP(Bitcoin Core Software Package). Think of BCSP as akin to a blockchain rendition of Linux-in-Docker.

How are asset transfers between the main chain and Fractal conducted?