意見: イーサリアムとその将来を「状態」の観点から理解する

編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfa​​ns)、許可を得てOdailyによって転載されました。

編集者注: この記事は以下から引用しました

イーサリアム愛好家 (ID: ethfa​​ns)イーサリアム愛好家 (ID: ethfa​​ns)、許可を得てOdailyによって転載されました。

最初のレベルのタイトル

I.はじめに

2015 年の創設以来、イーサリアム ブロックチェーンは 5 つの冬と夏を経験しました。 5 年間の歳月は、概念としてのイーサリアム プロトコル 1 を現実化し、このプロトコルをより成熟させ、より具体的なものにしただけでなく、そのような一連の設計の特徴とトレードオフも明らかにしました。設計上の課題としてのこれらのトレードオフは、イーサリアムの使いやすさを改善しようとする無数の才能を自然に引きつけ、そして引きつけ続けますが、その中で最も努力と想像力を結集するのは、一連の「スケーラビリティ」計画の改善です。この記事が指摘したいのは、イーサリアムのパラダイムが設計のトレードオフに直面しているのと同じように、これらすべてのスケーラビリティ ソリューションもトレードオフに直面していること、そしてこれらのトレードオフに価値があるかどうかを評価するには、イーサリアムに戻る必要があるということです。それ自体、イーサリアムへ イーサリアムノードとイーサリアムユーザーの本当の問題と本当のニーズ。イーサリアム自体を理解するための視点としての「状態」の視点は、これらのスキームの設計を明確にし、利益と損失を明らかにするのに役立ちます。この記事では、「状態」の意味を説明することから始め、イーサリアムの究極の槍とアキレス腱を明らかにし、その後、改善のためのさまざまな方向性を探ります。 「リッチステート」はイーサリアムスマートコントラクトにおける「構成可能性」の源泉ですが、イーサリアムネットワークの最大の弱点でもあります。このことから、よく言及されるどのソリューションが「組み合わせ可能性」に影響を与えるのか、またどの「スケーラビリティ」がより明確な意味を持つのかがわかります。2. パラダイムとしてのイーサリアム(1) 豊富なステートと構成可能性「ステータス」とは何ですか？状態とは、ある時点におけるシステムの特定の状況です。暗号通貨を実装するブロックチェーンを例にとると、ある瞬間のブロックチェーンの状態は、その瞬間のブロックチェーン上のすべてのアドレスの資産分布（アドレスAには10コイン、アドレスBには100コインなど）になります（実際、私たちが持っているものは、私たちの心と社会的合意によって「資産」として解釈される一部の状態にすぎません。この観点から、ブロックチェーン プロトコルの各セットは、大まかに 2 つの部分に分けることができ、1 つはコンセンサス メカニズム、もう 1 つは状態遷移ルール​​ (「コンセンサス ルール」と呼ばれることもあります) であり、前者はブロック生成ルールを定義します。ブロックチェーンに参加しているすべてのノードがブロックチェーン データベースの状態をローカルで更新する必要があるとき (たとえば、イーサリアム ブロックチェーンのノードとして、難易度の要件を満たすジョブを受け取るたびに、ノードはローカル ブロックチェーンの最新の状態を更新します)データベース）、状態遷移ルール​​はどのトランザクションが有効であるかを定義し（「アカウントはその残高を超える金額を使用できない」）、またトランザクションを処理するときにノードが状態を更新する方法も定義します（「このトランザクションはそのアカウントを意味します）」 A が 5 コインをアカウント B に送金すると、アカウント A の残高は 5 減り、アカウント B の残高は 5 追加されます。」ビットコインのコンセンサスメカニズムは「PoW + 中本コンセンサス」であり、状態遷移ルール​​はUTXOに基づいています。イーサリアムのブロック生成メカニズムは「PoW + Ghostルール」であり、状態遷移ルール​​はアカウントに基づいています。では、イーサリアムをこれほど画期的なイノベーションたらしめているものは何でしょうか?イーサリアムが特別である理由は、「プログラマビリティをサポートするチューリング完全プログラミング言語を導入している」などという意見をよく聞きます。実際、この記述は正確ではありません 2.より複雑なプログラミング言語を許可することには何の意味もないので、実際、ビットコインもプログラムできますが、ビットコインに堅牢性プログラミング言語の使用を許可しても、イーサリアムは取得されません。イーサリアムを本当に特別なものにしているのは、その「豊かなステートフルさ」です3。つまり、あるコントラクトから別のコントラクトを呼び出すことができ、ブロック サイズ自体は別として、そのような呼び出しのレベル数に制限がありません。コントラクト B はコントラクト A を呼び出し、コントラクト A によって開示されたコードに従ってコントラクト A の状態を変更できます。コントラクト B を呼び出すコントラクト C も間接的にコントラクト A を呼び出し、コントラクト A の状態を変更できますが、その制御ロジックは非常に重複する可能性があります。これは、状態を資産として捉えると、その資産の使用権（使用条件）をより厳密かつ複雑に継続的に管理できるようにすることに相当し、理論的には状態更新ロジックを意味する。現実の金融契約に限りなく近づけることができます (すべての金融契約は単純なロジックで重ね合わせて組み合わせることができるため)。任意の制御層の蓄積を可能にするこの属性は最も重要ですが、この制御をどのようにプログラムするかは二次的なものです。さらに、イーサリアムではユーザーが状態をブロックチェーンに書き込むこともでき、これらの状態をグローバル状態の一部にし、コントラクトで定義されたロジックに従ってノードが状態を更新することを要求します。その結果、コントラクトは自身の状態をイーサリアム上の他のすべてのアカウントに開示することができ、前述の豊かなステートフル性が実際に機能します。そう、これでドラゴンボールを集めるように3つの属性が集まりました。

(1) チェーン上のコンピューティング パラダイム: コントラクトは、ノードが独自に定義したロジックに従って計算を実行することを要求できます。

(2) グローバル状態: 契約の状態はグローバル状態の一部となり、他のすべてのアカウントに開示される可能性があります。(3) リッチステート: コントラクトは相互に呼び出すことができ、スタック層の数に制限がないため、制御ロジックを層ごとに蓄積できます。これでイーサリアム最強の槍「コンポーザビリティ」（通貨レゴ）を呼び出せるようになりました！チェーン上のコンピューティング手法により、さまざまなコントラクトを持つことが可能になり、グローバル ステートにより、これらのコントラクトが相互に状態にアクセスできるようになり、リッチ ステートにより、無限に多様なコントラクトの組み合わせが可能になります。つまり、安定通貨 DAI だけでなく、融資市場、宝くじアプリケーション、宝くじの収益を自動的に寄付するアプリケーション、異なる融資市場間の貯蓄率を自動的にリバランスするアプリケーションも持つことができます。(2) 状態データ爆発問題「構成可能性」はあまりにも優れていますよね？はい、上記の 3 つの属性の三位一体は、実際には両刃の剣です。イーサリアムの状態遷移プロセスは次のように抽象化できます。状態遷移関数は古い状態とトランザクション リストを入力として受け取り、新しい状態を出力します。これは、イーサリアムの完全検証ノードが、状態関数を実行し、その結果を使用してブロックの有効性を検証できるように、イーサリアム ブロックチェーンの最新の状態をローカルに維持する必要があることを意味します (また、他のイーサリアム ノードとのコンセンサスにも同意します)。矛盾は、コントラクトと開発者にとって、コントラクトの状態はイーサリアムのグローバル状態の一部としてイーサリアムのノードに保存され、コントラクトのステータス更新はイーサリアムのノードによって計算されることです (この「サーバーレス」アーキテクチャは非常に快適ですが、これらの状態は、1 回の支払いが行われる限り、イーサリアムの完全な検証ノードに永続的に保存されます。アップデートには課金が必要ですが、課金は避けられず、ステータスデータは蓄積・拡大し続けます。

状態データの拡張が問題となる理由は、完全検証ノードに対するハードディスク (ランダム) の読み取りおよび書き込みの負担がますます増大するためです。状態データはブロック データとは異なります。ブロック データは静的であり、永続的な保存後に頻繁に読み書きする必要はありません。ただし、状態データはブロックが追加されるたびに何度も読み書きする必要があり、読み書きの負担がかかります。どんどん重くなってしまいます。ここ数年、イーサリアムのフルノードの展開が難しいという声をよく聞きましたが、これが主な理由の 1 つです。少し前に、Infura の無料イーサリアム ノード サービスがクラッシュし、Infura に依存する多くのサービスがクラッシュしました。

この問題を解決するのは簡単ではありません。過去数年間、イーサリアムの複数のハードフォークのアップグレードにより、まさに経済的コストを伴う契約による新しい状態の作成を抑制するために、状態にアクセスするオペコードのガス消費量が増加しました。しかし、ロジックが根本的に変わっていないため、これは明らかに単なる一時的な解決策であり、状態データは引き続きイーサリアムノードに保存される必要がありますが、状態データを作成するユーザーは一度支払うだけで済みます。これを変えるためには、ある種の「州家賃」メカニズムを導入する必要があり、州が継続的に家賃を支払うことを節約する契約を要求し、そうでなければ契約の利用が終了するということも提案された。しかし、その仕組みは想像を絶する複雑さを有しており、合理的な家賃の徴収方法を決定することが難しい一方で、合理的な支払対象を決定することも困難です。そのため、州の家賃メカニズムに関する研究も 2019 年に停滞しました5。また、保有通貨量に基づいて利用可能な状態空間のサイズを定義しようとするプロジェクト (Nervos など) もあります。そのため、状態データのサイズには常に上限があり、状態の拡張の問題を回避できます。しかし、これにより元の資産、経済的属性も変化します。

これまでのところ、「無国籍」以外にこの問題に対する満足のいく根本的な解決策は見つかっておらず、現実的に言えば、これも多くの課題に直面しています。これについては後ほど説明します。

全体として、グローバル状態、オンチェーン コンピューティング、およびリッチ ステートは、イーサリアム上のコントラクトを構成可能にするだけでなく、小説「ロード・オブ・ザ・リング」のロード・オブ・ザ・リングのように、イーサリアム・ネットワークを集中化の危険にさらしています。リング」は、強力な力を呼び出すだけでなく、使用者自身を飲み込むことができます。私はイーサリアムがこの負担を長期間負うことになるのではないかと心配しています。
次に、「状態」の観点を使用して、さまざまなスケーラビリティ ソリューションの設計とトレードオフを理解します。3. イーサリアムの発展方向この章では、イーサリアムの 4 つの開発方向、レイヤー 2 スキーム、シャーディング、ステートレス、ロールアップ スキームを分析します。ロールアップはレイヤ 2 スキームのサブセットであり、ステートレス性はシャーディング以前のテクノロジであるため、この分類は完全に不合理であり、レイヤ 2 スキームではイーサリアムの最下層を変更する必要がほとんどないため、これらを並べることさえ不合理です。シャーディングとステートレスにはそのような要件があります。これは、説明と理解を容易にするためにのみ行われます。(1) レイヤ2方式レイヤ 2 スキームの背後にあるアイデアは、シンプルだが非常に正確な直観から来ています。イーサリアムがスループットのボトルネックに直面している理由は、イーサリアム ネットワークを構成するノードの帯域幅、コンピューティング能力、および状態データを維持する能力がすべて不足しているためです。限界があり改善が難しく、単にネットワーク全体のノードに単位時間当たりのトランザクション処理量を増やすだけでは、ノードの動作要件が必然的に増大し、分散化を損なうが、利用の観点からは、すべての状態をイーサリアム上に置く必要はありませんし、すべての状態計算をイーサリアム上で実行させる必要はありません; コントラクトの中間状態 (またはすべての状態) を他の場所に保存し、ユーザーのインタラクション (つまりつまり、状態の更新はイーサリアム ブロックチェーン上では行われず、ユーザーが特定の状態を解決する必要があると考えた場合にのみ、その状態が確認のためにイーサリアムに送信されます。一言で言えば、単位時間当たりのトランザクション数を増やすことについてネットワークの合意に達することができない場合は、単一トランザクションの意味合いを改善する必要があります。

古典的なレイヤー 2 スキーム「ステート チャネル」は、このアイデアを最も完全に体現しています。チャネルに参加している 2 人のユーザーが資金をコントラクトにロックすると、その後、2 人間のトランザクションはチェーンに送信されなくなり、他の通信ツールを使用して交換します。署名されたメッセージを作成し、チャネルの状態に関する合意に達します (したがって、送受信するメッセージの数や形成される状態データの量に関係なく、イーサリアムの負担にはなりません); 2 人が「何も存在しない」と考えるまで、対話する必要がある（または一度一時的に決済する必要がある）ので、相互に認識された状態と2人の署名をイーサリアムに送信し、イーサリアムは契約の状態を更新し、この状態に応じて2人は和解資金。

レイヤ 2 ソリューションをコントラクトの設計パターンとみなすと、それがより明確にわかります。レイヤ 2 ソリューションは、グローバル状態を利用しないことを選択します。別のコントラクトは、レイヤー 2 コントラクト内にどのような状態があるか (ユーザー A\B\C がどのくらいの資金を持っているか) をリアルタイムで知ることができません。これらの状態はチェーン上にないため、レイヤー 2 コントラクトは認識できません。他の契約と組み合わせてご利用いただけます。それでも、レイヤー 2 ソリューションは、トランザクション速度の高速化 (ただし、確認された中間状態はメイン チェーンの状態ほど安全ではありません)、手数料の削減、メイン チェーン ノードの負担の軽減など、非常に貴重なものも交換しています。 。しかし、ここ数年レイヤー 2 ソリューションが成果を上げていないのはなぜでしょうか?なぜなら、ロールアップスキームが登場する前は、国営チャネルやプラズマを含む他のスキームは、独自の契約にロックされている資金が、ステートフルコントラクトにロックされている資金と同じくらい安全である（凍結されていない、盗まれていない）ことを証明できなかったからです。ステート チャネル スキームでは、ブロックチェーンを常に監視していないと、取引相手が古い状態をメイン チェーンに送信してお金を「盗む」可能性がありますが、プラズマ スキームでは、多くの場合、提供するためにオペレーターに依存する必要があります。したがって、運営者自身が弁護することは非常に困難です。これは、イーサリアムメインネットで状態契約を使用する経験とはまったく異なります。契約のコードリスクを除けば、誰かが取引をキャンセルするために 51% 攻撃を開始しない限り、契約に預けたお金は盗まれません。自分の資金を引き出してください。 (後の記事で、ロールアップ ソリューションがこの問題をどのように解決するかについて説明します。)(2) 断片化イーサリアムを改善し、イーサリアムのスループットを向上させるためのもう 1 つの直感は次のとおりです: 各完全なノードがチェーン上のすべてのトランザクションを処理する必要があるため、イーサリアムのスループットは制限されています。各ノードにトランザクションの一部のみを処理させることができれば、ノードの違いは大きくなります。グループ内で異なるトランザクションが個別に (並行して) 処理される場合、単位時間あたりのシステム全体のスループットは、これらのノード グループの単一グループの処理能力の合計に等しくなります。つまり、単一ノードの負荷は増加するわけではありませんが、システム全体のスループットは増加します (パケットが細かくなるほど、スループット乗数は大きくなります)。これを「シャーディング」と呼びます。

シャード アーキテクチャに関する興味深い質問は、その正確な定義です。従来の非シャード ブロックチェーン アーキテクチャでは、フル ノードは (1) すべての計算を繰り返し、(2) すべての状態を維持し、(3) すべてのブロック/トランザクションを伝播する必要があります。どれか 1 つだけが壊れていれば断片化していると考える人もいますが、より厳密に考えると、理論的に導き出されるスループット向上効果を得るには 3 つすべてが壊れる必要があります 6 。定義が異なれば効果も異なります。ここで私がとった定義は、ノードは少なくともシステム全体のすべての状態を維持する必要はないということです。

しかし、さらに興味深いもう 1 つの疑問は、シャーディング アーキテクチャに必要なすべてのフロントエンド テクノロジが実現できた場合、このアーキテクチャがどれほど意味を持つかということです。イーサリアム財団の研究チームが考案したシャーディングアーキテクチャでは、システム全体の状態がいくつかの部分に分割され、各部分が並行して更新されるスライスの内部状態。シャード A のコントラクト A' がシャード B のコントラクト B' を呼び出そうとする場合、プロセッサがシャード B の状態を所有しているとは想定できないため、処理結果はシャード B が状態の更新を完了するまで待機してから返される必要があります。その結果、クロスシャードトランザクションは、トランザクション処理において最も耐え難いコストである遅延に耐えなければなりません。重要なのは、この遅延は金銭的なコストでは抽象化できないということです。シャード B は、自身を呼び出す必要があるトランザクションがシャード A で発生したことを知らないため、信頼できる通信層がこのトランザクションを自分自身にブロードキャストするのを待つことしかできません。単位時間あたりに作成できる価値が高いほど、遅延は耐えられなくなります。これは、特定の DeFi アプリケーション集中にシャードがあると仮定すると、これらのアプリケーションはクロスオーバーを通じて他のシャードでの処理をスケジュールしないことを意味します。まったく無意味であり、DeFi アプリケーションの遅延要件を満たすことができないため、あらゆる容量でシャード トランザクションを実行します。同様に、この DeFi アプリケーションによって集約されたシャードのうちの 1 つのシャードの処理能力がその処理能力の上限であることも意味します (単一のブロックチェーンと変わりません)。深い山や古い森に家を建てたり、道路を建設したりしても、大都市の人々の居住空間の問題は解決できません。(これらの「アイドル状態」のシャード スループットは、よりニッチなアプリケーションによって悪用される可能性があると主張する人もいます。私は、レイヤー 2 ソリューションでも同じ効果を達成できると考えていますが、基礎となるレイヤーへの変更が少なく、より安全であると考えています。)(3) 無国籍ステートレス性は、ステート データの拡張の問題に直接直面する唯一のアップグレードの方向性です。現在のイーサリアムプロトコルではトランザクション自体が遷移先の状態の情報を持たないため、トランザクションを処理するノードは状態遷移機能を実行する前提として状態データを保持する必要があります。だからこそ、状態データの増大（ノードの負担増大）が問題となるのです。

ステートレス化の鍵は、トランザクション/ブロック自体が訪問する状態の情報を付加できるようにすることです。したがって、ブロックはそれ自体で検証可能であり、トランザクションを処理するノードが状態を持つ必要はありません。

実はステートレス化とは、イーサリアムブロックの構造を変えることで、イーサリアムブロックの検証方法を変えることです。状態データを保持する必要がないため、ハードディスクの読み書きが不要になり、ブロック検証の速度も高速になります。さらに、各ノードは状態データをまったく維持しないことも、自身のニーズに応じて一部のコントラクトの状態データを維持することもできます。しかし、正直に言うと、現在、無国籍は非常に多くの設計上の課題に直面しています。具体的には、 (1) ステートレスであるためには、ブロック/トランザクションにアクセス状態の証明(証人)を付ける必要があるが、この部分のデータの規模は非常に大きくなる可能性があり、現在のイーサリアムのブロックデータサイズは20～40KB程度であるが、 、監視データのサイズは MB レベルになる可能性があります (アクセスされる状態ボリュームのサイズに応じて); (2) すべての状態を維持するノードのみが監視を組み立てることができるため、誰が一般ユーザーに状態を提供するか? （実際には、これはイーサリアムの動作前提の変更とみなすことができます。すべてのフルノードがマイニングに参加できますが、ステートレスが実現した後は参加できません。） (3) トランザクションのガス消費量をどのように価格設定するか?特に、ウィットネスの適時性により、オペコードに基づいてウィットネスを組み立てるのにどれだけの計算がかかるかを判断することはできません。これらの問題のため、イーサリアムのフルノードは、すべての状態を長期間維持するこのモードで実行する必要がある場合があります。ただし、ステートレス化は、イーサリアム プロトコルの現在の改善において最も魅力的な方向性であることは間違いありません。それはイーサリアムの核心問題に直接向き合い、この問題を根本から解決しようとしているからです。さらに、イーサリアム プロトコルでの状態データの使用に関する研究は、同期方法などの他の研究の方向性も育ててきました8。私は、イーサリアムの将来は、無国籍ではないにしても、無国籍に触発されたある種の計画であると信じている偏見があります。(4) ロールアップ方式Rollup スキームは Layer-2 スキームであり、その特徴は、各状態更新に使用されるトランザクションをイーサリアム ブロックチェーン上に公開することです。他のレイヤー 2 スキームと同様に、ロールアップ スキームもオフチェーンに状態を保存し、イーサリアム ノードがコントラクトの新しい状態を計算する必要はありませんが、コントラクトの状態を変更するすべてのトランザクションはデータとして公開されます。つまり、第三者はこれらの公開データと公開ルールに基づいて契約の状態を計算できます (ただし、イーサリアム上の契約ではこれらの状態を使用できません)。前述したように、Lyaer-2 コントラクトが状態計算をイーサリアム チェーンの外に移動し、自身のコントラクト状態を曖昧にすることを選択すると、ユーザーにリスクが生じます。ユーザーは、レイヤー 2 コントラクトのオペレーターが次のことを行うことを知りません。無効な状態はブロックチェーンによって最終的にチェーンに送信されません。オペレーターがこれを行うことができた場合、それはユーザーの資金を直接盗むことと同じであり、ユーザーはレイヤー 2 コントラクトの操作を知りません。投資家は自分の取引を検閲しないため、自分の資金が凍結されます。資金盗難の問題を解決するには 2 つの方法があります。1 つは、すべての状態遷移が有効であることを確認する、つまり、コントラクトのステート ルートが更新されるたびに、イーサリアムにコントラクトの整合性を確認するための検証プログラムを実行させることです。計算. 検証に合格した後にのみ、契約は状態ルートを更新することが許可されます. これは zk-rollup のアイデアです; もう 1 つのアイデアは、契約状態ルートの更新を要求するときに人々にデポジットを添付することを要求することです。提出された状態ルートは無効です。この状態ルートを報告した人は、元の提出者のデポジット (楽観的ロールアップ) を受け取ることができます。しかし、後者の考え方には前提条件があります。内部告発者は状態遷移前の状態を取得する方法を持っていなければなりません。そうでない場合、遷移の誤った証拠を生成する方法はありません。ロックされた資金の問題を解決する方法は 1 つだけです。「オペレーター」の概念を可能な限り弱め、誰でもイーサリアムにトランザクションを送信してレイヤー 2 コントラクトの状態を更新できるようにすることです。しかし、これは質問に戻ります。送信者が契約の状態を持っていない場合、どのようにして自分の状態へのアクセスの正当性を証明し、契約によってそれを解放させることができるのでしょうか?

最後に、ロールアップ ソリューションは、「状態遷移ごとに一致するトランザクション データを公開する」ことでこの問題を解決します。したがって、ロールアップ コントラクトはチェーン上の状態を公開しませんが、ロールアップ コントラクトのユーザーを含む誰もが、これらのパブリック トランザクション パッケージに基づいてロールアップ コントラクトの内部状態を再構築できます。これは、適切に設計されていれば、ロールアップ コントラクト内の資金は、イーサリアム ブロックチェーン上に状態で保存されたコントラクト (つまり、現在私たちが一般的に使用しているコントラクト) と同じくらい安全であることを意味します。

zk-rollup を例にとると、オンチェーン検証プログラムは、Maker DAO が許可なしに DAI を没収できないのと同じように、ロールアップ コントラクトが間違ったステート ルートを更新できないことを保証します; 同時に、計算​​の整合性も開示すると仮定します。構築方法を使用すると、いつでもチェーン上のコントラクトへの状態遷移を直接開始して、自分のお金を引き出すことができます。これは通常のステートフル コントラクトとまったく同じです。51% 攻撃がなければロールアップ コントラクトの状態をロールバックする方法はなく、継続的な 51% 攻撃がなければお金を取り戻すことを妨げるものは何もありません。楽観的ロールアップは、暗号経済学のいくつかの仮定に依存しているため、若干弱いです。攻撃者は、51% 攻撃のロールバック状態に加えて、一定期間継続する 51% レビュー攻撃を通じて、間違った状態のルートをコントラクトに注入することもできます。契約の最新の状態を計算した人は誰も誤差に気付かないでしょう (確率は非常に小さいです)。ただし、オプティミスティックロールアップは強力なカストディフリーも提供し、いつでもお金を取り戻すことができます。