Le véritable défi d'Ethereum : la résilience de l'infrastructure plutôt que l'optimisation du rendement

Source : CryptoNewsNet Titre original : Ethereum n’est pas à la recherche d’un rendement de 5,3 %, dit Vitalik — mais le risque de panne est plus de 5× supérieur aux chocs réglementaires Lien original : Ethereum n’a pas été créé pour rendre la finance efficace ou les applications pratiques. Il a été conçu pour libérer les gens.

Cette phrase du Manifeste Trustless a suscité des critiques lors de sa publication, et Vitalik Buterin l’a répétée le 5 janvier.

L’argument : La mission d’Ethereum diffère fondamentalement du jeu d’efficacité dans lequel les protocoles DeFi rivalisent. L’objectif n’est pas un rendement de 4,5 % contre 5,3 %, ni réduire la latence de 473 millisecondes à 368, ni réduire le nombre de clics pour s’inscrire de trois à un.

Le jeu d’Ethereum est la résilience : éviter les pertes totales lorsque l’infrastructure s’effondre, que les gouvernements deviennent hostiles ou que les développeurs disparaissent. La résilience signifie maintenir une latence de 2 000 millisecondes à 2 000 millisecondes, même lorsque Cloudflare échoue, que les sponsors font faillite ou que les utilisateurs sont déplatformés.

La résilience, c’est rester un participant de premier ordre, quelle que soit la géographie ou la politique.

Cela importe car Ethereum ancre près de $74 milliard de valeur de contrats intelligents dans sa couche-1 seulement, et plus de 65 % des actifs du monde réel tokenisés.

Pourtant, le système conçu pour être l’ordinateur mondial repose sur une pile étonnamment fragile de points de congestion centralisés.

Le protocole de consensus continuait de finaliser des blocs, mais le client RPC obsolète du fournisseur a causé des crashs d’échanges. La blockchain continuait de fonctionner, mais le CDN est tombé en panne, mettant hors ligne la moitié de l’écosystème.

Évitement de catastrophe plutôt qu’optimisation du rendement

Un rapport récent quantifie les enjeux : les défaillances d’infrastructure produisent des chocs de volatilité 5,7 fois plus importants que les annonces réglementaires sur les principales crypto-monnaies. Le risque extrême de perte totale d’accès, de verrouillage permanent des fonds et d’arrêt du réseau est plus important que les rendements incrémentiels.

Un protocole offrant un rendement de 5,3 % est sans valeur si une erreur de configuration peut détruire l’infrastructure.

La vision de Vitalik Buterin illustre cela. La résilience ne concerne pas la vitesse quand tout fonctionne, mais si votre application fonctionne du tout lorsque les fournisseurs d’infrastructure disparaissent ou que les plateformes d’hébergement déplatforment les utilisateurs.

La latence de 2 000 millisecondes qu’Ethereum offre peut être plus lente que Web2, mais elle continue de fonctionner même lorsque les systèmes Web2 s’arrêtent complètement.

Cependant, la promesse de résilience d’Ethereum doit faire face à des tests pratiques.

En novembre 2020, Infura, le fournisseur RPC par défaut pour MetaMask et la plupart des applications DeFi, utilisait un client Geth obsolète qui divergeait de la chaîne canonique.

Les échanges ont suspendu les retraits ETH, les explorateurs montraient des états conflictuels, et MakerDAO et Uniswap ont été interrompus pour les utilisateurs.

Bien que le bug ait été corrigé et que des progrès soient réalisés sur d’autres implémentations RPC, la centralisation reste la norme. Elle est simplement moins infura-only et plus « petit cartel ».

Le protocole a fonctionné, mais les points d’attachement ont échoué.

En novembre 2025, une erreur de configuration de Cloudflare a coupé environ 20 % du trafic web, y compris Arbiscan, DefiLlama, et plusieurs interfaces d’échange et DeFi. Ethereum a continué de traiter les blocs. Les utilisateurs n’ont pas pu y accéder.

Pendant la folie des inscriptions de 2024, le séquenceur unique d’Arbitrum a été bloqué pendant 78 minutes. Aucune transaction n’a été traitée, aucun lot n’a été publié sur Ethereum.

Arbitrum, Optimism, Base et zkSync dépendent tous actuellement d’un seul séquenceur centralisé. La couche de base décentralisée a fonctionné correctement, mais l’infrastructure centralisée a empêché les utilisateurs d’en bénéficier.