Les compromis de l'évolutivité de la Blockchain : Le choix entre Polkadot et Web3
Dans un monde où la technologie Blockchain cherche constamment une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances tout en maintenant 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 simplement plus rapide, s'il est construit sur le sacrifice de la confiance et de la sécurité, est souvent incapable de soutenir une véritable innovation durable.
En tant qu'important moteur de l'évolutivité du Web3, Polkadot a-t-il également fait certains compromis dans sa quête d'un haut débit et d'une faible latence ? Son modèle de rollup a-t-il fait des concessions en matière de décentralisation, de sécurité ou d'interopérabilité du réseau ? Cet article abordera ces questions, en analysant en profondeur les compromis et les arbitrages de Polkadot dans la conception de son évolutivité, et en les comparant aux solutions d'autres chaînes de blocs majeures, en explorant leurs différents choix de trajectoire entre performance, sécurité et décentralisation.
Les défis de la conception d'extension 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 centralisée, cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible de créer un point de défaillance unique ou un contrôle qui affecterait ses caractéristiques de décentralisation ?
Le fonctionnement du Rollup dépend d'un ordonneur de chaîne de relais connecté, dont la communication utilise un mécanisme appelé 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 du rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition d'une seule exigence : 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 mise à l'échelle verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonction "scalabilité élastique". Il a été constaté lors du processus de conception que, puisque la validation des blocs Rollup n'est pas fixée à un core particulier, 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, tout le monde peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. 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 et réduisant le débit global et l'efficacité du rollup.
L'objectif de Polkadot est de maintenir l'élasticité des rollups et une utilisation efficace des ressources de la chaîne de relais, sans compromettre les caractéristiques clés du système.
Sequencer est-il fiable ?
Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut aux ordonneurs qui ne se comportent 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 sequencer, car il est nécessaire de maintenir les caractéristiques de "sans confiance" et "sans autorisation" du système. Quiconque devrait être en mesure d'utiliser le protocole collator pour soumettre des demandes de transition d'état de rollup.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est la suivante : confier entièrement la question à 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 Polkadot la validation doit être effectuée.
Ce design assure une double garantie de flexibilité et de sécurité. Polkadot réexécutera les transitions d'état du rollup dans le processus de disponibilité et garantira l'exactitude de la répartition du core grâce au protocole économique cryptographique ELVES.
Avant que les données d'un bloc rollup ne soient écrites dans la couche de disponibilité des données de Polkadot, un groupe composé d'environ 5 validateurs vérifie d'abord leur légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le séquenceur, qui contiennent le bloc rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, et seront réexécutées par les validateurs sur la chaîne de relais.
Le résultat de la validation contient un sélecteur core, utilisé pour spécifier sur quel core le bloc doit être validé. Le validateur comparera cet index pour voir s'il correspond au core dont il est responsable ; s'il ne correspond pas, le bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours ses propriétés sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants comme les ordonnanceurs ne manipulent la position de validation, garantissant que même si le rollup utilise plusieurs cores, 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 sur le nombre de cores utilisés.
Ainsi, les rollups de Polkadot peuvent réaliser une véritable scalabilité 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 dans les 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être effectué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 réduite entraînent inévitablement une complexité, 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 cas d'utilisation.
La complexité spécifique dépend de la stratégie de gestion des ressources du rollup, qui peut 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 la charge de transaction spécifique dans le mempool des nœuds ;
Stratégie d'automatisation : Configurer les 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, et 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, l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui est attribué.
À l'avenir, Polkadot prendra également en charge la transmission de messages hors chaîne, avec la chaîne de relais comme surface de contrôle, plutôt que comme surface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups, augmentant 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 se fait souvent au détriment de la décentralisation et de la sécurité. Cependant, en regardant le coefficient de Nakamoto, même si certains concurrents de Polkadot ont un niveau de décentralisation inférieur, 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é grâce à une architecture à couche unique à haut débit, reposant sur la preuve d'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 de la mise ;
Plus vous misez, plus vous êtes distribué. 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 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, ce qui aggrave davantage 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 atteindre un TPS, son coefficient de Nakamoto n'est que de 20, bien en dessous des 172 de Polkadot.
TON
TON revendique un TPS allant jusqu'à 104 715, mais ce chiffre a été atteint 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 risques de sécurité : l'identité des nœuds de validation de fragments 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 fragment soit entièrement sous son contrôle, ou bloquer les validateurs honnêtes par le biais d'attaques DDoS, ce qui permet de modifier 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, 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'un seul validateurs honnête 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 l'expansion, 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 sous-réseaux).
Chaque sous-réseau peut atteindre un TPS théorique 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 établir des exigences supplémentaires telles que géographiques, KYC, sacrifiant ainsi la décentralisation et la sécurité.
Sur Polkadot, tous les rollups partagent une sécurité unifiée ; tandis que les sous-réseaux d'Avalanche n'ont pas de garanties de sécurité par défaut, certains pouvant même être totalement centralisés. Pour améliorer la sécurité, il est toujours nécessaire de faire des compromis sur les performances, et il est difficile de fournir des engagements de sécurité déterministes.
Ethereum
La stratégie d'extension d'Ethereum parie sur la scalabilité de la couche rollup, plutôt que de résoudre les problèmes directement au niveau de la couche de base. Cette approche n'a en essence 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 latence élevée (il faut attendre la période de preuve de fraude, qui dure généralement plusieurs jours).
ZK Rollup
La mise en œuvre des ZK rollups est limitée par le volume de données pouvant être traitées par transaction. Les exigences de calcul pour générer des preuves à divulgation nulle de connaissance sont très élevées, et le mécanisme "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups limitent souvent le volume de transactions par lot, ce qui peut 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 d'environ 2x10^6 fois celui du protocole de sécurité économique cryptographique central de Polkadot.
De plus, les problèmes de disponibilité des données des ZK rollups aggravent également leurs inconvénients. Pour s'assurer que tout le monde puisse vérifier les transactions, il est encore nécessaire de fournir des données transactionnelles complètes. Cela dépend souvent 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 pour améliorer ses performances ni celle de la confiance présupposée pour accroître son efficacité. Au lieu de cela, il a réalisé un équilibre multidimensionnel entre la sécurité, la décentralisation et la haute performance grâce à une extension é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 plus grande application à grande échelle aujourd'hui, la "scalabilité sans confiance" défendue par Polkadot est peut-ê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.
L'évolutivité flexible de Polkadot : une solution sans compromis dans l'écosystème Web3
Les compromis de l'évolutivité de la Blockchain : Le choix entre Polkadot et Web3
Dans un monde où la technologie Blockchain cherche constamment une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances tout en maintenant 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 simplement plus rapide, s'il est construit sur le sacrifice de la confiance et de la sécurité, est souvent incapable de soutenir une véritable innovation durable.
En tant qu'important moteur de l'évolutivité du Web3, Polkadot a-t-il également fait certains compromis dans sa quête d'un haut débit et d'une faible latence ? Son modèle de rollup a-t-il fait des concessions en matière de décentralisation, de sécurité ou d'interopérabilité du réseau ? Cet article abordera ces questions, en analysant en profondeur les compromis et les arbitrages de Polkadot dans la conception de son évolutivité, et en les comparant aux solutions d'autres chaînes de blocs majeures, en explorant leurs différents choix de trajectoire entre performance, sécurité et décentralisation.
Les défis de la conception d'extension 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 centralisée, cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible de créer un point de défaillance unique ou un contrôle qui affecterait ses caractéristiques de décentralisation ?
Le fonctionnement du Rollup dépend d'un ordonneur de chaîne de relais connecté, dont la communication utilise un mécanisme appelé 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 du rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition d'une seule exigence : 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 mise à l'échelle verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonction "scalabilité élastique". Il a été constaté lors du processus de conception que, puisque la validation des blocs Rollup n'est pas fixée à un core particulier, 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, tout le monde peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. 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 et réduisant le débit global et l'efficacité du rollup.
L'objectif de Polkadot est de maintenir l'élasticité des rollups et une utilisation efficace des ressources de la chaîne de relais, sans compromettre les caractéristiques clés du système.
Sequencer est-il fiable ?
Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut aux ordonneurs qui ne se comportent 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 sequencer, car il est nécessaire de maintenir les caractéristiques de "sans confiance" et "sans autorisation" du système. Quiconque devrait être en mesure d'utiliser le protocole collator pour soumettre des demandes de transition d'état de rollup.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est la suivante : confier entièrement la question à 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 Polkadot la validation doit être effectuée.
Ce design assure une double garantie de flexibilité et de sécurité. Polkadot réexécutera les transitions d'état du rollup dans le processus de disponibilité et garantira l'exactitude de la répartition du core grâce au protocole économique cryptographique ELVES.
Avant que les données d'un bloc rollup ne soient écrites dans la couche de disponibilité des données de Polkadot, un groupe composé d'environ 5 validateurs vérifie d'abord leur légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le séquenceur, qui contiennent le bloc rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, et seront réexécutées par les validateurs sur la chaîne de relais.
Le résultat de la validation contient un sélecteur core, utilisé pour spécifier sur quel core le bloc doit être validé. Le validateur comparera cet index pour voir s'il correspond au core dont il est responsable ; s'il ne correspond pas, le bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours ses propriétés sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants comme les ordonnanceurs ne manipulent la position de validation, garantissant que même si le rollup utilise plusieurs cores, 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 sur le nombre de cores utilisés.
Ainsi, les rollups de Polkadot peuvent réaliser une véritable scalabilité 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 dans les 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être effectué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 réduite entraînent inévitablement une complexité, 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 cas d'utilisation.
La complexité spécifique dépend de la stratégie de gestion des ressources du rollup, qui peut 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 la charge de transaction spécifique dans le mempool des nœuds ;
Stratégie d'automatisation : Configurer les 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, et 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, l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui est attribué.
À l'avenir, Polkadot prendra également en charge la transmission de messages hors chaîne, avec la chaîne de relais comme surface de contrôle, plutôt que comme surface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups, augmentant 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 se fait souvent au détriment de la décentralisation et de la sécurité. Cependant, en regardant le coefficient de Nakamoto, même si certains concurrents de Polkadot ont un niveau de décentralisation inférieur, 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é grâce à une architecture à couche unique à haut débit, reposant sur la preuve d'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 de la mise ;
Plus vous misez, plus vous êtes distribué. 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 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, ce qui aggrave davantage 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 atteindre un TPS, son coefficient de Nakamoto n'est que de 20, bien en dessous des 172 de Polkadot.
TON
TON revendique un TPS allant jusqu'à 104 715, mais ce chiffre a été atteint 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 risques de sécurité : l'identité des nœuds de validation de fragments 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 fragment soit entièrement sous son contrôle, ou bloquer les validateurs honnêtes par le biais d'attaques DDoS, ce qui permet de modifier 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, 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'un seul validateurs honnête 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 l'expansion, 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 sous-réseaux).
Chaque sous-réseau peut atteindre un TPS théorique 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 établir des exigences supplémentaires telles que géographiques, KYC, sacrifiant ainsi la décentralisation et la sécurité.
Sur Polkadot, tous les rollups partagent une sécurité unifiée ; tandis que les sous-réseaux d'Avalanche n'ont pas de garanties de sécurité par défaut, certains pouvant même être totalement centralisés. Pour améliorer la sécurité, il est toujours nécessaire de faire des compromis sur les performances, et il est difficile de fournir des engagements de sécurité déterministes.
Ethereum
La stratégie d'extension d'Ethereum parie sur la scalabilité de la couche rollup, plutôt que de résoudre les problèmes directement au niveau de la couche de base. Cette approche n'a en essence 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 latence élevée (il faut attendre la période de preuve de fraude, qui dure généralement plusieurs jours).
ZK Rollup
La mise en œuvre des ZK rollups est limitée par le volume de données pouvant être traitées par transaction. Les exigences de calcul pour générer des preuves à divulgation nulle de connaissance sont très élevées, et le mécanisme "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups limitent souvent le volume de transactions par lot, ce qui peut 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 d'environ 2x10^6 fois celui du protocole de sécurité économique cryptographique central de Polkadot.
De plus, les problèmes de disponibilité des données des ZK rollups aggravent également leurs inconvénients. Pour s'assurer que tout le monde puisse vérifier les transactions, il est encore nécessaire de fournir des données transactionnelles complètes. Cela dépend souvent 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 pour améliorer ses performances ni celle de la confiance présupposée pour accroître son efficacité. Au lieu de cela, il a réalisé un équilibre multidimensionnel entre la sécurité, la décentralisation et la haute performance grâce à une extension é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 plus grande application à grande échelle aujourd'hui, la "scalabilité sans confiance" défendue par Polkadot est peut-être la véritable solution capable de soutenir le développement à long terme du Web3.