Written by: mix
Editor: Faust, Geek Web3
On March 2, 2024, the founder of Runes Alpha, the Runes ecological infrastructure project, had a discussion with Casey, the founder of the Runes Protocol, in a public issue on GitHub, and the two sides discussed how to expand the public inscription mechanism of the Runes Protocol. Topics include:
Do you want to relax the requirement that public inscriptions cannot be reserved?
Pointed out the idea that there is no stewardship of runes issued by Public Inscriptions.
A set of issuance mechanisms based on the cooperation of inscription NFT and rune FT are proposed.
Out of a strong interest in the Bitcoin derivative asset protocol, the author of this article has written this article based on some of the latest topics of Runes above, and explores the past of Runes and the Ordinals protocol, as well as similar asset issuance methods, which I believe will help everyone understand the Bitcoin ecosystem.
The so-called runes protocol is a protocol for issuing fungible tokens on the Bitcoin network, which was reconstructed by Casey, the founder of Ordinals, after the release of the Ordinals scheme, based on the characteristics of Bitcoin UTXO, and the overall design idea is very simple.
It is worth mentioning that the runes protocol is scheduled to be launched on the mainnet in late April this year when Bitcoin halves in 2024 (block height 840,000). The runes protocol is still in the process of being optimized and iterated on.
Before we briefly popularize the principles of runes, let's take a quick look at the ins and outs of the runes and what the so-called "public inscriptions" actually represent.
As early as December 2022, Casey released the Ordinals protocol, with the intention of permanently putting NFT data on the chain Bitcoin, simply put, the NFT metadata is recorded in the witness data of Bitcoin transactions like an inscription (Witness mainly contains digital signature information). This makes it possible to inscribe any form of content (e.g. text, images, etc.) on the designated satosashi.
Then, the gears of history began to turn, and on March 8, 2023, the anonymous developer @domodata Based on Ordinals, a typical NFT issuance protocol, a set of BRC-20 standards for the issuance of fungible tokens has been developed in a roundabout way, which is to stipulate a unified format and attributes (token name, total ** amount, maximum single minting amount, etc.) for those derivative asset data that need to be uploaded to the Bitcoin chain in the form of inscriptions. This information is then parsed and tracked through the indexer to show the wallet accounts and asset amounts associated with BRC-20 tokens.
The key is that the issuance of BRC-20 depends on the Bitcoin inscription NFT protocol of Ordinals, so the initial issuance mechanism becomes similar to the NFT minting process, which naturally has the characteristics of "first come, first served".
This kind of fair launch feature gives most people a fair opportunity to participate in the initial issuance of fungible tokens, and everyone can participate in the initial issuance of assets at the first time. Soon, BRC20 brought about a boom in the issuance of derivatives on the Bitcoin chain, and even directly launched this round of bull run. It can be seen that the distribution method of public inscription, which we are focusing on today, is very important for the runes protocol.
But BRC-20 also brings a lot of problems: every operation of BRC-20 assets has to initiate a specific transaction on the Bitcoin chain, and with the popularity of BRC-20 assets, the Bitcoin UTXO dataset has also expanded rapidly, which makes BTC core developers openly question BRC-20.
Ordinals founder Casey not only opposes BRC-20, but also disagrees with FT assets issued on top of Ordinals, but the popularity of BRC-20 makes him feel that although 99% of tokens are ** and gimmicks, these things will still be like casinos that cannot disappear.
At the same time, BRC-20 has left too many traces on the Bitcoin chain, bringing a burden on data bearers for Bitcoin nodes, but if someone proposes a set of asset protocols that can reduce the burden on on-chain data, it may be able to alleviate the problems caused by BRC-20.
So Casey decided to build a better fungible token protocol for Bitcoin, and then on September 25, 2023, he released the initial idea for the Runes protocol.
From a technical point of view, the Runes protocol is built on the basis of Bitcoin UTXO and additional information, and every transaction is triggered, the digital signature information generated off-chain must be put on the chain, and we can carry a message in a specific format in the signature information. The runes protocol uses the op return opcode to flag specific messages that are related to changes to runes assets.
Compared to the BRC-20 protocol, Runes has many advantages, the most important of which are:
1.The transaction steps are simplified, and no redundant useless UTXOs are generated, which can better reduce the burden on Bitcoin nodes. In addition, BRC-20 supports only one recipient and one token for one transfer transaction, while Runes supports transferring money to multiple recipients at the same time and can transfer multiple Runes tokens.
2.Cleaner storage and indexing of asset data: BRC-20 data is stored in JSON format in the witness data of a specific transaction, and BRC-20 is based on an account model where asset balances are associated with specified accounts. The data of the runes protocol is stored in the op return field of a specific transaction, and the recording method of the asset adopts the UTXO model, which can be directly bound to the UTXO isomorphically on the Bitcoin chain.
When confirming the status of a person's RUNES assets, you only need to verify the special UTXOs that the person owns and are bound to the RUNES assets, although it is still necessary to trace some information to complete the calculation, but there is no need to scan the complete UTXO collection on the Bitcoin chain like BRC-20, which is more friendly to data indexing.
3.Compatible with UTXO function extension layers: Runes is based on UTXO-based design, making it more compatible with UTXO-based function expansion layers such as CKB, Cardano, and Fuel. Through UTXO homogeneous bindings similar to RGB++, the above functional extension layer can provide smart contract scenarios for Runes.
Now that we've talked about technology briefly, let's go back to the distribution mechanics that we talked about at the beginning of this article. Casey has designed two sets of issuances for runes runes, namely Fixed Amount and Public Inscription:
1.The fixed total amount means that the issuer directly inscribes all runes runes and then distributes them, which is relatively more centralized.
2.Public inscriptions are to set parameters for how runes runes are issued, such as specifying the height or timestamp of a block, how many assets the user mints in a time period that meets the rules, and finally how much the total amount of runes is.
The scenarios and mechanics corresponding to the two distribution methods are completely different, and we will only talk about public inscriptions below.
In fact, SondotPin has been talking about this topic since Runes' Issue 124 issue, which has been endorsed by Casey.
Issues 165 reads as follows:
sondotpin: the current public offering, the project party The issuer cannot reserve runes in advance, which limits the opportunity for the project party to design an excellent token economic model.
Casey: Please review previous issue 124. I'm considering relaxing this requirement to allow the issuer to arrange the runes in a reasonable way at the time of release, even beyond the set parameters. If this is designed, the information will be prominently displayed on the runes rune detail page.
Sondotpin: Is it possible to design a mechanism with multiple releases, such as two rounds of publicly inscribed runes and then set different parameters for each release?
Casey: I'm not inclined to do that, because runes don't have managers in nature. Authority to issue should not be in the hands of a single entity with special authority. But you can add an inscription when issuing a rune, and then issue a new rune based on that inscription, so that both runes are issued with the same asset. Of course, you can also use the pre-mining method and then distribute it in other distribution methods.
If the function of CTV can be launched smoothly in the future, there is no need for protocol support, and CTV can directly set the condition template in advance, and after the conditions are met, it can do airdrops and public offerings that meet the conditions.
Discussion around Casey and Sonpin, personal opinion:
1.In the early stages of initiating a project, it is necessary to reserve some tokens
In the early stage, if the project team wants to bootstrap the business, it needs to have a certain token reserve to motivate the core team and unite the community. If the agreement can be realized according to this discussion, it will be a supplement to the fairness and participation value of public inscription, and more valuable basic project parties can participate in the runes ecosystem through public inscription.
2.Whether and how to reserve is to hand over the means of self-certification to the issuer
In fact, Casey has repeatedly spoken out on YouTube ** that the fungible token is 999% are all **, don't say you want to change the world, frankly admit that this is an industry full of gambling and speculation, treat each other with sincerity, and be good to everyone. it’s just for fun!
From issue 124 to 165, we can see that Casey has more recognition of the use cases of homogeneous tokens. There is no need to question the way of public inscription, and to expand on this basis, such as adding a reservation mechanism, is to give the issuer the right to choose, the means of self-proof, and it is also a good way to prevent bad money from driving out good money.
3.There will be more room for innovation in Inscription NFTs and Rune NFTs
Casey's idea of an inscribed NFT and rune NFT working together for multiple rounds of issuance is quite interesting. In the background, we said that Ordinals and Runes are both protocols designed by Casey, which should be regarded as two parallel relationship protocols, but in the ORD project on GitHub, there are a lot of technical crossovers and cooperations, such as sharing the underlying logic such as synchronous blocks.
The current hot projects such as Runestone and Runecoin are also the combination of inscriptions and runes. Runecoin's method of playing is the most mainstream inscription pre-mining, holding the RSIC inscription issued by Runecoin, you will continue to mine the runes of the project, and then redistribute FT after the Runes protocol is launched at the end of April. We look forward to more projects in the future that can be innovated and bring more innovative ways to play.
4.Runes issued with Public Inscriptions have no ownership
Casey's original text only expresses that rune does not have ownership, but the author thinks that this should specifically refer to the non-ownership of runes issued by public inscriptions. The two rounds of public inscription proposed by Sonpin will definitely have an address with extremely high authority to operate, which is not what the crypto crypto field wants to see.
Just like the project Runecoin after sending 21,000 RSIC inscription NFTs, it quickly sent the parent inscription to Satoshi Nakamoto's address, which means that no one can use it again, that is, it promises not to do additional issuance through technical means. This wave of operation itself has brought it a lot of praise and is very popular.
PS: What is a parent inscription? Because the interaction speed is slow and the gas is high in BTC, when the number of operations is relatively large, in order to improve efficiency, a parent inscription is generally set first, and multiple child inscriptions are directly processed in batches in the transaction of the parent inscription, so as to save the storage space and processing time of the blockchain when interacting.
Finally, a few words about the CTV mentioned by Casey, which is Check Template Verify.
CTV is a protocol upgrade proposed by Bitcoin that aims to enhance the smart contract and locking capabilities of the Bitcoin network by allowing users to specify a template for future transactions when creating a transaction. The activation of CTV will enable users to create more complex transaction types, such as trustworthy airdrops and open etchings, without the explicit support of the protocol.
This CTV proposal increases the programmability and flexibility of the Bitcoin network, and in this discussion, it is mentioned in this discussion that in simple terms, it is possible to create a template of unlock conditions using UTXOs, which has the opportunity to create more ways to play Runes. For example, with the Runes protocol +CTV, 10 users can join forces to use CTV technology, mint runes together, and then preset the promise of some future Bitcoin payment transactions, etc.
Hotspot Engine Program