- Rubrique
87778 Popularité
40859 Popularité
13844 Popularité
3661 Popularité
4379 Popularité
28608 Popularité
15571 Popularité
21920 Popularité
12802 Popularité
2221 Popularité
- Épingler
87778 Popularité
40859 Popularité
13844 Popularité
3661 Popularité
4379 Popularité
28608 Popularité
15571 Popularité
21920 Popularité
12802 Popularité
2221 Popularité
Le choix entre Polkadot et l'évolutivité de Web3 : sécurité et Décentralisation sans compromis
Choix d'extensibilité : Les compromis entre Polkadot et Web3
Dans un monde de blockchain qui cherche constamment une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances d'échelle sans sacrifier la sécurité et la résilience du système ? Ce n'est pas seulement un défi au niveau technique, mais aussi un choix profond en matière de conception architecturale. Pour l'écosystème Web3, un système plus rapide basé sur un sacrifice de confiance et de sécurité a souvent du mal à soutenir une véritable innovation durable.
En tant que moteur important de la scalabilité Web3, Polkadot a-t-il également fait certains sacrifices dans l'objectif 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 se penchera sur ces questions, analysant en profondeur les compromis et les arbitrages de Polkadot en matière de conception de scalabilité, et comparant ses solutions avec celles d'autres chaînes de blocs majeures, en explorant leurs choix de trajectoire différents entre performance, sécurité et décentralisation.
Les défis du design 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 centralisée. Cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible qu'un point de défaillance ou de contrôle se forme, affectant ainsi ses caractéristiques de décentralisation ?
Le fonctionnement du Rollup dépend de l'ordonneur de la chaîne de relais connectée, dont la communication utilise le mécanisme du protocole collator. Ce protocole est entièrement sans autorisation et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de chaîne de relais et soumettre 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 respecter un prérequis : la transition d'état doit être valide, sinon l'état du rollup ne sera pas avancé.
compromis de l'extension verticale
Le Rollup peut réaliser une montée en charge verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonction "extensibilité élastique". Au cours du processus de conception, il a été constaté que, puisque la validation des blocs 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 permission et sans confiance, tout le monde peut soumettre des blocs à n'importe quel cœur attribué au rollup pour validation. Un attaquant pourrait exploiter cela en soumettant à 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éduirait le débit et l'efficacité globaux du rollup.
L'objectif de Polkadot est de maintenir la flexibilité des rollups et l'utilisation efficace des ressources de la chaîne relais, sans compromettre les caractéristiques clés du système.
Problème de confiance du Séquenceur
Une solution simple consiste à définir le protocole comme "avec autorisation": par exemple, en adoptant un mécanisme de liste blanche, ou en supposant que le tri par défaut des validateurs ne se comporte 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 permission » du système. Quiconque devrait pouvoir soumettre des demandes de changement d'état de rollup en utilisant le protocole collateur.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier complètement le problème à la fonction de conversion d'état du rollup (Runtime). Runtime est la seule source fiable de toutes les informations de consensus, donc il est impératif de déclarer clairement où la validation doit être exécutée sur le cœur de Polkadot.
Ce design assure une double garantie de flexibilité et de sécurité. Polkadot réexécutera la transition d'état du rollup dans le processus de disponibilité et garantira l'exactitude de l'allocation du core grâce au protocole économique ELVES.
Avant que des données soient écrites dans la couche de disponibilité des données de Polkadot sur n'importe quel bloc rollup, un groupe d'environ 5 validateurs vérifie 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, exécutée à nouveau par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur core, utilisé pour spécifier sur quel core le bloc doit être vérifié. Le validateur comparera cet index avec celui du core dont il est responsable ; s'ils ne correspondent pas, 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 tels que les ordonnanceurs ne manipulent la position de vérification, assurant ainsi 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 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é.
Avec le protocole ELVES, Polkadot étend complètement sa sécurité à tous les rollups, vérifiant tous les calculs sur le cœur, sans aucune restriction ni hypothèse sur le nombre de cœurs utilisés.
Ainsi, les rollups de Polkadot peuvent réaliser une véritable évolutivité sans sacrifier 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 en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécutés dans un 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 entraînent inévitablement une complexité, c'est la seule façon acceptable de faire des compromis 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, ces stratégies pouvant 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'élasticité de l'évolutivité 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 des blocs de communication de chaque rollup est fixe et n'est pas lié au nombre de cœurs qui lui est attribué.
À l'avenir, Polkadot prendra également en charge la transmission de messages hors chaîne, avec la chaîne de relais 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 avec une évolutivité élastique, renforçant ainsi la capacité d'extension verticale du système.
Compromis entre 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'après le coefficient de Nakamoto, même si certains concurrents de Polkadot présentent un niveau 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é 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 un leader, avec un TPS théorique pouvant atteindre 65 000.
Un élément de conception clé est son mécanisme de planification des leaders, qui est préalablement public et vérifiable :
PoH et le traitement parallèle exigent des exigences matérielles extrêmement élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud stake est élevé, plus les chances de produire un bloc sont grandes, tandis que les petits nœuds ont presque aucun slot, aggravant encore la centralisation et augmentant 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 de celui de Polkadot qui est de 172.
TON
TON prétend que le TPS peut atteindre 104 715, mais ce chiffre a été obtenu sur un testnet privé, avec 256 nœuds, dans des conditions réseau et matérielles idéales. En revanche, 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 shard peut être exposée à l'avance. Le livre blanc de TON souligne également que cela peut optimiser la bande passante, mais peut également être exploité de manière malveillante. En raison de l'absence de mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un certain shard soit complètement contrôlé par lui, ou interrompre les validateurs honnêtes par une attaque DDoS, permettant ainsi 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. Les attaquants ne peuvent pas connaître à l'avance l'identité des validateurs. L'attaque doit miser sur le contrôle complet pour réussir. Tant qu'un validateurs honnête soulève une contestation, l'attaque échouera et entraînera des pertes de mise pour les attaquants.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseau pour l'évolutivité, le réseau principal est composé de transferts X-Chain(, ~4 500 TPS), de contrats intelligents C-Chain(, ~100-200 TPS), et de gestion des validateurs et sous-réseaux P-Chain(.
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, 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 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 encore nécessaire de faire des compromis sur les performances, 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 sur la couche de base. Cette approche n'a essentiellement pas résolu le problème, mais l'a plutôt transféré à la couche supérieure de la pile.
Rollup optimiste
Actuellement, la plupart des rollups optimistes 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, de délais élevés ) nécessitant d'attendre la période de preuve de fraude, généralement 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. Les exigences de calcul pour générer des preuves à divulgation nulle de connaissance sont très élevées, et le mécanisme « 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 provoquer des congestions réseau et une augmentation des frais de gaz en période de forte demande, impactant 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, le problème de disponibilité des données des ZK rollups exacerbe également leurs inconvénients. Pour garantir que quiconque puisse vérifier les transactions, il est nécessaire de fournir des données de transaction complètes. Cela repose généralement sur des solutions de disponibilité des données supplémentaires, augmentant ainsi 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 de sacrifier la décentralisation pour la performance ni d'échanger la confiance prédéfinie contre l'efficacité, mais a plutôt atteint un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une mise à l'échelle élastique, une conception de protocole sans autorisation, une couche de sécurité unifiée et un mécanisme de gestion des ressources flexible.
Dans la recherche 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.