Le 18 janvier, PANews rapporte qu'Alexey Grishin a publié un message sur la plateforme X indiquant que l'un des aspects importants et longtemps sous-estimés de la « non-confiance », du « test de départ » et de l'« autonomie personnelle » est la simplicité du protocole. Même si un protocole possède des dizaines de milliers de nœuds, une tolérance aux Byzantins de 49 %, et que les nœuds vérifient tout via des preuves de calculs (peerdas) et des preuves de calculs (starks) résistantes aux ordinateurs quantiques, si ce protocole est un amas complexe composé de dizaines de milliers de lignes de code et de cinq niveaux de cryptographie nécessitant un doctorat, alors ce protocole échouera inévitablement aux trois tests : - Il ne sera pas non-confiant, car les utilisateurs devront faire confiance à un petit groupe d'experts pour leur expliquer les propriétés du protocole. - Il ne réussira pas le « test de départ », car si l'équipe actuelle des clients quitte, il sera extrêmement difficile pour une nouvelle équipe d'atteindre un niveau de qualité équivalent. - Il ne sera pas autonome, car même les utilisateurs les plus techniques ne pourront pas vérifier ou comprendre le protocole, donc il ne leur appartiendra pas pleinement. En outre, sa sécurité sera faible, car chaque composant du protocole, surtout lorsqu'il interagit de manière complexe avec d'autres, présente un risque de défaillance du protocole. Un de mes inquiétudes concernant le développement du protocole Ethereum est que nous pourrions être trop pressés d'ajouter de nouvelles fonctionnalités pour répondre à des besoins très spécifiques, même si ces fonctionnalités rendent le protocole plus lourd, ou introduisent de nouveaux types d'interactions ou des composants cryptographiques complexes comme dépendances clés. Cela peut être bénéfique à court terme en termes de fonctionnalités, mais à long terme, cela est très destructeur pour la création d'une infrastructure décentralisée durable, capable de survivre aux fluctuations des empires et des idéologies. Le problème fondamental est que si l'on juge les modifications du protocole en fonction de la « taille des changements par rapport au protocole existant », le désir de maintenir la compatibilité descendante signifie que l'on ajoute bien plus souvent que l'on ne retire, ce qui rend inévitablement le protocole plus lourd avec le temps. Pour y remédier, le processus de développement d'Ethereum doit inclure clairement une fonction de « simplification » ou de « recyclage » (garbage collection), avec trois critères de mesure pour la simplification : 1. Minimiser le nombre total de lignes de code du protocole. 2. Éviter les dépendances inutiles à des composants techniques fondamentalement complexes. 3. Ajouter plus d'invariants : des propriétés fondamentales sur lesquelles le protocole peut s'appuyer. Par exemple, l'EIP-6780 (suppression de selfdestruct) a ajouté la propriété selon laquelle un bloc ne peut modifier qu'un maximum de N emplacements de stockage, ce qui a considérablement simplifié le développement des clients. Le recyclage peut être ponctuel ou à grande échelle. La méthode ponctuelle vise à simplifier les fonctionnalités existantes pour les rendre plus claires et plus rationnelles. Un exemple de recyclage à grande échelle est le remplacement de la preuve de travail (PoW) par la preuve d'enjeu (PoS). Une autre approche est la « compatibilité descendante de type Rosetta », selon laquelle les fonctionnalités complexes mais peu utilisées restent disponibles, mais sont « dégradées » en code de contrat intelligent, et non plus en parties obligatoires du protocole, de sorte que les nouveaux développeurs de clients n'ont pas à les gérer. Par exemple, après la mise à jour complète vers l'abstraction native des comptes, tous les anciens types de transactions pourraient être éliminés ; les précompilations existantes pourraient être remplacées par du code EVM ou RISC-V ; et à terme, la machine virtuelle pourrait être remplacée de l'EVM vers le RISC-V. Enfin, j'espère que les développeurs de clients n'auront plus besoin de gérer toutes les anciennes versions du protocole Ethereum. À long terme, le rythme d'évolution d'Ethereum devrait ralentir, et nous devons éviter que les parties inutiles ne deviennent un fardeau permanent pour le protocole Ethereum.
Vitalik Buterin appelle à une simplification et à la « collecte des ordures » dans le développement du protocole Ethereum
PANewsPartager
Résumé
Vitalik Buterin a appelé à davantage de simplicité dans le développement des blockchains, soulignant qu'Ethereum devait éviter l'enflure du protocole. Il a proposé un « nettoyage de la mémoire » (« garbage collection ») afin de réduire la taille du code et ses dépendances. Buterin a également suggéré de déplacer les fonctionnalités sous-utilisées vers le développement des contrats intelligents plutôt que dans le code central. L'objectif est de préserver la décentralisation et la sécurité à long terme. La compatibilité du type Rosetta pourrait aider à maintenir le support rétroactif. Le plan se concentre sur la durabilité et la maintenabilité dans la conception du protocole.
Source:Afficher l'original
Clause de non-responsabilité : les informations sur cette page peuvent avoir été obtenues auprès de tiers et ne reflètent pas nécessairement les points de vue ou opinions de KuCoin. Ce contenu est fourni à titre informatif uniquement, sans aucune représentation ou garantie d’aucune sorte, et ne doit pas être interprété comme un conseil en investissement. KuCoin ne sera pas responsable des erreurs ou omissions, ni des résultats résultant de l’utilisation de ces informations.
Les investissements dans les actifs numériques peuvent être risqués. Veuillez évaluer soigneusement les risques d’un produit et votre tolérance au risque en fonction de votre propre situation financière. Pour plus d’informations, veuillez consulter nos conditions d’utilisation et divulgation des risques.