Selon un communiqué de BlockBeats, le 18 janvier, Vitalik, fondateur d'Ethereum, a publié un article affirmant que l'un des aspects importants, mais longtemps sous-estimés, de la « non-confiance », du « test de désengagement » et de l'« autonomie », est la simplicité du protocole. Même si un protocole est extrêmement décentralisé, compte des dizaines de milliers de nœuds, possède une tolérance aux fautes byzantines de 49 %, et que les nœuds utilisent des systèmes de pair (peerda) et des preuves STARK pour valider intégralement toutes les données, si ce protocole est néanmoins un amas complexe et désordonné composé de dizaines de milliers de lignes de code et de cinq formes de cryptographie nécessitant un niveau doctorat, alors ce protocole ne réussira finalement aucun des trois tests : il ne sera pas entièrement non fiable, pas entièrement autonome, et pas particulièrement sécurisé.
L'une de mes préoccupations 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 spécifiques, même si ces fonctionnalités rendent le protocole plus lourd, ou introduisent de nouveaux composants d'interaction ou des techniques cryptographiques complexes en tant que dépendances critiques. Bien que cela puisse améliorer les fonctionnalités à court terme, cela nuirait sérieusement à l'autonomie à long terme du protocole. Le problème fondamental est le suivant : si l'on juge les modifications du protocole en fonction de l'ampleur des changements apportés au protocole existant, alors, pour maintenir la compatibilité descendante, l'ajout de nouvelles fonctionnalités sera toujours plus fréquent que leur suppression, et le protocole deviendra inévitablement plus lourd avec le temps. Pour résoudre ce problème, le processus de développement d'Ethereum doit inclure un mécanisme clair de « simplification » ou de « nettoyage » (« garbage collection »).
Nous espérons que les développeurs de clients n'auront plus besoin de gérer toutes les anciennes versions du protocole Ethereum. Cela peut être laissé aux anciennes versions des clients exécutées dans des conteneurs Docker. À long terme, j'espère que le rythme des changements dans Ethereum ralentira. Je pense que, pour diverses raisons, cela deviendra inévitable à terme. Ces quinze premières années devraient être considérées comme une phase de croissance, durant laquelle nous avons exploré de nombreuses idées et observé lesquelles fonctionnaient, lesquelles étaient utiles, et lesquelles ne fonctionnaient pas. Nous devrions faire en sorte d'éviter que les éléments inutiles ne deviennent un fardeau permanent pour le protocole Ethereum.