Compromis d'évolutivité : Le choix entre Polkadot et Web3

Aujourd'hui, dans la quête d'une plus grande efficacité de la blockchain, une question clé émerge progressivement : comment garantir la sécurité et la résilience du système tout en améliorant les performances d'extension ? 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 est construit sur le sacrifice de la confiance et de la sécurité, a souvent du mal à soutenir une véritable innovation durable.

En tant que promoteur important de la scalabilité Web3, Polkadot a-t-il également fait certains compromis dans sa quête de haut débit et de 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é du réseau ? Cet article analysera en profondeur les compromis et les arbitrages de Polkadot dans la conception de sa scalabilité, et les comparera aux solutions d'autres blockchains majeures, en explorant leurs choix de trajectoire différents en matière de performance, de sécurité et de décentralisation.

Défis de la conception d'extension de Polkadot

Équilibre entre flexibilité et 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 de former un point de défaillance ou de contrôle qui pourrait affecter ses caractéristiques de décentralisation ?

Le fonctionnement des Rollups dépend des ordonnanceurs connectés à la chaîne de relais, dont la communication utilise un mécanisme appelé protocole collateur. Ce protocole est entièrement sans autorisation et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connectant à un petit nombre de nœuds de chaîne de relais et soumettant des demandes de transition d'état du rollup. Ces demandes seront vérifiées par un certain cœur de la chaîne de relais, à condition de satisfaire une exigence : elles doivent être des transitions d'état valides, sinon l'état du rollup ne sera pas avancé.

compromis de l'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é "scalabilité élastique". Au cours du processus de conception, nous avons constaté que, comme la validation des blocs de rollup n'est pas fixée à un core particulier, cela pourrait affecter son élasticité.

Étant donné que le protocole de soumission des blocs à la chaîne de relais est sans autorisation et sans confiance, tout le monde peut soumettre un bloc à n'importe quel core attribué au rollup pour validation. Les attaquants pourraient en profiter pour soumettre à plusieurs reprises des blocs légitimes déjà validés sur 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 de relais sans compromettre les caractéristiques clés du système.

Est-ce que Sequencer est 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 confiance par défaut à l'ordonnanceur qui ne se comportera 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 séquenceur, car il est nécessaire de maintenir les caractéristiques de "sans confiance" et "sans autorisation" du système. Quiconque devrait pouvoir utiliser le protocole collator pour soumettre des demandes de changement d'état de rollup.

Polkadot : une solution sans compromis

La solution 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 nécessaire de déclarer clairement dans la sortie sur quel core Polkadot la validation doit être exécutée.

Ce design assure 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 du core grâce au protocole économique de cryptographie ELVES.

Avant que les données de la couche de disponibilité de Polkadot soient écrites dans n'importe quel bloc rollup (DA), un groupe composé d'environ 5 validateurs vérifiera d'abord 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, réexécutées par les validateurs sur la chaîne relais.

Le résultat de la vérification contient un sélecteur de cœur, utilisé pour spécifier sur quel cœur le bloc doit être vérifié. Le validateur comparera cet index avec celui 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 ses propriétés sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants tels que les ordonnanceurs manipulent la position de validation, 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, nécessitant seulement un ordonneur honnête pour maintenir la viabilité.

Grâce au protocole ELVES, Polkadot étend totalement 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.

Ainsi, les rollups de Polkadot peuvent 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 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 effectué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 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 répondre partiellement aux 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 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 des nœuds ;

• Stratégies automatisées : Appeler à l'avance le service coretime pour configurer les ressources via les 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, 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 et n'est pas lié au nombre de cœurs qui lui sont attribués.

À 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 à jour améliorera la capacité de communication entre les rollups tout en augmentant la capacité d'extension verticale du système.

Quelles concessions ont fait les autres protocoles ?

Comme tout le monde le sait, l'amélioration des performances s'accompagne souvent d'un sacrifice 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é grâce à une architecture à couche unique à haut débit, reposant sur la preuve historique (PoH), le traitement parallèle 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 :

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

• Plus vous misez, plus vous êtes réparti. Par exemple, un validateur qui mise 1% obtiendra environ 1% de chances de générer un bloc;

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

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

Solana, 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.

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 et 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 souligne également que cela peut optimiser la bande passante, mais peut aussi être exploité de manière malveillante. En raison de l'absence d'un mécanisme de "faillite des joueurs", un attaquant peut attendre qu'un fragment soit complètement contrôlé par lui, ou bloquer des 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 retard, les attaquants ne peuvent pas connaître à l'avance l'identité des validateurs. L'attaque doit miser sur un contrôle total pour réussir; tant qu'un valideur honnête lance un litige, 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 est composé de X-Chain( pour les transferts, ~4 500 TPS), C-Chain( pour les contrats intelligents, ~100-200 TPS), et P-Chain( pour la gestion des validateurs et des sous-réseaux).

Chaque sous-réseau peut théoriquement atteindre un TPS 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 à des sous-réseaux, et ces sous-réseaux peuvent imposer des exigences supplémentaires 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 garanties 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 les performances 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. Cette approche ne résout en essence pas le problème, mais le transfère à la couche supérieure de la pile.

Rollup Optimiste

Actuellement, la plupart des Optimistic rollup sont centralisés, présentant des problèmes de sécurité insuffisante, d'isolement mutuel, de latence élevée ( nécessitant d'attendre la période de preuve de fraude, généralement de quelques jours ) et d'autres problèmes.

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 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 de base de Polkadot.

De plus, le problème de disponibilité des données des ZK rollups exacerbe également leurs inconvénients. Pour s'assurer que quiconque puisse vérifier les transactions, il est nécessaire de fournir des données de transaction complètes. Cela dépend souvent de 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é aux autres blockchains publiques, Polkadot n'a pas choisi le chemin de la centralisation pour améliorer les performances, ni celui de la confiance prédéfinie pour gagner en efficacité. Au contraire, il réalise un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une architecture extensible, à des protocoles sans autorisation, à une couche de sécurité unifiée et à des mécanismes de gestion des ressources flexibles.

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.