Introduction

The essence of the current Ethereum inscription is still Ordinals' old wine in new bottles, without a truly meaningful new paradigm. There are still security risks in ETHS. Although it is indeed more decentralized than Rollup, its withdrawal process still relies on a third-party notary/manager, which is at risk of theft. Obviously, ETHS is still mostly based on financial speculation, not that it can bring innovations that Ethereum Layer 2 cannot.

The recent popularity of BTC ecological inscription has driven developers of other chains to build similar systems. The implementation methods and achievable functions of the inscription system on different chains are slightly different, but they have some things in common:

1. The inscriptions all use the text information attached when transferring money to express the operation you want to complete . For example, write "Transfer 1 coin to XXX" in the information. Note that this information is in plain text and will not involve operations such as smart contract execution on the chain.

2. Developers will design a series of specifications and standards to standardize all text information.

3. The developer provides a set of Indexer indexers to collect the text information of all inscriptions on the chain and calculate the internal status of the inscription system. Indexer is an off-chain open source component that anyone can run.

BTC Ordinals has established a mechanism for issuing NFTs and tokens on BTC, which has also led to large-scale thinking about BTC L2. In this sense, we can consider Ordinals to have a certain cutting-edge and exploratory nature. However, Ordinals is limited by the architecture of BTC in terms of technology and product experience, and has also been criticized by OGs in the BTC community due to dust pollution and data occupation.

So, does it make sense to re-engrave the inscription on Ethereum? After all, Ethereum itself has complex smart contracts, and ERC20 and NFT are also inherent content on Ethereum; what impact will these inscription projects have on the Ethereum ecosystem? Will there be disputes and disturbances on BTC?

Technical implementation of Ethscriptions

Let's first take a look at the implementation of Ethscriptions, which is a well-known inscription project on Ethereum and mainly uses Calldata to operate.

Calldata is the raw input data transmitted in Ethereum transactions. It is generally used to transmit parameters required for smart contract interaction, but it can also be used to send text messages (messages, inscriptions, transfer notes, etc. for any purpose) to the EOA address. Input Data in the figure is calldata.

If you want to use Ethscriptions to engrave "Hello world" in the transaction, you need to construct a transaction containing the following calldata:

After the off-chain Indexer monitors this transaction, it will update the database and notify the user: a new inscription has been generated, and the inscribed content is Hello world. More complex content can also be placed in the inscription, such as base64 representing image information, etc.

Ethscriptions has currently passed 6 ESIPs (Proposals for improvement to the Ethscriptions protocol), similar to EIP proposals, to define the use of inscriptions in different scenarios. But these are only relatively basic inscription specifications, such as the format of inscription transactions initiated from EOA, contract emit events, etc.

Since Ethscriptions is a project on Ethereum, it can also use Ethereum's smart contracts to implement a certain degree of logic. It should be noted that interacting with smart contracts directly is not a recommended method by Ethscriptions.

Although the official NFT market is also implemented directly using smart contracts. According to the official documentation, what Ethscriptions wants to provide users is "decentralized and affordable computing services": stripping computing off-chain will significantly reduce the cost of using Ethereum.

Let’s explore the cost of calling smart contracts in detail, which can be divided into three parts:

·Base transaction cost: required for any Ethereum transaction, currently 21,000 gas.

·Data transmission cost (calldata): calldata is generally used to submit data and parameters for interaction with smart contracts. After EIP-2028 adjustment, each byte of calldata data generally consumes 16 gas (if the byte of data is 0, it consumes 4 gas).

·Contract execution cost: If the transaction calls a function in the smart contract, there will also be a computational cost based on the complexity of the function execution. For example, if status updates are involved (such as updating balance information in an ERC-20 contract), calling SSTORE will consume up to 5,000~20,000 gas.

Let's take a very simple USDT transfer transaction as an example. This transaction consumed a total of 63197 gas, and the calldata is:

Let’s parse the calldata and how much gas it will cost:

·Ethereum calldata is in hexadecimal format, that is, every two digits is one byte (16^2 = 2^8). The 0x at the beginning means that the data is in hexadecimal.

·The a9059cbb after the beginning 0x is the function selector, occupying 4 non-zero bytes.

·The next 32 bytes are the address, preceded by 12 bytes of zero (because the Ethereum address is 20 bytes, zeros are left-padded here to 32 bytes), and 20 bytes of non-zero address data.

·The last 32 bytes represent the amount, with a large number of zeros padded on the left. There is 3b9aca00 non-zero data at the end, and 4 bytes are non-zero.

·So, there are 28 non-zero bytes and 40 zero bytes

Therefore, calldataGas = 28 * 16 + 40 * 4 = 608 gas .

The total gas is 63197, minus the calldata cost and fixed cost, the smart contract calculation cost for executing this transaction is 41589 gas. The contract operation cost accounts for the majority of this transaction, and this is just a simple transaction. The cost of contract operation will further increase in complex transactions.

Putting the computing process off-chain will indeed significantly reduce the cost of use: If you don’t want to call the smart contract directly on the chain, you can send a request to an agreed EOA address.

0x00000000000000000000000000000000000face7 Send transaction data

In the calldata of the transaction, declare which contract you want to call and the corresponding input parameters. Since the above address is an EOA account and does not have a contract code, the operation mentioned above will not trigger a calculation task on the chain, but only publishes a message.

Off-chain, after Indexer listens to this message, it will analyze it and figure out which contract on the ETH chain the initiator of this message originally wanted to call. Then Indexer will calculate the result of the contract call off-chain.

So if the offline Indexer wants to perform inscription and smart contract operations, it must have a set of STF (state transition function) rules and runtime. The more complicated ones can be called virtual machines VM. Ethscriptions launched its own VM in ESIP-4 - Ethscriptions VM, which was later renamed Facet VM.

Facet - kind of like a coprocessor

Facet defines itself as a cheap, easy-to-use, secure, and decentralized computing platform. Monitor the calldata of Ethscriptions on Ethereum, pull it to the VM for calculation, and finally return the result to the user. Facet consists of several key components:

·Facet VM , a set of VM written in ruby, is responsible for monitoring ETHS transactions, parsing calldata, and performing operations.

·Rubidity , the smart contract programming language in Facet, has a certain similarity with Ruby, and retains many usages and concepts of solidity, so that developers can get started quickly.

·Dumb Contract , a contract that runs on Facet. This name is full of humor. Some people are right to call it a dumb contract. The word dumb itself is a pun, and dumb can describe the silent process of this kind of contract work. But on the other hand, according to the official saying "So dumb, they're smart", a fool is as smart as a fool, which strongly contradicts the smart contract, so it is okay to call it a dumb contract.

The stupid contract itself will not actually be deployed on Ethereum, but its code will be published to the ETH chain in the form of calldata. The following is an example of Facet calling a dumb contract:

A minting transaction to the EOA black hole address

0x0000000000000000000000000000000000face7 Submit the calldata in the picture below and declare that you want mint tokens and the amount. This is actually the same as Ordinals or BRC-20:

Let's take a look at the intuitive comparison between Rubidity and Solidity, as shown in the figure below.

Although it is officially said that Rubidity has concepts and structures similar to Solidity, allowing developers to get started quickly. But we know that this actually has a certain negative impact on the development of the developer side. And currently Facet VM only supports stupid contracts in the official whitelist, which shows that the official does not have full confidence in this language and VM. I don't know whether reusing EVM is officially more difficult in terms of engineering technology than developing a new VM and a new language. But one thing is for sure: a new language, a new contract, a new ecology, and a new way of using Ethereum do have enough gimmicks.

Facet attacks smart contracts

The Facet document made the following explosive comments about Ethereum and smart contracts: "Smart Contracts are considered to be the feature above all others that makes Ethereum special, and yet Facet's thesis is that Smart Contracts are Ethereum's biggest design flaw."

They believe that Ethereum's smart contract is the biggest design flaw, because as long as the input (calldata) is given to the contract itself, its output is certain, so operations should not be performed on the chain, which wastes money for no reason. Combined with what Ethscriptions calls "decentralized and affordable computing services", it is obvious that Ethscriptions and Facet very much want to create a market impression that "we are creating a new Ethereum expansion paradigm and usage method", but in fact ETHS itself Some of the technical solutions are not very reliable.

From a product perspective, Facet can indirectly call smart contracts off-chain, and has its own off-chain stupid contract system. Indeed, the official is fulfilling its slogan.

But from an economic perspective, there is no free lunch. Storage and computing certainly cost money. So how does Indexer solve this part of the cost? There is no official explanation, so we can imagine:

·Charge users. For example, the NFT market charges fees from buyers, but we cannot look at the long-term charging method of an L2-like network based on a simple project charging model.

·Get rich by relying on your own ecological hype. Of course this is feasible, but it is only a short-term solution to make the project side happy. If Ethscriptions wants to become a new Ethereum paradigm, Indexer must have a long-term, network-based economic mechanism to ensure its operation.

·If it is an unprofitable Public good, which institutions will donate it? I think at least the Ethereum Foundation will not be particularly active, because Ethereum itself has a very good solution - Rollup .

The root cause of Facet and stupid contracts

If we just need a simple form of Ethereum inscriptions, then only the Ethscriptions project is enough. So why did its ESIP-4 proposal spawn Facet?

Because the inscription system cannot be used for complex transaction logic. We can examine the operating logic of Ethscriptions' official NFT market contract, which uses a pending order mechanism.

If you want to recharge the Inscription NFT into the contract, you only need to write the calldata as the EthscriptionId of the Inscription and call the market contract. Since this operation deliberately chooses an invalid function call form, fallback() will be triggered by default.

Eventually, an event called PotentialEthscriptionDeposited will be thrown on the Ethereum chain. After the Indexer node listens to this event off-chain, it will locally transfer the ownership of the NFT to a market contract.

In order to save gas, the ETHS trading market does not store some parameters of the seller's order, such as price, deadline, etc., in the ETH contract. Instead, it is stored offline in the form of messages. Visual inspection should be stored in the dApp server. superior. After the buyer monitors this news, he can issue the buyWithSignature() command to propose a purchase.

It is normal to use the pending order mechanism for NFT, because NFT itself is not homogeneous. So if it is a homogenized token inscription, can the AMM mechanism of the contract be used? The answer is no. The status of the inscription NFT or token is not on L1, which is similar to Ordinals and BRC-20. This is completely contrary to the propaganda of some communities. Everyone needs to pay attention to the screening. Inscriptions are not the real assets on the ETH chain. We cannot say that the calldata of generated assets is on L1, and operation instructions can be declared on L1, which is called native assets on L1. Otherwise, the L2 native assets on Rollup can also be called L1 assets, because the calldata of Rollup are all in On L1. Obviously, calling this asset an L1 native asset is ridiculous.

You may be wondering, isn’t the above transaction using smart contracts? Why do we say that the contract cannot read and operate the inscription? In fact, this contract is only responsible for collecting money, transferring money, and throwing events for the Indexer node under the chain to monitor and trigger corresponding operations. In the eyes of Ethereum EVM, the status of things like inscriptions cannot be restored in the "world state" of Ethereum's database that specifically stores states, and contracts cannot reference it.

No matter what form the asset is, whether it is a token, NFT or anything weird, I can give a very simple standard to identify L1 assets and L2 assets: whether its state is on the "world state" of Ethereum After restoration, can L1's EVM reference, call, query, and modify the status of the asset? If not, then it is not an L1 asset.

So you can also see that the name of the recharge event is PotentialEthscriptionDeposit, which is "possible inscription recharge", rather than a deterministic recharge, because the contract cannot determine whether the inscription exists or verify its authenticity. If you place an order for a non-existent inscription, or someone else's inscription, the contract will not reject you, but Indexer will not include your behavior.

Therefore, the inscription system can only implement this simple pseudo-contract logic, and pending orders are one of them. The essence of a pending order is that both parties to the transaction agree with each other on the information provided by the other party under a certain rule. In fact, it can be expressed in plain text without a smart contract, which is similar to the principle of inscriptions.

We can imagine how to complete the above process without using smart contracts: the seller engraves a message in an ordinary transaction, and the person who transfers me 1ETH with the note 123 can get my inscribed NFT numbered 123. This only requires Indexer to support this logic. When it detects that someone transfers 1ETH to the seller and adds ABC, it can transfer it directly in the off-chain Indexer database.

Of course, this example will actually cause some problems, such as repeated transactions that may result from multiple people snapping up an NFT. The seller receives multiple transfers, but in the end the NFT can only be assigned to one person by Indexer. This should also be one of the reasons why the official clearly criticizes smart contracts, but uses contracts to realize the NFT market. Therefore, you should also be able to understand that the official statement that calling smart contracts through Facet without calculation is unreliable propaganda.

Of course, pending orders can theoretically use plain text instead of contracts, but the relatively complex logic of AMM must use smart contracts, because it requires not p2p recognition from both parties, but contract recognition. The contract, which acts as a reliable reviewer, needs to check basic information such as balance and liquidity, and perform calculations. Any asset data it needs must be available to the contract.

AMM is just a relatively simple form of DeFi, and any other complex logic cannot be realized only on Ethscriptions. This is also the reason why Facet was launched - the first priority of Facet is cross-domain! It is actually an L2, but it does not have a block structure, so we don’t call it cross-chain but cross-domain. When all L1 assets are cross-domain to Facet, there will be no problem of cross-domain inability to call. All off-chain assets can be operated off-chain using dumb contracts, thus supporting complex contract logic.

Comparison with Rollup

Through the long discussion above, you should be able to find that the Ethscriptions solution is somewhat similar to Rollup. But this is just "similar". If strictly speaking, it can only implement a subset of Rollup's core functions. The incomplete functions bring fatal injuries to its narrative, or put users in serious threats.

Rollup is a complex system, which we will not expand on here. It has some things in common with Ethscriptions:

- All submit L2 transaction data calldata on Ethereum.

- All operations are processed off-chain.

The commonalities are so clear that we need to demonstrate the differences in detail.

Rollup batch submit calldata

In most cases, users in Rollup will not submit transactions directly to L1, but submit them to the off-chain sequencer. The sequencer will sort all transactions, package and compress them, and send the calldata to L1 in batches. In this way, the calldata of multiple users is submitted in one transaction, which can dilute the basic cost of 21,000 gas.

There is no such mechanism in Ethscriptions, all users submit calldata directly to L1.

Let's use the USDT example above (608 gas for calldata), assuming that 100 users initiate 100 transactions, and roughly calculate the cost difference between the two very loosely:

·Inscription users each need to pay 21608 gas (608 + 21000). The rest of the operation is not paid because the operation is off-chain.

·Rollup users each pay 818 gas ((608*100+21000)/100). The operation part is the same as above.

Of course, each Rollup user also needs to pay L2 computing and storage fees to the sorter, but they are much cheaper than L1 and can be ignored in this example. In addition, rollup also requires some additional special fields to increase the size, but at the same time it has better data compression, which we will not expand here.

Through this rough estimation, we can find that Ethscriptions has no cost advantage over Layer 2. In addition, I have seen something like "4000 inscriptions can be transferred in batches in the project's community promotion, which costs about 0.11ETH, and each transfer only costs 0.05U on average." This proves that the use of Ethscriptions is very cheap. This is actually all The principles and interaction details of ETHS are not clarified.

Off-chain pre-confirmation

Due to the off-chain sequencer, Rollup's user requests can be pre-confirmed within 1 second. This is much better than the 12 seconds or more the inscription system takes on L1, and the UX is much better. Of course, inscription supporters can also argue that the finality of such transaction results is unreliable until the calldata is submitted to the ETH chain.

Censorship Resistance and Decentralization

Users in Rollup may be censored by off-chain sequencers, but Ethscriptions cannot censor users. However, a well-designed Rollup will have a forced collection function to resist the sorter's review, and ultimately the sorter will not have the power to review users at all.

Therefore, when users use Rollup, they can also use it directly on L1, bypassing the sequencer. Rollup gives users different options. They can use a faster sorter or directly use L1. However, Ethscriptions can only use L1, which does not give users a free choice.

In addition, Ethscriptions criticized Rollup's sorter for being centralized. But Indexer itself is also a highly centralized component. Ethscriptions explains that Indexer is not centralized because anyone can run and verify it, but in fact most people do not run nodes themselves. Therefore, ETHS will only show its more decentralized side than Rollup under extreme circumstances. After all, the Rollup sorter may be down or malfunction, but ETHS can continue to operate as long as there are community members running multiple Indexers.

Profit model

It is impossible for any project to generate electricity with love. Projects with long-term development must seriously consider the issue of profit model. Whether it is a combination of centralized entities or decentralized entities, they must be profitable to be able to protect network security in the long term.

Rollup's sorter has a clear profit model: charging more gas, extracting MEV, etc. The sequencer is motivated to keep the network functioning properly. Ethscriptions Since users submit calldata directly to L1, Indexer is actually not easy to charge.

Developer friendliness

Most of Rollup's contract development languages, tool chains, etc. can directly use Ethereum, and developers can seamlessly migrate to Rollup. None of this exists in Ethscriptions, new Rubidity needs to be mastered, new scans need to be built, new VMs need to be familiar, etc. Of course, these resistances, in turn, are also opportunities for pioneering that may arise when a new ecosystem develops.

Withdrawal and status settlement

This is Facet's fatal problem. We know that Rollup not only submits calldata (input) to L1 in batches, but also regularly submits the state settlement (output) after N operations to L1. ZKR and OPR have different proof methods to determine whether the relationship between input and output is correct. Regardless of the proof method, the final referee is the contract on L1. The output and input on Rollup are traceable and cannot be faked.

So what is the use of state settlement? Used for cash withdrawal, that is, fund withdrawal from L2 to L1. After the state on L1 is released, we can use Merkle Proof and other methods based on the state root to prove that my withdrawal request on L2 is included in the state root. After the contract is verified to be correct, the assets can be released on L1.

Facet does not have a state settlement mechanism, so it cannot achieve permissionless, decentralized withdrawals from L2 to L1. As mentioned above, he needs an L2 layer to execute more complex contract logic. Such as his AMM Swap FacetSwap.

We can see that in FacetSwap (a dex built using stupid contracts on Facet), there are clearly two actions: deposit and withdrawal. Generally, Swap does not allow deposits and withdrawals, because Facet requires you to cross domain before you can use it.

In Facet, recharging requires locking L1 funds on the L1 bridge contract and emitting the corresponding event ethscriptions_protocol_CreateEthscription for Indexer to index. This is consistent with other L2 recharge methods.

Withdrawals have serious security issues. Since there is no status settlement mechanism on Facet, contracts cannot be used on L2 to L1 to automatically determine whether a withdrawal is valid. So what method does Facet use? The administrator release, or witness mechanism, is similar to the Axie bridge that was stolen before.

Let’s take a look directly at Facet’s bridge. The address is:

0xD729345aA12c5Af2121D96f87B673987f354496B.

HashedMessage is a message signed by the signer, which contains some contents of the withdrawal. signer is a default administrator address. Because there is no status settlement, no verification can be done, such as whether the account has so many coins on L2. Therefore, all funds on the contract can be withdrawn based solely on the signature of the signer, whether the project party commits evil or a hacker attacks to obtain the private key.

In Rollup, there is no need for witnesses to release assets; in side chains, if witnesses want to be more decentralized, they can select a part from their own consensus system as agents and use pledges and other methods to provide certain economic deterrence. Curb evil.

In Ethscriptions and Facets, nothing. It is simply and unabashedly an administrator address. This is probably too careless for an L2-like project that frequently shouts "smart contracts are design flaws," "Rollup is centralized," and "we are a new generation of computing platform." Obviously, he still has many flaws, but we can stay on the sidelines, although these flaws are not easy to make up for and may also exist in Bitcoin Layer 2.

Summarize

There is a certain amount of "false propaganda" in the current Ethscriptions. Here are a few key points:

·The assets on Ethscriptions and Facet are not assets issued on L1.

·In order to have complex contract capabilities, the L2 entity Facet was evolved, but it has great financial security risks.

·The official claim is to decompute contracts on L1, but they don’t even use their top applications.

·Ethscriptions is similar to a Rollup with very incomplete basic functions. It is neither as cheap and fast as Rollup nor as safe as Rollup. Whatever it can achieve, Rollup can achieve. It cannot provide the very important functions that Rollup can achieve.

·If he wants to solve the above problems, he needs to develop a state settlement mechanism, coupled with a sequencer and L2 blocks, then it will eventually become a Rollup.

Ethscriptions took advantage of the popularity of BTC inscriptions and relied on concepts to hype old wine in new bottles, but it has not yet discovered a new paradigm. The current ETHS is still mainly based on financial speculation, rather than saying that this product itself can bring something that Ethereum Layer 2 does not have. The long-term value of this kind of thing obviously still needs to be explored, but in its current form, ETHS has already shouldered the "unbearable weight of life", and his slogan is far from its actual effect.