Scalabilité et compromis : Comment Polkadot cherche un équilibre dans l'écosystème Web3
Aujourd'hui, dans la quête d'une plus grande efficacité dans la blockchain, une question clé émerge progressivement : comment éviter de sacrifier la sécurité et la résilience du système tout en améliorant les performances d'évolutivité ? Ce n'est pas seulement un défi technique, mais aussi un choix profond en matière de conception architecturale. Pour l'écosystème Web3, un système plus rapide basé sur le sacrifice de la confiance et de la sécurité a souvent du mal à soutenir une véritable innovation durable.
Polkadot en tant que moteur important de l'évolutivité Web3, a-t-il 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 en matière de décentralisation, de sécurité ou d'interopérabilité réseau ? Cet article se penchera sur 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 blockchains majeures, en explorant leurs choix de chemins différents entre performances, sécurité et décentralisation.
Défis de la conception d'expansion 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 centralisée. Cela pourrait-il introduire des risques de centralisation d'une certaine manière ? 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 des ordonneurs de chaînes relais connectés, et leur communication utilise un mécanisme appelé protocole collateur. Ce protocole est totalement sans permission et sans confiance, toute personne ayant une connexion réseau peut l'utiliser pour se connecter à un petit nombre de nœuds de chaînes relais et soumettre des demandes de transition d'état de Rollup. Ces demandes seront vérifiées par un core de la chaîne relais, à condition qu'elles soient des transitions d'état valides, sinon l'état de ce Rollup ne sera pas avancé.
compromis sur l'extension verticale
Les rollups peuvent réaliser une scalabilité verticale en tirant parti de l'architecture multi-core de Polkadot. Cette nouvelle capacité a été introduite par la fonction de "scalabilité élastique". Au cours du processus de conception, nous avons découvert que, puisque la validation des blocs rollup n'est pas fixée à un cœur spécifique, cela pourrait affecter leur élasticité.
Étant donné que le protocole de soumission des blocs à la chaîne intermédiaire est sans permission et sans confiance, n'importe qui peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. Les attaquants peuvent exploiter cela pour soumettre à plusieurs reprises des blocs légitimes déjà vérifiés à différents cores, consommant ainsi malicieusement des ressources et diminuant 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 affecter les caractéristiques clés du système.
Sequencer est-il digne de confiance ?
Une solution simple consiste à définir le protocole comme "avec autorisation" : 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 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 autorisation » du système. Quiconque devrait pouvoir soumettre des demandes de changement 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 transition d'état des rollups (Runtime). Le Runtime est la seule source fiable de toutes les informations de consensus, il est donc impératif d'indiquer clairement dans la sortie sur quel cœur de Polkadot la validation doit être effectuée.
Ce design réalise une double garantie de flexibilité et de sécurité. Polkadot réexécutera les transitions d'état des rollups dans le processus de disponibilité et garantira la justesse de l'allocation de core grâce au protocole économique cryptographique ELVES.
Avant que toute donnée ne soit écrite dans la couche de disponibilité des données (DA) de Polkadot dans un bloc rollup, un groupe composé d'environ 5 validateurs vérifiera d'abord sa légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le ordonnanceur, qui contiennent le bloc rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, réexécutée par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de cœur, utilisé pour spécifier sur quel cœur le bloc doit être validé. Le validateur comparera cet index pour voir s'il correspond au cœur dont il est responsable ; en cas de non-conformité, ce 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 maintenir sa résilience.
sécurité
Dans sa quête d'évolutivité, Polkadot n'a pas compromis la sécurité. La sécurité des rollups est garantie par la chaîne de relais, et il suffit d'un ordonneur honnête pour maintenir la viabilité.
Grâce au protocole ELVES, Polkadot étend en toute sécurité sa sécurité à tous les rollups, en vérifiant 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 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 en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être effectuée dans un 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 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 respecter 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 des charges de transactions spécifiques dans le mempool des nœuds ;
Stratégies automatisées : Appel anticipé des services coretime pour configurer les ressources grâce aux données historiques et à l'interface XCM.
Bien que l'automatisation soit plus efficace, les coûts de mise en œuvre et de test augmentent également de manière significative.
interopérabilité
Polkadot prend en charge l'interopérabilité entre différents rollups, tandis que l'extensibilité élastique n'affecte pas le débit des messages.
La communication de messages entre rollups est réalisée par la couche de transport sous-jacente, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui est attribué.
À l'avenir, Polkadot prendra également en charge la transmission de messages hors chaîne, avec la chaîne de relais comme interface de contrôle, et non comme interface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups tout en augmentant l'évolutivité, renforçant ainsi la capacité d'évolutivité 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 détriment de la décentralisation et de la sécurité. Mais d'un point de vue du coefficient de Nakamoto, même si certains concurrents de Polkadot ont un degré de décentralisation relativement faible, leurs performances ne sont pas à la hauteur.
Solana
Solana n'adopte pas l'architecture de sharding de Polkadot ou d'Ethereum, mais utilise une architecture à couche unique à haut débit pour réaliser l'évolutivité, s'appuyant sur la preuve d'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 des éléments clés 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 obtenez de distribution. Par exemple, un validateur misant 1 % aura environ 1 % de chances de produire un bloc ;
Tous les mineurs sont annoncés à l'avance, augmentant 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 engage de mises, plus il a de chances de produire des blocs, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave 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
Un certain projet de blockchain revendique un TPS pouvant atteindre 104 715, mais ce chiffre a été atteint dans un réseau de test privé, avec 256 nœuds, dans des conditions idéales de réseau et de matériel. Pendant ce temps, Polkadot a atteint 128K TPS sur un réseau public décentralisé.
Le mécanisme de consensus de ce projet présente des vulnérabilités en matière de sécurité : l'identité des nœuds de validation des shards pourrait être exposée à l'avance. Son livre blanc indique également que, bien que cela puisse optimiser la bande passante, cela pourrait également être exploité de manière malveillante. En raison de l'absence d'un mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit complètement contrôlé par lui ou bloquer les validateurs honnêtes par une attaque DDoS, ce qui lui permettrait de falsifier l'état.
En comparaison, les validateurs de Polkadot sont attribués de manière aléatoire et leur identité est révélée avec un délai, 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, et tant qu'un seul validateur honnête lance une contestation, l'attaque échouera et entraînera 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 a un TPS théorique pouvant atteindre ~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 aux sous-réseaux, et ces sous-réseaux peuvent imposer des exigences géographiques, de KYC, etc., au détriment de la décentralisation et de la sécurité.
Dans Polkadot, tous les rollups partagent une 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 est toujours nécessaire de faire des compromis sur la performance, et il est difficile de fournir des engagements de sécurité déterministes.
Ethereum
La stratégie d'expansion 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. Essentiellement, cette approche ne résout pas le problème, mais le transfère à la couche supérieure de la pile.
Rollup Optimiste
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 temps de latence élevé (nécessitant d'attendre la période de preuve de fraude, généralement 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. Les exigences de calcul pour générer des preuves à divulgation nulle de connaissance sont extrêmement élevées, et le mécanisme de "gagnant prend 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 rollup 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 du ZK rollup aggravent é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 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 publiques, Polkadot n'a pas choisi de sacrifier la décentralisation pour la performance ou de privilégier la confiance présumée pour l'efficacité, mais a plutôt réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extensibilité flexible, 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, 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.
13 J'aime
Récompense
13
8
Partager
Commentaire
0/400
MysteryBoxOpener
· 07-22 22:03
dot est vraiment meilleur que les autres blockchains
Voir l'originalRépondre0
NotFinancialAdviser
· 07-22 21:00
Ne blague pas, dot c'est juste comme ça.
Voir l'originalRépondre0
LuckyBearDrawer
· 07-22 00:01
Cette vague de DOT va To the moon !
Voir l'originalRépondre0
P2ENotWorking
· 07-19 22:40
À quoi bon aller vite ? D'abord, il faut survivre.
Voir l'originalRépondre0
BrokenDAO
· 07-19 22:39
Encore en train de dépeindre un équilibre parfait... On se souvient encore de cette vague de paralysie écologique en 2021 ?
Voir l'originalRépondre0
ser_we_are_early
· 07-19 22:39
Top ! Pour cet article technique, je ne me préoccupe que d'une chose, hausse ou pas hausse.
Voir l'originalRépondre0
DevChive
· 07-19 22:32
dot est l'avenir, qui s'y oppose encore ?
Voir l'originalRépondre0
MagicBean
· 07-19 22:31
En attendant les résultats des participants de polka, je ne peux m'empêcher de dire qu'ils pourront toujours aller vers les étoiles.
Le chemin de l'équilibre de Polkadot : une évolutivité sans compromis dans l'écosystème Web3
Scalabilité et compromis : Comment Polkadot cherche un équilibre dans l'écosystème Web3
Aujourd'hui, dans la quête d'une plus grande efficacité dans la blockchain, une question clé émerge progressivement : comment éviter de sacrifier la sécurité et la résilience du système tout en améliorant les performances d'évolutivité ? Ce n'est pas seulement un défi technique, mais aussi un choix profond en matière de conception architecturale. Pour l'écosystème Web3, un système plus rapide basé sur le sacrifice de la confiance et de la sécurité a souvent du mal à soutenir une véritable innovation durable.
Polkadot en tant que moteur important de l'évolutivité Web3, a-t-il 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 en matière de décentralisation, de sécurité ou d'interopérabilité réseau ? Cet article se penchera sur 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 blockchains majeures, en explorant leurs choix de chemins différents entre performances, sécurité et décentralisation.
Défis de la conception d'expansion 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 centralisée. Cela pourrait-il introduire des risques de centralisation d'une certaine manière ? 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 des ordonneurs de chaînes relais connectés, et leur communication utilise un mécanisme appelé protocole collateur. Ce protocole est totalement sans permission et sans confiance, toute personne ayant une connexion réseau peut l'utiliser pour se connecter à un petit nombre de nœuds de chaînes relais et soumettre des demandes de transition d'état de Rollup. Ces demandes seront vérifiées par un core de la chaîne relais, à condition qu'elles soient des transitions d'état valides, sinon l'état de ce Rollup ne sera pas avancé.
compromis sur l'extension verticale
Les rollups peuvent réaliser une scalabilité verticale en tirant parti de l'architecture multi-core de Polkadot. Cette nouvelle capacité a été introduite par la fonction de "scalabilité élastique". Au cours du processus de conception, nous avons découvert que, puisque la validation des blocs rollup n'est pas fixée à un cœur spécifique, cela pourrait affecter leur élasticité.
Étant donné que le protocole de soumission des blocs à la chaîne intermédiaire est sans permission et sans confiance, n'importe qui peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. Les attaquants peuvent exploiter cela pour soumettre à plusieurs reprises des blocs légitimes déjà vérifiés à différents cores, consommant ainsi malicieusement des ressources et diminuant 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 affecter les caractéristiques clés du système.
Sequencer est-il digne de confiance ?
Une solution simple consiste à définir le protocole comme "avec autorisation" : 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 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 autorisation » du système. Quiconque devrait pouvoir soumettre des demandes de changement 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 transition d'état des rollups (Runtime). Le Runtime est la seule source fiable de toutes les informations de consensus, il est donc impératif d'indiquer clairement dans la sortie sur quel cœur de Polkadot la validation doit être effectuée.
Ce design réalise une double garantie de flexibilité et de sécurité. Polkadot réexécutera les transitions d'état des rollups dans le processus de disponibilité et garantira la justesse de l'allocation de core grâce au protocole économique cryptographique ELVES.
Avant que toute donnée ne soit écrite dans la couche de disponibilité des données (DA) de Polkadot dans un bloc rollup, un groupe composé d'environ 5 validateurs vérifiera d'abord sa légitimité. Ils reçoivent les reçus candidats et les preuves de validité soumis par le ordonnanceur, qui contiennent le bloc rollup et les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation de la chaîne parallèle, réexécutée par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de cœur, utilisé pour spécifier sur quel cœur le bloc doit être validé. Le validateur comparera cet index pour voir s'il correspond au cœur dont il est responsable ; en cas de non-conformité, ce 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 maintenir sa résilience.
sécurité
Dans sa quête d'évolutivité, Polkadot n'a pas compromis la sécurité. La sécurité des rollups est garantie par la chaîne de relais, et il suffit d'un ordonneur honnête pour maintenir la viabilité.
Grâce au protocole ELVES, Polkadot étend en toute sécurité sa sécurité à tous les rollups, en vérifiant 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 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 en moins de 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être effectuée dans un 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 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 respecter 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 des charges de transactions spécifiques dans le mempool des nœuds ;
Stratégies automatisées : Appel anticipé des services coretime pour configurer les ressources grâce aux données historiques et à l'interface XCM.
Bien que l'automatisation soit plus efficace, les coûts de mise en œuvre et de test augmentent également de manière significative.
interopérabilité
Polkadot prend en charge l'interopérabilité entre différents rollups, tandis que l'extensibilité élastique n'affecte pas le débit des messages.
La communication de messages entre rollups est réalisée par la couche de transport sous-jacente, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui est attribué.
À l'avenir, Polkadot prendra également en charge la transmission de messages hors chaîne, avec la chaîne de relais comme interface de contrôle, et non comme interface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups tout en augmentant l'évolutivité, renforçant ainsi la capacité d'évolutivité 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 détriment de la décentralisation et de la sécurité. Mais d'un point de vue du coefficient de Nakamoto, même si certains concurrents de Polkadot ont un degré de décentralisation relativement faible, leurs performances ne sont pas à la hauteur.
Solana
Solana n'adopte pas l'architecture de sharding de Polkadot ou d'Ethereum, mais utilise une architecture à couche unique à haut débit pour réaliser l'évolutivité, s'appuyant sur la preuve d'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 des éléments clés 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 obtenez de distribution. Par exemple, un validateur misant 1 % aura environ 1 % de chances de produire un bloc ;
Tous les mineurs sont annoncés à l'avance, augmentant 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 engage de mises, plus il a de chances de produire des blocs, tandis que les petits nœuds ont presque aucun slot, ce qui aggrave 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
Un certain projet de blockchain revendique un TPS pouvant atteindre 104 715, mais ce chiffre a été atteint dans un réseau de test privé, avec 256 nœuds, dans des conditions idéales de réseau et de matériel. Pendant ce temps, Polkadot a atteint 128K TPS sur un réseau public décentralisé.
Le mécanisme de consensus de ce projet présente des vulnérabilités en matière de sécurité : l'identité des nœuds de validation des shards pourrait être exposée à l'avance. Son livre blanc indique également que, bien que cela puisse optimiser la bande passante, cela pourrait également être exploité de manière malveillante. En raison de l'absence d'un mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit complètement contrôlé par lui ou bloquer les validateurs honnêtes par une attaque DDoS, ce qui lui permettrait de falsifier l'état.
En comparaison, les validateurs de Polkadot sont attribués de manière aléatoire et leur identité est révélée avec un délai, 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, et tant qu'un seul validateur honnête lance une contestation, l'attaque échouera et entraînera 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 a un TPS théorique pouvant atteindre ~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 aux sous-réseaux, et ces sous-réseaux peuvent imposer des exigences géographiques, de KYC, etc., au détriment de la décentralisation et de la sécurité.
Dans Polkadot, tous les rollups partagent une 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 est toujours nécessaire de faire des compromis sur la performance, et il est difficile de fournir des engagements de sécurité déterministes.
Ethereum
La stratégie d'expansion 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. Essentiellement, cette approche ne résout pas le problème, mais le transfère à la couche supérieure de la pile.
Rollup Optimiste
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 temps de latence élevé (nécessitant d'attendre la période de preuve de fraude, généralement 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. Les exigences de calcul pour générer des preuves à divulgation nulle de connaissance sont extrêmement élevées, et le mécanisme de "gagnant prend 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 rollup 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 du ZK rollup aggravent é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 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 publiques, Polkadot n'a pas choisi de sacrifier la décentralisation pour la performance ou de privilégier la confiance présumée pour l'efficacité, mais a plutôt réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extensibilité flexible, 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, le "zero-trust scalability" défendu par Polkadot pourrait être la véritable solution capable de soutenir le développement à long terme du Web3.