パブリックチェーンがイーサリアムを模倣しなくなったとき、Suiの「基本原理」をより深く理解する必要がある

著者：劉紅林

ブロックチェーンの世界は近年、猛烈なスピードで発展し、ますます目覚ましい発展を遂げています。ビットコインは「ピアツーピアの電子マネー」という概念を理論的な観点から現実のものとしました。イーサリアムは「スマートコントラクト」を最前線に押し上げ、無数のアプリケーションを生み出しました。しかし、それ以降の新たなパブリックチェーンの多くは、イーサリアムとの互換性を主張し、既存のエコシステムと開発者を「移行」するものと、パフォーマンスを重視し、ハードウェアを積み重ね、アーキテクチャを再設計してイーサリアムの混雑を解消しようとするものの2つのタイプに分かれています。

どちらの道も成功を収めていますが、どちらも潜在的な懸念事項を抱えています。イーサリアムは互換性の高さから最も繁栄したエコシステムとなっていますが、依然として長年の課題である混雑と高額な手数料に悩まされています。パフォーマンス重視のパブリックチェーンの中には、高価なハードウェアに頼って優れたTPSを実現しているものもありますが、これは高い運用コストと分散性の犠牲を伴います。また、複雑で階層化されたアーキテクチャを採用しているチェーンもあり、メンテナンスが困難になり、リスクが顕在化しています。ユーザーの観点から見ると、多くの場合、認識は「遅い、高価、非人道的」です。

こうした背景から、Suiが登場しました。「より高速なイーサリアム」や「より安価なSolana」を求めるのではなく、「第一原理に基づいて再設計されたL1パブリックブロックチェーン」を自信を持って宣言しました。

最初はあまり注目していませんでした。ブロックチェーンの世界では新しいコンセプトが尽きることがないからです。しかし、徐々に、開発者として働く友人や、プロジェクトを検討している投資家、そしてこれまでパブリックチェーンに無関心だった人たちまでもが、Suiについて話していることに気づきました。彼らは皆、SuiはEthereumやSolanaとは全く違うと言っていました。

好奇心から、洪林弁護士は時間をかけて調査を行いました。いわゆる「第一原理」は、一体どこに現れるのでしょうか？先行技術と比較して、その強みは何で、どのような潜在的な問題に直面しているのでしょうか？以下は、ブロックチェーン愛好家としての私の分析と考察です。ただし、洪林弁護士は技術的なバックグラウンドがないため、私の発言の一部は厳密さや正確性に欠ける可能性があります。不正確な点がありましたらご容赦ください。

資産とはいったい何でしょうか?

ブロックチェーンの核心は、本質的に資産の記録です。そこで、資産をオンチェーン上でどのように表現すべきかという疑問が生じます。ビットコインとイーサリアムは、口座と残高という簡潔な答えを提示しています。誰がいくらの資産を持っているかは、台帳上の数字の羅列で表現されます。このアプローチはシンプルですが、現実世界の資産とは大きく異なります。コンサートチケットは個別に購入され、一度購入すると期限切れになります。ゲーム内の装備にはレベルと耐久性があり、銀行の住宅ローン契約には具体的な条件と金利があります。もしこれらすべてを「口座の追加残高」のような単一の記述に圧縮すると、説明のために追加のロジックが必要になります。そのため、イーサリアムはERC-20、ERC-721、ERC-1155といった標準規格を継続的に導入し、残高モデルの欠点を補うパッチとして機能してきました。

Suiは異なるアプローチを採用しました。このロジックを継承するのではなく、資産を「オブジェクト」として直接モデル化しました。各オブジェクトには固有のID、所有権、属性があり、これらの属性は時間の経過とともに、また使用状況に応じて変化します。チケットは1回使用すると自動的に「使用済み」と表示され、剣はアップグレードしたり損傷したりします。つまり、オンチェーン上の資産はもはや冷たい数字ではなく、ライフサイクルを持つ「生き物」なのです。これにより、複雑な資産の開発がより自然になり、複雑な論理的説明が不要になります。

もちろん、この設計には代償が伴います。Solidityに慣れた開発者は、オブジェクトのライフサイクル管理に改めて適応する必要があります。ツールチェーンもこの流れに追随する必要があります。そうでなければ、インデクサー、ウォレット、取引所がオブジェクトモデルに適合していないと、開発者は「バランス思考」に頼ってしまう可能性があります。より現実的な問題は、ERCシリーズが事実上の世界標準となっていることです。EthereumやSolanaなどのエコシステムと相互運用する場合、Suiのオブジェクトロジックには追加のマッピングと変換が必要となり、煩雑なプロセスになる可能性があります。

したがって、資産をオブジェクトとして扱うというアイデアは魅力的であり、実際、実物資産の物理的な形態により近いと言えるでしょう。しかし、それが真に成功するかどうかは、包括的なエコシステムの構築、標準化、ツールのサポート、そしてチェーン間の相互運用性の確保にかかっています。そうでなければ、最も洗練されたコンセプトでさえ、理想と互換性の狭間で行き詰まってしまう可能性があります。

トランザクションをキューに入れる必要があるのはなぜですか?

ブロックチェーンの世界では、すべてのトランザクションを一つずつキューに入れなければならないという問題が根強く残っています。イーサリアムはこのように設計されており、各ブロック内でトランザクションは順番に処理されます。これは、街中にレジ係が一人しかいないようなものです。コーヒーを買うときも、不動産契約に署名するときも、全員が同じ列に並ばなければなりません。誰かが時間をずらせば、後ろの人は無駄に待たされることになります。これが、効率性の大きなボトルネックとなります。

Solanaのアプローチは、この料金所をスーパーハイウェイ料金所にアップグレードし、処理を合理化し、高性能ハードウェアを積み重ねることで、単一レーンのスループットを最大化することです。その結果、確かにEthereumよりもはるかに高速になりますが、結局のところ、それは「単一レーン」であり、単に高速に動作するだけです。積み重ねるハードウェアの数が増えるほど、コストは高くなり、参加ノードの要件は厳しくなり、分散化の度合いは低下します。

Suiは異なるアプローチを採用しました。アセットを独立したオブジェクトとしてモデル化することで、無関係な2つのオブジェクト間の操作が互いに待機する必要はなくなりました。そこで、実行ロジックを並列化するように変更しました。異なるオブジェクト間のトランザクションを同時に実行できるようになり、同じオブジェクトを変更する操作のみがキューイングされるようになりました。これは、単車線の高速道路を複数車線の高速道路に変更するようなものです。ほとんどの車両はそれぞれ別の道を走り、同じランプを競合する車両のみがキューイングされることになります。さらに、Suiはプログラマブル・トランザクション・ブロック（PTB）を設計しました。これにより、複雑な複数ステップの操作を単一のトランザクションにまとめ、一度に実行できるため、ボトルネックや重複確認を回避できます。

具体的な例え話をしましょう。スーパーマーケットでレジを済ませているところを想像してみてください。従来のイーサリアムモデルでは、店舗全体でレジカウンターは1つしかなく、水のボトル1本を買うにしても、トラック1台分の食料品を買うにしても、同じ列に並ばなければなりません。Solanaのアプローチでは、このレジカウンターに最速のバーコードスキャナーと最も熟練したレジ係を配置しますが、列は1つのままです。Suiのアプローチは、10個のレジカウンターがあるようなもので、ほとんどの顧客がレジを分散して行えるため、効率が大幅に向上します。

この設計は潜在的なパフォーマンスを大幅に向上させ、「高い並行性」を実現します。しかし、これはタダ飯ではありません。まず、システムは実行前にトランザクション間の依存関係を特定する必要があり、それ自体が計算オーバーヘッドを伴います。交通警察がどの車が同時に走行できるか、どの車が衝突する可能性があるかを判断し、それらを誘導する必要があるのと同じです。トランザクションが多すぎると、このスケジューリングだけでリソースを消費してしまいます。次に、ホットスポット問題は依然として存在します。人気のオーダーブックやNFTコントラクトなど、ネットワーク全体が争うような共有オブジェクトが出現すると、関連するすべてのトランザクションは依然としてキューイングされ、このボトルネックは解消されません。

開発者にとって、並列実行は新たな課題も生み出します。シーケンシャル実行の世界では、ロジックは比較的単純で、テストパスも制御可能です。しかし、並列環境では、同時読み取り・書き込み、状態の競合など、様々な問題を考慮する必要があります。適切に設計されていない場合、極端なケースでは再現困難なバグが発生する可能性があります。これは、シングルスレッドからマルチスレッドへの移行に似ています。パフォーマンスは向上するかもしれませんが、デバッグと検証の複雑さは飛躍的に増大することがよくあります。

したがって、並列実行は確かにブロックチェーンをシングルスレッド実行の制約から解放し、新たな道を切り開きました。しかし、真に大規模なアプリケーションを実現するには、スケジューリングのオーバーヘッド、ホットスポットのボトルネック、開発者の精神的な複雑さといった現実的な課題が依然として存在します。

安全性は言語や習慣に依存すべきでしょうか?

パブリックチェーンにおけるセキュリティ問題は、多くの場合、高度な攻撃者ではなく、言語自体に過剰な自由度が与えられていることに起因します。Solidityはその好例です。その柔軟性により、多岐にわたる独創的なロジックの開発が可能になりますが、同時に、DAOハッキング、再入攻撃、整数オーバーフロー、権限管理の脆弱性など、こうした痛ましい事例が次々と発生しています。これは開発者側の不注意に起因すると主張することもできますが、別の視点から考えてみましょう。システムのセキュリティが人間の絶え間ない監視に依存している場合、システムのルール自体が本質的に脆弱であるということです。

Suiはここで異なるアプローチを選択しました。Move言語をベースにスマートコントラクトを構築するというものです。MoveはFacebookのLibraプロジェクトに由来し、「リソースはリソースである」という中核概念を持っています。リソースは言語レベルで第一級オブジェクトとして扱われます。デフォルトでは、リソースは勝手にコピーまたは破棄することはできず、明確な所有権の下で転送する必要があります。グローバルストレージに保存するには、特定の権限が必要です。これらは開発者が「自発的に従う」慣習ではなく、言語のルールにハードワイヤードされた厳格な制約です。言い換えれば、セキュリティは「習慣」に依存するものから「システム」に依存するものへと移行したのです。

より現実的な例えはこうです。Solidityはガードレールのない山道のようなものです。どんなに速く走っても、滑れば溝に落ちてしまいます。一方、Moveは高速道路のようなものです。ガードレール、速度制限、そして至る所にスロープがあります。経験の浅いドライバーであっても、事故の可能性は大幅に低くなります。問題は、高速道路の建設と維持に多額の費用がかかることです。そして、高速道路の規制が地域間で標準化されていない場合、ドライバーは依然として異なる地域を運転するのが困難です。

この設計は多くの一般的なリスクを軽減します。イーサリアム開発者は、「二重転送」や「トークンの無からの生成」といったエラーを注意深く回避しなければならないことがよくあります。Moveでは、これらの脆弱性はコンパイル時に防止されます。ユーザーにとっては、コントラクトのバグによって資産が消失する可能性が大幅に低くなります。

しかし、こうしたガードレールの裏側には参入障壁があります。Moveのプログラミングパラダイムは、多くのエンジニアが慣れ親しんでいるものとは根本的に異なります。Solidityのベテラン開発者の多くは、初めてMoveを書く際に制約を感じます。コンパイラーは値のコピーを許可せず、オブジェクトの破棄には特定の条件が必要です。初期段階では、処理が著しく遅くなることがあります。さらに事態を複雑にしているのは、Moveのエコシステムはまだ未成熟であることです。Solidityは数え切れないほどのライブラリ、フレームワーク、監査経験を蓄積してきましたが、Moveのツールチェーン、監査会社、そしてベストプラクティスはまだ開発段階にあります。

見落とされがちなもう一つの現実は、MoveがAptosとSuiに完全に実装されていないことです。つまり、開発者は「一度学習すればどこでも使える」というわけにはいきません。この乖離は短期的には学習コストを増大させ、Moveエコシステムを分断させやすく、ネットワーク効果を弱めてしまいます。

したがって、セキュリティの観点から見ると、Suiの選択は合理的です。開発者の慎重さと自制心に頼るよりも、言語自体にルールを直接組み込む方が賢明です。しかし、エコシステムの観点から見ると、この道は容易ではありません。開発者には適応する時間が必要であり、ツールと監査システムを完成する必要があり、異なるプラットフォーム間の断片化を回避する必要があります。これらの問題に適切に対処しなければ、たとえ最良のガードレールであっても「限られた少数の人だけが通れるレーン」になってしまう可能性があります。

スケーラビリティは何に依存しますか?

スケーラビリティは、ほぼすべてのパブリックチェーンにとって避けられない問題です。イーサリアムはセカンドレイヤーの構築を選択しました。メインチェーンはセキュリティと決済を担い、セカンドレイヤーはトランザクションの大部分を処理します。このアプローチは、混雑した都市に高架道路を繰り返し建設するようなものです。確かに交通を迂回させるのに役立ちますが、上流と下流の切り替えが複雑になり、チェーン間の橋は事故の危険性が高いエリアになります。Solanaは正反対の極端なアプローチを取り、単一のマシンの性能を限界まで押し上げます。これは、スーパーハイウェイを建設し、すべての車をそこに強制的に走らせるようなものです。結果として速度は向上しますが、コストは高く、運転できる人の数は減少し、結果として分散化が損なわれます。

Suiは3つ目のアプローチを提案した。オンチェーン資産を独立したオブジェクトに抽象化するため、これらのオブジェクトは異なるノードによって独立して分割・処理される。無関係なオブジェクトのほとんどは並列処理され、特に人気のある共有オブジェクトに遭遇した場合にのみ、中央集権的な調整が必要となる。これは地下鉄網の構築に似ており、異なる路線が互いに干渉することなく同時に走行し、混雑は少数の乗り換え拠点でのみ発生する。理論的には、この設計はシステムを水平方向に拡張可能であり、ユーザー数、路線数、そして全体的な容量の増加を可能にする。

しかし、紙上の青写真と現実の間には依然としてギャップがある。Suiのメインネットは、数千万人の同時接続ユーザーという過酷なテストにまだ耐えていない。分散システムが大規模になればなるほど、スケジューリングと一貫性の問題は複雑になる。地下鉄の路線が増えれば増えるほど、ディスパッチセンターへの負荷が指数関数的に増大するのと同じだ。さらに、ノードの経済モデルにも疑問符が付く。誰が安定的かつ長期的にノードを運用する意思を持つだろうか？報酬が低すぎると、メンテナンスは失敗に終わる。設計が非論理的であれば、人気のノードに皆が集まり、人気のないエリアが軽視されるリスクがある。これは時が経つにつれて、「悪貨が良貨を駆逐する」事態にさえつながりかねない。

したがって、概念的な観点から見ると、Suiの拡張性ソリューションは「高架」や「片側一車線高速道路」よりも柔軟性が高いと言えます。しかし、真に接続性が高く安定した地下鉄網を構築するには、技術検証、経済的インセンティブ、そして生態系との統合といった要素の調整が依然として必要です。

エコシステムは本当に実装されていますか?

どれほど素晴らしいコンセプトでも、現実世界での応用がなければ、それは空想に過ぎません。Suiのメインネットのローンチは、金融からゲーム、ポータルからeコマースまで、数多くのエコシステムプロジェクトを育み、基本的なエコシステムを構築しました。しかし、このプロトタイプが活気のあるエコシステムになるまでには、まだ長い道のりがあります。

金融分野において、DeepBookはインフラとして位置づけられています。DeepBookは、並列実行と低レイテンシを活用し、中央集権型取引所と同等のシームレスでスムーズなマッチングと決済を実現する、高性能なオーダーブックマッチングシステムをオンチェーンで実行することを目指しています。オーダーブックは金融市場の心臓部であるため、この取り組みは非常に重要です。DeepBookがうまく機能すれば、高頻度取引や複雑な戦略にも対応できます。しかし、オーダーブックは本質的に共有オブジェクトであるため、並列実行の利点が損なわれます。ホットスポットは依然として存在し、パフォーマンスがボトルネックになりやすいのです。より現実的に考えると、オンチェーンマッチングがマーケットメーカーや機関投資家を真に惹きつけることができるかどうかは、財務面と綿密な検証の両方が必要となる難しい問題です。

Cetusは、分散型取引および流動性プロトコルとして位置付けられています。集約型ルーティングを提供し、ユーザーが複数のプール間で最適な価格を交渉できるようにします。DeFi版「どこでも配車」のDidiに少し似ています。しかし、集約化によって何もないところから深みが生まれるわけではありません。流動性は依然として投資家の意欲に依存しています。現在、Cetusの取引量はイーサリアム上のUniswapのほんの一部に過ぎず、そのエコシステムへの影響は未だ十分には認識されていません。

Scallop Lendは、機関投資家レベルの品質とコンポーザビリティを重視したレンディングを特徴とし、より多くのプロフェッショナルな参加者を引き付けることを期待しています。レンディングはDeFiの生命線ですが、リスク管理は依然として外部資金とオラクルに依存しています。Suiの固有のアーキテクチャ上の利点は、この「見えざる手」に取って代わることはできません。

ユーザーエントリーレベルにおいて、SuiはzkLoginとスポンサードトランザクションという2つの興味深いツールを提案しました。前者は、ゼロ知識証明によって保護された使い慣れたアカウントでdAppにログインすることを可能にし、複雑なオンチェーン秘密鍵のエクスペリエンスを実質的に隠蔽します。後者は、新規ユーザーがトークンを事前に購入することなく直接やり取りすることを可能にします。これらの設計は参入障壁を下げますが、同時に新たな疑問も生じます。長期的に見て、誰がスポンサードトランザクションの費用を支払うのでしょうか？健全なビジネスモデルがなければ、このエクスペリエンスは持続不可能になり、最終的にはユーザーにトークンを事前に購入させるという従来の慣習に戻ってしまう可能性があります。

NFTとeコマース分野において、Suiはキオスク標準を立ち上げ、上場、保管、決済、そして送金というオンチェーンプロセスの統一を目指しました。市場間の摩擦を軽減し、資産の流動性を向上させるというコンセプトは理にかなっています。しかしながら、SuiのNFT市場は現在、総取引量が限られており、ほとんどの商品には活発な二次市場が存在しません。ユーザーと資金の流れがなければ、最も洗練された標準でさえ孤立したままです。

ゲームも重要な注力分野です。Suiは『サムライスピリッツ R』のような有名IPを惹きつけ、独自のブロックチェーンゲームにも挑戦してきました。Suiのオブジェクトモデルは、複雑なゲームアイテムを表現するのに最適です。剣はアップグレードでき、ペットは進化します。これらはSuiコントラクトにおける自然な「オブジェクト状態変化」です。並列実行により、複数人が同時にインタラクトする際のラグも軽減されます。しかし、ゲームの寿命は、プレイヤーがエアドロップを狙うだけでなく、ゲームに留まる意欲にかかっています。現在まで、Sui上でAxie Infinityのような世界的な成功を収めたプロジェクトは存在しません。

これらの取り組みにより、Suiはシェルカンパニー化を免れましたが、依然として課題は明確です。ユーザー規模と取引量は、EthereumやSolanaと比較して依然として限られています。多くのプロジェクトは依然として財団からの補助金に依存しており、自立的なビジネスモデルを欠いています。いわゆる「日常的なアプリケーション」はまだ登場しておらず、一般ユーザーがチェーンを利用できるシナリオは依然として乏しいです。DeFiにおいても、深度管理とリスク管理は依然として外部資金に依存しており、チェーン固有のアーキテクチャ上の利点は、市場のコールドスタートを代替することはできません。つまり、並列実行はパフォーマンスの問題を解決できますが、ユーザーと資金を自動的に生成することはできません。

Suiのエコシステムは、まるで新しいショッピングモールのようです。美しく装飾され、最先端のデザインが施され、地下鉄の出入口と駐車場も整備されていますが、店舗数はまだ少なく、集客力はさらに低い状態です。財団は一時的に賃料を補助し、大手ブランドを誘致することはできますが、モールが真に繁栄するには、収益性の高い事業と強固な顧客基盤が不可欠です。これが、今後数年間のSuiにとって真の試練となるでしょう。

ブロックチェーンはどのようにして一般家庭に浸透していくのでしょうか?

Web3を初めて使う人の多くは、最初のハードルで行き詰まってしまいます。ウォレットをダウンロードし、意味不明なニーモニックフレーズを書き留め、ネイティブトークンを購入しようとしてようやく使い始める、といった具合です。たとえこれらのステップをなんとか完了できたとしても、高額なガス料金、取引の失敗、長い待ち時間などのために、諦めてしまうことがよくあります。Web3への入り口は長きにわたり、非人道的な障壁に満ちていました。

Suiの設計は、ある意味では的を絞ったソリューションと言えるでしょう。このオブジェクトモデルによって、オンチェーン資産は現実世界のオブジェクトに近づき、理解しやすくなります。例えば、コンサートチケットは単なる「アカウントの残高」ではなく、1回使用すると自動的に「使用済み」と表示されるIDを持つチケットです。ゲーム内の剣はもはや単なる数字ではなく、アップグレードしたり、ダメージを与えたり、さらには再販したりできるオブジェクトです。これにより、ユーザーはオンチェーン資産に初めて触れる際に、それらを「台帳上の数字」ではなく「オブジェクト」として体験できるようになります。

並列実行により、操作が高速化されます。従来のパブリックチェーンでは、送金と契約のデプロイは同じキューに投入されます。これは、コーヒーの購入と不動産の所有権移転を同じウィンドウで行うのと似ています。Suiの並列ロジックはより現実に近いものです。ほとんどの場合、異なるオブジェクト間のトランザクションは互いに干渉せず、ユーザーはアクションをクリックした後、即座にフィードバックを受け取ります。即時決済に慣れている一般ユーザーにとって、この「遅延のない」体験は非常に重要です。

PTB（Programmable Transaction Block）と組み合わせることで、複雑な複数ステップの操作を1回で完了できるため、途中で操作に失敗したり、何度も確認を繰り返すといったフラストレーションを軽減できます。初心者は、クリック操作に長時間苦労し、どこが間違っているのかわからないままエラーメッセージが表示されることがよくあります。PTBはこうした複雑さをバックエンドで隠蔽し、ユーザーエクスペリエンスを「ワンクリック完了」に近いものにします。

Sui氏はコールドスタート問題の解決策も模索しました。zkLoginを利用することで、ユーザーはGoogleアカウントやAppleアカウントで直接ログインできるため、公開鍵、秘密鍵、ニーモニックといった馴染みのないシステムを理解する必要がなくなります。スポンサー付きトランザクションを利用することで、新規ユーザーはトークンを事前に購入することなく、ブロックチェーン・オン・チェーン上での最初のトランザクションを正常に完了できます。これにより、参入障壁が大幅に下がり、少なくとも面倒な最初のステップでユーザーが躊躇してしまうことを防ぐことができます。

しかし、単に体験を「悪くない」ものにするだけでは不十分です。人々を真にブロックチェーンに移行させるには、Web2では提供できないようなアプリケーションシナリオが出現する必要があります。AlipayとWeChatは既に決済体験をほぼ摩擦ゼロのレベルまで洗練させています。こうしたライバルに対抗するためには、Suiはそれを使うべき理由を説得力を持って提供する必要があります。例えば、ユーザーが真に所有し、恣意的に凍結できない資産、アプリケーション間で自由に組み合わせられる体験（コンサートチケットは公式チャネルで購入できるだけでなく、二次流通市場で譲渡したり、コレクションとしてパッケージ化してゲーム内の仮想アイテムと一緒に表示したりすることも可能です）、ゲームの小道具はもはや単一のベンダーのサーバーに閉じ込められることなく、異なるゲーム間で転送できるようになります。このような体験こそWeb2では実現できないものであり、Suiが活用すべきキラーユースケースなのです。

より広い視点から見ると、Suiのアプローチは前任者たちのアプローチとは異なります。資産を残高からオブジェクトへと変換し、並列トランザクションを可能にし、言語ルールにセキュリティを組み込み、分散スケーラビリティによってハードウェアを置き換えます。Suiは、DeepBook、Cetus、ScallopといったDeFiプロジェクト、zkLoginやスポンサー付きトランザクションポータルの設計、キオスク標準化の試み、そしてブロックチェーンゲームの探求を通じて、エコシステム全体を通してこのコンセプトを実装しようと試みています。

しかし、Moveが直面する課題は無視できません。オブジェクトモデルはERCの世界から切り離されているため、相互運用性を確保するために追加のコストがかかります。並列実行では、ホットオブジェクトで依然としてボトルネックが発生します。Moveの学習曲線とエコシステムの規模は、開発者の移行速度を制限しています。分散スケーラビリティは、大規模なシナリオでは未だ実証されていません。アプリケーションエコシステムは依然として補助金に依存しており、実世界でのユースケースはまだ現れていません。

したがって、Suiが「第一原理」の探求であるとすれば、その最大の価値は異なる道筋を提示することにあります。Ethereumフレームワークをいじくり回すのではなく、根本的な問いを改めて問い直し、新たな答えを提供しようと試みるのです。これらの答えがどこまで実現するかについては、時間、エコシステム、政策、そして市場の総合的な検証が必要となるでしょう。