Les compromis de l'évolutivité de Web3 : La solution de Polkadot

Dans un monde de blockchain qui cherche constamment une plus grande efficacité, une question clé émerge progressivement : comment concilier la performance d'extension avec 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, s'il repose sur des sacrifices en matière de confiance et de sécurité, a souvent du mal à soutenir une véritable innovation durable.

Polkadot, en tant que moteur important de l'évolutivité de Web3, a-t-il fait des compromis en matière de décentralisation, de sécurité ou d'interopérabilité du réseau avec son modèle de rollup ? Cet article analysera en profondeur les compromis et les choix de Polkadot dans la conception de l'évolutivité, et comparera ses solutions à celles d'autres blockchains majeures, en explorant leurs choix distincts en matière de performance, de sécurité et de décentralisation.

Les défis de la conception d'extension de Polkadot

L'équilibre entre la flexibilité et la décentralisation

L'architecture de Polkadot repose sur un réseau de validateurs et une chaîne de relais. 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 qui pourrait affecter ses caractéristiques de décentralisation ?

Le fonctionnement des Rollups dépend des ordonnateurs de la chaîne de relais connectés, et leur 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 la chaîne de relais et soumettre des demandes de changement d'état des Rollups. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition de remplir un préalable : elles doivent être des changements d'état valides, sinon l'état de ce Rollup ne sera pas avancé.

compromis sur l'extension verticale

Les Rollups peuvent réaliser une mise à l'échelle verticale en utilisant l'architecture multicœur de Polkadot. Cette nouvelle capacité est introduite par la fonction de « mise à l'échelle élastique ». Au cours du processus de conception, nous avons constaté que, puisque la validation des blocs de rollup n'est pas fixée à un cœur particulier, cela pourrait affecter son élasticité.

Étant donné que le protocole de soumission de blocs à la chaîne de relais est sans permission et sans confiance, n'importe qui peut soumettre un bloc à n'importe quel core attribué au rollup pour validation. Un attaquant pourrait exploiter cela en soumettant de manière répétée des blocs légitimes déjà validés à différents cores, consommant ainsi des ressources de manière malveillante et réduisant le débit et l'efficacité globaux du rollup.

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

Le séquenceur 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 faisant en sorte que les classificateurs de confiance par défaut ne se comportent 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 important de maintenir les caractéristiques de « sans confiance » et « sans autorisation » du système. Quiconque devrait être en mesure de soumettre des demandes de transition d'état de rollup en utilisant le protocole de collateur.

Polkadot: une solution sans compromis

La solution choisie par Polkadot est la suivante : confier entièrement le problème à la fonction de transformation d'état du rollup (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 Polkadot la validation doit être exécutée.

Ce design assure une double garantie de flexibilité et de sécurité. Polkadot réexécutera la transformation d'état du rollup dans le processus de disponibilité et garantira l'exactitude de l'allocation de core grâce au protocole économique cryptographique ELVES.

Avant que les données du rollup ne soient écrites dans la couche de disponibilité des données (DA) de Polkadot, un groupe composé d'environ 5 validateurs va d'abord vérifier leur légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le séquenceur, qui contiennent le bloc de rollup ainsi que les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, et elles seront réexécutées par les validateurs sur la chaîne de relais.

Le résultat de la vérification contient un sélecteur de core, utilisé pour spécifier sur quel core le bloc doit être vérifié. Le validateur comparera cet index pour s'assurer qu'il correspond au core dont il est responsable ; s'il n'est pas cohérent, ce bloc sera rejeté.

Ce mécanisme garantit que le système conserve toujours ses propriétés sans confiance et sans autorisation, évitant la manipulation des positions de validation par des acteurs malveillants comme les ordonneurs, et assurant 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 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 aucune limitation ou hypothèse sur le nombre de cores utilisés.

Ainsi, les rollups de Polkadot peuvent réaliser une véritable évolutivité sans compromettre la sécurité.

Universalité

L'extension élastique n'entrave 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 terminée en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécutés tous les 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 une complexité, 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 de la RFC103 pour s'adapter à différents cas d'utilisation.

La complexité spécifique dépend des stratégies de gestion des ressources du rollup, qui peuvent 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 une charge de transaction spécifique dans le mempool du nœud ;

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

Bien que les méthodes d'automatisation soient plus efficaces, 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'élasticité de l'échelle 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é.

À l'avenir, Polkadot prendra également en charge la messagerie hors chaîne, avec la chaîne relais comme surface de contrôle, plutôt que comme surface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups tout en augmentant la scalabilité élastique, renforçant ainsi la capacité d'extension verticale du système.

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

Il est bien connu que l'amélioration des performances se fait souvent au détriment 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 relativement faible, leurs performances ne sont pas à la hauteur.

Une chaîne publique A

La chaîne publique A n'utilise pas l'architecture de sharding de Polkadot ou d'Ethereum, mais elle réalise l'évolutivité grâce à une architecture à couche unique à haut débit, en s'appuyant sur des preuves historiques, 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 leaders qui est préalablement public et vérifiable :

• Au début de chaque epoch (environ deux jours ou 432 000 slots), les slots sont répartis en fonction de la quantité de staking ;

• Plus vous misez, plus vous obtenez de répartition. Par exemple, un validateur misant 1 % obtiendra environ 1 % des chances de produire un bloc ;

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

L'histoire prouve que le traitement parallèle exige des exigences matérielles très élevées, ce qui conduit à 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, exacerbant ainsi la centralisation et augmentant le risque d'effondrement du système en cas d'attaque.

Une certaine blockchain A, dans sa quête de TPS, a sacrifié la décentralisation et la résistance aux attaques, son coefficient de Nakamoto n'étant que de 20, bien en dessous des 172 de Polkadot.

une blockchain publique B

Une certaine blockchain publique B prétend qu'elle peut 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. En revanche, Polkadot a atteint 128K TPS sur un réseau public décentralisé.

Le mécanisme de consensus de certaines blockchains B présente des vulnérabilités de sécurité : l'identité des nœuds de validation de shard peut être révélée à l'avance. Le livre blanc de certaines blockchains B précise également que, bien que cela puisse optimiser la bande passante, cela peut aussi être exploité de manière malveillante. En raison du manque de mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit entièrement contrôlé par lui, ou bloquer les validateurs honnêtes par une attaque DDoS, ce qui lui permet de modifier l'état.

En comparaison, les validateurs de Polkadot sont attribués de manière aléatoire et révélés avec délai, les attaquants ne peuvent pas connaître à l'avance l'identité des validateurs. Pour réussir une attaque, ils doivent parier sur le contrôle total. Tant qu'il y a un validateur honnête qui déclenche une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.

Une blockchain publique C

La blockchain publique C utilise une architecture de réseau principal + sous-réseau pour l'expansion. Le réseau principal est composé de X-Chain (transferts, ~4 500 TPS), C-Chain (contrats intelligents, ~100--200 TPS) et P-Chain (gestion des validateurs et 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, une certaine blockchain C 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 la sous-réseau de la blockchain C n'a pas de garantie de sécurité par défaut, certains peuvent même être complètement centralisés. Si l'on souhaite 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'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. Cette approche ne résout essentiellement pas le problème, mais le transfère à une couche supérieure de la pile.

Rollup Optimiste

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 et de latence élevée (nécessitant d'attendre la période de preuve de fraude, généralement de 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. La demande de calcul pour générer des preuves à divulgation nulle est extrêmement élevée, et le mécanisme "winner takes all" peut facilement entraîner 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 lors de fortes demandes, affectant l'expérience utilisateur.

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

De plus, le problème de disponibilité des données des ZK rollups amplifie également leurs inconvénients. Pour s'assurer que quiconque puisse vérifier les transactions, il est toujours nécessaire de fournir des données de transaction complètes. Cela dépend généralement de solutions de disponibilité des données supplémentaires, augmentant 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 pour améliorer les performances, ni celle de la confiance préalable pour gagner en efficacité. Au contraire, il réalise un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extensibilité flexible, un design 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 mise en œuvre à plus grande échelle aujourd'hui, le "zero trust scalability" défendu par Polkadot est peut-être la véritable solution capable de soutenir le développement à long terme du Web3.