EIP-7805: フォークチョイス強制インクルージョンリスト（FOCIL）

Ethereum Cat HerdersによるPEEPanEIPのエピソード141。ホストのPooja Ranjan氏が、イーサリアム財団のRobust Incentives Groupの研究者であり、EIP-7805 (新しいタブで開く)の共同執筆者であるThomas Thiery氏とJulian Ma氏を迎え、フォークチョイス強制インクルージョンリスト（FOCIL：Fork-choice enforced Inclusion Lists）について解説します。イーサリアムにプロトコルレベルの検閲耐性が必要な理由、そのメカニズムの仕組み、そして実装の現状について語ります。

このトランスクリプトは、Ethereum Cat Herdersによって公開された元のビデオのトランスクリプト (新しいタブで開く)のアクセシブルなコピーです。読みやすさを考慮して軽く編集されています。

イントロダクション (0:35)

Pooja Ranjan: こんにちは。PEEPanEIPへようこそ。この番組は、イーサリアム改善提案（EIP）を深く掘り下げ、エコシステムへの影響を探る唯一無二の番組です。Ethereum Cat Herdersがお送りするエピソード141です。ホストのPooja Ranjanです。本日は、EIP-7805「フォークチョイス強制インクルージョンリスト（Fork-choice enforced Inclusion Lists）」についてお話しします。

2024年11月に文書化されたEIP-7805は、現在ドラフト段階にあるスタンダードトラックのコア提案です。この提案は、バリデータのコミッティがすべてのブロックに一連のトランザクションを強制的に含めることができるようにすることを目的としています。Thomas Thiery、Francesco D'Amato、Julian Ma、Barnabé Monnot、Terence Tsao、Jacob Kaufmann、Jihoon Songによって共同執筆されたこの提案は、将来のアップグレードに向けて活発に議論されています。

このエピソードでは、EIP-7805の詳細、その意味合い、そしてイーサリアムのエコシステムに与える潜在的な影響について探ります。この提案についてさらに詳しくお話しいただくため、Thomas Thiery氏とJulian Ma氏にお越しいただきました。PEEPanEIPへようこそ。

Thomas Thiery: お招きいただきありがとうございます。

Julian Ma: はい、お招きいただき本当にありがとうございます。

Pooja Ranjan: 提案の概要、現在の状況、そしてイーサリアム・メインネットでいつ頃見られるようになるのかについて学べることを楽しみにしています。しかし、本題に入る前に、私たちのコミュニティは、プロジェクトの背後にいる研究者や開発者のことを知るのが大好きです。ご自身のこと、現在携わっているプロジェクト、そしてイーサリアムのエコシステムにおけるこれまでの歩みについて少し教えていただけますか？

ゲスト紹介 (2:14)

Julian Ma: はい、私から始めます。私はJulianです。Thomasと同じく、イーサリアム財団のRobust Incentives Groupで研究者をしています。Robust Incentives Groupは、プロトコルの経済学全般に広く関心を持っています。私たちのグループには、EIP-1559のようなトランザクション手数料メカニズムを研究しているメンバーもいれば、主に経済的インセンティブを動機とするコンセンサス・レイヤーへの攻撃について研究しているメンバーもいます。

私自身は、基本料金のデリバティブを調査するインターンシップから始まり、その後フルタイムで参加しました。主にプロポーザー・ビルダー分離 (PBS) やMEV関連のトピックに取り組んできましたが、現在は今回のEIPによるFOCILを通じたインクルージョン・リストに注力しており、アテスター・プロポーザー分離にも期待しています。私が最もワクワクしているのは、理論的な研究から始まり、イーサリアム内で提案・実装される可能性のあるEIPへと発展させるというパイプラインを通じて、研究を本番環境に導入することです。

Thomas Thiery: Thomasです。私もイーサリアム財団のRobust Incentives Groupで研究を行っています。私のバックグラウンドは実は神経科学の博士号であり、全く異なる分野でした。しかし、ブロックチェーンや分散型システムに興味を持ち、少し違うことに挑戦したいと思い、Duneという暗号資産データ企業に入社しました。そこにしばらくいましたが、研究が恋しくなり、幸運にもイーサリアム財団（EF）とRobust Incentives Groupに参加することができました。これまでのところ、とても素晴らしい経験になっています。

私も似たようなトピックに取り組んできました。私が参加した当時、MEVは非常に大きなテーマでした。面白いことに、私の最初の研究投稿は非常に小規模なものでしたが、インクルージョンの遅延と検閲耐性に関するものでした。最近になるまで、それほど深く掘り下げることはありませんでした。ここ半年から1年ほどは、検閲耐性とインクルージョンの分野でより積極的に活動しています。研究のアイデアから始め、非常に興味深いもののこれから話すような詳細が含まれていなかった過去のアイデアを改善し、提案をまとめ、そして今では私が話をしたほとんどの人がイーサリアムへの良い追加機能になると考えている実装やデブネットを持てるようになったのは、本当に素晴らしいことです。

Pooja Ranjan: 共有していただきありがとうございます。開発者のバックグラウンドを知ることは常に刺激になります。異なる分野から来て、最終的にイーサリアムのエコシステムに貢献しているのを見るのは興味深いですね。本日はプレゼンテーションをご用意いただいているとのことですね。それでは早速、見ていきましょう。

プレゼンテーション：FOCILの目標 (5:16)

Julian Ma: 完璧です、本当にありがとうございます。まずは、EIP-7805、つまりFOCILがどのように機能するのか、そしてなぜ私たちがそれを実行したいのかについての短いプレゼンテーションから始めたいと思います。これは対話のきっかけとなることを意図しているため、後で議論の余地を残すように、あまり深くは掘り下げません。

FOCILの主な目標は、イーサリアムの信頼できる中立性を高めることです。FOCILは、現在単一のプロポーザーやブロック・ビルダーが1つのスロット内で握っている、包含の独占権を排除することでこれを実現します。その代わりに、FOCILは複数のバリデータが各ブロックにトランザクションを含めることで、ブロックの構築に貢献できるようにします。

より高次元の目標は、私たちがチェーンの中立性と呼ぶ特性を追求することです。これは、保留中の手数料を支払うトランザクションが利用可能であり、オンチェーンに含める余地がある場合、それを含めるべきであるということを意味します。この特性が十分に満たされれば、イーサリアムの信頼できる中立性が高まると私たちは信じています。

なぜFOCILが必要なのか、そしてなぜ今なのか？ (6:09)

ジュリアン・マー: なぜこのようなものが必要なのでしょうか？現在、ほぼすべてのバリデータがブロックの構築をMEV-Boostに委託しています。これは、ビルダーがブロック構築の権利を入札するプロトコル外の市場です。この市場では、実質的に2つの事業体だけが支配的であり、これはブロックの90%がわずか2つの事業体によって構築されていることを意味します。

ここからわかるように、イーサリアムはもはやローカルでのブロック構築から信頼できる中立性を得ることはできません。かつてはそうでした。当初は、世界中にプロポーザーが存在し、それぞれがローカルでブロックを構築していたため、すべてのトランザクションが含まれていました。しかし、ブロック構築がこれらの高度な事業体に委託されている現在、これではもはや十分ではありません。そのため、より堅牢な検閲耐性対策を実装する必要があり、FOCILはそれを行うための最もよく知られた方法です。

なぜ今、FOCILを実装すべきなのでしょうか？現在はビルダーによる検閲はそれほど多くないと思われるかもしれませんが、規制上の理由であれ経済的な理由であれ、彼らはいつでも検閲を始める可能性があります。そして、経済的検閲は決して軽視すべき問題ではありません。また、検閲が比較的少ない時期にFOCILを導入するのも良いことです。なぜなら、それをベースラインおよびデフォルトとして導入できるからです。すべてのバリデータは、管轄区域や経済的インセンティブに関係なくインクルージョンリストを作成するため、市場の不安定化をほとんど引き起こしません。一方で、すべてのビルダーが検閲を行っている状況でFOCILを導入しようとすれば、おそらくもっと困難になるでしょう。

さらに、最近ではベースド・ロールアップが普及しつつあり、これらはイーサリアムのブロック構築に依存するようになります。イーサリアムが持つシーケンシングを提供したいのであれば、FOCILを通じてここで信頼できる中立性を確保することが必要です。

また、人によっては、FOCILがスケーリングに役立つ可能性があると考えています。今日でも、イーサリアムは依然としてローカルでのブロック構築から検閲耐性を得ています。もしイーサリアムが、例えばFOCILを通じて他の場所から検閲耐性を得ることができるようになれば、ブロック・ビルダーに対する期待値を高め、例えばより多くのブロブを許可できるようになるかもしれません。しかし、これはFOCILなしでも実現できる可能性があります。したがって、FOCILはフサカでの実装が提案されています。

FOCILの仕組み (8:10)

Julian Ma: それでは、FOCILの仕組みについて説明します。基本から始めて、メカニズムの全体像が把握できるまで順を追って説明し、その後、このメカニズム全体が私たちが求める特性をどのように満たしているかを探ります。

Mike Neuder氏によって以前にも提案されたインクルージョン・リストの基本的なアイデアは、ブロックを何らかの形で制約するトランザクションのリストが存在するということです。たとえば、トランザクションAとBを含むインクルージョン・リストがあり、プロトコルによって承認された誰かによって署名され、これらのトランザクションが何らかのブロックに含まれなければならないとします。FOCILはこれを変更するものではありません。これを基盤として構築されており、誰がこのリストを作成し、どのようにこのリストを強制するかに重点を置いています。

では、誰がこのリストを作成するのでしょうか？これがFOCILプロトコルが機能する最初のステップです。各スロットで、16のバリデータがインクルージョン・リストのコミッティ・メンバーとして選出されます。これらのコミッティ・メンバーはそれぞれメンプールを監視し、独自のインクルージョン・リストを構築します。1つのインクルージョン・リストは約8キロバイト、つまり平均的なトランザクション約20個分であり、全体で平均約320個のトランザクションになります。

2つ目のステップは、これらのインクルージョン・リストの配布です。インクルージョン・リストのコミッティ・メンバーは、グローバル・トピックを通じてインクルージョン・リストを配布しますが、彼ら自身がそれらをブロックに含めるわけではありません。彼らはスロットの9秒目までにこれを行う必要があり、その時点でアテスターはローカルのインクルージョン・リストのビューを凍結（フリーズ）します。次のステップで見るように、名前（フォークチョイスによって強制されるインクルージョン・リスト：fork-choice enforced inclusion lists）が示す通り、これらのインクルージョン・リストを実際に強制するのはアテスターです。彼らは9秒目にどのインクルージョン・リストを強制するかのビューを凍結し、これによりスプリットビュー攻撃を防ぎます。ブロック・プロデューサーには、インクルージョン・リストを監視し、インクルージョン・リストを見逃すことによる悪影響を受けないように確認するための数秒の猶予がまだあるため、この設定においてブロック・プロデューサーにリスクはありません。

そして、最後のステップである強制（エンフォースメント）に進みます。先ほど述べたように、強制はフォークチョイスを通じて行われます。アテスターは、インクルージョン・リストの条件を満たす場合にのみ、ブロックに投票します。彼らは、グローバル・トピックで送信されたインクルージョン・リストを監視し、これらのインクルージョン・リストで確認したトランザクションの集約リストを作成し、それらのトランザクションがすべてブロックに含まれているかどうかを確認することでこれを行います。このチェックに合格した場合、彼らはブロックに投票します。インクルージョン・リストのすべてのトランザクションがブロックに含まれていないものの、ブロックが満杯であるというケースもあり得ます。その場合も、アテスターはブロックに投票します。したがって、ブロックにトランザクションが含まれておらず、かつ満杯でない場合を除き、アテスターはブロックに投票します。

メカニズム全体を要約すると、各スロットで16のコミッティ・メンバーがインクルージョン・リストのコミッティ・メンバーとして選出されます。彼らはメンプールを監視し、インクルージョン・リストのオブジェクトを構築して、期限（この場合は9秒目）までにグローバル・トピックを通じて配布します。ビルダーはこれらのインクルージョン・リストを監視し、確認したすべてのトランザクションを自身のブロックに含めます。その後、アテスターは、9秒目より前にインクルージョン・リストで確認したすべてのトランザクションが実際にブロックに含まれているかどうかをチェックします。このチェックに合格すると、彼らはブロックに投票し、次のスロットに進み、そこで同じセットアップが再び行われます。

IL Boostと非過密性 (11:07)

Julian Ma: インクルージョン・リストに関する大きな懸念事項の1つは、Mikeによる以前のEIPやその後の開発中に声高に叫ばれた「IL Boost」、つまり非過密性（uncrowdability）です。これは、インクルージョン・リストのプロポーザーが、インクルージョン・リストを構築する権利を販売したがる可能性があるという事実を指しています。ブロック構築においてこのような事態が発生しているのを私たちは目の当たりにしているため、これは非常に論理的な懸念です。この権利を販売することは、洗練されたビルダーによる中央集権的な市場につながります。

私たちは、以下の特性により、FOCILがこれらのMEV-Boostのような市場、あるいは通称IL Boostと呼ばれるものに対して堅牢であると主張します。FOCILはトランザクションの順序付けを一切保証しません。インクルージョン・リストのどこにトランザクションを配置したかに関係なく、ブロック・ビルダーが適切だと考える任意の順序で順序付けられます。例えば、リストにアービトラージ（裁定取引）のトランザクションを含めたとしても、ビルダーがそのアービトラージ・トランザクションをブロックの先頭に配置して実際にアービトラージを実行させる可能性は極めて低いです。代わりに、ビルダーはおそらく自分自身でそれを行うでしょう。

さらに、プライベートなオーダーフローは不可能です。これらのインクルージョン・リストはグローバルなトピック上で分散されるため、ビルダーがブロックを構築する前にトランザクションは公開されます。インクルージョン・リストを介してプライベートなオーダーフローをブロックに含めることはできません。

第三に、スロットごとに複数のインクルージョン・リストのプロポーザーが存在します。仮に販売する価値のあるものがあったとしても、16人のインクルージョン・リストのコミッティ・メンバー全員がこのインクルージョン・リストを構築する同じ可能性を持っているため、インクルージョン・リストのプロポーザー間の競争によってその価値はゼロにまで下がるでしょう。

そして最後に、これらのインクルージョン・リストはブロック生成者が行動する3秒前に作成されます。インクルージョン・リストがコミットされてからブロック生成者が行動するまでの間に、MEVタイプのトランザクションにとって通常極めて重要となる3秒分の追加情報が到着します。つまり、情報面での優位性はほとんどありません。実際には、インクルージョン・リストをMEVの手段として利用しようとする者にとっては、情報面で不利になります。

これらの理由から、個々のインクルージョン・リストのプロポーザーは、MEVの根本的な定義である、包含、順序付け、または除外の権限を持っていないと私たちは考えています。したがって、インクルージョン・リストはMEVの対象にはならないはずです。

プレゼンテーションのまとめ (13:09)

ジュリアン・マ: この短いプレゼンテーションをまとめると、FOCILは複数のバリデータがブロック構築に貢献できるようにすることで、単一のプロポーザーによるインクルージョンの独占を防ぎ、イーサリアムの信頼できる中立性を高めます。現在、いつでも検閲を始める可能性のある支配的なビルダーが2つしか存在せず、それが彼らに利益をもたらす経済的な理由による可能性があるため、今すぐFOCILを実装する必要があると考えています。ベースド・ロールアップがイーサリアムのシーケンシング特性を利用しようとするため、ブロック構築はより大きな負荷を担うようになる可能性があります。検閲を行う当事者が少ない場合、FOCILははるかにスムーズにローンチされます。第一に、バリデータがインクルージョンリストを構築することがデフォルトになるためであり、第二に、検閲を行うビルダーと行わないビルダーの間で市場の不安定性が少なくなるためです。そして最後に、FOCILはスケーリングに役立つ可能性があり、これについてはさらに深く掘り下げることができるテーマかもしれません。

この短いプレゼンテーションの時間をいただき、ありがとうございます。興味のある方のために、EIPへのリンクとなるQRコードをお見せしたいと思います。

プージャ・ランジャン: 短いプレゼンテーションと提案の概要をありがとうございました。

Q&A: EIP-7805はEIP-7547とどう違うのか？ (14:17)

Pooja Ranjan: Q&Aセッションの最初の質問として、プレゼンテーションでも言及されていた以前の提案、Mike Neuderによる提案7547（インクルージョン・リスト）についてお聞きしたいと思います。その提案と、7805のFOCILとの基本的な違いを理解したいです。プレゼンテーションの中で、IL Boostとuncrowdability（混雑回避性）について少し触れられていましたね。これについてもう少し詳しく説明していただけますか？

Julian Ma: 7805が7547とどう違うかについては、おそらくThomasが答えるのが最適だと思いますが、私からも少しお話しできます。まず第一に、7547が次のスロットを対象としていたのに対し、FOCILは同じスロットを対象としています。同じスロットであるという特性により、インクルージョン・リストをオンチェーンに保存する必要がなくなるため、いくつかの点がより簡単になります。

uncrowdability（混雑回避性）の特性に関しては、非常に興味深く、微妙な問題です。私たちの提案の基盤となった素晴らしい提案である7547では、インクルージョン・リストは無条件にブロックの最後に追加され、1人の人物によって作成されます。これには、私たちの提案とは異なるいくつかの特性があります。まず第一に、トランザクションが順序付けられている点です。将来的には、ブロックの最後（bottom-of-block）でのアービトラージが非常に価値を持つようになる可能性があり、実際にThomasの研究でも、ここが潜在的に価値のある場所になり得ることが強調されています。インクルージョン・リストを構築する権利を持つということは、ブロック内で最後に行動する人物になるということであり、場合によってはこれが価値を持つかもしれません。第二に、それがたった1人の人物によって作成されるため、インクルージョン・リストのコミッティ・メンバー間で競合する効果が生じません。1人だけのコミッティが、ブロックの最後にトランザクションを含める完全な権利を持つため、これもまた価値を高める可能性があります。第三に、この無条件という特性があります。つまり、ブロック生成者が何をしようとも、あなたのトランザクションはとにかくオンチェーンに含まれるということです。そのため、インクルージョンに必要な最低限の保証を超えた、いくつかの追加の保証があり、それがある程度価値を持つ可能性があります。

Thomas Thiery: 大きな違いとして、インクルージョン・リストのプロポーザーの数も挙げられます。以前の提案では、スロットnのプロポーザーがインクルージョン・リストを作成し、スロットn+1のプロポーザーがそれを強制する必要があるというメカニズムでした。ここでの2つの大きなポイントは、まず1スロットの遅延があるため、インクルージョン・リスト内のトランザクションは、次のプロポーザーによって次のスロットに含まれさえすればよいということです。そして、実際にインクルージョン・リストを作成するプロポーザーは1人だけです。FOCILでは、これが16人になります。これは非常に大きな違いを生み出します。なぜなら、メカニズム全体が意図した通りに機能するためには、16人のILコミッティ・メンバーのうち1人だけが誠実であればよくなるからです。以前は単一の当事者に依存していましたが、これにより、優れた検閲耐性メカニズムを実際に実現できる可能性が何倍にも高まります。

さらに技術的な詳細についてですが、アカウント抽象化との間にいくつかの非互換性があり、ILのエキボケーション（誰かが2つの異なるインクルージョン・リストを送信すること）に対処するのが困難でした。ブロックのエキボケーションは既知の問題であり、プロトコルによってペナルティが科されますが、以前の提案ではすべてがオンチェーンで行われていたため、奇妙なエッジケースにも対処しなければならず、それらに対応するのはあまり簡単ではありませんでした。FOCILでは、インクルージョン・リストはオンチェーンには行きません。それらはP2Pのコンセンサス・レイヤーのネットワーク上でブロードキャストされるだけです。少し技術的になりますが、アカウント抽象化によって引き起こされるこれらのエッジケースや、ILのエキボケーションによってネットワークを2つのビューに分割するような攻撃に対処する上で、これは大きな違いをもたらします。

Pooja Ranjan: 本当にありがとうございます。提案7547についてもっと知りたい方のために、Mike Neuderを招いたPEEPanEIPのエピソード130の録画があり、そこでハイレベルな概要が説明されています。私は競合する提案を見るのがいつも好きです。なぜなら、それがエコシステムとチェーンの改善につながることを知っているからです。チャットにいくつか質問があるようです。Katayaさんに質問を共有していただきましょう。

プロポーザーは16個のリストすべてを含める必要がありますか？ (19:05)

カタヤ: こんにちは、ありがとうございます。私の質問は、ブロック・プロポーザーは各コミッティメンバーから1つずつ、合計16個のインクルージョン・リストを受け取り、それらのリストに含まれるすべてのトランザクションを含める必要があるのでしょうか？

トーマス・ティエリー: はい、その通りです。すべてのリスト（今回の場合は16個のリスト）にあるすべてのトランザクションの和集合をとります。当然、重複がある可能性があるので、和集合をとって重複を排除します。しかし、はい、アテスターによってブロックが有効であると見なされるためには、すべてのリストにあるすべてのトランザクションがブロックに含まれている必要があります。

プージャ・ランジャン: チャットの次の質問はジャスティンからです。ジャスティン、ゲストに向けて質問を読んでいただけますか？

インクルージョン・リストにおけるプライベート・メンプールのトランザクション (19:55)

Justin: たくさん質問してしまってすみません。プライベート・メンプールからのトランザクションをインクルージョン・リストに入れるのを防ぐものは何かと聞きたかったのですが、すでに十分に回答されたと思います。ビルダーは結局のところ自分たちが適切だと考える順序でそれらを並べ替えることになりますし、IL（インクルージョン・リスト）に出た時点でトランザクションは公開されることを考慮すると、それは全く問題ないように聞こえます。ですので、理にかなっていると思います。ありがとうございます。

Thomas Thiery: Julianが言及したように、それは考慮事項の一つでした。私たちは、FOCILやインクルージョン・リストがMEVトランザクション、プライベート・オーダーフロー、またはプレコンファメーションを含めるために使用されることを本当に望んでいませんでした。なぜなら、私たちが最終的に求めているのは検閲耐性であり、注意しないと、メカニズムが価値のあるトランザクションを含めるための手段になりやすいからです。トランザクションをインクルージョン・リストに含めると自動的に公開され、誰でも見ることができるようになり、順序の保証がなく、ビルダーによってブロック内のどこにでも含められる可能性があるという事実は、価値のあるトランザクションにはあまり適していないことを意味します。

したがって、公開トランザクションがあり、それをインクルージョン・リストに含めるためにパブリック・メンプールに送信するだけの場合もあれば、価値のあるプライベート・トランザクションがあり、その場合はFOCILを経由しない場合もあります。なぜなら、より良い方法があるからです。ビルダーに直接連絡し、プライベートなチャネルを通じて送信することになるでしょう。

Pooja Ranjan: 共有していただきありがとうございます。次の質問はLadislausからのようです。

FOCILとスケーリング (21:41)

Ladislaus: こんにちは。これは、FOCILとスケーリングに関して皆さんが提起したポイントに関連しています。最近、誰もがそうであるように、イーサリアムのスケーリングに関する議論を目にしていますが、皆さんが正しく指摘したように、そこには少数のビルダーによるボトルネックが存在します。個人的には、FOCILはローカルでのブロック構築に再び力を与えるものだと考えており、帯域幅の要件やノードの要件全般を引き上げる前に、プロトコルに組み込まれる必要があると考えています。これについてどう考えているか、また、言及されていたように、FOCILを使わない他のスケーリングの可能性についても詳しく教えていただけますか？

Julian Ma: 質問ありがとうございます。まず、FOCILによるスケーリングのケースについてです。現在、バリデータの90%がMEV-Boostを通じてブロック構築を外部委託しており、これらの高度なエンティティは明らかに最小ハードウェア要件以上の帯域幅を持っています。例えば、問題を引き起こすことなく、ブロックにより多くのブロブを含めることができます。しかし興味深いことに、イーサリアムは信頼できる中立性、つまり検閲耐性をローカルでのブロック構築に依存しています。なぜなら、これら2つの高度なエンティティは、イーサリアムの検閲耐性の基盤となるものではないからです。

したがって、イーサリアムのプロトコルは依然としてローカルでのブロック構築が可能であるように設計されなければならず、実際、MEV-Boostと比較して不採算にならないように設計されています。これはイーサリアムの設計上のことですが、現実にはもちろん、MEV-Boostの方がはるかに収益性が高くなります。第一に、これらの高度なブロック・ビルダーはより複雑なアルゴリズムを持っているためであり、第二に、はるかに多くのプライベートなオーダーフローを持っているためです。最近のData Alwaysによる調査では、MEV-Boostのブロックにははるかに多くのトランザクションが含まれていることが示されています。それだけでもより多くの利益につながります。

それでも、プロトコルは、あるバリデータが他のバリデータよりも収益性が低くなるような力がプロトコルのルール内から働かないように設計されています。そのルールを維持したいのであれば、FOCILが必要です。なぜなら、そうすればローカルのブロック・ビルダーがインクルージョンリストに貢献し、それによって検閲耐性を維持できるからです。しかし、このルールを廃止し、基本的にはローカルのブロック・ビルダーは一定数のブロブを含めることができるが、より高度なブロック・ビルダーは、ローカルのブロック・ビルダーが自分でブロックを作成する際にその負荷を処理できない程度まで、より多くのブロブを含めることができる、とすることも可能です。つまり、最大値が最低のハードウェア要件に設定されるというルールを維持したいのであれば、FOCILが必要です。そのルールを緩和しても構わないのであれば、スケーリングにFOCILは必要ないかもしれません。

Thomas Thiery: 非常に似ていると思いますが、現在イーサリアムでは奇妙な状況にあります。なぜなら、ほとんどのブロックを構築するために高度なビルダーに依存していますが、それらはわずか2つの当事者であるため、検閲耐性の観点からは好ましくないからです。もし彼らが任意の理由でトランザクションや一部のアドレスを検閲することを決定した場合、基本的には検閲耐性や、同様に非常に重要なパーミッションレス性が失われることになります。つまり、彼らが望むあらゆるアクターを検閲したり、オンチェーンへの参加を制限したりできるということであり、これは非常に悪いことです。

そして、私たちが維持している検閲耐性の特性も素晴らしいとは言えませんよね？ほとんどのブロックがこれら2つのビルダーによって構築されているため、基本的には、あるローカルのブロック・ビルダーが選出され、通常は検閲されるこれらのトランザクションをすべて含むブロックを提案するまで待つ必要がありますが、これは良い状況とは言えません。つまり、これらのユーザーは、自分のトランザクションが実際にオンチェーンに含まれるまで、10ブロック、12ブロック、あるいはもっと多くのブロックを待たなければならないということです。

したがって、私たちはホームステーカーやローカルのブロック・ビルダーを本当に維持したいと考えています。なぜなら、彼らこそが検閲耐性を維持しているからです。同時に、今日では彼らを利用することさえも素晴らしいとは言えません。なぜなら、2つのビルダーによって検閲された場合、トランザクションが含まれるまでに依然として長い時間を待たなければならないからです。FOCILを使用すると、検閲耐性を保証する参加者（私たちの場合はインクルージョンリストのコミッティメンバー）が、ブロックを構築する人々とは異なるかもしれない世界へと移行します。これは非常に興味深い展望を開くものだと思います。なぜなら、価値のあるブロックを構築することと検閲耐性に貢献することの両方を、全く同じ参加者に依存する必要がなくなるからです。FOCILは、その重要な方向への第一歩と考えることもできます。なぜなら、2つの非常に異なる役割があり、今日では全く同じバリデータノードに両方を行うよう求めており、それが大きな緊張関係を生んでいるからです。

Pooja Ranjan: 本当にありがとうございます。次の質問はLuisさんからだと思います。

トランザクションを選択する基準 (26:46)

Luis Pinto: 開始から数分後に参加したのですが、これはネットワーク全体でトランザクションの選択を分散化しているように見えます。私の意見では、これは非常に良いことです。MEVや検閲に対抗できるからです。そして、アテスターにこの役割を担わせるという部分が間違いなく気に入っています。なぜなら、将来的にはアテスターのハードウェア要件はビルダーよりも低くなり、ステートレス性やステートレス・クライアントの導入によってさらにそうなるからです。非常に低いハードウェア要件でこれを実行できるようになるため、物事が非常に分散化されます。ここでの主な課題は、これらのインクルージョン・リストのトランザクション選択基準を定義することだと思います。優先手数料でいくのか、ブロブの数でいくのか、非常に多くの変数が存在します。強制しようと考えている一連の基準にはすでに落ち着いているのでしょうか？

Thomas Thiery: 素晴らしい質問です。これには2つの側面があります。1つ目は非常に重要なことで、アテスターをブロックを構築または提案する人々から分離しようとする試みについてです。これがアテスター・プロポーザー分離（APS）という一連の研究の全体像であり、Julianはこれにかなり取り組んできました。私たちはこれを役割のアンバンドルと呼んでおり、それによってプロトコルの義務により密接に一致するようにしています。私は、考えられる分離についての記事を書き、先ほど共有しました。これは非常にオープンなものであり、皆さんからより多くの意見をいただきたいと思っています。この記事では、アテスター、インクルーダー（現在のILコミッティのメンバー）、そして実行プロポーザー（またはビルダー）の間で分離を行っています。これらは根本的に異なる義務であり、おそらくそれぞれに異なる役割を設けるべきだと考えています。

次に、インクルージョン・ルールについてですが、これは非常に良い質問です。私たちはこれについてかなり考え、2つの結論に達したと思います。1つ目は、ルールの多様性を求めているということです。すべてのクライアントに対して優先手数料の降順で並べ替えるといった、単一のルールは望んでいません。なぜなら、そうしてしまうと、実際にシステムを悪用し、自分のトランザクションだけがILに含まれるようにメンプールを並べ替えようとすることが可能になるからです。しかし、トランザクションがメンプールで保留されている時間を考慮するルールを含め、多様なルールが存在し、異なるクライアントが異なるルール（すべて同じような性質で、主に優先手数料とメンプールでの保留時間を中心としたもの）を実装していれば、システムを悪用することは非常に困難になり、プロトコルはさらに堅牢になります。また、これは現在のイーサリアムにあるクライアントの多様性を活かし、クライアントに独自の選択をさせるための良い方法でもあると思います。私たちは念頭に置いているルールがありますが、クライアント自身が最適なルールを選択することもできると考えています。全員が優先手数料で並べ替えるという全く同じルールを持たない限り、問題ありません。

Luis Pinto: なるほど、つまりこの基準も分散化し、インクルージョン・リストを構築する人々に独自の基準を持たせるということですね。それとも、これはプロトコルの一部になるのでしょうか？

Julian Ma: インクルージョン・ルールはプロトコルの一部にはなりません。第一に、強制するのは非常に困難ですし、第二に、実際には何も強制しない方が良いからです。コミッティのメンバーが自分で決定できるようにするか、クライアント・チームが彼らに代わってトランザクションを含める方法を決定できるようにすれば、ネットワークに一定の堅牢性が生まれます。異なる好みを持つ人々が異なる方法で含めるようになるため、システムを攻撃することがより困難になることを意味します。

Luis Pinto: わかりました、ありがとうございます。

EIP-7702、ePBS、およびPeerDASとの互換性 (30:43)

Pooja Ranjan: 本当にありがとうございます。私の理解では、この提案はペクトラの次のアップグレードであるフサカに向けてすでに提案されています。そして、フサカには進行中の他のEIPが含まれるかどうかわからないことを考慮すると、アカウント抽象化のための7702、ePBS、およびPeerDASなどの提案に対するFOCILの互換性の状況はどうなっているのでしょうか。

Thomas Thiery: 素晴らしい質問です。インクルージョン・リストの歴史があるため、私たちはここで少し有利な立場にありました。先ほど述べたように、7547は導入が検討されましたが、互換性の問題で却下されました。そのため、新しい提案を行う前に、これらの問題を解決することに非常に注意を払いました。なぜなら、人々が同じ疑問を持ってこの提案を見るだろうとわかっていましたし、それは当然のことだからです。

私たちは非常に自信を持っています。なぜなら、アカウント抽象化のチームとも話し合いましたし、PotuzやTerenceともたくさん話し合ったからです。Terenceは私たちを積極的に支援してくれており、ePBSとFOCILの両方に取り組んでいるため、それらが互換性があるかどうかを確認するのは非常に簡単でした。他のどのEIPとも互換性の問題があるとは本当に思っていません。ePBSに関しては、実行ペイロードをコンセンサスのブロックから分離するため、スロット全体のタイミングが変わり、さらにペイロードが提案される前に作成する必要があるIL（インクルージョン・リスト）の作成も追加されるため、タイミングに注意する必要があります。そのため、タイミングには気をつける必要がありますが、私の記憶が正しければ、前回PotuzとTerenceの両方とこの件について話したとき、致命的な互換性の問題はまったくありませんでした。互換性に関しては、良い状況にあると思います。

Pooja Ranjan: それは良かったです。JihoonもHackMDを共有してくれたことに気づきました。特にePBSとの互換性について詳しく知りたい人のために、これをリソースに追加します。そしてはい、Mikeとの前回の会話から覚えているのですが、アカウント抽象化との互換性がないためにその提案は含まれなかったのだと思います。ですので、この問題がすでに対処されていると知って安心しました。

FOCILとマルチスロットMEV (33:04)

プージャ・ランジャン: FOCILのウェブサイト（meetfocil.eth.limo）に追加されたドキュメントや詳細に目を通していたところ、マルチスロットMEVという用語について知りました。ジュリアンも、開発者たちが公平に保とうと努力しているにもかかわらず、一般的にMEV-Boostは収益性が高いと述べていました。FOCILはこれをどのように防ぐのでしょうか。

ジュリアン・マ: 質問ありがとうございます。まず、FOCILとMEVについて少しお話ししてから、マルチスロットMEVの話に移りましょう。FOCILは必ずしもMEVを防ぐわけではありません。これはまさに、MEVの部分とインクルージョン（トランザクションの取り込み）の部分を分離したいと考えているからです。私たちの見解では、そうすることが重要です。なぜなら、そうしなければIL Boostのような市場が出現してしまうからです。その理屈で言えば、もしインクルージョン・リストが抽出可能なMEVの量を制限できるとしたら、インクルージョン・リストを構築する価値が非常に高くなり、人々はその周辺に市場を立ち上げるでしょう。私たちの設計は、あくまで最小限のインクルージョン保証を提供するためのものです。つまり、インクルージョン・リストのコミッティメンバーになることの価値はそれほど高くなく、メンバーは16人いるため、高度なプロデューサーによる市場は存在しないということです。

次に、マルチスロットMEVについてですが、FOCILは問題の一部を軽減しますが、完全な解決には至りません。これもまた、検閲耐性の提供とMEVの解決策を両立させることの間に互換性がないためです。FOCILが行うのは、手数料を支払う限り、あらゆるトランザクションが取り込まれるようにすることであり、これによりマルチスロットMEVはある程度解決されます。ここでのマルチスロットMEVとは、ある当事者が2つのブロックを連続して制御した場合に、より多くのMEVを抽出できる状況を指します。

FOCILは、トランザクションを挿入できるようにすることで、問題の一部を軽減します。例えば、どこかのポジションの不良債権を清算するトランザクションを挿入する必要がある場合、プロポーザーがあなたを検閲し、次のブロックであなたからMEVを抽出しようとしたとしても、あなたはそれを実行することができます。

すべての問題を解決できない理由は、逆選択（アドバース・セレクション）という、一方が他方よりも多くの情報を持っている場合に生じる経済的特性のためです。マルチスロットMEVの一例として、2つのブロックにまたがってアービトラージ（裁定取引）を抽出するケースが挙げられます。この場合、ブロック・ビルダーは最初のブロックではアービトラージを抽出せず、2番目のブロックで抽出します。両方のスロットでアービトラージを抽出するよりも、この方法の方がブロック・ビルダーにとって収益性が高くなる可能性があることを示す理論的な結果もあります。アービトラージを行う人（アービトラージャー）は原則としてインクルージョン・リストにトランザクションを含めることができ、それによって何らかのアービトラージを強制的に発生させることができるため、ここでFOCILが役立つと考えるかもしれません。確かにその通りですが、アービトラージャーがFOCILにトランザクションを送信することはインセンティブに適合しません。なぜなら、トランザクションが送信されてからブロック・ビルダーが行動できるようになるまでに、まだ3秒のタイムラグがあるからです。外部市場で価格が常に変動している状況でアービトラージを行おうとする場合、3秒前にコミットしたくはないでしょう。なぜなら、後から行動するブロック・ビルダーよりも圧倒的に情報量が少ないからです。ここで逆選択が働きます。ビルダーの方がより多くの情報を持っているため、その余分な3秒間に外部市場の価格があなたに不利に動いた場合（つまりあなたにとって悪い結果になる場合）はあなたを勝たせ、自分にとって有利な場合は自分自身を勝たせるのです。

したがって、FOCILは、トランザクションが逆選択の影響を受けないマルチスロットMEVの部分を解決します。逆選択が存在するトランザクションについては少し複雑になりますが、ある程度は問題を軽減します。原則として、現状よりは状況を改善しますが、まだ少し課題が残されています。

プージャ・ランジャン: なるほど、共有していただきありがとうございます。MEVの問題に対処するために多くの研究が進行中であることは理解していますが、少なくとも原則として、現在の状況よりも役立つ方向に向かっていると知れて良かったです。

トレードオフと課題 (36:44)

Pooja Ranjan: トーマスが先ほど言及したILエキボケーションに関連して、1つ質問があります。提案のセキュリティに関する考慮事項のセクションを見ると、コンセンサスのライブネス、ILエキボケーション、ペイロードの構築など、かなり多くのポイントが挙げられていることに気づきました。最大のトレードオフは何だとお考えですか？あるいは、さらに調査が必要で、この提案がそのまま次のアップグレードに組み込まれるのを妨げる可能性のあるものはありますか？

Thomas Thiery: 正直なところ、セキュリティに関する考慮事項のセクションは、私たちがセキュリティに関する懸念について考え、対処してきたことを示すためのものという意味合いが強いです。私たちが把握していないセキュリティ上の未解決の疑問があるというわけではありません。セキュリティの観点から見て、大きなブロッカーや問題があるとは考えていません。

トレードオフについてですが、非常に狭い見方をすれば、FOCILがバリデータにいくつかのタスクを追加するのは事実です。インクルージョン・リストを提案しなければならない時と、アテスターがインクルージョン・リストに従ってブロックが有効であることを確認するために、もう1つ条件をチェックしなければならない時の両方においてです。また、プロポーザーにとっても小さなタスクが追加されます。ペイロードにIL内のトランザクションが実際に含まれていることを確認する必要があるからです。私にとってトレードオフはそれだけであり、これらのタスクは重いものでも複雑なものでもありません。ILコミッティのメンバーは、パブリックなメンプールを監視し、送信するリストにトランザクションを含めるだけです。特別なスキルや高度な知識を必要としない点は、素晴らしいことだと思います。一方で、先ほども述べたように、これによりスケーリングの大きな改善や、プロトコル内での参加者と役割のより良い分離が実現する可能性があります。

偏見があるかもしれませんが、大きなトレードオフがあるとは思えません。検閲耐性に関しては、すべてを根本から覆すようなものだと考えています。ビルダーによって検閲される可能性のあるものも含め、すべてのトランザクションが次のブロックに含まれるためには、基本的にはネットワークのわずか15%が正直であればよくなります。これは非常に大きな改善です。正直なところ、そこで多くのものを犠牲にしているとは思いません。

Pooja Ranjan: それを聞いて安心しました。ほとんどの提案では、セキュリティに関する考慮事項のセクションに情報が全くないか、ほとんどないことが多いので、その部分について調査が行われており、起こりうるセキュリティ上の考慮事項を私たちが認識できているのは良いことですね。将来の実装や採用に向けたブロッカーや潜在的な課題ではないと分かって良かったです。

インクルージョンリストのトランザクション手数料メカニズム (39:50)

Pooja Ranjan: ウェブサイトで見つけた、トランザクション手数料メカニズムに関するいくつかの未解決の疑問について質問があります。何か最新情報があるか、あるいはインクルージョンリストへの包含に対して手数料を請求し、分配する最適な方法について、さらに共有していただけることはありますか。

Thomas Thiery: 私たちは現在、まさにこの点と、IL（インクルージョンリスト）コミッティメンバーに報酬を与えるインセンティブメカニズムに焦点を当てた助成金プロジェクトを進行中です。これは簡単ではありません。非常に難しく、どのようにアプローチするにしても、これらは非常に大きな変更になります。イーサリアム上の手数料を変更することは、手数料の変更であれ、追加であれ、あるいは新規発行の追加であれ、すべて多くの検討と注意を必要とする大きな変更です。しかし、現在調査が進められており、例えばトランザクションを含めたコミッティメンバー間で手数料を分配するといったアイデアは、妥当なものに思えます。他の人が含めたがらないようなトランザクションを含めた人々に報酬を与えたいと考えているため、これは私たちが求める特性を備えていると言えます。そのため、私たちはこのことについて非常に深く考えており、現在進行中の助成金プロジェクトがあるのです。

また、そもそもILコミッティメンバーに手数料を与えるべきかという疑問もあります。なぜなら、世界中に分散している小規模な参加者に報酬を与えることは、著しく困難だからです。シビル攻撃は避けたいですし、多くのステークを持つ大規模な参加者がILコミッティの枠を独占することも避けたいはずです。それをどのように防ぐのでしょうか？それは非常に困難です。したがって、考慮すべき設計上の要素が数多く存在します。

私が最近持っている見解の1つは、FOCILにプライバシーのような優れた機能を追加し、特定のトランザクションリストを誰が提案したのかを実際には分からないようにしたらどうなるか、というものです。ILコミッティメンバーとして実際に選ばれた誰かであることは分かっても、誰がどのリストを提案したのか正確には分からないため、ILコミッティメンバーと彼らのIL内のトランザクションセットを結びつけることはできません。もしそれが可能になり、ILコミッティの役割を一種のオプトインにすることができれば、おそらくプロトコルには利他的な行動に依存する誠実な参加者が集まり、手数料メカニズムを一切設定する必要がなくなるかもしれません。これはごく最近の個人的な見解であり、現在まさに探求されているところです。これらはすべて「FOCILの未来」に関する議論であり、現在のEIPに含まれる予定のものではありません。

Julian Ma: 付け加えると、その最後の部分は非常に重要です。実装をよりシンプルにするため、EIP-7805にはトランザクション手数料メカニズムは一切含まれていません。これは基本的に、検閲耐性の特性を提供できる最小限の方法ですが、非常に拡張性が高いものです。私たちはその点について調査しています。Thomasは、インクルーダー（含める人）とプロポーザー向けの個別のトランザクション手数料について、かなりの研究を行ってきました。そして、Thomasが言及したように、ネザーマインドの素晴らしい研究者と共に、FOCILのトランザクション手数料メカニズムの構築を調査する助成金プロジェクトを進行中であり、これは非常に有望です。最後に、Sarisht Wadhwa、Fan Zhang、Kartik Nayakが数名のFOCIL著者と共に提案した、オークションベースのインクルージョンリスト設計であるAUCILと呼ばれるFOCILの亜種に関するトランザクション手数料メカニズムの研究もあり、これはインクルージョンリストのコミッティメンバーにインセンティブを与える方法を模索しています。

先ほどのLuisの指摘に関して言えば、インセンティブの付与は、インクルージョンリストがどのように作成されるかに大きく関わっています。つまり、プロトコルはインクルージョンリストのコミッティメンバーがどのように振る舞うべきかについて、特定の視点を提供したいと考えているということです。通常、これが意味するところは、特定の参加者に異なる行動をとらせたいということです。例えば、コミッティメンバー間で依然として異なる行動を維持するために、相関均衡を通じてコミッティメンバーを順序付けし、特定のトランザクションを割り当てるかもしれません。したがって、これは現在の提案の一部ではありませんが、私たちは間違いなく調査を進めており、FOCILの拡張性の方向性に合致しています。

Pooja Ranjan: おお、それは興味深いですね。つまり、現在のFOCILの機能を強化するための、将来の補足的な提案を期待して待つべきだということですね。

インクルージョン・リストのサイズ (44:16)

プージャ・ランジャン: もう一つ質問があります。現在の提案に含めるべきかどうかはわかりませんが、IL（インクルージョン・リスト）のサイズについて何か最新情報があるか気になっています。過剰な帯域幅の使用を防ぐために、インクルージョン・リストのサイズは制限される必要があると思われます。インクルージョン・リストの最適なサイズをどのように決定できるかについて、さらなる調査や最新情報はありますか？

トーマス・ティエリー: 現在、仕様には固定サイズが設定されており、しばらく前から8キロバイトになっています。キロバイト単位にしているのは、FOCILとILが実際に消費するのは帯域幅であり、ほぼそれだけだからです。トランザクションの中央値のサイズを取ると、1つのILあたり約40トランザクションになります。そして、すべてのトランザクションが固有のものである場合、16人のコミッティメンバー全員で合計約640トランザクションを組み合わせることができる計算になります。

正確な最適サイズについて、これ以上多くの調査を行う必要があるかはわかりません。私たちが採用した基準は、16 × 8キロバイトが基本的に1つのブロブのサイズに相当するということであり、合計しても膨大な帯域幅にはなりません。また、複数のILにまたがるトランザクションの組み合わせは1つのブロックよりも大きくなるため、そこで問題が発生することはないと考えています。

将来的には、ILのサイズを増やすこともできますが、ILコミッティのメンバー数を増やすことも検討できます。そうすることで、ネットワークの大部分が検閲を始めたとしても、1人の誠実なILコミッティメンバーを得られる可能性がさらに高まります。したがって、それも私たちが取れる選択肢の一つです。今のところ、16人で全く問題なく十分だと思われますが、検閲が非常に激しくなったり、さらなる対策を講じる必要が生じたりした場合には、将来的にこれらのパラメータを調整することは間違いなく可能です。

導入を追跡するための指標 (46:39)

Pooja Ranjan: ここで1つフォローアップの質問です。この提案の導入や成功を理解するために、私たちが追跡できる指標として何か考えているものはありますか？

Julian Ma: 素晴らしい質問ですね。私から手短に答えて、その後Thomasにバトンを渡します。分かりやすい指標としては、空ではないインクルージョン・リストがいくつ提案されたか、というものがあります。また、Toni Wahrstätterの「.pics」シリーズのようなダッシュボードを思い浮かべることもできるでしょう。そこでは、これらのインクルージョン・リストに何らかの品質基準を割り当てるなど、より詳細な情報が提供されるかもしれません。ただし原則として、検閲耐性を提供するためには、1つのスロットにつき1人が適切なインクルージョン・リストを作成するだけで十分です。

FOCILを早期に実装することが重要であるというのは、非常に重要なポイントだと思います。なぜなら、現在私たちは、ブロック・ビルダーがあまり検閲を行わず、バリデータもあまり検閲を行わないという、魔法のような状況にいるからです。これは非常に脆弱な状態だと言えます。これまで、ブロック・ビルダーは長い間検閲を行ってきましたが、もし今FOCILを導入すれば、すべてのバリデータがそれを採用し、意味のあるインクルージョン・リストを作成することをデフォルトにできる可能性があります。ブロック・ビルダーが検閲を行っていないため、ここで市場の不安定性が生じることはありません。もしビルダー間で検閲が起こるまで待ってしまえば、FOCILを導入するのははるかに困難になり、導入を測定するために使用されるすべての指標ははるかに悪化するだろうと想像します。

Thomas Thiery: 注目すべきもう1つの重要な指標は、文字通り、パブリックなメンプールのトランザクションがインクルードされるまでの遅延です。パブリックなメンプールで保留中となっているすべてのトランザクションを取得し、それらがどれだけ早くインクルードされるかを確認します。FOCILが機能していれば、それらはすべて次のブロックにインクルードされます。もしそうでない場合、それはバリデータの大部分が検閲を行っていることを意味します。したがって、私たちが注目できるもう1つの指標は、誰が検閲を行っているか、そしてネットワークのどの程度の割合が検閲を行っているかです。これを追跡するためのダッシュボードと非常に透明性の高い指標を用意する予定です。なぜなら、それが基本的にFOCILの目的だからです。パブリックなトランザクションが次のブロックにインクルードされない場合、それはネットワークの非常に大きな部分が実際にこれらのトランザクションを検閲していることを意味します。

Pooja Ranjan: 非常に興味深いですね。つまり、これは研究者にとってのアップグレードのウィッシュリストのようなものかもしれません。提案がネットワークのアップグレードに組み込まれる際には常に、開発者によってダッシュボードや指標トラッカーが共有されるべきだということですね。

クライアント実装の状況 (49:11)

Pooja Ranjan: ジュリアンが言及したように、この提案はできるだけ早く実装される必要があるかもしれません。クライアント実装の現状がどうなっているのか気になっています。というのも、前回のテストネットのコールで、パリトッシュ（Paritosh）がデブネットでのサポート追加について言及していたのを覚えているからです。現状はどうなっていますか？

Thomas Thiery: かなり順調に進んでいます。まず第一に、皆さんがFOCILの実装部分にどのように取り組んでくれたかを見るのは非常に素晴らしいことでした。というのも、私は開発者ではなく研究者だからです。最初から開発者たちと一緒に仕事をしてきましたが、クライアントに実装しているのは私ではありません。

それを牽引してくれたのは3人です。プリズムのテレンス（Terence）、そしてプリズムでテレンスを大いに助けつつゲスにも取り組んできたジフン（Jihoon）です。現在、プリズムとゲスで稼働するデブネットがあり、これは素晴らしいことで、多くのテストが行われています。また、Doraエクスプローラー上でFOCILを表示し、可視化しようともしています。それから、ライトハウスとレスに取り組んできたジェイコブ（Jacob）がいて、そこでもまだいくつかの取り組みが続いていると認識しています。ロードスターは最近非常に活発で、デブネットの稼働まであと少しのところまできていると思います。今日、ネザーマインドからプロトタイプができたというニュースがありましたが、これも非常に素晴らしいことです。誰かを忘れているような気がしますが... ニンバスも参加しているとジフンが言っています。本当に素晴らしいですね。

全体として、準備が整い稼働するデブネットやローカルのデブネットがどんどん増えており、実行クライアントとコンセンサス・レイヤークライアントの組み合わせも増えています。本当に良い進展があり、それを見るのは嬉しいことです。というのも、ペクトラが控えており、すでにPeerDASなどの作業にも取り組んでいるため、開発者が現在非常に忙しいことは誰もが知っているからです。イーサリアム全体のコミュニティが検閲耐性について非常に気にかけているのを見るのは、本当に素晴らしいことでした。私が特に声をかけていなかったチームのほとんどが、この取り組みに参加し、現在デブネットとテストに向けて作業を進めています。

Pooja Ranjan: 共有していただきありがとうございます。デブネットの最新情報を追うのを楽しみにしています。このデブネットのイテレーションが何回行われるかはわかりませんが、立ち上がるのを見るのが楽しみです。ジャスティン（Justin）から質問があるようです。ジャスティン、どうぞ。

フサカとグラムステルダム、FOCILはどちらに？ (52:07)

ジャスティン: さあ、ここからが本番です。検閲に対処する最適なタイミングは、検閲が起こる前であるという、非常に良い指摘がありましたね。では、FOCILはフサカに入れるべきでしょうか、それともグラムステルダムまで待てるでしょうか？また、開発者として私はどちらを支持すべきでしょうか？

トーマス・ティエリー: 私たちはPRを作成し、それはマージされ、FOCILはフサカに向けて提案されています。私たちはフサカに入れるべきだと考えています。その理由の一部は、一部のクライアントがすでに作業を開始しており、それほど多くの障害に直面していないためです。実装がはるかに難しく、より多くの作業を伴う他の提案とは異なります。また、それほど議論を呼ぶものでもありません。検閲耐性に反対する人はいないと思いますし、誰もができるだけ早く含める必要があるとある程度同意しています。ですので、私はフサカを支持します。

待てるかどうかはわかりません。提案やアップグレードはいつでも待つことができます。私はただ、これらの変更を実装するのが今ほど簡単ではなくなる世界を避けたいだけです。状況は非常に早く反転する可能性があります。私たちが見たように、逆のことが起こりました。数ヶ月前、主要なビルダーの1つが突然検閲をやめました。理由を尋ねると、「ええ、ただやめようと決めただけです」という感じでした。その場合は良い方向に向かったので良かったのですが、完全に元に戻る可能性もあり、そうなれば2つのビルダーが一部のトランザクションを検閲し、私たちは再び非常に悪い状況に戻ってしまうかもしれません。

もう一つ言及しておきたいことがあります。これは重要だと思うからです。私たちが取り組んできた設計のいくつかを使ってアテスターとプロポーザーを実際に分離できるAPSのような、私たちが話したいくつかの方向に向かうのであれば、その前にFOCILを導入し、FOCILが機能していることを確認する必要があります。FOCILがその目的、つまりイーサリアムの検閲耐性の特性を維持し向上させるという目的を果たしていることを実際に確認するためには、メインネットで半年から1年間FOCILを稼働させる必要があります。したがって、少なくとも私にとってのもう一つの緊急性は、APSで対処したいタイミングゲームやその他の懸念からアテスターを保護したいのであれば、できるだけ早くFOCILを導入する必要があるということです。

プージャ・ランジャン: 提案が次、あるいは直近のアップグレードに選ばれないのを見るのは時々悲しいことですが、1つのアップグレードに含めることができる提案の数には限りがあります。提案の提出、提案の準備、そしてそれに伴うテストの背後で行われているすべての懸命な作業に本当に感謝しています。イーサリアム・エコシステムのために皆さんが行っているすべての作業に、心から感謝します。

一問一答 (55:18)

プージャ・ランジャン: 締めくくる前に、簡単な一問一答のコーナーを用意しています。唯一の条件は、1単語または1文で答えることです。タイマーを使って、それぞれ30秒程度で進めたいと思います。準備ができたら、ジュリアンから始めましょう。現在、ブロックチェーン研究における最も難しい問題は何ですか？

ジュリアン・マー: あまりネタに走らず、真面目に答えますね。最も難しい問題はステーキングの未来だと思います。ステーキングの未来が何を意味するのか、どのサービスプロバイダーがどのような役割を果たすのか、その対価がどのように支払われるのか、そしてそれらが互いにどう関係していくのか、ということです。

プージャ・ランジャン: まだ十分に探求されていないブロックチェーンのユースケースを1つ挙げるとしたら何ですか？

ジュリアン・マー: FOCILですね。

プージャ・ランジャン: 今日のイーサリアムにとって最大のセキュリティリスクは何ですか？

ジュリアン・マー: 正直なところ、ここでは検閲耐性が非常に重要だと言えます。なぜなら、マルチブロックMEVのようなものが、例えばL2にとって巨大なセキュリティリスクをもたらす可能性があるからです。

プージャ・ランジャン: MEVは最小化すべきでしょうか、受け入れるべきでしょうか、それともその中間でしょうか？

ジュリアン・マー: これについてはFlashbotsの見解にほぼ同意します。つまり、民主化されるべきであり、必要なところでは最大化し、アプリケーション層では最小化すべきだということです。

プージャ・ランジャン: 分散化は常にトレードオフに見合う価値がありますか？

ジュリアン・マー: たいていの場合、トレードオフに見合う価値があります。

プージャ・ランジャン: イーサリアムが世界にもたらした最大のイノベーションは何ですか？

ジュリアン・マー: ここでは、デジタル財産権に関するDevconでのマイク・ノイダーの講演を引用したいと思います。世界を本当に変えつつあるのは、検閲耐性のあるデジタル財産権だと言えます。

プージャ・ランジャン: ありがとうございます、素晴らしい回答でした。次の一連の質問はトーマスに向けたものです。もしイーサリアムが存在しなかったら、どのブロックチェーンで働いていましたか？

トーマス・ティエリー: 私はかなりネタに走ると思います。ジュリアンも同じことをすると思っていたので、少し彼に梯子を外されましたね。そのブロックチェーンはFOCILでしょうね。

プージャ・ランジャン: ブロックチェーンのユースケースで最も過大評価されているものは何ですか？

トーマス・ティエリー: FOCILなしで騒ぐ価値のあるユースケースはありません。

プージャ・ランジャン: イーサリアムができるだけ早く改善すべきことは何ですか？

トーマス・ティエリー: FOCILによる検閲耐性です。

プージャ・ランジャン: 分散化を1単語で表すと？

トーマス・ティエリー: FOCILです。

プージャ・ランジャン: イーサリアムはスケーラビリティを完全に解決すると思いますか？

トーマス・ティエリー: FOCILを備えたイーサリアムなら、はい。

プージャ・ランジャン: レイヤー1 (L1) のスケーリングとレイヤー2 (L2) のスケーリング、どちらが勝ちますか？

トーマス・ティエリー: 無限のレイヤーです。すべてFOCILを備えています。

プージャ・ランジャン: お見事です、トーマス、本当にありがとうございました。すべての質問に答えていただき感謝します。締めくくりにあたり、この機会をあなたにお譲りしたいと思います。この提案についてコミュニティへのメッセージ、あるいはイーサリアムコミュニティ全体へのメッセージがあればお願いします。

コミュニティへのメッセージ (58:08)

Thomas Thiery: 実のところ、それは非常に重要です。なぜなら、私たちは常に活発な議論を行っており、そのすべてがディスコード上で公開されているからです。当初からすべてを公開しようという動きがあり、実際に人々がそれを実行しているため、私はとても嬉しく思っています。公開されているEth R&Dのディスコードのinclusion-listチャンネルで、議論や進捗状況を追うことができます。現在、基本的にはそこですべてが行われています。また、ツイッターやテレグラムなど、どこからでも私たちに連絡を取ることができます。お気軽にどうぞ。

より多くの人と話し、関わってもらうことで、設計も実装もより良いものになります。ですので、もし何らかの形で協力していただけるなら、ぜひご連絡ください。リサーチの面も含め、あらゆる面で喜んでサポートします。FOCILの未来に取り組みたいと考えている人たちと一緒に働くことは、私たちにとってさらに適していると思います。プライバシーやトランザクション手数料のメカニズムについて言及しましたが、私たちはブロブ向けのFOCILにも大いに注力していく予定です。これらすべてのことには、人材とリサーチの労力が必要です。興味がある方は、ぜひご連絡ください。本日はお招きいただき、本当にありがとうございました。また、イーサリアムのための皆さんのすべての活動にも感謝します。

Julian Ma: 付け加えさせていただきますと、私たちがFOCILについて皆さんに少しでも熱意を持っていただけたなら幸いです。もし熱意を持っていただけたなら、ぜひ私たちにお知らせください。また、まだ疑問に思うことがあれば、喜んでお答えします。そして、FOCILこそが進むべき道であると納得していただけることを願っています。本当にありがとうございました。ここに参加できて本当に光栄でした。セッションを主催していただきありがとうございます。そしてもちろん、ご参加いただいた皆様にも感謝申し上げます。

終わりの言葉 (59:52)

プージャ・ランジャン: ありがとうございます。本日はここまでとなります。本日ご参加いただき、EIP-7805についての知見を共有してくださったトーマスとジュリアンに心から感謝します。参加者の皆様にも感謝申し上げます。皆様からの質問は非常に励みになり、有益なものでした。ご視聴ありがとうございました。この対話をお楽しみいただけた場合は、ぜひ「いいね」やチャンネル登録をして、イーサリアム愛好家の仲間とこのエピソードをシェアしてください。PEEPanEIPでは、今後もさらに多くのEIPや研究の進捗状況をお届けしていきます。次回まで、知識を深めて喉を鳴らし、Ethereum Cat Herdersと一緒にイーサリアムの世界を探索し続けましょう。それでは、素晴らしい一日をお過ごしください。