Pourquoi l’architecture Ethereum est défectueuse | par Hugo Nguyen

Bitcoin n’est pas magique. Cela sacrifie toutes sortes d’efficacités, ce qui va à l’encontre de notre intuition et de nos « meilleures pratiques », afin de nous offrir quelque chose de spécial.

Bitcoin est particulièrement inefficace dans 2 dimensions :

• Il exige que le taux de blocs produits soit lent
• Il utilise la communication diffusée

Pour souligner à quel point cela est contre-intuitif. À quelle fréquence :

• Rendre volontairement un travail plus lent, même si vous avez trouvé un moyen de le rendre plus rapide ?
• Parlez à tous ceux que vous connaissez de tout ce que vous avez fait, chaque minute de la journée ?

Faire cela dans un environnement réseau est encore plus insensé. Non seulement vous êtes lent, mais tout le monde doit être lent. Non seulement vous criez après tout le monde, mais tout le monde crie après tout le monde.

De plus, ce réseau compte des centaines de milliers de membres. Si vous avez en tête un asile de fous géant, vous avez la bonne image mentale.

Faire les choses à la manière du Bitcoin est littéralement insensé, dans la plupart des contextes.

Il s’avère qu’être extrêmement inefficace a ses avantages. En forçant intentionnellement les choses à être lentes, Bitcoin rend la triche coûteuse. En utilisant la communication par diffusion, il minimise le besoin de faire confiance à des membres individuels (ou maximise la tolérance aux pannes, en termes informatiques).

En effectuant à la fois des blocages lents et des communications diffusées, Bitcoin résout le problème des généraux byzantins. Une énorme avancée en informatique.

Mais faire les choses à la manière de Bitcoin a un coût élevé. Il trace une ligne ténue entre l’éclat et l’inutilité. Les systèmes blockchain fonctionnent bien tant que les données qui les traversent augmentent à un rythme gérable.

Un taux de croissance des données tout sauf linéaire est insoutenable et constitue une certaine condamnation à mort. La croissance non linéaire des données tuera rapidement les nœuds individuels un par un et ramènera inévitablement le système à un modèle moins minimisé en matière de confiance.

Comme les systèmes blockchain sont déjà extrêmement inefficaces, il n’y a pas grand-chose sur quoi s’appuyer si les données augmentent trop rapidement. Les systèmes blockchain, tels qu’ils sont, marchent sur une glace très mince.

Donc lorsqu’il s’agit de données blockchain, vous devez être impitoyablement efficace. Il s’agit de compenser l’inefficacité maximale dans les domaines mentionnés ci-dessus.

C’est précisément pourquoi l’architecture « riche en état » d’Ethereum est une si mauvaise idée. Les états Ethereum sont nécessaires uniquement à des fins de calcul, mais ils croissent à un rythme ingérable.

Les décisions de conception d’Ethereum sont encore plus discutables lorsque les raisons d’adopter des États riches au niveau central sont vagues et douteuses.

Pour simuler la complétude de Turing ? Il ne peut y avoir de véritable exhaustivité de Turing sur les blockchains, car tous les programmes doivent être arrêtés d’une manière ou d’une autre. Donc « Turing-complet » est un véritable gadget. Vitalik lui-même l’a admis.

Pour faciliter la rédaction de contrats intelligents programmables ? La facilité d’utilisation est le moindre de vos soucis en matière d’ingénierie blockchain. Priorités rétrogrades. N’oubliez pas qu’avec les blockchains, vous marchez déjà sur de la glace, sans ajouter d’États riches.

Alors pourquoi ? Prendre en charge des calculs autrement impossibles avec des scripts de style Bitcoin seuls ? Pas vraiment. Tous les calculs pouvant être effectués avec les contrats intelligents Ethereum peuvent être effectués sur Bitcoin, uniquement à un niveau supérieur.

Et c’est là le nœud du problème. Ethereum résout les problèmes au mauvais niveau et, ce faisant, gonfle inutilement sa conception de base.

Retarder les choses en espérant que les problèmes difficiles se résoudront d’eux-mêmes n’est pas non plus une solution. Le partage n’est pas la solution, car le partage implique une réduction du niveau de communication de diffusion, ce qui est une fonctionnalité dans le contexte des blockchainspas un bug !

Placer tout espoir dans le sharding en tant que panacée magique caractérise l’attitude d’Ethereum envers l’ingénierie : Hopium.

Les problèmes d’Ethereum sont encore plus graves si l’on considère que Bitcoin, bien qu’il soit extrêmement conservateur quant au type de données et à la croissance des données qu’il traite, a encore de réelles chances d’échec. À mon humble avis, Bitcoin est encore une expérience.

Si vous avez lu mon récent article sur le système d’incitation de Bitcoin, vous remarquerez que j’ai laissé quelques questions ouvertes dont je ne connais toujours pas les réponses. Je suis optimiste sur Bitcoin, mais prudemment optimiste.

Pour récapituler : Bitcoin pousse déjà les choses à l’extrême pour obtenir quelque chose d’utile. Malgré cela, son succès n’est pas garanti. Ethereum va beaucoup plus loin, sans avoir de bonnes justifications. L’architecture d’Ethereum est défectueuse dès le départ pour cette raison.

Encore quelques mots sur le côté ingénierie des choses. L’histoire d’Ethereum n’est en réalité pas rare. Nous avons déjà vu ce film :

• RISC contre CISC dans les années 70
• Linux contre Windows dans les années 90

Dans ces épisodes, nous avons appris que le matériel et les logiciels fonctionnent mieux lorsqu’ils sont construits sous forme de couches simples et modulaires, illustrées par RISC et Linux (un autre exemple est TCP/IP). La raison en est que ces systèmes ont tendance à être plus flexibles, plus élégants et peuvent s’adapter plus facilement aux environnements/cas d’utilisation changeants.

Cette idée est immortalisée dans la philosophie de conception Unix : « La flexibilité, la simplicité et la liberté sont les principales considérations ».

La philosophie de conception Unix bénéficie également de la confiance de la nature. Les colonies de fourmis font preuve d’une intelligence émergente même si individuellement, les fourmis sont stupides et hautement spécialisées. De la même manière, notre cerveau est composé de neurones simples qui effectuent individuellement des tâches simples.

L’approche de l’évier de cuisine d’Ethereum au niveau de la couche centrale ressemble à l’idée d’un ensemble d’instructions complexe. Ou l’idée de créer un logiciel à partir de composants volumineux et complexes, au lieu de composants plus petits et plus spécialisés. La complexité pour la complexité, pas par l’émergence.

En résumé, Ethereum a pris des décisions de conception douteuses sans justification solide. Nous avons également déjà constaté des erreurs d’ingénierie similaires à celles d’Ethereum. Je suppose qu’Ethereum sera finalement une autre leçon de ce qu’il ne faut pas faire dans le livre d’histoire.

• J’utilise « systèmes blockchain » pour faire référence aux blockchains de type Bitcoin qui sont basées sur une preuve de travail.
• Lecture supplémentaire : Gregory Maxwell a expliqué la vérification et non le calcul ici. Ci-dessous un extrait.

Bob McElrath a également décrit le problème ici.