La balance de l'évolutivité de la Blockchain : Choix entre Polkadot et Web3
Dans un monde où la Blockchain cherche sans cesse à améliorer son efficacité, une question clé émerge progressivement : comment améliorer les performances d'extension tout en évitant de compromettre 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, se contenter de rechercher des systèmes plus rapides tout en négligeant la confiance et la sécurité rend difficile le soutien d'une véritable innovation durable.
En tant que moteur important de la scalabilité Web3, Polkadot a-t-il fait certains compromis dans sa quête d'un haut débit et d'une faible latence ? Son modèle de rollup fait-il des compromis sur la décentralisation, la sécurité ou l'interopérabilité du réseau ?
Cet article discutera de ces questions, analysera en profondeur les compromis de conception d'évolutivité de Polkadot et comparera ces solutions à celles d'autres blockchains majeures, en explorant leurs choix différents en matière de performance, de sécurité et de décentralisation.
Les défis de la conception d'extension de Polkadot
L'équilibre entre la flexibilité et la décentralisation
L'architecture de Polkadot repose sur un réseau de validateurs et une chaîne de relais. Cela pourrait-il introduire des risques de centralisation d'une certaine manière ? Y a-t-il un risque de point de défaillance unique ou de contrôle, ce qui pourrait affecter ses caractéristiques de décentralisation ?
Le fonctionnement de Rollup dépend d'un ordonnanceur de chaîne de relais, dont la communication utilise le mécanisme de protocole collator. Ce protocole est entièrement sans permission 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 de rollup. Ces demandes seront vérifiées par un certain core de la chaîne de relais, à condition de respecter un préalable : il doit s'agir d'une transition d'état valide, sinon l'état de ce rollup ne sera pas avancé.
compromis sur l'expansion verticale
Le Rollup peut réaliser une mise à l'échelle verticale en exploitant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonction « mise à l'échelle é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é.
Comme le protocole de soumission des blocs à la chaîne de relais est sans autorisation et sans confiance, tout le monde peut soumettre un bloc à n'importe quel core attribué au rollup pour vérification. Un attaquant pourrait en profiter pour soumettre à plusieurs reprises des blocs légitimes déjà vérifié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 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 "autorisé" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut à l'ordonnanceur qui ne se comportera 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 être en mesure d'utiliser le protocole collateur pour soumettre des demandes de transition d'état de rollup.
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) du rollup. Le Runtime est la seule source fiable de toutes les informations de consensus, il doit donc être clairement indiqué dans la sortie où la validation doit être effectuée sur le noyau Polkadot.
Ce design offre une double garantie d'élasticité et de sécurité. Polkadot réexécutera les transitions d'état du rollup dans le processus de disponibilité et garantira la justesse de l'allocation de core grâce au protocole économique cryptographique ELVES.
Avant l'écriture des données sur la couche de disponibilité de Polkadot dans tout bloc rollup, un groupe composé d'environ 5 validateurs vérifiera d'abord leur légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le ordonneur, qui contiennent le bloc rollup et la preuve de stockage correspondante. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, exécutée à nouveau par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de core, utilisé pour spécifier sur quel core le bloc doit être vérifié. Le validateur comparera cet index pour voir s'il correspond à son core attribué ; s'il n'est pas conforme, 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 tels que les ordonneurs ne manipulent la position de validation, assurant 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 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, en validant tous les calculs sur le core, sans aucune restriction ou hypothèse sur le nombre de cores utilisés.
Par conséquent, 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 qu'une seule exécution est complétée en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécutés par 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 introduisent inévitablement de la complexité, ce qui est le seul compromis acceptable dans la conception des systèmes.
Les Rollups peuvent ajuster dynamiquement les ressources via l'interface Agile Coretime pour maintenir un niveau de sécurité cohérent. Ils doivent également 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 : utilisez toujours un nombre fixe de core, ou ajustez manuellement hors chaîne ;
Stratégie légère : surveiller une charge de transaction spécifique dans le mempool des nœuds ;
Stratégies automatisées : Configurer les ressources en appelant à l'avance le service coretime via des données historiques et l'interface XCM.
Bien que la méthode automatisée soit plus efficace, les coûts de mise en œuvre et de test augmentent également de manière significative.
Interopérabilité
Polkadot prend en charge l'interopérabilité entre différents rollups, tandis que l'évolutivité flexible n'affecte pas le débit 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 couche de contrôle, plutôt que comme couche de données. Cette mise à niveau améliorera la capacité de communication entre les rollups tout en augmentant l'évolutivité de manière élastique, renforçant ainsi la capacité d'évolutivité 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 ont un niveau de décentralisation relativement faible, leurs performances ne sont pas satisfaisantes.
Solana
Solana n'adopte pas l'architecture de sharding de Polkadot ou d'Ethereum, mais réalise l'évolutivité avec 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 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 staké ;
Plus vous misez, plus vous êtes réparti. Par exemple, un validateur 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.
PoH et le traitement parallèle exigent des ressources matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud a de mises en jeu, plus il a de chances de produire un bloc, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave encore la centralisation et augmente le risque que le système s'effondre après une 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 des 172 de Polkadot.
TON
TON prétend un TPS pouvant atteindre 104 715, mais ce chiffre a été réalisé sur un réseau de test privé, avec 256 nœuds, dans des conditions réseau et matérielles idéales. Polkadot a atteint 128K TPS sur un réseau public décentralisé.
Le mécanisme de consensus de TON présente des risques 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 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 complètement contrôlé par lui, ou bloquer les validateurs honnêtes par une attaque DDoS, permettant ainsi de falsifier l'état.
En revanche, les validateurs de Polkadot sont attribués de manière aléatoire et révélés avec un délai, ce qui empêche les attaquants de 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 soulève une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseau pour s'étendre, 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 seul shard pour réaliser l'évolutivité. Cependant, Avalanche permet aux validateurs de choisir librement de participer à des sous-réseaux, qui peuvent imposer des exigences supplémentaires telles que 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 totalement centralisés. Pour améliorer la sécurité, il est nécessaire de faire des compromis sur la performance et il est difficile de fournir un engagement de sécurité déterministe.
Ethereum
La stratégie d'extension d'Ethereum parie sur la scalabilité de la couche rollup, plutôt que de résoudre directement les problèmes au niveau de la couche de base. Cette approche n'a essentiellement 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 entraîne 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 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 à connaissance nulle sont extrêmement élevées, et le mécanisme de "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 hausse des gas en période de forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût du ZK rollup Turing-complet est 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 aggravera é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 dépend généralement de 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 choisi la voie de la centralisation au détriment de la performance ni celle de la confiance prédéfinie au détriment de l'efficacité, mais a réalisé un équilibre multidimensionnel entre la sécurité, la décentralisation et la 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 mise en œuvre à 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.
16 J'aime
Récompense
16
6
Reposter
Partager
Commentaire
0/400
Fren_Not_Food
· 07-23 13:22
Le projet a l'air prometteur, voyons les performances réelles.
Voir l'originalRépondre0
BlockchainDecoder
· 07-23 11:10
Selon les données récentes du groupe de recherche Cho, le TPS d'une chaîne unique est généralement inférieur à 3k, et les problèmes d'équilibre doivent être résolus de toute urgence.
Voir l'originalRépondre0
GasGuzzler
· 07-21 02:15
L'extension purement linéaire ne peut pas gagner.
Voir l'originalRépondre0
DataOnlooker
· 07-21 02:15
Regardez encore~ DOT n'a toujours pas décollé.
Voir l'originalRépondre0
LidoStakeAddict
· 07-21 02:04
C'est bien dit, tout disparaît en un mot.
Voir l'originalRépondre0
LiquidatedTwice
· 07-21 02:04
dot est l'avenir, ni trop positif ni trop négatif.
Polkadot : une nouvelle option pour l'écosystème Web3 sans compromis sur l'évolutivité
La balance de l'évolutivité de la Blockchain : Choix entre Polkadot et Web3
Dans un monde où la Blockchain cherche sans cesse à améliorer son efficacité, une question clé émerge progressivement : comment améliorer les performances d'extension tout en évitant de compromettre 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, se contenter de rechercher des systèmes plus rapides tout en négligeant la confiance et la sécurité rend difficile le soutien d'une véritable innovation durable.
En tant que moteur important de la scalabilité Web3, Polkadot a-t-il fait certains compromis dans sa quête d'un haut débit et d'une faible latence ? Son modèle de rollup fait-il des compromis sur la décentralisation, la sécurité ou l'interopérabilité du réseau ?
Cet article discutera de ces questions, analysera en profondeur les compromis de conception d'évolutivité de Polkadot et comparera ces solutions à celles d'autres blockchains majeures, en explorant leurs choix différents en matière de performance, de sécurité et de décentralisation.
Les défis de la conception d'extension de Polkadot
L'équilibre entre la flexibilité et la décentralisation
L'architecture de Polkadot repose sur un réseau de validateurs et une chaîne de relais. Cela pourrait-il introduire des risques de centralisation d'une certaine manière ? Y a-t-il un risque de point de défaillance unique ou de contrôle, ce qui pourrait affecter ses caractéristiques de décentralisation ?
Le fonctionnement de Rollup dépend d'un ordonnanceur de chaîne de relais, dont la communication utilise le mécanisme de protocole collator. Ce protocole est entièrement sans permission 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 de rollup. Ces demandes seront vérifiées par un certain core de la chaîne de relais, à condition de respecter un préalable : il doit s'agir d'une transition d'état valide, sinon l'état de ce rollup ne sera pas avancé.
compromis sur l'expansion verticale
Le Rollup peut réaliser une mise à l'échelle verticale en exploitant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonction « mise à l'échelle é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é.
Comme le protocole de soumission des blocs à la chaîne de relais est sans autorisation et sans confiance, tout le monde peut soumettre un bloc à n'importe quel core attribué au rollup pour vérification. Un attaquant pourrait en profiter pour soumettre à plusieurs reprises des blocs légitimes déjà vérifié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 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 "autorisé" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut à l'ordonnanceur qui ne se comportera 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 être en mesure d'utiliser le protocole collateur pour soumettre des demandes de transition d'état de rollup.
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) du rollup. Le Runtime est la seule source fiable de toutes les informations de consensus, il doit donc être clairement indiqué dans la sortie où la validation doit être effectuée sur le noyau Polkadot.
Ce design offre une double garantie d'élasticité et de sécurité. Polkadot réexécutera les transitions d'état du rollup dans le processus de disponibilité et garantira la justesse de l'allocation de core grâce au protocole économique cryptographique ELVES.
Avant l'écriture des données sur la couche de disponibilité de Polkadot dans tout bloc rollup, un groupe composé d'environ 5 validateurs vérifiera d'abord leur légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le ordonneur, qui contiennent le bloc rollup et la preuve de stockage correspondante. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, exécutée à nouveau par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de core, utilisé pour spécifier sur quel core le bloc doit être vérifié. Le validateur comparera cet index pour voir s'il correspond à son core attribué ; s'il n'est pas conforme, 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 tels que les ordonneurs ne manipulent la position de validation, assurant 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 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, en validant tous les calculs sur le core, sans aucune restriction ou hypothèse sur le nombre de cores utilisés.
Par conséquent, 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 qu'une seule exécution est complétée en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécutés par 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 introduisent inévitablement de la complexité, ce qui est le seul compromis acceptable dans la conception des systèmes.
Les Rollups peuvent ajuster dynamiquement les ressources via l'interface Agile Coretime pour maintenir un niveau de sécurité cohérent. Ils doivent également 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 :
Bien que la méthode automatisée soit plus efficace, les coûts de mise en œuvre et de test augmentent également de manière significative.
Interopérabilité
Polkadot prend en charge l'interopérabilité entre différents rollups, tandis que l'évolutivité flexible n'affecte pas le débit 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 couche de contrôle, plutôt que comme couche de données. Cette mise à niveau améliorera la capacité de communication entre les rollups tout en augmentant l'évolutivité de manière élastique, renforçant ainsi la capacité d'évolutivité 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 ont un niveau de décentralisation relativement faible, leurs performances ne sont pas satisfaisantes.
Solana
Solana n'adopte pas l'architecture de sharding de Polkadot ou d'Ethereum, mais réalise l'évolutivité avec 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 clé de la conception est son mécanisme de planification des leaders, qui est préalablement public et vérifiable :
PoH et le traitement parallèle exigent des ressources matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud a de mises en jeu, plus il a de chances de produire un bloc, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave encore la centralisation et augmente le risque que le système s'effondre après une 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 des 172 de Polkadot.
TON
TON prétend un TPS pouvant atteindre 104 715, mais ce chiffre a été réalisé sur un réseau de test privé, avec 256 nœuds, dans des conditions réseau et matérielles idéales. Polkadot a atteint 128K TPS sur un réseau public décentralisé.
Le mécanisme de consensus de TON présente des risques 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 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 complètement contrôlé par lui, ou bloquer les validateurs honnêtes par une attaque DDoS, permettant ainsi de falsifier l'état.
En revanche, les validateurs de Polkadot sont attribués de manière aléatoire et révélés avec un délai, ce qui empêche les attaquants de 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 soulève une contestation, l'attaque échouera et entraînera des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseau pour s'étendre, 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 seul shard pour réaliser l'évolutivité. Cependant, Avalanche permet aux validateurs de choisir librement de participer à des sous-réseaux, qui peuvent imposer des exigences supplémentaires telles que 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 totalement centralisés. Pour améliorer la sécurité, il est nécessaire de faire des compromis sur la performance et il est difficile de fournir un engagement de sécurité déterministe.
Ethereum
La stratégie d'extension d'Ethereum parie sur la scalabilité de la couche rollup, plutôt que de résoudre directement les problèmes au niveau de la couche de base. Cette approche n'a essentiellement 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 entraîne 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 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 à connaissance nulle sont extrêmement élevées, et le mécanisme de "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 hausse des gas en période de forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût du ZK rollup Turing-complet est 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 aggravera é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 dépend généralement de 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 choisi la voie de la centralisation au détriment de la performance ni celle de la confiance prédéfinie au détriment de l'efficacité, mais a réalisé un équilibre multidimensionnel entre la sécurité, la décentralisation et la 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 mise en œuvre à 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.