1kx : La solution ultime à l'extensibilité de la blockchain repose sur la minimisation de la confiance et l'évolutivité horizontale
TechFlow SélectionTechFlow Sélection
1kx : La solution ultime à l'extensibilité de la blockchain repose sur la minimisation de la confiance et l'évolutivité horizontale
Pour étendre réellement les systèmes minimisant la confiance à chaque recoin de la planète, il est nécessaire de construire des systèmes à la fois minimisant la confiance et horizontalement évolutifs.
Dédié à des analyses Web3 approfondiesRédaction : weidai.eth
Traduction : Luffy, Foresight News
Ethereum est un ordinateur mondial sans autorisation. Au moment de la rédaction de cet article, il dispose du niveau de sécurité économique le plus élevé et sert de registre de règlement pour une vaste gamme d'actifs, d'applications et de services. Ethereum présente toutefois des limites : l'espace dans les blocs constitue une ressource rare et coûteuse sur le réseau principal d'Ethereum. Le scaling en couche 2 (L2) est considéré comme la meilleure solution à ce problème, et ces dernières années, un grand nombre de projets sont entrés sur ce créneau, dont la majorité sont des rollups. Cependant, même en respectant strictement la définition technique du terme « rollup » (données publiées sur Ethereum L1), on ne peut pas atteindre une scalabilité infinie d’Ethereum — sa limite supérieure se situe autour de quelques milliers de transactions par seconde.
Tout d'abord, présentons deux concepts clés :
-
Minimisation de la confiance : Si une fonctionnalité d’un système L2 ne nécessite aucune confiance au-delà de celle accordée à la couche L1 sous-jacente, alors cette fonctionnalité est dite « minimalement fiable ».
-
Extensibilité horizontale : Un système est dit extensible horizontalement s’il est possible d’y ajouter de nouvelles instances sans créer de goulot d’étranglement global.
Dans cet article, nous estimons que les systèmes combinant minimisation de la confiance et extensibilité horizontale constituent la voie la plus prometteuse pour développer les applications blockchain, bien que cette direction soit encore insuffisamment explorée. Nous développons notre argumentaire en examinant trois questions fondamentales :
-
Pourquoi les applications devraient-elles être minimalement fiables ?
-
Pourquoi construire des systèmes extensibles horizontalement ?
-
Comment renforcer davantage la minimisation de la confiance et l’extensibilité horizontale ?
Remarque : Bien que cet article mette l’accent principalement sur Ethereum en tant que couche L1 de base, la plupart des éléments abordés ici s’appliquent également à d’autres couches de règlement décentralisées situées en dehors d’Ethereum.
Pourquoi les applications devraient-elles être minimalement fiables ?
Les applications peuvent interagir avec Ethereum de manière fiable : elles peuvent écrire et lire des données sur la blockchain Ethereum, mais la confiance porte alors sur l’exécution correcte de la logique métier. Les échanges centralisés tels que Binance ou Coinbase sont d'excellents exemples d'applications fiables. Se connecter à Ethereum permet à une application d'utiliser un réseau de règlement mondial disposant de nombreux actifs.
Les services hors chaîne (off-chain) soumis à confiance comportent des risques importants. L'effondrement en 2022 de grands échanges et fournisseurs de services (par exemple FTX et Celsius) illustre parfaitement ce qui peut arriver lorsque des services fiables se comportent mal ou échouent.
En revanche, les applications minimalement fiables peuvent lire et écrire sur Ethereum de manière vérifiable, comme les applications basées sur contrats intelligents telles qu'Uniswap, les rollups tels qu'Arbitrum ou zkSync, ou encore les coprocesseurs comme Lagrange et Axiom. De façon générale, à mesure que les applications bénéficient de la protection du réseau Ethereum et que davantage de fonctionnalités sont déléguées à la L1, la nécessité de faire confiance diminue. Ainsi, des services financiers peuvent être proposés sans risque de contrepartie ni de dépôt.
En externalisant certaines fonctionnalités vers la L1, les applications et services acquièrent trois propriétés essentielles :
-
Vivacité (et ordonnancement) : les transactions soumises par les utilisateurs doivent être incluses rapidement (exécutées et réglées).
-
Validité : les transactions sont traitées conformément à des règles prédéfinies.
-
Disponibilité des données (et de l’état) : les utilisateurs ont accès aux données historiques ainsi qu’à l’état courant de l’application.
Pour chacune de ces propriétés, on peut identifier les hypothèses de confiance requises ; en particulier, savoir si la couche L1 d’Ethereum fournit ou non cette propriété, ou si une confiance externe est nécessaire. Le tableau ci-dessous classe différents paradigmes architecturaux selon ces critères.
Pourquoi construire des systèmes extensibles horizontalement ?
L’extensibilité horizontale consiste à étendre un système en ajoutant des instances indépendantes ou parallèles, comme des applications ou des rollups. Cela suppose qu’aucun goulot d’étranglement global n’existe dans le système. L’extensibilité horizontale permet une croissance exponentielle du débit du système.
L’extensibilité verticale consiste à augmenter le débit du système global (par exemple la couche L1 d’Ethereum ou une couche de disponibilité des données). Elle est souvent nécessaire lorsque l’extensibilité horizontale rencontre un goulot d’étranglement lié à des ressources partagées.
Affirmation 1 : Les rollups ne peuvent pas s’étendre horizontalement car ils peuvent rencontrer un goulot d’étranglement au niveau de la disponibilité des données (DA). Une solution DA verticalement évolutive implique généralement des compromis en matière de décentralisation.
La disponibilité des données (DA) reste le goulot d’étranglement des rollups. Actuellement, la capacité maximale cible par bloc L1 est de 1 Mo (85 Ko/s). À long terme, EIP-4844 offrira environ 2 Mo supplémentaires (171 Ko/s) d’espace disponible. Grâce à Danksharding, la bande passante DA de la L1 d’Ethereum pourrait finalement atteindre jusqu’à 1,3 Mo/s. La DA de la L1 d’Ethereum est une ressource convoitée par de nombreuses applications et services. Par conséquent, bien que l’utilisation de la L1 comme couche DA offre la meilleure sécurité, elle devient un goulot d’étranglement potentiel pour la scalabilité globale du système. Les systèmes utilisant la L1 comme couche DA ne peuvent généralement pas s’étendre horizontalement et souffrent d’une économie d’échelle inverse. Les couches alternatives de disponibilité des données, telles que Celestia ou EigenDA, ont également des limites de bande passante (bien que plus élevées, respectivement 6,67 Mo/s et 15 Mo/s), mais cela se fait au prix d’un transfert des hypothèses de confiance depuis Ethereum vers un autre réseau, généralement moins décentralisé, ce qui nuit à la sécurité.
Affirmation 2 : La seule façon d’étendre horizontalement des services minimalement fiables consiste à atteindre (ou s’approcher) d’un volume marginal de données L1 proche de zéro par transaction. Deux méthodes connues permettent cela : les rollups par différence d’état (SDR) et les validiums.
Un rollup par différence d’état (SDR) est un rollup qui publie sur la L1 d’Ethereum uniquement les différences d’état issues d’un lot agrégé de transactions. Pour l’EVM, à mesure que la taille des lots augmente, les données publiées par transaction sur la L1 tendent vers une constante très inférieure aux données complètes de chaque transaction du rollup.
Par exemple, lors d’un test de charge massif causé par l’afflux d’inscriptions, zkSync a observé une réduction du calldata à seulement 10 octets par transaction. En comparaison, sous trafic normal, les rollups comme Arbitrum, Optimism et Polygon zkEVM nécessitent environ 100 octets par transaction.
Un validium est un système qui publie sur Ethereum une preuve de validité de la transition d’état, sans inclure les données associées des transactions ni l’état lui-même. Même sous faible trafic, un validium possède une grande extensibilité horizontale. En outre, plusieurs validiums peuvent partager la même couche de règlement.
Outre l’extensibilité horizontale, les validiums peuvent offrir une confidentialité en chaîne (vis-à-vis des observateurs publics). Un validium doté d'une DA privée possède une disponibilité des données et de l’état centralisée et contrôlée : les utilisateurs doivent s’authentifier avant d’accéder aux données, et l’opérateur peut appliquer des mesures rigoureuses de protection de la vie privée. Cela reproduit une expérience utilisateur similaire à celle des services web ou financiers traditionnels : les activités des utilisateurs ne sont pas surveillées publiquement, mais un tiers de confiance (l’opérateur du validium) détient leurs données.
Qu’en est-il des séquenceurs centralisés versus décentralisés ? Pour préserver l’extensibilité horizontale du système, des séquenceurs indépendants (qu’ils soient centralisés ou décentralisés) sont essentiels. Notons que bien que les systèmes utilisant un séquenceur partagé offrent une composable atomique, ils ne peuvent pas s’étendre horizontalement, car le séquenceur peut devenir un goulot d’étranglement à mesure que de nouveaux systèmes sont ajoutés.
Et l’interopérabilité ? Si les systèmes extensibles horizontalement se règlent tous sur la même L1, ils peuvent interagir sans confiance supplémentaire, car les messages peuvent être transmis d’un système à l’autre via la couche de règlement partagée. Un compromis existe entre coût opérationnel et délai de transmission des messages (ce qui peut être résolu au niveau applicatif).
Minimisation de la confiance dans les systèmes extensibles horizontalement
Pouvons-nous aller plus loin dans la réduction des hypothèses de confiance relatives à la vivacité, au séquenceur et à la disponibilité des données dans les systèmes extensibles horizontalement ?
Il convient de noter qu’au prix d’une perte partielle d’extensibilité horizontale, nous savons comment restaurer la vivacité et la disponibilité des données sans confiance. Par exemple, les transactions L2 peuvent être initiées depuis la L1 afin de garantir leur inclusion. Un modèle Volition peut permettre aux utilisateurs de choisir volontairement une disponibilité d’état sur L1.
Une autre approche consiste à simplement décentraliser (sans dépendre de la L1). En remplaçant un seul séquenceur par un séquenceur décentralisé (comme Espresso Systems ou Astria), le système gagne en décentralisation, réduisant ainsi la confiance requise pour la vivacité, l’ordonnancement et la disponibilité des données. Cette approche comporte néanmoins certaines limitations par rapport aux solutions à opérateur unique : (1) les performances peuvent être limitées par celles des systèmes distribués, (2) pour les validiums à DA privée, la confidentialité par défaut est perdue si le réseau de séquenceurs décentralisés est sans permission.
Pour les validiums ou SDR à opérateur unique, quelles autres réductions de la confiance sont envisageables ? Plusieurs directions sont possibles.
Direction 1 : Disponibilité des données minimalement fiable dans les validiums. Plasma résout partiellement le problème de disponibilité d’état, soit en traitant les retraits pour certains modèles d’état spécifiques (notamment le modèle UTXO), soit en exigeant que les utilisateurs soient régulièrement en ligne (Plasma Free).
Direction 2 : Pré-validation responsable dans les SDR et validiums. L’objectif est de fournir aux utilisateurs une pré-confirmation rapide de l’inclusion d’une transaction par le séquenceur, tout en permettant de contester cette inclusion si elle n’est pas honorée, avec une sanction économique (slashing) du séquenceur. Le défi ici est de prouver qu’une transaction n’a pas été incluse, ce qui peut nécessiter que l’utilisateur fournisse des données supplémentaires que le séquenceur pourrait simplement refuser de divulguer. Il est donc raisonnable de supposer qu’un SDR ou un validium doit employer un comité de disponibilité des données capable de produire, sur demande de l’utilisateur, une preuve d’absence d’inclusion (pour une transaction pré-validée).
Direction 3 : Récupération rapide après défaillance de vivacité. Les systèmes à opérateur unique peuvent connaître des pannes de vivacité (par exemple Arbitrum pendant l’événement des inscriptions). Pouvons-nous concevoir un système qui évite l’interruption de service dans de telles situations ? Dans un certain sens, les L2 permettant l’auto-ordonnancement et la proposition d’état offrent une garantie contre les pannes de vivacité à long terme. Les systèmes à opérateur unique résilients face aux pannes de vivacité à court terme restent largement inexplorés. Une solution potentielle serait d’imposer un slashing en cas de défaillance de vivacité. Une autre option pourrait être de simplement raccourcir le délai de prise en charge (actuellement fixé à environ une semaine).
Conclusion
Étendre un registre mondial de règlement tout en maintenant une confiance minimale est un défi majeur. Dans les domaines actuels des rollups et de la disponibilité des données, la distinction entre extension verticale et horizontale n’est pas encore nettement établie. Pour vraiment étendre les systèmes minimalement fiables à chaque coin de la planète, nous devons construire des systèmes à la fois minimalement fiables et extensibles horizontalement.
Merci à Vitalik Buterin et Terry Chung pour leurs retours et discussions, ainsi qu’à Diana Biggs pour ses commentaires d’édition.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
1kx
