BTC halving is imminent: Interpreting the underlying design mechanism and limitations of the Runes protocol

Author: Shisijun

Foreword

After a long hiatus, I am finally back. I am Shisijun again.

In the past six months, I have completely switched from the ETH ecosystem to the BTC ecosystem, from the application layer to the bottom layer of the chain, looking at the bottom layer of L2 public chains such as btc, merlin, babylon, xion, and studying the source code of Ordinals, brc20, atomic, Runealpha, Runes and other inscription rune protocols.

I have some experience, so I will continue to output. I will bring you unique insights and market value from a technical perspective.

1. What are Runes?

In the past year, the biggest narrative of web3 is the explosion of the inscription ecosystem. The initial starting point is Ordinals, a technology that gives a unique serial number to each satoshi on BTC. You can read more: Interpretation of Bitcoin Oridinals Protocol and BRC20 Standard Principle Innovation and Limitations

Its core founder, casey, submitted the basic version of Runes code in September last year, but has not yet released the main network. Therefore, during the inscription boom in September, projects such as runeAlpha forked the code in advance and issued RunesAlpha and other protocols separately. Although there is a certain claim of plagiarism, the total market value growth of hundreds of millions in just a few months also makes people see the infinite potential of the Runes protocol.

Then the official and genuine Runes protocol designed by casey, the founder of the Ordinals protocol, will also be officially announced and launched around April 20, 2024. And it will be directly launched on the btc mainnet, so all project parties who want to issue Runes assets, all wallets, and NFT/FT trading markets who want to support Runes will face one of the most difficult challenges in the blockchain industry, how to sprint directly to the mainnet without a testnet!

The official Twitter statement is even more confident~ Learn a new word by the way: Seppuku

This article will systematically sort out the underlying field changes of the Rune project, so that everyone can fundamentally understand the differences between Runes and FT protocols such as Brc20 and Arc20, and compare the advantages and disadvantages to make rational decisions and participate.

2. How is additional information recorded on Bitcoin?

There are two mainstream schemes for attaching off-chain data to the chain on Bitcoin, engraving and etching

2.1 Basic principles of etching

Runes uses etching technology, which is a simple and intuitive way to record information on the chain: that is, writing it into the op-return field of UTXO (unspent transaction) in bitcoin. Since the function was enabled in Bitcoin Core client version 0.9 (14 years), OP-RETURN will create a clear verifiable non-consumable output, allowing data to exist on the blockchain, similar to the output of utxo, but it cannot be consumed.

In the BTC blockchain browser, you can easily see that the transaction is attached with an op-return information, such as the figure below:

You can see that the output #3 here is actually free. Although it occupies the output position of the utxo output, it is a closed rectangle, which means that it cannot be transferred and consumed again. So it is like a transaction note area, which is left in the Bitcoin storage space and found through the transaction hash area index.

You may find out carefully why there is a RUNE_TEST after OP_RETURN. This is the result after decoding the specific content. After clicking the details button, you can find a coded string like 52554e455f54455354. In fact, it is a string of hexadecimal encoded data. After decoding, you can get RUNE_TEST. Similarly, there are other codes in the details. After decoding, it will become a string, probably in json format, which reflects the deployment, casting, issuance and other meanings of Runes assets.

2.2 Basic principles of inscription

In fact, in protocols such as Ordinals/brc20, metadata is embedded in the chain by writing it into the witness data (witness data, witness field) of the transaction. This inscription process is implemented through Segregated Witness (SegWit) and "Pay-to-Taproot" (P2TR), which includes two stages of commit and reveal, that is, the final two transactions are completed.

In fact, P2TR is a type of transaction output of Bitcoin. It was introduced in the Taproot upgrade in 2021. It allows different transaction conditions to be stored in the blockchain more "privately". The reason for improving privacy is that only when it is revealed can the specific and complete content be seen. Specifically, the script hash is used to generate the p2tr address, and the real script (including inscription data) is provided when spending. Therefore, in order to upload the inscription data, a utxo (commit transaction) that pays to the p2tr address generated by this script needs to be generated first. Then, when spending this utxo, the real script needs to be provided in the witness script, which uploads the inscription data to the chain (reveal transaction).

In fact, the Ordinals protocol is very easy to understand. After completing the inscription process (commit, reveal) and both transactions are on the chain, the Ordinals protocol defines that this inscription is bound to the first sat of the first input. Therefore, the binding process is engraving, and the binding result is the inscription.

2.3. Comparison of the two data chaining schemes

Etching:

• Advantages: simple, intuitive and clear logic, low transaction cost, and no need to occupy the full node memory pool.

• Disadvantages: limited to 80 bytes in length, requiring highly compressed data encoding.

Inscription:

• Advantages: Almost no size limit, certain privacy protection capabilities, multiple gameplays (time lock, proof of work), etc.

• Disadvantages: Transactions need to be on the chain twice, resulting in higher final costs, longer commit duration, and greater pressure on the full node memory pool.

3. Interpretation of Runes underlying design

The original code of the Runes protocol was released by casey on Ordinals 0.11., and the latest Ordinals has evolved to version 0.18. The huge version change also gives us the opportunity to step into the design process of a top-level protocol, just like the ERC721/ERC3525/ERC3475 standards that Shisijun once interpreted. Extended reading:

We might as well step into the field changes of the two versions of Runes, the starting point and the end point, to interpret the value of Runes according to the rules.

3.1、Interpretation of Runes 0.11 version

The original Runes overall field is divided into 3 parts, edicts (asset transfer information), etching (asset deployment information), and burn (destruction).

{  "edicts": // Asset transfer information   [    {      "id": "1000c82970852",        "amount":  sp;1000, //      Amount to transfer     "output": 0   // The output to which it is bound    }  ],  "etching": {  sp;//Asset deployment information"divisibility":1,//Minimum division unit"limit":1000,//Amount of each mint"rune":"COOK",//Full name sp;  "symbol": "C", //Abbreviation    "term": 150 //How many blocks can be minted  },  "burn": false //Destroy information}

Specifically, when the information in the op_Return of a transaction can present the information of edicts after decoding, and the format is correct, then the parser under the chain will calculate that the user's assets have been transferred, and the output is the destination of the transfer.

Similarly, the content of etching also directly presents the main information of the deployed assets. We can compare it with ERC721. The biggest difference is that limit and term limit the number of mints and the range that can be minted. This is the fundamental difference between the inscription and rune projects and the issuance of assets by Ethereum smart contracts. Due to the lack of smart contract verification on the chain, there is no real-time verification capability. If a project party issues assets on the chain and runs a new inscription protocol to customize its own whitelist Mint, token economics release rate, royalty payment and other functions, there will be a lack of consensus, and no one will participate in this project. Therefore, the inscription protocol (brc20, atomic, Runes) and others all unify the way of asset issuance and the way users participate in mint. With the concept of fair launch, users are fully open to participation, which further eliminates the situation where the project party excessively intervenes in the perception of the asset market.

Even if the project party controls the market by sweeping up and accumulating assets, it still needs to pay a huge gas price, which can be perceived and freely chosen by users in this process.

The original version of the Runes protocol design is actually quite perfect, so the evolved runealpha, even if it is a copycat, occupies a lot of market size, with a total of 820,000 transactions, and the handling fee alone consumes 312 BTC.

Users can easily use the design of the rune field itself to realize the combination and splitting of assets. Even once the Runes asset is combined with Ordinals, atomics and other assets across protocols, it can also be split with the help of op_Return's diverse language expressions.

What does the latest Runes protocol implement in 0.18, and what are the considerations for having such a field?

3.2, Runes 0.18 version interpretation

To understand Runes 0.18 was very difficult because of the lack of a test network. Basically, I could only look at the logic from casey's source code. Finally, I sorted out the fields into 4 aspects:

pub struct Runestone {  pub edicts: Vec<Edict>,  pub etching: Option<Etching>,  pub mint: Option<RuneId>,  pub pointer: Option<u32>,}pub  nbsp;struct Edict {  pub id: RuneId,  pub amount: u128,  pub output: u32,}

First of all, edicts still defines the direction of asset transfer, which is basically the same as runeAlpha. The difference is that there is an additional pointer parameter, which is used to modify the default transfer direction of assets. The original default transfer is the 0th bit. With this parameter, it can be set to 1 or others. The design concept is to adapt to the simultaneous transfer of multiple Runes assets, reduce the effect of op_Return encoding, and ultimately reduce the transaction cost of users.

Secondly, a new Mint field has been added. Since its mint is placed in an object of the same level as edicts, this means that only one asset can be minted in one transaction. This is different from the previous RunesAlpha, when the deliberate design allowed a large number of new assets to be minted in one transaction. This balances the starting line between technical asset mining and ordinary user asset mining, and everyone has to compete for gas to obtain assets.

The way to deploy assets has changed dramatically

The last and more important change is Etching is the detailed design of asset deployment. The complete field content is as follows:

pub struct Etching {  // Asset deployment information  pub divisibility: Option<u8>,  //Minimum division unit  pub premine: Option<u128>,  // Pre-mine block number  pub rune: Option<Rune>,  bsp;  // runes asset name  pub spacers: Option<u32>, // dot separator for runes asset name  pub symbol: Option<char>, // abbreviation  pub terms: Option<Terms>, // series of fields for casting rules  pub turbo: bool, ;       // Turbine, whether the asset will participate in subsequent test version changes}pub struct Terms { // Series of fields for casting rules  pub amount: Option<u128>, // Quantity limit for a single mint  pub cap: Option<u128>,     // Total number of mints   pub height: (Option<u64>, Option<u64>), // The height of the block that can be minted  pub offset: (Option<u64>, Option<u64>), // Offset, the end point of mint}

You must be dizzy after reading this. It is indeed a very complicated way to deploy new assets. Let us explain it in detail~

First of all, the biggest change is to reduce the design of op_Return encoding. After all, op_Return is limited to 80 bytes in length and every encoding space must be cherished. Therefore, Casey made a change to the asset ID, from the unique ID value generated by the simple block height + transaction number to the block height + colon + transaction number in the string form. Since the Bitcoin main network has a block height of only more than 800,000, the final ID code saves half. Don't underestimate it. In batch Mint and batch transfer scenarios, the cost is reduced exponentially.

The second is the terms field to ensure fairness for participants. Now the deployment of assets starts Mint no longer starts from the block height of the transaction chain on the deployment asset agreement as Runealpha, but the height and offset specified by the issuer as the starting and ending points. In this way, even if users do not keep an eye on the memory pool all the time to explore the latest opportunities that can be minted, they do not have to worry too much about mistakenly entering the phishing copycat project. After all, the project party can deploy the assets in advance, and then carry out a series of operational publicity activities to finally let users participate. In addition to the interval height as a measure of participation time, there is also a cap, as the total number of mints, which further controls the scale of asset issuance. It is no longer an unlimited mint, but a limited issuance, first come first served.

As an asset issuance agreement, how to control the scale and rights of the issuer is a major challenge. For inscriptions, the most important thing is the asset name, so the name in Runes is a scarce resource. There is a Runes name length release rule with a halving cycle. At the beginning, only longer names can be deployed. The longer the time, the fewer characters can be deployed.

It can be imagined that every time a name length release cycle comes, there will be a continuous trend of registration similar to domain names. How to avoid the project party being preempted?

This introduces the most significant change in Runes' deployment. The deployment process is no longer just an op_Return transaction, but an engraving. As mentioned above, engraving technology can provide certain privacy protection through commit and reveal. The new version of premine takes on this role, requiring a certain interval between commit and reveal transactions. Only when the name is revealed can the market know the name that the issuer wants to use. At this time, even if other hackers want to make phishing assets, even if experts have seen the name in the memory pool and want to counterfeit, they cannot get past this advance limit, which protects the issuer's control over the name.

At the end of version 18, a turbo field was added. This has no clear public function for the time being, implying participation in other protocol layer changes later.

4. How to evaluate the new version of Runes protocol

Through the above interpretation of the underlying fields, Shisijun can't help but sigh that Casey has a unique insight into the gameplay of asset issuance. In just two months, he designed and implemented the protocol content that fits the pain points of market demand.

This is a market that measures value by price. The Inscription Protocol, as a completely differentiated smart contract model, opened up a lot of imagination. The real fair mint also allowed a large number of users to truly enter the BTC circle, which further triggered the BTCL2D craze. However, the roughness of the Inscription Protocol at the beginning led to the flying of inferior assets, and the piracy and rugs on the streets made the Inscription ecosystem dusty. The emergence of runes and more customized issuance management will make the market orderly.

And the Runes Protocol is embedded in the Ordinals Protocol itself. With the help of Ordinals' own user base, the issuance of the Runes Protocol has stood on the shoulders of giants from the beginning. The positioning as an FT protocol makes up for the original dilemma of Ordinals as NFT lacking market operation gameplay.

Finally, the use of op_Return to record on-chain data can almost allow Runes assets to have the ability of any institution and reproduce ledgers. The further reduction of its centralization can also allow Runes assets to have a certain security performance equal to BTC.

What are the shortcomings of the Runes Protocol? Indeed, there is.

First, it is a market timing issue. Although Casey chose to launch it simultaneously with the BTC halving period, the highly tight development time, and even yesterday, the content of the protocol was still being changed. This also makes the number of institutions in the market that can access the Runes protocol at the first time less and less, so the protocol ecosystem needs more time to ferment.

Second, it is the complexity of the rules. The rules for issuance management are already very complicated, but the change in the name allows the issuer to choose a longer name at the beginning. Combined with the special dot symbol, the maximum length of the Runes protocol name even becomes:

B•C•G•D•E•N•L•Q•R•Q•W•D•S•L•R•U•G•S•N•L•B•T•M•F•I•J•A•V

It is almost 55 bits long, which in disguise amplifies the risk of users being phished, and it is also difficult to fully display the interface such as the mobile plug-in end.

Finally, there is the issue of future compatibility. The atomic protocol, which is also very popular in the market, has now moved towards the AVM stage, allowing Inscription to get rid of the simple token speculation stage and move further into the narrative of BTC L2 or BVM. Casey has to lag behind in this regard, and it also limits the Rune project to only be used as a distribution-level gameplay.