講演者: イーサリアム創設者ヴィタリック・ブテリン氏 編集者: 0xxz、ゴールデン・ファイナンス EthCC7 が最近ブリュッセルで開催され、主催者はイーサリアム創設者ヴィタリック氏を基調講演に招待しました。 2024年がイーサリアムIC0の10周年にあたることは注目に値する。ヴィタリック氏のスピーチの後、イーサリアムの中心的創設者であるヴィタリック・ブテリン氏、ジョセフ・ルービン氏、ギャビン・ウッド氏の3人が記念の記念として再び集合写真を撮った。 この記事は、最近EthCC7でイーサリアムの創設者であるVitalik氏が行った基調講演をGolden Finance 0xxzが編集したものです。 スピーチ トピックの強化 L1: イーサリアムを最適化して、信頼性が高く、信頼できるパーミッションレスのレイヤー 2 ベース レイヤーにする

イーサリアムビジョンスペクトル
今後 5 ～ 10 年間、イーサリアムベースレイヤーがエコシステム内で果たす役割に関しては、さまざまな役割分担が考えられると思います。左から右へのスペクトルと考えることができます。 スペクトルの左側では、基本的にすべての L2 の証明バリデータとしてのみ機能する、非常に最小限のベースレイヤーになろうとします。おそらく、異なる L2 間で ETH を転送する機能も提供します。でもそれ以外は基本的にはそれだけです。 スペクトルの右側では、基本的に主に L1 で実行される dApp に再び焦点が当てられ、L2 は一部の非常に特殊で高パフォーマンスのトランザクションにのみ使用されます。 その中間には興味深いオプションがいくつかあります。 L2のベースレイヤーとして左から2番目にイーサリアムを置きました。極端なバージョンを一番左に置きました。極端なバージョンは、イーサリアムの実行クライアント部分を完全に放棄し、コンセンサス部分のみを保持し、いくつかのゼロ知識証明バリデータを追加して、基本的に実行層全体をロールアップに変えるというものです。 つまり、非常に極端なオプションが左側にあり、右側はベースレイヤーである可能性がありますが、L2 にさらに多くの機能を提供することもできます。この方向での 1 つのアイデアは、現在 12 秒であるイーサリアムのスワップ時間をさらに短縮し、おそらく 2 ～ 4 秒まで短縮することです。この目的は、実際には、ベースのロールアップを L2 操作の主要な方法として実行可能にすることです。したがって、L2 に最高のユーザー エクスペリエンスを提供したい場合は、独自の事前検証を行う必要があります。これは、集中型ソーターまたは独自の分散型ソーターのいずれかを意味します。彼らのコンセンサスがスピードアップすれば、L2 はこれを行う必要がなくなります。 L1 のスケーラビリティを本当に向上させたい場合は、L2 の必要性も減ります。 つまり、これはスペクトルです。現時点では主に左から 2 つのバージョンに焦点を当てていますが、ここで提案する内容は他のビジョンにも当てはまり、ここでのアドバイスは実際に他のビジョンを妨げるものではありません。これはとても重要なことだと思います。 イーサリアムの堅牢性の利点
イーサリアムの大きな利点は、大規模で比較的分散化されたステーキング エコシステムがあることです。

上の写真の左側はすべてのビットコインマイニングプールのハッシュレートチャートで、右側はイーサリアムステーカーチャートです。 ビットコインの計算能力の配分は現在あまり良好ではありません。2 つのマイニング プールの合計は計算能力の 50% 以上に達し、4 つのマイニング プールの合計は 75% 以上になります。 そして、イーサリアムの状況は実際にはチャートで示されているよりも良好です。灰色の部分の 2 番目の大きな部分が実際には正体不明であるためです。これは、多くの人々の組み合わせである可能性があり、そこには多くの独立したステーカーが存在する可能性さえあることを意味します。青い Lido は実際には、37 の異なるバリデーターで構成される、奇妙な、緩く調整された構造です。したがって、イーサリアムには実際に、非常にうまく機能する比較的分散型のステーキングエコシステムがあります。 この分野には多くの改善の余地がありますが、これを認識する価値はまだあると思います。これは、私たちが実際に構築できる独自の利点の 1 つです。

イーサリアムの堅牢性の利点には次のようなものもあります。 ● マルチクライアント エコシステムを有する: Geth 実行クライアントと非 Geth 実行クライアントがあり、非 Geth 実行クライアントの割合は Geth 実行クライアントの割合を上回っています。同様の状況がコンセンサス クライアント システムでも発生します。 ● 国際コミュニティ: プロジェクト、L2、チームなどを含むさまざまな国に人々がいます。 ● マルチセンターの知識エコシステム: イーサリアム財団があり、クライアント チームが存在します。 Paradigm の Reth チームのようなチームでさえ、最近ではオープンソースでのリーダーシップを強化しており、これらの特性を重視する文化が存在するため、ベースレイヤーとしてのイーサリアムエコシステムにはすでにこれらの非常に強力な利点があります。これはとても貴重なことだと思いますので、簡単に諦めてはいけないと思います。私は、これらの強みをさらに強化し、さらには弱点に対処するために講じることができる明確なステップがあるとまで言いたいと思います。 イーサリアム L1 のどこが高い基準を満たしていないのでしょうか?どうすれば改善できますか?
これは私が約半年前に Farcaster で行ったアンケートです。Solo ステーキングをしていない場合、Solo ステーキングを妨げているものは何ですか? この会場でもう一度質問しますが、ソロ ステーキングを行っているのは誰ですか? Solo ステーキングを使用しない場合、32 ETH のしきい値が最大の障害であると感じているのは誰ですか、ノードの実行が難しすぎると感じているのは誰ですか、最大の障害は ETH を投資できないことであると感じているのは誰ですかDeFiプロトコルも同時に？最大の障害は、秘密鍵を簡単に盗まれる可能性のある実行中のノードに置かなければならないという恐怖だと感じる人はいるでしょうか? 合意された上位 2 つの障害は、32 ETH の最小要件とノードの運用の難しさであることがわかります。これを認識することが常に重要です。 多くの場合、人々が DeFi プロトコルで担保を二重に使用できる能力を最大限に高める方法を掘り下げ始めると、DeFi プロトコルをまったく使用していない人が多数いることに気づきます。それでは、主な問題と、それらを解決するために何ができるかに焦点を当ててみましょう。 バリデーターノードを実行することから始めます。つまり、32 ETH のしきい値から始めます。実際、これら 2 つの質問は両方ともイーサリアムのプルーフ オブ ステークのバリデーターの数の関数であるため、関連しています。 現在、約 100 万のバリデーターエンティティがあり、それぞれに 32 ETH のデポジットがあるため、最小要件が 4 ETH に変更された場合、800 万か、おそらく 800 万を超え、おそらく 900 万または 1,000 万のバリデーターが存在することになります。バリデーターの数を 100,000 人まで下げたい場合、最小要件はおそらく 300 ETH 程度まで上がるでしょう。 したがって、それはトレードオフです。イーサリアムは歴史的にトレードオフの中間に位置しようとしてきました。ただし、それを改善する方法が見つかった場合は、最小要件を軽減したり、ノードの実行を容易にしたりするためにオプションで使用できる追加の統計ポイントが得られます。 実際、今では、署名の集約はノードを実行する上での主な困難ではないと考えています。最初は最小要件を減らすことに重点を置くかもしれませんが、最終的には両方が関係することになります。 したがって、これら 2 つの側面を改善できるテクニックが 2 つあります。 1 つの手法は、すべてのバリデーターに署名を要求せずにステーキングを許可したり、ファイナリティを許可したりすることです。基本的に、重要な経済的安全性を達成するには、十分なノードの何らかのランダム サンプリングが必要です。 現時点では、経済的安全は十分すぎるほどあると思います。 51% 攻撃を実行するコストは、削減された ETH の量に換算すると、3,200 万 ETH の 3 分の 1、つまり約 1,100 万 ETH になります。イーサリアムのブロックチェーンを破壊するために1,100万ETHを費やす人はいるでしょうか。誰も、米国政府さえも望んでいません。 これらのサンプリング手法は、家があり、玄関ドアが 4 層の鋼鉄で保護されているものの、窓が単なる低品質のガラスで、野球のバットで簡単に割れる場合と似ています。イーサリアムもある程度そうなると思いますが、51%攻撃をしたければ1100万ETHを失わなければなりません。しかし実際には、プロトコルを攻撃する方法は他にもたくさんあり、これらの防御をさらに強化する必要があります。したがって、代わりに、ファイナリティを実行するバリデーターのサブセットがある場合、プロトコルは依然として十分に安全であり、分散化のレベルを実際に高めることができます。 2 番目の手法は、より優れた署名の集約です。 Starks のような高度なことを行うこともでき、スロットごとに 30,000 の署名をサポートする代わりに、最終的にはさらに多くの署名をサポートできるようになるかもしれません。これが最初の部分です。 2 番目の部分は、ノードの実行を容易にすることです。 最初のステップは履歴の有効期限です。実際、EIP-4444 に関しては多くの進歩がありました。 2 番目のステップはステートレス クライアントです。 Verkle は長い間存在しており、もう 1 つの可能なオプションは、Stark に優しいハッシュ関数である Poseidon のようなバイナリ ハッシュ ツリーを作成することです。これを取得すると、イーサリアム ブロックを検証するためにハード ドライブは必要なくなります。また、イーサリアム ブロック全体をスターク検証できるタイプ 1 ZKVM を後から追加することもできるため、データやデータの可用性のサンプリング データをダウンロードすることで任意の大きなイーサリアム ブロックを検証でき、その後は 1 つの証明だけを検証する必要があります。 こうするとノードの実行が楽になります。現在、ステートレス クライアントで非常に面倒な点の 1 つは、ハードウェアまたはソフトウェアの設定を変更したい場合、通常、最初から開始して 1 日を無駄にするか、非常に危険なことをしてキーを 2 つに分けなければならないかのどちらかであることです。どこかでスラッシュされますが、ステートレス クライアントがある場合は、これを行う必要はなくなります。 新しいスタンドアロン クライアントを起動し、古いクライアントを閉じ、キーを移動して、新しいクライアントを起動するだけです。失われるのは 1 エポックだけです。 ZKVM を導入すると、ハードウェア要件は基本的にほぼゼロになります。 したがって、32 ETH のしきい値とノードの実行の困難さという両方の問題は技術的に解決できます。これを行うことには他にも多くの利点があると思います。これにより、個人のステーキングを増やす能力が大幅に向上し、より良い個人ステーキングのエコシステムが得られ、ステーキングの集中化のリスクが回避されます。 プルーフ・オブ・ステークには、リキッド・ステーキングに関連するリスクや MEV に関連するリスクなど、他にも課題があります。これらも引き続き検討すべき重要な質問です。私たちの研究者はこれについて考えています。 51%の攻撃から回復
本当に真剣に、厳密に考えるようになりました。このトピックについてまったく考えず、ただブラックボックスのように扱っている人がいかに多いかには驚くべきです。 実際に 51% 攻撃に遭遇したらどうなるでしょうか? イーサリアムは 51% 攻撃に遭遇する可能性があり、ビットコインは 51% 攻撃に遭遇する可能性があり、政府も政治家の 51% を買収するなどの 51% 攻撃に遭遇する可能性があります。 問題の 1 つは、予防だけに頼るのではなく、回復計画も必要であることです。 よくある誤解は、51% 攻撃はファイナリティを逆転させることだと思われているということです。これがサトシ・ナカモトが白書で強調したことであるため、人々はこれに注目します。二重に使うことができます。プライベート ジェットを購入した後、51% 攻撃を実行してビットコインを取り戻し、プライベート ジェットを維持して飛び回りました。 より現実的な攻撃には、取引所への入金や、DeFi プロトコルの侵害などが含まれる可能性があります。 しかし、逆転は実際には最悪のことではありません。私たちが懸念すべき最大のリスクは、実は検閲です。ノードの 51% は、他の 49% のノード、または何らかのトランザクションを含めようとするノードからのブロックの受け入れを停止しました。 なぜこれが最大のリスクなのでしょうか?ファイナリティ反転にはスラッシュがあるため、少なくとも 3 分の 1 のノードが非常に非常に間違ったことを行い、罰せられたという検証可能な証拠が即座にオンチェーンに存在します。 そして、検閲攻撃の場合、それは手続き上の責任ではなく、誰が何か悪いことをしたかを示す即時の手続き上の証拠はありません。さて、オンライン ノードの場合、特定のトランザクションが 100 ブロック内に含まれていないことを確認したい場合、しかし、このチェックを行うためのソフトウェアさえ作成されていません。レビューに関するもう 1 つの課題は、誰かが必要とするかどうかです。攻撃に対して、彼らはこれを行うことができます。彼らは、気に入らないトランザクションとブロックを 30 秒間遅らせることから始め、次に 1 分間遅らせ、次に 2 分間遅らせます。いつ対応するかについての合意さえありません。 。 つまり、検閲の方が実際にはより大きなリスクであると私は言います。 ブロックチェーン文化では、攻撃が発生した場合、コミュニティは団結し、明らかにいくつかのソフトフォークを実行して攻撃者を排除するだろうという議論があります。 これは今日では真実かもしれませんが、調整、イデオロギー、その他あらゆる種類の事柄に関する多くの仮定に依存しており、このようなことが 10 年後にどれほど真実になるかは不明です。したがって、他の多くのブロックチェーンコミュニティがやり始めていることは、検閲のようなものがあり、本質的により帰属されにくいエラーがあると言うことです。したがって、私たちは社会的合意に頼らなければなりません。したがって、社会的合意のみに依存し、問題を解決するためにそれを利用することを誇りを持って認めましょう。 実際、私は逆の方向に進むことを推奨しています。自動応答を完全に調整し、レビュー対象の攻撃者の大多数を自動的にフォークすることは数学的に不可能であることを私たちは知っています。しかし、可能な限りそれに近づけることはできます。 ネットワーク状態に関するいくつかの仮定に基づいて、少なくとも大部分のノードを実際にオンラインにするフォークを作成できます。私がここで主張したいのは、私たちが実際に望んでいるのは、51% 攻撃への対応を可能な限り自動化することだということです。 あなたがバリデーターである場合、ノードは検閲されているトランザクションや特定のバリデーターが検閲されているのを検出した場合、自動的にチェーンの大部分を検閲解除し、すべての誠実なノードが自動的に検閲を解除するソフトウェアを実行している必要があります。実行中のコードは上で調整されます。同じソフトフォークがいくつかあります。 もちろん、ここでも数学的に不可能な結果が生じます。少なくともその時点でオフラインの誰もが、誰が正しくて誰が間違っていたのかを判断することはできません。 多くの制限がありますが、この目標に近づけば近づくほど、社会的合意に必要な作業は少なくなります。 51% 攻撃が実際にどのようなことが起こるかを想像してみてください。以下にあるように、ある時点で突然、Lido、Coinbase、Kraken が 5 時 46 分にブログ投稿を公開して、要は「みなさん、現在レビューを行っています」というようなものではないでしょう。 実際に起こる可能性があるのは、ソーシャルメディア戦争が同時に起こり、他のあらゆる種類の攻撃が同時に起こることです。ちなみに、実際に 51% 攻撃が起こったとしても、Lido、Coinbase、Kraken が 10 年後に権力を握ると想定すべきではありません。イーサリアムのエコシステムはますます主流になるため、これに高度に適応する必要があります。私たちはソーシャル層の負担をできるだけ軽くしたいと考えています。つまり、技術層が少なくとも明確な勝者候補を見つけ出す必要があり、検討中のチェーンから分岐したい場合は、技術層が結集する必要があります。優れたソフトフォークがいくつかあります。 私は、さらに調査を行い、非常に具体的な推奨事項を作成することを主張します。 提案: クォーラムのしきい値を 75% または 80% に引き上げる
私は、クォーラム (注: クォーラム メカニズムは、データの冗長性と最終整合性を確保するために分散システムで一般的に使用される投票アルゴリズムです) のしきい値を、現在の 3 分の 2 から 75% または 80% まで引き上げることができると考えています。 基本的な議論は、検閲チェーンなどの悪意のあるチェーンが攻撃した場合、回復は非常に困難になるということです。しかしその一方で、クォーラムの割合を増やすとどのようなリスクが生じるのでしょうか?クォーラムが 80% の場合、34% のノードがオフラインになってファイナリティが停止するのではなく、21% のノードがオフラインになってファイナリティが停止することになります。 これは危険です。実際にどのように見えるか見てみましょう?私の理解では、ノードの 3 分の 1 以上がオフラインだったために、ファイナリティが約 1 時間停止したのは 1 回だけだったと思います。そして、ノードの 20% ～ 33% がオフラインになるようなインシデントはありましたか?多くても 1 回、少なくとも 0 回考えます。実際にはオフラインになるバリデーターはほとんどないので、これを実行するリスクは実際にはかなり低いと思います。基本的な利点は、攻撃者が到達する必要がある基準が大幅に増加し、クライアント側の脆弱性が発生した場合にチェーンがセーフ モードに移行するシナリオの範囲が大幅に拡大されるため、人々が実際に協力して問題を解決できることです。間違ってしまいました。 クォーラムのしきい値が 67% から 80% に増加した場合、クライアントが到達する必要がある割合が 67% から 80% に増加すると仮定すると、少数のクライアントの値、または少数のクライアントの値がクライアントが提供できる数は実際に増加し始めています。 その他の検閲に関する懸念 その他の検閲に関する懸念は、包含リストまたは包含リストの代替となるものです。したがって、多重並列プロポーザー全体が機能すれば、包含リストの代わりになる可能性さえあります。アカウントの抽象化、または何らかのプロトコル内でのアカウントの抽象化のいずれかが必要です。 これが必要な理由は、現時点ではスマート コントラクト ウォレットが包含リストから実際に恩恵を受けていないためです。スマート コントラクト ウォレットは、プロトコル層でのいかなる種類の検閲耐性保証からも実際には恩恵を受けません。 プロトコル内にアカウントの抽象化があれば、彼らは恩恵を受けるでしょう。たくさんのことがあり、実際、これらの多くは L2 センターのビジョンと L1 センターのビジョンにおいて価値があります。 私が議論したさまざまなアイデアのうち、約半分はおそらくイーサリアムの L2 ソリューションに特化したものですが、残りの半分は基本的に L2 をベース レイヤとして、L1 またはユーザーへの直接アプリケーションを使用するイーサリアム ユーザーに適用できます。 ライトクライアントをどこでも使用できる 多くの意味で、私たちが業界とどのように関わっているかは少し悲しいことです。私たちは分散していて、信頼できません。この部屋の誰が自分のコンピューター上でコンセンサスを検証する軽量クライアントを実行しているでしょうか?レア。 Infura のブラウザ ウォレットを信頼してイーサリアムを使用するのは誰ですか? 5年後には挙手の数が逆転してほしいと思っています。 Infura を一切信用しないウォレットを見てみたいと思います。ライトクライアントを統合する必要があります。 Infura は引き続きデータを提供できます。つまり、Infura を信頼する必要がない場合、インフラストラクチャの構築とデプロイが容易になるため、Infura にとっては実際には良いことですが、信頼要件を削除するツールがあります。 私たちにできることは、エンドユーザーが Helios ライト クライアントのようなものを実行するシステムを構築できることです。実際にはブラウザ内で直接実行され、イーサリアムのコンセンサスを直接検証する必要があります。チェーンとの対話など、チェーン上の何かを検証したい場合は、マークル証明を直接検証するだけです。 これを行うと、イーサリアムとのやり取りにおいて、実際にある程度の信頼性が得られます。こちらはL1用です。さらに、L2 にも同等のスキームが必要です。 L1 チェーンには、ブロック ヘッダー、状態、同期委員会、およびコンセンサスがあります。コンセンサスを検証する場合、ブロック ヘッダーが何であるかがわかっていれば、Merkle ブランチをたどって状態を確認できます。では、L2 に対して軽量のクライアント セキュリティ保証を提供するにはどうすればよいでしょうか。 Rollup ベースの場合、L2 のステート ルートが存在し、そのスマート コントラクトに L2 のブロック ヘッダーが格納されます。または、事前確認がある場合は、事前確認が誰であるかを保存するスマート コントラクトがあるため、事前確認が誰であるかを判断し、その署名の 3 分の 2 のサブセットを聞きます。 したがって、イーサリアムのブロック ヘッダーを取得すると、検証できる非常に単純な信頼チェーン、ハッシュ、マークル ブランチ、署名が得られ、簡単なクライアント検証を行うことができます。どの L2 にも同じことが当てはまります。 私は過去にこのことを人々に話したことがありますが、多くの場合、その反応はこうでした。L2 の多くはマルチシグネチャです。マルチ署名を検証するためにマルチ署名を信頼しないのはなぜでしょうか? 幸いなことに、昨年の時点では、これは実際にはもう真実ではありません。 Optimism と Arbitrum はロールアップの第 1 フェーズにあり、実際にはチェーン上で実行されている証明システムと、脆弱性が発生した場合にそれらをカバーできるセキュリティ委員会を備えていますが、セキュリティ委員会は非常に高い投票基準を通過する必要があります。 、8 人の 75% が言うと、Arbitrum の規模は 15 人に増加します。つまり、Optimism と Arbitrum の場合、それらは単なるマルチシグではなく、実際の証明システムがあり、それらの証明システムは、少なくともどのチェーンが正しいか間違っているかを決定する際に大多数の権限を持つという点で、実際に役割を果たしています。 。 EVM はさらに進んでおり、セキュリティ委員会さえないと思います。そのため、完全にトラストレスです。私たちはこれに関して本格的に前進し始めており、他の多くの L2 も同様に前進していることを私は知っています。したがって、L2 は単なるマルチシグではないため、L2 のライト クライアントの概念が実際に意味を持ち始めます。 今日ではコードを書くだけで、すでに Merkle ブランチを検証できます。明日には、ZKVM も検証できるようになるので、ブラウザー ウォレットでイーサリアムと L2 を完全に検証できるようになります。 ブラウザウォレットでトラストレスなイーサリアムユーザーになりたい人がいるでしょうか?素晴らしい。携帯電話でトラストレス・イーサリアム・ユーザーになりたいと思う人は誰でしょうか? Raspberry Piからはどうなるでしょうか？スマートウォッチではどうでしょうか？宇宙ステーションから？それも修正します。したがって、必要なのは、通信しているサーバーだけでなく、実際のライト クライアント認証命令も含む RPC 構成と同等のものです。これは私たちが取り組めることです。 反量子戦略
量子コンピューティングまでの時間は短縮されています。 Metaculous は、量子コンピューターは 2030 年代初頭に登場すると考えていますが、それより早いと考える人もいます。 したがって、量子耐性戦略が必要です。私たちは量子耐性戦略を持っています。イーサリアムには量子コンピューティングに対して脆弱な部分が 4 つあり、それぞれに自然な代替手段があります。 Verkle Tree に代わる量子耐性のある代替手段は Starked Poseidon Hash です。または、より保守的である場合は、Blake コンセンサス署名を使用できます。現在は BLS 集約署名を使用していますが、これは Stark 集約署名で置き換えることができます。 Blob は KZG を使用します。これは、分離エンコードされたマークル ツリー Stark を使用して証明できます。ユーザーアカウントは現在 ECDSA SECP256K1 を使用していますが、これはハッシュベースの署名やアカウントの抽象化と集約、スマート コントラクト ウォレット ERC 4337 などに置き換えることができます。 これを取得すると、ユーザーは基本的にハッシュベースの署名を使用して、独自の署名アルゴリズムを設定できます。ユーザーのウォレットがハッシュベースの署名に簡単にアップグレードできるように、ハッシュベースの署名を実際に構築することを本当に考え始める必要があると思います。 プロトコルの簡素化 堅牢なベースレイヤーが必要な場合、プロトコルはシンプルである必要があります。 2014 年に Vitalik という名前の人が思いついたランダムで愚かなアイデアのせいで、73 個のランダムなフックや下位互換性が存在するべきではありません。 したがって、本当に簡素化し、技術的負債を本当に排除し始めることには価値があります。現在、ログはブルーム フィルターに基づいていますが、これはうまく機能せず、速度も十分ではありません。そのため、より強力な不変性を追加するにはログの改善が必要です。これはステートレス側ですでに実行されており、基本的に各ブロックの訪問の状態を制限します。 イーサリアムは現時点で信じられないほどのコレクションです。RLP、SSZ、API があり、理想的には SSZ だけを使用する必要がありますが、少なくとも RLP、状態、およびバイナリ マークル ツリーを削除する必要があります。バイナリ マークル ツリーを取得したら、すべてのイーサリアムはバイナリ マークル ツリー上にあります。 Fast Finality、Single Slot Finality (SSF) は、コンセンサス エラーを引き起こすことが多い ModX プリコンパイラーなどの未使用のプリコンパイラーをクリーンアップします。これを削除して、高性能の Solidity コードに置き換えることができれば素晴らしいと思います。 要約する 堅牢なベースレイヤーとして、イーサリアムには非常にユニークな利点があり、その中にはコンセンサス分散化や 51% の攻撃回復に関する重要な研究など、ビットコインにはない利点もあります。 そういった強みをしっかりと強化していく必要があると思います。また、非常に高い基準を確実に満たすために、自分たちの欠点を認識して修正します。これらのアイデアは、積極的な L1 ロードマップと完全に互換性があります。 イーサリアム、特にコア開発プロセスに関して私が最も満足していることの 1 つは、並行して作業する能力が大幅に向上したことです。それが強みであり、実際に多くのことに並行して取り組むことができます。したがって、これらのトピックを考慮しても、L1 および L2 エコシステムを改善する能力には実際には影響しません。たとえば、暗号化を容易にするために L1 EVM を改善します。 EVM でのポセイドン ハッシュの検証は、現時点ではコストが高すぎます。 384 ビット暗号化も高価すぎます。 そのため、SIMD オペコード、EVM 最大値など、EOF に加えていくつかのアイデアがあります。この高性能コプロセッサを EVM に接続する機会があります。これは、証明の検証が安価になるためレイヤー 2 に適しており、zk SNARK などのプライバシー プロトコルが安価であるためレイヤー 1 アプリケーションに適しています。 プライバシー契約を使用したのは誰ですか? 80 ドルではなく 40 ドルの手数料を払いたい人がいるでしょうか?前者を選ぶ人が増えるだろう。 2 番目のユーザー グループはレイヤー 2 でトランザクションを実行でき、レイヤー 1 ではコストを大幅に削減できます。 ​