What other expansion plans does Fractal, OP_NET, and AVMBRC100 have for BTC?

Author: Trustless Labs, Source: Author's Twitter @TrustlessLabs

Since the first quarter of 2024, the speculative enthusiasm of the BTC ecosystem has not been as high as in 2023, but as more and more developers join and become familiar with the BTC model, the BTC ecosystem has made rapid progress in terms of technology, especially in terms of programmable expansion solutions. Trustless labs has previously introduced BTC's L2 and UTXO binding and BTC re-staking. This article will continue to fill in the gaps and introduce the highly popular Fractal Bitcoin and programmable solutions for BTC metadata protocols such as BRC20, CBRC, and ARC20.

1. Fractal

Fractal is a virtualized bitcoin core client software that recursively creates a tree-like scalable framework. Each layer of the blockchain can improve the performance of the entire Fractal network. Because of the reuse of the main code, Fractal is instantly fully compatible with Bitcoin and its infrastructure, such as mining. The difference is that Fractal activates the op_cat operator, allowing more logic to be implemented.

Fractal was developed by the Unisat team, and Unisat mentioned the relevant development progress of Fractal in a blog in January 2024. The project launched the Beta test network on June 1, 2024, completed a reset of the testing phase on July 29, and the main network is expected to be launched in September 2024.

The team has just released its token economics. The Fractal network will have its own tokens, 50% of which will be mined, 15% will be used for the ecosystem, 5% will be pre-sold to early investors, 20% will be for consultants and core contributors, and 10% will be used for community subsidies to establish partnerships and liquidity.

Architecture Design

Fractal fully virtualizes the bitcoin core client and encapsulates it into a deployable and runnable blockchain software package (Bitcoin Core Software Package, BCSP). Then it runs one or more BCSP instances independently by recursively anchoring to the Bitcoin mainnet. Through modern virtualization technology, efficient hardware performance sharing is achieved, allowing multiple instances to run on the main system. In simple terms, it is similar to opening multiple virtual machine instances (BCSP instances built by Fractal) on a computer (BTC mainnet), and it can also be recursive.

When a large number of on-chain interaction needs arise, these needs can be selectively delegated to deeper levels. The dynamic balancing ability of this system helps avoid excessive congestion at any particular level. In order to provide a better user experience, Fractal has also made some changes to bitcoin core. The block confirmation time has been changed to 30 seconds or less, and the block size has been increased 20 times to 20 MB, which ensures sufficient performance and short enough latency.

Fractal has activated the op_cat operator, making it possible to explore and test more expansion solutions on BTC.

At the asset cross-chain level, since different instances are running in the same physical environment, it can be understood that multiple bitcoin core chains are running under the same BTC framework, so the instance chains can communicate with each other, and a universal asset transfer interface is constructed to achieve seamless asset transfer between different layers.

Bitcoin and assets such as BRC-20 and Ordinals can be bridged through decentralized. The underlying mechanism is a rotating MPC signature mechanism with dynamic replacement. At present, it should be a packaging layer. In subsequent iterations, BTC and other mainnet assets can also exist on Fractal Bitcoin as brc-20 wrapped assets.

Compared to typical Ethereum Layer 2 solutions, this form of virtualization achieves computational scalability through an additional abstraction layer outside the main chain while maintaining consistency with the main chain without introducing a new consensus mechanism. Therefore, current BTC ASIC miners and mining pools can seamlessly join the Fractal network.

Fractal's security guarantee lies in its computing power. The design mainly enhances the security of Fractal's PoW mechanism through three aspects. Fractal introduces joint mining, where one out of every three blocks is generated by merged mining with BTC miners to help protect the network from potential 51% attacks; the remaining two blocks are produced by the Fractal network's own computing power. It can be seen that the impact on BTC miners is the key to Fractal's success, and its token economy will inevitably tilt towards miners.

At the same time, the newly created virtualized instance chain will experience an initial fragile period during the startup phase. When launching a new instance, the operator can set a specific block height to provide protection until the instance reaches a safe and healthy state. In the future, miners with a large amount of computing power can allocate their resources to different BCSP instances, thereby enhancing the robustness and resilience of the entire system.

Relationship between Fractal mainnet coin and sats

The mining output of Fractal mainnet coin is to ensure the operation of the chain. The fb chain is basically the same as BTC, and there is no ability to run smart contracts directly. Therefore, complex defi functions such as swaps require additional infrastructure. Unisat promises to use brc20 sats for swaps. This swap runs on Fractal and also requires its own nodes. The service fees charged by these nodes for self-financing are sats.

2. AVM

AVM (Atomicals Virtual Machine) is the BTC smart contract implementation of Atomicals Protocol. AVM creates a virtual machine that simulates the BTC script permission and opens multiple BTC original opcodes in the virtual machine. Developers implement smart contracts through Bitcoin script combinations and define their own rules to manage the creation and transfer of assets.

Satoshi Nakamoto designed a fully expressive script language design at the beginning of Bitcoin, which includes a rich set of original opcode instructions. These scripts have certain data storage capabilities and are Turing complete. Later, Bitcoin Core disabled some opcodes required for Turing completeness, such as basic string concatenation operations (OP_CAT) and arithmetic operators (such as multiplication OP_MUL and division OP_DIV).

The idea of ​​​​AVM is to maximize the original opcode capabilities of BTC. The AVM virtual machine simulates the BTC script and achieves Turing completeness through a dual-stack PDA (Pressable Storage Automaton). This virtual machine runs in a sandbox, which contains an indexer, an instruction parser, and a global state, so as to realize the processing of smart contracts and the synchronization and verification of states.

The instruction set of the AVM virtual machine contains a complete set of BTC opcodes, so developers can use many BTC unactivated functions for programming on the main network. This makes AVM look like a native pre-network for BTC ecological expansion.

AVM is a set of architectures, and any BTC metadata protocol, such as BRC20, ARC20, Runes, and CBRC, can be customized and jointly managed by application developers, service providers, and users to form a spontaneous consensus. Therefore, it is applicable to almost any metadata protocol, and only the indexer under the virtual machine needs to be fine-tuned.

AVM has released a beta version https://x.com/atomicalsxyz/status/1823901701033934975, and the relevant code is https://github.com/atomicals/avm-interpreter.

3. OP_NET

Official website: https://opnet.org/#

OP_NET was proposed in the third quarter of 2024 and is committed to introducing smart contract functions similar to Ethereum on the Bitcoin network, but it is more in line with the characteristics and architecture of Bitcoin. To conduct transactions on OP_NET, you only need to use native Bitcoin, without using other tokens to pay node incentives or transaction fees.

OP_NET provides a complete, compact and easy-to-use development library, written primarily in AssemblyScript (similar to TypeScript, which can be compiled to WebAssembly), designed to simplify the creation, reading and operation of Bitcoin-related technologies, especially in smart contracts and Bitcoin Smart Inscriptions (BSI).

OP_NET's Core Functions and Features

OP_NET retains Bitcoin's block consensus and data availability, ensuring that all transactions are stored on the Bitcoin network and protected by its immutable protection. Through an execution virtual machine (OP_VM), OP_NET can perform complex calculations on Bitcoin blocks, and all submitted OP_NET transactions are marked with a "BSI" string and executed in the OP_VM to update the contract status.

OP_NET nodes run a WASM virtual machine, so they support multiple programming languages ​​such as AssemblyScript, Rust, and Python. By using Tapscript to enable advanced smart contract functions, developers can deploy and interact with smart contracts directly on the Bitcoin blockchain without permission.

The code of these smart contracts is compressed and written into BTC transactions. This will generate a UTXO address, which is regarded as the contract address. Users need to transfer money to this address to interact with the contract.

When interacting with the OP_NET network, in addition to the BTC transaction fee, users also need to pay an additional fee of at least 330 satoshis to ensure that the transaction will not be identified as a "dust attack" by BTC mainnet miners. Users can add more gas fees, and the packaging order of transactions in the OP_NET network will be sorted according to the fee, not entirely dependent on the BTC block packaging order. If the OP_NET transaction fee paid by the user is greater than 250,000 sats, the excess will be rewarded to the OP_NET node network.

In order to expand the use of BTC in DeFi applications, OP_NET provides a Proof of Authority system that allows BTC to be encapsulated as WBTC, and the mainnet BTC is bridged to the OP_NET protocol through multi-signature.

It is worth mentioning that OP_NET is compatible with SegWit and Taproot, and its token design is not bound to UTXO, avoiding the risk of sending tokens to miners by mistake, further improving the security and reliability of the system. Through these features, OP_NET injects stronger smart contract functions and decentralized application support into the Bitcoin ecosystem.

OP_NET's ecological projects

OP_NET's predecessor is the cbrc-20 protocol, and most ecological projects are directly continued. The ecology covers multiple fields such as decentralized trading, lending, market making, liquidity provision, cross-chain bridges, etc.:

· Motoswap: This is a decentralized trading protocol that runs on Bitcoin Layer 1.

· Stash: This is a decentralized lending protocol that runs on Bitcoin Layer 1. Stash uses OP_NET's WBTC as collateral, allowing users to conduct permissionless lending, and loans are issued in the form of USDs stablecoins.

· Ordinal Novus: This is a market making and liquidity provision platform in the OP_NET ecosystem.

· Ichigai: This is a decentralized aggregator that integrates multiple DeFi platforms, allowing users to manage transactions, market tracking, and portfolios on a single interface.

· SatBot: A trading bot integrated into Telegram that allows users to execute transactions, track markets, and manage portfolios in real time through Telegram.

· KittySwap: A decentralized exchange and perpetual contract platform running on OP_NET.

· Redacted: Providing on-chain private and compliant DeFi private banking services.

· SLOHM Finance: A decentralized reserve currency project launched on OP_NET.

· BuyNet: A buying bot developed for the Bitcoin DeFi ecosystem.

· SatsX: A project that develops multi-functional features and tools on OP_NET to expand the capabilities of the ecosystem.

· Meme Coins such as Satoshi Nakamoto Inu, Zyn, Unga, Pepe: These are Meme tokens based on the OP_20 protocol, all supported by OP_NET.

4. BRC100

Documentation: https://docs.brc100.org

BRC-100 is a decentralized computing protocol built on the Ordinals theory. By adding new operations such as "destruction" and "minting" to brc20, and combining these new operations, the balance and status of tokens held by different addresses are recorded in the indexer, thereby realizing complex defi operations. Developers can also expand more operators based on the BRC-100 protocol to expand their business.

BRC-100 protocol operations

BRC-100 provides some operations: mint2/mint3 and burn2/burn3, so that tokens can be safely converted between the UTXO model and the state machine model:

· mint2: used to generate new tokens and increase the circulation of the entire system. Usually requires permission from an application or address to operate.

· mint3: similar to mint2, but does not increase circulation. It is mainly used to convert balances in applications into UTXO (unspent transaction outputs), which can be used in other applications.

· burn2: used to destroy tokens and update the status of the application at the same time. The destroyed tokens can be regenerated through mint2 under certain conditions.

· burn3: Similar to burn2, but instead of reducing the circulation, it converts the tokens into the state of the application. The destroyed tokens can be regenerated through mint3.

Extension and Compatibility

Computing power and state transitions can be extended through the BRC-100 extension protocol. All BRC-100 extension protocols are compatible with each other, that is, tokens that implement BRC-100 and its extension protocols can be used in all applications. At the same time, the BRC-100 protocol and its extension protocols can be updated and upgraded through improvement protocols.

The BRC-100 protocol and all its extensions and improvement protocols are collectively referred to as the BRC-100 protocol stack. All BRC-100 extension protocols are compatible with each other, that is, tokens that implement BRC-100 and its extension protocols can be used in all applications and support cross-chain operations. There are BRC-101, BRC-102 and BRC-104:

· BRC-101 is a decentralized on-chain governance protocol that defines how to govern applications based on the BRC-100 protocol or its extension protocols.

· BRC-102 is an automated liquidity protocol for BRC-100 assets, which defines an automated market-making method based on the "constant product formula" (x*y=k) for a pair of tokens based on the BRC-100 protocol stack.

· BRC-104 is a liquidity staking/re-staking pool protocol that defines how to wrap BRC-20 assets, Rune assets and BTC into BRC-100 assets through staking, and how to distribute BRC-100 asset rewards to BRC-100 assets, BRC-20 assets, Rune assets or BTC stakers. BRC-104 is the Asset Wrapping protocol and Yield Farming protocol of the BRC-100 protocol stack.

BRC-100 Ecosystem Project

The project party is exploring a method to implement a minimum index for the BRC-100 protocol indexer. The demand side can deploy its own minimum index to obtain the status of all assets of the BRC-100 protocol stack without implementing the complex calculation logic of all extended protocols. Moreover, the minimum index does not need to be updated or upgraded frequently.

There are 3 projects in the BRC-100 ecosystem:

· inBRC (Launched) - The first BRC-100 market and indexer: https://inbrc.org.

· 100Swap (Launched) - The first Bitcoin L1 AMM inscription decentralized exchange based on the BRC-102 protocol: https://100swap.io.

· 100Layer (Developing) - A liquidity protocol for the Bitcoin ecosystem on Bitcoin L1, based on the BRC-104 protocol and the BRC-106 protocol, consisting of stablecoins, wrapped tokens, and liquidity mining backed by decentralized collateral: https://100layer.io.

5. PROGRAMMABLE RUNES (Protorunes)

A rune is essentially a data structure stored in the OP_RETURN field of Bitcoin. Compared with other JSON-based protocols such as BRC-20, runes are more lightweight and do not rely on complex indexing systems, maintaining the simplicity and security of Bitcoin.

Programmable Runes is an extension layer of Runes that allows the creation of programmable assets with Runes. The introduction of these assets can exist in UTXO and support operations similar to AMM (Automated Market Maker) protocols. The core idea of ​​Programmable Runes is to use data on the Bitcoin blockchain to realize the functions of smart contracts through virtual machines or similar technologies.

Proto-Runes Protocol

In Programmable Runes, the most important project is Proto-Runes Protocol, which is led by the team of @judoflexchop, the founder of oyl wallet. Currently open source: https://github.com/kungfuflex/protorune

Proto-Runes Protocol is a standard and specification that provides a framework for programmable runes. By managing and transferring rune assets between meta protocols, AMMs, lending protocols, or mature smart contracts can be built.

For example, Proto-Runes Protocol implements a DEX (decentralized exchange) similar to Uniswap on the Bitcoin network, supporting atomic swaps of rune assets and the creation of liquidity pools. Through the combination of prototype destruction and prototype messages, users can conduct decentralized transactions and asset management without leaving the Bitcoin network.

In short, Proto-Runes Protocol allows runes to be burned into the form of programmable rune Protorunes, giving runes additional functions and uses.

Protoburn and Protorunes

One ​​of the key mechanisms of Proto-Runes is Protoburn, which allows users to destroy and convert runes into representations that are only used by sub-protocols. These rune assets are targeted through pointers in Runestone or edicts (edicts) on the Rune Protocol, thereby generating new asset forms in the sub-protocol, that is, programmable rune Protorunes.

Protoburn ensures the unspendability of runes by locking them on OP_RETURN outputs. This mechanism ensures that rune assets can be safely transferred from the main protocol to the sub-protocol, allowing further operations and transactions in the sub-protocol.

This process is generally one-way, that is, assets are transferred from the Rune Protocol to the sub-protocol, but cannot be directly transferred back. Protoburn messages are embedded within Protostone in the Protocol field of Runestone, and its protocol tag is 13 (Rune Protocol Tag). The message contains information such as the target subprotocol ID and a pointer to the asset. This mechanism provides the basis for asset management and transfer between subprotocols and allows features such as atomic swaps.

Protomessage

In the Proto-Runes protocol, Protomessage refers to the operation instructions performed in the subprotocol. It is implemented by encoding in the Protostone structure and parsing by the indexer. Protomessage usually includes operation requests for assets, such as transfers, transactions, or other protocol-defined functions. When the indexer parses the message field in Protostone, the field contains a byte array, which is usually parsed by protobuf or other subprotocol expected serializers, and then passed as a parameter to the runtime of the subprotocol. The message may involve asset transfers, transaction logic, or other protocol functions.

The pointer is used to specify the target location of the Protostone, which can be a UTXO in the transaction output or another Protostone. If the sub-protocol decides not to execute an input, when the transaction fails, the protorunes will be returned to the location pointed to by the refund pointer (refund_pointer), and the unused assets will be returned to the initiator of the original transaction.

Operation Mechanism of Proto-Runes Protocol

The operation mechanism of the Proto-Runes protocol is: the indexer first processes the Runestone features in the Rune Protocol, and then processes the protocol messages of the sub-protocol in sequence. All Protostones are processed in the order in which they appear in the Protocol field of the Runestone. In order to avoid complexity and potential security vulnerabilities, the Proto-Runes protocol prohibits recursive execution of prototype messages, that is, each prototype message can only be executed once, and any recursive instructions will cause the transaction to fail and the unused assets will be refunded.

In the Proto-Runes protocol, LEB128 (Little Endian Base 128) is a variable-length encoding method for representing large integers. LEB128 encoding is widely used to represent protocol fields and messages to save space and improve processing efficiency. Each subprotocol has a unique protocol tag to distinguish different subprotocols. These tags are represented by u128 values ​​and appear as LEB128-encoded values ​​in Protostone. Pointers are used to specify the target location of Protostone, which can be UTXO in transaction output, another Protostone, or even reference to a prototype message, so as to implement complex operation logic in the subprotocol.

Latest Progress: Genesis Protorune

QUORUM•GENESIS•PROTORUNE is the first Protorrune. Its Protoburn has been successfully completed, and the correct operation of the ord indexer can be seen. The Protoburn occurred without cenotaph because OP_RETURN was used to output the balance of QUORUM•GENESIS•PROTORUNE, which can be seen through this link: https://mempool.space/tx/eb2fa5fad4a7f054c6c039ff934c7a6a8d18313ddb9b8c9ed1e0bc01d3dc9572.

This Genesis Protorune is only a reference implementation and is not intended for sale. It is intended to serve as an open forum for the Protorune standard and can be integrated into the protocol to provide governance functions for project tokens.

@judoflexchop team is still developing an indexer for this genesis protorune WASM: https://github.com/kungfuflex/quorumgenesisprotorune

This is a functional model for implementing on-chain governance on Bitcoin L1. As an indexer, it allows users to generate voting tokens through protomessage. The same range of runes in each proposal can only generate voting tokens once. Proposals are automatically executed after reaching a quorum, and users can also withdraw votes by transferring voting tokens to non-spendable addresses. The whole process ensures the transparency and effectiveness of governance.