Finalité à slot unique

Il faut environ 15 minutes pour qu'un bloc Ethereum soit finalisé. Cependant, nous pouvons rendre le mécanisme de consensus d'Ethereum plus efficace pour valider les blocs et réduire considérablement le temps de finalité. Au lieu d'attendre quinze minutes, les blocs pourraient être proposés et finalisés dans le même créneau. Ce concept est connu sous le nom de finalité à slot unique (SSF).

Qu'est-ce que la finalité ?

Dans le mécanisme de consensus basé sur la preuve d'enjeu (PoS) d'Ethereum, la finalité fait référence à la garantie qu'un bloc ne peut pas être modifié ou retiré de la chaîne de blocs sans brûler au moins 33 % du total des ETH mis en jeu. Il s'agit d'une sécurité « crypto-économique » car la confiance provient du coût extrêmement élevé associé à la modification de l'ordre ou du contenu de la chaîne, ce qui dissuaderait tout acteur économique rationnel de s'y essayer.

Pourquoi viser une finalité plus rapide ?

Le temps de finalité actuel s'est avéré trop long. La plupart des utilisateurs ne veulent pas attendre 15 minutes pour la finalité, et il est peu pratique pour les applications et les plateformes d'échange qui pourraient souhaiter un débit de transaction élevé de devoir attendre aussi longtemps pour être certains que leurs transactions sont permanentes. Le fait d'avoir un délai entre la proposition d'un bloc et sa finalisation crée également une opportunité pour de courtes réorganisations qu'un attaquant pourrait utiliser pour censurer certains blocs ou extraire de la MEV. Le mécanisme qui gère la mise à niveau des blocs par étapes est également assez complexe et a été corrigé à plusieurs reprises pour combler des failles de sécurité, ce qui en fait l'une des parties de la base de code d'Ethereum où des bugs subtils sont les plus susceptibles d'apparaître. Tous ces problèmes pourraient être éliminés en réduisant le temps de finalité à un seul créneau.

Le compromis entre décentralisation, temps et surcharge

La garantie de finalité n'est pas une propriété immédiate d'un nouveau bloc ; il faut du temps pour qu'un nouveau bloc soit finalisé. La raison en est que les validateurs représentant au moins 2/3 du total des ETH mis en jeu sur le réseau doivent voter pour le bloc (« attester ») afin qu'il soit considéré comme finalisé. Chaque nœud de validation sur le réseau doit traiter les attestations des autres nœuds afin de savoir si un bloc a atteint, ou non, ce seuil des 2/3.

Plus le temps alloué pour atteindre la finalisation est court, plus la puissance de calcul requise à chaque nœud est importante, car le traitement des attestations doit être effectué plus rapidement. De plus, plus il y a de nœuds de validation sur le réseau, plus il y a d'attestations à traiter pour chaque bloc, ce qui augmente également la puissance de traitement requise. Plus la puissance de traitement requise est élevée, moins il y a de personnes qui peuvent participer, car un matériel plus coûteux est nécessaire pour faire fonctionner chaque nœud de validation. Augmenter le temps entre les blocs réduit la puissance de calcul requise à chaque nœud, mais allonge également le temps de finalité, car les attestations sont traitées plus lentement.

Par conséquent, il existe un compromis entre la surcharge (puissance de calcul), la décentralisation (nombre de nœuds pouvant participer à la validation de la chaîne) et le temps de finalité. Le système idéal équilibre une puissance de calcul minimale, une décentralisation maximale et un temps de finalité minimal.

Le mécanisme de consensus actuel d'Ethereum a équilibré ces trois paramètres en :

Fixant la mise minimale à 32 ETH. Cela fixe une limite supérieure au nombre d'attestations de validateurs qui doivent être traitées par les nœuds individuels, et donc une limite supérieure aux exigences de calcul pour chaque nœud.
Fixant le temps de finalité à environ 15 minutes. Cela donne suffisamment de temps aux validateurs fonctionnant sur des ordinateurs personnels normaux pour traiter en toute sécurité les attestations pour chaque bloc.

Avec la conception actuelle du mécanisme, afin de réduire le temps de finalité, il est nécessaire de réduire le nombre de validateurs sur le réseau ou d'augmenter les exigences matérielles pour chaque nœud. Cependant, des améliorations peuvent être apportées à la façon dont les attestations sont traitées, ce qui peut permettre de comptabiliser davantage d'attestations sans augmenter la surcharge à chaque nœud. Un traitement plus efficace permettra de déterminer la finalité au sein d'un seul créneau, plutôt que sur deux époques.

Voies vers la SSF

Le mécanisme de consensus actuel combine les attestations de plusieurs validateurs, appelés comités, pour réduire le nombre de messages que chaque validateur doit traiter pour valider un bloc. Chaque validateur a l'opportunité d'attester à chaque époque (32 créneaux), mais dans chaque créneau, seul un sous-ensemble de validateurs, appelé « comité », atteste. Ils le font en se divisant en sous-réseaux dans lesquels quelques validateurs sont sélectionnés pour être des « agrégateurs ». Ces agrégateurs combinent chacun toutes les signatures qu'ils voient des autres validateurs de leur sous-réseau en une seule signature agrégée. L'agrégateur qui inclut le plus grand nombre de contributions individuelles transmet sa signature agrégée au proposeur de bloc, qui l'inclut dans le bloc avec la signature agrégée des autres comités.

Ce processus offre une capacité suffisante pour que chaque validateur puisse voter à chaque époque, car 32 slots * 64 committees * 256 validators per committee = 524,288 validators per epoch. Au moment de la rédaction (février 2023), il y a environ 513 000 validateurs actifs.

Dans ce schéma, il n'est possible pour chaque validateur de voter sur un bloc qu'en répartissant ses attestations sur toute l'époque. Cependant, il existe potentiellement des moyens d'améliorer le mécanisme afin que chaque validateur ait la chance d'attester dans chaque créneau.

Depuis la conception du mécanisme de consensus d'Ethereum, le schéma d'agrégation de signatures (BLS) s'est avéré beaucoup plus évolutif qu'on ne le pensait initialement, tandis que la capacité des clients à traiter et vérifier les signatures s'est également améliorée. Il s'avère que le traitement des attestations d'un très grand nombre de validateurs est en fait possible au sein d'un seul créneau. Par exemple, avec un million de validateurs votant chacun deux fois dans chaque créneau, et des temps de créneau ajustés à 16 secondes, les nœuds seraient tenus de vérifier les signatures à un rythme minimum de 125 000 agrégations par seconde afin de traiter l'ensemble du million d'attestations dans le créneau. En réalité, il faut environ 500 nanosecondes à un ordinateur normal pour effectuer une vérification de signature, ce qui signifie que 125 000 peuvent être effectuées en environ 62,5 ms - bien en dessous du seuil d'une seconde.

D'autres gains d'efficacité pourraient être réalisés en créant des supercomités de, par exemple, 125 000 validateurs sélectionnés au hasard par créneau. Seuls ces validateurs peuvent voter sur un bloc et, par conséquent, seul ce sous-ensemble de validateurs décide si un bloc est finalisé. Savoir si c'est une bonne idée ou non revient à déterminer à quel point la communauté souhaiterait qu'une attaque réussie sur Ethereum soit coûteuse. En effet, au lieu de nécessiter les 2/3 du total des ethers mis en jeu, un attaquant pourrait finaliser un bloc malhonnête avec les 2/3 des ethers mis en jeu dans ce supercomité. Il s'agit toujours d'un domaine de recherche actif, mais il semble plausible que pour un ensemble de validateurs suffisamment grand pour nécessiter des supercomités en premier lieu, le coût d'attaque de l'un de ces sous-comités sera extrêmement élevé (par exemple, le coût d'attaque libellé en ETH serait de 2/3 * 125,000 * 32 = ~2.6 million ETH). Le coût de l'attaque peut être ajusté en augmentant la taille de l'ensemble des validateurs (par exemple, ajuster la taille des validateurs pour que le coût de l'attaque soit égal à 1 million d'ethers, 4 millions d'ethers, 10 millions d'ethers, etc.). Des sondages préliminaires (opens in a new tab) auprès de la communauté semblent suggérer que 1 à 2 millions d'ethers constituent un coût d'attaque acceptable, ce qui implique environ 65 536 à 97 152 validateurs par supercomité.

Cependant, la vérification n'est pas le véritable goulot d'étranglement - c'est l'agrégation de signatures qui met vraiment les nœuds de validation à l'épreuve. Pour faire évoluer l'agrégation de signatures, il faudra probablement augmenter le nombre de validateurs dans chaque sous-réseau, augmenter le nombre de sous-réseaux ou ajouter des couches supplémentaires d'agrégation (c'est-à-dire mettre en œuvre des comités de comités). Une partie de la solution pourrait consister à autoriser des agrégateurs spécialisés - de la même manière que la construction de blocs et la génération d'engagements pour les données de rollup seront externalisées à des constructeurs de blocs spécialisés dans le cadre de la séparation proposant-constructeur (PBS) et du danksharding.

Quel est le rôle de la règle de choix de fourche dans la SSF ?

Le mécanisme de consensus actuel repose sur un couplage étroit entre le gadget de finalité (l'algorithme qui détermine si les 2/3 des validateurs ont attesté d'une certaine chaîne) et la règle de choix de fourche (l'algorithme qui décide quelle chaîne est la bonne lorsqu'il y a plusieurs options). L'algorithme de choix de fourche ne prend en compte que les blocs depuis le dernier bloc finalisé. Sous la SSF, il n'y aurait aucun bloc à prendre en compte pour la règle de choix de fourche, car la finalité se produit dans le même créneau que celui où le bloc est proposé. Cela signifie que sous la SSF, soit l'algorithme de choix de fourche, soit le gadget de finalité serait actif à tout moment. Le gadget de finalité finaliserait les blocs où les 2/3 des validateurs étaient en ligne et attestaient honnêtement. Si un bloc n'est pas en mesure de dépasser le seuil des 2/3, la règle de choix de fourche interviendrait pour déterminer quelle chaîne suivre. Cela crée également une opportunité de maintenir le mécanisme de fuite d'inactivité qui récupère une chaîne où plus d'un tiers des validateurs se déconnectent, bien qu'avec quelques nuances supplémentaires.

Problèmes en suspens

Le problème avec la mise à l'échelle de l'agrégation en augmentant le nombre de validateurs par sous-réseau est que cela entraîne une charge plus importante sur le réseau pair à pair. Le problème avec l'ajout de couches d'agrégations est que c'est assez complexe à concevoir et ajoute de la latence (c'est-à-dire qu'il pourrait falloir plus de temps au proposeur de bloc pour recevoir les informations de tous les agrégateurs de sous-réseaux). Il n'est pas non plus clair comment gérer le scénario où il y a plus de validateurs actifs sur le réseau qu'il n'est possible d'en traiter dans chaque créneau, même avec l'agrégation de signatures BLS. Une solution potentielle est que, puisque tous les validateurs attestent dans chaque créneau et qu'il n'y a pas de comités sous la SSF, le plafond de 32 ETH sur le solde effectif pourrait être entièrement supprimé, ce qui signifie que les opérateurs gérant plusieurs validateurs pourraient consolider leur mise et en faire fonctionner moins, réduisant ainsi le nombre de messages que les nœuds de validation doivent traiter pour prendre en compte l'ensemble des validateurs. Cela repose sur le fait que les grands stakers acceptent de consolider leurs validateurs. Il est également possible d'imposer un plafond fixe sur le nombre de validateurs ou le montant d'ETH mis en jeu à tout moment. Cependant, cela nécessite un mécanisme pour décider quels validateurs sont autorisés à participer et lesquels ne le sont pas, ce qui est susceptible de créer des effets secondaires indésirables.

Progrès actuels

La SSF est en phase de recherche. Son déploiement n'est pas prévu avant plusieurs années, probablement après d'autres mises à niveau substantielles telles que les arbres Verkle et le danksharding.

Complément d'information

Dernière mise à jour de la page : 6 juin 2026