Vitalik Buterin admet sa plus grande erreur de conception depuis 2017 – votre Ethereum est-il donc en danger ?

Vitalik Buterin a déclaré qu'il n'est 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 traiter la vérification auto-hébergée comme une sortie de secours non négociable à mesure que son architecture devient plus légère et plus modulaire.

La position initiale de Buterin est née d'un débat de conception sur la question de savoir si une blockchain devrait s'engager à l'état on-chain ou traiter l'état comme « implicite », reconstructible uniquement en rejouant les transactions ordonnées.

L'approche d'Ethereum, qui place une racine d'état dans chaque en-tête de bloc et prend en charge les preuves de type 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, tant que l'utilisateur accepte la validité du consensus de la chaîne sous l'hypothèse d'une majorité honnête.

Dans son nouveau message, Buterin a recadré ce compromis comme incomplet dans la pratique car il peut encore contraindre les utilisateurs à choisir entre rejouer la chaîne complète ou faire confiance à un intermédiaire tel qu'un opérateur RPC, un hôte de données d'archives ou un service de preuve.

Le revirement de Vitalik sur la vérification personnelle de l'historique de la blockchain

Il a ancré le changement dans deux évolutions : la faisabilité et la fragilité.

Sur la faisabilité, Buterin a écrit que les preuves à divulgation nulle de connaissance offrent désormais un moyen de vérifier l'exactitude sans « littéralement réexécuter chaque transaction ».

En 2017, il a soutenu 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 le ZK comme une primitive de vérifiabilité, ethereum.org présentant les preuves à divulgation nulle de 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 où un appareil peut se synchroniser à l'aide de preuves compactes plutôt que de faire confiance à une passerelle toujours en ligne.

Sur la fragilité, Buterin a énuméré les modes de défaillance qui se situent en dehors des modèles de menace propres : réseau p2p dégradé, services de longue durée fermant, concentration des validateurs qui modifie le sens pratique de « majorité honnête », et pression de gouvernance informelle qui transforme « appeler les développeurs » en solution de secours.

Il a cité la pression de 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 cadrage s'inscrit dans une discussion plus large sur le renforcement de la couche de base d'Ethereum et la limitation du turnover, au milieu d'une poussée vers l'« ossification » du protocole.

Dans le récit de Buterin, la « cabane de montagne » n'est pas un mode de vie par défaut.

C'est une solution de secours crédible qui change les incitations, car la connaissance que les utilisateurs peuvent sortir réduit l'effet de levier de toute couche de service unique.

Cet argument arrive alors qu'Ethereum réduit ce que les nœuds ordinaires sont censés stocker, tandis que l'histoire de vérification du réseau doit suivre le rythme.

Utilisation et historique des clients Ethereum

Les clients d'exécution évoluent 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é-Merge, mettant un nœud à portée sur un disque de 2 To.

En 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 environ tous les 1,1 jours.

Ces paramètres rendent la vérification par client léger réalisable à grande échelle.

Cependant, ils concentrent également l'expérience utilisateur autour de la disponibilité de données correctes et de relais bien comportés lorsque les conditions se détériorent.

Le travail à plus long terme d'Ethereum sur l'« absence d'état » vise à réduire la nécessité pour les nœuds de détenir un état important tout en maintenant la validation des blocs intacte.

Ethereum.org met en garde que l'« absence d'état » est un terme impropre, distinguant les formes plus faibles des conceptions plus fortes qui restent de la recherche, y compris l'expiration d'état.

Les arbres Verkle s'inscrivent dans ce plan car ils réduisent les tailles de preuve et sont positionnés comme une étape clé pour valider sans stocker un grand état localement.

À mesure que davantage de charge de stockage se déplace vers l'extérieur, soit vers des hôtes d'historique spécialisés ou d'autres réseaux de données, l'histoire de la sécurité devient moins une question de savoir qui peut tout stocker et plus une question de savoir qui peut vérifier indépendamment l'exactitude et récupérer ce dont il a besoin lorsqu'un chemin par défaut échoue.

Ce que cela signifie pour l'avenir

Au cours des 12 à 36 prochains mois, la question pratique est de savoir si la vérification se propage vers l'extérieur alors qu'Ethereum externalise davantage de charges de stockage, ou si la confiance se regroupe autour de nouveaux points d'étranglement de service.

Une voie est 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 la preuve devienne ordinaire, avec des implémentations de preuve redondantes et des outils permettant 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 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 l'UX de vérification, laissant les utilisateurs avec moins d'options viables lors de pannes ou d'événements de censure.

Cela rendrait la « cabane de montagne » opérationnellement réelle pour seulement une tranche étroite du réseau.

Buterin a présenté la cabane comme la BATNA d'Ethereum, rarement utilisée mais toujours disponible, car l'existence d'une option autonome limite les conditions imposées par les intermédiaires.

Il a conclu en arguant que le maintien de cette solution de secours fait partie du maintien d'Ethereum lui-même.

L'article Vitalik Buterin admet sa plus grande erreur de conception depuis 2017 – votre Ethereum est-il donc en danger ? est apparu en premier sur CryptoSlate.