Ce document a été motivé par notre travail sur le FOCIL consensus spec 23, où nous avons réalisé que le protocole nécessitait une réflexion plus approfondie sur les contraintes de ressources, car certains détails n'étaient pas explicitement spécifiés dans le FOCIL Ethereum recherche post 14.

Prérequis

Avant de commencer, nous supposons la configuration suivante pour établir une base propre pour nos considérations:

• La configuration est basée sur la fourchette dure Electra. Il a également du sens de revoir cela sur la base de l'EIP-7732 (ePBS) pour comparaison
• Nous supposons la construction et la publication de blocs en solo, où le proposant n'exécute pas MEV-Boost. C'est le premier élément clé à bien faire, tandis que l'API du constructeur est une considération secondaire
• Nous supposons une configuration de staker solo avec les exigences de calcul, de mémoire et de bande passante typiques que vous pouvez facilement suivre sur la chaîne Ethereum aujourd'hui

Acteurs

Avant de continuer, nous supposons que les acteurs suivants font partie du protocole et analysons leurs responsabilités:

• Les membres du comité de la liste d'inclusion (IL), qui sont responsables de restreindre le prochain proposant de créneaux par son ensemble de transactions de liste d'inclusion
• Le proposant, qui est responsable de proposer le prochain emplacement
• Les validateurs qui attestent pour le prochain emplacement pour le chef de chaîne
• Les nœuds, qui vérifient et suivent la chaîne. Les proposants et les témoins font partie des nœuds qui ont misé de l'Ether.

Chronologie

Nous supposons la chronologie suivante dans laquelle le comité IL, le proposant et les validateurs effectuent des actions honnêtes :

• Slot n-1, t=6: Le comité d'IL publie leurs listes d'inclusion locales (IL) sur un sujet mondial après avoir pris connaissance du contenu du bloc n-1
• Fente n-1, t=9: Les validateurs et les nœuds de vérification honnêtes verrouillent leur vue des IL locaux
• Slot n, t=0: Le proposant de bloc pour la fente n libère le bloc B, qui inclut la charge utile qui devrait satisfaire l'exigence IL
• Slot n, t=4: Les testeurs pour le slot n votent sur le bloc B, vérifiant l'agrégation de l'IL en le comparant à leurs vues locales de l'IL et confirmant si le bloc B est “valide”
  • Nous surchargeons le mot "valide" lorsqu'il s'agit d'un bloc, mais cela pourrait signifier "importable", "canonique", ou autre chose. Voir la question ouverte pour plus de clarification

Intervalle 1 : Le comité IL publie l'IL local

Acteur: Comité de la liste d'inclusion

Les membres du comité IL récupèrent une liste des transactions IL du client EL étant donné la tête (appel CL → EL), puis ils signent le IL local (transactions + résumés) et le publient sur le réseau de ragots.

Considérations sur les ressources

• Récupération des transactions IL depuis le pool de mémoire EL → CPU/MEM
• Signature de la liste d'inclusion → CPU
• Téléchargement de la liste d'inclusion sur le réseau de commérages → Bande passante (Téléchargement)

Acteur: Noeuds (y compris les Attestants)

Les nœuds suivant la chaîne téléchargeront le IL, le vérifieront pour anti-DOS (sans l'importer dans EL pour le moment), et le transmettront à d'autres pairs. Les nœuds importent également le IL dans le choix de la fourche et suivent les IL qui ont été vus en utilisant un cache aggreGate. Les validateurs et les nœuds suivant la chaîne devraient avoir la même vue de la chaîne.

Considérations relatives aux ressources

• Téléchargement de l'IL → Bande passante (Téléchargement)
• Transfert de la bande passante → IL (téléchargement)
• Vérification de l'IL pour anti-DOS → CPU/MEM
• Caching vu et aggreGate ILs → MEM

Acteur: Proposant

Le proposant pour le prochain créneau surveille activement le réseau de messagerie IL, collecte et agrège les IL locaux, puis, à la coupure d'agrégation IL (intervalle #2), le proposant met à jour le processus de construction de bloc avec une liste de transactions IL à inclure pour son bloc. Cela nécessite un appel CL à EL.

Considérations de ressources

• Hérite des mêmes coûts que les nœuds suivant la chaîne

Cas limite du proposant

Si le proposant du prochain créneau observe un nombre suffisant de listes d'inclusion basées sur un hachage parent qu'il n'a pas vu, le proposant devra demander manuellement le bloc beacon manquant, importer le bloc et construire dessus.

Conclusion

Basé sur ce qui précède, nous pouvons identifier les domaines potentiellement gourmands en ressources et les restreindre.

• Impact du CPU du comité IL : récupération des transactions IL à partir d'EL et signature : bien qu'il y ait des demandes de ressources ici, cela est présumé relativement peu coûteux et pas une préoccupation majeure.
• Impact sur la bande passante des nœuds : Les nœuds téléchargeant et téléchargeant des IL peuvent utiliser des tonnes de bande passante, en particulier la publication de recherche actuelle indique que la taille de la liste d'inclusion est flexible / non bornée. Cela introduit un risque potentiel de DOS, car un membre malveillant du comité IL pourrait inonder le réseau avec un grand nombre de transactions, même si elles sont invalides. Les nœuds continueront à propager les IL avant de les importer. Des mesures anti-DoS doivent être envisagées avec soin.

Interval 2: Les nœuds verrouillent leur vue, l'importateur de proposition importe les transactions IL

Acteur: Proposant

Le proposant met à jour le processus de construction de bloc avec une liste de transactions de la liste d'inclusion. Il s'agit d'un appel CL → EL.

Considérations sur les ressources

• Mises à jour du processus de construction de bloc avec une liste de transactions incluses dans la liste → CPU/MEM

Acteur: Noeuds (y compris Attestants)

Vue de la liste d'inclusion de verrouillage. Arrêtez d'accepter la liste d'inclusion locale à partir de ce point.

Considérations des ressources

• Verrouiller la vue de la liste d'inclusion locale → Aucun

Conclusion

• Impact sur le processeur du proposant : L'importation des transactions IL dans le processus de construction des blocs pourrait perturber ce processus, ce qui pourrait solliciter le processeur du client de la couche d'exécution lors de la simulation des transactions. Cela pourrait devenir compliqué avec l'abstraction des comptes car les transactions pourraient s'annuler mutuellement. Cela devrait être analysé plus en détail.

Intervalle 3: Le proposant publie un bloc

Acteur: Proposant

Le demandeur récupère la charge d'exécution du client EL (appel CL → EL) et la libère dans le réseau de diffusion de blocs de balisage. Tout le monde vérifie ensuite le bloc.

Considérations sur les ressources

• Récupération de la charge utile à partir du client EL → CPU/MEM

Acteur : Nodes

Les nœuds reçoivent le bloc phare et le vérifient. Les nouvelles étapes de vérification comprennent la vérification de la construction de la liste d'inclusion aggreGate et la confirmation que la liste d'inclusion satisfait la fonction d'évaluation, qui doit être terminée sur le CL. La vérification des conditions de l'IL (qu'elles peuvent être sautées en raison de conflits ou non) sera effectuée sur l'EL.

Considérations de ressources

• Vérification que la liste d'inclusion est satisfaite sur CL → CPU
• Vérification des conditions de liste d'inclusion sur EL → CPU

Conclusion

Les tâches supplémentaires pour le demandeur ne semblent pas être une préoccupation majeure. Les nouvelles étapes de vérification pour les nœuds - vérifier si la liste d'inclusion satisfait les conditions requises - peuvent entraîner une charge CPU supplémentaire, mais cela ne semble pas être un problème majeur.

Intervalle 4 : Comité Attesteur

Acteur : Attester

L'attestant vote pour le bloc phare en utilisant la règle de choix de fourchette LMD GHOST. Les attestants ne voteront que pour un bloc phare qui satisfait la fonction d'évaluation de la liste d'inclusion, basée sur les observations de l'Interval 1.

Considérations sur les ressources

• Les validateurs votent pour un bloc qui satisfait la fonction d'évaluation de la liste d'inclusion → Pas de coût supplémentaire

Conclusion

Il n'y a aucune différence par rapport à aujourd'hui.

Résumé de la considération des ressources

Comme on peut le voir ci-dessus, les principales préoccupations concernant les ressources tournent autour de l'importation et du téléchargement d'une liste d'inclusion, ainsi que du potentiel de spam depuis la perspective d'un nœud. Un autre point clé est la charge supplémentaire pour les nœuds lors de la vérification et de l'importation de la liste d'inclusion, ainsi que la nécessité pour le proposeur de mettre à jour son processus de construction de bloc pour satisfaire à la liste d'inclusion. Ces aspects nécessitent une réflexion et une conception minutieuses pour garantir efficacité et sécurité.

Questions ouvertes

Sur la base de ce qui précède, nous soulignons plusieurs questions ouvertes qui influenceront la rédaction de la spécification :

1. Bloc ne satisfaisant pas la fonction d'évaluation : Comment un bloc qui échoue la fonction d'évaluation de la liste d'inclusion doit-il être traité, et quelles considérations de conception entrent en jeu pour de telles conditions ?
   • Doit-il être traité de manière similaire aux blobs et ne peut pas être importé?
   • Ne devrait-il pas être filtré par le choix du fork?
   • Ne devrait-ce pas être valide dans la fonction de transition d'état?
2. Liste d'inclusion des équivoques : Si un membre du comité de liste d'inclusion envoie différentes versions de la liste d'inclusion à différents nœuds, et qu'elles sont toutes propagées à travers le réseau, quelles sont les conséquences de cette action ? Comment un tel comportement pourrait-il avoir un impact négatif sur le proposeur qui construit le bloc suivant ?
3. Le proposant construit déjà sur une tête différente : Si le proposant construit sur une tête différente de celle envoyée par le comité d'inclusion, et doit donc changer sa vue de tête, quelles sont les conséquences de cette action sur la validité du bloc et le comportement du proposant ?
4. Invalidations des transactions de la liste d'inclusion : Les transactions de la liste d'inclusion locale peuvent être invalidées de plusieurs façons. Même si ces transactions sont invalidées, le bloc devrait toujours être en mesure de satisfaire la fonction d'évaluation. Les transactions peuvent être invalidées lorsque plusieurs listes d'inclusion se fusionnent entre elles ou avec des transactions dans le bloc. En plus de la vérification habituelle du nonce, l'abstraction de compte introduit de nouvelles façons d'invalidation des transactions, car le solde peut être vidé avec un nonce statique. Il reste à voir combien de simulations supplémentaires un constructeur de bloc doit effectuer en raison de l'invalidation des transactions et dans quelle mesure cela affecte son calcul CPU, tant pour les acteurs MEV-Boost que pour les constructeurs locaux.
5. Observation du sous-réseau du comité d'inclusion du proposant : Le proposant surveille le sous-réseau du comité d'inclusion pour savoir quand il est prêt à construire l'aggreGate. Il existe deux approches de conception ici, et il vaut la peine de les considérer davantage. La première approche est un proposant avide, où le proposant attend jusqu'à t=9, rassemble autant d'IL que possible, les envoie à l'EL, et l'EL met à jour son bloc. La deuxième approche est un proposant sélectif, où le proposant attend d'avoir une liste d'inclusion suffisante pour satisfaire la fonction d'évaluation, les envoie à l'EL, et peut le faire en moins de t=9s ou même plus tôt. La question est de savoir si la deuxième approche justifie l'optimisation permettant au proposant de libérer l'aggreGate d'inclusion plus tôt. La deuxième approche peut ne convenir qu'à une IL avec sa propre limite de gaz dédiée.

Avertissement :

1. Cet article est repris de [Gateethresear]. Tous les droits d'auteur appartiennent à l'auteur original [terence]. If there are objections to this reprint, please contact the Gate Learnl'équipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent en aucun cas des conseils en investissement.
3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.