Vitalik の最新の長い記事: イーサリアムの進化理論の続編、L2 の 4 つの重要な改善点イーサリアムのスケーリングの将来DAS に命を吹き込むL2パフォーマンスの向上これはイーサリアムの開発にとって何を意味しますか?これはイーサリアムの開発にとって何を意味しますか?これはアプリケーションと

原作者：ヴィタリック・ブテリン 原作編集：jk、Odaily Planet Daily

3 月 13 日、Dencun ハード フォークが有効になり、イーサリアムの待望の機能の 1 つであるプロト ダンクシャーディング (別名 EIP-4844、別名 BLOB) が可能になりました。当初、BLOB は事実上無料であったため、フォークによりロールアップの取引手数料が 100 分の 1 以上削減されました。ここ 1 日で、ついに BLOB のサイズが急増し、BLOB スクリプト プロトコルが BLOB を使用し始めると手数料市場が活性化しました。 BLOB は無料ではありませんが、それでも calldata よりもはるかに安価です。

左: Blobscriptions のおかげで、BLOB の使用量はついにブロックあたり 3 という目標に達しました。右: その後の BLOB 料金は「価格検出モードに入る」 出典: https://dune.com/0x Rob/blobs

このマイルストーンは、イーサリアムの長期ロードマップにおける重要な変化を表しています。ブロブにより、イーサリアムのスケーリングはもはや「0 対 1」の問題ではなく、「1 対多」の問題です。ここから、BLOB の数を増やすか、各 BLOB を利用するためのロールアップの機能を増やすなど、重要なスケーリング作業が継続しますが、より段階的なものになります。イーサリアムがエコシステムとして動作する方法の根本的な変更に関連するスケーリングの変更は、ますます遅れています。さらに、焦点は徐々に移行しており、PoS やスケーリングなどの L1 の問題からアプリケーション層に近い問題にゆっくりと移行し続けるでしょう。この記事で探る重要な質問は、「イーサリアムは次にどこへ行くのか?」です。

イーサリアムのスケーリングの将来

過去数年間にわたり、私たちはイーサリアムが徐々に L2 中心のエコシステムに変化するのを目の当たりにしてきました。主要なアプリケーションは L1 から L2 に移行し始め、支払いはデフォルトで L2 に基づいて行われ始め、ウォレットは新しいマルチ L2 環境を中心にユーザー エクスペリエンスを構築し始めました。

当初からのロールアップ中心のロードマップの重要な部分は、独立したデータ可用性スペースの概念でした。これは、ロールアップなどの第 2 層プロジェクトのデータを保存できる、EVM からアクセスできないブロック内のスペースの特別な部分です。このデータ空間は EVM にアクセスできないため、ブロックとは別にブロードキャストし、個別に検証できます。最終的には、データ可用性サンプリングと呼ばれる手法を通じて検証できます。これにより、各ノードは、いくつかの小さなサンプルをランダムにチェックすることで、データが正しく公開されたことを検証できます。実装すると、BLOB スペースを大幅に拡張でき、最終目標はスロットあたり 16 MB (約 1.33 MB/秒) になります。

データ可用性のサンプリング: 各ノードは、データ全体の可用性を検証するためにデータのごく一部をダウンロードするだけで済みます。

EIP-4844 (つまり BLOB) は、データ可用性のサンプリングを提供しません。ただし、ここから、ユーザーやアプリケーションが関与することなく、データ可用性のサンプリングが導入され、舞台裏で BLOB の数が増加できるように、基本的なフレームワークがセットアップされます。実際、必要な「ハードフォーク」は単純なパラメータ変更だけです。

ここから、開発を継続する必要がある 2 つの方向は次のとおりです。

1. BLOB 容量を徐々に増やし、最終的にはデータ可用性サンプリングのパノラマ ビューを実現し、タイム スロットごとに 16 MB のデータ スペースを提供します。

2. L2 を改善して、保有しているデータスペースをより有効に活用します。

DAS に命を吹き込む

次の段階は、PeerDAS と呼ばれる DAS の簡易バージョンになる可能性があります。 PeerDAS では、各ノードは総 blob データの重要な部分 (たとえば、1/8) を格納し、ノードは p2p ネットワーク内の多くのピアとの接続を維持します。ノードは、特定のデータ部分をサンプリングする必要がある場合、そのデータ部分の保存を担当することがわかっているピアの 1 つに問い合わせます。

各ノードがすべてのデータの 1/8 をダウンロードして保存する必要がある場合、PeerDAS では理論的には BLOB のサイズを 8 倍に増やすことができます (消失符号化の冗長性により 2 倍が失われるため、実際には 4 倍になります)。 PeerDAS は時間をかけて展開することができます。プロのステーカーが完全な BLOB をダウンロードし続ける一方で、個人のステーカーがデータの 1/8 だけをダウンロードするフェーズが存在する可能性があります。

これに加えて、EIP-7623 (または 2D 価格設定などの代替手段) を使用して、実行ブロック (つまり、ブロック内の「通常のトランザクション」) の最大サイズに対してより厳しい制限を設定することもできます。これにより、BLOB ターゲットと L1 ガスの両方の増加が可能になります。キャップがより安全になります。長期的には、より複雑な 2D DAS プロトコルにより、全体的な改善が可能になり、BLOB スペースをさらに増やすことができるようになります。

L2パフォーマンスの向上

現在、レイヤー 2 (L2) プロトコルは 4 つの主要な方法で改善できます。

1. データ圧縮によりバイトをより効率的に使用する

私のデータ圧縮の概要図はまだここで見ることができます

素朴に言うと、トランザクションには約 180 バイトのデータが必要です。ただし、このサイズをいくつかの段階で削減できるさまざまな圧縮技術があり、圧縮を最適化することで、最終的にはトランザクションあたりのデータ量を 25 バイト未満に削減できる可能性があります。

2. L2 のセキュリティを確保するために、特殊な状況下でのみ L1 のオプティミスティック データ テクノロジーを使用してください。

素朴に言うと、トランザクションには約 180 バイトのデータが必要です。ただし、このサイズをいくつかの段階で削減できるさまざまな圧縮技術があり、圧縮を最適化することで、最終的にはトランザクションあたりのデータ量を 25 バイト未満に削減できる可能性があります。

2. L2 のセキュリティを確保するために、特殊な状況下でのみ L1 のオプティミスティック データ テクノロジーを使用してください。

Plasma は、一部のアプリケーションに対してロールアップと同等のセキュリティを提供しながら、通常の状況下でデータを L2 に保持できるようにするテクノロジーのクラスです。 EVM の場合、Plasma はすべてのコインを保護することはできません。しかし、プラズマにインスピレーションを得たビルドは、ほとんどのコインを保護できます。そして、Plasma よりもはるかに単純なビルドにより、今日の検証が大幅に改善される可能性があります。すべてのデータをオンチェーンに置くことを望まない L2 は、そのようなテクノロジーを検討する必要があります。

3. 執行関連の制限を継続的に改善する

Dencun ハード フォークがアクティブ化されると、導入される BLOB を使用するためにロールアップをセットアップするコストが 100 分の 1 に削減されます。 Base Rollup では、すぐに使用量が急増しました。

これにより、Base は内部ガス制限に達し、予期せぬ料金の高騰を引き起こしました。これにより、拡張する必要があるのはイーサリアムのデータ空間だけではなく、内部的にはロールアップも拡張する必要があるという認識が広まりました。

これには並列化が含まれており、ロールアップでは EIP-648 に似たものを実装できます。しかし、同様に重要なのはストレージ、そして計算とストレージの間の相互作用です。これは、ロールアップにとってエンジニアリング上の重大な課題を表しています。

4. セキュリティを継続的に改善する

ロールアップがコードによって真に保護される世界にはまだ程遠いです。実際、l2 Beat によれば、これら 5 つのうちの 1 つだけ (Arbitrum のみ) が EVM を完全にサポートしており、私がいわゆる「ステージ 1」に到達しています。

これには正面から取り組む必要があります。私たちは、洗練されたオプティミスティックまたは SNARK ベースの EVM バリデーターのコードにまだ十分な自信を持っていませんが、間違いなくその半分まで到達することができ、高いしきい値で介入できる安全委員会を持っています (例: 私のようなもの)提案は 6-of-8、Arbitrum は 9-of-12) を実行してコードの動作を変更します。

エコシステムの基準はより厳格になる必要があります。これまでのところ、私たちは「分散化への道を進んでいる」と主張するプロジェクトを寛容に受け入れてきました。年末までに基準を引き上げ、少なくともステージ 1 に達したプロジェクトのみをロールアップとして考慮すべきだと思います。

この後、私たちは慎重に第 2 段階に進むことができます。コードによって真にサポートされているロールアップと、コードが「明らかに矛盾している」場合にのみ安全委員会が設置されます (たとえば、2 つの互換性のない状態ルートを受け入れる、または 2 つの異なる世界を受け入れるなど)。異なる答えをした場合にのみ介入してください）。この目標を安全に達成する 1 つの方法は、複数の証明者を使用することです。

これはイーサリアムの開発にとって何を意味しますか?

これはイーサリアムの開発にとって何を意味しますか?

2022 年の夏の ETHCC で、私はイーサリアム開発の現状を S カーブとして説明するレポートを行いました。私たちは非常に急速な移行期に入りつつあり、その後、L1 が統合され、開発はユーザーとアプリケーションに再び焦点を当てます。層、開発は再び減速します。

今日、私たちは明らかにこの S 字カーブの右側の減速部分にいると言えます。 2 週間前の時点で、イーサリアム ブロックチェーンに対する 2 つの最大の変更、プルーフ オブ ステークへの切り替えと BLOB へのリファクタリングが完了しました。将来の変更も依然として重要です (例: Verkle ツリー、単一スロットのファイナリティ、プロトコル内アカウントの抽象化) が、Proof-of-Stake やシャーディングほど劇的ではありません。 2022 年、イーサリアムは飛行中にエンジンを交換する飛行機のようなものです。 2023年に翼を交換しました。 Verkle ツリーの移行は、残りの本当に重要な主な変更です (テストネットはすでにあります); 他の変更は、リア ウイングの交換に似ています。

EIP-4844 の目標は、ロールアップの長期的な安定性を設定するために 1 回限りの大規模な変更を行うことです。 BLOB が公開されたので、今後は 16 MB BLOB を使用した完全なダンクシャーディングへのアップグレード、またはフィールド上の STARK 用の暗号化の 64 ビット ゴルディロックへの変換さえ、ロールアップやユーザーによる追加の操作を必要とせずに実行できます。また、これは重要な先例を裏付けるものです。イーサリアムの開発プロセスは長年の周知のロードマップに従って実行され、「新しいイーサリアム」を念頭に置いて構築されたアプリケーション（L2 を含む）は長期的に安定した環境を獲得します。

これはアプリケーションとユーザーにとって何を意味しますか?

イーサリアムの最初の 10 年間は、まさにトレーニング段階でした。目標は常にイーサリアム L1 を軌道に乗せることであり、主に熱心な少数のグループの間で採用が行われました。過去10年間に大量導入がなかったことが、仮想通貨が役に立たないことを証明していると多くの人が主張している。私は常に、非金融投機の仮想通貨アプリケーションのほぼすべてが低額の手数料に依存しているという考えに反対してきました。したがって、高額な手数料に直面しても、主に金融投機であることに驚くべきではありません。

BLOB ができたので、私たちを妨げていたこの重要な制限が溶け始めます。手数料がついに大幅に下がり、インターネット・オブ・マネーのコストは取引ごとに 5 セント以下であるべきだという私の 7 年前の主張がついに実現しました。私たちはまだ完全に危機を脱したわけではありません。使用量が急速に増加した場合、料金は依然として増加する可能性があり、今後数年間にわたって BLOB (および個別のロールアップ) のスケーリングに取り組み続ける必要があります。しかし、私たちはトンネルの終わりに光を見ます...ええと...暗い森。

開発者にとって、これは単純な 1 つのことを意味します。それは、もう言い訳はできないということです。数年前まで、私たちはプロトタイプとして機能し、適度に分散化されている限り、明らかに大規模には使用できないアプリケーションを構築するという低いハードルを自分たちに設定していました。今日、私たちはサイファーパンクでありながらユーザーフレンドリーなアプリケーションを構築するために必要なツールをすべて備えており、実際、これからも使用できるツールのほとんどが揃っています。だから、外に出てそれをやるべきだ。

開発者にとって、これは単純な 1 つのことを意味します。それは、もう言い訳はできないということです。数年前まで、私たちはプロトタイプとして機能し、適度に分散されている限り、明らかに大規模には使用できないアプリケーションを構築するという低いハードルを自分たちに設定していました。今日、私たちはサイファーパンクでありながらユーザーフレンドリーなアプリケーションを構築するために必要なツールをすべて備えており、実際、今後も備えられるであろうツールのほとんどを備えています。だから、外に出てそれをやるべきだ。

多くの人がこの課題に立ち向かっています。 Daimo Wallet は、自身をイーサリアム上の Venmo であると明確に説明しており、Venmo の利便性とイーサリアムの分散化を組み合わせることを目指しています。分散型ソーシャルの世界では、Farcaster は真の分散化 (たとえば、独自の代替クライアントの構築方法に関するこのガイドを確認してください) と優れたユーザー エクスペリエンスを組み合わせるという素晴らしい仕事をしています。以前の「ソーシャル ファイナンス」ブームとは異なり、平均的な Farcaster ユーザーはギャンブルをするためにそこにいるのではなく、真に持続可能な暗号アプリのための重要なテストに合格するためにそこにいるのではありません。

この投稿はメインの Farcaster クライアント Warpcast 経由で送信され、このスクリーンショットは代替の Farcaster + Lens クライアント Firefly からのものです。

これらの成功を基にして、アイデンティティ、評判、ガバナンスなどの他のアプリケーション分野に拡張する必要があります。

現在構築または保守されているアプリケーションには、2020 年代のイーサリアムが青写真として含まれている必要があります

イーサリアムのエコシステムには、基本的に「2010 年代のイーサリアム」であるワークフローを中心に動作する多数のアプリケーションが依然として存在します。ほとんどの ENS アクティビティは依然として最初の層 (L1) で発生します。ほとんどのトークン発行も第 1 層で行われ、ブリッジング トークンが第 2 層 (L2) で確実に利用できるようにすることについては真剣に考慮されていません (たとえば、このゼレンスキー ミームコイン ファンが、コインの継続的なウクライナへの寄付を称賛していますが、不満を漏らしているのをご覧ください) L1 料金については高すぎます)。スケーラビリティに加えて、プライバシーの面でも遅れています。POAP はすべてオンチェーンで公開されており、これは一部のユースケースでは正しい選択かもしれませんが、他のユースケースでは最適とは言えません。ほとんどの DAO と Gitcoin Grants は依然として完全に透明性の高いオンチェーン投票を使用しているため、贈収賄 (イベント後のエアドロップを含む) の影響を非常に受けやすく、寄付パターンを著しく歪めていることがわかっています。現在、ZK-SNARK は何年も前から存在していますが、多くのアプリケーションはまだ ZK-SNARK を適切に使用し始めていません。

これらのチームは、既存の大規模なユーザー ベースに対応しなければならない勤勉なチームなので、同時に最新のテクノロジーの波にアップグレードしなかったことを責めるつもりはありません。しかし、すぐにこのアップグレードが必要になります。基本的に 2010 年代のイーサリアム ワークフローと基本的に 2020 年代のイーサリアム ワークフローの主な違いをいくつか示します。

基本的に、イーサリアムはもはや単なる金融エコシステムではありません。これは、ほとんどの分野で「集中型テクノロジー」に代わるフルスタックであり、集中型テクノロジーではできないいくつかの機能 (ガバナンス関連のアプリケーションなど) も提供します。私たちは、このより広範なエコシステムを念頭に置いて構築する必要があります。

結論は

イーサリアムは、「L1 の急速な進歩」の時代から、L1 の進歩は依然として顕著であるものの、若干控えめでアプリケーションへの影響が少ない時代への決定的な移行を経験しています。

まだ拡張を完了する必要があります。この作業は舞台裏で行われることになりますが、それでも重要です。

アプリ開発者はもはやプロトタイプを構築するだけではなく、何百万人もの人々が使用できるツールを構築しています。エコシステム全体にわたって、私たちはそれに応じて考え方を完全に調整する必要があります。

まだ拡張を完了する必要があります。この作業は舞台裏で行われることになりますが、それでも重要です。

アプリ開発者はもはやプロトタイプを構築するだけではなく、何百万人もの人々が使用できるツールを構築しています。エコシステム全体にわたって、私たちはそれに応じて考え方を完全に調整する必要があります。

イーサリアムは、「単なる」金融エコシステムから、より完全な独立した分散型テクノロジースタックへと進化しました。エコシステム全体にわたって、私たちはこれに対する考え方を完全にそれに応じて調整する必要があります。