L'équilibre entre l'évolutivité, la sécurité et la Décentralisation : Les choix technologiques de Polkadot

Dans un monde de blockchain qui recherche constamment une plus grande efficacité, une question clé émerge progressivement : lors de l'amélioration des performances d'extension, doit-on nécessairement sacrifier la sécurité et la résilience du système ?

Ce n'est pas seulement un défi technique, mais aussi un choix profond en matière de conception architecturale. Pour l'écosystème Web3, un système plus rapide construit sur le sacrifice de la confiance et de la sécurité a souvent du mal à soutenir une véritable innovation durable.

Polkadot, en tant que moteur important de l'évolutivité Web3, a-t-il également fait certains sacrifices dans la quête d'un haut débit et d'une faible latence ? Son modèle rollup a-t-il fait des compromis sur la Décentralisation, la sécurité ou l'interopérabilité réseau ?

Cet article abordera ces questions en profondeur, en analysant les compromis et les choix de conception d'évolutivité de Polkadot, et en les comparant aux solutions d'autres blockchains majeures, tout en explorant leurs choix de chemins différents entre performance, sécurité et Décentralisation.

Défis de la conception d'extension de Polkadot

Équilibre entre l'élasticité et la Décentralisation

L'architecture de Polkadot repose sur un réseau de validateurs et une chaîne de relais centralisée, cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible qu'un point de défaillance unique ou un contrôle se forme, affectant ainsi ses caractéristiques de Décentralisation ?

Le fonctionnement des Rollups dépend d'un ordonnanceur de chaîne relais connecté, dont la communication utilise un mécanisme appelé protocole collator. Ce protocole est entièrement sans autorisation et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de chaîne relais et soumettre des demandes de transition d'état de Rollup. Ces demandes seront vérifiées par un core de la chaîne relais, à condition de satisfaire un prérequis : la transition d'état doit être valide, sinon l'état du Rollup ne sera pas avancé.

compromis sur l'extension verticale

Rollup peut réaliser une extension verticale en exploitant l'architecture multicœur de Polkadot. Cette nouvelle capacité est introduite par la fonction "extension élastique". Au cours du processus de conception, il a été constaté que, comme la validation des blocs rollup n'est pas fixée à un cœur particulier, cela pourrait affecter son élasticité.

Comme le protocole de soumission de blocs à la chaîne intermédiaire est sans permission et sans confiance, n'importe qui peut soumettre des blocs à n'importe quel core attribué au rollup pour validation. Un attaquant pourrait en profiter pour soumettre à plusieurs reprises des blocs légitimes déjà validés à différents cores, consommant ainsi des ressources de manière malveillante, ce qui réduit le débit et l'efficacité globale du rollup.

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

Sequencer est-il digne de confiance ?

Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, en adoptant un mécanisme de liste blanche, ou en supposant que le classeur de confiance par défaut n'agira pas de manière malveillante, garantissant ainsi l'activité du rollup.

Cependant, dans la philosophie de conception de Polkadot, nous ne pouvons faire aucune hypothèse de confiance sur le séquenceur, car il est nécessaire de maintenir les caractéristiques de "sans confiance" et "sans permission" du système. Quiconque devrait pouvoir utiliser le protocole de collateur pour soumettre des demandes de changement d'état de rollup.

Polkadot : une solution sans compromis

La solution finalement choisie par Polkadot est : confier entièrement le problème à la fonction de conversion d'état des rollups (Runtime). Le Runtime est la seule source fiable de toutes les informations de consensus, il doit donc être clairement indiqué dans la sortie sur quel cœur de Polkadot la validation doit être effectuée.

Cette conception réalise une double garantie d'élasticité et de sécurité. Polkadot réexécutera la transition d'état du rollup dans le processus de disponibilité et garantira la validité de la distribution de core grâce au protocole économique cryptographique ELVES.

Avant d'écrire sur la couche de disponibilité des données Polkadot dans tout bloc rollup, un groupe composé d'environ 5 validateurs vérifiera d'abord sa légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le séquenceur, qui contiennent le bloc rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle et seront réexécutées par les validateurs sur la chaîne de relais.

Le résultat de la validation contient un sélecteur de cœur (core selector) qui spécifie sur quel cœur (core) le bloc doit être validé. Le validateur va comparer cet index avec le cœur (core) dont il est responsable ; s'ils ne correspondent pas, le bloc sera rejeté.

Ce mécanisme garantit que le système conserve toujours ses attributs sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants comme les ordonnanceurs n'exercent une manipulation sur les positions de vérification, assurant que même lorsque 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, et il suffit d'un ordonneur honnête pour maintenir la viabilité.

Grâce au protocole ELVES, Polkadot étend intégralement sa sécurité à tous les rollups, vérifiant tous les calculs sur le core, sans aucune restriction ou hypothèse sur le nombre de cores utilisés.

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

Universalité

L'extension élastique n'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 qu'une exécution unique est complétée en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécuté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 entraînent inévitablement de la complexité, ce qui est le seul compromis acceptable 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 les charges de transactions spécifiques dans le mempool des nœuds ;

• Stratégies automatisées : Configurer les ressources en appelant à l'avance le service coretime via des données historiques et l'interface XCM.

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, tandis que 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, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui est attribué.

Dans le futur, Polkadot prendra également en charge la messagerie hors chaîne, avec la chaîne de relais comme plan de contrôle, plutôt que comme plan de données. Cette mise à niveau améliorera la capacité de communication entre les rollups avec une mise à l'échelle élastique, renforçant ainsi la capacité d'extensibilité verticale du système.

Quels compromis d'autres protocoles ont-ils fait ?

Il est bien connu que l'amélioration des performances s'accompagne souvent d'un sacrifice de la Décentralisation et de la sécurité. Cependant, d'un point de vue du coefficient de Nakamoto, même si certains concurrents de Polkadot présentent 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 à couche unique à haut débit, s'appuyant sur la preuve historique (PoH), le traitement parallèle par CPU et un mécanisme de consensus basé sur un leader, avec un TPS théorique pouvant atteindre 65 000.

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

• Au début de chaque epoch (environ deux jours ou 432 000 slots), les slots sont attribués en fonction du montant de la mise ;

• Plus vous stakez, plus vous recevez. Par exemple, un validateurs qui stake 1% obtiendra environ 1% d'opportunités de création de blocs ;

• Tous les mineurs de blocs sont annoncés à l'avance, augmentant le risque que le réseau subisse des attaques DDoS ciblées et des pannes fréquentes.

La PoH et le traitement parallèle exigent des ressources matérielles très élevées, ce qui entraîne une concentration des nœuds de validation. Plus un nœud stake est important, plus il a de chances de produire un bloc, tandis que les petits nœuds n'ont presque aucune opportunité de slot, ce qui aggrave encore la décentralisation et augmente le risque de paralysie du système en cas d'attaque.

Solana a sacrifié la décentralisation et la résistance aux attaques pour poursuivre le TPS, son coefficient de Nakamoto n'étant que de 20, bien en dessous des 172 de Polkadot.

TON

TON affirme que le TPS peut atteindre 104 715, mais ce chiffre est atteint dans 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 atteint 128K TPS sur un réseau public décentralisé.

Le mécanisme de consensus de TON présente des vulnérabilités de sécurité : l'identité des nœuds de validation de shard peut être exposée à l'avance. Le livre blanc de TON souligne également que cela peut optimiser la bande passante, mais peut également être exploité de manière malveillante. En raison de l'absence d'un mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit complètement contrôlé par lui, ou empêcher des validateurs honnêtes par le biais d'attaques DDoS, afin de modifier 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, les attaquants ne peuvent pas connaître l'identité des validateurs à l'avance, l'attaque doit miser sur le contrôle total pour réussir, tant qu'un seul validateur honnête initie une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.

Avalanche

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

Chaque sous-réseau peut théoriquement atteindre un TPS d'environ 5 000, similaire à l'approche 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 supplémentaires telles que géographiques, KYC, etc., sacrifiant ainsi la Décentralisation et la sécurité.

Dans Polkadot, tous les rollups partagent une garantie de 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 complètement centralisés. Pour améliorer la sécurité, il faut encore faire des compromis sur la performance, et il est difficile de fournir des engagements de sécurité déterministes.

Ethereum

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

Optimistic Rollup

Actuellement, la plupart des rollups Optimistic sont décentralisés (certains n'ont même qu'un seul séquenceur), ce qui pose des problèmes de sécurité insuffisante, d'isolement mutuel et de latence élevée (il faut attendre 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 à divulgation nulle de connaissance 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 gaz en période de forte demande, affectant ainsi l'expérience utilisateur.

En comparaison, le coût des ZK rollups complètement Turing 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 des ZK rollup exacerberont é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 dépend souvent de solutions supplémentaires de disponibilité des données, 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 publiques, Polkadot n'a pas choisi la voie de la centralisation au détriment de la performance ni celle de la confiance présumée au détriment de 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.

Aujourd'hui, dans la quête d'une application à plus grande échelle, le "scalabilité sans confiance" défendu par Polkadot est peut-être la véritable solution qui peut soutenir le développement à long terme du Web3.