Les compromis de l'évolutivité de la Blockchain : Le chemin de l'équilibre entre Polkadot et Web3

Dans un monde où la Blockchain cherche constamment à atteindre une plus grande efficacité, une question clé commence à émerger : lors de l'amélioration des performances d'extension, doit-on nécessairement sacrifier la sécurité et la résilience du système ? Cela représente non seulement un défi sur le plan technique, mais également un choix profond en matière de conception d'architecture. Pour l'écosystème Web3, un système plus rapide, s'il repose sur le sacrifice de la confiance et de la sécurité, a souvent du mal à soutenir une véritable innovation durable.

En tant qu'acteur clé de l'évolutivité Web3, le modèle rollup de Polkadot a-t-il fait des concessions en matière de décentralisation, de sécurité ou d'interopérabilité du réseau ? Cet article analysera en profondeur les compromis et les arbitrages de Polkadot dans la conception de l'évolutivité, et les comparera aux solutions d'autres chaînes publiques majeures, en explorant leurs choix de chemins différents entre performance, sécurité et décentralisation.

Les défis auxquels est confronté le design d'extension de Polkadot

L'équilibre entre l'élasticité et la décentralisation

L'architecture de Polkadot repose sur un réseau de validateurs et sur la chaîne relais (Relay Chain). Cela pourrait-il introduire des risques de centralisation dans certains aspects ? Existe-t-il un risque de point de défaillance unique ou de contrôle, ce qui affecterait ses caractéristiques de décentralisation ?

Le fonctionnement des Rollups dépend de l'ordonnanceur de la chaîne de relais connecté ( sequencer ), dont la communication utilise un mécanisme appelé protocole collator. Ce protocole est entièrement sans permission et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de chaîne de relais et soumettre des demandes de transition d'état des rollups. Ces demandes seront validées par un core de la chaîne de relais, à condition qu'elles respectent un prérequis : elles doivent être des transitions d'état valides, sinon l'état du rollup ne sera pas avancé.

compromis d'extension verticale

Le Rollup peut réaliser une scalabilité verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité "Elastic Scaling"(Elastic Scaling). Au cours du processus de conception, nous avons découvert que, puisque la validation des blocs de rollup n'est pas fixée sur un core particulier, cela pourrait affecter sa flexibilité.

Comme le protocole de soumission de blocs à la chaîne de relais est sans autorisation et sans confiance, tout le monde peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. Les attaquants pourraient en profiter pour soumettre à plusieurs reprises des blocs légitimes déjà vérifiés à différents cores, consommant ainsi malicieusement des ressources et réduisant le débit et l'efficacité globaux du rollup.

L'objectif de Polkadot est de maintenir la flexibilité des rollups et l'utilisation efficace des ressources de la chaîne de relais, sans compromettre les caractéristiques clés du système.

Sequencer est-il fiable ?

Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut aux ordonnanceurs qui ne se comportent pas de manière malveillante, afin d'assurer l'activité du rollup.

Cependant, dans la philosophie de conception de Polkadot, nous ne pouvons faire aucune hypothèse de confiance sur le sequencer, car il est nécessaire de maintenir les caractéristiques "sans confiance" et "sans autorisation" du système. Quiconque devrait pouvoir soumettre des demandes de transition d'état de rollup en utilisant le protocole collator.

Polkadot : une solution sans compromis

La solution finalement choisie par Polkadot est : confier complètement le problème à la fonction de transition d'état du rollup (Runtime). Runtime est la seule source fiable de toutes les informations de consensus, il est donc impératif de déclarer clairement sur quel cœur de Polkadot la validation doit être effectuée.

Ce design réalise une double garantie de flexibilité et de sécurité. Polkadot réexécutera les transitions d'état des rollups dans le processus de disponibilité et garantira l'exactitude de l'allocation des cores grâce au protocole économique cryptographique ELVES.

Avant qu'un bloc rollup ne soit écrit dans la couche de disponibilité des données de Polkadot (DA), un groupe composé d'environ 5 validateurs vérifiera d'abord sa légitimité. Ils reçoivent le reçu candidat (candidate receipt) soumis par le sélecteur et la preuve de validité (PoV), qui contient le bloc rollup et la preuve de stockage correspondante. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, réexécutées par les validateurs sur la chaîne de relais.

Le résultat de la vérification contient un sélecteur core, qui est utilisé pour spécifier sur quel core le bloc doit être vérifié. Le validateur comparera cet index avec le core dont il est responsable ; s'ils ne correspondent pas, le bloc sera rejeté.

Ce mécanisme garantit que le système conserve toujours des propriétés sans confiance et sans autorisation, évitant que des acteurs malveillants comme les ordonnanceurs ne manipulent la position de validation, garantissant que même si le rollup utilise plusieurs cœurs, il peut rester résilient.

Sécurité

Dans sa quête d'évolutivité, Polkadot n'a pas compromis la sécurité. La sécurité des rollups est garantie par la chaîne de relais, nécessitant seulement un ordonneur honnête pour maintenir la viabilité.

Grâce au protocole ELVES, Polkadot étend intégralement sa sécurité à tous les rollups, en vérifiant tous les calculs sur le core, sans avoir besoin de limiter ou de faire des hypothèses sur le nombre de cores utilisés.

Par conséquent, le rollup de Polkadot peut réaliser une véritable évolutivité sans compromettre la sécurité.

Universalité

L'extension élastique ne limitera pas la programmabilité des rollups. Le modèle de rollup de Polkadot prend en charge l'exécution de calculs Turing-complets dans un environnement WebAssembly, tant que chaque exécution est terminée en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être effectués dans chaque cycle de 6 secondes est augmentée, mais le type de calcul n'est pas affecté.

Complexité

Une plus grande capacité de traitement et une latence plus faible introduisent inévitablement de la complexité, ce qui est la seule façon d'accepter le compromis dans la conception des systèmes.

Les Rollups peuvent ajuster dynamiquement les ressources via l'interface Agile Coretime pour maintenir un niveau de sécurité cohérent. Ils doivent également mettre en œuvre certaines exigences du RFC103 pour s'adapter à différents scénarios d'utilisation.

La complexité spécifique dépend de la stratégie de gestion des ressources du rollup, qui peut dépendre de variables on-chain ou off-chain. Par exemple :

• Stratégie simple : utilisez toujours un nombre fixe de core, ou ajustez manuellement hors chaîne ;

• Stratégie légère : surveiller la charge de transaction spécifique dans le mempool des nœuds ;

• Stratégies d'automatisation : Appeler à l'avance le service coretime via les données historiques et l'interface XCM pour configurer les ressources.

Bien que l'automatisation soit plus efficace, les coûts de mise en œuvre et de test augmentent également de manière significative.

Interopérabilité

Polkadot prend en charge l'interopérabilité entre différents rollups, et l'évolutivité élastique n'affecte pas le débit de transmission des messages.

La communication des messages entre les rollups est réalisée par la couche de transport sous-jacente, l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui est attribué.

À l'avenir, Polkadot prendra également en charge la messagerie off-chain (, avec la chaîne de relais comme plan de contrôle, et non comme plan de données. Cette mise à niveau améliorera la capacité de communication entre les rollups avec une extension élastique, renforçant ainsi la capacité d'extension verticale du système.

Quels compromis ont été faits par d'autres protocoles ?

Comme tout le monde le sait, l'amélioration des performances se fait souvent au détriment de la décentralisation et de la sécurité. Mais d'un point de vue du coefficient de Nakamoto, même si certains concurrents de Polkadot ont un degré de décentralisation plus faible, leurs performances ne sont pas à la hauteur.

) Solana

Solana n'utilise pas l'architecture de sharding de Polkadot ou d'Ethereum, mais réalise l'évolutivité avec une architecture à haute capacité de traitement unique, s'appuyant sur la preuve historique ###PoH(, le traitement parallèle des CPU et un mécanisme de consensus basé sur le leader, avec un TPS théorique pouvant atteindre 65 000.

Un élément de conception clé est son mécanisme de planification des leaders, qui est préalablement public et vérifiable :

• Chaque epoch) dure environ deux jours ou 432 000 slots( au début, les slots sont attribués en fonction du montant staké ;

• Plus vous misez, plus vous recevez. Par exemple, un validateur qui mise 1 % obtiendra environ 1 % d'opportunités de bloc.

• Tous les producteurs de blocs sont annoncés à l'avance, ce qui augmente le risque de subir des attaques DDoS ciblées et des pannes fréquentes.

PoH et le traitement parallèle ont des exigences matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud a de mises en jeu, plus il a de chances de produire des blocs, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave davantage la centralisation et augmente le risque d'effondrement du système après une attaque.

Solana a sacrifié la décentralisation et la résistance aux attaques pour atteindre un TPS, son coefficient Nakamoto n'est que de 20, bien en dessous de celui de Polkadot qui est de 172.

) TON

TON prétend atteindre 104 715 TPS, mais ce chiffre a été réalisé sur un réseau de test privé, avec 256 nœuds, dans des conditions idéales de réseau et de matériel. Pendant ce temps, Polkadot a déjà atteint 128K TPS sur un réseau public décentralisé.

Le mécanisme de consensus de TON présente des risques de sécurité : l'identité des nœuds de validation de fragment peut être dévoilée à l'avance. Le livre blanc de TON indique également que cela peut optimiser la bande passante, mais peut également être exploité de manière malveillante. En raison de l'absence de mécanisme de "faillite du parieur", un attaquant peut attendre qu'un fragment soit complètement contrôlé par lui ou bloquer les validateurs honnêtes par une attaque DDoS, ce qui lui permet de falsifier l'état.

En comparaison, les validateurs de Polkadot sont attribués de manière aléatoire et révélés avec un délai, ce qui empêche les attaquants de connaître à l'avance l'identité des validateurs. Pour réussir une attaque, ils doivent parier sur le contrôle total ; tant qu'un seul validateur honnête soulève une contestation, l'attaque échouera et entraînera une perte de mise pour l'attaquant.

Avalanche

Avalanche utilise une architecture de réseau principal + sous-réseau pour l'échelle, le réseau principal est constitué de transferts X-Chain###, ~4 500 TPS(, des contrats intelligents C-Chain), ~100--200 TPS(, et la gestion des validateurs et des sous-réseaux) par le P-Chain(.

Chaque sous-réseau a un TPS théorique pouvant atteindre ~5 000, similaire à l'idée de Polkadot : réduire la charge d'un seul shard pour réaliser l'évolutivité. Cependant, Avalanche permet aux validateurs de choisir librement de participer à un sous-réseau, et les sous-réseaux peuvent imposer des exigences géographiques, KYC, etc., sacrifiant ainsi la décentralisation et la sécurité.

Dans Polkadot, tous les rollups partagent une sécurité unifiée ; tandis que les sous-réseaux d'Avalanche n'ont pas de garantie de sécurité par défaut, certains pouvant même être entièrement centralisés. Pour améliorer la sécurité, il faut néanmoins faire des compromis sur la performance, et il est difficile de fournir des promesses de sécurité déterministes.

) Ethereum

La stratégie d'extension d'Ethereum parie sur la scalabilité de la couche rollup, plutôt que de résoudre directement les problèmes au niveau de la couche de base. Essentiellement, cette approche ne résout pas le problème, mais le transfère à la couche supérieure de la pile.

Optimistic Rollup

Actuellement, la plupart des Optimistic rollups sont centralisés. Certains n'ont même qu'un seul séquenceur, ce qui entraîne des problèmes de sécurité insuffisante, d'isolement mutuel, de forte latence, et d'attente de la période de preuve de fraude, qui dure généralement plusieurs jours.

ZK Rollup

La mise en œuvre des ZK rollups est limitée par la quantité de données pouvant être traitées par transaction. Les exigences de calcul pour générer des preuves à connaissance nulle sont très élevées, et le mécanisme de "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups limitent souvent le volume de transactions par lot, ce qui peut provoquer des congestions réseau et une augmentation des frais de gas en période de forte demande, affectant l'expérience utilisateur.

En comparaison, le coût des ZK rollup Turing-complets est d'environ 2x10^6 fois celui du protocole de sécurité économique central de Polkadot.

De plus, les problèmes de disponibilité des données liés aux ZK rollups aggravent également leurs inconvénients. Pour garantir que quiconque puisse vérifier les transactions, il est toujours nécessaire de fournir des données de transaction complètes. Cela repose généralement sur des solutions de disponibilité des données supplémentaires, ce qui augmente encore les coûts et les frais pour les utilisateurs.

Conclusion

La fin de l'évolutivité ne devrait pas être un compromis.

Comparé à d'autres blockchains, Polkadot n'a pas emprunté la voie de la centralisation pour des performances, ni échangé la confiance prédéfinie pour l'efficacité, mais a réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extensibilité flexible, une conception de protocole sans autorisation, une couche de sécurité unifiée et un mécanisme de gestion des ressources flexible.

Dans la quête d'une application à plus grande échelle aujourd'hui, l'"extensibilité sans confiance" défendue par Polkadot est peut-être la véritable solution capable de soutenir le développement à long terme du Web3.