Compromis sur l'évolutivité : Les défis de Polkadot et du Web3
Aujourd'hui, alors que la blockchain recherche une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances d'échelle sans compromettre la sécurité et la résilience du système ? Cela représente non 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 construit sur la base d'un sacrifice de confiance et de sécurité est souvent incapable de soutenir une véritable innovation durable.
En tant que moteur important de l'évolutivité Web3, Polkadot a-t-il sacrifié certains aspects pour atteindre des objectifs de haute bande passante et de 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é réseau ?
Cet article se penchera sur ces questions, en analysant en profondeur les compromis et les choix de conception de l'évolutivité de Polkadot, et en les comparant aux solutions d'autres chaînes de blocs majeures, afin d'explorer leurs différentes options entre performance, sécurité et décentralisation.
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 à certains égards ? 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 des ordonnateurs de la chaîne de relais connectée, dont la communication utilise le mécanisme de protocole collator. Ce protocole est totalement sans autorisation et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de la chaîne de relais et soumettre des demandes de transition d'état du rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition d'une seule exigence : elles doivent être des transitions d'état valides, sinon l'état du rollup ne sera pas avancé.
compromis d'extension verticale
Le Rollup peut réaliser une évolutivité verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité "extensibilité élastique". Au cours du processus de conception, il a été constaté que, puisque la validation des blocs de rollup n'est pas fixée à un core particulier, cela pourrait affecter son élasticité.
Étant donné que le protocole de soumission de blocs à la chaîne intermédiaire est sans autorisation et sans confiance, tout le monde peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. Un attaquant pourrait en tirer parti 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 diminuant 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 fiable ?
Une solution simple consiste à configurer le protocole comme "avec permission" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut au tri qui n'agira 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 transition d'état de rollup en utilisant le protocole de collateur.
Polkadot : une solution sans compromis
La solution choisie par Polkadot est : confier entièrement le problème à la fonction de transition d'état du rollup (Runtime). Le Runtime est la seule source fiable de toutes les informations de consensus, il doit donc être clairement indiqué dans la sortie sur quel cœur de Polkadot la validation doit être effectuée.
Ce design réalise une double garantie d'élasticité et de sécurité. Polkadot réexécutera la conversion d'état des rollups dans le processus de disponibilité et garantira l'exactitude de la distribution du core grâce au protocole économique cryptographique ELVES.
Avant qu'une couche de disponibilité des données de Polkadot ne soit écrite dans n'importe quel bloc rollup, un groupe composé d'environ 5 validateurs va d'abord vérifier sa légitimité. Ils reçoivent des reçus candidats et des preuves de validité soumis 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, qui sera réexécutée par les validateurs sur la chaîne de relais.
Le résultat de la validation contient un sélecteur de cœur, qui spécifie sur quel cœur le bloc doit être validé. Le validateur comparera cet index pour voir s'il correspond à son cœur responsable ; s'il n'est pas cohérent, le bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours des attributs sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants comme les ordonneurs ne manipulent les positions de validation, assurant 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 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 intégralement sa sécurité à tous les rollups, en vérifiant tous les calculs sur le cœur, sans aucune restriction ou hypothèse concernant le nombre de cœurs utilisés.
Ainsi, 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 exécution unique est complétée dans les 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécutés dans chaque cycle de 6 secondes est augmentée, mais le type de calcul n'est pas affecté.
complexité
Une plus grande capacité de traitement 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 répondre à certaines exigences de la RFC103 pour s'adapter à différents scénarios d'utilisation.
La complexité spécifique dépend de la stratégie de gestion des ressources du rollup, qui peut reposer 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 : Appeler à l'avance le service coretime pour configurer les ressources 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'évolutivité élastique n'affecte pas le débit de la transmission des messages.
La communication des messages entre les rollups est réalisée par la couche de transport sous-jacente, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui sont attribués.
À l'avenir, Polkadot prendra également en charge la communication hors chaîne, avec la chaîne de relais agissant comme surface de contrôle plutôt que comme surface de données. Cette mise à niveau améliorera les capacités de communication entre les rollups en parallèle à l'extension élastique, renforçant ainsi la capacité d'extension verticale du système.
Quels compromis ont été faits par 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'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 réalise l'évolutivité avec une architecture à couche unique à haut débit, s'appuyant sur la preuve d'historique (PoH), le traitement parallèle par CPU et un mécanisme de consensus basé sur le leader, avec un TPS théorique pouvant atteindre 65 000.
Un élément clé du design est son mécanisme de planification des leaders, qui est préalablement public et vérifiable :
Au début de chaque epoch (environ deux jours ou 432 000 slots), les slots sont attribués en fonction de la quantité de mise ;
Plus vous misez, plus vous êtes distribué. Par exemple, un validateur misant 1% aura environ 1% de chances de produire un bloc ;
Tous les mineurs 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 en jeu, 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'étant que de 20, bien en dessous des 172 de Polkadot.
TON
TON prétend atteindre 104 715 TPS, mais ce chiffre est réalisé 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 vulnérabilités de sécurité : l'identité des nœuds de validation de shards peut être exposée à l'avance. Le livre blanc de TON souligne également que, bien que cela puisse optimiser la bande passante, cela peut également être exploité de manière malveillante. En raison de l'absence de mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit entièrement sous son contrôle, ou utiliser une attaque DDoS pour bloquer les validateurs honnêtes, permettant ainsi 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. Les attaquants ne peuvent pas connaître à l'avance l'identité des validateurs, et une attaque doit miser sur le contrôle total pour réussir. Tant qu'un validateur honnête conteste, 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'évolutivité. Le réseau principal est composé de X-Chain (transferts, ~4 500 TPS), C-Chain (contrats intelligents, ~100-200 TPS) et P-Chain (gestion des validateurs et des sous-réseaux).
Chaque sous-réseau peut théoriquement atteindre ~5 000 TPS, similaire à l'idée de Polkadot : réduire la charge d'un seul shard pour réaliser l'évolutivité. Mais Avalanche permet aux validateurs de choisir librement de participer aux sous-réseaux, et ces sous-réseaux peuvent imposer des exigences supplémentaires géographiques, KYC, etc., au détriment de la décentralisation et de 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 encore faire des compromis en termes de performance, et il est difficile de fournir des engagements de sécurité déterministes.
Ethereum
La stratégie d'extension d'Ethereum parie sur l'évolutivité de la couche rollup, plutôt que de résoudre le problème directement au niveau de la couche de base. Cette approche ne résout essentiellement pas le problème, mais le transfère à la couche supérieure de la pile.
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 latence élevée (il faut 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 "le gagnant emporte tout" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups limitent souvent le volume des transactions par lot, ce qui peut provoquer des congestions réseau et une augmentation des frais de gaz en période de forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût des ZK rollups Turing-complets est d'environ 2x10^6 fois celui du protocole de sécurité économique cryptographique de base de Polkadot.
De plus, les problèmes de disponibilité des données des ZK rollups aggravent également leurs inconvénients. Pour garantir que tout le monde puisse vérifier les transactions, il est toujours nécessaire de fournir des données de transaction complètes. Cela repose souvent sur des solutions supplémentaires de disponibilité des données, ce qui augmente encore les coûts et les frais pour les utilisateurs.
Conclusion
La fin de l'évolutivité ne devrait pas être un compromis.
Comparé à d'autres blockchains, Polkadot n'a pas opté pour un échange de centralisation contre performance ni pour un échange de confiance présupposée contre efficacité, mais a réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extension élastique, une conception de protocole sans autorisation, une couche de sécurité unifiée et un mécanisme de gestion des ressources flexible.
Dans la quête d'une application à plus grande échelle aujourd'hui, le "zero trust scalability" défendu par Polkadot 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.
13 J'aime
Récompense
13
10
Reposter
Partager
Commentaire
0/400
DuskSurfer
· 07-24 17:29
L'infrastructure doit être priorisée pour aller vite.
Voir l'originalRépondre0
TokenRationEater
· 07-24 00:36
Pas assez rapide, ça fait déjà 22 ans.
Voir l'originalRépondre0
LiquidityWhisperer
· 07-22 15:35
La vitesse et la sécurité ne peuvent-elles pas être toutes les deux ?
Voir l'originalRépondre0
DiamondHands
· 07-22 13:17
La vitesse et la sécurité sont en fait mutuellement exclusives, n'est-ce pas ?
Voir l'originalRépondre0
GasGuru
· 07-21 22:12
Encore une chaîne qui joue à l'équilibriste.
Voir l'originalRépondre0
TokenVelocity
· 07-21 22:10
Est-ce que Polkadot est vraiment stable ? Ou est-ce qu'on se fait prendre pour des cons ?
Voir l'originalRépondre0
BearMarketSage
· 07-21 21:53
On ne peut pas avoir à la fois le poisson et l'ours.
Voir l'originalRépondre0
MidnightSeller
· 07-21 21:52
Sacrifier la sécurité pour la vitesse, c'est presque comme attendre sur le toit.
Voir l'originalRépondre0
PermabullPete
· 07-21 21:48
Compris, mais les points ?
Voir l'originalRépondre0
MEVSandwichMaker
· 07-21 21:48
Le coût du sacrifice doit toujours être payé, il suffit de voir qui va exploser en premier.
Comment Polkadot réalise l'extension sans confiance et dirige l'avenir du Web3
Compromis sur l'évolutivité : Les défis de Polkadot et du Web3
Aujourd'hui, alors que la blockchain recherche une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances d'échelle sans compromettre la sécurité et la résilience du système ? Cela représente non 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 construit sur la base d'un sacrifice de confiance et de sécurité est souvent incapable de soutenir une véritable innovation durable.
En tant que moteur important de l'évolutivité Web3, Polkadot a-t-il sacrifié certains aspects pour atteindre des objectifs de haute bande passante et de 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é réseau ?
Cet article se penchera sur ces questions, en analysant en profondeur les compromis et les choix de conception de l'évolutivité de Polkadot, et en les comparant aux solutions d'autres chaînes de blocs majeures, afin d'explorer leurs différentes options entre performance, sécurité et décentralisation.
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 à certains égards ? 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 des ordonnateurs de la chaîne de relais connectée, dont la communication utilise le mécanisme de protocole collator. Ce protocole est totalement sans autorisation et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de la chaîne de relais et soumettre des demandes de transition d'état du rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition d'une seule exigence : elles doivent être des transitions d'état valides, sinon l'état du rollup ne sera pas avancé.
compromis d'extension verticale
Le Rollup peut réaliser une évolutivité verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité "extensibilité élastique". Au cours du processus de conception, il a été constaté que, puisque la validation des blocs de rollup n'est pas fixée à un core particulier, cela pourrait affecter son élasticité.
Étant donné que le protocole de soumission de blocs à la chaîne intermédiaire est sans autorisation et sans confiance, tout le monde peut soumettre des blocs à n'importe quel core attribué au rollup pour vérification. Un attaquant pourrait en tirer parti 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 diminuant 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 fiable ?
Une solution simple consiste à configurer le protocole comme "avec permission" : par exemple, en adoptant un mécanisme de liste blanche, ou en faisant confiance par défaut au tri qui n'agira 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 transition d'état de rollup en utilisant le protocole de collateur.
Polkadot : une solution sans compromis
La solution choisie par Polkadot est : confier entièrement le problème à la fonction de transition d'état du rollup (Runtime). Le Runtime est la seule source fiable de toutes les informations de consensus, il doit donc être clairement indiqué dans la sortie sur quel cœur de Polkadot la validation doit être effectuée.
Ce design réalise une double garantie d'élasticité et de sécurité. Polkadot réexécutera la conversion d'état des rollups dans le processus de disponibilité et garantira l'exactitude de la distribution du core grâce au protocole économique cryptographique ELVES.
Avant qu'une couche de disponibilité des données de Polkadot ne soit écrite dans n'importe quel bloc rollup, un groupe composé d'environ 5 validateurs va d'abord vérifier sa légitimité. Ils reçoivent des reçus candidats et des preuves de validité soumis 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, qui sera réexécutée par les validateurs sur la chaîne de relais.
Le résultat de la validation contient un sélecteur de cœur, qui spécifie sur quel cœur le bloc doit être validé. Le validateur comparera cet index pour voir s'il correspond à son cœur responsable ; s'il n'est pas cohérent, le bloc sera rejeté.
Ce mécanisme garantit que le système conserve toujours des attributs sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants comme les ordonneurs ne manipulent les positions de validation, assurant 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 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 intégralement sa sécurité à tous les rollups, en vérifiant tous les calculs sur le cœur, sans aucune restriction ou hypothèse concernant le nombre de cœurs utilisés.
Ainsi, 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 exécution unique est complétée dans les 2 secondes. Grâce à l'extension élastique, la quantité totale de calculs pouvant être exécutés dans chaque cycle de 6 secondes est augmentée, mais le type de calcul n'est pas affecté.
complexité
Une plus grande capacité de traitement 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 répondre à certaines exigences de la RFC103 pour s'adapter à différents scénarios d'utilisation.
La complexité spécifique dépend de la stratégie de gestion des ressources du rollup, qui peut reposer 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 : Appeler à l'avance le service coretime pour configurer les ressources 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'évolutivité élastique n'affecte pas le débit de la transmission des messages.
La communication des messages entre les rollups est réalisée par la couche de transport sous-jacente, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui sont attribués.
À l'avenir, Polkadot prendra également en charge la communication hors chaîne, avec la chaîne de relais agissant comme surface de contrôle plutôt que comme surface de données. Cette mise à niveau améliorera les capacités de communication entre les rollups en parallèle à l'extension élastique, renforçant ainsi la capacité d'extension verticale du système.
Quels compromis ont été faits par 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'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 réalise l'évolutivité avec une architecture à couche unique à haut débit, s'appuyant sur la preuve d'historique (PoH), le traitement parallèle par CPU et un mécanisme de consensus basé sur le leader, avec un TPS théorique pouvant atteindre 65 000.
Un élément clé du design est son mécanisme de planification des leaders, qui est préalablement public et vérifiable :
Au début de chaque epoch (environ deux jours ou 432 000 slots), les slots sont attribués en fonction de la quantité de mise ;
Plus vous misez, plus vous êtes distribué. Par exemple, un validateur misant 1% aura environ 1% de chances de produire un bloc ;
Tous les mineurs 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 en jeu, 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'étant que de 20, bien en dessous des 172 de Polkadot.
TON
TON prétend atteindre 104 715 TPS, mais ce chiffre est réalisé 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 vulnérabilités de sécurité : l'identité des nœuds de validation de shards peut être exposée à l'avance. Le livre blanc de TON souligne également que, bien que cela puisse optimiser la bande passante, cela peut également être exploité de manière malveillante. En raison de l'absence de mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un shard soit entièrement sous son contrôle, ou utiliser une attaque DDoS pour bloquer les validateurs honnêtes, permettant ainsi 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. Les attaquants ne peuvent pas connaître à l'avance l'identité des validateurs, et une attaque doit miser sur le contrôle total pour réussir. Tant qu'un validateur honnête conteste, 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'évolutivité. Le réseau principal est composé de X-Chain (transferts, ~4 500 TPS), C-Chain (contrats intelligents, ~100-200 TPS) et P-Chain (gestion des validateurs et des sous-réseaux).
Chaque sous-réseau peut théoriquement atteindre ~5 000 TPS, similaire à l'idée de Polkadot : réduire la charge d'un seul shard pour réaliser l'évolutivité. Mais Avalanche permet aux validateurs de choisir librement de participer aux sous-réseaux, et ces sous-réseaux peuvent imposer des exigences supplémentaires géographiques, KYC, etc., au détriment de la décentralisation et de 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 encore faire des compromis en termes de performance, et il est difficile de fournir des engagements de sécurité déterministes.
Ethereum
La stratégie d'extension d'Ethereum parie sur l'évolutivité de la couche rollup, plutôt que de résoudre le problème directement au niveau de la couche de base. Cette approche ne résout essentiellement pas le problème, mais le transfère à la couche supérieure de la pile.
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 latence élevée (il faut 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 "le gagnant emporte tout" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups limitent souvent le volume des transactions par lot, ce qui peut provoquer des congestions réseau et une augmentation des frais de gaz en période de forte demande, affectant ainsi l'expérience utilisateur.
En comparaison, le coût des ZK rollups Turing-complets est d'environ 2x10^6 fois celui du protocole de sécurité économique cryptographique de base de Polkadot.
De plus, les problèmes de disponibilité des données des ZK rollups aggravent également leurs inconvénients. Pour garantir que tout le monde puisse vérifier les transactions, il est toujours nécessaire de fournir des données de transaction complètes. Cela repose souvent sur des solutions supplémentaires de disponibilité des données, ce qui augmente encore les coûts et les frais pour les utilisateurs.
Conclusion
La fin de l'évolutivité ne devrait pas être un compromis.
Comparé à d'autres blockchains, Polkadot n'a pas opté pour un échange de centralisation contre performance ni pour un échange de confiance présupposée contre efficacité, mais a réalisé un équilibre multidimensionnel entre sécurité, décentralisation et haute performance grâce à une extension élastique, une conception de protocole sans autorisation, une couche de sécurité unifiée et un mécanisme de gestion des ressources flexible.
Dans la quête d'une application à plus grande échelle aujourd'hui, le "zero trust scalability" défendu par Polkadot est peut-être la véritable solution capable de soutenir le développement à long terme du Web3.