Partnered With:

Analyzing the Luke Dashjr proposal and reflecting on the essence of blockchain.

Read this article in 17 Minutes

Many times, solving the immediate real-world problems is much more important than indulging in some beautiful illusions that will always exist in tomorrow.

Original Title: "From Luke Dashjr's Plan to Reflections on the Essence of Blockchain"

Original Author: Faust & Misty, Geek Web3

·The Ordinals protocol is a system for numbering satoshis (the smallest unit of Bitcoin), or a derivative protocol that uses Bitcoin UTXOs as data storage media. Its essence is based on the "colored coin" system.

·Luke Dashjr wants to solve the problem of "garbage data" caused by BRC-20 and Ordinals on the Bitcoin mainnet, not to completely reject BRC-20 itself, in order to reduce the burden on Bitcoin, ensure its simplicity and decentralization.

From Luke's proposal alone, as long as there is a mining pool willing to package Ordinals and BRC-20 transaction data, both can survive on the Bitcoin network, but the UX will be significantly worse (BRC-20 transaction processing delays will become longer); but this also highlights the potential and opportunities of Bitcoin Layer2;

If utopian slogans like "Dollar Alternatives" and "Code is Law" can be constantly proven false over time, then what is the meaning of the existence of Bitcoin and blockchain? What problems can it truly solve?

Recently, Luke Dashjr, a veteran in the Bitcoin community, sparked countless discussions with his radical remarks about BRC-20. Luke believes that BRC-20 and the Inscription Protocol bypass the data size limit of Bitcoin blocks and forcibly stuff a large amount of "garbage data" into the blocks. This approach will cause unnecessary burden on nodes, as it increases the nodes' expenses in terms of network speed, bandwidth, and storage capacity. If this situation continues for a long time, it will continuously reduce the decentralization of the Bitcoin network and ultimately undermine the excellent tradition that supports this "most decentralized blockchain ecosystem".

Actually, Luke's concerns are not unfounded. On February 1st of this year, the Bitcoin network saw its "largest block ever" at 3.96MB, solely due to the inclusion of an NFT called Taproot Wizards. At the time, Luke Dashjr and others recognized that this phenomenon would cause Bitcoin's block size to remain high, thereby increasing the hardware requirements for full nodes. Decentralization is crucial in reducing the cost of running nodes for users. If Bitcoin were to become like Solana and Sui in the future, where people can only run nodes in third-party data centers, it would be a tragedy for the Bitcoin community and even the entire Web3.

Increasing the bandwidth/storage cost of nodes and weakening decentralization, large blocks themselves also have an impact on security because the larger the block, the slower it propagates within the network, the worse the data consistency of nodes, and the higher the orphan rate and ledger fork rate. The Conflux team has repeatedly emphasized this point before, and the Ethereum Foundation has also been evaluating the impact of larger block sizes on security after the launch of EIP-4844. This kind of thing is bound to "affect the whole body with a slight move".

Setting aside the negative impact of BRC-20 and Ordinals on the underlying security and decentralization of the Bitcoin network, the practice of nesting derivative assets in Bitcoin UTXOs, also known as "nesting dolls," represents a new risk. Essentially, this transfers the security issues that derivative assets need to solve directly to the Bitcoin network. If the total value of these derivatives exceeds the value of assets/computing power required to ensure the security of the Bitcoin network, there may be a "top-heavy" problem, which has become increasingly apparent in POS Ethereum. Previously, the tech celebrity "Xiangma" expressed concern about this issue in an interview.

But interestingly, although Luke expressed negative attitudes towards BRC-20 and various inscriptions in some of his remarks, and stated that if the new version of the node client code is released and widely adopted, BRC-20 and Ordinals may disappear, when others pointed out that Bitcoin Layer2 could be used as the new destination for BRC-20 to avoid burdening the Bitcoin mainnet, Luke affirmed this view and did not absolutely deny BRC-20 in terms of "ideology". Later, Luke himself even said: it is not necessary to eradicate all inscriptions in order to bring benefits to the Bitcoin network.

Ultimately, Luke's dissatisfaction seems to lie in the risk that the data expansion caused by various derivative products poses to the Bitcoin mainnet, rather than the desire to "eliminate" these derivatives themselves. Instead, he wants to drive out "uninvited guests" like Ordinals to facilities outside the Bitcoin mainnet, which in turn presents an opportunity for Bitcoin Layer2. However, Luke's radical approach has also sparked controversy among many people. His actions not only involve disputes over the discourse power of the Bitcoin ecosystem, but also reflect the fundamental differences in product design philosophy between BTC and ETH - years ago, Vitalik disagreed with Luke and others on similar issues, indirectly leading to his decision to create his own chain.

In the following text, we will analyze the technical aspects of the Ordinals protocol and Luke's solution, and briefly explain the issues faced by the "Satoshi Nakamotoists" represented by Luke and the "speculators" represented by BRC-20 players. If Web3 is not as grand and beautiful as some people say, what is its true value?

Analysis of the Principles of the Ordinals Protocol

From a technical perspective, Ordinals protocol is a system that assigns a number to each satoshi (the smallest unit of Bitcoin) or a derivative protocol that uses Bitcoin UTXO as a storage medium. Ordinals assigns a unique number to each satoshi and attaches additional data (text, images, code, etc.) to make each satoshi a unique NFT, a process known as "engraving". BRC-20, based on Ordinals, has also introduced a method for issuing homogeneous tokens similar to ERC-20. However, BTC script is not Turing complete and cannot implement complex smart contract systems like Ethereum. For example, the simplest transfer function for derivative assets based on the Ordinals protocol needs to include the following content in the script:

You can see that this is a pure text interaction. The Bitcoin network itself does not perform any computation or state settlement on the transaction content of BRC-20. The messages that users see, such as successful BRC-20 transfers, are the final results obtained by those nodes that recognize the Ordinals protocol after parsing and calculating the original script on the BTC chain.

If you only have 100 ORDI, but you write 10000 in the transfer quantity, you can still send this transaction to the Bitcoin network. However, the relevant nodes and browsers will not interpret it as a valid transfer.

Therefore, Ordinals essentially treats the Bitcoin network as an immutable network disk, with only metadata and operation declarations inscribed on the chain. However, all operation calculations and state settlements are located off-chain on the data indexing website's servers. This approach is almost identical to the project EverPay in the Arweave ecosystem.

Overall, Ordinals have the following issues:

1. State operation layer without unified consensus. The data parsed by different wallets, browsers, etc. may not be the same. Previously, there have been many cases where user assets have different display results on different wallets.

2. Dependent centralized Indexer infrastructure. From the perspective of blockchain standards, this application does not have strict security requirements and is unreliable.

3. Usage scenarios are limited. A series of complex DeFi activities in Ethereum cannot be completed based on simple Ordinals protocol. Even the current Ordinals transactions can only be completed through pending orders, instead of using popular AMM. Therefore, products like Ordinals seem to be better implemented on Ethereum.

4. Network Pollution. The operation form of Ordinals, such as thousands of users operating only $0.1 worth of value in a short period of time but paying $10 in transfer fees, is very similar to dust attacks in the eyes of BTC purists. In the eyes of these users or developers, BTC is mainly used for storage and transfer, and Ordinals activities seriously interfere with normal network operation.

5. Increased user usage costs. Various inscriptions have raised the transaction fees of the Bitcoin mainnet, which has affected other users. In addition, the new infrastructure introduced by BRC-20 and Ordinals requires users to understand and use new wallets, tools, etc.

Luke's Solution Approach

Faced with BRC-20 and Ordinals issues, Luke did not directly modify the consensus layer, but instead modified the Spam Filter (policy) module to make nodes reject Ordinals transactions when receiving P2P broadcast messages. In the policy, there are multiple isStandard() series functions to check whether various aspects of the transaction meet the standards. If they do not meet the standards, the transaction received by the node will be quickly discarded.

In other words, Ordinals can ultimately be linked, but most nodes will not put such data into the transaction pool, which will delay the transmission of Ordinals data to mining pools willing to package it on the chain. However, if a mining pool broadcasts a block containing BRC-20 transactions, the nodes will still recognize it.

Source: https://twitter.com/BenWAGMI/status/1732423859092247013

Luke has submitted policy modifications in the Bitcoin Knots client, and he also wants to add the same submission to the Bitcoin Core client. In policy.cpp, he added a parameter called g_script_size_policy_limit, which limits the script size in multiple locations.

Previously, there were no restrictions on the script size of Pay-to-Taproot (i.e. transaction types using Ordinals) in the client, but this has now been addressed.

其中，g_script_size_policy_limit has a default value of 1650 Bytes, which limits the scripts used in many Ordinals. The following image shows the size of a script related to NFT: