Les compromis et défis de l'évolutivité de la Blockchain : La solution de Polkadot
Dans un monde où la technologie Blockchain recherche constamment une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances sans sacrifier la sécurité et la résilience du système ? 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 construit sur le sacrifice de la confiance et de la sécurité est souvent difficile à soutenir pour une véritable innovation durable.
Polkadot, en tant qu'importante force motrice de l'évolutivité Web3, a-t-il fait des concessions en matière de décentralisation, de sécurité ou d'interopérabilité réseau avec son modèle de rollup ? Cet article analysera en profondeur les compromis et les arbitrages de Polkadot dans la conception de son évolutivité, et comparera ces choix avec les solutions d'autres chaînes de blocs majeures, en explorant leurs différentes approches 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 l'élasticité et la décentralisation
L'architecture de Polkadot repose sur un réseau de validateurs et une chaîne de relais (Relay Chain), ce qui peut introduire des risques de centralisation dans certains aspects. Le fonctionnement des Rollups dépend des séquenceurs (sequencer) connectés à la chaîne de relais, dont la communication utilise le mécanisme de 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 des rollups.
Compromis sur l'expansion verticale
Le Rollup peut réaliser une mise à l'échelle verticale en tirant parti de l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité "Elastic Scaling". Cependant, comme la validation des blocs rollup n'est pas fixée à un core particulier, cela peut affecter son élasticité. Les attaquants pourraient en tirer parti en soumettant à plusieurs reprises des blocs légitimes déjà validés sur différents cores, consommant ainsi malicieusement des ressources et réduisant le débit et l'efficacité globaux du rollup.
Problèmes de confiance du Séquenceur
Une solution simple consiste à configurer le protocole comme "ayant une licence", par exemple en adoptant un mécanisme de liste blanche, ou en supposant par défaut que le séquenceur ne se comporte pas de manière malveillante. Cependant, dans la philosophie de conception de Polkadot, aucune hypothèse de confiance ne peut être faite sur le séquenceur, car il est nécessaire de maintenir les caractéristiques "sans confiance" et "sans permission" du système.
La solution de Polkadot
La solution finalement choisie par Polkadot est de laisser le problème entièrement à la fonction de transition d'état du rollup (Runtime). Le Runtime est la seule source fiable de toutes les informations de consensus et doit clairement indiquer dans la sortie sur quel core de Polkadot la vérification doit être effectuée.
Ce design assure une double garantie de flexibilité et de sécurité. Polkadot réexécutera la transformation d'état de rollup dans le processus de disponibilité et garantira la justesse de l'allocation du core grâce au protocole économique ELVES.
Avant qu'un bloc rollup ne soit écrit dans la couche de disponibilité des données (DA) de Polkadot, un groupe composé d'environ 5 validateurs va d'abord vérifier sa 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ée par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de core, qui est 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 ainsi que des acteurs malveillants comme les ordonneurs ne manipulent les positions de validation, assurant ainsi que même si le rollup utilise plusieurs core, il peut maintenir sa résilience.
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 complètement sa sécurité à tous les rollups, vérifiant tous les calculs sur le core, sans aucune restriction ou hypothèse concernant le nombre de cores utilisés.
Universalité
L'extension élastique ne limite 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 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é constant. Ils doivent également respecter partiellement les 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 reposer 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 les charges de transaction spécifiques dans le mempool des nœuds ;
Stratégie d'automatisation : appeler à l'avance le service coretime pour configurer les ressources 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, et l'évolutivité élastique n'affecte pas le débit des communications. La communication entre 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 sont attribués.
À l'avenir, Polkadot prendra également en charge la messagerie hors chaîne, avec la chaîne de relais comme interface de contrôle, et non comme interface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups avec une extension élastique, renforçant ainsi davantage la capacité d'extension verticale du système.
Équilibres d'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'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 utilise une architecture à haute capacité de traitement à couche unique pour réaliser l'évolutivité, s'appuyant sur la preuve historique (PoH), le traitement parallèle sur CPU et un mécanisme de consensus basé sur un leader, avec un TPS théorique pouvant atteindre 65 000. Son design clé est un mécanisme de planification des leaders qui est préalablement public et vérifiable.
Cependant, le 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, 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'un effondrement du système après une 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 de celui de Polkadot qui est de 172.
TON
TON prétend que le TPS peut atteindre 104 715, mais ce chiffre a été 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. 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 des fragments peut être exposée à l'avance. Le livre blanc de TON indique également que cela peut optimiser la bande passante, mais pourrait également ê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 fragment soit entièrement contrôlé par lui, ou interrompre les validateurs honnêtes par des attaques DDoS, afin de falsifier 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. Pour réussir une attaque, ils doivent parier sur le contrôle total ; tant qu'un validateur honnête soulève une contestation, l'attaque échoue et entraîne des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseaux 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 théoriquement atteindre ~5 000 TPS, similaire à l'idée de Polkadot : réduire la charge d'un seul shard pour réaliser l'évolutivité.
Mais Avalanche permet aux validateurs de choisir librement de participer à des sous-réseaux, et ces sous-réseaux peuvent imposer des exigences géographiques, de KYC, etc., 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 peuvent même être complètement centralisés. Pour améliorer la sécurité, il faut néanmoins 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 l'évolutivité de la couche rollup, plutôt que de résoudre les problèmes directement dans la couche de base. Cette approche n'a fondamentalement pas résolu le problème, mais a plutôt transféré le problème à la couche supérieure de la pile.
La plupart des Optimistic Rollups sont actuellement centralisés, ce qui pose 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 quelques jours).
La mise en œuvre de ZK Rollup est limitée par la quantité de données pouvant être traitées par une seule transaction. Les exigences de calcul pour générer des preuves à divulgation nulle de connaissance sont très élevées, et le mécanisme "le gagnant emporte tout" tend à centraliser le 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 gas lors d'une forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût des ZK rollups Turing-complets est environ 2x10^6 fois celui du protocole de sécurité économique central de Polkadot. De plus, le problème de la disponibilité des données des ZK rollups aggravera également ses désavantages. 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 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 emprunté la voie du centrage au détriment de la performance ou de la confiance prédéfinie au détriment de l'efficacité, mais a réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une conception de protocole flexible, 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 être la véritable solution capable de soutenir le développement à long terme du Web3.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
22 J'aime
Récompense
22
6
Partager
Commentaire
0/400
DuskSurfer
· 07-09 17:45
C'est une bonne chose que le DOT ne soit pas mort.
Voir l'originalRépondre0
StakeOrRegret
· 07-09 03:46
老盖被dot prendre les gens pour des idiots麻了
Voir l'originalRépondre0
CryptoPunster
· 07-09 03:45
Nous en sommes à la phase de discussion sur le triangle sacrificiel, il est évident qui est accroupi et qui est debout.
Voir l'originalRépondre0
Token_Sherpa
· 07-09 03:43
meh... un autre L1 promettant la sainte trinité de la scalabilité. déjà vu, déjà fait, perdu de l'argent sur les ICO smh
Voir l'originalRépondre0
OnchainSniper
· 07-09 03:42
Il vaut mieux parler directement des données de performance.
Voir l'originalRépondre0
SelfCustodyBro
· 07-09 03:31
Ne parlons pas d'extension, parlons plutôt de la chute terrible de dot aujourd'hui.
Comment Polkadot réalise-t-il une haute performance d'extension sans sacrifier la sécurité et la Décentralisation
Les compromis et défis de l'évolutivité de la Blockchain : La solution de Polkadot
Dans un monde où la technologie Blockchain recherche constamment une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances sans sacrifier la sécurité et la résilience du système ? 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 construit sur le sacrifice de la confiance et de la sécurité est souvent difficile à soutenir pour une véritable innovation durable.
Polkadot, en tant qu'importante force motrice de l'évolutivité Web3, a-t-il fait des concessions en matière de décentralisation, de sécurité ou d'interopérabilité réseau avec son modèle de rollup ? Cet article analysera en profondeur les compromis et les arbitrages de Polkadot dans la conception de son évolutivité, et comparera ces choix avec les solutions d'autres chaînes de blocs majeures, en explorant leurs différentes approches 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 l'élasticité et la décentralisation
L'architecture de Polkadot repose sur un réseau de validateurs et une chaîne de relais (Relay Chain), ce qui peut introduire des risques de centralisation dans certains aspects. Le fonctionnement des Rollups dépend des séquenceurs (sequencer) connectés à la chaîne de relais, dont la communication utilise le mécanisme de 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 des rollups.
Compromis sur l'expansion verticale
Le Rollup peut réaliser une mise à l'échelle verticale en tirant parti de l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité "Elastic Scaling". Cependant, comme la validation des blocs rollup n'est pas fixée à un core particulier, cela peut affecter son élasticité. Les attaquants pourraient en tirer parti en soumettant à plusieurs reprises des blocs légitimes déjà validés sur différents cores, consommant ainsi malicieusement des ressources et réduisant le débit et l'efficacité globaux du rollup.
Problèmes de confiance du Séquenceur
Une solution simple consiste à configurer le protocole comme "ayant une licence", par exemple en adoptant un mécanisme de liste blanche, ou en supposant par défaut que le séquenceur ne se comporte pas de manière malveillante. Cependant, dans la philosophie de conception de Polkadot, aucune hypothèse de confiance ne peut être faite sur le séquenceur, car il est nécessaire de maintenir les caractéristiques "sans confiance" et "sans permission" du système.
La solution de Polkadot
La solution finalement choisie par Polkadot est de laisser le problème entièrement à la fonction de transition d'état du rollup (Runtime). Le Runtime est la seule source fiable de toutes les informations de consensus et doit clairement indiquer dans la sortie sur quel core de Polkadot la vérification doit être effectuée.
Ce design assure une double garantie de flexibilité et de sécurité. Polkadot réexécutera la transformation d'état de rollup dans le processus de disponibilité et garantira la justesse de l'allocation du core grâce au protocole économique ELVES.
Avant qu'un bloc rollup ne soit écrit dans la couche de disponibilité des données (DA) de Polkadot, un groupe composé d'environ 5 validateurs va d'abord vérifier sa 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ée par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de core, qui est 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 ainsi que des acteurs malveillants comme les ordonneurs ne manipulent les positions de validation, assurant ainsi que même si le rollup utilise plusieurs core, il peut maintenir sa résilience.
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 complètement sa sécurité à tous les rollups, vérifiant tous les calculs sur le core, sans aucune restriction ou hypothèse concernant le nombre de cores utilisés.
Universalité
L'extension élastique ne limite 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 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é constant. Ils doivent également respecter partiellement les 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 reposer 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, et l'évolutivité élastique n'affecte pas le débit des communications. La communication entre 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 sont attribués.
À l'avenir, Polkadot prendra également en charge la messagerie hors chaîne, avec la chaîne de relais comme interface de contrôle, et non comme interface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups avec une extension élastique, renforçant ainsi davantage la capacité d'extension verticale du système.
Équilibres d'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'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 utilise une architecture à haute capacité de traitement à couche unique pour réaliser l'évolutivité, s'appuyant sur la preuve historique (PoH), le traitement parallèle sur CPU et un mécanisme de consensus basé sur un leader, avec un TPS théorique pouvant atteindre 65 000. Son design clé est un mécanisme de planification des leaders qui est préalablement public et vérifiable.
Cependant, le 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, 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'un effondrement du système après une 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 de celui de Polkadot qui est de 172.
TON
TON prétend que le TPS peut atteindre 104 715, mais ce chiffre a été 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. 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 des fragments peut être exposée à l'avance. Le livre blanc de TON indique également que cela peut optimiser la bande passante, mais pourrait également ê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 fragment soit entièrement contrôlé par lui, ou interrompre les validateurs honnêtes par des attaques DDoS, afin de falsifier 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. Pour réussir une attaque, ils doivent parier sur le contrôle total ; tant qu'un validateur honnête soulève une contestation, l'attaque échoue et entraîne des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseaux 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 théoriquement atteindre ~5 000 TPS, similaire à l'idée de Polkadot : réduire la charge d'un seul shard pour réaliser l'évolutivité.
Mais Avalanche permet aux validateurs de choisir librement de participer à des sous-réseaux, et ces sous-réseaux peuvent imposer des exigences géographiques, de KYC, etc., 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 peuvent même être complètement centralisés. Pour améliorer la sécurité, il faut néanmoins 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 l'évolutivité de la couche rollup, plutôt que de résoudre les problèmes directement dans la couche de base. Cette approche n'a fondamentalement pas résolu le problème, mais a plutôt transféré le problème à la couche supérieure de la pile.
La plupart des Optimistic Rollups sont actuellement centralisés, ce qui pose 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 quelques jours).
La mise en œuvre de ZK Rollup est limitée par la quantité de données pouvant être traitées par une seule transaction. Les exigences de calcul pour générer des preuves à divulgation nulle de connaissance sont très élevées, et le mécanisme "le gagnant emporte tout" tend à centraliser le 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 gas lors d'une forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût des ZK rollups Turing-complets est environ 2x10^6 fois celui du protocole de sécurité économique central de Polkadot. De plus, le problème de la disponibilité des données des ZK rollups aggravera également ses désavantages. 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 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 emprunté la voie du centrage au détriment de la performance ou de la confiance prédéfinie au détriment de l'efficacité, mais a réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une conception de protocole flexible, 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 être la véritable solution capable de soutenir le développement à long terme du Web3.