
EthsはLayer2ですか?Ethscriptions Virtual Machineとその位置づけを一文で理解する
TechFlow厳選深潮セレクト

EthsはLayer2ですか?Ethscriptions Virtual Machineとその位置づけを一文で理解する
Ethscriptionsは、ユーザーがスマートコントラクトのストレージや実行をバイパスして、より低いコストでイーサリアムL1上で情報を共有し、計算を実行することを可能にする。これは、イーサリアムのコールデータに決定性のあるプロトコルルールを適用することで状態を計算するものである。
執筆:Arrow、Go2Mars Capital 創設者、Sleipnir Research パートナー
「Ethscriptionsとは、ユーザーがより低コストでイーサリアムL1上で情報を共有し、計算を実行できるようにするプロトコルであり、スマートコントラクトのストレージや実行を利用せずにこれを実現しており、イーサリアムの呼び出しデータ(calldata)に決定論的なプロトコルルールを適用して状態を計算する。」
私が初めてethsについて知ったのは今年の8月中旬でしたが、その時点ですでに新しい概念ではなく、さまざまなインスクリプションが乱立しており、多くの人々はこれをBRC-20の模倣と見なしていました。また当時のTwitterでは、このコンセプトに対する現在のような熱狂はまったくありませんでした。今日になって各位が「ethsはLayer2なのか」と議論するのを見て、ようやく関心を持つようになりました。
さまざまなメディアを探しましたが、Ethscriptions Virtual Machine(ESC-VM)という概念に関する解説記事は見当たりませんでした。そこで、技術的詳細に深入りせず、なるべくシンプルに分かりやすく、これが一体何なのかを説明する記事を書くことにしました。
Layer2
まずは簡単にLayer2について整理します。この概念については多くの方がご存じでしょう。以前私はOP Rollup、ZK Rollupといった主要なLayer2スケーリングソリューションや、OP Stackをチェーン展開用SaaSツールとして扱う一連の記事を書いていました。
ここでは基礎的な事項は省略します。Layer2の核心目的はスケーリングと取引コストの削減です。
なぜなら、膨大なノードが限られたブロックスペースを争っているため、イーサリアムエコシステムの急速な発展に伴い、より多くの実行・計算が必要となり、チェーン上の取引が極度に混雑し、ガス代が高騰してしまうからです。
L2を実現する方法は多数あり、進化し続けています。初期のステートチャネル、Plasma、Validium、そして現在主流のOptimistic-Rollup、Zk-Rollupなどがあります。
Rollup方式は、取引の計算と具体的な状態変更をオフチェーンで行い、オンチェーンでは取引とバッチ処理された最終状態の要約を処理・検証することで、イーサリアムの混雑を効果的に緩和します。
しかし当時、私たちはethsをLayer2の解決策として、あるいは予備案としてさえも考えていませんでした。なぜなら、当時のethsは単なるイーサリアム上のインスクリプションプロトコルに過ぎず、特に目立つ特徴がなかったからです。
その後のアップデートにおいて、Ethscriptionsプロトコルを改善する提案であるESIP-4: The Ethscriptions Virtual Machineが、多くの点で状況を根本的に変えました。
Ethscriptions(ETHS)
Ethscriptionsは、ユーザーがより低コストでイーサリアムL1上での情報共有および計算実行を可能にするプロトコルです。これはスマートコントラクトによるストレージや実行を回避し、イーサリアムの呼び出しデータに決定論的なプロトコルルールを適用して状態を計算することによって実現されています。
コストが低い理由は、オンチェーンデータの保存にスマートコントラクトではなくイーサリアム取引のcalldataを使用しているためであり、これにより自然とコストが削減されます。また、OPにおける楽観的検証やZKにおける有効性証明などの検証コストも不要になります。
もちろん、Ethscriptions自体について語ることはたくさんありますが、ここでは重点的にThe Ethscriptions Virtual Machineについて話します。
ESIP-4: The Ethscriptions Virtual Machine
Ethscriptions仮想マシン(ESC-VM)は、ethsを改良する草案ESIP-4の中核となる内容であり、この提案による機能拡張こそが、ethsをインスクリプションの投機的ブームから脱却させ、実用的な機能を持たせる契機となりました。
ホワイトペーパーにある一文から、その開発目的が明確になります:
ESC-VMの目的は、スマートコントラクトやL2を置き換えることではなく、分散化を最優先しつつ、いかに低コストな計算能力を提供するかを考えることにある。
ESIP-4の草案では、Ethscriptions仮想マシン(ESC-VM)という新たなプロトコルを導入しています。
ESC-VMにより、ethsはコンピュータ命令として機能可能になり、プロトコルの機能が強化されます。これらの命令を通じて、ユーザーは「ダムコントラクト(Dumb Contracts)」と呼ばれる特殊なプログラムとやり取りできます。
従来のETHSインスクリプションでは、画像などを「刻む」ためにイーサリアムの「呼び出しデータ(Calldata)」機能を利用していました。Calldataとは、スマートコントラクトの呼び出し時に提供されるデータのことです。これが、コントラクトストレージを使うよりも安価な理由です。
ESIP-4のダムコントラクトでは、「デプロイ(新規コントラクト作成)」や「呼び出し(既存コントラクトの状態変更関数の実行)」といったコマンドを実行できます。このプロセスもインスクリプション形式で保存され、取引はcalldataフィールドとしてオンチェーンに記録されるため、EVMの実行およびストレージコストを回避できます。
ESC-VMはダムコントラクトにEVMに類似した環境を提供し、その機能をスマートコントラクト並みに高めます。つまり、ESC-VMは実質的にEVMと同等と考えてよいでしょう。
このプロセスでは、EVMの実行・ストレージコストを回避するため、ダムコントラクトはスマートコントラクトよりもはるかに安価であり、大幅なコスト削減が可能です。これでまさにLayer2の核心目的を達成しているではありませんか。
ただし、違いも当然存在します。次にESC-VMと既存のLayer2との相違点を見ていきましょう。
ESC-VMと既存Layer2の違い(ESC-VMはL2か?)
ESIP-4のホワイトペーパーでは、この点について明確に言及されており、その理由も示されています。
The ESC VM is not an L2. One way to understand this is to consider the two notions of consensus that exist on Ethereum:
(1)各ブロックにどの取引が含まれ、どのような順序であるかに関する合意(consensus)。
(2)上記(1)がEVMの状態に与える総合的影響に関する合意。
Ethscriptionsの主な思想は:
(1)に注力して完全に分散化されたシステムを構築することです。ブロックチェーンの状態は明確かつ決定論的にEVMの状態を定義しており、ブロックチェーン自体があれば誰でも独立して正確にEVMの状態を検証できます。
一方で、(1)の「真実性」を検証することは不可能です。なぜならこれは非決定的なプロセスであり、「正しい答え」が存在しないためです。
(1)と(2)をイーサリアムプロトコル内で統合するのは理想的ですが、多くのアプリケーションにとってこの組み合わせは高価すぎます。Ethscriptionsはイーサリアムプロトコルの一部である(2)を犠牲にし、決定論的な状態計算を容易にするツールを構築しています。
対照的に、L2は逆のアプローチを取ります。L2の状態はブロックチェーンの文脈内で管理されているため、Ethscriptionsエコシステムの状態よりも検証が容易です。しかし、L2の検証は条件付きです。「Xという取引がYという順序でブロックに含まれているならば、ブロックチェーンの状態はZに変化すべきだ」と推論できますが、L2システム内ではXとYが正しいかどうかを検証する手段がありません。
一般に、XとYが公正になるのは、それがL2運営組織の目標と一致している場合に限られます。L2を運営する企業は、L2ユーザーの利益よりも株主の利益を優先する責任を負っています。極端な場合、L2が企業の利益に合わなくなれば、サービスは停止される可能性があります。
Ethscriptionsが表現する理念は:
非決定的な問題(例:ブロックへの取引包含や取引順序)に関して分散型の合意が形成されていない限り、ブロックチェーンは決して安全とは言えない。ESC-VMの目的は、分散性と安全性を、EVMに近い機能と組み合わせることにあるのです。
課題点
現時点では、ダムコントラクトにはいくつかの重要な課題があります。
① ダムコントラクトは直接支払いができず、橋渡し(ブリッジ)が必要;
② ESIP-4では任意のダムコントラクト作成を許可していない。信頼なしでデプロイ・実行は可能だが、コード自体はESIPプロセス内の他のEthscriptionsプロトコルルールとともに定義される;
③ 0x8699氏(@ethan0x8699)が指摘した非常に重要な問題:ethsは極度にindexerに依存しているが、そのメカニズムは十分に重視されていない。この問題については別途深掘りした記事を書くべきであり、ここではこれ以上触れません。
本稿はホワイトペーパーおよび諸氏の議論を参考にまとめたものであり、投資勧誘を意図するものではありません。誤りや漏れがある場合はすべて私の責任です。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News













