EIP-7805 : Listes d'inclusion appliquées par le choix de fork (FOCIL)

Épisode 141 de PEEPanEIP par les Ethereum Cat Herders. L'animatrice Pooja Ranjan est rejointe par Thomas Thiery et Julian Ma, chercheurs au sein du Robust Incentives Group de la Fondation Ethereum et co-auteurs de l'EIP-7805 (s'ouvre dans un nouvel onglet), pour expliquer les listes d'inclusion appliquées par le choix de fork (FOCIL) : pourquoi Ethereum a besoin d'une résistance à la censure au niveau du protocole, comment fonctionne le mécanisme et où en est l'implémentation.

Cette transcription est une copie accessible de la transcription originale de la vidéo (s'ouvre dans un nouvel onglet) publiée par les Ethereum Cat Herders. Elle a été légèrement modifiée pour en faciliter la lecture.

Introduction (0:35)

Pooja Ranjan : Bonjour et bienvenue dans PEEPanEIP, la seule et unique émission où nous explorons en détail les propositions d'amélioration d'Ethereum et analysons leur impact sur l'écosystème. Voici l'épisode 141, qui vous est présenté par les Ethereum Cat Herders. Je suis votre hôte, Pooja Ranjan, et aujourd'hui nous parlons de l'EIP-7805, les listes d'inclusion imposées par le choix de fork (Fork-choice enforced Inclusion Lists).

Documentée en novembre 2024, l'EIP-7805 est une proposition principale de la voie des standards actuellement à l'état de brouillon. Cette proposition vise à permettre à un comité de validateurs d'inclure de force un ensemble de transactions dans chaque bloc. Co-écrite par Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann et Jihoon Song, la proposition fait l'objet de discussions actives en vue d'une future mise à jour.

Dans cet épisode, nous explorerons les détails de l'EIP-7805, ses implications et son impact potentiel sur l'écosystème Ethereum. Pour parler plus en détail de la proposition, nous sommes rejoints par Thomas Thiery et Julian Ma. Bienvenue dans PEEPanEIP.

Thomas Thiery : Merci de nous recevoir.

Julian Ma : Oui, merci beaucoup de nous recevoir.

Pooja Ranjan : Nous sommes impatients de découvrir l'aperçu de la proposition, où elle en est aujourd'hui, et quand nous pourrons la voir sur le réseau principal Ethereum. Mais avant de commencer, notre communauté adore apprendre à connaître les chercheurs et les développeurs derrière ce travail. Pourriez-vous nous en dire un peu plus sur vous, sur le projet dans lequel vous êtes actuellement impliqués, et sur votre parcours au sein de l'écosystème Ethereum ?

Présentation des invités (2:14)

Julian Ma : Bien sûr, je peux commencer. Je suis Julian, chercheur au sein du Robust Incentives Group, tout comme Thomas, à la Fondation Ethereum. Le Robust Incentives Group s'intéresse à l'économie du protocole au sens large. Certains d'entre nous se sont penchés sur les mécanismes de frais de transaction, comme l'EIP-1559, et d'autres ont étudié les attaques sur la couche de consensus, principalement celles motivées par des incitations économiques.

Pour ma part, j'ai commencé par un stage sur les dérivés de frais de base, puis j'ai été embauché à temps plein. J'ai principalement travaillé sur la séparation proposant-constructeur (PBS) et les sujets liés à la MEV, et je me concentre maintenant sur les listes d'inclusion via FOCIL avec cette EIP, tout en attendant avec impatience la séparation attestateur-proposant. Je dirais que ce qui m'enthousiasme le plus, c'est de faire passer la recherche en production via ce processus qui consiste à commencer par un travail plus théorique pour l'amener vers une EIP qui, je l'espère, pourra être proposée et implémentée au sein d'Ethereum.

Thomas Thiery : Je suis Thomas. Je travaille également à la Fondation Ethereum au sein du Robust Incentives Group, en tant que chercheur. À la base, j'ai un doctorat en neurosciences, ce qui était très différent. Mais je suis devenu curieux des chaînes de blocs et des systèmes distribués, j'ai voulu essayer quelque chose d'un peu différent et j'ai rejoint une entreprise de données crypto appelée Dune. J'y suis resté un certain temps, mais la recherche m'a manqué, et j'ai eu la chance de pouvoir rejoindre la Fondation Ethereum (EF) et le Robust Incentives Group, ce qui a été formidable jusqu'à présent.

J'ai travaillé sur des sujets similaires. La MEV était un sujet assez important quand je suis arrivé. Fait intéressant, mes tout premiers articles de recherche étaient très courts, mais ils portaient sur les délais d'inclusion et la résistance à la censure. Je ne m'y suis vraiment plongé en profondeur que plus récemment. Depuis six mois à un an, je suis plus actif sur les aspects de résistance à la censure et d'inclusion. C'est vraiment agréable de pouvoir partir d'idées de recherche, d'améliorer des idées précédentes qui étaient très intéressantes mais n'incluaient pas certains des détails dont nous allons parler, de formuler une proposition, et d'avoir maintenant des implémentations et des devnets que la plupart des personnes avec qui j'ai discuté considèrent comme un bon ajout à Ethereum.

Pooja Ranjan : Merci pour ce partage. Il est toujours inspirant de découvrir le parcours des développeurs. Il est intéressant de voir qu'ils viennent de différents domaines et finissent par contribuer à l'écosystème Ethereum. Je crois comprendre que nous avons une présentation aujourd'hui. Alors sans plus tarder, jetons-y un coup d'œil.

Présentation : objectifs de FOCIL (5:16)

Julian Ma : Parfait, merci beaucoup. J'aimerais commencer par une petite présentation sur le fonctionnement de l'EIP-7805, ou FOCIL, et sur les raisons exactes pour lesquelles nous voulons le mettre en place. Le but est de lancer la conversation, donc ce ne sera pas trop approfondi, afin de laisser un peu de place pour la discussion par la suite.

L'objectif principal de FOCIL est d'augmenter la neutralité crédible d'Ethereum. FOCIL y parvient en supprimant le monopole d'inclusion qu'un seul proposant ou constructeur de blocs détient actuellement au sein d'un créneau. Au lieu de cela, FOCIL permet à plusieurs validateurs de contribuer à la construction d'un bloc en incluant des transactions dans chaque bloc.

L'objectif de plus haut niveau est de poursuivre une propriété que nous appelons la neutralité de la chaîne, ce qui signifie que toute transaction en attente payant des frais devrait être incluse si elle est disponible et s'il y a de la place pour l'inclure onchain. Nous pensons que si cette propriété est suffisamment satisfaite, alors nous augmentons la neutralité crédible d'Ethereum.

Pourquoi avons-nous besoin de FOCIL, et pourquoi maintenant ? (6:09)

Julian Ma : Pourquoi avons-nous besoin de quelque chose comme cela ? Actuellement, presque tous les validateurs sous-traitent la construction de blocs à MEV-Boost, qui est un marché hors protocole où les constructeurs enchérissent pour obtenir les droits de construction de blocs. Sur ce marché, seules deux entités dominent réellement, ce qui signifie que 90 % des blocs sont construits par seulement deux entités.

Nous voyons ici qu'Ethereum ne peut plus tirer sa neutralité crédible de la construction locale de blocs. C'était le cas autrefois. Au départ, les proposants étaient répartis dans le monde entier, chacun construisant ses blocs localement, ce qui signifiait que toutes les transactions étaient incluses. Mais maintenant que la construction de blocs est sous-traitée à ces entités sophistiquées, ce n'est plus suffisant. Il est donc nécessaire de mettre en œuvre des mesures anti-censure plus robustes, et FOCIL est le moyen le plus connu d'y parvenir.

Pourquoi devrions-nous implémenter FOCIL maintenant ? Vous pourriez penser que les constructeurs ne censurent pas tant que ça actuellement, mais ils pourraient commencer à le faire à tout moment, que ce soit pour des raisons réglementaires ou économiques. Et il ne faut absolument pas se méprendre sur la censure économique. Il est également judicieux d'introduire FOCIL lorsqu'il y a relativement peu de censure, car vous l'introduisez alors comme référence et par défaut. Tous les validateurs créent des listes d'inclusion indépendamment de leur juridiction ou de leurs incitations économiques, et cela cause peu d'instabilité sur le marché. Alors que si vous deviez introduire FOCIL lorsque tous les constructeurs censurent, ce serait peut-être plus difficile.

Ensuite, les rollups basés deviennent de plus en plus courants de nos jours, et ils vont s'appuyer sur la construction de blocs d'Ethereum. Si nous voulons fournir le séquençage qu'Ethereum possède, il est nécessaire d'avoir une neutralité crédible ici via FOCIL.

Et potentiellement, FOCIL pourrait aider à la mise à l'échelle, selon à qui vous posez la question. Aujourd'hui, Ethereum tire toujours sa résistance à la censure de la construction locale de blocs. Si Ethereum peut tirer sa résistance à la censure d'ailleurs, par exemple via FOCIL, alors nous pourrons peut-être augmenter les attentes que nous avons envers les constructeurs de blocs et autoriser, par exemple, plus de blobs. Mais cela pourrait potentiellement être fait sans FOCIL également. Par conséquent, il a été proposé d'implémenter FOCIL dans Fusaka.

Comment fonctionne FOCIL (8:10)

Julian Ma : Je vais maintenant vous expliquer comment fonctionne FOCIL. Nous allons commencer par les bases et avancer étape par étape jusqu'à obtenir le mécanisme complet, puis nous explorerons comment ce mécanisme complet satisfait les propriétés que nous recherchons.

L'idée de base d'une liste d'inclusion, qui a également été proposée par Mike Neuder auparavant, est qu'il existe une liste de transactions qui contraint le bloc d'une manière ou d'une autre. Il y a donc, par exemple, une liste d'inclusion qui inclut les transactions A et B, elle est signée par quelqu'un qui est reconnu par le protocole, et ensuite ces transactions doivent être incluses dans un bloc. FOCIL ne change pas cela. Il s'appuie dessus, et il s'agit plutôt de savoir qui crée cette liste et comment cette liste est appliquée.

Alors, qui crée cette liste ? C'est la première étape du fonctionnement du protocole FOCIL. À chaque créneau, 16 validateurs sont sélectionnés comme membres du comité de la liste d'inclusion. Chacun de ces membres du comité observe la mempool et construit sa propre liste d'inclusion. Une liste d'inclusion devrait faire environ 8 kilo-octets, soit environ 20 transactions moyennes, ce qui signifie environ 320 transactions moyennes au total.

La deuxième étape est la distribution de ces listes d'inclusion. Les membres du comité de la liste d'inclusion distribuent leurs listes d'inclusion sur le topic global, et ils ne les incluent pas eux-mêmes dans un bloc. Ils doivent le faire avant la 9e seconde du créneau, moment auquel les attestateurs gèlent leur vue des listes d'inclusion locales. Comme nous le verrons dans la prochaine étape, ce sont les attestateurs qui appliquent réellement ces listes d'inclusion, comme le nom l'indique : listes d'inclusion appliquées par le choix de fork (fork-choice enforced inclusion lists). Ils gèlent leur vue des listes d'inclusion qu'ils appliqueront à la 9e seconde, ce qui empêche les attaques par division de vue. Le producteur de blocs dispose encore de quelques secondes supplémentaires pour observer les listes d'inclusion et s'assurer qu'il n'est pas affecté négativement par l'absence de listes d'inclusion, de sorte que le producteur de blocs ne court aucun risque dans cette configuration.

Ensuite, nous passons à l'étape finale, qui est l'application. Comme je l'ai dit, l'application se fait via le choix de fork. Les attestateurs ne voteront pour un bloc que s'il satisfait à la condition de la liste d'inclusion. Ils le font en observant les listes d'inclusion qui ont été envoyées sur le topic global, en créant une liste agrégée des transactions qu'ils ont vues dans ces listes d'inclusion, puis en vérifiant si toutes ces transactions sont dans le bloc. Si cette vérification réussit, ils votent pour le bloc. Il se peut également que toutes les transactions des listes d'inclusion ne soient pas dans le bloc, mais que le bloc soit plein. Dans ce cas, les attestateurs votent également pour le bloc. Donc, à moins que le bloc ne contienne pas les transactions et ne soit pas plein, les attestateurs votent pour le bloc.

Pour résumer le mécanisme complet : à chaque créneau, 16 membres du comité sont sélectionnés comme membres du comité de la liste d'inclusion. Ils observent la mempool et construisent des objets de liste d'inclusion qu'ils distribuent sur le topic global avant une date limite, dans ce cas la 9e seconde. Le constructeur observe ces listes d'inclusion et inclut toutes les transactions qu'il a vues dans son bloc. Les attestateurs vérifient ensuite si toutes les transactions qu'ils avaient vues avant la 9e seconde dans les listes d'inclusion sont bel et bien dans le bloc. Si cette vérification réussit, ils votent pour le bloc, et nous passons au créneau suivant, où la même configuration se répète.

IL Boost et non-encombrement (11:07)

Julian Ma : L'une des grandes inquiétudes concernant les listes d'inclusion, exprimée pour la précédente EIP de Mike et pendant le développement qui a suivi, est l'« IL Boost », ou le non-encombrement. Cela fait référence au fait que les proposants de listes d'inclusion pourraient vouloir vendre leurs droits de construire une liste d'inclusion. C'est une préoccupation très logique, car nous voyons cela se produire avec la construction de blocs : la vente de ce droit conduit à un marché centralisé de constructeurs sophistiqués.

Nous soutenons que FOCIL est robuste face à ces marchés de type MEV-Boost, ou IL Boost comme on les appelle familièrement, en raison des propriétés suivantes. FOCIL ne garantit aucun ordre des transactions. Peu importe où vous placez votre transaction dans votre liste d'inclusion, elle sera ordonnée de la manière que le constructeur de blocs jugera appropriée. Si vous deviez, par exemple, inclure une transaction d'arbitrage dans la liste, il est très peu probable que le constructeur place votre transaction d'arbitrage en haut du bloc pour qu'elle exécute réellement l'arbitrage. Au lieu de cela, le constructeur le fera probablement lui-même.

De plus, le flux d'ordres privé n'est pas possible. Ces listes d'inclusion sont distribuées sur le topic global, vos transactions sont donc publiques avant que le constructeur ne construise le bloc. Il n'est pas possible de faire entrer un flux d'ordres privé dans le bloc via une liste d'inclusion.

Troisièmement, il y a plusieurs proposants de listes d'inclusion par créneau. Même s'il y avait quelque chose de valeur à vendre, les 16 membres du comité de la liste d'inclusion ont la même possibilité de construire cette liste d'inclusion, de sorte que la concurrence entre ces proposants de listes d'inclusion ferait chuter la valeur à zéro.

Et enfin, ces listes d'inclusion sont créées 3 secondes avant que le producteur de bloc n'agisse. Il y a 3 secondes d'informations supplémentaires, qui sont généralement extrêmement pertinentes pour les transactions de type MEV, qui arrivent après que la liste d'inclusion a été soumise et avant que le producteur de bloc n'agisse, ce qui signifie qu'il y a très peu d'avantage informationnel. En fait, il y a un désavantage informationnel pour ceux qui essaient d'utiliser les listes d'inclusion comme vecteur de MEV.

Pour ces raisons, nous pensons qu'aucun proposant individuel de liste d'inclusion n'a de pouvoir d'inclusion, d'ordonnancement ou d'exclusion, ce qui est la définition fondamentale de la MEV. Par conséquent, les listes d'inclusion ne devraient pas être soumises à la MEV.

Résumé de la présentation (13:09)

Julian Ma : Pour résumer cette rapide présentation : FOCIL permet à plusieurs validateurs de contribuer à la construction de blocs, empêchant le monopole d'inclusion d'un seul proposant et renforçant la neutralité crédible d'Ethereum. Nous pensons qu'il est nécessaire de mettre en œuvre FOCIL dès maintenant car il n'y a actuellement que deux constructeurs dominants qui pourraient commencer à censurer à tout moment, et ce pour des raisons économiques dont ils pourraient tirer profit. La construction de blocs pourrait devenir plus critique car les rollup basés voudront utiliser les propriétés de séquençage d'Ethereum. Le lancement de FOCIL se fera beaucoup plus en douceur lorsqu'il y aura peu de parties censurantes : premièrement, parce que cela signifie que c'est un comportement par défaut pour les validateurs de construire des listes d'inclusion, et deuxièmement, parce que cela signifie qu'il y a moins d'instabilité du marché entre les constructeurs qui censurent et ceux qui ne le font pas. Et enfin, FOCIL pourrait potentiellement aider à la mise à l'échelle, ce qui est peut-être un sujet que nous pourrons approfondir.

Merci pour le temps accordé à cette petite présentation. Je voulais juste montrer le code QR, qui mène à l'EIP, pour les personnes intéressées.

Pooja Ranjan : Merci beaucoup pour cette rapide présentation et cet aperçu de la proposition.

Q&A : en quoi l'EIP-7805 diffère-t-il de l'EIP-7547 ? (14:17)

Pooja Ranjan : J'aimerais commencer la session de questions-réponses par la toute première question, concernant la proposition précédente qui a également été mentionnée dans votre présentation : la proposition 7547, les listes d'inclusion, par Mike Neuder. Je veux comprendre la différence fondamentale entre cette proposition et le FOCIL que nous avons avec l'EIP-7805. Vous avez partiellement abordé dans votre présentation l'IL Boost et la non-encombrabilité (uncrowdability). Voudriez-vous peut-être nous en dire un peu plus à ce sujet ?

Julian Ma : Thomas est peut-être le mieux placé pour expliquer en quoi l'EIP-7805 diffère de l'EIP-7547, mais je peux en dire quelques mots. Tout d'abord, FOCIL concerne le même créneau, tandis que l'EIP-7547 concernait le créneau suivant. La propriété du même créneau facilite certaines choses, car cela signifie que la liste d'inclusion n'a pas besoin d'être stockée onchain.

En ce qui concerne la propriété de non-encombrabilité, c'est très intéressant et subtil. Dans l'EIP-7547, qui était une excellente proposition sur laquelle notre proposition s'appuie, la liste d'inclusion est ajoutée inconditionnellement au bas du bloc et créée par une seule personne. Cela présente quelques propriétés différentes des nôtres. Tout d'abord, les transactions sont ordonnées. Il se pourrait qu'à l'avenir, il soit très précieux d'avoir un arbitrage en bas de bloc, et en fait, certaines des recherches de Thomas ont souligné que cela pourrait potentiellement être un endroit précieux. Avoir le droit de construire la liste d'inclusion signifie que vous êtes la dernière personne à agir dans le bloc, et dans certains cas, cela pourrait être précieux. Deuxièmement, elle est créée par une seule personne, il n'y a donc pas cet effet de concurrence entre les membres du comité de la liste d'inclusion. Un comité d'une seule personne a le plein droit d'inclure des transactions au bas du bloc, ce qui pourrait également le rendre plus précieux. Troisièmement, il y a cette propriété inconditionnelle, ce qui signifie que peu importe ce que fait le producteur de blocs, votre transaction sera de toute façon incluse onchain. Elle offre donc quelques garanties supplémentaires, au-delà du minimum nécessaire pour l'inclusion, qui pourraient la rendre précieuse dans une certaine mesure.

Thomas Thiery : Une grande différence réside également dans le nombre de proposants de listes d'inclusion que nous avons. Dans la proposition précédente, il y avait un mécanisme par lequel le proposant du créneau n crée la liste d'inclusion que le proposant du créneau n+1 doit appliquer. Les deux points importants ici : premièrement, il y a un délai d'un créneau, de sorte que les transactions de la liste d'inclusion ne doivent être incluses que dans le créneau suivant par le proposant suivant. Et il n'y a qu'un seul proposant qui crée réellement la liste d'inclusion. Avec FOCIL, nous en avons 16. Cela fait une énorme différence, car maintenant nous n'avons besoin que d'un seul membre honnête sur les 16 du comité IL pour que l'ensemble du mécanisme fonctionne comme prévu. Cela multiplie vos chances d'avoir réellement un bon mécanisme résistant à la censure, alors qu'auparavant vous dépendiez d'une seule partie.

Et puis quelques détails plus techniques : il y avait des incompatibilités avec l'abstraction de compte, et il était difficile de gérer l'équivoque d'IL, c'est-à-dire quelqu'un qui envoie deux listes d'inclusion différentes. L'équivoque de bloc est une chose connue et elle est pénalisée par le protocole, mais comme tout allait onchain dans la proposition précédente, vous deviez également faire face à des cas particuliers étranges, et il n'était pas très facile de s'y adapter. Avec FOCIL, les listes d'inclusion ne vont pas onchain. Elles sont simplement diffusées sur le réseau de la couche de consensus P2P. C'est un peu technique, mais cela fait une grande différence dans le traitement de ces cas particuliers causés par l'abstraction de compte, ou des attaques où vous divisez le réseau en deux vues avec l'équivoque d'IL.

Pooja Ranjan : Merci beaucoup. Pour les personnes qui souhaiteraient en savoir plus sur la proposition 7547, nous avons un épisode enregistré avec Mike Neuder, l'épisode 130 de PEEPanEIP, qui fournit un aperçu de haut niveau. J'aime toujours voir des propositions concurrentes, car je sais que c'est pour l'amélioration de l'écosystème et de la chaîne. Je vois dans le chat qu'il y a quelques questions. J'aimerais peut-être inviter Kataya à partager sa question.

Le proposant doit-il inclure les 16 listes ? (19:05)

Kataya : Bonjour, merci. Ma question était : le proposeur de bloc reçoit-il 16 listes d'inclusion, chacune provenant d'un membre du comité, et doit-il inclure toutes les transactions de ces listes ?

Thomas Thiery : Oui, c'est exact. Vous prenez l'union de toutes les transactions de toutes les listes, dans notre cas 16 listes. Il peut y avoir des chevauchements, évidemment, donc vous prenez l'union et vous dédupliquez, mais oui, toutes les transactions de toutes les listes doivent être incluses dans le bloc pour qu'il soit considéré comme valide par les attestateurs.

Pooja Ranjan : La question suivante dans le chat est de Justin. Justin, aimeriez-vous lire votre question pour les invités ?

Transactions de mempool privée dans les listes d'inclusion (19:55)

Justin : J'ai posé tellement de questions. Je voulais demander ce qui empêche de placer une transaction d'une mempool privée dans une liste d'inclusion, et je pense que la réponse a été assez claire. Il semble que ce soit tout à fait possible, étant donné que le constructeur va de toute façon les ordonner comme bon lui semble, et que votre transaction devient publique lorsqu'elle est diffusée sur l'IL également. Donc je pense que c'est logique. Merci.

Thomas Thiery : C'était l'une des considérations, comme Julian l'a mentionné. Nous ne voulions vraiment pas que FOCIL et les listes d'inclusion soient utilisés pour inclure des transactions MEV, des flux d'ordres privés ou des préconfirmations, car en fin de compte, ce que nous voulons, c'est la résistance à la censure, et il est très facile pour un mécanisme de devenir un moyen d'inclure des transactions de valeur si l'on n'y prend pas garde. Le fait que lorsque vous incluez votre transaction dans une liste d'inclusion, elle devient automatiquement publique, tout le monde peut la voir, elle n'a aucune garantie d'ordre, et elle peut être incluse par le constructeur n'importe où dans le bloc, la rend très peu adaptée aux transactions de valeur.

Donc, soit vous avez une transaction publique, et vous pouvez simplement la soumettre à la mempool publique pour qu'elle soit incluse dans une liste d'inclusion, soit vous avez des transactions privées de valeur, et dans ce cas vous ne passeriez pas par FOCIL, car il y a de meilleures façons de le faire. Vous contacteriez directement le constructeur et l'enverriez par des canaux privés.

Pooja Ranjan : Merci pour ce partage. Je vois que la prochaine question est de Ladislaus.

FOCIL et mise à l'échelle (21:41)

Ladislaus : Salut les gars. Cela fait référence au point que vous avez soulevé concernant FOCIL et la mise à l'échelle. J'ai vu quelques discussions récemment, comme nous tous, sur la mise à l'échelle d'Ethereum, et comme vous l'avez mentionné à juste titre, il y a ce goulot d'étranglement dû au petit nombre de constructeurs existants. Personnellement, j'aime voir FOCIL comme un moyen de redonner du pouvoir à la construction locale, et je considère qu'il est nécessaire de l'inscrire dans le protocole avant d'augmenter les exigences en matière de bande passante, ou les exigences des nœuds en général. Peut-être pourriez-vous développer votre point de vue à ce sujet, ainsi que d'autres moyens potentiels de mise à l'échelle, peut-être sans FOCIL, comme vous l'avez mentionné.

Julian Ma : Merci pour la question. Tout d'abord, les arguments en faveur de la mise à l'échelle via FOCIL. Actuellement, 90 % des validateurs externalisent la construction de blocs via MEV-Boost, et ces entités sophistiquées disposent évidemment de plus de bande passante que les exigences matérielles minimales. Elles pourraient, par exemple, inclure plus de blobs dans leurs blocs sans que cela ne pose de problème. Une chose intéressante, cependant, est qu'Ethereum s'appuie sur la construction locale de blocs pour garantir une neutralité crédible, ou la résistance à la censure, car ces deux entités sophistiquées ne sont pas celles sur lesquelles la résistance à la censure d'Ethereum peut reposer.

Le protocole Ethereum doit donc toujours être conçu de manière à ce qu'il soit possible d'effectuer une construction locale de blocs, et en fait, nous le concevons pour que cela ne soit pas non rentable par rapport à MEV-Boost. C'est dans la conception d'Ethereum, mais en pratique, bien sûr, MEV-Boost est beaucoup plus rentable : d'abord parce que ces constructeurs de blocs sophistiqués ont des algorithmes plus complexes, et ensuite parce qu'ils ont beaucoup plus de flux d'ordres privés. Une recherche récente de Data Always a montré que les blocs MEV-Boost contiennent beaucoup plus de transactions. Cela seul conduit à plus de profits.

Néanmoins, le protocole est conçu de sorte qu'aucune force issue des règles du protocole ne rende un validateur moins rentable qu'un autre. Si nous voulons conserver cette règle, alors FOCIL est nécessaire, car les constructeurs de blocs locaux peuvent alors contribuer aux listes d'inclusion et ainsi maintenir la résistance à la censure. Nous pourrions cependant aussi nous débarrasser de cette règle et dire en gros que les constructeurs de blocs locaux peuvent inclure un certain nombre de blobs, mais que les constructeurs de blocs plus sophistiqués pourraient inclure plus de blobs, au point que les constructeurs de blocs locaux ne seraient pas capables de gérer cette charge en créant un bloc eux-mêmes. Donc, si nous voulons conserver la règle selon laquelle le maximum est fixé aux exigences matérielles les plus basses, alors nous avons besoin de FOCIL. Si nous sommes d'accord pour assouplir cette règle, alors nous n'avons potentiellement pas besoin de FOCIL pour la mise à l'échelle.

Thomas Thiery : C'est très similaire, je suppose, mais en ce moment sur Ethereum, nous sommes dans une position étrange, car nous comptons sur des constructeurs sophistiqués pour construire la plupart des blocs, mais ceux-ci ne sont pas géniaux pour la résistance à la censure, car il ne s'agit que de deux parties. S'ils décident de censurer des transactions ou certaines adresses pour une raison arbitraire, alors nous n'avons fondamentalement plus de résistance à la censure ni de nature sans permission, ce qui est également très important. Cela signifie qu'ils peuvent censurer ou empêcher n'importe quel acteur de leur choix de participer onchain, ce qui est très mauvais.

Et les propriétés de résistance à la censure que nous conservons ne sont pas incroyables, n'est-ce pas ? Étant donné que la plupart des blocs sont construits par ces deux constructeurs, vous devez essentiellement attendre qu'un constructeur de blocs local soit élu et propose un bloc qui inclut toutes ces transactions qui sont normalement censurées, ce qui n'est pas idéal. Cela signifie que ces utilisateurs devront attendre 10, 12, je ne sais pas, beaucoup de blocs avant que leurs transactions ne soient réellement incluses onchain.

Nous voulons donc vraiment conserver les stakers à domicile et les constructeurs de blocs locaux, car ce sont eux qui préservent la résistance à la censure. En même temps, aujourd'hui, même le fait de les utiliser n'est pas génial, car vous devez toujours attendre beaucoup de temps pour que votre transaction soit incluse si elle est censurée par les deux constructeurs. Avec FOCIL, vous passez à un monde où les participants garantissant la résistance à la censure, les membres du comité de la liste d'inclusion dans notre cas, pourraient être différents des personnes qui construisent les blocs. Je pense que cela ouvre des perspectives très intéressantes, car nous n'avons plus besoin de compter sur le même participant pour à la fois construire des blocs de valeur et contribuer à la résistance à la censure. FOCIL peut également être considéré comme une première étape dans cette direction importante, car vous avez deux tâches très différentes, et aujourd'hui nous demandons aux mêmes nœuds validateurs de faire les deux, ce qui crée beaucoup de tension.

Pooja Ranjan : Merci beaucoup. Je pense que la prochaine question est posée par Luis.

Critères de sélection des transactions (26:46)

Luis Pinto : J'ai rejoint quelques minutes après le début, mais il me semble que cela décentralise la sélection des transactions dans le réseau dans son ensemble. C'est une très bonne chose à mon avis ; cela lutte contre la MEV et la censure. Et j'aime vraiment l'idée que les attestateurs fassent ce travail, car à l'avenir, ils auront des exigences matérielles inférieures à celles des constructeurs, d'autant plus avec l'absence d'état et les clients sans état. Puisque vous pourrez exécuter cela avec très peu de matériel, cela rend les choses très décentralisées. Je suppose que le principal défi ici est de définir les critères de sélection des transactions de ces listes d'inclusion, que vous optiez pour les frais de priorité ou le nombre de blobs ; il y a tellement de variables. Avez-vous arrêté un ensemble de critères que vous envisagez d'appliquer ?

Thomas Thiery : C'est une excellente question. Elle comporte deux volets. Le premier est très important, il s'agit d'essayer de séparer les attestateurs des personnes qui construisent ou proposent le bloc. C'est tout l'axe de recherche sur la séparation attestateur-proposant (APS) ; Julian a beaucoup travaillé là-dessus. Nous appelons cela le dégroupage des rôles, afin qu'ils correspondent plus étroitement aux tâches du protocole. J'ai écrit un article, que je viens de partager, sur une séparation possible, qui est très ouverte, et j'aimerais beaucoup avoir plus d'avis de la part des gens. Dans cet article, je fais une séparation entre les attestateurs, les inclueurs, qui sont maintenant les membres du comité IL, et les proposants d'exécution, ou constructeurs. Je pense que ce sont des tâches fondamentalement différentes, et peut-être devrions-nous avoir des rôles différents pour elles.

Ensuite, pour la règle d'inclusion, c'est une très bonne question. Nous y avons pas mal réfléchi, et je pense que nous avons abouti à deux choses. La première est que nous voulons une diversité de règles. Nous ne voulons pas d'une seule règle, par exemple un classement par frais de priorité décroissants pour tous les clients, car alors vous pouvez en fait manipuler le système et essayer de réorganiser la mempool pour que seules vos transactions soient incluses dans les IL. Mais si vous avez une diversité de règles, y compris une règle qui prend également en compte le temps qu'une transaction a passé en attente dans la mempool, et que différents clients implémentent différentes règles, toutes du même genre, principalement autour des frais de priorité et du temps d'attente dans la mempool, alors il est très, très difficile de manipuler le système, et cela rend le protocole encore plus robuste. C'est aussi un bon moyen, je pense, de tirer parti de la diversité des clients que nous avons sur Ethereum aujourd'hui, et de laisser les clients faire des choix tranchés. Nous avons des règles en tête, mais nous pensons que les clients peuvent également choisir les meilleures règles pour eux. Tant que tout le monde n'a pas exactement la même règle classée par frais de priorité, tout ira bien.

Luis Pinto : D'accord, donc vous distribuez également ces critères, en laissant ceux qui construisent les listes d'inclusion avoir leurs propres critères. Ou cela fera-t-il partie du protocole ?

Julian Ma : La règle d'inclusion ne fera pas partie du protocole. Tout d'abord, c'est très difficile à appliquer, et deuxièmement, il est en fait préférable de ne rien imposer. Si nous permettons aux membres du comité de décider par eux-mêmes, ou si nous laissons les équipes clientes agir en leur nom, de la manière dont ils incluent les transactions, alors nous créons une certaine robustesse dans le réseau. Les personnes ayant des préférences différentes incluront de différentes manières, ce qui signifie qu'il est plus difficile d'attaquer le système.

Luis Pinto : D'accord, merci.

Compatibilité avec l'EIP-7702, ePBS et PeerDAS (30:43)

Pooja Ranjan : Merci beaucoup. Si je comprends bien, cette proposition est déjà proposée pour la mise à jour après Pectra, Fusaka. Et étant donné que Fusaka peut inclure ou non d'autres EIP en cours, je me demande quel est le statut de compatibilité de FOCIL par rapport à des propositions telles que la 7702, qui concerne l'abstraction de compte, ePBS et PeerDAS.

Thomas Thiery : Excellente question. Nous avions un petit avantage ici en raison de l'historique des listes d'inclusion. Comme nous l'avons mentionné, la 7547 a été envisagée pour l'inclusion, puis rejetée en raison d'incompatibilités. Nous avons donc pris grand soin de les résoudre avant de faire une nouvelle proposition, car nous savions que les gens allaient l'examiner avec les mêmes questions, ce qui est logique.

Nous sommes très confiants, car nous avons également discuté avec les équipes chargées de l'abstraction de compte, et nous avons beaucoup parlé avec Potuz et Terence. Terence nous a aidés activement, et il a travaillé à la fois sur ePBS et FOCIL, il a donc été très facile pour nous de vérifier si c'était également compatible. Je ne pense vraiment pas qu'il y ait d'incompatibilités avec les autres EIP. Avec ePBS, il faut faire attention au timing, car vous séparez la charge utile d'exécution du bloc de consensus, donc le timing de l'ensemble du créneau change, et maintenant vous ajoutez également la création des IL qui doivent être faites avant que la charge utile ne soit proposée. Il faut donc faire attention aux timings, mais si je me souviens bien, depuis la dernière fois que nous en avons parlé avec Potuz et Terence, il n'y avait aucune incompatibilité cruciale. Je pense que nous sommes bien partis en ce qui concerne la compatibilité.

Pooja Ranjan : C'est bon à savoir. J'ai remarqué que Jihoon a également partagé un HackMD, que nous ajouterons aux ressources, pour les personnes qui souhaiteraient en savoir plus sur la compatibilité avec ePBS en particulier. Et oui, je me souviens de la dernière conversation avec Mike, je suppose que la proposition n'a pas été incluse en raison de l'incompatibilité avec l'abstraction de compte. Il est donc bon de savoir que cela a déjà été réglé.

FOCIL et la MEV multi-créneaux (33:04)

Pooja Ranjan : Je parcourais les documents et les détails ajoutés au site Web de FOCIL, meetfocil.eth.limo, et j'ai découvert un terme appelé MEV multi-créneaux. Julian a également mentionné que MEV-Boost en général est rentable, malgré la volonté et les efforts déployés par les développeurs pour le maintenir à l'équilibre. Je me demande comment FOCIL va empêcher cela.

Julian Ma : Merci pour votre question. Tout d'abord, permettez-moi de dire quelques mots sur FOCIL et la MEV, et ensuite nous pourrons passer à la MEV multi-créneaux. FOCIL n'empêche pas nécessairement la MEV, et c'est précisément parce que nous voulons dissocier les parties liées à la MEV et celles liées à l'inclusion. À notre avis, il est important de le faire, car sinon vous voyez apparaître ce genre de marchés de type IL Boost. Selon ce raisonnement, si la liste d'inclusion pouvait limiter la quantité de MEV extractible, alors la construction de la liste d'inclusion deviendrait très précieuse, et les gens créeraient des marchés autour d'elle. Notre conception est vraiment là pour fournir la garantie d'inclusion minimale, ce qui signifie qu'il n'est pas si précieux d'être membre du comité de la liste d'inclusion, et il y en a 16, ce qui signifie qu'il n'y a pas de marché de producteurs sophistiqués.

Ensuite, pour passer à la MEV multi-créneaux : FOCIL atténue certains des problèmes, mais il ne va pas jusqu'au bout. C'est encore une fois en raison de cette incompatibilité entre le fait de fournir à la fois une résistance à la censure et une solution à la MEV. Ce que fait FOCIL, c'est permettre à n'importe quelle transaction d'être incluse tant qu'elle paie les frais, ce qui résout la MEV multi-créneaux dans une certaine mesure. La MEV multi-créneaux ici, c'est lorsqu'une partie est capable d'extraire plus de MEV si elle contrôle deux blocs d'affilée.

FOCIL atténue certains des problèmes car il vous permet d'insérer votre transaction. Par exemple, si vous devez insérer une transaction liquidant une créance douteuse sur une position quelconque, vous êtes en mesure de le faire même si le proposant essaie de vous censurer et extrairait de la MEV de vous dans le bloc suivant.

La raison pour laquelle il ne résout pas tous les problèmes est due à la sélection adverse, une propriété économique où une personne a plus d'informations que l'autre. Un exemple de MEV multi-créneaux serait l'extraction d'un arbitrage sur deux blocs, où le constructeur de blocs n'extrait pas d'arbitrage dans le premier bloc et le fait dans le second bloc. Il existe des résultats théoriques montrant que cela peut être plus rentable pour le constructeur de blocs que d'extraire l'arbitrage dans les deux créneaux. Vous pourriez penser que FOCIL aide ici, car les arbitragistes pourraient en principe inclure leur transaction dans la liste d'inclusion et ainsi forcer une sorte d'arbitrage à se produire. Bien que ce soit le cas, il n'est pas compatible avec les incitations pour les arbitragistes de soumettre leur transaction à FOCIL, car il s'écoule encore 3 secondes entre la soumission de leur transaction et le moment où le constructeur de blocs peut agir. Si vous essayez de faire de l'arbitrage et que le prix évolue constamment sur un marché externe, vous ne voulez pas vous engager 3 secondes à l'avance, car vous avez beaucoup moins d'informations que le constructeur de blocs, qui agit plus tard que vous. La sélection adverse entre en jeu car le constructeur a plus d'informations : il vous laissera gagner si c'est mauvais pour vous, si le prix sur le marché externe a évolué en votre défaveur pendant ces trois secondes supplémentaires, et il se laissera gagner si c'est mieux pour lui de gagner.

Ainsi, FOCIL résout les parties de la MEV multi-créneaux où les transactions ne subissent pas de sélection adverse. Pour les transactions où il y a une sélection adverse, c'est un peu plus compliqué, mais cela atténue le problème dans une certaine mesure. En principe, cela améliore les choses par rapport à la situation actuelle, mais il reste encore un peu de travail à faire.

Pooja Ranjan : Très bien, merci beaucoup d'avoir partagé cela. Je comprends qu'il y a beaucoup de recherches en cours pour aborder la question de la MEV, il est donc bon de savoir qu'au moins en principe, cela va aider davantage que le scénario actuel.

Compromis et défis (36:44)

Pooja Ranjan : J'ai une question liée à ce que Thomas a mentionné plus tôt concernant l'équivoque des listes d'inclusion (IL). J'ai remarqué que dans la section des considérations de sécurité de la proposition, pas mal de points sont mentionnés, comme la vivacité du consensus, l'équivoque des IL et la construction de la charge utile. Quel serait selon vous le plus grand compromis, ou quelque chose qui pourrait nécessiter plus de recherches et empêcher cette proposition d'être intégrée telle quelle dans la prochaine mise à jour ?

Thomas Thiery : Pour être honnête, je pense que la section sur les considérations de sécurité était surtout un moyen de montrer que nous avons réfléchi aux problèmes de sécurité et que nous les avons traités. C'est plus cela que d'avoir des questions ouvertes sur des aspects de sécurité que nous ignorons. Je ne pense pas qu'il y ait de gros blocages ou de problèmes en termes de considérations de sécurité.

Pour les compromis : si l'on adopte un point de vue très strict, il est vrai que FOCIL ajoute quelques tâches aux validateurs, à la fois lorsqu'ils doivent proposer une liste d'inclusion, et pour les attestateurs, lorsqu'ils doivent vérifier une condition supplémentaire pour s'assurer que le bloc est valide selon les listes d'inclusion. Cela ajoute également une petite tâche pour le proposant, car il doit maintenant s'assurer que sa charge utile inclut réellement les transactions des IL. Pour moi, c'est le seul compromis, et ces tâches ne sont ni lourdes ni complexes. Un membre du comité IL surveille simplement la mempool publique et inclut des transactions dans une liste qu'il envoie. Cela ne nécessite aucune compétence ou sophistication particulière, ce qui est une bonne chose selon moi. D'un autre côté, comme nous l'avons dit, cela pourrait débloquer d'importantes améliorations de mise à l'échelle et une meilleure séparation entre les participants et les tâches au sein du protocole.

Je suis peut-être partial, mais je ne vois pas de gros compromis. Je pense que cela change complètement la donne en matière de résistance à la censure. Maintenant, il suffit qu'environ 15 % du réseau soit honnête pour que toutes les transactions, y compris celles qui pourraient être censurées par les constructeurs, soient incluses dans le bloc suivant, ce qui est une très grande amélioration. Honnêtement, je ne pense pas que l'on fasse beaucoup de compromis ici.

Pooja Ranjan : C'est bon à savoir. Dans la plupart des propositions, nous constatons que la section sur les considérations de sécurité ne contient aucune ou très peu d'informations, il est donc bon de savoir que des recherches ont été menées sur cette partie et que nous sommes conscients des éventuelles considérations de sécurité. Je suis ravie de savoir que ce n'est pas un point de blocage ou un défi potentiel pour la mise en œuvre et l'adoption à l'avenir.

Mécanismes de frais de transaction pour les listes d'inclusion (39:50)

Pooja Ranjan : J'ai une question concernant certaines questions ouvertes que j'ai trouvées sur le site web lui-même, à propos du mécanisme de frais de transaction. Je me demande s'il y a du nouveau, ou si vous aimeriez en dire plus sur la meilleure façon de facturer des frais et de distribuer ces frais pour l'inclusion dans la liste d'inclusion.

Thomas Thiery : Nous avons une subvention en cours qui se penche spécifiquement sur ce point et sur les mécanismes d'incitation pour récompenser les membres du comité de la liste d'inclusion (IL). Ce n'est pas facile. C'est délicat, et peu importe comment vous l'abordez, ce sont aussi de très grands changements. Modifier les frais sur Ethereum, que ce soit en modifiant un frais, en en ajoutant un, ou en ajoutant une nouvelle émission, représente de grands changements qui nécessitent beaucoup de réflexion et de prudence. Mais c'est en cours d'exploration, et les idées autour de la distribution des frais entre, par exemple, les membres du comité qui incluent une transaction semblent être de bonnes idées. Cela a en quelque sorte les propriétés que nous recherchons, car nous voulons récompenser les personnes qui incluent des transactions que d'autres pourraient ne pas vouloir inclure. Nous y réfléchissons donc très sérieusement, et nous avons une subvention en cours.

Il y a aussi la question de savoir si nous voulons un jour accorder des frais aux membres du comité IL, car il est notamment très difficile de récompenser les petits participants répartis dans le monde entier. Vous ne voulez pas d'attaques Sybil, et vous ne voulez pas que de gros participants avec une mise importante évincent l'ensemble du comité IL. Comment empêcher cela ? C'est très difficile. Vous avez donc de nombreuses considérations de conception à prendre en compte.

L'une de mes réflexions récentes est la suivante : et si nous ajoutions des fonctionnalités intéressantes à FOCIL, comme la confidentialité, de sorte que vous ne puissiez pas vraiment savoir qui a proposé une liste de transactions donnée ? Vous savez que c'est quelqu'un qui a été effectivement sélectionné comme membre du comité IL, mais vous ne savez pas exactement qui a proposé quelle liste, vous ne pouvez donc pas lier les membres du comité IL à l'ensemble des transactions de leurs listes d'inclusion. Si nous pouvons avoir cela, et faire en sorte que le rôle du comité IL soit sur la base du volontariat, alors nous aurions probablement des participants honnêtes dans le protocole, s'appuyant sur un comportement altruiste, et peut-être que nous n'aurions pas du tout besoin de mettre en place un mécanisme de frais. C'est un point de vue très récent et tranché, et il est actuellement en cours d'exploration. Toutes ces discussions concernent « l'avenir de FOCIL » ; elles ne sont pas censées être incluses dans l'EIP actuel.

Julian Ma : Juste pour ajouter à cela, cette dernière partie est également très importante : l'EIP-7805 n'inclut aucun mécanisme de frais de transaction, afin de le rendre plus simple à mettre en œuvre. C'est fondamentalement la façon la plus minimaliste possible de fournir les propriétés de résistance à la censure, mais c'est très extensible. Nous nous penchons là-dessus. Thomas a fait pas mal de travail sur des frais de transaction séparés pour les inclueurs et pour les proposants. Ensuite, comme Thomas l'a mentionné, nous avons une subvention en cours avec un chercheur exceptionnel chez Nethermind qui étudie la création d'un mécanisme de frais de transaction pour FOCIL, et c'est très prometteur. Et enfin, il y a eu des travaux sur un mécanisme de frais de transaction pour une variante de FOCIL appelée AUCIL, une conception de liste d'inclusion basée sur des enchères proposée par Sarisht Wadhwa, Fan Zhang et Kartik Nayak avec plusieurs des auteurs de FOCIL, qui cherche des moyens d'inciter les membres du comité de la liste d'inclusion.

Pour revenir au point soulevé par Luis plus tôt, l'incitation concerne en grande partie la façon dont les listes d'inclusion sont créées. Cela signifie que le protocole veut donner une certaine vision de la façon dont les membres du comité de la liste d'inclusion devraient se comporter. En général, cela revient à dire qu'il veut que certains participants fassent des choses différentes. Par exemple, il peut ordonner les membres du comité et leur attribuer certaines transactions via un équilibre corrélé, afin d'avoir toujours un comportement différent entre les membres du comité. Ce n'est donc pas inclus dans la proposition actuelle, mais nous l'étudions sérieusement, et cela s'inscrit dans la lignée de l'extensibilité de FOCIL.

Pooja Ranjan : Oh, c'est intéressant. Nous devrions donc nous attendre à des propositions supplémentaires à l'avenir pour améliorer les fonctionnalités actuelles de FOCIL.

Taille de la liste d'inclusion (44:16)

Pooja Ranjan : J'ai une autre question. Je ne suis pas sûre que cela doive faire partie de la proposition actuelle, mais je suis curieuse de savoir s'il y a du nouveau concernant la taille des IL. Les listes d'inclusion doivent probablement être limitées en taille pour éviter une utilisation excessive de la bande passante. Avons-nous d'autres recherches ou mises à jour sur la façon dont la taille optimale de la liste d'inclusion peut être déterminée ?

Thomas Thiery : Nous avons maintenant une taille fixe dans la spécification, et elle y est depuis un certain temps : 8 kilo-octets. Nous l'avons définie en kilo-octets car ce que FOCIL et les IL consomment réellement, c'est de la bande passante, et c'est à peu près tout. Si vous prenez la taille médiane d'une transaction, nous arrivons à environ 40 transactions par IL, et si toutes les transactions sont uniques, cela représente environ 640 transactions qui pourraient être combinées entre les 16 membres du comité.

Je ne sais pas s'il y a beaucoup de recherches à faire sur la taille optimale exacte. Ce que nous avons choisi : 16 fois 8 kilo-octets correspond essentiellement à la taille d'un blob, ce n'est donc pas une énorme quantité de bande passante combinée. Et comme la combinaison des transactions à travers les IL est plus grande qu'un bloc, je ne pense pas que nous rencontrerons de problèmes à ce niveau.

À l'avenir, vous pourriez augmenter la taille des IL, mais vous pourriez également envisager d'augmenter le nombre de membres du comité des IL. Cela vous permet d'avoir encore plus de chances d'obtenir un membre honnête dans le comité des IL si la majeure partie du réseau décide de commencer à censurer. C'est donc aussi quelque chose que nous pourrions faire. Pour l'instant, il semble que 16 serait tout à fait correct et suffisant, mais vous pourrez certainement jouer avec ces paramètres à l'avenir si la censure devient incontrôlable, ou si nous devons prendre d'autres mesures.

Métriques pour suivre l'adoption (46:39)

Pooja Ranjan : Juste une question de suivi ici : avez-vous des métriques en tête que nous pouvons suivre pour comprendre l'adoption ou le succès de cette proposition ?

Julian Ma : C'est une excellente question. Laissez-moi y répondre rapidement, puis je passerai le relais à Thomas. Quelques métriques simples sont simplement le nombre de listes d'inclusion proposées qui ne sont pas vides. Et vous pourriez penser à des tableaux de bord, comme la série ".pics" de Toni Wahrstätter, où il y a peut-être plus de nuances, en attribuant une certaine mesure de qualité à ces listes d'inclusion. En principe, cependant, une seule personne par créneau a besoin de créer une liste d'inclusion appropriée afin d'assurer la résistance à la censure.

Je pense que c'est un point tellement important qu'il est crucial de mettre en œuvre FOCIL rapidement, car nous sommes actuellement dans ce régime magique où les constructeurs de blocs ne censurent pas trop et les validateurs ne censurent pas trop non plus. Je dirais que c'est très fragile. Jusqu'à présent, les constructeurs de blocs ont censuré pendant longtemps, et si nous introduisons FOCIL maintenant, nous avons la possibilité d'en faire une norme par défaut pour que tous ces validateurs l'adoptent et créent des listes d'inclusion significatives. Étant donné que les constructeurs de blocs ne censurent pas, aucune instabilité du marché n'est créée ici. Si nous attendons qu'il y ait de la censure parmi les constructeurs, il sera alors beaucoup plus difficile d'introduire FOCIL, et j'imagine que toutes les métriques qui seraient utilisées pour mesurer l'adoption seraient bien pires.

Thomas Thiery : Une métrique clé à examiner également est littéralement le délai d'inclusion pour les transactions de la mempool publique. Vous prenez toutes les transactions qui sont en attente dans la mempool publique et vous regardez à quelle vitesse elles sont incluses. Si FOCIL fonctionne, elles seront toutes incluses dans le prochain bloc. Si ce n'est pas le cas, cela signifie qu'une grande proportion de validateurs censure. L'autre métrique que nous pouvons donc examiner est de savoir qui censure, et quelle proportion du réseau censure. Nous aurons des tableaux de bord et des métriques très transparentes pour suivre cela, car c'est fondamentalement ce que FOCIL est censé faire. Si les transactions publiques ne sont pas incluses dans le prochain bloc, cela signifie qu'une très grande partie du réseau censure réellement ces transactions.

Pooja Ranjan : Très intéressant. C'est donc peut-être quelque chose pour les chercheurs : une liste de souhaits possible pour les mises à jour, à savoir que les tableaux de bord et les outils de suivi des métriques devraient être partagés par les développeurs pour une proposition chaque fois qu'elle est incluse dans une mise à jour du réseau.

État de l'implémentation des clients (49:11)

Pooja Ranjan : Comme Julian l'a mentionné, cette proposition devra peut-être être implémentée le plus tôt possible. Je suis curieuse de comprendre où nous en sommes concernant l'implémentation des clients, car je me souviens que lors du dernier appel sur les réseaux de test, Paritosh a mentionné l'ajout d'une certaine prise en charge avec les devnets. Alors, où en sommes-nous à ce sujet ?

Thomas Thiery : Nous nous en sortons plutôt bien. Tout d'abord, c'était super de voir comment les gens ont pris en charge la partie implémentation de FOCIL, car je ne suis pas un développeur, je suis un chercheur. J'ai travaillé avec des développeurs depuis le début, mais ce n'est pas moi qui implémente les choses dans les clients.

Ceux qui ont mené la charge, tous les trois : nous avons Terence de Prysm, et Jihoon, qui a beaucoup aidé Terence sur Prysm mais a également travaillé sur Geth. Donc maintenant, nous avons un devnet fonctionnel pour Prysm et Geth, ce qui est génial, et il y a beaucoup de tests en cours. Nous essayons également maintenant de rendre FOCIL affiché et visible sur l'explorateur Dora. Ensuite, vous avez Jacob, qui a travaillé sur Lighthouse et Reth, et je sais que des efforts sont toujours en cours de ce côté-là. Lodestar a été très actif dernièrement ; je pense qu'ils sont très proches d'avoir un devnet fonctionnel. Nous avons eu des nouvelles de Nethermind aujourd'hui indiquant qu'ils ont un prototype, ce qui est super. J'ai l'impression d'en oublier certains... Nimbus se joint également à nous, dit Jihoon. C'est vraiment bien.

Dans l'ensemble, nous avons de plus en plus de devnets prêts et en ligne, des devnets locaux, et de plus en plus de combinaisons entre les clients de la couche d'exécution et de la couche de consensus. Il y a eu de très bons progrès, et c'est agréable à voir, car nous savons tous que les développeurs sont très occupés en ce moment avec l'arrivée de Pectra, et travaillent déjà sur PeerDAS et d'autres choses. C'était vraiment génial de voir à quel point les gens sur Ethereum en général se soucient de la résistance à la censure. La plupart des équipes que je n'avais pas spécifiquement contactées ont simplement rejoint l'effort et travaillent maintenant sur les devnets et les tests.

Pooja Ranjan : Merci d'avoir partagé cela. J'ai hâte de suivre les mises à jour sur les devnets. Je ne suis pas sûre du nombre d'itérations qu'il y aura pour ce devnet, mais je suis impatiente de voir cela arriver. Je vois que Justin a une question ici. Justin, allez-y s'il vous plaît.

FOCIL dans Fusaka ou Glamsterdam ? (52:07)

Justin : D'accord, accrochez-vous pour celle-ci. Vous avez fait une très bonne remarque en disant que le meilleur moment pour s'attaquer à la censure est avant qu'elle ne se produise, n'est-ce pas ? Donc : FOCIL dans Fusaka, ou cela peut-il attendre Glamsterdam ? Et pour laquelle devrais-je plaider en tant que développeur ?

Thomas Thiery : Nous avons ouvert la PR, et elle a été fusionnée, FOCIL étant proposé pour Fusaka. Nous pensons que cela devrait être intégré à Fusaka. Une partie du raisonnement est que certains clients ont déjà commencé à y travailler, et ils n'ont pas rencontré trop d'obstacles. Ce n'est pas comme d'autres propositions qui sont beaucoup plus difficiles à mettre en œuvre et impliquent beaucoup plus de travail. Et ce n'est pas très controversé non plus. Je ne pense pas que quiconque plaide contre la résistance à la censure, et tout le monde est plus ou moins d'accord pour dire que cela doit être inclus dès que possible. Donc j'opterais pour Fusaka.

Je ne sais pas si cela peut attendre ou non. Les propositions et les mises à jour peuvent toujours attendre. Je veux juste éviter un monde dans lequel il n'est pas aussi facile de mettre en œuvre ces changements. Les choses peuvent basculer très rapidement. Comme nous l'avons vu, cela s'est passé dans l'autre sens : il y a quelques mois, l'un des principaux constructeurs a soudainement arrêté de censurer. Nous avons demandé pourquoi, et la réponse a été du genre : « ouais, nous avons juste décidé de ne pas le faire ». C'était une bonne chose dans ce cas, car c'était du bon côté, mais cela peut complètement s'inverser, et nous pourrions alors avoir les deux constructeurs censurant certaines transactions, et nous nous retrouverions dans une très mauvaise situation.

L'autre chose que je veux mentionner, car je pense vraiment que c'est important : si nous allons vers certaines des choses dont nous avons parlé, comme l'APS, où vous pouvez réellement séparer l'attestateur et le proposant avec certaines des conceptions sur lesquelles nous avons travaillé, nous devons intégrer FOCIL avant cela, et nous devons savoir que FOCIL fonctionne. Nous avons besoin de FOCIL sur le Réseau principal pendant six mois, un an, pour être vraiment sûrs qu'il remplit son objectif, qui est de maintenir et d'améliorer les propriétés de résistance à la censure d'Ethereum. Donc, une autre urgence, du moins pour moi, est que si nous voulons protéger les attestateurs des jeux de timing et de certaines autres préoccupations que nous voulons aborder avec l'APS, nous devons intégrer FOCIL dès que possible.

Pooja Ranjan : Il est parfois triste de voir que des propositions ne sont pas sélectionnées pour la prochaine mise à jour ou la plus proche, mais seul un certain nombre de propositions peuvent être incluses dans une seule mise à jour. J'apprécie vraiment tout le travail acharné qui est fait derrière la soumission de la proposition, la préparation de la proposition, ainsi que les tests qui y sont associés. Donc merci beaucoup pour tout le travail que vous faites pour l'écosystème Ethereum.

Questions en rafale (55:18)

Pooja Ranjan : Avant de conclure, nous avons une petite série de questions en rafale. La seule condition est que la réponse doit tenir en un mot ou une phrase, et nous essaierons de le faire avec un chronomètre, peut-être 30 secondes chacun. Si vous êtes prêts, allons-y et commençons par Julian. Quel est le problème le plus difficile dans la recherche sur la chaîne de blocs en ce moment ?

Julian Ma : Je ne vais pas trop faire de mèmes, donc je vais répondre sérieusement. Je dirais que le problème le plus difficile est l'avenir du staking : ce que signifie l'avenir du staking, quels rôles jouent les fournisseurs de services, comment ils sont rémunérés pour cela, et comment ils interagissent les uns avec les autres.

Pooja Ranjan : Quel est le cas d'utilisation de la chaîne de blocs qui n'a pas été suffisamment exploré ?

Julian Ma : Je dirais FOCIL.

Pooja Ranjan : Quel est le plus grand risque de sécurité pour Ethereum aujourd'hui ?

Julian Ma : Honnêtement, je dirais que la résistance à la censure est très critique ici, en raison de choses comme la MEV multi-blocs qui pourrait poser d'énormes risques de sécurité, par exemple pour les couches 2 (l2).

Pooja Ranjan : La MEV doit-elle être minimisée, adoptée, ou quelque chose entre les deux ?

Julian Ma : Je suis largement d'accord avec le point de vue de Flashbots ici, à savoir qu'elle devrait être démocratisée, ce qui signifie qu'elle devrait être maximisée là où c'est nécessaire, et minimisée au niveau de la couche applicative.

Pooja Ranjan : La décentralisation vaut-elle toujours les compromis ?

Julian Ma : Elle vaut généralement les compromis.

Pooja Ranjan : Quelle est la plus grande innovation qu'Ethereum a apportée au monde ?

Julian Ma : Ici, j'aimerais citer la présentation de Mike Neuder à la Devcon sur les droits de propriété numérique. Je dirais les droits de propriété numérique résistants à la censure qui changent vraiment le monde.

Pooja Ranjan : Merci beaucoup, très bien répondu. Ma prochaine série de questions s'adresse à Thomas. Alors, si Ethereum n'existait pas, sur quelle chaîne de blocs travailleriez-vous ?

Thomas Thiery : Je pense que je vais faire beaucoup de mèmes, et Julian m'a un peu coupé l'herbe sous le pied parce que je pensais qu'il allait faire la même chose. La chaîne de blocs serait FOCIL.

Pooja Ranjan : Quel est le cas d'utilisation le plus survendu pour la chaîne de blocs ?

Thomas Thiery : Aucun cas d'utilisation ne mérite d'engouement sans FOCIL.

Pooja Ranjan : Quelle est la chose qu'Ethereum doit améliorer le plus rapidement possible ?

Thomas Thiery : La résistance à la censure, avec FOCIL.

Pooja Ranjan : Un mot pour décrire la décentralisation ?

Thomas Thiery : FOCIL.

Pooja Ranjan : Pensez-vous qu'Ethereum résoudra complètement le problème de la scalabilité ?

Thomas Thiery : Ethereum avec FOCIL, oui.

Pooja Ranjan : La mise à l'échelle de la couche 1 (l1) ou de la couche 2 (l2), laquelle gagne ?

Thomas Thiery : Une infinité de couches, toutes avec FOCIL.

Pooja Ranjan : Très bien joué, merci beaucoup, Thomas. Merci d'avoir répondu à toutes ces questions. Alors que nous concluons, j'aimerais vous donner cette opportunité : si vous avez un message pour la communauté concernant la proposition, ou pour la communauté Ethereum en général.

Messages à la communauté (58:08)

Thomas Thiery : En fait, c'est un point très important, car nous avons des discussions actives en permanence, et tout est public sur le Discord. Il y a eu une volonté au début de tout rendre public, et les gens le font vraiment, donc j'en suis très heureux. Vous pouvez suivre les discussions et les progrès sur le Discord public Eth R&D, dans le canal inclusion-list. C'est essentiellement là que tout se passe en ce moment. Ensuite, vous pouvez nous contacter sur Twitter, Telegram, n'importe où. N'hésitez pas.

Plus nous échangeons avec des personnes et les impliquons, meilleures seront la conception et l'implémentation. Donc, si vous pouvez aider d'une manière ou d'une autre, contactez-nous et nous serons heureux de vous aider à tous les niveaux, même du côté de la recherche. C'est encore plus approprié, je suppose, pour nous de travailler avec des personnes qui veulent travailler sur l'avenir de FOCIL. Nous avons mentionné la confidentialité, nous avons mentionné les mécanismes de frais de transaction, et nous allons également beaucoup nous concentrer sur FOCIL pour les blobs. Toutes ces choses nécessitent des personnes et des efforts de recherche. Si vous êtes intéressé, contactez-nous. Merci beaucoup de nous avoir invités, et merci pour tout le travail que vous faites pour Ethereum également.

Julian Ma : Juste pour ajouter à cela, j'espère que nous avons rendu certaines personnes enthousiastes à propos de FOCIL. Si vous êtes enthousiaste, n'hésitez pas à nous le faire savoir. Et s'il vous reste des questions, nous serons heureux d'y répondre, et nous espérons pouvoir vous convaincre que FOCIL est bel et bien la voie à suivre. Merci beaucoup. C'était vraiment un plaisir d'être ici, et merci d'avoir animé la session. Et merci également à tous les participants, bien sûr.

Mot de la fin (59:52)

Pooja Ranjan : Merci. C'est tout pour aujourd'hui. Un grand merci à Thomas et Julian de s'être joints à nous aujourd'hui et d'avoir partagé leurs connaissances sur l'EIP-7805. Merci à tous les participants ; vos questions sont encourageantes et instructives. Merci de nous avoir suivis. Si vous avez apprécié cette conversation, n'oubliez pas d'aimer, de vous abonner et de partager cet épisode avec vos amis passionnés d'Ethereum. Nous vous présenterons d'autres EIP et avancées de recherche sur PEEPanEIP. D'ici la prochaine fois, continuez à ronronner de connaissances et à rôder sur Ethereum avec les Ethereum Cat Herders. Passez une excellente fin de journée.