Forward the Original Title‘Fractal、OP_NET、AVM、BRC100、可编程符文，BTC 还有哪些扩展方案？’

Since the first quarter of 2024, the speculative enthusiasm in the BTC ecosystem has not matched that of 2023. However, as more developers join and become familiar with the BTC model, the technical progress in the BTC ecosystem has been rapid, especially in terms of programmabile scalability solutions. Previously, Trustless labs introduced BTC’s L2 and UTXO binding, as well as BTC re-staking. This article will continue to fill in the gaps and introduce the highly popular Fractal Bitcoin and the programmable solutions of BTC metadata protocols such as BRC20, CBRC, and ARC20.

1. Fractal

Fractal is an expandable framework based on Bitcoin core client software virtualization, creating a recursive tree-like structure where each layer of blockchain can improve the performance of the entire Fractal network. By reusing the main code, Fractal is instantly fully compatible with Bitcoin and its infrastructure, for example, in mining. The difference is that Fractal has activated the op_cat operator, allowing for more logic implementation.

Fractal was developed by the Unisat team, which mentioned Fractal’s development progress in their blog in January 2024. The project launched its Beta testnet on June 1, 2024, completed a test phase reset on July 29, and the mainnet is expected to launch in September 2024.

The team has just released its tokenomics. The Fractal network will have its own token, with 50% produced by mining, 15% for the ecosystem, 5% pre-sold to early investors, 20% for advisors and core contributors, and 10% as community subsidies for establishing partnerships and liquidity.

Architecture design

Fractal fully virtualizes the Bitcoin core client, encapsulating it into a deployable and runnable Bitcoin Core Software Package (BCSP). It then recursively anchors to the Bitcoin mainnet, independently running one or more BCSP instances. Through modern virtualization technology, it achieves efficient hardware performance sharing, allowing multiple instances to run on the main system. Simply put, it’s similar to running multiple virtual machine instances (Fractal-built BCSP instances) on a single computer (BTC mainnet), and it can recurse further.

When a large number of on-chain interaction demands appear, these demands can be selectively delegated to deeper levels. This system’s dynamic balance capability helps avoid excessive congestion at any specific level. For a better user experience, Fractal has also made some modifications to Bitcoin core, changing the block confirmation time to 30 seconds or less, and increasing the block size 20-fold to 20 MB, ensuring sufficient performance and short latency.

Fractal has activated the op_cat operator, enabling more exploration and testing possibilities for BTC scalability schemes.

In terms of cross-chain assets, since different instances all run in one physical environment, it can be understood as running multiple Bitcoin core chains under the same BTC framework. Therefore, instance chains can communicate with each other, achieving seamless asset transfer between different layers by constructing a universal asset transfer interface.

Bitcoin, as well as assets like BRC-20 and Ordinals, can be bridged in a decentralized manner. The underlying mechanism is a rotating MPC signature mechanism with dynamic replacement. Currently, it appears to be a wrapping layer. In subsequent iterations, BTC and other mainnet assets can also exist as brc-20 wrapped assets on Fractal Bitcoin.

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 new consensus mechanisms. Therefore, current BTC ASIC miners and mining pools can seamlessly join the Fractal network.

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

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

The relationship between Fractal mainnet coins and sats

The mining output of Fractal mainnet coins is to ensure chain operation. The fb chain and btc are basically the same, without the ability to directly run smart contracts. Therefore, complex DeFi functions like swaps require additional infrastructure. Unisat promises that brc20 sats will be used for swaps. This swap runs on Fractal and also needs its own nodes. The service fees charged by these nodes for self-sufficiency are sats.

2. AVM

AVM (Atomicals Virtual Machine) is the BTC smart contract implementation of the Atomicals Protocol. AVM creates a virtual machine that simulates BTC script capabilities and enables multiple BTC native opcodes within the virtual machine. Developers can implement smart contracts by combining Bitcoin scripts, defining their own rules to manage asset creation and transfer.

Satoshi Nakamoto designed a fully expressive scripting language design at the beginning of Bitcoin, which contains a rich set of primitive opcode instructions. These scripts have certain data storage capabilities, and their execution is Turing complete. Bitcoin Core later 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).

AVM’s approach is to maximize the capabilities of BTC’s original opcodes. The AVM virtual machine simulates BTC scripts and achieves Turing completeness through a dual-stack PDA (Pushdown Automaton). This virtual machine runs in a sandbox that includes an indexer, instruction parser, and global state, enabling smart contract processing and state synchronization and validation.

The instruction set of the AVM virtual machine contains the complete BTC opcodes, allowing developers to program using many BTC features that haven’t been activated on the mainnet. This makes AVM appear like a native pioneer network for BTC ecosystem expansion.

AVM is an architecture that can be customized for any BTC metadata protocol, such as BRC20, ARC20, Runes, and CBRC. It is jointly managed by application developers, service providers, and users, forming a spontaneous consensus. Therefore, it is applicable to almost any metadata protocol, requiring only minor adjustments to the indexer under the virtual machine.

AVM has released a beta version https://x.com/atomicalsxyz/status/1823901701033934975…, with the related code available at https://github.com/atomicals/avm-interpreter….

3. OP_NET

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

OP_NET, proposed in the third quarter of 2024, aims to introduce Ethereum-like smart contract functionality to the Bitcoin network while aligning with Bitcoin’s characteristics and architecture. Transactions on OP_NET only require native bitcoin, eliminating the need for additional tokens to pay for node incentives or transaction fees.

OP_NET offers a comprehensive, compact, and user-friendly development library, primarily written in AssemblyScript (similar to TypeScript, compilable to WebAssembly). Its design goal is to simplify the creation, reading, and manipulation of Bitcoin-related technologies, especially in terms of smart contracts and Bitcoin Smart Inscriptions (BSI).

OP_NET core functions and features

OP_NET maintains Bitcoin’s block consensus and data availability, ensuring all transactions are stored on the Bitcoin network and protected by its immutability. Through an execution virtual machine (OP_VM), OP_NET can perform complex computations on Bitcoin blocks. All submitted OP_NET transactions are marked with a “BSI” string and executed in the OP_VM to update contract states.

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

The code for these smart contracts is compressed and written into BTC transactions. This generates a UTXO address, considered the contract address, to which users must transfer funds to interact with the contract.

When interacting with the OP_NET network, in addition to BTC transaction fees, users need to pay at least 330 satoshis extra to ensure the transaction isn’t considered a “dust attack” by BTC mainnet miners. Users can add more gas fees, and the packaging order of transactions in the OP_NET network is sorted based on fees, not entirely relying on BTC block packaging order. If a user pays more than 250,000 sat for an OP_NET transaction fee, the excess will be rewarded to the OP_NET node network.

To expand BTC usage in DeFi applications, OP_NET provides a Proof of Authority system, allowing BTC to be wrapped as WBTC. Mainnet BTC is bridged into the OP_NET protocol through multi-signature methods.

Notably, OP_NET is compatible with SegWit and Taproot, and its token design isn’t bound to UTXO, avoiding the risk of erroneously sending tokens to miners, further enhancing the system’s security and reliability. Through these features, OP_NET injects stronger smart contract functionality and decentralized application support into the Bitcoin ecosystem.

OP_NET ecosystem projects

OP_NET’s predecessor was the cbrc-20 protocol, with most ecosystem projects directly continuing. The ecosystem covers various areas including decentralized trading, lending, market making, liquidity provision, and cross-chain bridges:

· Motoswap: A decentralized trading protocol running on Bitcoin Layer 1.

· Stash: A decentralized lending protocol running on Bitcoin Layer 1. Stash uses OP_NET’s WBTC as collateral, allowing users to engage in permissionless borrowing, with loans issued in USDs stablecoin.

· Ordinal Novus: A market making and liquidity provision platform in the OP_NET ecosystem.

· Ichigai: A decentralized aggregator integrating multiple DeFi platforms, allowing users to manage trades, track markets, and handle portfolios in one interface.

· SatBot: A Telegram-integrated trading bot supporting real-time trade execution, market tracking, and portfolio management via Telegram.

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

· Redacted: Provides on-chain private, compliant DeFi private banking services.

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

· BuyNet: A buy-in bot developed for the Bitcoin DeFi ecosystem.

· SatsX: A project developing multi-functional features and tools on OP_NET, expanding the ecosystem’s capabilities.

· 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

Document: https://docs.brc100.org

BRC-100 is a decentralized computation protocol built on Ordinals theory. It extends BRC-20 by introducing new operations like “burn” and “mint”, which, when combined, enable complex DeFi operations by recording token balances and states for different addresses in an indexer. Developers can also expand on the BRC-100 protocol by adding more operators to extend functionality.

BRC-100 Protocol Operations

BRC-100 introduces operations like mint2/mint3 and burn2/burn3, allowing tokens to safely transition between the UTXO model and state machine model:

· mint2: Generates new tokens, increasing the total supply. Usually requires permission from a specific application or address.

· mint3: Similar to mint2, but doesn’t increase supply. Mainly used to convert application balances to UTXOs (unspent transaction outputs) for use in other applications.

· burn2: Destroys tokens while updating the application’s state. Burned tokens can be regenerated via mint2 under specific conditions.

· burn3: Similar to burn2, but doesn’t reduce supply. Instead, it converts tokens to the application’s state. Burned tokens can be regenerated via mint3.

Extensions and compatibility

Computational power and state transitions can be extended through BRC-100 extension protocols. All BRC-100 extension protocols are mutually compatible, meaning tokens implementing BRC-100 and its extensions can be used across all applications. The BRC-100 protocol and its extensions can be updated and upgraded through improvement protocols.

The BRC-100 protocol and all its extensions and improvements are collectively known as the BRC-100 protocol stack. All BRC-100 extension protocols are mutually compatible, allowing tokens implementing BRC-100 and its extensions to be used across all applications and supporting cross-chain operations. Notable extensions include BRC-101, BRC-102, and BRC-104:

· BRC-101: A decentralized on-chain governance protocol defining how to govern applications based on BRC-100 or its extension protocols.

· BRC-102: An automated liquidity protocol for BRC-100 assets, defining an automated market-making method based on the “constant product formula” (x*y=k) for token pairs based on the BRC-100 protocol stack.

· BRC-104: A liquidity staking/re-staking pool protocol, defining how to wrap BRC-20 assets, rune assets, and BTC as 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 serves as the Asset Wrapping and Yield Farming protocol for the BRC-100 protocol stack.

BRC-100 ecosystem projects

The project team is exploring a method to implement minimal indexing for the BRC-100 protocol indexer. This allows parties to deploy their own minimal index to obtain the state of all assets in the BRC-100 protocol stack without implementing complex computational logic for all extension protocols. Moreover, the minimal index doesn’t require frequent updates or upgrades.

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 BRC-104 and BRC-106 protocols, comprising stablecoins backed by decentralized collateral, wrapped tokens, and liquidity mining: https://100layer.io.

5. Programmable RUNES (Protorunes)

Runes are essentially data structures stored in Bitcoin’s OP_RETURN field. Compared to other JSON-based protocols like BRC-20, runes are more lightweight, don’t rely on complex indexing systems, and maintain Bitcoin’s simplicity and security.

Programmable runes are an extension layer of runes, allowing the creation of programmable assets with runes. These assets can exist within UTXOs and support operations similar to AMM (Automated Market Maker) protocols. The core concept of programmable runes is to utilize data on the Bitcoin blockchain to implement smart contract functionality through virtual machines or similar technologies.

Proto-Runes Protocol

The primary project in programmable runes is the Proto-Runes Protocol, led by the team of @judoflexchop, founder of the oyl wallet. It has been open-sourced: https://github.com/kungfuflex/protorune…

The Proto-Runes Protocol is a standard and specification that provides a framework for programmable runes. By managing and transferring rune assets between subprotocols (meta protocols), it enables the construction of AMMs, lending protocols, or mature smart contracts.

For instance, Proto-Runes Protocol has implemented a Uniswap-like DEX (Decentralized Exchange) on the Bitcoin network, supporting atomic swaps of rune assets and the creation of liquidity pools. Through a combination of prototype burning and prototype messages, users can engage in decentralized trading and asset management without leaving the Bitcoin network.

In simple terms, the Proto-Runes Protocol allows runes to be burned into the form of programmable runes (Protorunes), thus endowing runes with additional functions and uses.

Protoburn and Protorunes

One of the key mechanisms of Proto-Runes is Protoburn, which allows users to burn runes and convert them into a representation for use only by subprotocols. These rune assets are targeted through Runestone pointers or edicts on the rune protocol, generating new asset forms in subprotocols, namely programmable runes or Protorunes.

Prototype burning ensures non-spendability by locking runes in OP_RETURN outputs. This mechanism ensures that rune assets can be safely transferred from the main protocol to subprotocols, allowing for further operations and transactions within subprotocols.

This process is typically one-way, meaning assets are transferred from the rune protocol to subprotocols but cannot be directly transferred back. Protoburn messages are embedded in Protostone within the Protocol field of Runestone, with a protocol tag of 13 (rune protocol tag). The message contains information such as the target subprotocol ID and asset pointers. This mechanism provides a foundation for asset management and transfer between subprotocols and allows for functions like Atomic Swaps.

Protomessage

In the Proto-Runes protocol, a Protomessage refers to operation instructions executed in subprotocols. It is implemented by encoding in the Protostone structure and parsed by the indexer. Protomessages typically include asset operation requests such as transfers, transactions, or other protocol-defined functions. When the indexer parses the message field in Protostone, this field contains a byte array that is usually parsed through protobuf or other serializers expected by the subprotocol, and then passed as parameters to the subprotocol’s runtime. This message may involve asset transfers, transaction logic, or other protocol functions.

Pointers are used to specify the target location of Protostone, which can be a UTXO in the transaction output or another Protostone. If the subprotocol decides not to execute an input and the transaction fails, protorunes will be returned to the location pointed to by the refund_pointer, returning unused assets to the initiator of the original transaction.

Proto-Runes protocol operating mechanism

The operating mechanism of the Proto-Runes protocol is as follows: The indexer first processes the Runestone features in the rune protocol, then processes the protocol messages of subprotocols in sequence. All Protostones are processed in the order they appear in the Protocol field of Runestone. To avoid complexity and potential security vulnerabilities, the Proto-Runes protocol prohibits recursive execution of prototype messages, meaning each prototype message can only be executed once, and any recursive instructions will cause the transaction to fail, with unused assets being refunded.

In the Proto-Runes protocol, LEB128 (Little Endian Base 128) is a variable-length encoding method used to represent 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 as u128 values and appear as LEB128 encoded values in Protostone. Pointers are used to specify the target location of Protostone, which can be a UTXO in the transaction output, another Protostone, or even reference prototype messages to implement complex operation logic in subprotocols.

Latest Developments: Genesis Protorune

QUORUM•GENESIS•PROTORUNE is the first Protorune, and its Protoburn has been successfully completed. The correct operation of the ord indexer can be observed, where Protoburn occurred without a cenotaph because the OP_RETURN output used the balance of QUORUM•GENESIS•PROTORUNE. This can be seen through this link: https://mempool.space/tx/eb2fa5fad4a7f054c6c039ff934c7a6a8d18313ddb9b8c9ed1e0bc01d3dc9572…

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

The @judoflexchop team is still developing a WASM indexer for this genesis protorune: 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 protomessages, with only one voting token being generated for the same range of runes in each proposal. Proposals are automatically executed when a quorum is reached, and users can also withdraw their votes by transferring voting tokens to unspendable addresses. The entire process ensures transparency and effectiveness of governance.

Disclaimer：

1. This article is reprinted from [TrustlessLabs]. Forward the Original Title‘Fractal、OP_NET、AVM、BRC100、可编程符文，BTC 还有哪些扩展方案？’. All copyrights belong to the original author [TrustlessLabs]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.