
Is Eths a Layer2? A Comprehensive Guide to the Ethscriptions Virtual Machine and Its Positioning
TechFlow Selected TechFlow Selected

Is Eths a Layer2? A Comprehensive Guide to the Ethscriptions Virtual Machine and Its Positioning
Ethscriptions allow users to share information and perform computation on Ethereum L1 at a lower cost, bypassing the use of smart contracts for storage and execution by applying deterministic protocol rules to Ethereum call data to compute state.
Author: Arrow, Founder of Go2Mars Capital, Partner at Sleipnir Research
"Ethscriptions is a protocol designed to allow users to share information and perform computation on Ethereum L1 at lower cost. It bypasses the use of smart contract storage and execution by applying deterministic protocol rules to Ethereum call data to compute state."
I first learned about eths in mid-August this year. By then, it was no longer an emerging concept—various inscriptions were already everywhere, and many people viewed it merely as a copycat of BRC-20. Back then, there was certainly no enthusiasm on Twitter for the idea like we see today. It wasn't until I saw various experts discussing whether eths qualifies as a Layer2 that I became truly interested.
I looked around various media outlets but couldn’t find any beginner-friendly explanation of the Ethscriptions Virtual Machine (ESC-VM) concept, so I decided to write this article to clarify what it actually is—keeping technical details to a minimum and explaining things as simply and clearly as possible.
Layer2
Let’s briefly recap Layer2—a concept most readers should already be familiar with. I previously wrote a series on mainstream Layer2 scaling solutions such as OP Rollup and ZK Rollup, as well as a dedicated piece on OP Stack as a chain-launching Chain SaaS tool.
We won’t rehash foundational topics here. The core purpose of Layer2 is scalability and lowering transaction costs.
On-chain nodes compete for limited block space. As the Ethereum ecosystem rapidly grows, more execution and computation are required, leading to severe network congestion and gas fees skyrocketing.
There are many approaches to implementing L2, and they continue to evolve. Early solutions included state channels, Plasma, Validium; today’s popular ones include Optimistic Rollup and ZK-Rollup.
Rollup schemes perform transaction computation and state changes off-chain, while posting transaction batches and final state summaries on-chain for verification—effectively alleviating congestion on Ethereum.
At the time, however, we didn’t consider eths as a Layer2 solution, nor even as a potential alternative. This was because eths was initially seen only as an inscription protocol on Ethereum, without anything particularly special about it.
That changed fundamentally with an update: a proposal to improve the Ethscriptions protocol—ESIP-4: The Ethscriptions Virtual Machine.
Ethscriptions (ETHS)
Ethscriptions is a protocol designed to enable users to share information and execute computations on Ethereum L1 at lower cost. It achieves this without relying on smart contract storage or execution, instead applying deterministic protocol rules to Ethereum call data to calculate state.
It's cheaper because it uses Ethereum transaction call data rather than storing data via smart contracts on-chain—naturally reducing costs—and also avoids validation expenses associated with mechanisms like OP’s optimistic proofs or ZK’s validity proofs.
Of course, there's already a lot to say about Ethscriptions, but our focus here will be on The Ethscriptions Virtual Machine.
ESIP-4: The Ethscriptions Virtual Machine
The Ethscriptions Virtual Machine is the central component of ESIP-4, a draft proposal to enhance eths. It is precisely this proposal’s functional expansion of ETHS that moved it beyond mere inscription hype, adding practical utility beyond speculative value.
As stated in the whitepaper, we can clearly understand its development goal:
The goal of ESC-VM is not to replace smart contracts or L2s, but to prioritize providing low-cost computational capability in a decentralized manner.
The ESIP-4 draft introduces the concept of the Ethscriptions Virtual Machine (ESC-VM), a new protocol built atop Ethscriptions.
ESC-VM enables ethscriptions to function as computer instructions, enhancing the capabilities of the Ethscriptions protocol. These instructions allow users to interact with special programs known as Dumb Contracts.
In earlier ETHS inscriptions, "engraving" images leveraged Ethereum's "call data"—the "calldata" field—which refers to data provided during calls to smart contracts. This is the key reason why it's cheaper than using contract storage.
With ESIP-4’s dumb contracts, commands such as deployment (creating new contracts) and invocation (calling state-changing functions of existing contracts) can now be executed. This process is stored via inscription format, with transactions recorded on-chain within the calldata field—bypassing both EVM execution and storage costs.
ESC-VM provides dumb contracts with an environment similar to the EVM, enabling their functionality to parallel that of smart contracts—in essence, ESC-VM can largely be considered equivalent to the EVM.
Because this approach bypasses EVM execution and storage costs, dumb contracts are significantly cheaper than smart contracts, greatly reducing overall costs—this directly addresses the core objective of Layer2.
However, important differences remain. Let’s now examine how ESC-VM differs from existing Layer2 solutions.
Differences Between ESC-VM and Existing Layer2s (Is the ESC-VM an L2?)
The ESIP-4 whitepaper explicitly addresses this point and provides reasoning.
The ESC VM is not an L2. One way to understand this is to consider the two types of consensus that exist on Ethereum:
(1) Consensus over which transactions are included in each block and in what order.
(2) Consensus over the aggregate impact (1) has on the state of the EVM.
The main idea behind Ethscriptions is:
To build a fully decentralized system by focusing on (1), since the blockchain state explicitly and deterministically defines the EVM state. With just the blockchain itself, anyone can independently and exactly verify the state of the EVM.
On the other hand, verifying the “authenticity” of (1)—i.e., whether specific transactions were actually included and correctly ordered—is impossible, because this is a non-deterministic process with no single “correct answer.”
Combining (1) and (2) within the Ethereum protocol is ideal. However, for most applications, this combination is too expensive. Ethscriptions sacrifices part of the Ethereum protocol—specifically (2)—and builds tools to make computing deterministic states convenient.
In contrast, L2s take the opposite approach. Since L2 state is managed within the context of the blockchain, it is more convenient to verify than the state in the Ethscriptions ecosystem. However, L2 verification is conditional: it says that given transaction X is included in a block ordered Y, we can infer the blockchain state should change to Z. But in an L2 system, there's no way to verify whether X and Y themselves are correct.
In general, X and Y are only fairly determined when doing so aligns with the business interests of the organization operating the L2. The company running the L2 bears fiduciary duties to shareholders that may outweigh the interests of L2 users. In extreme cases, if maintaining the L2 no longer serves corporate interests, it could be shut down.
The philosophy represented by Ethscriptions is:
A blockchain cannot be considered secure if there is no decentralized consensus on non-deterministic issues such as block inclusion and transaction ordering. The goal of using ESC-VM is to combine decentralization and security with functionality approaching that of the EVM.
Existing Issues
Currently, Dumb Contracts face several pressing issues.
① Dumb contracts cannot make direct payments and require bridging;
② ESIP-4 does not allow arbitrary creation of dumb contracts. While dumb contracts can be deployed and executed trustlessly, their code is defined collectively alongside the rest of the Ethscriptions protocol rules within the ESIP process;
③ A critical issue raised by 0x8699 (@ethan0x8699): eths is highly dependent on indexers, yet the mechanism doesn’t adequately incentivize or emphasize them. Given the depth of this topic, it deserves its own dedicated article, so we won’t explore it further here.
This article synthesizes insights from the whitepaper and discussions among experts. It does not constitute investment advice. Any errors or omissions are my responsibility.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News













