Vitalik Buterin a déclaré qu’il n’était plus d’accord avec son tweet de 2017 qui minimisait la nécessité pour les utilisateurs de vérifier personnellement Ethereum de bout en bout.
Cette semaine, il a soutenu que le réseau devrait considérer la vérification auto-hébergée comme une échappatoire non négociable, à mesure que son architecture devient plus légère et plus modulaire.
La position originale de Buterin est née d’un débat de conception sur la question de savoir si une blockchain devrait s’engager à maintenir un état en chaîne ou traiter l’état comme « implicite », reconstructible uniquement en répétant les transactions ordonnées.
L’approche d’Ethereum, en plaçant une racine d’état dans chaque en-tête de bloc et en prenant en charge les preuves de style Merkle, permet à un utilisateur de prouver un solde spécifique, un code de contrat ou une valeur de stockage sans réexécuter tout l’historique, à condition que l’utilisateur accepte la validité consensuelle de la chaîne sous une hypothèse de majorité honnête.
Vitalik fait demi-tour sur la vérification personnelle de l’historique de la blockchain
Il a ancré le changement sur deux axes : la faisabilité et la fragilité.
Concernant la faisabilité, Buterin a écrit que les preuves sans connaissance offrent désormais un moyen de vérifier l’exactitude sans « littéralement réexécuter chaque transaction ».
En 2017, il a fait valoir que cela aurait poussé Ethereum vers une capacité inférieure pour maintenir la vérification à portée de main.
Ce changement est important car la feuille de route publique d’Ethereum traite de plus en plus ZK comme une primitive de vérifiabilité, ethereum.org encadrant les preuves sans connaissance comme un moyen de préserver les propriétés de sécurité tout en réduisant ce qu’un vérificateur doit calculer.
Les travaux sur les directions « ZK-light-client » pointent également vers un modèle dans lequel un appareil peut se synchroniser à l’aide d’épreuves compactes plutôt que de faire confiance à une passerelle toujours en ligne.
Concernant la fragilité, Buterin a énuméré des modes de défaillance qui s’inscrivent en dehors des modèles de menace propres : réseaux p2p dégradés, fermeture de services de longue durée, concentration des validateurs qui modifie le sens pratique de « majorité honnête » et pression de gouvernance informelle qui transforme « appeler les développeurs » en filet de sécurité.
Il a cité la pression de la censure autour de Tornado Cash comme exemple de la façon dont les intermédiaires peuvent restreindre l’accès, arguant que l’option de dernier recours d’un utilisateur devrait être « d’utiliser directement la chaîne ».
Ce cadre s’inscrit dans le cadre d’une discussion plus large sur le renforcement de la couche de base d’Ethereum et la limitation du taux de désabonnement, dans un contexte de poussée vers une « ossification » du protocole.
Selon Buterin, la « cabane de montagne » n’est pas un mode de vie par défaut.
Il s’agit d’une solution de repli crédible qui modifie les incitations, car le fait de savoir que les utilisateurs peuvent quitter réduit l’effet de levier de n’importe quelle couche de service.
Cet argument se pose alors qu’Ethereum réduit ce que les nœuds ordinaires sont censés stocker, tandis que l’histoire de la vérification du réseau doit suivre le rythme.
Utilisation et historique du client Ethereum
Les clients d’exécution s’orientent vers une expiration partielle de l’historique, et la Fondation Ethereum a déclaré que les utilisateurs peuvent réduire l’utilisation du disque d’environ 300 à 500 Go en supprimant les données de bloc pré-fusion, mettant ainsi un nœud à portée de main sur un disque de 2 To.
Dans le même temps, les clients légers reflètent déjà un modèle de confiance formalisé optimisé pour les appareils à faibles ressources, s’appuyant sur un comité de synchronisation de 512 validateurs sélectionnés tous les 1,1 jours environ.
Ces paramètres rendent la vérification des clients légers réalisable à grande échelle.
Cependant, ils concentrent également l’expérience utilisateur sur la disponibilité de données correctes et de relais performants lorsque les conditions se détériorent.
Le travail à long terme d’Ethereum sur « l’apatridie » vise à réduire la nécessité pour les nœuds de détenir un grand état tout en préservant la validation des blocs intacte.
Ethereum.org prévient que « l’apatridie » est un terme impropre, distinguant les formes les plus faibles des conceptions plus solides qui restent des recherches, y compris l’expiration de l’État.
Les arbres Verkle se trouvent à l’intérieur de ce plan car ils réduisent la taille des preuves et sont positionnés comme une étape clé permettant la validation sans stocker localement un grand état.
À mesure que la charge de stockage se déplace vers l’extérieur, soit vers des hôtes d’historique spécialisés, soit vers d’autres réseaux de données, la question de la sécurité se résume moins à savoir qui peut tout stocker, mais davantage à savoir qui peut vérifier indépendamment l’exactitude et récupérer ce dont il a besoin en cas d’échec d’un chemin par défaut.
Ce que cela signifie pour l’avenir
Au cours des 12 à 36 prochains mois, la question pratique est de savoir si la vérification s’étendra à mesure qu’Ethereum externalisera davantage de charges de stockage, ou si la confiance se regroupera autour de nouveaux points d’étranglement de service.
Une solution consiste à ce que les portefeuilles et l’infrastructure passent de « faire confiance au RPC » à « vérifier la preuve », tandis que la production de preuves se consolide en un petit ensemble de piles optimisées difficiles à répliquer, déplaçant la dépendance d’une classe de fournisseur à une autre.
Une autre voie est que la vérification basée sur des preuves devienne ordinaire, avec des implémentations et des outils de preuve redondants qui permettent aux utilisateurs de changer de fournisseur ou de vérifier localement lorsqu’un point de terminaison censure, se dégrade ou disparaît, s’alignant ainsi sur les efforts visant à des flux de vérification légers.
Une troisième voie est que l’élagage et la modularité progressent plus rapidement que la vérification UX, laissant aux utilisateurs moins d’options pratiques en cas de pannes ou d’événements de censure.
Cela rendrait la « cabane de montagne » opérationnellement réelle pour une partie restreinte du réseau seulement.
Buterin a présenté la cabine comme le BATNA d’Ethereum, rarement utilisé mais toujours disponible, car l’existence d’une option autonome contraint les conditions imposées par les intermédiaires.
Il a conclu en affirmant que le maintien de cette solution de repli fait partie du maintien d’Ethereum lui-même.
