L'équilibre de l'évolutivité du Blockchain : l'exemple de Polkadot
Aujourd'hui, alors que la technologie Blockchain recherche constamment une efficacité accrue, un problème clé se dessine progressivement : comment améliorer les performances sans sacrifier la sécurité et la résilience du système ? Ce n'est pas seulement un défi technique, mais aussi un choix architectural profond. Pour l'écosystème Web3, un système plus rapide, s'il est construit sur la base d'un sacrifice de la confiance et de la sécurité, a souvent du mal à soutenir une véritable innovation durable.
Cet article explorera en profondeur les compromis et les arbitrages de Polkadot dans la conception de l'évolutivité, et comparera cela aux solutions d'autres chaînes publiques majeures, en analysant leurs choix de parcours différents en matière de performance, de sécurité et de décentralisation.
Les défis de la conception d'extension de Polkadot
É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 (Relay Chain). Le fonctionnement des Rollups dépend d'un séquenceur (sequencer) connecté à la chaîne de relais, dont la communication utilise le mécanisme de protocole collator. Ce protocole est entièrement sans autorisation et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de la chaîne de relais et soumettre des demandes de transition d'état de rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition de satisfaire un préalable : 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 scalabilité verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité d'"Élasticité" (Elastic Scaling). Au cours du processus de conception, il a été constaté que, comme la validation des blocs Rollup n'est pas exécutée de manière fixe sur un core particulier, cela pourrait affecter son élasticité.
Étant donné que le protocole de soumission des blocs à la chaîne de relais est sans permission et sans confiance, toute personne peut soumettre un bloc à n'importe quel core attribué au rollup pour validation. Les attaquants pourraient exploiter cela en soumettant de manière répétée des blocs légitimes déjà validés à différents cores, consommant ainsi malicieusement des ressources et réduisant le débit et l'efficacité globale 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.
Problème de confiance du Sequencer
Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, en utilisant un mécanisme de liste blanche, ou en faisant en sorte que les séquenceurs de confiance par défaut n'agissent pas de manière malveillante, garantissant ainsi l'activité du rollup. Cependant, dans la philosophie de conception de Polkadot, nous ne pouvons faire aucune hypothèse de confiance sur le séquenceur, car il est nécessaire de maintenir les caractéristiques "sans confiance" et "sans permission" du système. N'importe qui devrait pouvoir utiliser le protocole collator pour soumettre des demandes de transition d'état du rollup.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier entièrement le problème à 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 d'élasticité et de sécurité. Polkadot réexécutera la transformation 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 qu'un bloc rollup ne soit écrit dans la couche de disponibilité des données (DA) de Polkadot, un groupe composé d'environ 5 validateurs va d'abord vérifier sa légitimité. Ils reçoivent les reçus candidats (candidate receipt) et les preuves de validité (PoV) soumis par le séquenceur, qui contiennent le bloc rollup ainsi que les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation des chaînes parallèles et réexécutées par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de cœur (core selector), utilisé pour spécifier sur quel cœur (core) le bloc doit être vérifié. Le validateur comparera cet index avec celui du cœur dont il est responsable ; s'ils ne correspondent pas, ce bloc sera rejeté.
Ce mécanisme garantit que le système maintient toujours des caractéristiques sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants comme les ordonnanceurs ne manipulent les positions de validation, assurant que même si le rollup utilise plusieurs core, il peut rester résilient.
sécurité
Dans sa quête d'évolutivité, Polkadot n'a pas fait de compromis sur la sécurité. La sécurité des rollups est garantie par la chaîne de relais, qui nécessite seulement un ordonneur honnête pour maintenir la survie.
Grâce au protocole ELVES, Polkadot étend intégralement sa sécurité à tous les rollups, vérifiant 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 évolutivité 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 exécutée tous les 6 secondes est augmentée, mais le type de calcul n'est pas affecté.
Complexité
Une plus grande capacité de traitement et une latence plus faible entraînent inévitablement une complexité, ce qui est le seul compromis acceptable dans la conception des systèmes.
Les Rollups peuvent ajuster dynamiquement les ressources via l'interface Agile Coretime pour maintenir un niveau de sécurité cohérent. Ils doivent également mettre en œuvre certaines exigences de la RFC103 pour s'adapter à différents scénarios d'utilisation.
La complexité spécifique dépend des stratégies de gestion des ressources du rollup, qui peuvent dépendre de variables en chaîne ou hors chaîne. Par exemple :
Stratégie simple : utilisez toujours un nombre fixe de core, ou ajustez manuellement hors chaîne ;
Stratégie légère : surveiller les charges de transaction spécifiques 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 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'évolutivité flexible 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, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui sont attribués.
À l'avenir, Polkadot prendra également en charge la messagerie hors chaîne (off-chain messaging), avec la chaîne de relais comme couche de contrôle, plutôt que comme couche de données. Cette mise à niveau améliorera la capacité de communication entre les rollups en même temps que l'extension élastique, renforçant ainsi la capacité d'extension verticale du système.
Compromis d'autres protocoles
Comme tout le monde le sait, l'amélioration des performances se fait souvent au prix de la décentralisation et de la sécurité. Mais d'après le coefficient de Nakamoto, même si certains concurrents de Polkadot sont moins décentralisés, 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, s'appuyant sur la preuve historique (PoH), le traitement parallèle par CPU et un mécanisme de consensus basé sur un leader, avec un TPS théorique pouvant atteindre 65 000.
Un élément clé de la conception est son mécanisme de planification des leaders, qui est préalablement public et vérifiable :
Au début de chaque epoch (environ deux jours ou 432 000 slots), les slots sont attribués en fonction de la quantité de staking ;
Plus vous stakez, plus vous êtes réparti. Par exemple, un validateur qui stake 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 matériels très performants, 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 encore 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 poursuivre le TPS, son coefficient de Nakamoto n'étant que de 20, bien inférieur aux 172 de Polkadot.
TON
TON prétend que le TPS peut atteindre 104 715, mais ce chiffre a été réalisé dans 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 fragments peut être révélée à l'avance. Le livre blanc de TON 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 de mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un fragment soit complètement contrôlé par lui, ou bloquer les validateurs honnêtes par une attaque DDoS, ce qui lui permet de modifier l'état.
En comparaison, les validateurs de Polkadot sont assignés de manière aléatoire et leur identité est révélée avec un certain 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 dès qu'un validateur honnête soulève une contestation, l'attaque échoue et entraîne des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseaux pour l'évolutivité, le réseau principal étant composé de X-Chain (transferts, ~4 500 TPS), C-Chain (contrats intelligents, ~100-200 TPS) et P-Chain (gestion des validateurs et des sous-réseaux).
Chaque sous-réseau peut atteindre un TPS théorique d'environ 5 000, similaire à l'approche 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 à des sous-réseaux, qui peuvent imposer des exigences supplémentaires telles que géographiques ou KYC, sacrifiant ainsi la décentralisation et la sécurité.
Dans Polkadot, tous les rollups partagent une garantie de sécurité unifiée ; tandis que les sous-réseaux d'Avalanche n'ont pas de garantie de sécurité par défaut, certains peuvent même être complètement centralisés. Pour améliorer la sécurité, il faut encore faire des compromis sur la performance, 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 directement le problème au niveau de la couche de base. Cette approche ne résout fondamentalement pas le problème, mais le transfère à la couche supérieure de la pile.
Optimistic Rollup
Actuellement, la plupart des rollups Optimistes sont centralisés (certaines n'ont même qu'un seul séquenceur), présentant des problèmes de sécurité insuffisante, d'isolement mutuel et de délais élevés (nécessitant d'attendre la période de preuve de fraude, généralement 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 "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups ont souvent des limites sur le volume de transactions par lot, ce qui peut provoquer des congestions réseau et une augmentation des frais de gas en période de forte demande, impactant 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 central de Polkadot.
De plus, le problème de disponibilité des données des ZK rollups aggrave également leurs inconvénients. Pour garantir que quiconque puisse vérifier les transactions, il est nécessaire de fournir des données de transaction complètes. Cela repose souvent sur des solutions supplémentaires de disponibilité des données, augmentant 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 emprunté la voie de la centralisation au détriment de la performance ni celle de la confiance prédéfinie au détriment de l'efficacité, mais a réalisé un équilibre multidimensionnel entre 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, le "scalabilité sans confiance" 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.
9 J'aime
Récompense
9
6
Partager
Commentaire
0/400
GateUser-a5fa8bd0
· Il y a 1h
Il faut bien apprendre le point ! On ne peut plus compter sur son ancien métier.
Voir l'originalRépondre0
AirdropworkerZhang
· 08-01 00:33
Cette efficacité est super élevée et le coût est super bas. Boss, je vais miner.
Voir l'originalRépondre0
MEVHunter
· 07-31 10:51
meh... le relaychain de dot est toujours un goulot d'étranglement sous une forte pression de mempool à vrai dire. J'ai vu des pics de flux toxiques la semaine dernière
Voir l'originalRépondre0
Lonely_Validator
· 07-31 10:51
Joueur expérimenté des blockchains publiques, Dot est très apprécié tout au long du parcours.
Voir l'originalRépondre0
DeFiCaffeinator
· 07-31 10:51
DOT n'est pas encore à la lune ? Pourquoi s'inquiéter ?
Polkadot extensibilité élastique : un équilibre entre performance et sécurité Web3 sans compromis
L'équilibre de l'évolutivité du Blockchain : l'exemple de Polkadot
Aujourd'hui, alors que la technologie Blockchain recherche constamment une efficacité accrue, un problème clé se dessine progressivement : comment améliorer les performances sans sacrifier la sécurité et la résilience du système ? Ce n'est pas seulement un défi technique, mais aussi un choix architectural profond. Pour l'écosystème Web3, un système plus rapide, s'il est construit sur la base d'un sacrifice de la confiance et de la sécurité, a souvent du mal à soutenir une véritable innovation durable.
Cet article explorera en profondeur les compromis et les arbitrages de Polkadot dans la conception de l'évolutivité, et comparera cela aux solutions d'autres chaînes publiques majeures, en analysant leurs choix de parcours différents en matière de performance, de sécurité et de décentralisation.
Les défis de la conception d'extension de Polkadot
É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 (Relay Chain). Le fonctionnement des Rollups dépend d'un séquenceur (sequencer) connecté à la chaîne de relais, dont la communication utilise le mécanisme de protocole collator. Ce protocole est entièrement sans autorisation et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de la chaîne de relais et soumettre des demandes de transition d'état de rollup. Ces demandes seront vérifiées par un core de la chaîne de relais, à condition de satisfaire un préalable : 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 scalabilité verticale en utilisant l'architecture multi-core de Polkadot. Cette nouvelle capacité est introduite par la fonctionnalité d'"Élasticité" (Elastic Scaling). Au cours du processus de conception, il a été constaté que, comme la validation des blocs Rollup n'est pas exécutée de manière fixe sur un core particulier, cela pourrait affecter son élasticité.
Étant donné que le protocole de soumission des blocs à la chaîne de relais est sans permission et sans confiance, toute personne peut soumettre un bloc à n'importe quel core attribué au rollup pour validation. Les attaquants pourraient exploiter cela en soumettant de manière répétée des blocs légitimes déjà validés à différents cores, consommant ainsi malicieusement des ressources et réduisant le débit et l'efficacité globale 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.
Problème de confiance du Sequencer
Une solution simple consiste à définir le protocole comme "ayant une licence" : par exemple, en utilisant un mécanisme de liste blanche, ou en faisant en sorte que les séquenceurs de confiance par défaut n'agissent pas de manière malveillante, garantissant ainsi l'activité du rollup. Cependant, dans la philosophie de conception de Polkadot, nous ne pouvons faire aucune hypothèse de confiance sur le séquenceur, car il est nécessaire de maintenir les caractéristiques "sans confiance" et "sans permission" du système. N'importe qui devrait pouvoir utiliser le protocole collator pour soumettre des demandes de transition d'état du rollup.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est : confier entièrement le problème à 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 d'élasticité et de sécurité. Polkadot réexécutera la transformation 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 qu'un bloc rollup ne soit écrit dans la couche de disponibilité des données (DA) de Polkadot, un groupe composé d'environ 5 validateurs va d'abord vérifier sa légitimité. Ils reçoivent les reçus candidats (candidate receipt) et les preuves de validité (PoV) soumis par le séquenceur, qui contiennent le bloc rollup ainsi que les preuves de stockage correspondantes. Ces informations seront traitées par la fonction de validation des chaînes parallèles et réexécutées par les validateurs sur la chaîne de relais.
Le résultat de la vérification contient un sélecteur de cœur (core selector), utilisé pour spécifier sur quel cœur (core) le bloc doit être vérifié. Le validateur comparera cet index avec celui du cœur dont il est responsable ; s'ils ne correspondent pas, ce bloc sera rejeté.
Ce mécanisme garantit que le système maintient toujours des caractéristiques sans confiance et sans autorisation, évitant ainsi que des acteurs malveillants comme les ordonnanceurs ne manipulent les positions de validation, assurant que même si le rollup utilise plusieurs core, il peut rester résilient.
sécurité
Dans sa quête d'évolutivité, Polkadot n'a pas fait de compromis sur la sécurité. La sécurité des rollups est garantie par la chaîne de relais, qui nécessite seulement un ordonneur honnête pour maintenir la survie.
Grâce au protocole ELVES, Polkadot étend intégralement sa sécurité à tous les rollups, vérifiant 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 évolutivité 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 exécutée tous les 6 secondes est augmentée, mais le type de calcul n'est pas affecté.
Complexité
Une plus grande capacité de traitement et une latence plus faible entraînent inévitablement une complexité, ce qui est le seul compromis acceptable dans la conception des systèmes.
Les Rollups peuvent ajuster dynamiquement les ressources via l'interface Agile Coretime pour maintenir un niveau de sécurité cohérent. Ils doivent également mettre en œuvre certaines exigences de la RFC103 pour s'adapter à différents scénarios d'utilisation.
La complexité spécifique dépend des stratégies de gestion des ressources du rollup, qui peuvent dépendre de variables en chaîne ou hors chaîne. Par exemple :
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'évolutivité flexible 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, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui sont attribués.
À l'avenir, Polkadot prendra également en charge la messagerie hors chaîne (off-chain messaging), avec la chaîne de relais comme couche de contrôle, plutôt que comme couche de données. Cette mise à niveau améliorera la capacité de communication entre les rollups en même temps que l'extension élastique, renforçant ainsi la capacité d'extension verticale du système.
Compromis d'autres protocoles
Comme tout le monde le sait, l'amélioration des performances se fait souvent au prix de la décentralisation et de la sécurité. Mais d'après le coefficient de Nakamoto, même si certains concurrents de Polkadot sont moins décentralisés, 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, s'appuyant sur la preuve historique (PoH), le traitement parallèle par CPU et un mécanisme de consensus basé sur un leader, avec un TPS théorique pouvant atteindre 65 000.
Un élément clé de la conception est son mécanisme de planification des leaders, qui est préalablement public et vérifiable :
PoH et le traitement parallèle exigent des matériels très performants, 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 encore 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 poursuivre le TPS, son coefficient de Nakamoto n'étant que de 20, bien inférieur aux 172 de Polkadot.
TON
TON prétend que le TPS peut atteindre 104 715, mais ce chiffre a été réalisé dans 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 fragments peut être révélée à l'avance. Le livre blanc de TON 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 de mécanisme de "faillite des parieurs", un attaquant peut attendre qu'un fragment soit complètement contrôlé par lui, ou bloquer les validateurs honnêtes par une attaque DDoS, ce qui lui permet de modifier l'état.
En comparaison, les validateurs de Polkadot sont assignés de manière aléatoire et leur identité est révélée avec un certain 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 dès qu'un validateur honnête soulève une contestation, l'attaque échoue et entraîne des pertes pour l'attaquant.
Avalanche
Avalanche utilise une architecture de réseau principal + sous-réseaux pour l'évolutivité, le réseau principal étant composé de X-Chain (transferts, ~4 500 TPS), C-Chain (contrats intelligents, ~100-200 TPS) et P-Chain (gestion des validateurs et des sous-réseaux).
Chaque sous-réseau peut atteindre un TPS théorique d'environ 5 000, similaire à l'approche 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 à des sous-réseaux, qui peuvent imposer des exigences supplémentaires telles que géographiques ou KYC, sacrifiant ainsi la décentralisation et la sécurité.
Dans Polkadot, tous les rollups partagent une garantie de sécurité unifiée ; tandis que les sous-réseaux d'Avalanche n'ont pas de garantie de sécurité par défaut, certains peuvent même être complètement centralisés. Pour améliorer la sécurité, il faut encore faire des compromis sur la performance, 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 directement le problème au niveau de la couche de base. Cette approche ne résout fondamentalement pas le problème, mais le transfère à la couche supérieure de la pile.
Optimistic Rollup
Actuellement, la plupart des rollups Optimistes sont centralisés (certaines n'ont même qu'un seul séquenceur), présentant des problèmes de sécurité insuffisante, d'isolement mutuel et de délais élevés (nécessitant d'attendre la période de preuve de fraude, généralement 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 "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups ont souvent des limites sur le volume de transactions par lot, ce qui peut provoquer des congestions réseau et une augmentation des frais de gas en période de forte demande, impactant 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 central de Polkadot.
De plus, le problème de disponibilité des données des ZK rollups aggrave également leurs inconvénients. Pour garantir que quiconque puisse vérifier les transactions, il est nécessaire de fournir des données de transaction complètes. Cela repose souvent sur des solutions supplémentaires de disponibilité des données, augmentant 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 emprunté la voie de la centralisation au détriment de la performance ni celle de la confiance prédéfinie au détriment de l'efficacité, mais a réalisé un équilibre multidimensionnel entre 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, le "scalabilité sans confiance" défendu par Polkadot est peut-être la véritable solution capable de soutenir le développement à long terme du Web3.