Inscription gained a sudden surge in popularity in late 2023, which caught many blockchain developers off guard. This article title borrows the Human Instrumentality Project concept from the Japanese anime Neon Genesis Evangelion to make the inscription technology beneficial to the blockchain smart contract.
The inscription uses off-chain computation to enable Bitcoin to achieve some of the same functionality as ERC20 tokens. However, this approach has limitations, such as the difficulty of implementing whitelisting and administrator features. As a result, the market has embraced inscription as a "fair launch" alternative to ERC20 tokens.
This article proposes some improvements to the Inscription technology to explore whether it can be used to create more interesting blockchain technologies.
Putting rules on-chain
The main criticism of the Inscription technology comes from the centralization of the Inscription system. The Indexer comes from a third party to assign new rules to Bitcoin transactions. Different results will occur if multiple parties use different rules to interpret Inscription transactions.
One obvious way to address this is to write the Indexer program to the chain. This is an expensive operation in Bitcoin, but it is relatively simple to implement in a newly designed blockchain.
After the rules are put on-chain, we will find that the gap between Inscription and smart contracts is shrinking. The verification of Inscription transactions becomes decentralized because the rules are the same. However, what are the remaining differences?
First on-chain, then verify
The smart contract mode is to verify the execution first, then record it on-chain. If an NFT has a total supply of 100, the first 100 mint operations will be successful, and the 101st mint operation will fail. If the contract is implemented correctly, the 101st mint operation should not charge a transaction fee and should not be written into the block.
Inscription is different because miners do not need to worry about whether the 100 mint quotas are exhausted when packing transactions. They only need to write the transactions into the block in order without executing the transaction or verifying the legality of the transaction. This greatly reduces the burden on miners:
No need to run a virtual machine
No need to keep and access to the smart-contract global state
Of course, the negative impact is also great. The transactions sent by users may not be successful. For example, if a user only has 10 USDT and tries to transfer out 15 USDT, the miner will process the transaction, and the transaction fee will also be charged, but the transaction is invalid. The user must verify whether it is successful himself.
Delayed computation of state
To summarize the Inscription model, we get delayed state computation, first on-chain, then verify.
If we change the existing blockchain to this mode, can we significantly increase the throughput of the blockchain? Since such a blockchain does not need to consider the size of the state and the efficiency of the virtual machine execution in the consensus stage, its speed is extremely fast.
Focused contract computation
As we all know, smart contracts blockchain has a big global state, and all nodes need to compute all transaction inputs. The computing speed of “world computers” is far from the needs of all mankind. However, it is possible to focus on ERC20 transfer contracts, SWAP, and other DeFi applications. The delayed computation means that we don't need to compute all the transactions before the consensus.
Let some nodes focus on USDT and related contract state calculations is possible. For example, the SWAP: usually, a SWAP needs two ERC20 contracts to participate so that a node can focus on the state calculation of a SWAP pool and the two dependent ERC20 contracts. The other nodes can work on the USDC related transactions.
Inscription smart contract blockchain
Based on this, we designed a smart contracts blockchain driven by the inscription technology. Its core has two points: 1) put the indexer program rules on the chain and 2) first consensus transaction inputs, then calculate state.
However, before implementation and testing, we don't know what will happen to this idea? Welcome to give us some comments.