Ethereum est un ordinateur mondial sans permission qui possède(sans doute) le plus haut niveau de sécurité économique au moment où nous écrivons ces lignes, agissant comme un grand livre de comptes pour un grand nombre d'actifs, d'applications et de services. Ethereum a ses limites : l'espace de blocs est une ressource rare et coûteuse sur la première couche d'Ethereum (L1). La mise à l'échelle de la couche deux (L2) a été considérée comme la solution à ce problème, et de nombreux projets ont été lancés sur le marché ces dernières années, principalement sous la forme de rollups. Toutefois, les rollups, au sens strict du terme (c'est-à-dire que les données du rollup se trouvent sur Ethereum L1), ne permettent pas à Ethereum d'évoluer indéfiniment, puisqu'ils n'autorisent que quelques milliers de transactions par seconde.

Confiance minimisée - (une caractéristique) d'un système L2 est une confiance minimisée si elle fonctionne sans nécessiter de confiance externe à la base L1.

Évolution horizontale - un système est évolutif horizontalement si des instances peuvent être ajoutées sans imposer de goulots d'étranglement globaux.

Dans cet article, nous soutenons que les systèmes minimisant la confiance et évolutifs horizontalement sont la manière la plus prometteuse de mettre à l'échelle les applications de la blockchain, bien qu'ils soient actuellement sous-explorés. Nous présentons l'argument en explorant trois questions :

1. Pourquoi faut-il limiter la confiance dans les applications ?
2. Pourquoi construire des systèmes extensibles horizontalement ?
3. Comment maximiser à la fois la minimisation de la confiance et l'évolutivité horizontale ?

(Avertissement : bien que nous nous concentrions sur Ethereum en tant que L1 de base dans cet article, la plupart des points abordés ici s'appliquent à des couches de règlement décentralisées autres qu'Ethereum).

Pourquoi faut-il limiter la confiance dans les applications ?

Les applications peuvent être connectées à Ethereum de manière fiable - elles peuvent écrire et lire dans la blockchain Ethereum, mais la confiance est placée sur les opérateurs pour exécuter correctement la logique commerciale. Les bourses centralisées comme Binance et Coinbase sont de bons exemples d'applications de confiance. En étant connectées à Ethereum, les applications peuvent accéder à un réseau de règlement mondial avec un ensemble diversifié d'actifs.

Les services hors chaîne de confiance comportent des risques importants. L'effondrement d'échanges et de services majeurs en 2022, tels que FTX et Celsius, est un exemple édifiant de ce qui se passe lorsque des services de confiance se comportent mal et échouent.

D'autre part, les applications dont la confiance est limitée peuvent écrire et lire sur Ethereum de manière vérifiable. Il s'agit par exemple d'applications de contrats intelligents comme Uniswap, de rollups comme Arbitrum ou zkSync, et de coprocesseurs comme Lagrange et Axiom. D'une manière générale, la confiance disparaît au fur et à mesure que les applications sont sécurisées par le réseau Ethereum et que davantage de fonctionnalités (voir ci-dessous) sont externalisées vers L1. Par conséquent, des services financiers minimisés par la confiance peuvent être offerts sans risque de contrepartie ou de dépositaire.

Les applications et les services peuvent avoir trois propriétés essentielles, qui peuvent être confiées à L1 :

1. La vivacité (et l'ordonnancement) : les transactions soumises par les utilisateurs doivent être incluses (exécutées et réglées) en temps utile.
2. Validité : les transactions sont traitées conformément à des règles prédéfinies.
3. Disponibilité des données (et de l'état) : les données historiques, ainsi que l'état actuel de l'application, sont accessibles à l'utilisateur.

Pour chacune des propriétés susmentionnées, nous pouvons nous demander quelle est l'hypothèse de confiance requise ; en particulier, Eth L1 fournit-elle la propriété ou une confiance externe est-elle nécessaire. Le tableau ci-dessous classe ces éléments en fonction des différents paradigmes d'architecture.

Pourquoi construire des systèmes extensibles horizontalement ?

La mise à l'échelle horizontale fait référence à la mise à l'échelle par l'ajout d'instances indépendantes ou parallèles d'un système, par exemple ou un rollup. Pour cela, il faut qu'il n'y ait pas de goulot d'étranglement au niveau mondial. La mise à l'échelle horizontale permet et facilite la croissance exponentielle.

La mise à l'échelle verticale fait référence à la mise à l'échelle via l'augmentation du débit d'un système monolithique, tel que Eth L1 ou une couche de disponibilité des données. Lorsque la mise à l'échelle horizontale se heurte à des goulets d'étranglement sur une telle ressource partagée, une mise à l'échelle verticale est souvent nécessaire.

Affirmation 1 : Les rollups (de données transactionnelles) ne peuvent pas évoluer horizontalement parce qu'ils peuvent être bloqués par la disponibilité des données (DA). Les solutions d'AD à échelle verticale exigent des compromis en matière de décentralisation.

La disponibilité des données (DA) reste le goulot d'étranglement des rollups. Actuellement, chaque bloc L1 a un objectif de taille maximale d'environ 1 Mo (85 Ko/s). Avec l'EIP-4844, ~2 MB (171 KB/s) supplémentaires seront mis à disposition (à long terme). Avec le Danksharding, Eth L1 peut éventuellement prendre en charge jusqu'à 1,3 Mo/s de bande passante DA. Eth L1 DA est une ressource partagée que de nombreuses applications & services se disputent. Par conséquent, bien que l'utilisation de L1 pour la DA offre la meilleure sécurité, elle gêne l'extensibilité potentielle de ces systèmes. Les systèmes qui utilisent L1 pour l'AD ne seront (généralement) pas en mesure d'évoluer horizontalement et présenteront des déséconomies d'échelle. Les couches DA alternatives, telles que Celestia ou EigenDA, ont également des limites de bande passante (bien qu'elles soient plus importantes, à savoir 6,67 Mo/s et 15 Mo/s, respectivement). Mais cela se fait au prix d'un déplacement de l'hypothèse de confiance d'Ethereum vers un autre réseau (souvent moins décentralisé), ce qui compromet la sécurité (économique).

Affirmation 2 : Le seul moyen de faire évoluer horizontalement les services à confiance minimale est d'obtenir (presque) zéro donnée marginale L1 par transaction. Les deux approches connues sont les rollups état-diff (SDR) et les validiums.

Les rollups de différences d'état (SDR) sont des rollups qui affichent les différences d'état d'un lot agrégé de transactions sur Ethereum L1. Pour l'EVM, au fur et à mesure que les lots de transactions augmentent, les données par transaction affichées sur L1 diminuent jusqu'à une constante qui est beaucoup plus petite que celle des rollups de données de transaction.

Par exemple, lors d'un test de stress avec un afflux important d'inscriptions, zkSync a constaté une réduction des données d'appel par transaction jusqu'à 10 octets par transaction. En revanche, les rollups de données transactionnelles comme Arbitrum, Optimism et Polygon zkEVM, voient typiquement autour de 100 octets par transaction pour un trafic normal.

Un validium est un système qui publie des preuves de validité des transitions d'état sur Ethereum, sans données de transaction ou d'état associées. Les validiums sont hautement évolutifs horizontalement, même dans des conditions de faible trafic. Cela est d'autant plus vrai que le règlement des différents validiums peut être agrégé.

Outre l'évolutivité horizontale, un validium peut également assurer la confidentialité de la chaîne (vis-à-vis des observateurs publics). Un validium avec DA privée dispose de données et d'états centralisés et contrôlés, ce qui signifie que les utilisateurs doivent s'authentifier avant d'accéder aux données et que l'opérateur peut mettre en œuvre de bonnes mesures de protection de la vie privée. Les activités de l'utilisateur sont dissimulées au public, mais les données de l'utilisateur sont conservées par un gardien de confiance, en l'occurrence l'opérateur du validium.

Qu'en est-il des séquenceurs centralisés ou décentralisés ? Pour que les systèmes puissent évoluer horizontalement, il est essentiel d'instancier des séquenceurs indépendants, qu'ils soient centralisés ou décentralisés. Notamment, bien que les systèmes utilisant des séquenceurs partagés bénéficient d'une <a href="https://hackmd.io/@EspressoSystems/SharedSequencing"> composabilité, ils ne peuvent pas évoluer horizontalement, car le séquenceur peut devenir un goulot d'étranglement au fur et à mesure que d'autres systèmes sont ajoutés.

Qu'en est-il de l'interopérabilité ? Les systèmes évolutifs horizontalement peuvent interagir sans confiance supplémentaire s'ils se règlent tous sur la même L1, car les messages peuvent être envoyés d'un système à l'autre par l'intermédiaire de la couche de règlement partagée. Il existe un compromis entre le coût d'exploitation et le délai de transmission des messages (qui peut éventuellement être résolu au niveau de l'application).

Minimisation de la confiance pour les systèmes extensibles horizontalement

Est-il possible de réduire davantage les exigences de confiance en matière de disponibilité, d'ordonnancement et de disponibilité des données dans les systèmes horizontalement extensibles ?

Il convient de noter qu'au prix de l'extensibilité horizontale, nous savons comment sauver l'intégrité et la disponibilité des données. Par exemple, les transactions L2 peuvent être initiées à partir de L1 pour une inclusion garantie. Volition peut offrir aux utilisateurs la possibilité d'accéder à l'état L1.

Une autre solution consiste à décentraliser tout simplement (sans s'appuyer sur la L1). Au lieu d'un séquenceur unique, les systèmes pourraient devenir plus décentralisés en utilisant des séquenceurs décentralisés (tels que Espresso Systems ou Astria), ce qui minimiserait la confiance requise pour la vivacité, l'ordonnancement et la disponibilité des données. Cette approche présente des limites par rapport aux solutions à opérateur unique : (1) les performances peuvent être limitées par les performances du système distribué, et (2) pour les validiums avec DA privée, la garantie de confidentialité par défaut est perdue si le réseau de séquenceurs décentralisés est sans permission.

Quel degré de confiance pouvons-nous minimiser en plus pour les validiums à opérateur unique ou SDR ? Il y a plusieurs directions ouvertes ici.

Orientation ouverte 1 : disponibilité des données en toute confiance dans les validiums. Plasma résout le problème de la disponibilité de l'état dans une certaine mesure - il résout le problème soit pour les retraits uniquement pour certains modèles d'état (ce qui inclut le modèle d'état UTXO), soit en exigeant que les utilisateurs soient en ligne périodiquement(Plasma Free).

Orientation 2 : Préconfirmations responsables dans les DTS et les validiums. L'objectif est ici de fournir aux utilisateurs une pré-confirmation rapide de l'inclusion d'une transaction par un séquenceur, et la confirmation devrait permettre à l'utilisateur de contester et de réduire l'enjeu économique du séquenceur si la promesse d'inclusion n'est pas tenue. La difficulté réside dans le fait que la preuve de la non-inclusion (nécessaire pour le découpage) nécessite probablement des données supplémentaires pour l'utilisateur, qu'un séquenceur peut simplement refuser. Par conséquent, il est raisonnable de supposer que nous exigeons au moins que le DTS ou le validium fasse appel à un comité de disponibilité des données (éventuellement autorisé) pour l'ensemble de ses données d'appel ou de son historique de transactions, ce qui permet à ce même comité de fournir la preuve de la non-inclusion (des transactions pré-confirmées) à la demande d'un utilisateur.

Direction ouverte 3 : Récupération rapide en cas de défaillance de la sensibilité. Les systèmes à opérateur unique peuvent souffrir d'un manque de réactivité (par ex. Arbitrum a été mis hors ligne pendant l'événement d'inscription). Pouvons-nous concevoir des systèmes qui assurent une interruption minimale des services dans ce scénario ? Dans un certain sens, les L2 qui autorisent l'auto-séquence et les propositions d'état fournissent des garanties contre les défaillances prolongées de la permanence. La conception de systèmes à opérateur unique plus résistants aux défaillances de courte durée est actuellement sous-explorée. Une solution potentielle consiste à responsabiliser les défaillances en matière de respect des délais, en prévoyant une réduction des frais pour les défaillances en matière de respect des délais. Une autre solution potentielle consiste à raccourcir simplement le délai (qui est actuellement fixé à environ une semaine) avant qu'une prise de contrôle puisse avoir lieu.

Conclusion

La mise à l'échelle d'un grand livre de règlement mondial tout en maintenant la minimisation de la confiance est un problème difficile. Il n'y a pas eu de distinction claire entre l'échelonnement vertical et l'échelonnement horizontal dans le monde du rollup et de la disponibilité des données aujourd'hui. Pour que tous les habitants de la planète puissent bénéficier de systèmes minimisant la confiance, nous devons construire des systèmes minimisant la confiance et évolutifs sur le plan horizontal.

Remerciements

Nous remercions Vitalik Buterin et Terry Chung pour leurs commentaires et leurs discussions, ainsi que Diana Biggs pour ses commentaires éditoriaux.

声明：

Clause de non-responsabilité：

1. Cet article est repris de[Mirror]. Tous les droits d'auteur appartiennent à l'auteur original[1kx]. Si vous avez des objections à cette réimpression, veuillez contacter l'équipe de Gate Learn, qui s'en chargera rapidement.
2. Clause de non-responsabilité : Les points de vue et les opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.