Le chemin de la vérifiabilité

Le principal avantage de Web3 est sa vérifiabilité - les utilisateurs peuvent vérifier le fonctionnement réel des systèmes. Cette fonctionnalité explique pourquoi de nombreuses personnes, à l’intérieur et à l’extérieur de l’industrie de la cryptographie, décrivent Web3 comme une étape vers un internet plus transparent et vérifiable.

Contrairement aux plateformes Web2 telles que Facebook ou Instagram, où les algorithmes et les règles restent opaques, même lorsqu’ils sont documentés, les protocoles crypto sont conçus pour une auditabilité complète. Même s’ils sont partagés, vous ne disposez pas de la capacité de vérifier si la plateforme fonctionne comme spécifié. C’est le contraire de la crypto, où chaque protocole est conçu pour être aussi auditable que possible - ou du moins, on s’attend à ce qu’il le soit.

Aujourd’hui, nous allons explorer “The Verge”, une section récemment publiée par Vitaliksérie en six parties sur l’avenir d’Ethereum, pour analyser les mesures prises par Ethereum pour atteindre la vérifiabilité, la durabilité et la scalabilité à l’avenir. Sous le titre « The Verge », nous discuterons de la manière dont les architectures de blockchain peuvent être rendues plus vérifiables, des innovations que ces changements apportent au niveau du protocole, et de la manière dont ils offrent aux utilisateurs un écosystème plus sécurisé. Commençons !

Que signifie la “vérifiabilité” ?

Les applications Web2 fonctionnent comme des “boîtes noires” - les utilisateurs ne peuvent voir que leurs entrées et les sorties résultantes, sans visibilité sur le fonctionnement réel de l’application. En revanche, les protocoles de cryptomonnaie rendent généralement leur code source public, ou du moins ont l’intention de le faire. Cette transparence sert à deux fins: elle permet aux utilisateurs d’interagir directement avec le code du protocole s’ils le souhaitent, et elle les aide à comprendre exactement comment le système fonctionne et quelles règles le régissent.

“Décentralisez ce que vous pouvez, vérifiez le reste.”

La vérifiabilité garantit que les systèmes sont responsables et, dans de nombreux cas, garantit que les protocoles fonctionnent comme prévu. Ce principe souligne l’importance de minimiser la centralisation, car elle conduit souvent à des structures opaques et irresponsables où les utilisateurs ne peuvent pas vérifier les opérations. Au lieu de cela, nous devrions nous efforcer de décentraliser autant que possible et de rendre les éléments restants vérifiables et responsables là où la décentralisation n’est pas réalisable.

La communauté Ethereum semble être en phase avec cette perspective, comme la feuille de routeinclut une étape (appelée “The Verge”) visant à rendre Ethereum plus vérifiable. Cependant, avant de se plonger dans The Verge, nous devons comprendre quels aspects des blockchains doivent être vérifiés et quels éléments sont cruciaux du point de vue des utilisateurs.

Les blockchains fonctionnent essentiellement comme des horloges mondiales. Dans un réseau distribué avec environ 10 000 ordinateurs, il peut falloir un temps considérable pour qu’une transaction se propage du nœud d’origine à tous les autres nœuds. Pour cette raison, les nœuds à travers le réseau ne peuvent pas déterminer l’ordre exact des transactions, savoir si l’une est arrivée avant ou après une autre, car ils n’ont que leurs propres perspectives subjectives.

Parce que l’ordre des transactions est important, les réseaux blockchain utilisent des méthodes spécialisées appelées «algorithmes de consensus” pour garantir que les nœuds restent synchronisés et traitent les séquences de transactions dans le même ordre. Bien que les nœuds ne puissent pas déterminer l’ordre des transactions globalement, les mécanismes de consensus permettent à tous les nœuds de s’accorder sur la même séquence, permettant au réseau de fonctionner comme un seul ordinateur cohérent.

Au-delà de la couche de consensus, il y a aussi la couche d’exécution qui existe dans chaque blockchain. La couche d’exécution est formée par les transactions que les utilisateurs veulent exécuter.

Une fois que les transactions ont été correctement ordonnées par consensus, chaque transaction doit être appliquée à l’état actuel au niveau de l’exécution. Si vous vous demandez, “Quel est l’état?”, vous avez probablement vu des blockchains comparées à des bases de données, ou plus précisément à la base de données d’une banque, car les blockchains, tout comme les banques, tiennent un registre des soldes de tout le monde.

Si vous avez 100 $ dans l’état que nous appelons “S” et que vous voulez envoyer 10 $ à quelqu’un d’autre, votre solde dans l’état suivant, “S+1”, sera de 90 $. Ce processus d’application des transactions pour passer d’un état à un autre est ce que nous appelons une STF (Fonction de Transition d’État).

Dans Bitcoin, le STF se limite principalement aux modifications de solde, ce qui le rend relativement simple. Cependant, contrairement à Bitcoin, le STF d’Ethereum est beaucoup plus complexe car Ethereum est une blockchain entièrement programmable avec une couche d’exécution capable d’exécuter du code.

Dans une blockchain, il y a trois composants fondamentaux que vous devez — ou êtes en mesure de — vérifier :

1. État : Vous voudrez peut-être lire une pièce de données sur la blockchain, mais vous ne disposez pas d’accès à l’état car vous ne l’exécutez pas.nœud complet. Par conséquent, vous demandez les données via un fournisseur RPC (Remote Procedure Call) tel que Alchemy ou Infura. Cependant, vous devez vérifier que les données n’ont pas été altérées par le fournisseur RPC.
2. Exécution : Comme mentionné précédemment, les blockchains utilisent un STF. Vous devez vérifier que la transition d’état a été exécutée correctement, non pas sur une base par transaction mais sur une base par bloc.
3. Consensus : Des entités tierces, comme les RPC, peuvent vous fournir des blocs valides qui n’ont pas encore été inclus dans la blockchain. Ainsi, vous devez vérifier que ces blocs ont été acceptés par consensus et ajoutés à la blockchain.

Si cela vous semble confus ou flou, ne vous inquiétez pas. Nous passerons en revue chacun de ces aspects en détail. Commençons par la vérification de l’état de la blockchain !

Comment vérifier l’état de la blockchain?

L’”état” d’Ethereum fait référence à l’ensemble des données stockées dans la blockchain à un moment donné. Cela comprend les soldes des comptes (comptes de contrat et comptes détenus à l’extérieur ou EOAs), le code des contrats intelligents, le stockage des contrats, et plus encore. Ethereum est une machine basée sur l’état car les transactions traitées dans la machine virtuelle Ethereum (EVM) modifient l’état précédent et produisent un nouvel état.

Chaque bloc Ethereum contient une valeur qui résume l’état actuel du réseau après ce bloc : la racine d’état. Cette valeur est une représentation compacte de l’état Ethereum entier, composée d’un hachage de 64 caractères.

À mesure que chaque nouvelle transaction modifie l’état, l’état racine enregistré dans le bloc suivant est mis à jour en conséquence. Pour calculer cette valeur, les validateurs d’Ethereum utilisent une combinaison de la fonction de hachage Keccak et d’une structure de données appelée le Arbre de Merkleorganiser et résumer différentes parties de l’état.

Les fonctions de hachage sont des fonctions à sens unique qui transforment une entrée en une sortie de longueur fixe. Dans Ethereum, des fonctions de hachage comme Keccaksont utilisées pour générer des résumés de données, servant de sorte d’empreinte digitale pour l’entrée. Les fonctions de hachage ont quatre propriétés fondamentales:

1. Déterminisme: La même entrée produira toujours la même sortie.
2. Longueur de sortie fixe: quelle que soit la longueur de l’entrée, la longueur de sortie est toujours fixe.
3. Propriété à sens unique : Il est pratiquement impossible de dériver l’entrée d’origine à partir de la sortie.
4. Unicité : Même un petit changement dans l’entrée produit une sortie complètement différente. Ainsi, une entrée spécifique est associée à une sortie pratiquement unique.

Grâce à ces propriétés, les validateurs Ethereum peuvent effectuer la STF (Fonction de Transition d’État) pour chaque bloc - exécutant toutes les transactions du bloc et les appliquant à l’état - puis vérifier si l’état indiqué dans le bloc correspond à l’état obtenu après la STF. Ce processus garantit que le proposeur du bloc a agi honnêtement, ce qui en fait l’une des principales responsabilités des validateurs.

Cependant, les validateurs d’Ethereum ne hachent pas l’état entier directement pour trouver son résumé. En raison de la nature à sens unique des fonctions de hachage, le hachage direct de l’état éliminerait la vérifiabilité, car la seule façon de reproduire le hachage serait de posséder l’état entier.

Étant donné que l’état d’Ethereum est de plusieurs téraoctets, il est impraticable de stocker l’intégralité de l’état sur des appareils quotidiens tels que les téléphones ou les ordinateurs personnels. Pour cette raison, Ethereum utilise une structure d’arbre de Merkle pour calculer la racine de l’état, préservant ainsi autant que possible la vérifiabilité de l’état.

Un Arbre de Merkleest une structure de données cryptographique utilisée pour vérifier de manière sécurisée et efficace l’intégrité et la correction des données. Les arbres de Merkle sont construits à partir de fonctions de hachage et organisent les hachages d’un ensemble de données de manière hiérarchique, ce qui permet de vérifier l’intégrité et la correction de ces données. Cette structure d’arbre se compose de trois types de nœuds:

1. Nœuds feuilles : Ces nœuds contiennent les hachages des données individuelles et sont situés au niveau inférieur de l’arbre. Chaque nœud feuille représente le hachage d’une pièce de données spécifique dans l’arbre de Merkle.
2. Noeuds de branche: Ces noeuds contiennent les hachages combinés de leurs noeuds enfants. Par exemple, dans un arbre de Merkle binaire (où N=2), les hachages de deux noeuds enfants sont concaténés et hachés à nouveau pour produire le hachage d’un noeud de branche à un niveau supérieur.
3. Nœud racine: Le nœud racine se trouve au niveau le plus élevé de l’arbre de Merkle et représente le résumé cryptographique de l’ensemble de l’arbre. Ce nœud est utilisé pour vérifier l’intégrité et la correction de l’ensemble des données dans l’arbre.

Si vous vous demandez comment construire un tel arbre, cela ne nécessite que deux étapes simples :

• Création des nœuds feuilles : Chaque morceau de données est traité à travers une fonction de hachage, et les hachages résultants forment les nœuds feuilles. Ces nœuds résident au niveau le plus bas de l’arbre et représentent le résumé cryptographique des données.

• Combiner et hacher: Les hachages des nœuds feuilles sont regroupés (par exemple, par paires) et combinés, puis hachés. Ce processus crée des nœuds de branche au niveau suivant. Le même processus est répété pour les nœuds de branche jusqu’à ce qu’il ne reste qu’un seul hachage.

Le hachage final obtenu en haut de l’arbre est appelé la racine de Merkle. La racine de Merkle représente le résumé cryptographique de l’arbre entier et permet la vérification sécurisée de l’intégrité des données.

Comment utilisons-nous les racines de Merkle pour vérifier l’état d’Ethereum?

Les preuves de Merkle permettent au Vérificateur de valider efficacement des éléments de données spécifiques en fournissant une série de valeurs de hachage qui créent un chemin depuis les données ciblées (un nœud feuille) jusqu’à la Racine de Merkle stockée dans l’en-tête de bloc. Cette chaîne de hachages intermédiaires permet au Vérificateur de confirmer l’authenticité des données sans avoir besoin de hacher l’intégralité de l’état.

À partir du point de données spécifique, le Vérificateur le combine avec chaque hachage “frère” fourni dans la Preuve de Merkle et les hache étape par étape jusqu’à l’arbre. Ce processus continue jusqu’à ce qu’un seul hachage soit produit. Si ce hachage calculé correspond à la Racine de Merkle stockée, les données sont considérées comme valides; sinon, le Vérificateur peut déterminer que les données ne correspondent pas à l’état revendiqué.

Exemple: Vérification d’un point de données avec une preuve de Merkle

Supposons que nous ayons reçu les données n ° 4 d’un RPC et que nous voulions vérifier son authenticité à l’aide d’une preuve de Merkle. Pour ce faire, le RPC fournirait un ensemble de valeurs de hachage le long du chemin nécessaire pour atteindre la racine de Merkle. Pour les données 4, ces hachages frères et sœurs comprendraient le hachage n ° 3, le hachage n ° 12 et le hachage n ° 5678.

1. Commencez par les données 4 : d’abord, nous hachons les données n°4 pour obtenir le hachage n°4.
2. Combinez avec les frères et sœurs: nous combinons ensuite le hachage n°4 avec le hachage n°3 (son frère ou sa sœur au niveau des feuilles) et les hachons ensemble pour produire le hachage n°34.
3. Remontez l’arbre: Ensuite, nous prenons le Hash #34 et le combinons avec le Hash #12 (son frère dans le niveau supérieur) et les hashons pour obtenir le Hash #1234.
4. Étape finale: Enfin, nous combinons le Hash #1234 avec le Hash #5678 (le dernier sibling fourni) et les hachons ensemble. Le hash résultant devrait correspondre à la racine de Merkle (Hash #12345678) stockée dans l’en-tête du bloc.

Si la racine de Merkle calculée correspond à la racine d’état dans le bloc, nous confirmons que la Donnée n°4 est effectivement valide dans cet état. Sinon, nous savons que les données n’appartiennent pas à l’état revendiqué, ce qui indique une altération potentielle. Comme vous pouvez le voir, sans fournir les hachages de toutes les données ou exiger que le Vérificateur reconstruise entièrement l’ensemble de l’Arbre de Merkle à partir de zéro, le Prouveur peut prouver que la Donnée n°4 existe dans l’état et n’a pas été altérée au cours de son parcours, en utilisant seulement trois hachages. C’est la raison principale pour laquelle les Preuves de Merkle sont considérées comme efficaces.

Bien que les arbres de Merkle soient sans aucun doute efficaces pour fournir une vérification sécurisée et efficace des données dans de grands systèmes blockchain comme Ethereum, sont-ils vraiment suffisamment efficaces? Pour répondre à cela, nous devons analyser comment les performances et la taille des arbres de Merkle impactent la relation entre le prouveur et le vérificateur.

Deux facteurs clés affectant les performances de l’arbre de Merkle: ⌛

1. Facteur de branchement : Le nombre de nœuds enfants par branche.
2. Taille totale des données: La taille de l’ensemble de données représenté dans l’arbre.

L’effet du facteur de branchement:

Utilisons un exemple pour mieux comprendre son impact. Le facteur de branchement détermine combien de branches émergent de chaque nœud dans l’arbre.

• Petit facteur de branchement (par exemple, arbre de Merkle binaire) :
  Si un arbre de Merkle binaire (facteur de branchement de 2) est utilisé, la taille de la preuve est très petite, ce qui rend le processus de vérification plus efficace pour le vérificateur. Avec seulement deux branches à chaque nœud, le vérificateur n’a besoin de traiter qu’un hachage de frère par niveau. Cela accélère la vérification et réduit la charge de calcul. Cependant, le facteur de branchement réduit augmente la hauteur de l’arbre, ce qui nécessite plus d’opérations de hachage lors de la construction de l’arbre, ce qui peut être contraignant pour les validateurs.
• Facteur de branchement plus important (par exemple, 4) :
  Un facteur de ramification plus élevé (par exemple, 4) réduit la hauteur de l’arbre, créant une structure plus courte et plus large. Cela permet aux nœuds complets de construire l’arbre plus rapidement car moins d’opérations de hachage sont nécessaires. Cependant, pour le vérificateur, cela augmente le nombre de hachages frères qu’ils doivent traiter à chaque niveau, ce qui entraîne une taille de preuve plus grande. Plus de hachages par étape de vérification signifient également des coûts de calcul et de bande passante plus élevés pour le vérificateur, ce qui déplace efficacement la charge des validateurs vers les vérificateurs.

L’effet de la taille totale des données :

A mesure que la blockchain Ethereum se développe, avec chaque nouvelle transaction, contrat ou interaction utilisateur ajoutant à l’ensemble de données, l’arbre de Merkle doit également se développer. Cette croissance augmente non seulement la taille de l’arbre, mais impacte également la taille de la preuve et le temps de vérification.

• Les nœuds complets doivent traiter et mettre à jour régulièrement l’ensemble de données croissant pour maintenir l’Arbre de Merkle.
• Les vérificateurs, à leur tour, doivent valider des preuves de plus en plus longues et complexes à mesure que l’ensemble de données se développe, ce qui nécessite un temps de traitement et une bande passante supplémentaires. \
  Cette taille croissante des données augmente la demande à la fois sur les nœuds complets et les vérificateurs, rendant plus difficile la mise à l’échelle efficace du réseau.

En résumé, bien que les arbres de Merkle offrent un certain degré d’efficacité, ils ne sont pas une solution optimale pour l’ensemble de données en croissance continue d’Ethereum. Pour cette raison, pendant la phase The Verge, Ethereum vise à remplacer les arbres de Merkle par une structure plus efficace connue sous le nom de Arbres VerkleLes arbres Verkle ont le potentiel de fournir des tailles de preuve plus petites tout en maintenant le même niveau de sécurité, rendant le processus de vérification plus durable et évolutif pour les Provers et les Vérificateurs.

Chapitre 2: Révolutionner la vérifiabilité dans Ethereum - The Verge

Le Verge a été développé comme une étape importante dans la feuille de route d’Ethereum visant à améliorer la vérifiabilité, renforcer la structure décentralisée de la blockchain et améliorer la sécurité du réseau. L’un des objectifs principaux du réseau Ethereum est de permettre à n’importe qui d’exécuter facilement un validateur pour vérifier la chaîne, créant ainsi une structure où la participation est ouverte à tous sans centralisation. L’accessibilité de ce processus de vérification est l’une des caractéristiques clés qui distingue les blockchains des systèmes centralisés. Alors que les systèmes centralisés n’offrent pas de capacités de vérification, la justesse d’une blockchain est entièrement entre les mains de ses utilisateurs. Cependant, pour maintenir cette assurance, l’exécution d’un validateur doit être accessible à tous - un défi qui, dans le système actuel, est limité en raison des exigences de stockage et de calcul.

Depuis la transition vers un modèle de consensus Proof-of-Stake avec The Merge, les validateurs d’Ethereum ont eu deux responsabilités principales :

1. Garantir le consensus : soutenir le bon fonctionnement des protocoles de consensus probabilistes et déterministes et appliquer l’algorithme de choix de la fourchette.
2. Vérification de l’exactitude du bloc : Après l’exécution des transactions dans un bloc, vérification que la racine de l’arbre d’état résultant correspond à la racine d’état déclarée par le proposant.

Pour remplir la deuxième responsabilité, les validateurs doivent avoir accès à l’état avant le bloc. Cela leur permet d’exécuter les transactions du bloc et de déduire l’état ultérieur. Cependant, cette exigence impose un fardeau considérable aux validateurs, car ils doivent gérer des besoins de stockage importants. Bien que Ethereum soit conçu pour être réalisable et que les coûts de stockage diminuent dans le monde entier, le problème est moins lié au coût et plus à la dépendance à un matériel spécialisé pour les validateurs. The Verge vise à surmonter ce défi en créant une infrastructure où la vérification complète peut être effectuée même sur des appareils avec un espace de stockage limité, tels que les téléphones mobiles, les portefeuilles de navigateur et même les montres connectées, permettant aux validateurs de fonctionner sur ces appareils.

Première étape de la vérifiabilité : État

La transition vers les arbres Verkle est une partie essentielle de ce processus. Initialement, The Verge s’est concentré sur le remplacement des structures d’arbres de Merkle d’Ethereum par des arbres Verkle. La raison principale d’adopter les arbres Verkle est que les arbres de Merkle posent un obstacle important à la vérifiabilité d’Ethereum. Alors que les arbres de Merkle et leurs preuves peuvent fonctionner efficacement dans des scénarios normaux, leurs performances se dégradent considérablement dans des scénarios de pire cas.

Selon les calculs de Vitalik, la taille de preuve moyenne est d’environ 4 Ko, ce qui semble gérable. Cependant, dans les pires scénarios, la taille de la preuve peut gonfler à 330 Mo. Oui, vous avez bien lu - 330 Mo.

L’extrême inefficacité des arbres de Merkle d’Ethereum dans les pires scénarios découle de deux raisons principales :

1. Utilisation des arbres hexaraires : Ethereum utilise actuellement des arbres de Merkle avec un facteur de branchement de 16. Cela signifie que la vérification d’un seul nœud nécessite de fournir les 15 hachages restants dans la branche. Étant donnée la taille de l’état d’Ethereum et le nombre de branches, cela crée un fardeau substantiel dans les pires scénarios.

1. Non-Merkelization du code : Au lieu d’incorporer le code du contrat dans la structure de l’arbre, Ethereum se contente de hacher le code et utilise la valeur résultante comme nœud. Étant donné que la taille maximale d’un contrat est de 24 Ko, cette approche impose une charge importante pour parvenir à une vérifiabilité totale.

La taille de l’épreuve est directement proportionnelle au facteur de branchement. La réduction du facteur de branchement diminue la taille de l’épreuve. Pour résoudre ces problèmes et améliorer les pires scénarios, Ethereum pourrait passer des arbres hexarys aux arbres de Merkle binaires et commencer à merkliser les codes de contrat. Si le facteur de branchement dans Ethereum est réduit de 16 à 2 et que les codes de contrat sont également merklisés, la taille maximale de la preuve pourrait être réduite à 10 Mo. Bien qu’il s’agisse d’une amélioration significative, il est important de noter que ce coût s’applique à la vérification d’un seul élément de données. Même une simple transaction accédant à plusieurs éléments de données nécessiterait des preuves plus volumineuses. Compte tenu du nombre de transactions par bloc et de l’état de croissance continue d’Ethereum, cette solution, bien que meilleure, n’est toujours pas tout à fait réalisable.

Pour ces raisons, la communauté Ethereum a proposé deux solutions distinctes pour résoudre le problème :

1. Verkle Trees
2. Preuves STARK + Arbres binaires de Merkle

Verkle Trees & Vector Commitments

Les arbres Verkle, comme leur nom l’indique, sont des structures arborescentes similaires aux arbres Merkle. Cependant, la différence la plus significative réside dans l’efficacité qu’ils offrent lors des processus de vérification. Dans les arbres Merkle, si une branche contient 16 morceaux de données et que nous voulons en vérifier un seul, une chaîne de hachage couvrant les 15 autres morceaux doit également être fournie. Cela augmente considérablement la charge de calcul de la vérification et entraîne des tailles de preuve importantes.

En revanche, les arbres Verkle utilisent une structure spécialisée connue sous le nom de “Engagements de vecteurs basés sur des courbes elliptiques”, plus précisément un Engagement de vecteur basé sur un Argument de produit interne (IPA). Un vecteur est essentiellement une liste d’éléments de données organisés dans une séquence spécifique. L’état d’Ethereum peut être considéré comme un vecteur : une structure où de nombreux éléments de données sont stockés dans un ordre particulier, chaque élément étant crucial. Cet état comprend divers composants de données tels que des adresses, des codes de contrat et des informations de stockage, où l’ordre de ces éléments joue un rôle critique dans l’accès et la vérification.

Les engagements vectoriels sont des méthodes cryptographiques utilisées pour prouver et vérifier les éléments de données au sein d’un ensemble de données. Ces méthodes permettent de vérifier à la fois l’existence et l’ordre de chaque élément dans un ensemble de données simultanément. Par exemple, les preuves de Merkle, utilisées dans les arbres de Merkle, peuvent également être considérées comme une forme d’engagement vectoriel. Alors que les arbres de Merkle nécessitent toutes les chaînes de hachage pertinentes pour vérifier un élément, la structure prouve intrinsèquement que tous les éléments d’un vecteur sont connectés dans une séquence spécifique.

Contrairement aux arbres Merkle, les arbres Verkle utilisent des engagements vectoriels à base de courbes elliptiques qui offrent deux avantages clés :

• Les engagements de vecteurs basés sur des courbes elliptiques éliminent le besoin de détails sur les éléments autres que les données vérifiées. Dans les arbres de Merkle avec un facteur de branchement de 16, la vérification d’une seule branche nécessite de fournir les 15 autres hachages. Étant donnée la taille considérable de l’état d’Ethereum, qui implique de nombreuses branches, cela crée une inefficacité significative. Les engagements de vecteurs basés sur des courbes elliptiques, en revanche, éliminent cette complexité, permettant une vérification avec moins de données et d’efforts de calcul.
• Grâce à des preuves multiples, les preuves générées par les engagements vectoriels basés sur les courbes elliptiques peuvent être compressées en une seule preuve de taille constante. L’état d’Ethereum est non seulement volumineux mais également en croissance continue, ce qui signifie que le nombre de branches nécessitant une vérification pour accéder à la racine de Merkle augmente avec le temps. Cependant, avec les arbres Verkle, nous pouvons “compresser” les preuves pour chaque branche en une seule preuve de taille constante en utilisant la méthode détaillée dans L’article de Dankrad Feist. Cela permet aux Vérificateurs de valider l’ensemble de l’arbre avec une petite preuve au lieu de vérifier chaque branche individuellement. Cela signifie également que les arbres Verkle ne sont pas affectés par la croissance de l’état d’Ethereum.

Ces caractéristiques des engagements vectoriels basés sur les courbes elliptiques réduisent significativement la quantité de données nécessaires pour la vérification, permettant aux arbres Verkle de produire de petites preuves de taille constante même dans les pires cas. Cela minimise le surdébit de données et les temps de vérification, améliorant ainsi l’efficacité des réseaux à grande échelle comme Ethereum. Par conséquent, l’utilisation d’engagements vectoriels basés sur les courbes elliptiques dans les arbres Verkle permet une gestion plus facile et plus efficace de l’état expansif d’Ethereum.

Comme toutes les innovations, les arbres Verkle ont leurs limites. L’un de leurs principaux inconvénients est qu’ils reposent sur la cryptographie à courbes elliptiques, qui est vulnérable aux ordinateurs quantiques. Les ordinateurs quantiques possèdent une puissance de calcul bien plus grande que les méthodes classiques, ce qui constitue une menace significative pour les protocoles cryptographiques basés sur les courbes elliptiques. Les algorithmes quantiques pourraient potentiellement casser ou affaiblir ces systèmes cryptographiques, soulevant des inquiétudes quant à la sécurité à long terme des arbres Verkle.

Pour cette raison, bien que les arbres Verkle offrent une solution prometteuse vers la non-étatique, ils ne sont pas la solution ultime. Cependant, des figures comme Dankrad Feist ont souligné que, bien qu’une considération prudente soit nécessaire lors de l’intégration de la cryptographie résistante à la cryptographie quantique dans Ethereum, il convient de noter que les engagements KZG actuellement utilisés pour les blobs dans Ethereum ne sont pas non plus résistants à la cryptographie quantique. Ainsi, les arbres Verkle peuvent servir de solution intérimaire, offrant au réseau un temps supplémentaire pour développer des alternatives plus robustes.

Preuves STARK + Arbres binaires de Merkle

Les arbres Verkle offrent des tailles de preuve plus petites et des processus de vérification plus efficaces par rapport aux arbres Merkle, ce qui facilite la gestion de l’état toujours croissant d’Ethereum. Grâce aux engagements vectoriels basés sur les courbes elliptiques, des preuves à grande échelle peuvent être générées avec beaucoup moins de données. Cependant, malgré leurs avantages impressionnants, la vulnérabilité des arbres Verkle aux ordinateurs quantiques en fait une solution temporaire. Alors que la communauté Ethereum considère les arbres Verkle comme un outil à court terme pour gagner du temps, l’accent à long terme est mis sur la transition vers des solutions résistantes aux ordinateurs quantiques. C’est là que les preuves STARK et les arbres Merkle binaires présentent une alternative solide pour construire une infrastructure de vérifiabilité plus robuste pour l’avenir.

Dans le processus de vérification d’état d’Ethereum, le facteur de ramification des arbres de Merkle peut être réduit (de 16 à 2) en utilisant des arbres de Merkle binaires. Ce changement est une étape critique pour réduire les tailles de preuve et rendre les processus de vérification plus efficaces. Cependant, même dans le pire des cas, les tailles de preuve peuvent atteindre 10 Mo, ce qui est considérable. C’est là que les preuves STARK entrent en jeu, compressant ces grandes preuves de Merkle binaires à seulement 100-300 ko.

Cette optimisation est particulièrement vitale lors de la prise en compte des contraintes liées à l’exploitation des validateurs sur des clients légers ou des appareils avec un matériel limité, surtout si l’on considère que les vitesses moyennes de téléchargement et de téléversement mobiles mondiaux sont d’environ 7,625 Mo/s et 1,5 Mo/s, respectivement. Les utilisateurs peuvent vérifier les transactions avec de petites preuves portables sans avoir besoin d’accéder à l’état complet, et les validateurs peuvent effectuer des tâches de vérification de bloc sans stocker l’état entier.

Cette approche à double bénéfice réduit à la fois la bande passante et les exigences de stockage pour les validateurs, tout en accélérant la vérification, trois améliorations clés qui soutiennent directement la vision d’Ethereum en matière de scalabilité.

Principaux défis pour les preuves STARK :

1. Charge computationnelle élevée pour les prouveurs: \
   Le processus de génération de preuves STARK est intensif en termes de calcul, en particulier du côté du prouveur, ce qui peut augmenter les coûts opérationnels.
2. Inefficacité dans les preuves de petites données:

Bien que les preuves STARK excellent dans la manipulation de grands ensembles de données, elles sont moins efficaces lorsqu’il s’agit de prouver de petites quantités de données, ce qui peut entraver leur application dans certains scénarios. Lorsqu’il s’agit de programmes impliquant des étapes ou des ensembles de données plus petits, la taille de preuve relativement grande des STARKs peut les rendre moins pratiques ou rentables.

La sécurité quantique a un coût : charge de calcul côté prouveur

La preuve de Merkle d’un bloc peut inclure environ 330 000 hachages, et dans les pires cas, ce nombre peut atteindre 660 000. Dans de tels cas, une preuve STARK aurait besoin de traiter environ 200 000 hachages par seconde.

C’est là que les fonctions de hachage compatibles avec zk, comme Poseidon, entrent en jeu, spécifiquement optimisées pour les preuves STARK afin de réduire cette charge. Poseidon est conçu pour fonctionner de manière plus transparente avec les preuves ZK par rapport aux algorithmes de hachage traditionnels tels que SHA256 et Keccak. La raison principale de cette compatibilité réside dans la manière dont les algorithmes de hachage traditionnels fonctionnent: ils traitent les entrées sous forme de données binaires (0s et 1s). D’autre part, les preuves ZK travaillent avec des corps premiers, des structures mathématiques fondamentalement différentes. Cette situation est analogue à celle des ordinateurs qui fonctionnent en binaire tandis que les humains utilisent un système décimal dans la vie quotidienne. La traduction de données basées sur des bits en formats compatibles avec ZK implique une surcharge computationnelle significative. Poseidon résout ce problème en opérant nativement dans des corps premiers, accélérant ainsi considérablement son intégration avec les preuves ZK.

Cependant, étant donné que Poseidon est une fonction de hachage relativement nouvelle, il nécessite une analyse de sécurité plus approfondie pour établir le même niveau de confiance que les fonctions de hachage traditionnelles telles que SHA256 et Keccak. À cette fin, des initiatives comme le Initiative d’analyse cryptographique de Poséidon, lancé par la Fondation Ethereum, invite des experts à tester et analyser rigoureusement la sécurité de Poseidon, en veillant à ce qu’elle puisse résister à un examen adversarial et devenir une norme robuste pour les applications cryptographiques. En revanche, des fonctions plus anciennes comme SHA256 et Keccak ont déjà été largement testées et ont un bilan de sécurité avéré mais ne sont pas ZK-friendly, ce qui entraîne des baisses de performance lorsqu’elles sont utilisées avec des preuves STARK.

Par exemple, les preuves STARK utilisant ces fonctions de hachage traditionnelles ne peuvent actuellement traiter que 10 000 à 30 000 hachages. Heureusement, les avancées dans la technologie STARK suggèrent que ce débit pourrait bientôt atteindre 100 000 à 200 000 hachages, améliorant considérablement leur efficacité.

L’inefficacité des STARKs dans la preuve des petites données

Alors que les preuves STARK excellent en termes de scalabilité et de transparence pour les grands ensembles de données, elles présentent des limites lorsqu’il s’agit de travailler avec de petits éléments de données nombreux. Dans ces scénarios, les données à prouver sont souvent de petite taille, mais le besoin de multiples preuves reste inchangé. Des exemples incluent :

1. Validation de transaction Post-AA : \
   Avec l’abstraction de compte (AA), les portefeuilles peuvent pointer vers le code du contrat, en contournant ou en personnalisant des étapes telles que la vérification du nonce et de la signature, qui sont actuellement obligatoires dans Ethereum. Cependant, cette flexibilité en matière de validation nécessite la vérification du code du contrat ou d’autres données associées dans l’état pour prouver la validité de la transaction.
2. Appels RPC du client léger : \
   Les clients légers interrogent les données d’état du réseau (par exemple, lors d’une demande eth_call) sans exécuter un nœud complet. Pour garantir la justesse de cet état, les preuves doivent prendre en charge les données interrogées et confirmer qu’elles correspondent à l’état actuel du réseau.
3. Listes d’inclusion: \
   Les petits validateurs peuvent utiliser des mécanismes de liste d’inclusion pour garantir que les transactions sont incluses dans le prochain bloc, limitant l’influence des puissants producteurs de blocs. Cependant, valider l’inclusion de ces transactions nécessite de vérifier leur exactitude.

Dans de tels cas d’utilisation, les preuves STARK offrent peu d’avantages. Les STARK, mettant l’accent sur la scalabilité (comme le souligne le “S” dans leur nom), sont performants pour les ensembles de données volumineux mais rencontrent des difficultés dans les scénarios de données réduites. En revanche, les SNARK, conçus pour leur concision (comme le souligne le “S” dans leur nom), se concentrent sur la minimisation de la taille de la preuve, offrant des avantages clairs dans les environnements avec des contraintes de bande passante ou de stockage.

Les preuves STARK ont généralement une taille de 40 à 50 Ko, soit environ 175 fois plus grande que les preuves SNARK, qui ne font que 288 octets. Cette différence de taille augmente à la fois le temps de vérification et les coûts de réseau. La principale raison de la plus grande taille des preuves STARK est leur dépendance à la transparence et aux engagements de polynômes pour assurer la scalabilité, ce qui introduit des coûts de performance dans les scénarios de petites données. Dans de tels cas, des méthodes plus rapides et plus efficaces en termes d’espace, comme les preuves de Merkle, pourraient être plus pratiques. Les preuves de Merkle offrent des coûts de calcul faibles et des mises à jour rapides, ce qui les rend adaptées à ces situations.

Néanmoins, les preuves STARK restent cruciales pour l’avenir sans état d’Ethereum en raison de leur sécurité quantique.

Comme résumé dans le tableau, Ethereum a quatre chemins potentiels à choisir:

• Arbres Verkle
  1. Les arbres Verkle ont reçu un large soutien de la communauté Ethereum, avec des réunions bihebdomadaires organisées pour faciliter leur développement. Grâce à ce travail et à ces tests constants, les arbres Verkle se distinguent comme la solution la plus mature et la mieux étudiée parmi les alternatives actuelles. De plus, leurs propriétés homomorphes additives éliminent le besoin de recomputer chaque branche pour mettre à jour la racine de l’état, contrairement aux arbres Merkle, ce qui fait des arbres Verkle une option plus efficace. Par rapport à d’autres solutions, les arbres Verkle mettent l’accent sur la simplicité, en adhérant à des principes d’ingénierie tels que « gardez-le simple » ou « le simple est le meilleur ». Cette simplicité facilite à la fois l’intégration dans Ethereum et l’analyse de sécurité.
  2. Cependant, les arbres Verkle ne sont pas sécurisés quantiquement, ce qui les empêche de constituer une solution à long terme. S’ils sont intégrés dans Ethereum, cette technologie devrait probablement être remplacée à l’avenir lorsque des solutions résistantes à la cryptographie quantique seront nécessaires. Même Vitalik considère les arbres Verkle comme une mesure temporaire pour gagner du temps pour que les STARKs et d’autres technologies mûrissent. De plus, les engagements vectoriels basés sur les courbes elliptiques utilisés dans les arbres Verkle imposent une charge computationnelle plus élevée par rapport aux simples fonctions de hachage. Les approches basées sur les fonctions de hachage peuvent offrir des temps de synchronisation plus rapides pour les nœuds complets. En outre, la dépendance à l’égard de nombreuses opérations de 256 bits rend les arbres Verkle plus difficiles à prouver à l’aide de SNARKs au sein des systèmes de preuve modernes, compliquant les efforts futurs pour réduire la taille des preuves.

Néanmoins, il est important de noter que les arbres Verkle, en raison de leur non-dépendance vis-à-vis du hachage, sont significativement plus prouvables que les arbres Merkle.

• STARKs + Fonctions de hachage conservatrices
  1. La combinaison des STARKs avec des fonctions de hachage conservatrices bien établies telles que SHA256 ou BLAKE fournit une solution robuste qui renforce l’infrastructure de sécurité d’Ethereum. Ces fonctions de hachage ont été largement utilisées et largement testées dans les domaines académiques et pratiques. De plus, leur résistance quantique renforce la résilience d’Ethereum contre les menaces futures posées par les ordinateurs quantiques. Pour les scénarios critiques en matière de sécurité, cette combinaison offre une base fiable.
  2. Cependant, l’utilisation de fonctions de hachage conservatrices dans les systèmes STARK introduit des limitations de performance importantes. Les exigences computationnelles de ces fonctions de hachage entraînent une latence élevée du prouveur, la génération de preuve prenant plus de 10 secondes. Il s’agit d’un inconvénient majeur, en particulier dans des scénarios tels que la validation de blocs exigeant une faible latence. Bien que des efforts comme les propositions de gaz multidimensionnelles tentent d’aligner la latence dans le pire des cas et dans le cas moyen, les résultats sont limités. De plus, bien que les approches basées sur le hachage puissent faciliter des temps de synchronisation plus rapides, leur efficacité pourrait ne pas correspondre aux objectifs de scalabilité plus larges des STARKs. Les longs temps de calcul des fonctions de hachage traditionnelles réduisent l’efficacité pratique et limitent leur applicabilité.
• STARKs + Fonctions de hachage relativement nouvelles
  1. Les STARK associés à de nouvelles fonctions de hachage compatibles avec les STARK de nouvelle génération (par exemple, Poseidon) améliorent considérablement les performances de cette technologie. Ces fonctions de hachage sont conçues pour s’intégrer parfaitement aux systèmes STARK et réduire considérablement la latence du prouveur. Contrairement aux fonctions de hachage traditionnelles, elles permettent de générer une preuve en aussi peu que 1 – 2 secondes. Leur efficacité et leur faible surcharge computationnelle améliorent le potentiel de scalabilité des STARK, les rendant très efficaces pour traiter de grands ensembles de données. Cette capacité les rend particulièrement attrayants pour les applications exigeant des performances élevées.
  2. Cependant, la nouveauté relative de ces fonctions de hachage nécessite une analyse de sécurité approfondie et des tests. Le manque de tests complets comporte des risques lorsqu’on envisage leur implémentation dans des écosystèmes critiques comme Ethereum. De plus, étant donné que ces fonctions de hachage ne sont pas encore largement adoptées, les processus de test et de validation nécessaires pourraient retarder les objectifs de vérifiabilité d’Ethereum. Le temps nécessaire pour garantir pleinement leur sécurité pourrait rendre cette option moins attrayante à court terme, ce qui pourrait reporter les ambitions de scalabilité et de vérifiabilité d’Ethereum.
• Arbres de Merkle basés sur le réseau en treillis
  1. Les arbres de Merkle basés sur les treillis offrent une solution avant-gardiste qui combine la sécurité quantique avec l’efficacité de mise à jour des arbres Verkle. Ces structures traitent des faiblesses à la fois des arbres Verkle et des STARKs et sont considérées comme une option prometteuse à long terme. Grâce à leur conception basée sur les treillis, ils offrent une résistance solide aux menaces de l’informatique quantique, en accord avec l’accent d’Ethereum sur la protection future de son écosystème. De plus, en conservant les avantages de mise à jour des arbres Verkle, ils visent à offrir une sécurité accrue sans compromettre l’efficacité.
  2. Cependant, la recherche sur les arbres de Merkle basés sur des réseaux en treillis en est encore à ses débuts et est largement théorique. Cela crée une incertitude significative quant à leur mise en œuvre pratique et à leurs performances. Intégrer une telle solution dans Ethereum nécessiterait des recherches et développements approfondis, ainsi qu’une validation rigoureuse de ses avantages potentiels. Ces incertitudes et complexités infrastructurelles rendent peu probable l’utilisation des arbres de Merkle basés sur des réseaux en treillis pour Ethereum dans un proche avenir, retardant potentiellement les progrès vers les objectifs de vérifiabilité du réseau.

Qu’en est-il de l’exécution : Preuves de validité de l’exécution de l’EVM

Tout ce que nous avons discuté jusqu’à présent tourne autour de l’élimination du besoin pour les validateurs de stocker l’état précédent, qu’ils utilisent pour passer d’un état à l’autre. L’objectif est de créer un environnement plus décentralisé où les validateurs peuvent accomplir leurs tâches sans conserver des téraoctets de données d’état. Même avec les solutions que nous avons mentionnées, les validateurs n’auraient pas besoin de stocker l’intégralité de l’état, car ils recevraient toutes les données requises pour l’exécution par le biais de témoins inclus avec le bloc. Cependant, pour passer à l’état suivant et ainsi vérifier la stateRoot sur le dessus du bloc, les validateurs doivent toujours exécuter le STF eux-mêmes. Cette exigence pose à son tour un autre défi à la nature sans permission et à la décentralisation d’Ethereum.

À l’origine, The Verge était conçu comme une étape qui se concentrait uniquement sur la transition de l’arbre d’état d’Ethereum des arbres de Merkle aux arbres de Verkle afin d’améliorer la vérifiabilité de l’état. Au fil du temps, cependant, il est devenu une initiative plus vaste visant à améliorer la vérifiabilité des transitions d’état et du consensus. Dans un monde où le trio État, Exécution et Consensus est entièrement vérifiable, les validateurs Ethereum pourraient fonctionner sur pratiquement n’importe quel appareil avec une connexion Internet qui peut être catégorisé comme un client léger. Cela rapprocherait Ethereum de la réalisation de sa vision de la « vraie décentralisation ».

Quelle est la définition du problème?

Comme mentionné précédemment, les validateurs exécutent une fonction appelée STF (State Transition Function) toutes les 12 secondes. Cette fonction prend l’état précédent et un bloc en entrée et produit l’état suivant en sortie. Les validateurs doivent exécuter cette fonction à chaque fois qu’un nouveau bloc est proposé et vérifier que le hachage représentant l’état sur le dessus du bloc, communément appelé la racine d’état, est correct.

Les exigences élevées du système pour devenir un validateur découlent principalement de la nécessité d’effectuer ce processus efficacement.

Si vous souhaitez transformer un réfrigérateur intelligent - oui, même un réfrigérateur - en validateur Ethereum avec l’aide d’un logiciel installé, vous rencontrez deux obstacles majeurs :

1. Votre réfrigérateur n’aura probablement pas une connexion internet suffisamment rapide, ce qui signifie qu’il ne pourra pas télécharger les données et les preuves nécessaires à l’exécution, même avec les solutions de vérifiabilité de l’état que nous avons discutées jusqu’à présent.
2. Même s’il avait accès aux données nécessaires pour STF, il n’aurait pas la puissance de calcul requise pour effectuer l’exécution du début à la fin ou pour construire un nouvel arbre d’état.

Pour résoudre les problèmes causés par les clients légers n’ayant pas accès à l’état précédent ou à la totalité du dernier bloc, The Verge propose que le proposant effectue l’exécution puis attache une preuve au bloc. Cette preuve inclurait la transition de la racine de l’état précédent à la racine de l’état suivant ainsi que le hachage du bloc. Avec cela, les clients légers peuvent valider la transition d’état en utilisant seulement trois hachages de 32 octets, sans avoir besoin d’une preuve zk.

Cependant, comme cette preuve fonctionne à travers des hachages, il serait incorrect de dire qu’elle ne valide que la transition d’état. Au contraire, la preuve attachée au bloc doit valider simultanément plusieurs choses:

Racine d’état dans le bloc précédent = S, Racine d’état dans le bloc suivant = S + 1, Hash du bloc = H

1. Le bloc lui-même doit être valide, et la preuve d’état à l’intérieur, qu’il s’agisse d’une preuve Verkle ou de STARKs, doit vérifier avec précision les données accompagnant le bloc.
   En bref: Validation du bloc et la preuve d’état accompagnante.
2. Lorsque le STF est exécuté en utilisant les données nécessaires à l’exécution et inclus dans le bloc correspondant à H, les données qui doivent changer dans l’état doivent être mises à jour correctement.
   En bref : Validation de la transition d’état.
3. Lorsqu’un nouvel arbre d’état est reconstruit avec les données correctement mises à jour, sa valeur racine doit correspondre à S + 1.
   En bref: Validation du processus de construction de l’arbre.

Dans l’analogie du Prover- Vérificateur que nous avons mentionnée précédemment, on peut généralement dire qu’il y a généralement un équilibre computationnel entre les deux acteurs. Alors que la capacité de preuves requises pour rendre le STF vérifiable afin de valider plusieurs choses simultanément offre des avantages significatifs pour le Vérificateur, cela indique également que générer de telles preuves pour garantir la correction de l’exécution sera relativement difficile pour le Prover. Avec la vitesse actuelle d’Ethereum, un bloc Ethereum doit être prouvé en moins de 4 secondes. Cependant, même le Prover EVM le plus rapide que nous ayons aujourd’hui ne peut prouver en moyenne un bloc en environ 15 secondes.[1]

Cela étant dit, il y a trois chemins distincts que nous pouvons emprunter pour surmonter ce défi majeur:

1. Parallélisation dans la preuve & l’agrégation: Un des avantages significatifs des preuves ZK est leur capacité à être agrégées. La capacité de combiner plusieurs preuves en une seule preuve compacte offre une efficacité substantielle en termes de temps de traitement. Cela réduit non seulement la charge sur le réseau mais accélère également les processus de vérification de manière décentralisée. Pour un grand réseau comme Ethereum, cela permet une génération plus efficace des preuves pour chaque bloc.

Lors de la génération de la preuve, chaque petite partie du processus d’exécution (par exemple, les étapes de calcul ou l’accès aux données) peut être prouvée individuellement, et ces preuves peuvent ensuite être agrégées dans une structure unique. Avec le mécanisme correct, cette approche permet à des preuves de bloc d’être générées rapidement et de manière décentralisée par de nombreuses sources différentes (par exemple, des centaines de GPUs). Cela améliore les performances tout en contribuant également à l’objectif de décentralisation en engageant un plus large éventail de participants.

1. Utilisation de systèmes de preuve optimisés : Les systèmes de preuve de nouvelle génération ont le potentiel de rendre les processus de calcul d’Ethereum plus rapides et plus efficaces. Des systèmes avancés comme Orion, Binius, et GKRpeut considérablement réduire le temps de prouver pour les calculs à usage général. Ces systèmes visent à surmonter les limites des technologies actuelles, en augmentant la vitesse de traitement tout en consommant moins de ressources. Pour un réseau axé sur la scalabilité et l’efficacité comme Ethereum, de telles optimisations offrent un avantage significatif. Cependant, la mise en œuvre complète de ces nouveaux systèmes nécessite des tests complets et des efforts de compatibilité au sein de l’écosystème.
2. Changements de coût en gaz : Historiquement, les coûts en gaz pour les opérations sur la Machine Virtuelle Ethereum (EVM) étaient généralement déterminés en fonction de leurs coûts de calcul. Cependant, aujourd’hui, une autre métrique a gagné en importance : la complexité du prouveur. Alors que certaines opérations sont relativement faciles à prouver, d’autres ont une structure plus complexe et prennent plus de temps à vérifier. Ajuster les coûts en gaz non seulement en fonction de l’effort de calcul, mais aussi de la difficulté de prouver les opérations est essentiel pour améliorer à la fois la sécurité et l’efficacité du réseau.

Cette approche peut minimiser l’écart entre les scénarios du pire des cas et du cas moyen, ce qui permet une performance plus cohérente. Par exemple, les opérations plus difficiles à prouver pourraient avoir des coûts de gaz plus élevés, tandis que celles qui sont plus faciles à prouver pourraient avoir des coûts plus bas. De plus, remplacer les structures de données d’Ethereum (comme l’arbre d’état ou la liste des transactions) par des alternatives compatibles avec STARK pourrait accélérer davantage les processus de preuve. De tels changements aideraient Ethereum à atteindre ses objectifs de scalabilité et de sécurité tout en rendant sa vision de vérifiabilité plus réaliste.

Les efforts d’Ethereum pour permettre des preuves d’exécution représentent une occasion importante de réaliser ses objectifs de vérifiabilité. Cependant, pour atteindre cet objectif, il faut non seulement des innovations techniques, mais aussi des efforts d’ingénierie accrus et des décisions critiques au sein de la communauté. Rendre les processus d’exécution vérifiables sur la couche 1 doit trouver un équilibre entre être accessible à un large éventail d’utilisateurs tout en préservant la décentralisation et en s’alignant sur l’infrastructure existante. L’établissement de cet équilibre accroît la complexité des méthodes utilisées pour prouver les opérations pendant l’exécution, ce qui souligne la nécessité de progrès tels que la génération de preuves parallèles. De plus, les exigences infrastructurelles de ces technologies (par exemple, tables de recherche) doit être mis en œuvre et opérationnalisé, ce qui nécessite encore des recherches et des développements substantiels.

D’autre part, les circuits spécialisés (par exemple, ASIC, FPGA, GPU) conçus spécifiquement pour certaines tâches présentent un potentiel significatif pour accélérer le processus de génération de preuves. Ces solutions offrent une efficacité beaucoup plus élevée par rapport au matériel traditionnel et peuvent accélérer les processus d’exécution. Cependant, les objectifs de décentralisation d’Ethereum au niveau de la couche 1 empêchent que ce matériel ne soit accessible à un groupe restreint d’acteurs. Par conséquent, on s’attend à ce que ces solutions soient davantage utilisées dans les systèmes de couche 2. Néanmoins, la communauté doit également parvenir à un consensus sur les exigences matérielles pour la génération de preuves. Une question de conception clé émerge : la génération de preuves devrait-elle fonctionner sur du matériel grand public comme des ordinateurs portables haut de gamme, ou nécessiter une infrastructure industrielle ? La réponse façonne l’ensemble de l’architecture d’Ethereum - permettant une optimisation agressive pour les solutions de couche 2 tout en exigeant des approches plus conservatrices pour la couche 1.

Enfin, la mise en œuvre des preuves d’exécution est directement liée à d’autres objectifs de la feuille de route d’Ethereum. L’introduction de preuves de validité ne soutiendrait pas seulement des concepts tels que l’état sans état, mais renforcerait également la décentralisation d’Ethereum en rendant des domaines tels que le staking en solo plus accessibles. L’objectif est de permettre le staking même sur les appareils les moins performants. De plus, la restructuration des coûts en gaz sur l’EVM en fonction de la difficulté computationnelle et de la probabilité pourrait minimiser l’écart entre les scénarios moyens et les pires cas. Cependant, de tels changements pourraient rompre la compatibilité ascendante avec le système actuel et obliger les développeurs à réécrire leur code. Pour cette raison, la mise en œuvre des preuves d’exécution n’est pas seulement un défi technique, c’est un parcours qui doit être conçu pour défendre les valeurs à long terme d’Ethereum.

Dernière étape pour une vérification complète et véritable : Consensus

Le mécanisme de consensus d’Ethereum s’efforce d’établir un équilibre unique qui préserve la décentralisation et l’accessibilité tout en atteignant des objectifs de vérifiabilité. Dans ce cadre, les méthodes de consensus probabilistes et déterministes offrent des avantages et des défis distincts.

Le consensus probabiliste repose sur un modèle de communication par bavardage. Dans ce modèle, au lieu de communiquer directement avec tous les nœuds représentant le réseau, un nœud partage des informations avec un ensemble de 64 ou 128 nœuds sélectionnés au hasard. La sélection de la chaîne d’un nœud est basée sur ces informations limitées, ce qui introduit la possibilité d’erreur. Cependant, au fil du temps, à mesure que la blockchain progresse, ces sélections sont censées converger vers la chaîne correcte avec un taux d’erreur de 0%.

Un avantage de la structure probabiliste est que chaque nœud ne diffuse pas sa vue de la chaîne en tant que message séparé, ce qui réduit les frais de communication. En conséquence, une telle structure peut fonctionner avec beaucoup plus de nœuds décentralisés sans permission et avec des exigences système moins élevées. En revanche, le consensus déterministe fonctionne selon un modèle de communication un-à-tous. Ici, un nœud envoie sa vue de la chaîne en tant que vote à tous les autres nœuds. Cette approche génère une intensité de messages plus élevée et, à mesure que le nombre de nœuds augmente, le système peut éventuellement atteindre ses limites. Cependant, le plus grand avantage du consensus déterministe est la disponibilité des votes concrets, ce qui vous permet de savoir exactement quel nœud a voté pour quelle fourchette. Cela garantit une finalité de chaîne rapide et définitive, garantissant que les blocs ne peuvent pas changer leur ordre et les rendant vérifiables.

Pour fournir un mécanisme de consensus vérifiable tout en préservant la décentralisation et une structure sans autorisation, Ethereum a trouvé un équilibre entre les slots et les epochs. Les slots, qui représentent des intervalles de 12 secondes, sont les unités de base où un validateur est responsable de la production d’un bloc. Bien que le consensus probabiliste utilisé au niveau du slot permette à la chaîne de fonctionner de manière plus flexible et décentralisée, il présente des limites en termes d’ordonnancement définitif et de vérifiabilité.

Les époques, qui englobent 32 slots, introduisent un consensus déterministe. À ce niveau, les validateurs votent pour finaliser l’ordre de la chaîne, garantissant la certitude et rendant la chaîne vérifiable. Cependant, bien que cette structure déterministe offre une vérifiabilité grâce à des votes concrets au niveau de l’époque, elle ne peut pas offrir une vérifiabilité complète au sein des époques elles-mêmes en raison de la structure probabiliste. Pour combler cette lacune et renforcer la structure probabiliste au sein des époques, Ethereum a développé une solution connue sous le nom de Comité de synchronisation.

Protocole du client léger d’Altair : Comité de synchronisation

Le comité de synchronisation est un mécanisme introduit avec la mise à niveau Altair pour surmonter les limitations du consensus probabiliste d’Ethereum et améliorer la vérifiabilité de la chaîne pour les clients légers. Le comité est composé de 512 validateurs sélectionnés de manière aléatoire qui servent pendant 256 époques (~27 heures). Ces validateurs produisent une signature représentant la tête de la chaîne, permettant aux clients légers de vérifier la validité de la chaîne sans avoir besoin de télécharger des données historiques de la chaîne. Le fonctionnement du comité de synchronisation peut être résumé comme suit:

1. Formation du Comité :
   512 validateurs sont sélectionnés de manière aléatoire parmi tous les validateurs du réseau. Cette sélection est régulièrement actualisée pour maintenir la décentralisation et éviter de dépendre d’un groupe spécifique.
2. Génération de signature:
   Les membres du comité produisent une signature qui représente l’état le plus récent de la chaîne. Cette signature est une signature BLS collective créée par les membres et est utilisée pour vérifier la validité de la chaîne.
3. Vérification du client léger:
   Les clients légers peuvent vérifier la validité de la chaîne en vérifiant simplement la signature du comité de synchronisation. Cela leur permet de suivre en toute sécurité la chaîne sans télécharger les données de la chaîne passée.

Cependant, le comité de synchronisation a fait l’objet de critiques dans certains domaines. Notamment, le protocole manque d’un mécanisme pour réduire les validateurs pour un comportement malveillant, même si les validateurs sélectionnés agissent intentionnellement contre le protocole. En conséquence, beaucoup considèrent le comité de synchronisation comme un risque pour la sécurité et s’abstiennent de le classer entièrement comme un protocole client léger. Néanmoins, la sécurité du comité de synchronisation a été mathématiquement prouvée, et des détails supplémentaires peuvent être trouvés dans cet article sur les réductions du Comité de synchronisation.

L’absence d’un mécanisme de suppression dans le protocole n’est pas un choix de conception, mais une nécessité découlant de la nature du consensus probabiliste. Le consensus probabiliste ne fournit pas de garanties absolues sur ce qu’un validateur observe. Même si la majorité des validateurs signalent une fourchette particulière comme la plus lourde, il peut encore y avoir des validateurs exceptionnels observant une fourchette différente comme plus lourde. Cette incertitude rend difficile de prouver une intention malveillante et donc impossible de punir un comportement incorrect.

Dans ce contexte, plutôt que de qualifier le Comité de synchronisation d’insécurité, il serait plus précis de le décrire comme une solution inefficace. Le problème ne vient pas de la conception mécanique ou du fonctionnement du Comité de synchronisation, mais de la nature inhérente du consensus probabiliste. Étant donné que le consensus probabiliste ne peut pas offrir de garanties définitives sur ce que les nœuds observent, le Comité de synchronisation est l’une des meilleures solutions pouvant être conçues dans un tel modèle. Cependant, cela n’élimine pas les faiblesses du consensus probabiliste dans la garantie de la finalité de la chaîne. Le problème ne réside pas dans le mécanisme mais dans la structure de consensus actuelle d’Ethereum.

En raison de ces limitations, des efforts sont en cours dans l’écosystème Ethereum pour redéfinir le mécanisme de consensus et mettre en œuvre des solutions qui offrent une finalité déterministe en périodes plus courtes. Des propositions comme Orbit-SSFet3SFvise à remodeler la structure de consensus d’Ethereum de fond en comble, créant ainsi un système plus efficace pour remplacer le consensus probabiliste. Ces approches cherchent non seulement à raccourcir le temps de finalité de la chaîne, mais aussi à offrir une structure réseau plus efficace et vérifiable. La communauté Ethereum continue de développer activement et de préparer ces propositions pour une mise en œuvre future.

Snarkification du consensus

Verge vise à améliorer les mécanismes de consensus actuels et futurs d’Ethereum en les rendant plus vérifiables grâce à la technologie des preuves de connaissance nulle, plutôt que de les remplacer entièrement. Cette approche vise à moderniser les processus de consensus d’Ethereum tout en préservant ses principes fondamentaux de décentralisation et de sécurité. L’optimisation de tous les processus de consensus historiques et actuels de la chaîne avec les technologies zk joue un rôle crucial dans la réalisation des objectifs de scalabilité et d’efficacité à long terme d’Ethereum. Les opérations fondamentales utilisées dans la couche de consensus d’Ethereum revêtent une grande importance dans cette transformation technologique. Prenons un peu plus près ces opérations et les défis auxquels elles sont confrontées.

• ECADDs:
  • Objectif : Cette opération est utilisée pour regrouper les clés publiques des validateurs et est essentielle pour garantir l’exactitude et l’efficacité de la chaîne. Grâce à la nature regroupable des signatures BLS, plusieurs signatures peuvent être combinées dans une seule structure. Cela réduit la surcharge de communication et rend les processus de vérification sur la chaîne plus efficaces. Assurer une synchronisation plus efficace parmi les grands groupes de validateurs rend cette opération essentielle.
  • Défis : Comme mentionné précédemment, les validateurs d’Ethereum votent pour l’ordre de la chaîne pendant les époques. Aujourd’hui, Ethereum est un réseau avec environ 1,1 million de validateurs. Si tous les validateurs essayaient de propager leurs votes simultanément, cela créerait une tension importante sur le réseau. Pour éviter cela, Ethereum permet aux validateurs de voter sur une base de slot pendant une époque, où seulement 1/32 de tous les validateurs votent par slot. Bien que ce mécanisme réduise les frais généraux de communication du réseau et rende le consensus plus efficace, compte tenu du nombre de validateurs d’aujourd’hui, environ 34 000 validateurs votent dans chaque slot. Cela se traduit par environ 34 000 opérations ECADD par slot.
• Paires:
  • Objectif : Les opérations de couplage sont utilisées pour vérifier les signatures BLS, assurant la validité des époques sur la chaîne. Cette opération permet une vérification en lot des signatures. Cependant, elle n’est pas zk-friendly, ce qui la rend extrêmement coûteuse à prouver en utilisant la technologie zk-proof. Cela présente un défi majeur dans la création d’un processus de vérification intégré avec des technologies de preuve de zéro-connaissance.
  • Défis : Les opérations d’appariement dans Ethereum sont limitées à un maximum de 128 attestations (signatures agrégées) par créneau, ce qui se traduit par moins d’opérations d’appariement par rapport aux ECADD. Cependant, le manque de convivialité zk dans ces opérations pose un défi important. Prouver une opération d’appariement avec des preuves zk est des milliers de fois plus coûteux que prouver une opération ECADD [2]. Cela rend l’adaptation des opérations d’appariement pour les technologies de connaissance nulle l’un des plus grands obstacles dans les processus de vérification du consensus d’Ethereum.
• Hashes SHA256 :
  • Objectif : Les fonctions de hachage SHA256 sont utilisées pour lire et mettre à jour l’état de la chaîne, garantissant l’intégrité des données de la chaîne. Cependant, leur manque de convivialité pour zk entraîne des inefficacités dans les processus de vérification basés sur la preuve zk, posant un obstacle majeur aux objectifs de vérifiabilité future d’Ethereum.
  • Défis : Les fonctions de hachage SHA256 sont fréquemment utilisées pour lire et mettre à jour l’état de la chaîne. Cependant, leur incompatibilité avec la preuve de connaissance nulle (zk-proof) entre en conflit avec les objectifs de vérification basés sur la preuve de Ethereum. Par exemple, entre deux époques, chaque validateur exécute la STF de la couche de consensus d’Ethereum pour mettre à jour l’état avec des récompenses et des pénalités basées sur la performance du validateur pendant l’époque. Ce processus repose fortement sur les fonctions de hachage SHA256, augmentant considérablement les coûts des systèmes basés sur la preuve de connaissance nulle (zk-proof). Cela crée une barrière substantielle pour aligner le mécanisme de consensus d’Ethereum avec les technologies zk.

Les opérations ECADD, Pairing et SHA256 utilisées dans la couche de consensus actuelle jouent un rôle essentiel dans les objectifs de vérifiabilité d’Ethereum. Cependant, leur manque de convivialité pour zk pose des défis significatifs sur la voie de la réalisation de ces objectifs. Les opérations ECADD créent un fardeau coûteux en raison du grand volume de votes des validateurs, tandis que les opérations de Pairing, bien qu’en nombre plus réduit, sont des milliers de fois plus coûteuses à prouver avec des zk-proofs. De plus, la non-convivialité pour zk des fonctions de hachage SHA256 rend extrêmement difficile la preuve de la transition d’état de la chaîne de balises. Ces problèmes soulignent la nécessité d’une transformation complète pour aligner l’infrastructure existante d’Ethereum avec les technologies de connaissance zéro.

Solution « Beam Chain » : Repenser la couche de consensus d’Ethereum

Le 12 novembre 2024, lors de sa présentation à Devcon, Justin Drake a présenté une proposition appelée «Beam Chain» visant à transformer fondamentalement et de manière exhaustive la couche de consensus d’Ethereum. La Beacon Chain est au cœur du réseau Ethereum depuis près de cinq ans. Cependant, au cours de cette période, il n’y a eu aucun changement structurel majeur apporté à la Beacon Chain. En revanche, les avancées technologiques ont progressé rapidement, dépassant largement la nature statique de la Beacon Chain.

Dans sa présentation, Justin Drake a souligné que Ethereum a appris des leçons significatives au cours de ces cinq années dans des domaines critiques tels que la compréhension de l’exploitation de la valeur de l’ensemble des mineurs (MEV), les percées dans les technologies SNARK et la prise de conscience rétrospective des erreurs technologiques. Les conceptions informées par ces nouvelles connaissances sont catégorisées en trois piliers principaux : Production de blocs, Enjeu et Cryptographie. Le visuel suivant résume ces conceptions et la feuille de route proposée :

• Les boîtes vertes et grises représentent des développements incrémentiels qui peuvent être mis en œuvre progressivement chaque année. Ces types d’améliorations, tout comme les mises à niveau précédentes, peuvent être intégrés étape par étape sans perturber l’architecture existante d’Ethereum.
• Les boîtes rouges, d’autre part, signifient des changements à haute synergie, à grande échelle et fondamentaux qui doivent être mis en œuvre ensemble. Selon Drake, ces changements visent à faire avancer la capacité et la vérifiabilité d’Ethereum en un seul grand bond.

Dans cette section, nous avons examiné en détail les étapes de consensus, d’état et d’exécution de The Verge, et l’un des problèmes les plus importants mis en évidence au cours de ce processus est l’utilisation de la fonction de hachage SHA256 dans la chaîne Beacon d’Ethereum. Bien que SHA256 joue un rôle central dans la sécurité du réseau et le traitement des transactions, son manque de convivialité pour zk pose un obstacle important à la réalisation des objectifs de vérifiabilité d’Ethereum. Son coût élevé en calcul et son incompatibilité avec les technologies zk en font une question critique qui doit être abordée dans les futurs développements d’Ethereum.

La feuille de route de Justin Drake, présentée lors de sa conférence Devcon, prévoit de remplacer SHA256 dans Beacon Chain par des fonctions de hachage zk-friendly telles que Poseidon. Cette proposition vise à moderniser la couche de consensus d’Ethereum, la rendant plus vérifiable, efficace et alignée sur les technologies de preuve zk.

Dans ce contexte, nous voyons que Ethereum doit non seulement relever les défis liés aux fonctions de hachage non compatibles avec zk, mais doit également réévaluer les signatures numériques utilisées dans sa couche de consensus pour une sécurité à long terme. Avec l’avancée de l’informatique quantique, des algorithmes de signature numérique comme ECDSA actuellement utilisés pourraient être confrontés à des menaces significatives. Comme indiqué dans les lignes directrices publiées par le NIST, les variantes de l’ECDSA avec un niveau de sécurité de 112 bits seront obsolètes d’ici 2030 et complètement interdites d’ici 2035. Cela rend nécessaire une transition pour Ethereum et des réseaux similaires vers des alternatives plus résistantes telles que des signatures sécurisées quantiquement à l’avenir.

À ce stade, les signatures basées sur le hachage émergent comme des solutions résistantes aux attaques quantiques qui pourraient jouer un rôle critique dans la prise en charge de la sécurité et des objectifs de vérifiabilité du réseau. En répondant à ce besoin, on élimine également le deuxième obstacle majeur à rendre la Beacon Chain vérifiable : les signatures BLS. L’une des étapes les plus significatives qu’Ethereum peut franchir pour garantir la sécurité quantique est d’adopter des solutions post-quantiques telles que les signatures basées sur le hachage et les SNARKs basés sur le hachage.

Comme Justin Drake l’a souligné dans sa présentation Devcon, les fonctions de hachage sont intrinsèquement résistantes aux ordinateurs quantiques en raison de leur dépendance à la résistance aux préimages, ce qui en fait l’un des éléments fondamentaux de la cryptographie moderne. Cette propriété garantit que même les ordinateurs quantiques ne peuvent pas inverser efficacement l’entrée d’origine à partir d’un hachage donné, préservant ainsi leur sécurité. Les systèmes de signature basés sur des hachages permettent aux validateurs et aux témoins de générer des signatures entièrement basées sur des fonctions de hachage, garantissant une sécurité post-quantique tout en fournissant un niveau de vérifiabilité plus élevé sur le réseau — surtout si une fonction de hachage SNARK-friendly est utilisée. Cette approche permet non seulement d’améliorer la sécurité du réseau, mais aussi de rendre l’infrastructure de sécurité à long terme d’Ethereum plus robuste et plus adaptée aux évolutions futures.

Ce système repose sur la combinaison de signatures basées sur des hachages et de SNARKs basés sur des hachages (preuves de type STARK) pour créer des schémas de signatures agrégeables. Les signatures agrégeables compressent des milliers de signatures en une seule structure, la réduisant à quelques centaines de kilooctets de preuve. Cette compression diminue considérablement la charge de données sur le réseau tout en accélérant grandement les processus de vérification. Par exemple, les milliers de signatures de validateur produites pour une seule tranche sur Ethereum peuvent être représentées par une seule signature agrégée, économisant ainsi à la fois de l’espace de stockage et de la puissance de calcul.

Cependant, la caractéristique la plus remarquable de ce schéma est son agrégation infiniment récursive. C’est-à-dire qu’un groupe de signatures peut être combiné sous un autre groupe, et ce processus peut se poursuivre sur la chaîne. Grâce à ce mécanisme et en tenant compte des avancées technologiques futures, il est juste de dire que cela ouvre la porte à des possibilités actuellement inatteignables avec BLS.

Réflexions finales et conclusion

Le chemin d’Ethereum vers la vérifiabilité représente un changement fondamental dans la technologie de la blockchain. L’initiative Verge aborde les inefficacités fondamentales grâce aux arbres Verkle pour la vérification de l’état et aux preuves STARK pour des transitions évolutives.

L’une des propositions les plus ambitieuses est Beam Chain, une refonte complète de la couche de consensus d’Ethereum. En abordant les limitations de Beacon Chain et en intégrant des alternatives zk-friendly, cette approche vise à améliorer la scalabilité d’Ethereum tout en préservant ses principes fondamentaux de décentralisation et d’accessibilité. Cependant, la transition met également en évidence les défis auxquels Ethereum est confronté pour équilibrer les exigences computationnelles avec son objectif de maintenir un réseau sans autorisation et inclusif.

Avec le NIST prévoyant d’éliminer la cryptographie à courbes elliptiques actuelle d’ici 2035, Ethereum doit adopter des solutions résistantes aux quantiques telles que des signatures basées sur des hachages et Poseidon. Ces solutions présentent leurs propres compromis en termes d’efficacité.

L’utilisation des STARKs dans la feuille de route d’Ethereum met davantage l’accent sur la scalabilité et la vérifiabilité. Bien qu’ils excellent dans la fourniture de preuves transparentes et résistantes aux attaques quantiques, leur intégration pose des défis liés aux coûts de calcul du côté du prouveur et aux inefficacités des petites données. Ces obstacles doivent être surmontés pour réaliser pleinement la vision d’Ethereum de l’état sans état et de la vérification efficace des blocs, en veillant à ce que le réseau reste robuste face à une demande croissante.

Malgré ces avancées, des défis clés subsistent. Ethereum doit naviguer à travers les problèmes de convivialité zk, de scalabilité du consensus et des complexités liées à l’intégration de la cryptographie résistante aux attaques quantiques. De plus, la compatibilité ascendante de l’infrastructure existante pose des obstacles pratiques qui nécessitent des solutions d’ingénierie soigneuses pour éviter les perturbations tant pour les développeurs que pour les utilisateurs.

Ce qui distingue Ethereum, ce ne sont pas seulement ses innovations techniques, mais son approche itérative pour résoudre certains des problèmes les plus difficiles de la blockchain. La voie à suivre - que ce soit par le biais de technologies telles que Beam Chain, Verkle Trees ou STARK proofs - dépend d’un effort collaboratif des développeurs, des chercheurs et de la communauté dans son ensemble. Ces avancées ne visent pas à atteindre la perfection du jour au lendemain, mais à créer une base pour un Internet transparent, décentralisé et vérifiable.

L’évolution d’Ethereum souligne son rôle de joueur clé dans la définition de l’ère Web3. En abordant les défis actuels avec des solutions pratiques, Ethereum se rapproche d’un avenir où la vérifiabilité, la résistance quantique et la scalabilité deviennent la norme, et non l’exception.

Avertissement :

1. Cet article est repris de [[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[2077 Recherche](https://research.2077.xyz/)\]. Tous les droits d’auteur appartiennent à l’auteur original [ Koray Akpinarr]. S’il y a des objections à cette reproduction, veuillez contacter le Apprenez Gatel’équipe et ils s’en occuperont rapidement.
2. Clause de non-responsabilité : Les opinions exprimées dans cet article sont uniquement celles de l’auteur et ne constituent en aucun cas des conseils en matière d’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.