- Rubrique
76k Popularité
30k Popularité
9k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
12k Popularité
2k Popularité
- Épingler
76k Popularité
30k Popularité
9k Popularité
4k Popularité
4k Popularité
29k Popularité
16k Popularité
22k Popularité
12k Popularité
2k Popularité
Le chemin d'innovation de Polkadot : comment réaliser un équilibre entre évolutivité, sécurité et Décentralisation
Choix de l'évolutivité du Blockchain : Le chemin innovant de Polkadot
Dans un contexte où la technologie Blockchain recherche constamment une efficacité accrue, une question clé émerge progressivement : comment améliorer les performances sans 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, s'il est basé sur le sacrifice de la confiance et de la sécurité, peine souvent à soutenir une véritable innovation durable.
En tant que moteur important de l'évolutivité 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é du réseau ? Cet article analysera en profondeur les choix et les compromis de Polkadot dans la conception de l'évolutivité, et les comparera aux solutions d'autres chaînes de blocs majeures, en explorant leurs différentes voies entre performance, sécurité et 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 dépend d'un réseau de validateurs ainsi que de la chaîne de relais (Relay Chain), 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 du séquenceur ( qui connecte la chaîne relais, dont la communication utilise un mécanisme appelé protocole collator. Ce protocole est complètement sans permission et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connectant à un petit nombre de nœuds de la chaîne relais et soumettant des demandes de transition d'état du rollup. Ces demandes seront vérifiées par un core de la chaîne relais, à condition de respecter une exigence : elles doivent être des transitions d'état valides, sinon l'état du rollup ne sera pas avancé.
) compromis d'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é "Elastic Scaling"###Elastic Scaling(. Au cours du processus de conception, il a été constaté que, étant donné que la validation des blocs Rollup n'est pas fixée sur un core particulier, cela pourrait affecter sa flexibilité.
Puisque le protocole de soumission des blocs à la chaîne de relais est sans autorisation et sans confiance, tout le monde peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. Les attaquants pourraient exploiter cela en soumettant à plusieurs reprises des blocs légitimes déjà vérifiés sur différents cores, consommant malicieusement des ressources et réduisant ainsi le débit et l'efficacité globaux du rollup.
L'objectif de Polkadot est de maintenir l'élasticité des rollups et une utilisation efficace des ressources de la chaîne de relais, sans affecter les caractéristiques clés du système.
) Problèmes de confiance du Séquenceur
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 le tri par défaut des validateurs ne se comporte pas malicieusement, 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. Toute personne devrait pouvoir soumettre des demandes de transformation d'état de rollup en utilisant le protocole de collateur.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier complètement le problème à la fonction de transition d'état rollup ###Runtime(. Runtime est la seule source fiable de toutes les informations de consensus, il est donc impératif de déclarer clairement sur quel cœur Polkadot la validation doit être exécutée.
Cette conception réalise une double garantie d'élasticité 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 core grâce au protocole économique cryptographique ELVES.
Avant que tout bloc rollup n'écrive dans la couche de disponibilité des données de Polkadot )DA(, un groupe composé d'environ 5 validateurs vérifiera d'abord sa légitimité. Ils reçoivent le reçu candidat )candidate receipt( soumis par le trieur ainsi qu'une preuve de validité )PoV(, qui contient le bloc rollup et la preuve de stockage correspondante. 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 validation contient un core selector, utilisé pour spécifier sur quel core le bloc doit être validé. Le validateur comparera si cet index correspond à celui du 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 autorisation, évitant que des acteurs malveillants comme les ordonneurs ne manipulent les positions de validation, assurant ainsi que même lorsque le rollup utilise plusieurs core, il peut maintenir sa résilience.
) 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, 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, en validant tous les calculs sur le core, sans aucune restriction ni hypothèse sur le nombre de cores utilisés.
Ainsi, les rollups de Polkadot peuvent réaliser une véritable extensibilité 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 individuelle est complétée dans les 2 secondes. Grâce à l'extension élastique, le montant total de calculs pouvant être exécutés toutes les 6 secondes est augmenté, 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 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:
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é flexible 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 est attribué.
Dans le futur, Polkadot prendra également en charge la messagerie hors chaîne ###off-chain messaging(, avec la chaîne de relais comme couche de contrôle, plutôt que comme couche de données. Cette mise à niveau permettra d'améliorer la capacité de communication entre les rollups tout en augmentant l'évolutivité, renforçant ainsi la capacité d'évolutivité verticale du système.
Compromis d'autres protocoles
Comme tout le monde le sait, l'amélioration des performances se fait souvent au prix de la décentralisation et de la sécurité. Mais d'après 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.
) 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, s'appuyant sur la preuve historique ###PoH(, le traitement parallèle par CPU et un mécanisme de consensus basé sur les leaders, avec un TPS théorique pouvant atteindre 65 000.
Un élément clé de la conception est son mécanisme de planification des leaders, préalablement public et vérifiable:
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 mise, plus il a de chances de produire un bloc, tandis que les petits nœuds ont presque aucun slot, aggravant ainsi la centralisation et augmentant le risque d'effondrement du système en cas d'attaque.
Solana a sacrifié la décentralisation et la capacité de 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 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. Polkadot a déjà 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 shards peut être exposée à l'avance. Le livre blanc de TON souligne également que cela peut optimiser la bande passante, mais peut également être utilisé de manière malveillante. En raison de l'absence de mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit complètement contrôlé par lui, ou intercepter des validateurs honnêtes par le biais d'attaques DDoS, ce qui permet de manipuler l'état.
En comparaison, les validateurs de Polkadot sont attribués de manière aléatoire et leur identité est révélée avec un délai. Les attaquants ne peuvent pas connaître à l'avance l'identité des validateurs, l'attaque nécessite de parier sur le contrôle total pour réussir. Tant qu'il y a un validateur honnête qui soulève une contestation, l'attaque échouera et entraînera une perte de la mise pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseau pour l'expansion, le réseau principal est composé de transferts X-Chain###, ~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 shard unique pour réaliser l'évolutivité. Cependant, Avalanche permet aux validateurs de choisir librement de participer à un sous-réseau, et des exigences supplémentaires telles que géographiques ou KYC peuvent être définies pour le sous-réseau, 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 garantie de sécurité par défaut, certains peuvent même être complètement centralisés. Pour améliorer la sécurité, il est toujours 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 en essence pas le problème, mais le transfère à la couche supérieure de la pile.
Optimistic Rollup
Actuellement, la plupart des Optimistic rollups sont centralisés, et certains n'ont même qu'un seul séquenceur, ce qui entraîne des problèmes tels qu'une sécurité insuffisante, une isolation entre eux, une latence élevée, et un temps d'attente pour la période de preuve de fraude, généralement de quelques 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 "celui qui gagne prend tout" 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 gaz en période de forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût des ZK rollup 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 exacerbent leurs inconvénients. Afin de garantir 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.
Contrairement à d'autres blockchains, Polkadot n'a pas choisi la voie de la centralisation au détriment des performances, ni celle de la confiance prédéfinie pour plus d'efficacité, mais a plutôt réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extension élastique, 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 application à 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.