Author: 十四君

Source: https://mp.weixin.qq.com/s/EN8ZdiomQVUQ4WBRZ4GqKA

What is Runes?

In the past year, the biggest narrative in web3 has been the explosion of the inscription ecosystem, starting with Ordinals, a technology that assigns unique serial numbers to every sat on bitcoin network.

Its core founder, Casey, submitted the basic version of the Runes code in September last year, but it has not been officially launched on the mainnet, so during the inscription craze in September, projects like runeAlpha forked the code in advance and independently launched protocols like RunesAlpha. Although there have been allegations of plagiarism, the market cap growth of several hundred million in just a few months also demonstrates the infinite potential of the Runes protocol.

So, the official version of Runes protocol, designed by Casey, the founder of the Ordinals protocol, will also be officially announced around April 20, 2024. And it will directly go online on the btc mainnet, so projects wanting to issue Runes assets and various wallet, NFT/FT trading markets wanting to support Runes will face one of the most difficult challenges in the blockchain industry: how to directly sprint to the mainnet without a testnet!

And Casey’s Twitter statement is highly confident：

This article will systematically sort out the underlying field changes of the Runes project, allowing everyone to fundamentally understand the differences between Runes and Brc20, Arc20, and other FT protocols, and make rational decisions by comparing their advantages and disadvantages.

How is additional information recorded on Bitcoin?

There are two mainstream off-chain data attachment schemes on Bitcoin: inscribing and etching.

Etching Basic Principles

Runes uses etching technology, a simple and intuitive way to record information on the chain: that is, writing into the op-return field of Bitcoin UTXO (Unspent Transaction Output), which has been enabled since Bitcoin Core client version 0.9 (14 years ago). OP-RETURN creates a clear, verifiable, and non-spendable output on the blockchain, allowing data to exist on the blockchain, similar to UTXO outputs but not spendable.

In btc’s blockchain explorer, it is easy to see that this transaction is attached with an op-return message, as shown in the figure below:

As you can see, output #3 here is actually detached. Although it occupies an output position of this UTXO, it is a closed-loop rectangle, indicating that it cannot be transferred and spent again. So it’s like a transaction’s memo area, left on Bitcoin’s storage space, and can be found by indexing through the transaction hash.

You might notice why there’s a RUNE_TEST after OP_RETURN. This is the result of decoding the specific content. Clicking on the details button, you can find a hexadecimal encoding string like 52554e455f54455354. It’s actually a hexadecimal encoded data, which when decoded will become RUNE_TEST. Similarly, there are other encodings in the details, which will eventually be decoded into a string, probably in json format, reflecting the deployment, casting, and issuance implications of Runes assets, etc.

Inscribing Basic Principles

In fact, in protocols like Ordinals/BRC20, embedding metadata on-chain is written to the witness data (witness field) of the transaction. This inscribe process is implemented through Segregated Witness (SegWit) and Pay-to-Taproot (P2TR) to isolate the witness, which includes two stages: commit and reveal, which are completed by two final transactions.

Actually, P2TR is a transaction output type of Bitcoin, introduced in the Taproot upgrade in 2021. It allows different transaction conditions to be stored more “privately” on the blockchain. The reason for enhancing privacy is that only when revealed, can the specific complete content be seen. Specifically, the generation of p2tr addresses uses script hashes, and when spending, provides the real script (including engraved data), so to upload inscribed data, you need to first generate a utxo (commit transaction) that pays to the p2tr address generated by this script, and then when spending this utxo, provide the real script in the witness script, thereby uploading the inscribed data to the chain (reveal transaction).

In fact, the Ordinals protocol is very easy to understand. It completes the inscribing process (commit, reveal) by two transactions being chained, and the Ordinals protocol defines that the inscription is bound to the first sat of the first input. So, the binding process is inscribing, and the result of binding is the inscription.

Comparison of the two on-chain data schemes

Etching:

● Advantages: Simple, intuitive, clear logic, low transaction cost, and does not occupy the full node memory pool.

● Disadvantages: Limited to 80-byte length, requires highly compressed data encoding.

Inscribing:

● Advantages: Almost no size limit, has some privacy protection capabilities, has various gameplay (time lock, proof of work), etc.

● Disadvantages: Transactions need to be chained twice, resulting in higher final costs, long-term commitment, and high pressure on the full node memory pool.

Interpretation of the underlying design of Runes

The initial code of the Runes protocol was released by Casey on the Ordinals 0.11 version, and the latest Ordinals has evolved to version 0.18, a huge version change, also giving us the opportunity to step into the design process of a top protocol.

Let’s start with the changes in the underlying fields of the starting point and endpoint versions of Runes.

Interpretation of Runes 0.11 version

The initial Runes has three main parts: edicts (asset transfer information), etching (asset deployment information), and burn (destruction).

Specifically, when the information in the op_Return of a transaction can present the information of edicts and the format is correct, the off-chain parser will calculate that the user’s assets have been transferred, and the output is the target of the transfer.

Similarly, the content of etching also directly presents the main information of deploying assets. We can compare it with ERC721. The biggest difference lies in the limit and term, which corresponds to the maximum total issuance and the termination condition of the issuance (controlled by blocks).

The fundamental difference between the inscription and rune projects and issuing assets through Ethereum smart contracts lies in the lack of real-time validation on the blockchain due to the absence of smart contract verification. This results in a lack of consensus if a project issues assets on-chain and also runs a new inscription protocol to customize features such as whitelisting for minting, tokenomic release rates, royalty payments, etc. Without consensus, there will be no participation in the project. Therefore, inscription protocols (such as BRC20, Atomical, Runes) all uniformly define the method of asset issuance and also standardize the way users participate in minting, based on the concept of fair launch, completely open to user participation, further eliminating the situation where project teams excessively intervene in asset market perception.

Even if a project team tries to control the market by accumulating assets through buying, it still needs to pay a huge gas cost, a process that users can perceive and freely choose.

The initial version of the Runes protocol design was quite comprehensive, so the derivative runeAlpha, even though it’s a clone, still occupies a considerable market share, accumulating 820,000 transactions, consuming 312 BTC in fees alone.

Users can easily use the design of the rune field itself to achieve asset composition, splitting, and even once Runes assets are combined across protocols like Ordinals, Atomical, etc., they can also utilize the expressive language variety of op_Return to achieve splitting.

What does the latest version of the Runes protocol achieve in 0.18, and what considerations led to the introduction of such fields?

Interpretation of Runes 0.18 version

Interpreting Runes 0.18 is quite challenging due to the lack of a test network. Essentially, one has to examine the logic from Casey’s source code to understand it. The final delineation of the fields can be categorized into four aspects:

Firstly, the edicts still define the direction of asset transfer, similar to RuneAlpha, but with the addition of a pointer parameter. This is used to modify the default direction of asset transfer. Originally, the default transfer was at position 0, but with this parameter, it can be set to 1 or other values. The design philosophy behind this is to adapt to various Runes assets being transferred simultaneously, reducing op_Return encoding, and ultimately lowering transaction costs for users.

Secondly, a new field called Mint has been added. Since mint is placed at the same level as edicts, it means that a transaction can only mint one asset. This is different from the previous RunesAlpha, where deliberately designed transactions could mint a large number of new assets in one go. This balances the starting line for both technical and regular users, as everyone has to compete for gas.

A significant change in the deployment of assets:

The most important change is the etching, which is the detailed design of asset deployment. The complete field content is as follows:

It might seem overwhelming at first, indeed, it’s a very complex way to deploy new assets. Let’s delve into it in detail.

The major change is the design to reduce op_Return encoding. Given that op_Return limits the length to 80 bytes, every encoding space needs to be cherished. Hence, Casey changed the asset ID from a simple unique ID generated from block height + transaction number to a string format of block height + colon + transaction number. Since the Bitcoin mainnet has only over 800,000 blocks, the final ID encoding saves half the space. This reduction in encoding costs multiplies in scenarios involving batch minting and batch transfer.

Another significant change is the terms field, ensuring fairness for participants. Now, asset deployment and minting no longer start like in RuneAlpha, based on the block height when the asset deployment protocol transaction is on-chain. Instead, it starts at the height and offset specified by the issuer. This means users don’t need to constantly monitor the memory pool for the latest minting opportunities, reducing the risk of falling into phishing or scam projects. The issuer can deploy the asset in advance, conduct a series of marketing activities, and finally engage users. Besides using height as a measure of participation time, there’s also a cap to control the scale of asset issuance. It’s no longer unlimited minting but limited issuance, first come, first served.

As an asset issuance protocol, one of the major challenges is controlling the scale and equity of the issuer. For inscription, the most crucial aspect is the asset name. In Runes, the name is a scarce resource, and there’s a rule for releasing Rune names based on a halving cycle. Initially, only longer names can be deployed, and over time, shorter names can be deployed.

Imagine, with each name length release cycle, there’s a continuous surge of registration, akin to domain name rushes. How to prevent issuers from being snatched?

This leads to the most significant change in the deployment of Runes this time: the deployment process is no longer just a single op_Return transaction but a inscribe process. As mentioned earlier, inscribe technology provides some privacy protection through commit and reveal. The new version of premine serves this purpose, requiring a certain interval between commit and reveal transactions. When the name used by the issuer is revealed, even if other hackers want to create phishing assets and have seen the name in the memory pool, they cannot bypass this limitation of advance disclosure, thus protecting the issuer’s control over the name.

In the final version 0.18, a turbo field is added, which currently doesn’t have a clear public function, suggesting participation in subsequent protocol layer changes.

How do we evaluate the new version of the Runes protocol?

After interpreting the underlying fields above, one cannot help but marvel at Casey’s insights into asset issuance. In just two months, he designed and implemented protocol content that aligns so closely with market demand pain points.

This is a market where value is measured by prices.Inscription initially introduced as a completely differentiated smart contract model, opened up many imaginative possibilities. True fair minting also allowed a large number of users to truly enter the BTC circle, further igniting the BTC L2 frenzy. However, the initial roughness of the inscription led to a proliferation of low-quality assets, with rampant piracy and rugs tarnishing the inscription ecosystem. The appearance of Runes, with its highly customized issuance management, will bring order to the market.

Moreover, the Runes protocol is embedded within the Ordinals protocol itself, leveraging the user base of Ordinals from the start. Positioned as an FT protocol, it compensates for the previous plight of Ordinals being only an NFT with a lack of market operational gameplay.

Finally, recording on-chain data using op_Return almost allows any institution the ability to replicate ledger. Further reducing centralization can make Runes assets have the same security performance as BTC.

Are there any shortcomings in the Runes protocol? Indeed, there are.

Firstly, there’s a timing issue in the market. Although Casey chose to synchronize the launch with the BTC halving period, the highly tense development time, even changes to the protocol’s content as recently as yesterday, means fewer and fewer institutions can access the Runes protocol firsthand. As a result, the protocol ecosystem will need more time to mature.

Secondly, there’s the complexity of the rules. The rules for issuance management are already complex, but the change in names allows issuers to initially choose longer names, combined with special punctuation, making the maximum length of Runes protocol names like:

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,almost 55 characters. This indirectly increases the risk of users being phished, and it’s challenging for interfaces on mobile and plugin ends to fully display them.

Lastly, there’s a future compatibility issue. The Atomical protocol, which is also hot in the market, has now moved towards the AVM stage, allowing inscription to move away from the token speculation stage and further towards the narratives of BTC L2 or BVM, which has to be said that casey is slightly behind, but also limited the rune project to only being a play in the issuance layer.

Follow us

Twitter: https://twitter.com/WuBlockchain

Telegram: https://t.me/wublockchainenglish