Les compromis de l'évolutivité de la Blockchain : Exploration de Polkadot et de l'écosystème Web3
Aujourd'hui, alors que la Blockchain poursuit sans cesse une plus grande efficacité, une question clé se pose progressivement : comment améliorer les performances d'échelle tout en évitant de 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. Surtout pour l'écosystème Web3, un système plus rapide, s'il est construit au détriment de la confiance et de la sécurité, a souvent du mal à soutenir une innovation vraiment durable.
En tant qu'importante force motrice de l'évolutivité Web3, Polkadot a-t-il également fait certains sacrifices dans la poursuite 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é des réseaux ?
Cet article abordera ces questions, en analysant en profondeur les compromis et les choix de conception de l'évolutivité de Polkadot, et en les comparant aux solutions d'autres chaînes de blocs majeures, en explorant leurs différentes options entre performance, sécurité et décentralisation.
Les défis liés à la conception de l'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 (Relay Chain), cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible qu'un point de défaillance ou un contrôle se forme, affectant ainsi ses caractéristiques de décentralisation ?
Le fonctionnement des Rollups dépend du séquenceur (sequencer) qui relie la chaîne de relais, et sa communication utilise un mécanisme appelé le protocole collator. Ce protocole est complètement sans autorisation et sans confiance, toute personne disposant d'une connexion réseau peut l'utiliser, se connecter à un nombre limité de nœuds de la chaîne de relais et soumettre des demandes de transition d'état du rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition qu'elles satisfassent un prérequis : elles doivent être des transitions d'état valides, sinon l'état de ce rollup ne sera pas avancé.
Compromis d'extension verticale
Le Rollup peut réaliser une extension verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonction « Elastic Scaling ». Au cours du processus de conception, nous avons découvert que, puisque la validation des blocs de rollup n'est pas fixée à un core spécifique, cela peut affecter sa flexibilité.
Étant donné que le protocole de soumission des blocs à la chaîne de relais est sans permission et sans confiance, n'importe qui peut soumettre des blocs à n'importe quel core attribué au rollup pour validation. Les attaquants peuvent exploiter cela en soumettant de manière répétée des blocs légitimes déjà validés à différents cores, consommant ainsi malicieusement des ressources 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 relais, sans affecter les caractéristiques clés du système.
Sequencer est-il fiable ?
Une solution simple consiste à définir le protocole comme "avec licence" : par exemple, utiliser un mécanisme de liste blanche, ou faire en sorte que les ordonneurs par défaut ne se livrent pas à des comportements malveillants, 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 sequencer, car il est nécessaire de maintenir les caractéristiques de « sans confiance » et « sans autorisation » du système. Quiconque devrait pouvoir soumettre des demandes de transition d'état de rollup en utilisant le protocole collator.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier entièrement le problème à la fonction de conversion 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.
Cette conception garantit à la fois la flexibilité et la sécurité. Polkadot réexécutera la transformation d'état des rollups dans le processus de disponibilité et assurera la justesse de l'allocation du core par le biais du protocole économique crypté ELVES.
Avant l'écriture des données de la rollup Bloc dans la couche de disponibilité des données (DA) de Polkadot, un groupe composé d'environ 5 validateurs va d'abord vérifier leur légitimité. Ils reçoivent le reçu candidat (candidate receipt) soumis par le trieur et la preuve de validité (PoV), qui contient le Bloc de la rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, et seront réexécutées par les validateurs sur la chaîne de relais.
Le résultat de la validation contient un core selector, qui spécifie sur quel core le bloc doit être validé. Le validateur comparera cet index avec le core dont il est responsable ; s'il n'est pas cohérent, ce bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours des attributs sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants, tels que des ordonneurs, manipulent la position de validation, garantissant que même lorsque des rollups utilisent plusieurs cœurs, la résilience est maintenue.
Sécurité
Dans la quête de l'é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, et il suffit d'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 sur le nombre de cores utilisés.
Ainsi, le rollup de Polkadot peut 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é
Un débit plus élevé et une latence plus faible entraînent inévitablement une complexité, ce qui constitue 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 mettre en œuvre certaines exigences de la RFC103 pour s'adapter à différents scénarios d'utilisation.
La complexité spécifique dépend des stratégies de gestion des ressources du rollup, qui peuvent s'appuyer sur des variables on-chain ou off-chain. Par exemple :
Stratégie simple : toujours utiliser un nombre fixe de core, ou ajuster manuellement hors chaîne ;
Stratégie légère : surveiller les charges transactionnelles spécifiques dans le mempool des nœuds ;
Stratégies automatisées : configurer les ressources à l'avance en appelant le service coretime via les données historiques et l'interface XCM.
Bien que les méthodes d'automatisation soient plus efficaces, 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é é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, 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 (off-chain messaging), avec la chaîne de relais servant de couche de contrôle, plutôt que de couche 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.
Quels compromis ont été faits par d'autres protocoles ?
Comme tout le monde le sait, l'amélioration des performances est souvent réalisée au prix de la décentralisation et de la sécurité. Cependant, d'après le coefficient de Nakamoto, même si certains concurrents de Polkadot ont un niveau 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é avec une architecture à haute capacité de traitement à couche unique, 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 :
Au début de chaque epoch (environ deux jours ou 432 000 slots), les slots sont attribués en fonction de la quantité de mise;
Plus vous misez, plus vous recevez. Par exemple, un validateurs qui mise 1% obtiendra environ 1% de chances de produire un bloc ;
Tous les producteurs de blocs sont annoncés à l'avance, ce qui augmente le risque de DDoS ciblé sur le réseau et de pannes fréquentes.
PoH et le traitement parallèle exigent des exigences matérielles très élevées, ce qui conduit à la centralisation des nœuds de validation. Plus un nœud stake est important, plus ses chances de produire des blocs sont grandes, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave encore la centralisation et augmente le risque d'effondrement du système après une attaque.
Solana a sacrifié la décentralisation et la 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 prétend que le TPS peut atteindre 104 715, mais ce chiffre a été réalisé 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é.
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, bien que cela puisse optimiser la bande passante, cela 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 fragment soit entièrement 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. Pour réussir une attaque, ils doivent parier sur le contrôle total. Tant qu'il y a un validateur honnête qui initie une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseaux pour l'évolutivité. 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 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é. Mais Avalanche permet aux validateurs de choisir librement de participer à un sous-réseau, et les 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 garanties 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 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 de rollup, plutôt que de résoudre les problèmes directement au niveau de la couche de base. Cette approche ne résout essentiellement 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 (certains n'ont même qu'un seul séquenceur), ce qui entraîne 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 de 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. La demande de calcul pour générer des preuves à divulgation nulle est extrêmement élevée, et le mécanisme du "gagnant emporte 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 rollups 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 aggraveront é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 souvent sur des solutions supplémentaires de disponibilité des données, 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, Polkadot n'a pas emprunté la voie de la centralisation pour obtenir des performances ou de la confiance présupposée pour gagner en 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 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 bien être la véritable solution capable de soutenir le développement à long terme de 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.
14 J'aime
Récompense
14
5
Partager
Commentaire
0/400
SignatureCollector
· 07-30 01:18
Point de chaîne, ça monte vite, ça monte vite
Voir l'originalRépondre0
ForumMiningMaster
· 07-30 01:15
Pour gagner 100 000 par mois, il suffit de ces quelques chaînes.
Voir l'originalRépondre0
LostBetweenChains
· 07-30 01:12
Il suffit d'augmenter la position de BTC ordinaire.
Polkadot extensibilité élastique : le chemin vers une haute performance Web3 sans compromis
Les compromis de l'évolutivité de la Blockchain : Exploration de Polkadot et de l'écosystème Web3
Aujourd'hui, alors que la Blockchain poursuit sans cesse une plus grande efficacité, une question clé se pose progressivement : comment améliorer les performances d'échelle tout en évitant de 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. Surtout pour l'écosystème Web3, un système plus rapide, s'il est construit au détriment de la confiance et de la sécurité, a souvent du mal à soutenir une innovation vraiment durable.
En tant qu'importante force motrice de l'évolutivité Web3, Polkadot a-t-il également fait certains sacrifices dans la poursuite 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é des réseaux ?
Cet article abordera ces questions, en analysant en profondeur les compromis et les choix de conception de l'évolutivité de Polkadot, et en les comparant aux solutions d'autres chaînes de blocs majeures, en explorant leurs différentes options entre performance, sécurité et décentralisation.
Les défis liés à la conception de l'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 (Relay Chain), cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible qu'un point de défaillance ou un contrôle se forme, affectant ainsi ses caractéristiques de décentralisation ?
Le fonctionnement des Rollups dépend du séquenceur (sequencer) qui relie la chaîne de relais, et sa communication utilise un mécanisme appelé le protocole collator. Ce protocole est complètement sans autorisation et sans confiance, toute personne disposant d'une connexion réseau peut l'utiliser, se connecter à un nombre limité de nœuds de la chaîne de relais et soumettre des demandes de transition d'état du rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition qu'elles satisfassent un prérequis : elles doivent être des transitions d'état valides, sinon l'état de ce rollup ne sera pas avancé.
Compromis d'extension verticale
Le Rollup peut réaliser une extension verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonction « Elastic Scaling ». Au cours du processus de conception, nous avons découvert que, puisque la validation des blocs de rollup n'est pas fixée à un core spécifique, cela peut affecter sa flexibilité.
Étant donné que le protocole de soumission des blocs à la chaîne de relais est sans permission et sans confiance, n'importe qui peut soumettre des blocs à n'importe quel core attribué au rollup pour validation. Les attaquants peuvent exploiter cela en soumettant de manière répétée des blocs légitimes déjà validés à différents cores, consommant ainsi malicieusement des ressources 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 relais, sans affecter les caractéristiques clés du système.
Sequencer est-il fiable ?
Une solution simple consiste à définir le protocole comme "avec licence" : par exemple, utiliser un mécanisme de liste blanche, ou faire en sorte que les ordonneurs par défaut ne se livrent pas à des comportements malveillants, 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 sequencer, car il est nécessaire de maintenir les caractéristiques de « sans confiance » et « sans autorisation » du système. Quiconque devrait pouvoir soumettre des demandes de transition d'état de rollup en utilisant le protocole collator.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier entièrement le problème à la fonction de conversion 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.
Cette conception garantit à la fois la flexibilité et la sécurité. Polkadot réexécutera la transformation d'état des rollups dans le processus de disponibilité et assurera la justesse de l'allocation du core par le biais du protocole économique crypté ELVES.
Avant l'écriture des données de la rollup Bloc dans la couche de disponibilité des données (DA) de Polkadot, un groupe composé d'environ 5 validateurs va d'abord vérifier leur légitimité. Ils reçoivent le reçu candidat (candidate receipt) soumis par le trieur et la preuve de validité (PoV), qui contient le Bloc de la rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, et seront réexécutées par les validateurs sur la chaîne de relais.
Le résultat de la validation contient un core selector, qui spécifie sur quel core le bloc doit être validé. Le validateur comparera cet index avec le core dont il est responsable ; s'il n'est pas cohérent, ce bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours des attributs sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants, tels que des ordonneurs, manipulent la position de validation, garantissant que même lorsque des rollups utilisent plusieurs cœurs, la résilience est maintenue.
Sécurité
Dans la quête de l'é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, et il suffit d'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 sur le nombre de cores utilisés.
Ainsi, le rollup de Polkadot peut 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é
Un débit plus élevé et une latence plus faible entraînent inévitablement une complexité, ce qui constitue 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 mettre en œuvre certaines exigences de la RFC103 pour s'adapter à différents scénarios d'utilisation.
La complexité spécifique dépend des stratégies de gestion des ressources du rollup, qui peuvent s'appuyer sur des variables on-chain ou off-chain. Par exemple :
Stratégie simple : toujours utiliser un nombre fixe de core, ou ajuster manuellement hors chaîne ;
Stratégie légère : surveiller les charges transactionnelles spécifiques dans le mempool des nœuds ;
Stratégies automatisées : configurer les ressources à l'avance en appelant le service coretime via les données historiques et l'interface XCM.
Bien que les méthodes d'automatisation soient plus efficaces, 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é é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, 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 (off-chain messaging), avec la chaîne de relais servant de couche de contrôle, plutôt que de couche 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.
Quels compromis ont été faits par d'autres protocoles ?
Comme tout le monde le sait, l'amélioration des performances est souvent réalisée au prix de la décentralisation et de la sécurité. Cependant, d'après le coefficient de Nakamoto, même si certains concurrents de Polkadot ont un niveau 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é avec une architecture à haute capacité de traitement à couche unique, 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 :
Au début de chaque epoch (environ deux jours ou 432 000 slots), les slots sont attribués en fonction de la quantité de mise;
Plus vous misez, plus vous recevez. Par exemple, un validateurs qui mise 1% obtiendra environ 1% de chances de produire un bloc ;
Tous les producteurs de blocs sont annoncés à l'avance, ce qui augmente le risque de DDoS ciblé sur le réseau et de pannes fréquentes.
PoH et le traitement parallèle exigent des exigences matérielles très élevées, ce qui conduit à la centralisation des nœuds de validation. Plus un nœud stake est important, plus ses chances de produire des blocs sont grandes, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave encore la centralisation et augmente le risque d'effondrement du système après une attaque.
Solana a sacrifié la décentralisation et la 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 prétend que le TPS peut atteindre 104 715, mais ce chiffre a été réalisé 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é.
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, bien que cela puisse optimiser la bande passante, cela 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 fragment soit entièrement 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. Pour réussir une attaque, ils doivent parier sur le contrôle total. Tant qu'il y a un validateur honnête qui initie une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseaux pour l'évolutivité. 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 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é. Mais Avalanche permet aux validateurs de choisir librement de participer à un sous-réseau, et les 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 garanties 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 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 de rollup, plutôt que de résoudre les problèmes directement au niveau de la couche de base. Cette approche ne résout essentiellement 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 (certains n'ont même qu'un seul séquenceur), ce qui entraîne 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 de 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. La demande de calcul pour générer des preuves à divulgation nulle est extrêmement élevée, et le mécanisme du "gagnant emporte 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 rollups 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 aggraveront é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 souvent sur des solutions supplémentaires de disponibilité des données, 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, Polkadot n'a pas emprunté la voie de la centralisation pour obtenir des performances ou de la confiance présupposée pour gagner en 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 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 bien être la véritable solution capable de soutenir le développement à long terme de Web3.