Arbitrage de l'évolutivité : Le choix entre Polkadot et Web3

Dans un contexte où la technologie blockchain cherche constamment à améliorer son efficacité, une question clé émerge progressivement : comment améliorer la scalabilité tout en évitant de sacrifier la sécurité et la résilience du système ? Cela représente non seulement un défi technique, mais aussi un choix architectural profond. Pour l'écosystème Web3, un système plus rapide construit sur la base du sacrifice de la confiance et de la sécurité a souvent du mal à soutenir une véritable innovation durable.

En tant que promoteur essentiel de la scalabilité Web3, Polkadot a-t-il fait certains compromis dans sa quête d'un haut débit et d'une faible latence ? Son modèle de rollup a-t-il fait des concessions en matière de décentralisation, de sécurité ou d'interopérabilité réseau ? Cet article analysera en profondeur les compromis et les arbitrages de Polkadot dans la conception de la scalabilité, et comparera ses solutions avec celles d'autres blockchains principales, explorant leurs choix différents en matière de performance, de sécurité et de décentralisation.

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 à certains égards ? 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 connecté à la chaîne de relais, dont la communication utilise un mécanisme appelé protocole collateur. 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 du rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition d'une seule précondition : elles doivent être des changements d'état valides, sinon l'état du rollup ne sera pas avancé.

compromis d'extension verticale

Le Rollup peut réaliser une mise à l'échelle verticale en utilisant l'architecture multicœur de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité « mise à l'échelle élastique ». Au cours du processus de conception, il a été constaté que, puisque la validation des blocs rollup n'est pas fixée sur un cœur particulier, cela pourrait affecter son élasticité.

Étant donné que 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 cœur assigné au rollup pour validation. Les attaquants pourraient en profiter pour soumettre à plusieurs reprises des blocs légitimes déjà validés à différents cœurs, consommant ainsi des ressources de manière malveillante, ce qui réduit 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 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 ordonneurs qui ne présentent pas de comportements malveillants, 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 soumettre une demande 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 conversion d'état (Runtime) du rollup. Le Runtime est la seule source fiable de toutes les informations de consensus, il est donc impératif de préciser dans la sortie sur quel cœur de Polkadot la validation doit être effectuée.

Cette conception assure une double garantie d'élasticité et de sécurité. Polkadot réexécutera la transition d'état des rollups dans le processus de disponibilité et garantira l'exactitude de l'allocation de core grâce au protocole économique cryptographique ELVES.

Avant l'écriture des données de la rollup sur la couche de disponibilité des données 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 rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, exécutée à nouveau par les validateurs sur la chaîne de relais.

Le résultat de la validation contient un sélecteur core, utilisé pour spécifier sur quel core la validation du bloc doit avoir lieu. Le validateur comparera cet index avec le core dont il est responsable ; s'il n'est pas cohérent, le bloc sera rejeté.

Ce mécanisme garantit que le système conserve toujours des propriétés sans confiance et sans permission, évitant ainsi que des acteurs malveillants, comme les ordonnanceurs, manipulent la position de vérification, assurant que même lorsque le rollup utilise plusieurs cœurs, il reste résilient.

sécurité

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

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

Ainsi, le rollup de Polkadot peut réaliser une véritable scalabilité 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 l'exécution unique est terminée dans les 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécutés par cycle de 6 secondes est augmentée, mais le type de calcul n'est pas affecté.

complexité

Un débit plus élevé et une latence plus faible introduisent 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 de la 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 s'appuyer sur des 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 des charges de transaction 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'extensibilité é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é.

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

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

Comme tout le monde le sait, l'augmentation des performances se fait souvent au détriment de la décentralisation et de la sécurité. Cependant, d'après le 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'adopte pas l'architecture de sharding de Polkadot ou d'Ethereum, mais réalise l'évolutivité avec une architecture à couche unique à haut débit, reposant 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 êtes attribué. Par exemple, un validateur qui stake 1% aura environ 1% de chances de produire un bloc ;

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

PoH et le traitement parallèle exigent 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 en cas d'attaque.

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

TON

TON revendique un TPS pouvant atteindre 104 715, mais ce chiffre a été atteint dans 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 TON présente des vulnérabilités de sécurité : l'identité des nœuds de validation de fragments peut être exposée à l'avance. Le livre blanc de TON indique également que, bien que cela puisse optimiser la bande passante, cela peut également être exploité de manière malveillante. En raison de l'absence de mécanisme de "faillite des joueurs", un attaquant peut attendre qu'un fragment soit entièrement contrôlé par lui ou bloquer les validateurs honnêtes par une attaque DDoS, ce qui 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, et tant qu'un seul validateur honnête soulève une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.

Avalanche

Avalanche utilise une architecture de réseau principal + sous-réseau 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 atteindre un TPS théorique d'environ 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 ce dernier peut imposer des exigences supplémentaires telles que géographiques ou KYC, 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 est néanmoins nécessaire de 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 les problèmes directement au niveau de la couche de base. Cette approche ne résout essentiellement pas le problème, mais le transmet à la couche supérieure de la pile.

Rollup optimiste

Actuellement, la plupart des Optimistic rollups sont centralisées, 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 plusieurs jours).

ZK Rollup

La mise en œuvre du ZK rollup est limitée par la quantité de données pouvant être traitées par transaction. Les besoins en calcul pour générer des preuves à connaissance nulle sont extrêmement élevés, et le mécanisme de "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, le ZK rollup limite souvent le volume des transactions par lot, ce qui peut entraîner des congestions réseau et une augmentation des frais de gas en période de forte demande, affectant ainsi 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 central de Polkadot.

De plus, les problèmes de disponibilité des données des 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 dépend généralement 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ésupposé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 évolutivité 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, le "zero trust scalability" défendu par Polkadot pourrait bien être la véritable solution capable de soutenir le développement à long terme du Web3.