Since the first quarter of 2024, the speculative enthusiasm for the BTC ecosystem has not been as strong as in 2023. However, with more and more developers joining and becoming familiar with the BTC model, the technical progress of the BTC ecosystem can be described as rapid, especially in terms of programmable expansion solutions. Previously, Trustless Labs introduced BTC's L2 and UTXO binding, BTC re-staking. This article will continue to fill in the gaps and introduce the programmable solutions of the highly anticipated Fractal Bitcoin and BTC metadata protocols such as BRC20, CBRC, and ARC20.

Fractal

Fractal is a virtualization based on the bitcoin core client software, creating a scalable framework through recursive tree-like structures, where each layer of the blockchain can improve the performance of the entire Fractal network. Because it reuses the main code, Fractal is instantly compatible with Bitcoin and its infrastructure, such as in mining. The difference is that Fractal activates the op_cat operator, allowing for the implementation of more logic.

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

The team has just released its token economics. The Fractal network will have its own token, with 50% produced through mining, 15% for the ecosystem, 5% pre-sold to early investors, advisors and core contributors holding 20%, and 10% of the community subsidy used to establish partnerships and liquidity.

Architecture Design

Fractal completely virtualizes the bitcoin core client, encapsulating it into a deployable and runnable blockchain software package (Bitcoin Core Software Package, BCSP). It then anchors recursively on the Bitcoin mainnet, independently running one or more instances of BCSP. Through modern virtualization technology, it achieves efficient hardware performance sharing, allowing multiple instances to run on the main system. In simple terms, it is similar to running multiple virtual machine instances (BCSP instances built by Fractal) on a computer (BTC mainnet), and it can be recursive.

When a large number of on-chain interaction demands arise, these demands can be selectively delegated to deeper levels. This dynamic balancing ability of the system helps to avoid over-congestion at any specific level. For a better user experience, Fractal also made some modifications to the bitcoin core, reducing block confirmation time to 30 seconds or less, and increasing block size by 20 times to 20 MB, ensuring sufficient performance and short latency.

Fractal activates the op_cat operator, allowing for the exploration and testing of more scalability solutions on BTC.

At the asset cross-chain level, since different instances all run in a physical environment, it can be understood as running multiple bitcoin core chains in the same BTC framework, so the instance chains can communicate with each other, achieving seamless asset transfer between different layers through constructing a universal asset transfer interface.

Bitcoin and assets such as BRC-20 and Ordinals can be bridged through decentralized bridging. The underlying mechanism is a rotating MPC signature mechanism with dynamic replacement. Currently, it seems to be a layer of packaging. 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 outside the main chain through additional abstract layers, while maintaining consistency with the main chain and without introducing new consensus mechanisms. Therefore, current BTCASIC miners and mining pools can seamlessly join the Fractal network.

The security guarantee of Fractal lies in its hashing power. In design, Fractal mainly enhances the security of its PoW mechanism in three aspects. Fractal introduces merged mining, where every three blocks are merged-mined with BTC miners to help protect the network from potential 51% attacks; the remaining two blocks are produced by the Fractal network's own hashing power. It is evident that the impact on BTC miners is crucial to the success of Fractal, and its token economy will inevitably lean towards miners.

At the initial stage of launching a new virtualized instance chain, it will go through a period of initial vulnerability. When starting a new instance, the operator can set a specific block height to provide protection until the instance reaches a secure and healthy state. In the future, miners with a large amount of hashing power can allocate their resources to different BCSP instances, thereby enhancing the overall system's robustness and resilience.

Relationship between Fractal Mainnet Coin and sats

The mining output of the Fractal mainnet coin is to ensure the operation of the chain. The fb chain is basically consistent with BTC and does not have the ability to directly run smart contracts, so complex DeFi functions such as swap require additional infrastructure. Unisat has committed to using brc20 sats for swap on Fractal, which also requires its own nodes. These nodes charge service fees for profit and loss.

AVM

AVM (Atomicals Virtual Machine) is the BTC smart contract implementation of the Atomicals Protocol. AVM creates a simulated BTC script-allowed virtual machine and opens multiple BTC raw opcodes in the virtual machine, allowing developers to implement smart contracts by combining Bitcoin scripts and defining their own rules for managing asset creation and transfer.

Satoshi Nakamoto initially designed a fully expressive script language for Bitcoin, including a rich set of raw opcode instructions. These scripts have a certain data storage capacity 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 capabilities of BTC's raw opcodes. AVM virtualizes BTC scripts, achieving Turing completeness through a double-stack PDA (pushdown automaton) and runs in a sandbox containing an indexer, instruction parser, and global state, thereby enabling the processing, synchronization, and verification of smart contracts.

The instruction set of AVM's virtual machine contains the complete BTC opcodes, allowing developers to program using many BTC features that have not been activated on the mainnet. This makes AVM look like a native advanced network for BTC ecosystem expansion.

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

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

OP_NET

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

OP_NET was proposed in the third quarter of 2024, aiming to introduce Ethereum-like smart contract functionality on the Bitcoin network, but in a way that is more in line with the characteristics and architecture of Bitcoin. When transacting on OP_NET, only native Bitcoin is used, and there is no need to use other tokens to pay node incentives or transaction fees.

OP_NET provides a complete, compact, and easy-to-use development library, mainly written in AssemblyScript (similar to TypeScript, can be compiled to WebAssembly). Its design goal is to simplify the creation, reading, and manipulation of Bitcoin-related technologies, especially in smart contracts and Bitcoin Smart Inscriptions (BSI).

Core Features and Characteristics of OP_NET

OP_NET retains Bitcoin's block consensus and data availability, ensuring that all transactions are stored on the Bitcoin network and are protected from tampering. Through an execution virtual machine (OP_VM), OP_NET can perform complex computations on Bitcoin blocks, and all submitted OP_NET transactions are marked with the "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, and enabling advanced smart contract functionality using Tapscript without the need for permission to deploy and interact with smart contracts directly on the Bitcoin blockchain.

The code for these smart contracts is compressed and written into BTC transactions, creating a UTXO address that is considered a contract address, and users need to transfer funds to this address to interact with the contract.

When interacting on the OP_NET network, in addition to BTC transaction fees, users need to pay an additional fee of at least 330 satoshis to ensure that the transaction is not considered a "dust attack" by BTC mainnet miners. Users can add more gas fees, and the packing order of transactions in the OP_NET network is based on fee sorting, not solely relying on BTC block packing order. If the fee paid for an OP_NET transaction exceeds 250,000 satoshis, the excess amount will be rewarded to OP_NET node networks.

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

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 mistakenly sending tokens to miners, further enhancing the security and reliability of the system. Through these features, OP_NET injects stronger smart contract functionality and decentralized application support into the Bitcoin ecosystem.

OP_NET Ecosystem Projects

The predecessor of OP_NET is the cbrc-20 protocol, and most ecosystem projects are direct continuations. The ecosystem covers decentralized trading, lending, market making, liquidity provision, cross-chain bridges, and more:

1. Motoswap: This is a decentralized trading protocol running on Bitcoin Layer 1.
2. Stash: This is a decentralized lending protocol running on Bitcoin Layer 1. Stash uses OP_NET's WBTC as collateral, allowing users to engage in permissionless lending, with loans issued in the form of the USDs stablecoin.
3. Ordinal Novus: This is a market-making and liquidity provision platform in the OP_NET ecosystem.
4. Ichigai: This is a decentralized aggregator that integrates multiple DeFi platforms, allowing users to manage transactions, track markets, and portfolios in one interface.
5. SatBot: A trading bot integrated into Telegram, allowing users to execute trades, track markets, and manage portfolios in real-time through Telegram.
6. KittySwap: A decentralized exchange and perpetual contract platform running on OP_NET.
7. Redacted: Provides on-chain private and compliant DeFi private banking services.
8. SLOHM Finance: A decentralized reserve currency project launched on OP_NET.
9. BuyNet: A buy bot developed for the Bitcoin DeFi ecosystem.
10. SatsX: A project developing multifunctional features and tools on OP_NET, expanding the ecosystem's capabilities.
11. 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.

BRC100

Documentation: https://docs.brc100.org

BRC-100 is a decentralized computing protocol built on the Ordinals theory, adding new operations such as "burn" and "mint" to brc20, and combining these new operations to record token balances and states held by different addresses in the indexer, enabling complex DeFi operations. Developers can also extend more operators based on the BRC-100 protocol to expand their business.

Operations of the BRC-100 Protocol

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

• mint2: Used to generate new tokens and increase the overall circulation. It typically requires permission from a specific application or address to operate.
• mint3: Similar to mint2, but does not increase circulation. It is mainly used to convert balances in the application to UTXOs (unspent transaction outputs) that can be used in other applications.
• burn2: Used to burn tokens and update the application's state. Burned tokens can be regenerated through mint2 under specific conditions.
• burn3: Similar to burn2, but does not reduce circulation; instead, it converts tokens to the application's state. Burned tokens can be regenerated through mint3.

Expansion and Compatibility

Computational capabilities and state transitions can be expanded through the BRC-100 extension protocol. All BRC-100 extension protocols are mutually compatible, meaning that tokens implementing BRC-100 and its extension protocols can be used in all applications. Additionally, the BRC-100 protocol and its extension protocols can be updated and upgraded through improved protocols.

The BRC-100 protocol and all its extension and improvement protocols are collectively referred to as the BRC-100 protocol stack. All BRC-100 extension protocols are mutually compatible, meaning that tokens implementing 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, defining an automated market-making method based on the "constant product formula" (x*y=k) for a pair of tokens in the BRC-100 protocol stack.
• BRC-104 is a liquidity staking/ restaking pool protocol, defining how to stake BRC-20 assets, runic assets, and BTC as BRC-100 assets, and how to distribute BRC-100 asset rewards to BRC-100 assets, BRC-20 assets, runic assets, or BTC stakers. BRC-104 is the Asset Wrapping protocol and Yield Farming protocol of the BRC-100 protocol stack.

BRC-100 Ecosystem Projects

The project team is exploring a way to implement the minimal indexer for the BRC-100 protocol. Demand-side can deploy their own minimal indexer to obtain the status of all assets in the BRC-100 protocol stack without implementing the complex calculation logic of all extension protocols. Additionally, the minimal indexer does not 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 runic decentralized exchange based on the BRC-102 protocol: https://100swap.io/.
• 100Layer (Developing) - A liquidity protocol for the Bitcoin L1 ecosystem, based on the BRC-104 protocol and BRC-106 protocol, consisting of stablecoins, wrapped tokens, and liquidity mining supported by decentralized collateral: https://100layer.io/.

Programmable RUNES (Protorunes)

Runes are essentially a data structure stored in the OP_RETURN field of Bitcoin. Compared to other JSON-based protocols (such as BRC-20), runes are more lightweight, do not rely on complex indexing systems, and maintain the simplicity and security of Bitcoin.

Programmable runes are an extension layer of runes that allow the creation of programmable assets with runes. Introducing these assets can exist in UTXOs and support operations similar to AMM (Automated Market Maker) protocols. The core idea of programmable runes is to utilize data on the Bitcoin blockchain through a virtual machine or similar technology to implement smart contract functionality.

Proto-Runes Protocol

In programmable runes, the primary project is the Proto-Runes Protocol, led by the team of @judoflexchop, the 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, allowing the management and transfer of runic assets between sub-protocols (meta protocols) to build AMM, lending protocols, or mature smart contracts.

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

In essence, the Proto-Runes Protocol allows runes to be burned into the form of programmable runes, giving runes additional functionality and utility.

Protoburn and Protorunes

One of the key mechanisms of Proto-Runes is Protoburn, which allows users to burn runes and convert them into a form exclusively for use in sub-protocols. These runic assets are targeted through pointers in runestones or edicts on the runic protocol, generating new asset forms in sub-protocols, namely programmable runes (Protorunes).

Protoburn ensures the unspendability of burned runes by locking them in OP_RETURN outputs. This mechanism ensures the safe transfer of runic assets from the main protocol to sub-protocols, allowing further operations and transactions in sub-protocols.

This process is typically one-way, with assets moving from the runic protocol to sub-protocols but unable to move directly back. Protoburn messages are embedded in the Protocol field of Protostone within Runestone, with a protocol tag of 13 (runic protocol tag). The message contains the target sub-protocol ID and asset pointers, among other information. This mechanism forms the basis for asset management and transfer between sub-protocols and allows functionalities such as atomic swaps.

Protomessage

In the Proto-Runes protocol, Protomessage refers to the operational instructions executed in sub-protocols. It is encoded in Protostone and parsed by the indexer. Protomessages typically include requests for asset operations, such as transfers, transactions, or other protocol-defined functionalities. When the indexer parses the message field in Protostone, it contains a byte array, usually parsed through protobuf or other expected serializers of sub-protocols, and then passed as parameters to the sub-protocol runtime. The message may involve asset transfers, transaction logic, or other protocol functionalities.

Pointers are used to specify the target location of Protostone, which can be a UTXO in transaction outputs or another Protostone. If a sub-protocol decides not to execute a certain input, the transaction fails, and the unutilized assets are refunded to the refund pointer, returning the unused assets to the initiator of the original transaction.

Operational Mechanism of the Proto-Runes Protocol

The operational mechanism of the Proto-Runes protocol involves the indexer first processing the runestone features in the runic protocol, followed by sequentially processing the protocol messages of sub-protocols. 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 the recursive execution of prototype messages, meaning each prototype message can only be executed once. Any recursive instructions will result in transaction failure, and the unused assets will be 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 sub-protocol has a unique protocol tag to distinguish different sub-protocols. 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 transaction outputs, another Protostone, or even reference a prototype message to implement complex operational logic in sub-protocols.

Latest Development: 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 seen, where Protoburn occurs without cenotaph because the balance of QUORUM•GENESIS•PROTORUNE is used in the OP_RETURN output, visible at: https://mempool.space/tx/eb2fa5fad4a7f054c6c039ff934c7a6a8d18313ddb9b8c9ed1e0bc01d3dc9572.

This genesis Protorune is intended 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 protocols to provide governance functionality for project tokens.

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

This is a functional model for on-chain governance on Bitcoin L1, serving as an indexer that allows users to generate voting tokens through protomessage, with each range of runes in the same proposal generating voting tokens only once. Proposals are automatically executed upon reaching the required number of participants, and users can also withdraw their votes by transferring voting tokens to an unspendable address. The entire process ensures transparency and effectiveness in governance.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。