- Rubrique
77k Popularité
33k Popularité
10k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
13k Popularité
3k Popularité
- Épingler
77k Popularité
33k Popularité
10k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
13k Popularité
3k Popularité
L'évolutivité flexible de Polkadot : compromis entre évolutivité et sécurité dans l'écosystème Web3
Scalabilité et compromis : choix technologique entre Polkadot et l'écosystème Web3
Aujourd'hui, alors que la technologie blockchain s'efforce d'atteindre une efficacité toujours plus grande, une question clé émerge progressivement : comment concilier performance d'échelle, sécurité et résilience des systèmes ? Cela représente non seulement un défi technique, mais aussi un choix profond en matière de conception architecturale. Pour l'écosystème Web3, il est difficile de soutenir une innovation véritablement durable en ne recherchant qu'un système plus rapide au détriment de la confiance et de la sécurité.
En tant qu'importante force motrice de l'évolutivité de Web3, Polkadot a-t-il fait certains sacrifices dans sa quête d'un haut débit et d'une faible latence ? Son modèle de rollup compromet-il la décentralisation, la sécurité ou l'interopérabilité du réseau ? Cet article se penchera sur ces questions, analysera en profondeur les compromis et les arbitrages de Polkadot dans la conception de l'évolutivité, et comparera ses solutions avec celles d'autres chaînes publiques majeures, explorant les différentes voies qu'elles empruntent en matière de performance, de sécurité et de décentralisation.
Les défis de la conception d'extensions 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 ? Est-il possible de créer un point de défaillance unique ou un contrôle qui pourrait affecter ses caractéristiques de décentralisation ?
Le fonctionnement des Rollups dépend des ordonnateurs des chaînes de relais connectées, dont la communication utilise le mécanisme de protocole collator. Ce protocole est entièrement sans permission et sans confiance, toute personne disposant d'une connexion réseau peut l'utiliser, connecter un petit nombre de nœuds de chaînes de relais et soumettre des demandes de transformation d'état pour le rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition de satisfaire un prérequis : elles doivent être des transformations d'état valides, sinon l'état de ce rollup ne sera pas avancé.
compromis d'extension verticale
Les Rollups peuvent réaliser une scalabilité verticale en tirant parti de l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité de "scalabilité élastique". Au cours du processus de conception, il a été constaté que le fait que la validation des blocs Rollup ne soit pas fixe sur un core particulier pourrait affecter son élasticité.
Puisque le protocole de soumission des blocs à la chaîne relais est sans permission et sans confiance, tout le monde peut soumettre des blocs à n'importe quel core attribué au rollup pour validation. Un attaquant pourrait en tirer parti en soumettant à plusieurs reprises des blocs légitimes déjà validés à différents cores, consommant malicieusement des ressources, ce qui réduirait le débit global et l'efficacité 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.
Problème de fiabilité des séquenceurs
Une solution simple consiste à définir le protocole comme "avec licence" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut aux ordonneurs qui 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 nécessaire de maintenir les caractéristiques de "sans confiance" et "sans autorisation" 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 transition 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 de Polkadot la validation doit être effectuée.
Ce design offre une double garantie de flexibilité et de sécurité. Polkadot réexécutera les transitions d'état du rollup dans le processus de disponibilité et garantira la justesse de l'allocation du core grâce au protocole économique cryptographique ELVES.
Avant que les données soient écrites dans la couche de disponibilité des données (DA) de Polkadot dans n'importe quel bloc rollup, un groupe composé d'environ 5 validateurs vérifiera d'abord leur légitimité. Ils reçoivent des reçus candidats et des preuves de validité soumis par le validateur, 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ée par les validateurs sur la chaîne de relais.
Le résultat de la validation contient un sélecteur de cœur, qui spécifie sur quel cœur le bloc doit être validé. Le validateur comparera cet index pour voir s'il correspond au cœur dont il est responsable ; s'il ne correspond pas, le bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours ses propriétés de non-confiance et de permission, évitant ainsi que des acteurs malveillants comme les ordonneurs n'altèrent la position de validation, 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 compromis 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 intégralement sa sécurité à tous les rollups, en validant 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 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 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 à certaines exigences de la RFC103 pour s'adapter à différents cas 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 :
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 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 comme couche de contrôle, plutôt que comme couche de données. Cette mise à niveau améliorera la capacité de communication entre les rollups tout en augmentant l'évolutivité en fonction des besoins, renforçant ainsi la capacité d'évolutivité verticale du système.
Trade-offs des 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, en regardant le coefficient de Nakamoto, même si certains concurrents de Polkadot ont un degré de décentralisation relativement faible, leurs performances ne sont pas à la hauteur.
Chaîne publique A
Une certaine blockchain A 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, 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 rendu public et vérifiable :
L'histoire prouve que le traitement parallèle nécessite des exigences matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud mise, plus il a de chances de produire des blocs, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave la centralisation et augmente le risque d'effondrement du système après une attaque.
Une certaine blockchain A, dans sa quête de TPS, a sacrifié la décentralisation et la résilience aux attaques, son coefficient de Nakamoto n'étant que de 20, bien en dessous des 172 de Polkadot.
Une chaîne publique B
Une certaine blockchain publique B prétend atteindre 104 715 TPS, 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é.
Un mécanisme de consensus de la blockchain publique B 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 la blockchain publique B 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 parieurs", un attaquant peut attendre qu'un shard 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 revanche, 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. L'attaque nécessite de parier sur le succès du contrôle total ; tant qu'il y a un validateur honnête qui lance une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.
une chaîne de blocs 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 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, 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 supplémentaires telles que 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 le sous-réseau de la blockchain C n'a pas de garantie de sécurité par défaut, certains peuvent même être entièrement centralisés. Pour améliorer la sécurité, il faut encore faire des compromis sur les performances et il est difficile de fournir des engagements de sécurité déterministes.
une chaîne de blocs D
La stratégie d'expansion de la blockchain publique D parie sur l'évolutivité de la couche rollup, plutôt que de résoudre les problèmes directement au niveau de la couche de base. Cette approche n'a en essence pas résolu le problème, mais l'a simplement transféré à la 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 pose des problèmes de sécurité insuffisante, d'isolement entre eux et de délais élevés (nécessitant d'attendre la période de preuve de fraude, qui dure généralement plusieurs jours).
ZK Rollup
La mise en œuvre de ZK rollup 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, ZK rollup limite souvent le volume de transactions par lot, ce qui peut entraîner des congestions réseau et une augmentation des frais de transaction en période de forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût d'un ZK rollup Turing-complet est d'environ 2x10^6 fois celui du protocole de sécurité économique de base de Polkadot.
De plus, les problèmes de disponibilité des données de ZK rollup aggraveront également ses inconvénients. Pour garantir que quiconque puisse vérifier les transactions, il est nécessaire de fournir des données transactionnelles 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é à d'autres blockchains publiques, Polkadot n'a pas emprunté la voie de la centralisation pour gagner en performance, ni échangé la confiance présumée pour l'efficacité, mais a plutôt réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extensibilité flexible, une conception de protocole sans permission, 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 "zero-trust scalability" défendu par Polkadot est peut-être la véritable solution capable de soutenir le développement à long terme du Web3.