Un aspect important, et perpétuellement sous-estimé, de la "non-dépendance", du "test de désengagement" et de la "souveraineté personnelle" est la simplicité des protocoles. Même si un protocole est super décentralisé avec des centaines de milliers de nœuds, et qu'il a une tolérance aux fautes byzantines de 49 %, et que les nœuds vérifient tout avec des peerdas et des starks résistants aux quantiques, si le protocole est un fouillis ingérable de centaines de milliers de lignes de code et cinq formes de cryptographie de niveau doctorat, en fin de compte, ce protocole échoue aux trois tests : * Ce n'est pas sans confiance parce que vous devez faire confiance à une petite classe de grands prêtres qui vous disent quelles propriétés le protocole a * Il ne passe pas le test de désengagement parce que si les équipes de clients existantes s'en vont, il est extrêmement difficile pour de nouvelles équipes d'atteindre le même niveau de qualité * Ce n'est pas auto-souverain parce que si même les personnes les plus techniques ne peuvent pas inspecter et comprendre la chose, ce n'est pas entièrement à vous C'est aussi moins sécurisé, car chaque partie du protocole, surtout si elle peut interagir avec d'autres parties de manière compliquée, comporte un risque que le protocole se casse. Une de mes craintes concernant le développement du protocole Ethereum est que nous puissions être trop désireux d'ajouter de nouvelles fonctionnalités pour répondre à des besoins très spécifiques, même si ces fonctionnalités gonflent le protocole ou ajoutent de nouveaux types de composants interactifs ou de cryptographie compliquée comme dépendances critiques. Cela peut être agréable pour des gains de fonctionnalité à court terme, mais c'est très destructeur pour la préservation de la souveraineté personnelle à long terme, et pour créer une hyperstructure décentralisée de cent ans qui transcende la montée et la chute des empires et des idéologies. Le problème central est que si les changements de protocole sont jugés du point de vue de "quelle est leur ampleur par rapport au protocole existant", alors le désir de préserver la compatibilité ascendante signifie que les ajouts se produisent beaucoup plus souvent que les soustractions, et le protocole gonfle inévitablement avec le temps. Pour contrer cela, le processus de développement d'Ethereum a besoin d'une fonction explicite de "simplification" / "collecte des déchets". La "simplification" a trois métriques : * Minimiser le nombre total de lignes de code dans le protocole. Un protocole idéal tient sur une seule page - ou au moins quelques pages * Éviter les dépendances inutiles sur des composants techniques fondamentalement complexes. Par exemple, un protocole dont la sécurité dépend uniquement des hachages (encore mieux : d'une seule fonction de hachage) est meilleur qu'un qui dépend des hachages et des réseaux. Ajouter des isogénies est le pire de tous, car (désolé aux véritables nerds brillants et travailleurs qui ont compris cela) personne ne comprend les isogénies. * Ajouter plus d'_invariants_ : des propriétés fondamentales sur lesquelles le protocole peut compter, par exemple l'EIP-6780 (suppression de l'auto-destruction) a ajouté la propriété que, au maximum, N emplacements de stockage peuvent être changés par emplacement, simplifiant considérablement le développement des clients, et l'EIP-7825 (plafond de gaz par transaction) a ajouté un maximum sur le coût de traitement d'une transaction, ce qui aide grandement les ZK-EVM et l'exécution parallèle. La collecte des déchets peut être par étapes, ou elle peut être à grande échelle. L'approche par étapes essaie de prendre des fonctionnalités existantes et de les rationaliser afin qu'elles soient plus simples et plus sensées. Un exemple est les réformes des coûts de gaz à Glamsterdam, qui font que de nombreux coûts de gaz qui étaient auparavant arbitraires dépendent désormais d'un petit nombre de paramètres clairement liés à la consommation de ressources. Une collecte des déchets à grande échelle a été le remplacement de PoW par PoS. Une autre est susceptible de se produire dans le cadre du consensus Lean, ouvrant la voie à la correction d'un grand nombre d'erreurs en même temps ( ). Une autre approche est la "compatibilité ascendante de style Rosetta", où les fonctionnalités qui sont complexes mais peu utilisées restent utilisables mais sont "déclassées" pour ne plus faire partie du protocole obligatoire et deviennent plutôt du code de contrat intelligent, afin que les nouveaux développeurs de clients n'aient pas besoin de s'en préoccuper. Exemples : * Après que nous ayons mis à niveau vers une abstraction de compte native complète, tous les anciens types de transactions peuvent être retirés, et les EOAs peuvent être convertis en portefeuilles de contrats intelligents dont le code peut traiter tous ces types de transactions * Nous pouvons remplacer les précompilations existantes (sauf celles qui sont _vraiment_ nécessaires) par du code EVM ou plus tard RISC-V * Nous pouvons finalement changer la VM de l'EVM à RISC-V (ou une autre VM plus simple) ; l'EVM pourrait être transformé en un contrat intelligent dans la nouvelle VM. ...