Le compromis et l'équilibre de l'évolutivité de la Blockchain : l'exemple de Polkadot
Aujourd'hui, alors que la technologie Blockchain cherche constamment à atteindre une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances d'expansion 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 d'architecture. Pour l'écosystème Web3, un système plus rapide basé sur la compromission de la confiance et de la sécurité a généralement du mal à soutenir une véritable innovation durable.
En tant qu'important moteur de scalabilité pour le 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 compromis sur la décentralisation, la sécurité ou l'interopérabilité du réseau ? Cet article abordera ces questions, en analysant en profondeur les compromis et les choix de conception de Polkadot en matière de scalabilité, et en les comparant aux solutions d'autres chaînes de blocs majeures, explorant leurs différentes trajectoires entre performance, sécurité et décentralisation.
Les défis de la conception d'expansion de Polkadot
É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 former un point de défaillance unique ou un contrôle, ce qui affecterait ses caractéristiques de décentralisation ?
Le fonctionnement des Rollups dépend d'un ordonneur de la chaîne de relais connecté, dont la communication utilise un mécanisme appelé 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 relais et soumettre des demandes de transition d'état de Rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition qu'une seule condition soit remplie : la transition d'état doit être valide, 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é « scalabilité élastique ». Au cours du processus de conception, il a été constaté que, étant donné que la validation des blocs de rollup n'est pas fixée sur un core particulier, cela pourrait affecter son élasticité.
Puisque 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 assigné au rollup pour validation. Un attaquant pourrait exploiter cela en soumettant de manière répétée des blocs légitimes déjà vérifiés à différents cores, 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 de relais, sans compromettre les caractéristiques clés du système.
Sequencer est-il digne de confiance ?
Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, adopter un mécanisme de liste blanche, ou faire confiance par défaut aux ordonneurs qui ne se comportent pas de manière malveillante, garantissant ainsi l'activité du rollup.
Cependant, dans la 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 «sans confiance» et «sans permission» du système. Quiconque devrait pouvoir soumettre une demande de transition d'état de rollup en utilisant le protocole de collator.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier complètement le problème à la fonction de conversion d'état (Runtime) des rollups. 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 l'exécution de la vérification doit avoir lieu.
Ce design assure à la fois la flexibilité et la sécurité. Polkadot réexécutera les transitions d'état des rollups dans le processus de disponibilité et garantira la justesse de l'allocation du core grâce au protocole économique cryptographique ELVES.
Avant qu'un bloc rollup n'écrive dans la couche de disponibilité des données 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é soumises par le triant, 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ées par les validateurs sur la chaîne relais.
Le résultat de la vérification contient un sélecteur de core, qui sert à spécifier sur quel core le bloc doit être vérifié. Le validateur comparera si cet index correspond à celui du core dont il est responsable ; si ce n'est pas le cas, le bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours des attributs sans confiance et sans autorisation, évitant que des acteurs malveillants comme des ordonnanceurs manipulent les positions de vérification, assurant ainsi que même lorsque le rollup utilise plusieurs cœurs, 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 assurée par la chaîne de relais, nécessitant seulement un ordonneur honnête pour maintenir la viabilité.
Grâce au protocole ELVES, Polkadot étend intégralement sa sécurité à tous les rollups, validant tous les calculs sur le core, sans aucune restriction ou hypothèse concernant 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 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 chaque exécution est terminée en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calcul pouvant être exécutée tous les 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é, 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 des stratégies de gestion des ressources du rollup, qui peuvent dépendre de 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 une charge de transaction spécifique dans le mempool du nœud ;
Stratégies automatisées : configuration des ressources en appelant à l'avance le service coretime via les données historiques et l'interface XCM.
Bien que les méthodes automatisées 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'extensibilité é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, 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, plutôt que comme interface de données. Cette mise à niveau permettra d'améliorer la capacité de communication entre les rollups avec une scalabilité élastique, renforçant ainsi davantage la capacité d'extension verticale du système.
Quels compromis d'autres protocoles ont-ils faits ?
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 du point de vue du coefficient de Nakamoto, même si certains concurrents de Polkadot présentent un degré 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, 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 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 du montant des mises ;
Plus vous misez, plus vous êtes distribué. Par exemple, un validateurs misant 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 que le réseau subisse des attaques DDoS ciblées et des pannes fréquentes.
L'histoire prouve que le traitement parallèle exige des ressources matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud stake est élevé, plus ses chances de produire un bloc sont grandes, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave davantage la centralisation et augmente le risque d'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 est réalisé sur un réseau de test privé, avec 256 nœuds, dans des conditions réseau et matérielles idéales. Pendant ce temps, 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 est 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 d'un mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit entièrement contrôlé par lui ou perturber les validateurs honnêtes par une attaque DDoS, ce qui permet de falsifier l'état.
En comparaison, les validateurs de Polkadot sont attribués de manière aléatoire et révélés après un certain délai, rendant impossible pour un attaquant de connaître à l'avance l'identité des validateurs. L'attaque nécessite de parier sur l'ensemble du contrôle pour réussir ; tant qu'un seul validateurs honnête soulève une contestation, l'attaque échoue et entraîne la perte de la mise de 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 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 les sous-réseaux peuvent imposer des exigences géographiques, 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 cependant faire des compromis sur la performance, et il est difficile de fournir des promesses 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 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.
Optimistic Rollup
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 mutuel et de délais élevés (nécessitant d'attendre 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 extrêmement élevées, et le mécanisme du "gagnant prend tout" tend à 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 gas en période de 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 de base de Polkadot.
De plus, les problèmes de disponibilité des données liés au ZK rollup exacerbent également ses inconvénients. Pour garantir que quiconque puisse vérifier les transactions, il est toujours 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 emprunté la voie de la centralisation pour améliorer les performances ou d'une confiance présumé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 mise à l'échelle é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, la "scalabilité sans confiance" défendue 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.
Polkadot extensibilité élastique : rechercher un équilibre entre performance et Décentralisation
Le compromis et l'équilibre de l'évolutivité de la Blockchain : l'exemple de Polkadot
Aujourd'hui, alors que la technologie Blockchain cherche constamment à atteindre une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances d'expansion 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 d'architecture. Pour l'écosystème Web3, un système plus rapide basé sur la compromission de la confiance et de la sécurité a généralement du mal à soutenir une véritable innovation durable.
En tant qu'important moteur de scalabilité pour le 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 compromis sur la décentralisation, la sécurité ou l'interopérabilité du réseau ? Cet article abordera ces questions, en analysant en profondeur les compromis et les choix de conception de Polkadot en matière de scalabilité, et en les comparant aux solutions d'autres chaînes de blocs majeures, explorant leurs différentes trajectoires entre performance, sécurité et décentralisation.
Les défis de la conception d'expansion de Polkadot
É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 former un point de défaillance unique ou un contrôle, ce qui affecterait ses caractéristiques de décentralisation ?
Le fonctionnement des Rollups dépend d'un ordonneur de la chaîne de relais connecté, dont la communication utilise un mécanisme appelé 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 relais et soumettre des demandes de transition d'état de Rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition qu'une seule condition soit remplie : la transition d'état doit être valide, 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é « scalabilité élastique ». Au cours du processus de conception, il a été constaté que, étant donné que la validation des blocs de rollup n'est pas fixée sur un core particulier, cela pourrait affecter son élasticité.
Puisque 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 assigné au rollup pour validation. Un attaquant pourrait exploiter cela en soumettant de manière répétée des blocs légitimes déjà vérifiés à différents cores, 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 de relais, sans compromettre les caractéristiques clés du système.
Sequencer est-il digne de confiance ?
Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, adopter un mécanisme de liste blanche, ou faire confiance par défaut aux ordonneurs qui ne se comportent pas de manière malveillante, garantissant ainsi l'activité du rollup.
Cependant, dans la 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 «sans confiance» et «sans permission» du système. Quiconque devrait pouvoir soumettre une demande de transition d'état de rollup en utilisant le protocole de collator.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier complètement le problème à la fonction de conversion d'état (Runtime) des rollups. 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 l'exécution de la vérification doit avoir lieu.
Ce design assure à la fois la flexibilité et la sécurité. Polkadot réexécutera les transitions d'état des rollups dans le processus de disponibilité et garantira la justesse de l'allocation du core grâce au protocole économique cryptographique ELVES.
Avant qu'un bloc rollup n'écrive dans la couche de disponibilité des données 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é soumises par le triant, 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ées par les validateurs sur la chaîne relais.
Le résultat de la vérification contient un sélecteur de core, qui sert à spécifier sur quel core le bloc doit être vérifié. Le validateur comparera si cet index correspond à celui du core dont il est responsable ; si ce n'est pas le cas, le bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours des attributs sans confiance et sans autorisation, évitant que des acteurs malveillants comme des ordonnanceurs manipulent les positions de vérification, assurant ainsi que même lorsque le rollup utilise plusieurs cœurs, 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 assurée par la chaîne de relais, nécessitant seulement un ordonneur honnête pour maintenir la viabilité.
Grâce au protocole ELVES, Polkadot étend intégralement sa sécurité à tous les rollups, validant tous les calculs sur le core, sans aucune restriction ou hypothèse concernant 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 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 chaque exécution est terminée en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calcul pouvant être exécutée tous les 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é, 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 des stratégies de gestion des ressources du rollup, qui peuvent dépendre de 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 une charge de transaction spécifique dans le mempool du nœud ;
Stratégies automatisées : configuration des ressources en appelant à l'avance le service coretime via les données historiques et l'interface XCM.
Bien que les méthodes automatisées 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'extensibilité é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, 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, plutôt que comme interface de données. Cette mise à niveau permettra d'améliorer la capacité de communication entre les rollups avec une scalabilité élastique, renforçant ainsi davantage la capacité d'extension verticale du système.
Quels compromis d'autres protocoles ont-ils faits ?
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 du point de vue du coefficient de Nakamoto, même si certains concurrents de Polkadot présentent un degré 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, 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 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 du montant des mises ;
Plus vous misez, plus vous êtes distribué. Par exemple, un validateurs misant 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 que le réseau subisse des attaques DDoS ciblées et des pannes fréquentes.
L'histoire prouve que le traitement parallèle exige des ressources matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud stake est élevé, plus ses chances de produire un bloc sont grandes, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave davantage la centralisation et augmente le risque d'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 est réalisé sur un réseau de test privé, avec 256 nœuds, dans des conditions réseau et matérielles idéales. Pendant ce temps, 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 est 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 d'un mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit entièrement contrôlé par lui ou perturber les validateurs honnêtes par une attaque DDoS, ce qui permet de falsifier l'état.
En comparaison, les validateurs de Polkadot sont attribués de manière aléatoire et révélés après un certain délai, rendant impossible pour un attaquant de connaître à l'avance l'identité des validateurs. L'attaque nécessite de parier sur l'ensemble du contrôle pour réussir ; tant qu'un seul validateurs honnête soulève une contestation, l'attaque échoue et entraîne la perte de la mise de 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 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 les sous-réseaux peuvent imposer des exigences géographiques, 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 cependant faire des compromis sur la performance, et il est difficile de fournir des promesses 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 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.
Optimistic Rollup
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 mutuel et de délais élevés (nécessitant d'attendre 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 extrêmement élevées, et le mécanisme du "gagnant prend tout" tend à 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 gas en période de 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 de base de Polkadot.
De plus, les problèmes de disponibilité des données liés au ZK rollup exacerbent également ses inconvénients. Pour garantir que quiconque puisse vérifier les transactions, il est toujours 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 emprunté la voie de la centralisation pour améliorer les performances ou d'une confiance présumé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 mise à l'échelle é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, la "scalabilité sans confiance" défendue par Polkadot pourrait être la véritable solution capable de soutenir le développement à long terme du Web3.