イーサリアムインスクリプションETHSの技術解説：本質は金融的投機であって、製品革新ではない

2023.12.15

共有先

TechFlow厳選深潮セレクト

イーサリアムインスクリプションETHSの技術解説：本質は金融的投機であって、製品革新ではない

EthscriptionsはBTCのインスクリプションブームに乗って、概念の投機により古くからのやり方を新しい瓶に詰め直したが、まだ新たなパラダイムを切り開けていない。

2023.12.15 - 10:54:46

Web3業界の深掘り報道に専念し潮流を洞察

執筆：霧月、Geek Web3

導入：現時点でのイーサリアム・インスクリプションは本質的にOrdinalsの新瓶旧酒であり、真に意味のある新しいパラダイムを生み出してはいない。ETHSには依然としてセキュリティリスクが存在する。確かにRollupよりも分散化されているが、引き出しプロセスは依然としてサードパーティの証人／管理者に依存しており、盗難リスクがある。明らかにETHSは現時点で金融的な投機が主目的であり、イーサリアムLayer2が提供できない革新をもたらすというわけではない。

最近のBTCエコシステムにおけるインスクリプションの人気に伴い、他のチェーンの開発者たちも同様のシステム構築を進めている。異なるチェーン上のインスクリプションシステムの実装方法や機能は若干異なるが、共通点もある：

インスクリプションはすべて、送金時に付加されるテキスト情報を操作内容の表明に利用している。例えば、「XXXに1コインを送る」という記述を行う。ただし、これらの情報は純粋なテキストであり、スマートコントラクトの実行などチェーン上での処理とは関係しない。
開発者は一連の仕様と基準を設計し、すべてのテキスト情報を標準化する。
開発者がIndexer（インデクサー）を提供し、チェーン上のすべてのインスクリプションテキスト情報を収集して、システム内の状態を計算する。Indexerはチェーン外のオープンソースコンポーネントであり、誰でも実行できる。

BTCインスクリプション「Ordinals」は、BTC上でNFTやトークンを発行する仕組みを構築し、BTC L2に関する大規模な議論を引き起こした。この意味で、Ordinalsはある程度先駆的かつ探求的な性質を持っていると考えられる。しかし、技術および製品体験面ではBTC自体のアーキテクチャに制限され、また粉塵汚染やデータ占有などの理由から、BTCコミュニティのOGから批判を受けてきた。

それでは、イーサリアム上でインスクリプションを再現することに意味はあるのだろうか？そもそもイーサリアムは複雑なスマートコントラクトを備えており、ERC20やNFTも元々存在するものである。このようなインスクリプションプロジェクトはイーサリアムエコシステムにどのような影響を与えるのか？BTC上で起きたような議論や混乱が繰り返されるのだろうか？

Ethscriptionsの技術的実装方法

まず、Ethscriptionsの実装方法を見てみよう。これはイーサリアム上で有名なインスクリプションプロジェクトであり、主にCalldataを利用して動作している。

Calldataとは、イーサリアムのトランザクションに含まれる元の入力データである。通常はスマートコントラクトとのやり取りに必要なパラメータを伝達するために使われるが、EOAアドレスに対してテキストメッセージ（メモ、刻印、送金備考など）を送信することにも使える。図中のInput Dataがcalldataに当たる。

もしEthscriptionsを使ってトランザクション中に「Hello world」と刻印したい場合、以下のようなcalldataを含むトランザクションを作成する必要がある：

チェーン外のIndexerがこのトランザクションを監視すると、データベースを更新しユーザーに通知する：新しいインスクリプションが生成され、「Hello world」という内容が刻まれた。インスクリプションにはbase64形式の画像データなど、より複雑なコンテンツも格納可能である。

現在Ethscriptionsは、ESIP（Ethscriptions改善提案）と呼ばれる6つの提案を通じて、さまざまなシナリオにおけるインスクリプションの使用方法を定義している。これらはEIPに類似したプロポーザルであるが、比較的基礎的な規範に留まっており、EOAからのインスクリプショントランザクション形式やコントラクトemitイベントなどに限定されている。

Ethscriptionsはイーサリアム上のプロジェクトであるため、イーサリアムのスマートコントラクトを利用して一定程度のロジックを実現することも可能である。ただし、スマートコントラクトとの直接的なやり取りはEthscriptionsが推奨していないことに注意が必要である。

公式のNFTマーケットプレイスなども直接スマートコントラクトで実装されているが、公式ドキュメントによると、Ethscriptionsが目指すのは「分散化されて安価な演算サービス」であり、演算をチェーン外に切り離すことで、イーサリアムの利用コストを大幅に削減することである。

スマートコントラクト呼び出しのコストについて具体的に見てみよう。これは以下の3つの部分に分けられる：

基本トランザクションコスト：すべてのイーサリアムトランザクションに発生し、現在は21,000 gasである。
データ転送コスト（calldata）：calldataは通常、スマートコントラクトとやり取りするデータやパラメータを送信するために使用される。EIP-2028により、calldataの各バイトは通常16 gas消費する（データがゼロのバイトは4 gas）。
コントラクト実行コスト：トランザクションがスマートコントラクトの関数を呼び出す場合、関数の複雑さに応じて計算コストが発生する。例えば、ステート更新（ERC-20コントラクトでの残高更新など）に関与するSSTOREは5,000～20,000 gasまで消費する。

非常にシンプルなUSDT送金トランザクションを例に取ると、このトランザクションは合計63,197 gasを消費し、calldataは以下の通りである：

このcalldataを解析し、どれくらいのgasがかかるかを見てみよう：

イーサリアムのcalldataは16進数形式であり、2桁ごとに1バイト（16^2 = 2^8）となる。先頭の0xは16進数であることを示す。
0xの後に続くa9059cbbは関数セレクタであり、4つの非ゼロバイトを占める。
その後の32バイトはアドレスであり、先頭に12バイトのゼロ（イーサリアムアドレスは20バイトだが、左側をゼロで埋めて32バイトにしている）、および20バイトの非ゼロアドレスデータ。
最後の32バイトは金額を表し、多くのゼロで埋められており、末尾に3b9aca00という非ゼロデータ（4バイトの非ゼロ）がある。
つまり、非ゼロバイトは28個、ゼロバイトは40個。

したがって、calldataGas = 28 * 16 + 40 * 4 = 608 gas。

総gasは63,197であり、calldataコストと固定コストを差し引くと、スマートコントラクトの計算コストは41,589 gasとなる。このトランザクションでは、コントラクト演算コストが大部分を占めており、これは単純なトランザクションにすぎない。より複雑なトランザクションでは、コントラクト演算コストはさらに増加する。

演算をチェーン外に移すことで、確かに利用コストを大幅に削減できる：スマートコントラクトを直接呼び出さずに、事前に決められたEOAアドレス

0x00000000000000000000000000000000000face7にトランザクションデータを送信する。

トランザクションのcalldata内に、本来呼び出したかったコントラクトとその入力パラメータを宣言する。前述のアドレスはEOAアカウントであり、コントラクトコードがないため、上記の操作はチェーン上で計算タスクをトリガーせず、単なるメッセージの発行に過ぎない。

一方、チェーン外のIndexerはこのメッセージを監視し、解析して、発信者がどのイーサリアムチェーン上のコントラクトを呼び出そうとしていたかを特定し、その後、Indexerがチェーン外でコントラクト呼び出しの結果を計算する。

そのため、Indexerがインスクリプションとスマートコントラクトの演算を行うには、STF（状態遷移関数）ルールとランタイム、あるいはより複雑な場合は仮想マシン（VM）が必要となる。EthscriptionsはESIP-4において独自のVM—Ethscriptions VMを導入し、後にFacet VMと改名された。

Facet――協働プロセッサのような存在

Facetは、安価で使いやすく、安全かつ分散化された計算プラットフォームとして自らを定義している。イーサリアム上のEthscriptionsのcalldataを監視し、VMに取り込んで演算を行い、最終的にユーザーに結果を返す。Facetはいくつかの重要な構成要素を持つ：

Facet VM：Rubyで書かれたVMで、ETHSトランザクションの監視、calldataの解析、演算の実行を担当。
Rubidity：Facetにおけるスマートコントラクト言語。Rubyに似ておりながら、Solidityの多くの構文や概念を維持しており、開発者が簡単に習得できるように設計されている。
Dumb Contract（ダムコントラクト）：Facet上で動作するコントラクト。この名称にはユーモアが込められている。「アホコントラクト」と呼んでもよい。dumbは二重の意味を持ち、静黙した動作過程を「無言」と表現する一方、公式のスローガン「So dumb, they're smart」（あまりに愚かすぎて賢い）から、まるでスマートコントラクトへの挑戦のように感じられ、「呆笨コントラクト」と呼ぶのも適切である。

ダムコントラクト自体は実際にイーサリアム上にデプロイされるわけではなく、そのコードはcalldataの形でETHチェーン上に投稿されるのみである。以下はFacetによるダムコントラクトの呼び出し例である：

ミントトランザクションにおいて、EOAブラックホールアドレス

0x00000000000000000000000000000000000face7に下図のようなcalldataを提出し、ミントしたいトークンと数量を宣言すればよい。これはまさにOrdinalsやBRC-20と同様の手法である：

次に、RubidityとSolidityの直感的な比較を見てみよう。下図参照。

公式ではRubidityがSolidityに似た概念や構造を持ち、開発者が迅速に習得できると述べている。しかし、実際には開発者サイドにとってマイナスの影響もある。そして現時点ではFacet VMは公式ホワイトリスト内のダムコントラクトのみをサポートしており、これは公式がこの言語およびVMに対して十分な自信を持っていないことを示唆している。公式にとってEVMを再利用する方が、新しいVMと新しい言語を開発するよりも工学的に難しいかどうかは不明である。しかし、確かなのは、新しい言語、新しいコントラクト、新しいエコシステム、新しいイーサリアムの利用方法という、十分な話題性を持っていることである。

Facetによるスマートコントラクトへの批判

Facetのドキュメントには、イーサリアムおよびスマートコントラクトに対する刺激的なコメントがある：「スマートコントラクトはイーサリアムを特別なものにする最大の特徴だと考えられているが、Facetの主張は、スマートコントラクトこそがイーサリアム最大の設計欠陥であるということだ。」

彼らは、イーサリアムのスマートコントラクトが最大の設計欠陥だと考える。なぜなら、コントラクトは入力（calldata）を与えられれば出力が決定的であり、チェーン上で演算を行うのはお金を無駄に浪費するだけだからである。これに加え、Ethscriptionsが言う「分散化されて安価な演算サービス」という文脈を考えると、EthscriptionsとFacetが明確に作り出そうとしている市場イメージは、「我々は全く新しいイーサリアムのスケーリングパラダイムと利用方法を創出している」であるが、実際にはETHS自身の技術的仕組みはかなり頼りない。

製品の観点から見れば、Facetはチェーン外で間接的にスマートコントラクトを呼び出せ、独自のチェーン外ダムコントラクト体系を持っているため、公式のスローガンを実際に実践していると言える。

しかし経済的観点からは、天下に無料の昼食はない。ストレージも演算も当然コストがかかる。では、Indexerはこのコストをどうやって賄うのか？これについては公式は何も明確に説明していない。以下のように想像してみよう：

ユーザーから料金を徴収する。例えばNFTマーケットプレイスが買い手から手数料を取る。しかし、簡易的なプロジェクトの収益モデルを、L2ネットワーク規模の長期的な収益モデルとして見るのは不適切である。
自身のエコシステムの投機によって富を得る。もちろん可能だが、短期的にプロジェクト側が満足するだけの一時的な手段にすぎない。Ethscriptionsが本当に新しいイーサリアムのパラダイムになろうとするなら、Indexerにはネットワーク全体に基づく持続可能な経済メカニズムが必要である。
利益を出さない公共財（Public goods）であれば、誰が寄付するのか？少なくともイーサリアム財団は積極的ではないだろう。なぜなら、イーサリアムにはすでに優れた解決策——Rollupがあるからである。

Facetとダムコントラクトが登場した根本的理由

もし単にイーサリアムインスクリプションのシンプルな形態だけが必要であれば、Ethscriptions一つで十分である。では、なぜそのESIP-4プロポーザルがFacetを生み出したのか？

理由は、インスクリプションシステムでは複雑な取引ロジックに対応できないからである。Ethscriptions公式NFTマーケットプレイスのコントラクトの動作ロジックを見てみよう。これはオーダーブック方式を採用している。

インスクリプションNFTをコントラクトに預けるには、calldataにEthscriptionIdを書き込み、マーケットコントラクトを呼び出せばよい。この操作は意図的に無効な関数呼び出し形式を選択しており、デフォルトでfallback()をトリガーする。

最終的にイーサリアムチェーン上でPotentialEthscriptionDepositedというイベントが発行され、Indexerノードがチェーン外でこのイベントを監視し、ローカルでNFTの所有権をマーケットコントラクトに移転する。

gasを節約するため、ETHSの取引所は売り手の注文パラメータ（価格、有効期限など）をETHコントラクトに保存せず、メッセージ形式でチェーン外に置いている（おそらくdAppサーバーに保存されている）。買い手がこのメッセージを監視することで、buyWithSignature()命令を発行して購入を申し込むことができる。

NFTの場合、オーダーブック方式は正常である。なぜならNFTは同質性を持たないからである。しかし、均質化されたトークンインスクリプションでは、コントラクトのAMM方式を使えるだろうか？答えは「否」である。インスクリプションNFTやトークンの状態はL1上にないため、OrdinalsやBRC-20とほぼ同じである。これは一部コミュニティの宣伝とは正反対であり、注意が必要である。インスクリプションは真に意味でのETHチェーン上の資産ではない。生成資産のcalldataがL1上にあり、L1上で操作命令を宣言できることをもって「L1上原生資産」と呼ぶのは誤りである。そうでなければ、RollupのcalldataもすべてL1上にあるため、RollupのL2原生資産もL1資産と呼べることになる。明らかに、このような資産をL1原生資産と呼ぶのは極めて馬鹿げている。

疑問に思うかもしれない：上記では確かにスマートコントラクトで売買を行っているではないか？どうしてコントラクトはインスクリプションを読み取ったり操作したりできないと言うのか？実際、このコントラクトはお金を受け取り、送金し、チェーン外のIndexerノードが監視して対応操作をトリガーするイベントを発行するだけである。イーサリアムEVMの目から見れば、インスクリプションのようなものの状態は、イーサリアムの「世界状態」と呼ばれる専用のステートデータベースで再現できず、コントラクトもそれを参照できない。

資産の形態が何であれ、トークンであろうとNFTであろうと、あるいは奇妙な何かであろうと、L1資産とL2資産を見分ける非常に簡単な基準を提示できる：その状態がイーサリアムの「世界状態」上で再現できるか、L1のEVMがその資産の状態を参照、呼び出し、照会、変更できるか。それが不可能であれば、それはL1資産ではない。

そのため、入金イベントの名前がPotentialEthscriptionDeposit、つまり「可能性のあるインスクリプション入金」となっているのがわかる。確定的な入金ではなく、コントラクトはそのインスクリプションが存在するか、真偽を検証できないためである。存在しないインスクリプションや他人のインスクリプションを出品しても、コントラクトは拒否しない。ただIndexerがその行動を記録しないだけである。

したがって、インスクリプションシステムはこのような簡易な疑似コントラクトロジックしか実現できず、オーダーブックはその一例である。オーダーブックの本質は、取引双方が一定のルールの下で相手の提供する情報を相互に承認することであり、スマートコントラクトを使わず純粋なテキストでも表現可能であり、インスクリプションの原理と似ている。

以下のように、スマートコントラクトを使わずに上記のプロセスを完了する方法を想像してみよう：売り手が通常のトランザクションでメッセージを刻み、「1ETHを私に送り、附言にABCと書いた人には私の番号123のインスクリプションNFTを渡す」とする。Indexerがこのロジックをサポートしていれば、誰かが売り手に1ETHを送り附言ABCをつけたことを監視し、チェーン外のIndexerデータベース内で所有権を移転できる。

もちろん、この例は実際にはいくつかの問題を引き起こす。例えば、複数人が同一NFTを購入しようとした場合の重複取引などがあり、売り手は複数の送金を受け取るが、最終的にNFTはIndexerによって一人にのみ割り当てられる。これが公式がスマートコントラクトを批判しながらも、NFTマーケットにコントラクトを使用する理由の一つでもある。したがって、Facetが計算を行わずスマートコントラクトを呼び出すというのは、信頼できない宣伝であることも理解できるはずだ。

もちろん、オーダーブックは理論的には純テキストで実現可能であり、必ずしもコントラクトを使う必要はない。しかし、AMMのように比較的複雑なロジックはスマートコントラクトなしでは実現できない。なぜなら必要なのはP2P式の相互承認ではなく、コントラクトによる承認だからである。信頼できる審査者としてのコントラクトは、残高や流動性などの基本情報をチェックし、演算を行う必要があり、必要なすべての資産データを取得できなければならない。

AMMはDeFiの中でも比較的単純な形態にすぎず、Ethscriptionsだけで実現可能なのはごく一部に限られる。これがFacetが登場した理由でもある——Facetの最優先課題はクロスドメイン！実際はブロック構造のないL2であり、そのためクロスチェーンではなくクロスドメインと呼んでいる。すべてのL1資産がFacetにクロスドメインすれば、チェーン外資産に対してダムコントラクトで操作でき、複雑なコントラクトロジックをサポートできる。

Rollupとの比較

以上の長文を読めば、Ethscriptionsの仕組みがどこかRollupに似ていることに気づくだろう。しかし、これはあくまで「似ている」にすぎず、厳密に言えば、Rollupの核心機能の一部しか実現できていない。欠落した機能は、その物語に致命的な傷を与え、あるいはユーザーを深刻な脅威にさらすことになる。

Rollupは複雑な体系であり、ここでは詳述しない。しかし、Ethscriptionsと共通する点もある：

両方ともイーサリアム上でL2トランザクションのデータcalldataを提出する。
両方とも演算をチェーン外で処理する。

共通点は明確であるが、相違点について詳しく論じる必要がある。

Rollupはcalldataをまとめて提出する

Rollupでは、ユーザーはほとんどの場合L1に直接トランザクションを提出せず、チェーン外のシーケンサに提出する。シーケンサはすべてのトランザクションを順序付け、まとめ、圧縮し、calldataをまとめてL1に送信する。これにより、多数のユーザーのcalldataを1回のトランザクションで提出でき、21,000 gasの基本コストを分担できる。

一方、Ethscriptionsにはこのような仕組みはなく、すべてのユーザーが直接L1にcalldataを提出する。

前述のUSDTの例（calldataは608 gas）を使い、100人のユーザーが100件のトランザクションを発行したと仮定し、二者のコスト差を大まかに計算してみよう：

インスクリプションユーザーはそれぞれ21,608 gas（608 + 21,000）を支払う必要がある。演算部分は支払わない（演算はチェーン外で行われるため）。
Rollupユーザーはそれぞれ818 gas（(608*100+21,000)/100）を支払う。演算部分は同様。

もちろん、RollupユーザーはシーケンサにL2の演算およびストレージ費用も支払う必要があるが、L1に比べてはるかに安価であり、本例では無視できる。また、rollupには追加の特殊フィールドによりサイズが増えるが、同時に良いデータ圧縮もあるため、ここでは深入りしない。

このような大まかな見積もりからも、EthscriptionsがLayer2と比較してコスト面で何の利点もないことがわかる。また、このプロジェクトのコミュニティ宣伝文には「4,000件のインスクリプションをまとめて転送でき、約0.11ETHが必要で、平均して1回の転送あたり0.05U程度」という表現があり、Ethscriptionsの利用が非常に安いことを証明しているように見えるが、これはETHSの原理やインタラクションの詳細を理解していない。

チェーン外の事前確定

シーケンサの存在により、Rollupのユーザー要求は1秒以内に事前確定される。これはインスクリプションシステムのL1上での12秒以上に比べ、UXがはるかに優れている。もちろん、インスクリプション支持者は反論できる：ETHチェーンにcalldataが提出される前は、そのトランザクションの最終性はいずれにせよ信頼できない。

検閲耐性と分散化

Rollupのユーザーはチェーン外のシーケンサに検閲される可能性があるが、Ethscriptionsはユーザーを検閲できない。しかし、設計の良いRollupは強制的集約機能を持ち、シーケンサの検閲に対抗し、最終的にシーケンサがユーザーを検閲する権限を完全に失うようにする。

したがって、RollupユーザーはL1上でシーケンサを迂回して直接使用することも可能である。Rollupはユーザーに選択肢を提供する：より高速なシーケンサを使うことも、直接L1を使うこともできる。しかし、EthscriptionsはL1しか使えず、ユーザーに自由な選択肢を与えていない。

また、EthscriptionsはRollupのシーケンサが中央集権的であると批判している。しかし、Indexer自体も高度に中央集権的なコンポーネントである。Ethscriptionsは、誰でもIndexerを実行・検証できるため中央集権ではないと説明するが、実際には大多数の人は自分でノードを運営しない。したがって、ETHSは極端な状況下でのみ、Rollupよりも分散化されている一面を示す。Rollupのシーケンサがダウンしたり故障したりする可能性があるが、ETHSはコミュニティメンバーが複数のIndexerを運営していれば継続稼働できる。

収益モデル

どんなプロジェクトも愛だけでは成り立たず、長期的な発展を目指すプロジェクトは、収益モデルについて真剣に考える必要がある。中央集権的組織であろうと分散型組織であろうと、利益を得なければネットワークのセキュリティを長期的に守れない。

Rollupのシーケンサには明確な収益モデルがある：余分なgasを徴収する、MEVを搾取するなど。シーケンサにはネットワークの正常稼働を維持するインセンティブがある。一方、Ethscriptionsではユーザーが直接L1にcalldataを提出するため、Indexerは料金を設定しにくい。

開発者フレンドリー度

多くのRollupは、コントラクト開発言語やツールチェーンなどをイーサリアムそのまま使えるため、開発者はシームレスに移行できる。一方、Ethscriptionsではこれらは存在せず、新しいRubidityを習得し、新しいscanを構築し、新しいVMに慣れなければならない。もちろん、これらの障壁は逆に新エコシステムの開拓機会を生む可能性もある。

出金と状態決済

これはFacetの致命的な問題である。Rollupはcalldata（入力）をL1にまとめて提出するだけでなく、N回の演算後の状態決済（出力）も定期的にL1に提出する。ZKRとOPRは入出力関係の正当性を確認する異なる証明方式を持ち、証明方式が異なっても最終的な裁定者はL1上のコントラクトである。Rollupでは出力と入力には明確な痕跡があり、偽造は不可能である。

では、状態決済は何のためにあるのか？出金、つまりL2からL1への資金引き出しのためにある。L1上に状態が公開されると、その状態根を使ってMerkle Proofなどの手段で、自分がL2で行った出金リクエストがその状態根に含まれていることを証明できる。コントラクトが検証に成功すれば、L1上で資産を解放する。

Facetには状態決済メカニズムがないため、L2からL1への無許可、分散化された出金を実現できない。前述したように、より複雑なコントラクトロジックを実行するためのL2層が必要であり、例えば彼のAMM Swap「FacetSwap」などがある。

FacetSwap（Facet上でダムコントラクトで構築されたDEX）では、明確に「入金」と「出金」の2つのアクションがあることがわかる。通常のSwapには入金・出金はないが、Facetではまずクロスドメインしなければ使えないためである。

Facetでは、入金にはL1ブリッジコントラクト上でL1の資金をロックし、対応するイベントethscriptions_protocol_CreateEthscriptionを発行してIndexerがインデックスできるようにする。これは他のL2の入金方法と一致している。

一方、出金には重大なセキュリティ問題がある。Facetには状態決済メカニズムが存在しないため、L2からL1への出金が有効かどうかをコントラクトが自動判定することはできない。では、Facetはどのような方法を使っているのか？管理者による承認、または「証人メカニズム」と呼ばれるものであり、以前にハッキングされたAxieブリッジと同様である。

実際にFacetのブリッジを見てみよう。アドレスは

0xD729345aA12c5Af2121D96f87B673987f354496Bである。

hashedMessageはsignerによって署名されたメッセージであり、出金内容が含まれている。signerは事前に設定された管理者アドレスである。状態決済がないため、該当アカウントがL2上でその量のコインを持っているかといった検証が一切できない。したがって、signerの署名があれば、プロジェクト側の悪意やハッカーによる秘密鍵の盗難に関わらず、コントラクト上のすべての資金を引き出すことができる。

Rollupでは、証人が資産を解放する必要はない。サイドチェーンでは、証人をより分散化しようとすれば、自らのコンセンサス体系から一部を選んで代理人とし、ステーキングなどで経済的抑止を施すことで悪意行為を防ぐことができる。

EthscriptionsとFacetでは、何も存在しない。単純に、露骨に管理者アドレスが存在するだけである。これは「スマートコントラクトは設計欠陥」「Rollupは中央集権的」「我々は次世代計算プラットフォーム」と叫ぶようなL2類似プロジェクトにとっては、あまりに杜撰である。明らかに、他にも多くの欠陥があるが、しばらく様子見も可能である。ただし、これらの欠陥は補うのが難しく、おそらくビットコインLayer2にも同様に存在するだろう。