Mega Research
MegaETH：初のリアルタイムブロックチェーンの登場
MegaETHは、EVM互換のブロックチェーンであり、Web2レベルのリアルタイムパフォーマンスを暗号の世界にもたらします。わたし達の目標は、パフォーマンスをハードウェアの限界まで引き上げ、ブロックチェーンと従来のクラウドコンピューティングサーバーのギャップを橋渡しすることです。
MegaETHは、取引スループットの高さ、豊富な計算能力、そして最もユニークな特徴として、重い負荷の下でもミリ秒単位の応答時間を提供します。MegaETHを使えば、開発者は最も要求の厳しいアプリケーションを制限なく構築・組み合わせることができます。
なぜ世界には新たなブロックチェーンが必要なのか？
ブロックチェーンフレームワークの進歩により、新しいチェーンを作成するための障壁が大幅に低くなりました。その結果、最近では多数の新しいチェーンが登場しています。例えば、L2BeathasはLayer-2エコシステムにおいて120を超えるプロジェクトを記録しています。
しかし、単に新しいチェーンを作成することだけでは、ブロックチェーンのスケーラビリティ問題を解決することにはなりません。なぜなら、各チェーンが依然として、そのホストするdAppに対して大きな制限を課しているからです。例えば、下の表は現在の主要なEVMチェーンのターゲットガス/秒とブロック時間を示しています。
この表は、既存のEVMチェーンがいくつかの側面で重要な制限に直面していることを明確に示しています。まず、すべてのチェーンが低い取引スループットを示しています。例えば、opBNBは仲間の中で例外的に高いガスレート100 MGas/sを誇っていますが、それでも現代のWeb2サーバーの能力には及びません。参考までに、100 MGas/sは1秒あたりわずか650回のUniswapスワップ、または3,700回のERC-20トランスファーに相当します。一方、現代のデータベースサーバーは、TPC-Cベンチマークで1秒あたり100万回のトランザクションを超えています。
次に、高度なアプリケーションは計算能力が不足しているため、ブロックチェーン上で実行できません。例えば、n = 10^8の場合のn番目のフィボナッチ数を計算する単純なEVM契約は、約55億ガスを消費します。これは、opBNBチェーンで100 MGas/sの速度で計算するのに55秒かかります。対照的に、Cで書かれた同様のプログラムは、わずか30ミリ秒で同じタスクを完了でき、すでにCPUコア1つで1833倍の速さです！さらに、マルチコア処理を活用してもう100倍の計算能力を引き出せるブロックチェーンでの可能性を想像してみてください。
最後に、高い更新率や迅速なフィードバックループを必要とするアプリケーションは、長いブロック時間では実現できません。Arbitrum Oneを除くすべてのチェーンは、状態を毎秒またはそれ以上の間隔で更新します。しかし、完全にオンチェーンの高度なdApp（例えば、自律的な世界など）は、リアルタイムの戦闘や物理シミュレーションを行うために高いティックレート（例えば、100ミリ秒未満のブロック間隔）を必要とします。さらに、オンチェーンでの高頻度取引は、注文の発注やキャンセルが10ミリ秒以内で行える場合を除いて実現できません。
幸いなことに、これらの制限はEVMチェーンにとって克服不可能なものではありません。わたし達の技術的進歩により、これらの可能性を解放するためにリアルタイムブロックチェーンを構築する時が来ました。より正式には、リアルタイムブロックチェーンとは、取引が到着次第処理し、その結果をリアルタイムで更新することができるブロックチェーンです。さらに、ピーク時のユーザー需要にも対応できるよう、高い取引スループットと十分な計算能力をサポートし、リアルタイム体験を維持する必要があります。
ノードの専門化：パフォーマンス中心の設計のためのパラダイムシフト
ブロックチェーンのスケーラビリティは、長年にわたる研究分野です。それでは、どのようにして、現状の最先端を大幅に超えるパフォーマンス向上を突然実現できるのでしょうか？その答えは驚くほど簡単です：セキュリティと検閲耐性をEthereumやEigenDAのような基本レイヤーに委ねることで、攻撃的なパフォーマンス最適化を実現するための広範な設計空間を探求できるのです。
この考え方をより良く理解するために、まずは今日のブロックチェーンがどのように機能しているかを見てみましょう。すべてのブロックチェーンは、2つの基本的なコンセンサスと実行のコンポーネントで構成されています。コンセンサスはユーザーの取引順序を決定し、実行はその順序で取引を処理してブロックチェーンの状態を更新します。
ほとんどのL1ブロックチェーンでは、各ノードが専門化せずに同じ作業を行います。すべてのノードが分散プロトコルに参加してコンセンサスを達成し、その後、各取引をローカルで実行します。この設定は、パフォーマンスと分散化の間に基本的なトレードオフを課します。すべてのL1は、セキュリティや検閲耐性といったブロックチェーンの基本的な特性を損なうことなく、ユーザーがノードを実行するためのハードウェア要件をどこまで引き上げることができるかを決定しなければなりません。
「ブロックチェーンの分散化にとって、通常のユーザーがノードを実行できることは非常に重要です。」
しかし、フルノードに必要なハードウェア要件について、明確な答えはありません。異なるL1は、パフォーマンスと分散化のスペクトル上で非常に異なる位置づけをしています。例えば、以下の表は、いくつかのL1の推奨ハードウェア構成を示しています。
対照的に、L2はブロックチェーン設計におけるパラダイムシフトを意味し、そのノードに対する一律のハードウェア要件を排除します。これは、L2ブロックチェーンが本質的に異種であるためです。異なるノードは、特定のタスクをより効率的に実行するように専門化されています。例えば、一般的なL2では、取引の順序を決定するために特別なシーケンサー・ノードを利用します。また、ZK-Rollupsの証明者ノードは、証明生成のコストを削減するために、GPUやFPGAなどの専用アクセラレータを使用することがよくあります。MegaETHは、レプリカ・ノードという新しいクラスのノードを導入することによって、ノードの専門化を次のレベルに引き上げます。レプリカ・ノードは取引の実行を完全に省略し、従来のフル・ノードとは異なる役割を担います。
その結果、MegaETHには4つの主要な役割があります：シーケンサー、証明者、フル・ノード、レプリカ・ノードです。
シーケンサー・ノードは、ユーザーの取引を順番に並べて実行する役割を担います。しかし、MegaETHには任意の時点でアクティブなシーケンサーが1つだけ存在し、通常の実行中にコンセンサスのオーバーヘッドを排除します。レプリカ・ノードは、このシーケンサーからp2pネットワークを介して状態の差分（ディフ）を受け取り、その差分を直接適用してローカル状態を更新します。重要なのは、レプリカ・ノードは取引を再実行しないことです。代わりに、証明者が提供する証明を使用してブロックを間接的に検証します。フル・ノードは通常通り動作します：すべての取引を再実行してブロックを検証します。これは、ブリッジ運営者やマーケット・メーカーなどのパワーユーザーが高速な最終確定を実現するために重要ですが、シーケンサーに追いつくためにより高いハードウェア要件が必要です。最後に、証明者は状態を保持しない検証スキームを用いて、非同期で順不同にブロックを検証します。
以下の図は、MegaETHの基本的なアーキテクチャとその主要コンポーネント間の相互作用を示しています。なお、EigenDAはEigenLayer上に構築された外部コンポーネントです。
ノードの専門化の重要な利点は、各ノードタイプのハードウェア要件を独立して設定できる点です。例えば、シーケンサー・ノードは実行の重い作業を担っているため、パフォーマンスを向上させるために高性能サーバーで実行することが望ましいです。対照的に、レプリカ・ノードのハードウェア要件は低くても問題なく、なぜなら証明を検証することは計算的に安価だからです。さらに、フル・ノードは実行を行い続けますが、シーケンサーによって生成された補助情報を活用することで、取引の再実行をより効率的に行うことができます。このセットアップの意味は深遠です。ヴィタリックの「エンドゲーム」投稿で述べられているように、ノードの専門化は、ブロック生成がより集中化するにもかかわらず、信頼なしで非常に分散化されたブロック検証を保証します。
この表は、MegaETHの各ノードタイプに対する予測されるハードウェア要件を示しています：
ZK証明者ノードは、証明スタックに依存し、異なるプロバイダーによってハードウェア要件が大きく異なるため、表から省略しています。さまざまなVMインスタンスの時間単位のコストは、instance-pricing.comから取得しています。特に、ノードの専門化により、シーケンサー・ノードはSolanaの平均的なバリデーターの20倍のコスト（および5〜10倍のパフォーマンス）を持ちながら、フル・ノードのコストをEthereum L1ノードと比較可能な範囲に保つことができます。
リアルタイムブロックチェーンの設計
ノードの専門化というコンセプトは、エレガントで強力です。自然に、このことは次の質問を投げかけます：MegaETHの秘密は、単に強力な中央集権的なシーケンサーに過ぎないのでしょうか？答えは「いいえ」です。
中央集権的なサーバーに例えることは、MegaETHの潜在能力を理解するための有用な思考モデルになるかもしれませんが、それは舞台裏での研究とエンジニアリングの複雑さを大幅に過小評価しています。リアルタイムブロックチェーンを作成するには、オフ・ザ・シェルフのEthereum実行クライアントを使ってシーケンサーのハードウェアを強化するだけでは足りません。
例えば、わたし達のパフォーマンス実験では、512GBのRAMを搭載した強力なサーバーでも、Rethは最近のEthereumブロックのライブ同期セットアップで約1000TPS、すなわち約100 MGas/sしか達成できませんでした。この特定の実験では、Rethのパフォーマンスは、各ブロックのMerkle Patricia Trie（MPT）を更新するオーバーヘッドによってボトルネックになっています。MPTの更新は、取引の実行よりも計算的に約10倍高コストです。詳細については、EthDenver'24での発表「Ethereum実行クライアントのパフォーマンス理解」をご参照ください。
要約すると、ノードの専門化はパフォーマンスの向上において大きな機会を解放しますが、ハイパー最適化されたブロックチェーンの設計と実装は依然として解決されていない課題です。
わたし達の設計哲学
あらゆる複雑なコンピュータシステムと同様に、ブロックチェーンには複数の相互作用するコンポーネントにまたがる潜在的なボトルネックが多く存在します。ボトルネックを単独で解決しても、エンドツーエンドのパフォーマンス向上にはほとんどつながりません。なぜなら、（1）それが最も重要な制約要因ではない、または（2）最も重要なボトルネックが単に別のコンポーネントに移動するからです。わたし達は何度も、特定のコンポーネントの最適化に焦点を当てるプロジェクトを見てきました。その結果、孤立したマイクロベンチマークで印象的なスピードアップを示すことができても、これらの結果は最終的なユーザーに利益をもたらすエンドツーエンドのパフォーマンス向上に繋がらないことが多いです。
MegaETHでは、初めからより包括的で原則に基づいたアプローチを研究開発プロセスに適用することを決定しました。わたし達の設計哲学は次のように要約できます。
まず、わたし達は常に「計測してから構築する」というアプローチを採ります。つまり、既存システムの実際の問題を特定するために、まず深いパフォーマンス計測を行います。これらの洞察に基づいて、すべての問題を同時に解決するための新しい技術を設計します。
次に、わたし達はシステムをハードウェアの限界に到達するように設計することを目指します。既存システムの上に段階的に改善を加えるのではなく、理論的な上限に近づくクリーンスレート設計を好みます。わたし達の目標は、暗号インフラストラクチャにおけるパフォーマンス向上の余地をほとんど残さず、業界が採用を妨げる他の課題にリソースを振り向けられるようにすることです。
以下では、高パフォーマンスなリアルタイムブロックチェーンの設計と実装における主要な課題を解説します。
取引の実行
下の図は、ユーザーの取引がシステム内をどのように移動するかを示しており、その後で説明する技術的な課題を解説する際の参考になります。
まず、シーケンサーから始めます。シーケンサーは、多くの人々にとって最も馴染みのあるコンポーネントです。シーケンサーは取引の順序付けと実行を担当します。EVMは比較的低い実行パフォーマンスのためにしばしば非難されており、そのためEthereumのL2ではEVMを他の仮想マシンに置き換えるための多くの努力が行われています。
しかし、このステレオタイプは単に真実ではありません。わたし達のパフォーマンス測定では、revmは最近のEthereumブロックで約14,000TPSを達成できることが示されています（これは履歴同期セットアップでの結果です）。マシン構成は、前述のライブ同期実験と同じです。
14,000TPSはほとんどのL2にとって十分以上ですが、MegaETHのようなリアルタイムブロックチェーンには不十分です。従来のEVM実装には3つの主要な非効率性があります：1）状態アクセスの遅延、2）並列実行の欠如、3）インタープリタのオーバーヘッド。ノードの専門化のおかげで、わたし達のシーケンサー・ノードは、Ethereumの現在の状態である約100GBのブロックチェーンの状態全体を保持できる十分なRAMを搭載しています。このセットアップにより、SSDの読み取り遅延を排除することで状態アクセスが大幅に加速されます。例えば、上記の履歴同期実験では、sload操作が実行時間のわずか8.8％を占めています。そのため、以下では他の2つの課題に焦点を当てます。
最近、Parallel EVMは注目のトピックとなっており、多くのチームがBlock-STMアルゴリズムをMoveVMからEVMに移植することに注力しています。Parallel EVMは解決された問題と言えますが、実際の生産環境で達成可能なスピードアップには限界があります。その限界は、ワークロードにおける並列性に依存しているためです。
残念ながら、わたし達の測定結果によると、最近のEthereumブロックでの中央値の並列性は2未満です。たとえブロックを大きなバッチに人工的に統合しても、中央値の並列性は2.75にしか増加しません。実験データを詳しく調べると、今日のEthereumワークロードには長い依存関係のチェーンが多く見られます。競合を解決して並列性を増加させるための追加技術がなければ、Parallel EVMの利点は比較的限られたままとなります。
前述のフィボナッチの例で議論したように、revmのような比較的高速なEVMインタープリタでさえ、ネイティブ実行と比べて1〜2桁遅いです。このパフォーマンスギャップを反映するように、AOT/JITコンパイルを使用して単一スレッドのEVM実行を加速することへの関心が再燃しています。これに関して、revmc、evm-mlir、IL-EVMなど、複数のチームが競い合っています。
これらのプロジェクトは、いくつかの計算集約的なコントラクトで有望な結果を示していますが、生産環境でのスピードアップは非常に限られています。その理由の一つは、今日のほとんどのコントラクトがそれほど計算集約的ではないことです。例えば、わたし達は履歴同期中に各オペコードに費やされた時間をプロファイルし、revmでの時間の約50％が「ホスト」や「システム」オペコード（keccak256、sload、sstoreなど）に費やされていることを発見しました。これらはすでにRustで実装されているため、これらのオペコードはコンパイルから恩恵を受けることができず、生産環境での最大スピードアップは2倍に制限されます。
これまで、高性能なEVMチェーンに共通する課題についてのみ議論してきました。リアルタイムブロックチェーンの要求は、少なくとも2つの追加的な課題をもたらします。第一に、10ミリ秒ごとなど、高頻度でブロックを一貫して生成する必要があります。第二に、並列実行エンジンは取引の優先順位をサポートし、ピーク時の混雑時でも重要な取引がキュー待ちの遅延なく処理されるようにしなければなりません。このように、一般的には良い解決策であるBlock-STMですが、低遅延環境には適していません。
状態同期
状態同期は、フルノードをシーケンサーと同期させるプロセスであり、高性能なブロックチェーン設計において最も挑戦的な側面の一つですが、しばしば見過ごされています。
状態同期がなぜ挑戦的なのかを理解するために、ERC-20転送のようなシンプルな取引を考えます。100,000回のERC-20転送を秒間で同期するために必要な帯域幅を計算してみましょう。各ERC-20転送は3つの値を変更します：送信者の残高（アドレス20バイト + 値32バイト）とERC-20コントラクトの2つのストレージスロット（各64バイト、アドレス20バイト）。したがって、状態の差分をエンコードする簡単な方法でおおよそ200バイトかかります。100,000回の転送/秒の場合、これにより帯域幅消費は152.6Mbpsとなり、すでに帯域幅の予算を超えてしまいます。比較すると、これらは177バイトの生の取引データを直接送信するよりも高コストです。
より複雑な取引は、より大きな状態差分を生成します。例えば、Uniswapのスワップは送信者の残高に加えて、3つのコントラクトにわたる8つのストレージスロットを変更します。すなわち、64B * 8 + 20B * 3 + 52B = 624Bです。100,000回のスワップ/秒では、帯域幅消費は476.1Mbpsになります！
さらに、フルノードが100Mbpsのネットワーク接続を持っているからといって、100％のネットワーク利用率で同期できるわけではありません。その理由はいくつかあります。まず、インターネットプロバイダーは実際の持続可能な帯域幅を過大に見積もることが多いです。次に、同じノード上のアプリケーションは接続を共有しなければなりません。さらに、新しいフルノードがネットワークに参加し、ブートストラップできるように、十分な余裕を確保する必要があります。もしフルノードが常に100％のネットワーク利用率で動作していると、新しく参加したノードは決して最新の状態に追いつけなくなります。最後に、ピアツーピアネットワークプロトコルは必然的にオーバーヘッドを引き起こします。
では、状態同期にどれくらいの帯域幅を快適に割り当てることができるのでしょうか？平均的な持続可能帯域幅が75Mbpsであり、そのうちの3分の2を他のアプリケーションと新しいノードのブートストラップに割り当てると仮定しましょう。これで残りは25Mbpsになります。その場合、100,000回のUniswapスワップ/秒を同期するには、状態差分を19倍圧縮する必要があります！
状態ルートの更新
Ethereumを含むほとんどのブロックチェーンは、各ブロック後に状態をコミットするために、MPTのようなツリー状の認証されたデータ構造を使用します。このコミットメントは状態ルートとして知られており、ライトクライアントにストレージ証明を提供するために不可欠です。したがって、ノードの専門化があっても、フルノードはシーケンサーノードと同様に状態ルートを維持する必要があります。
前述のように、Rethで状態ルートを更新するのは現在、取引を実行するよりもほぼ10倍高コストです。このプロセスは非常にI/O集約的だからです。例えば、以下の図は、バイナリMPTで葉ノードを更新する際のI/Oパターンを示しています。
MPTでは、各葉がブロックチェーン状態の一部であるキーと値のペアを格納しており、各内部ノードはその下位のサブツリーをコミットする中間ハッシュを格納し、子ノードへのポインタを含んでいます。葉を変更した後に状態ルートを更新するためには、ルートからその葉への経路に沿ったすべての内部ノードも更新する必要があり、そのためにはハッシュを再計算するために子ノードを読み取る必要があります。たとえば、上記の図で葉aを更新する場合、3つのノードを読み取り、4つのノードを更新する必要があります。内部ノードは更新する前に読み取る必要があることに注意してください。さもなければ、子ノードをどのように取得するかを決定することはできません。
一般的に、k-ary MPTでn個の葉を持つ状態で1つのキーと値のペアを更新するには、それぞれO(k \log_k n)およびO(\log_k n)のノードを読み取り書き込みする必要があります。16億キー（すなわち1TBのブロックチェーン状態）を持つバイナリMPTの場合、約68回の読み取り操作と34回の書き込み操作が必要です。幸いなことに、通常はバイナリMPTの最初の24レベルをキャッシュできるため、最後の20回の読み取りおよび10回の書き込み操作はランダムディスクI/Oを発生させるかもしれません。
この課題をよりよく理解するために、1秒あたり100,000件のERC-20転送の例を再考してみましょう。各ERC-20転送は3つの値を変更するため、状態トライは1秒あたり300,000キーの更新をサポートする必要があります。単純なバイナリMPTの場合、これは約600万回の非キャッシュデータベース読み取りに相当します。これらのデータベース読み取りが各々1回のディスクI/Oで処理されると仮定しても、600万IOPSは現在の消費者向けSSDの能力をはるかに超えています――この計算では書き込み操作は考慮していません。
ディスクI/Oを削減するための一般的な最適化戦略は、複数のトライノードをサブツリーとしてまとめ、それらを1つの4KBディスクページに格納することです。たとえば、NOMTは深さ6の根なしバイナリサブツリーをディスクページに収めます。理想的には、これにより更新されたキーごとに非キャッシュデータベース読み取りが20回から2回に減少し、約60万IOPSとなります。しかし、楽観的な計算と実際の実装のパフォーマンスとの間には、ソフトウェアのオーバーヘッドにより大きなギャップが生じることに注意することが重要です。Thrumのベンチマークによれば、134百万キーのNOMTは現在、1秒あたり最大50,000回の葉更新を処理できます。これは既存の状態トライ実装に対する大幅な改善を示していますが、それでも目標のスループットには6倍足りず、しかもブロックチェーン状態は上記の例の128分の1のサイズです。
ブロックガス制限
これまで、ブロックチェーンノードが実行するさまざまなタスクの高速化に関する課題を議論してきました。しかし、ここに落とし穴があります。たとえ誰かが特定のタスクを10倍速くする優れた技術を開発したとしても、それがブロックチェーンの動作速度を必ずしも速くするとは限りません。
その理由は、ブロックチェーンの最大速度がブロックガス制限という人工的な制約によって制限されているからです。ブロックガス制限は、1つのブロック内で消費される最大ガス量を定義します。ブロック時間とともに、ブロックガス制限はシステム内のすべてのノードが最低限のハードウェア要件を満たしていれば、ネットワークの他のノードに追いつくことができるようにするためのスロットリング機構として機能します。
ブロックガス制限は、ブロックチェーンのセキュリティと信頼性を確保するために不可欠です。ブロックガス制限を設定する際の一般的な指針は、その制限内であればどのブロックでも確実に処理できるようにすることです。この基準を満たさない場合、悪意のある攻撃者による脆弱性がネットワークに露呈することになります。言い換えれば、ブロックガス制限は最悪のシナリオを考慮して慎重に選定する必要があります。
たとえば、並列EVMの実際の速度向上はワークロードに依存していることを思い出してください。過去のワークロードで平均して2倍の速度向上を達成することは可能ですが、長い依存チェーンを含むブロックの大部分では速度向上がほとんどありません。そのため、並列EVMによる平均的な速度向上を元にブロックガス制限を引き上げることは現実的ではありません。
同様に、JITコンパイルされたコントラクトの速度向上は、コントラクトの性質に大きく依存します。計算集約型のコントラクトは1〜2桁の速度向上を見込めますが、今日のほとんどのコントラクトでは改善は限られています。さらに、JITコンパイルは現在のガスモデルでは捉えきれないオーバーヘッドを導入します。たとえば、コンパイル自体がCPUサイクルを消費し、生成されたネイティブコードはメモリやディスクスペースを占有するなどです。したがって、ガスモデルを再設計して(1)コンパイルによるオーバーヘッドを考慮し、(2)コンパイルの恩恵を受けないオペコードの価格を適切に再設定するまで、計算集約型のアプリケーションを有効にするためにブロックガス制限を積極的に引き上げることはできません。
サポートインフラ
最後に、ユーザーはシーケンサーのノードと直接やり取りするわけではなく、ほとんどのユーザーは自宅でフルノードを実行していません。その代わりに、ユーザーは取引をサードパーティのRPCノードに送信し、dAppやブロックチェーンエクスプローラー（例えばetherscan.io）のウェブフロントエンドを使用して取引結果を確認します。
したがって、ブロックチェーンの実際のユーザー体験は、RPCノードやインデクサーといったサポートインフラに大きく依存します。リアルタイムのブロックチェーンがどれほど速く動作しても、RPCノードがピーク時に大量の読み取りリクエストを効率的に処理できなかったり、シーケンサーのノードに取引を迅速に伝播できなかったり、インデクサーがチェーンに追いつけるようにアプリケーションのビューを更新できなかったりすれば、意味がありません。
原則に基づいたスケーリングアプローチ
ブロックチェーンが本当に複雑なシステムであり、パフォーマンス向上には並列EVMやJITコンパイルといった孤立した技術だけでは足りないことが明確になったことを願っています。SolanaやAptosなどのすべての成功した高性能L1ブロックチェーンは、システムのほぼすべての側面で印象的なエンジニアリングの努力を行ってきました。
そのため、MegaETHは最初から全体的かつ原則的な研究開発アプローチを採用しています。初期段階で深いパフォーマンス分析を行うことで、常にユーザーに実際の利益をもたらす問題の解決に焦点を当てています。この道のりを通じて、これまで述べたすべての課題に対して、わたし達が提供できるクールな解決策があることを実感しています。具体的な解決策はこの記事の範囲外ですが、将来的にそれらについて詳細に取り上げることを楽しみにしています。
数十億のユーザーにリアルタイムのパフォーマンスを提供する
リアルタイムのブロックチェーンは、Web2サーバーとブロックチェーンの境界を曖昧にします。MegaETHでは、エンドユーザーは前例のないリアルタイムパフォーマンスを体験でき、開発者は制限なく最も野心的なアイデアを探求できるようになります。10年以上の実験を経て、ついにWeb2規模のアプリケーションをオンチェーンで実現することができるようになりました。
これまで支援していただいた皆様に深く感謝するとともに、これから提供する内容について非常にワクワクしています。それでは、次回まで。