Author: Jasmine

X/Tweet: @Jasmine9m88

As we all know, the reason Casey launched Runes was that he believed that BRC20 was technically deficient and hoped to reduce the pressure on the Bitcoin network through the new FT protocol. The Runes protocol is based on UTXO, which not only can effectively reduce the expansion of garbage UTXO, but also has good compatibility and scalability. Its core protocol has been simplified to just 500 lines of code, with the goal of providing developers and users with a simple and easy-to-use homogeneous token protocol.

Casey: “I’m not sure it’s a good idea to create a new fungible token protocol for Bitcoin. 99.9% of fungible tokens are scams and memes. However, they don’t seem to be going away any time soon. Casinos don’t seem to be disappearing any time soon. Creating a good fungible token protocol for Bitcoin could bring significant transaction fee revenue to the Bitcoin network, attract developer attention, and bring in more users. Additionally, if this protocol has a smaller on-chain footprint while promoting responsible UTXO management, it may be able to mitigate the damage more than existing protocols.”

Since the development of the Runes protocol was announced in September last year, after several months of careful polishing, what features and advantages does Runes have compared to FT protocols such as BRC20?

This article sorts out the above issues based on Casey’s recent speeches, interviews, blogs, and content on GitHub for your reference and does not represent my own views. Since I have no technical background, please feel free to point out any errors.

Runes VS BRC20

1. Operation is simpler and more efficient

Reduced number of transactions: The deployment and minting of BRC20 tokens require two transactions each, and token claiming requires three times. Runes only requires one transaction to complete all operations without generating unnecessary useless UTXO.

Improved transfer efficiency: A transfer transaction in BRC20 only supports one recipient and one token. Runes supports transfers to multiple recipients at the same time, and can transfer multiple Runes tokens.

2. More friendly to developers

Data storage and indexing: BRC20 data is stored in Segregated Witness in JSON format, based on the account model, and the balance is bound to the address. The data of Runes is stored in the OP_RETURN field of the transaction, using the UTXO model, and the token balance is directly bound to the UTXO. Therefore, when confirming the Runes balance, you only need to verify the UTXO you own. There is no need to scan the entire network state like BRC20, which is more friendly to indexes.

Provide reference implementation: When BRC20 was launched, it only had specifications but no supporting facilities such as indexing, browsers, and wallets. Runes came with its own reference implementation (ord) when it was launched, including indexing, browser and wallet functions. BRC20 relies on ordinal theory for token transfer, which is complex to implement. While Runes are independent and do not rely on ordinal numbers or inscriptions, it should be easier to write alternative implementations.

3. Stronger compatibility and scalability

Compatible with UTXO second-layer protocols: Runes’ UTXO-based design makes it better compatible with UTXO-based second-layer Bitcoin protocols such as Lightning Network and CKB. Through "UTXO isomorphic binding", CKB can even directly provide smart contract functions for Runes.

Supports SPV (Simple Payment Verification): An SPV wallet is a lightweight Bitcoin wallet that only downloads and verifies block header data related to user transactions. Users can use the SPV wallet to manage and use Runes tokens and enjoy a light, simple and fast trading experience. This is something BRC20 cannot achieve.

Support soft fork upgrade: Compared with the BRC-20 protocol, Runes is more scalable and can be upgraded through soft fork.

4. The token issuance (etch) method is more flexible

Name length supports 1-28 characters: BRC20’s token names are limited to four characters, while Runes token name length can be adjusted between 1 and 28 characters. In order to balance the release pace of Runes and prevent popular short names from being quickly taken up, the Runes protocol requires names to be at least 13 letters in length within the first four months of launch. Every approximately four months thereafter, the minimum length of the name will be reduced by one letter until the next halving event occurs, when single-character Runes (26 in total) can be created.

More unambiguous names: Unlike BRC20 token names, which may contain arbitrary Unicode characters, Runes names only support letters A through Z and • characters, making the names more unambiguous and difficult to forge.

Solve the name front-running problem: Use the Commit-Reveal mechanism to prevent miners from learning about Runes ++ in advance

name and make a head start.

Introducing diversified token issuance methods: In addition to the two issuance methods of open etch (the project cannot pre-allocate tokens) and fixed total issuance (the project can pre-allocate tokens), we are also considering adding more gameplay to relax open Non-reservable requirements for etch. In addition, Runes can be "expressive" - ​​perhaps by creating a parent-child inscription and placing the Runes under the child inscription.

5. Higher security

Resist poisoning transaction attacks: BRC20 may be subject to poisoning transactions (the attacker sends a large number of small-amount BRC20 transfer inscriptions to the victim's address, which may cause the recipient's balance to be "locked"). Runes does not have this risk. .

In addition, Casey also made a rough comparison between several other older FT protocols and Runes. In addition to being simpler, the advantages of Runes are also reflected in the following aspects:

Runes VS RGB

Better user experience: The prerequisite for receiving RGB tokens is that UTXO must already exist on the address, which is not required for Runes.

Stronger security: Runes adopts Bitcoin’s UTXO model, so it is not affected by race conditions.

On-chain: When performing RGB transactions, not only do you need to download data from the Bitcoin blockchain, but you also need to download and upload data to the server. Runes are on-chain, so transactions can occur without uploading or downloading server data, or even communicating with the recipient.

Unique names: Runes token names are unique, while RGB token names can be repeated.

Runes VS Taproot Assets

On-chain: Similar to RGB, transactions with#TaprootAssets not only require downloading data from the Bitcoin blockchain, but also downloading and uploading data to the server. Runes transactions are completed on the chain without relying on additional server data interaction.

Runes VS Counterparty

No native token required: Counterparty requires leveraging native assets to create tokens, while Runes does not.

UTXO-based model: Unlike Counterparty’s account-based model, Runes uses a UTXO-based model. This helps avoid address reuse issues, improve scripting capabilities, and integrate more naturally with the Bitcoin ecosystem.

Script compatibility: Runes is automatically compatible with all current and future script opcodes and address types, while Counterparty requires additional development of these features, which increases the flexibility and scalability of Runes.

Runes VS ERC20

Consistency: The behavior of all Runes tokens is uniform, while the issuance of ERC20 tokens relies on their respective smart contracts, which can lead to complexity and the need for additional audits.

Unique name: The name of the Runes token is unique, while the name of the ERC20 token can be repeated.

“We will all pass away one day, and perhaps what matters is what we leave behind. Do you want to leave an eternal mark on the solid chain of Bitcoin, or build on other chains that may disappear?”

—Casey

that's all.

Content reference:

https://rodarmor.com/blog/runes/

https://www.youtube.com/watch?v=IS406ToIRo4

Disclaimer: This article is for reference only and may not be used as legal, tax, investment, financial or any other advice and does not represent the position of RunesCC.

Author: Runes Chinese Community; from the ChainDD content open platform "DeDeHao". This article only represents the author's opinion and does not represent the official position of ChainDD. For "DeDeHao" articles, the originality and authenticity of the content are determined by the contributors. We guarantee that if the manuscript is plagiarized, falsified, etc., the legal consequences will be the responsibility of the contributor himself. Dehao platform publishes the article. If there is any infringement, violation of regulations or other inappropriate speech content, readers are requested to monitor it. Once confirmed, the platform will immediately download it. Wire. If you encounter any problems with the article content, please contact WeChat: chaindd123