Équilibre entre évolutivité et sécurité : conception de l'architecture Web3 de Polkadot
Dans un contexte où la technologie blockchain recherche constamment une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances sans sacrifier la sécurité et la résilience du système ? Cela représente non seulement un défi technique, mais implique également des réflexions profondes sur la conception architecturale. Pour l'écosystème Web3, un système à haute vitesse qui se construit au détriment de la confiance et de la sécurité est souvent difficile à soutenir pour une véritable innovation durable.
En tant que moteur important de l'évolutivité Web3, Polkadot a-t-il fait certains compromis dans sa quête de haut débit 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é du réseau ? Cet article discutera de ces questions, en analysant en profondeur les choix et les compromis de Polkadot dans la conception de son évolutivité, et en les comparant aux solutions d'autres chaînes publiques majeures, en explorant leurs choix différents en matière de performance, de sécurité et de décentralisation.
Les défis de la conception d'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. Cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible qu'un point de défaillance unique ou un contrôle se forme, affectant ainsi ses caractéristiques de décentralisation ?
Le fonctionnement des Rollups dépend des ordonneurs du parachain connecté, dont la communication utilise le mécanisme de protocole collator. Ce protocole est entièrement sans permission et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de parachain et soumettre des demandes de transition d'état pour le rollup. Ces demandes seront vérifiées par un certain core de la parachain, à condition de respecter un prérequis : la transition d'état doit être valide, sinon l'état du rollup ne sera pas avancé.
compromis d'extension verticale
Les Rollups peuvent réaliser une mise à l'échelle verticale en tirant parti de l'architecture multicore de Polkadot. Cette nouvelle capacité est introduite par la fonction « mise à l'échelle élastique ». Au cours du processus de conception, il a été constaté que, comme la validation des blocs rollup n'est pas fixée à un core spécifique, cela pourrait affecter son elasticité.
Étant donné que le protocole pour soumettre des blocs à la chaîne relais est sans permission et sans confiance, n'importe qui peut soumettre un bloc à n'importe quel core attribué au rollup pour validation. Un attaquant pourrait exploiter cela en soumettant de manière répétée des blocs légitimes déjà validés à différents cores, consommant ainsi des ressources de manière malveillante, ce qui réduit 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 relais, sans compromettre les caractéristiques clés du système.
Problème de confiance du séquenceur
Une solution simple consiste à définir le protocole comme "avec licence" : par exemple, en adoptant un mécanisme de liste blanche, ou en supposant par défaut que le tri ne se comportera pas de manière malveillante, garantissant ainsi l'activité du rollup.
Cependant, dans la philosophie de conception de Polkadot, nous ne pouvons faire aucune hypothèse de confiance concernant le séquenceur, car il est essentiel de maintenir les caractéristiques de « sans confiance » et « sans permission » du système. Quiconque devrait pouvoir soumettre des demandes de transformation d'état de rollup en utilisant le protocole collator.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est de laisser entièrement la résolution des problèmes à 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 core de Polkadot la validation doit être effectuée.
Ce design garantit à la fois la flexibilité et la sécurité. Polkadot réexécutera les transitions d'état du rollup dans le processus de disponibilité et assurera l'exactitude de l'allocation du core grâce au protocole économique cryptographique ELVES.
Avant que les données de Polkadot ne soient écrites dans n'importe quel bloc rollup, un petit groupe composé d'environ 5 validateurs validera 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 vérification contient un sélecteur de core, qui est utilisé pour spécifier sur quel core le bloc doit être vérifié. Le validateurs compareront cet index avec le core dont ils sont responsables ; s'ils ne correspondent 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 que des acteurs malveillants comme les ordonnanceurs ne manipulent la position de validation, assurant ainsi que même si le rollup utilise plusieurs cœurs, il peut rester résilient.
sécurité
Dans sa quête d'évolutivité, Polkadot n'a pas compromis la sécurité. La sécurité des rollups est garantie par la chaîne de relais, nécessitant seulement un ordonneur honnête pour maintenir la viabilité.
Grâce au protocole ELVES, Polkadot étend complètement sa sécurité à tous les rollups, en vérifiant tous les calculs sur le core, sans avoir à imposer de limites ou d'hypothèses 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'élasticité d'extension 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'élasticité d'extension, la quantité totale de calculs pouvant être exécutés dans un 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 du 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 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 les charges de transaction spécifiques dans le mempool des nœuds ;
Stratégies automatisées : Configurer les ressources en appelant à l'avance le service coretime via des données historiques et l'interface XCM.
Bien que 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é flexible n'affecte pas le débit des messages.
La communication des messages entre les rollups est réalisée par la couche de transport sous-jacente, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui sont alloués.
À l'avenir, Polkadot prendra également en charge la messagerie hors chaîne, avec la chaîne de relais comme interface de contrôle plutôt que comme interface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups avec une extension élastique, renforçant ainsi la capacité d'extension verticale du système.
Compromis des autres protocoles
Comme tout le monde le sait, l'amélioration des performances est souvent obtenue au prix 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 degré de décentralisation plus faible, 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 à haute capacité de traitement à couche unique, s'appuyant sur la preuve historique, 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 préalablement divulgué 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 misez, plus vous recevez de récompenses. Par exemple, un validateurs misant 1% recevra environ 1% des chances de produire des blocs ;
Tous les mineurs 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.
L'histoire prouve que le traitement parallèle exige des ressources matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud est staké, 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ésilience aux attaques pour poursuivre le TPS, son coefficient de Nakamoto n'étant que de 20, bien en dessous de celui de Polkadot qui est de 172.
TON
TON prétend que le TPS peut atteindre 104 715, mais ce chiffre a été atteint dans un réseau de test privé, avec 256 nœuds, dans des conditions de réseau et de matériel idéales. Pendant ce temps, 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 sera exposée à l'avance. Le livre blanc de TON indique également que cela peut optimiser la bande passante, mais peut aussi ê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 totalement contrôlé par lui ou bloquer les validateurs honnêtes par une attaque DDoS, altérant ainsi l'état.
En revanche, les validateurs de Polkadot sont attribués de manière aléatoire et révélés avec un délai, ce qui empêche les attaquants de connaître à l'avance l'identité des validateurs. Pour réussir une attaque, ils doivent parier sur le contrôle total et, dès qu'un validateurs 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 est composé de X-Chain (transferts, ~4 500 TPS), C-Chain (contrats intelligents, ~100-200 TPS), P-Chain (gestion des validateurs et des sous-réseaux).
Chaque TPS théorique de sous-réseau peut 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 à un sous-réseau, et le sous-réseau peut imposer des exigences géographiques, KYC, etc., sacrifiant ainsi la décentralisation et 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 garanties 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 essentiellement pas résolu le problème, mais a plutôt transféré le problème à la couche supérieure de la pile.
Rollup optimiste
Actuellement, la plupart des rollups optimistes sont centralisés, 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 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 très élevées, et le mécanisme de "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups limitent souvent le volume de transactions par lot, ce qui peut provoquer des congestions réseau et une 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, le problème de la disponibilité des données dans les ZK rollups exacerbera également leurs inconvénients. Pour s'assurer que tout le monde puisse vérifier les transactions, il est toujours nécessaire de fournir des données de transaction complètes. Cela dépend généralement de solutions supplémentaires de disponibilité des données, ce qui augmente encore les coûts et les frais pour les utilisateurs.
Conclusion
La fin de l'évolutivité ne devrait pas être un compromis.
Comparé à d'autres blockchains, Polkadot n'a pas choisi de sacrifier la décentralisation pour des performances, ni de faire confiance à des systèmes prédéfinis pour l'efficacité. Il 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 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.
19 J'aime
Récompense
19
5
Reposter
Partager
Commentaire
0/400
NFT_Therapy
· 07-16 00:58
Encore vu mon vieux fren dot !
Voir l'originalRépondre0
LayerZeroHero
· 07-14 19:38
Il s'avère qu'il y a certainement un compromis, et il faut encore exécuter des benchmarks pour le vérifier...
Voir l'originalRépondre0
BearMarketBuyer
· 07-14 19:17
dot est vraiment bon.. ça fait trois ans que je suis holder
L'architecture Web3 de Polkadot : un équilibre parfait entre évolutivité et sécurité
Équilibre entre évolutivité et sécurité : conception de l'architecture Web3 de Polkadot
Dans un contexte où la technologie blockchain recherche constamment une plus grande efficacité, une question clé émerge progressivement : comment améliorer les performances sans sacrifier la sécurité et la résilience du système ? Cela représente non seulement un défi technique, mais implique également des réflexions profondes sur la conception architecturale. Pour l'écosystème Web3, un système à haute vitesse qui se construit au détriment de la confiance et de la sécurité est souvent difficile à soutenir pour une véritable innovation durable.
En tant que moteur important de l'évolutivité Web3, Polkadot a-t-il fait certains compromis dans sa quête de haut débit 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é du réseau ? Cet article discutera de ces questions, en analysant en profondeur les choix et les compromis de Polkadot dans la conception de son évolutivité, et en les comparant aux solutions d'autres chaînes publiques majeures, en explorant leurs choix différents en matière de performance, de sécurité et de décentralisation.
Les défis de la conception d'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. Cela pourrait-il introduire des risques de centralisation dans certains aspects ? Est-il possible qu'un point de défaillance unique ou un contrôle se forme, affectant ainsi ses caractéristiques de décentralisation ?
Le fonctionnement des Rollups dépend des ordonneurs du parachain connecté, dont la communication utilise le mécanisme de protocole collator. Ce protocole est entièrement sans permission et sans confiance, toute personne ayant une connexion réseau peut l'utiliser, se connecter à un petit nombre de nœuds de parachain et soumettre des demandes de transition d'état pour le rollup. Ces demandes seront vérifiées par un certain core de la parachain, à condition de respecter un prérequis : la transition d'état doit être valide, sinon l'état du rollup ne sera pas avancé.
compromis d'extension verticale
Les Rollups peuvent réaliser une mise à l'échelle verticale en tirant parti de l'architecture multicore de Polkadot. Cette nouvelle capacité est introduite par la fonction « mise à l'échelle élastique ». Au cours du processus de conception, il a été constaté que, comme la validation des blocs rollup n'est pas fixée à un core spécifique, cela pourrait affecter son elasticité.
Étant donné que le protocole pour soumettre des blocs à la chaîne relais est sans permission et sans confiance, n'importe qui peut soumettre un bloc à n'importe quel core attribué au rollup pour validation. Un attaquant pourrait exploiter cela en soumettant de manière répétée des blocs légitimes déjà validés à différents cores, consommant ainsi des ressources de manière malveillante, ce qui réduit 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 relais, sans compromettre les caractéristiques clés du système.
Problème de confiance du séquenceur
Une solution simple consiste à définir le protocole comme "avec licence" : par exemple, en adoptant un mécanisme de liste blanche, ou en supposant par défaut que le tri ne se comportera pas de manière malveillante, garantissant ainsi l'activité du rollup.
Cependant, dans la philosophie de conception de Polkadot, nous ne pouvons faire aucune hypothèse de confiance concernant le séquenceur, car il est essentiel de maintenir les caractéristiques de « sans confiance » et « sans permission » du système. Quiconque devrait pouvoir soumettre des demandes de transformation d'état de rollup en utilisant le protocole collator.
Polkadot : une solution sans compromis
La solution finalement choisie par Polkadot est de laisser entièrement la résolution des problèmes à 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 core de Polkadot la validation doit être effectuée.
Ce design garantit à la fois la flexibilité et la sécurité. Polkadot réexécutera les transitions d'état du rollup dans le processus de disponibilité et assurera l'exactitude de l'allocation du core grâce au protocole économique cryptographique ELVES.
Avant que les données de Polkadot ne soient écrites dans n'importe quel bloc rollup, un petit groupe composé d'environ 5 validateurs validera 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 vérification contient un sélecteur de core, qui est utilisé pour spécifier sur quel core le bloc doit être vérifié. Le validateurs compareront cet index avec le core dont ils sont responsables ; s'ils ne correspondent 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 que des acteurs malveillants comme les ordonnanceurs ne manipulent la position de validation, assurant ainsi que même si le rollup utilise plusieurs cœurs, il peut rester résilient.
sécurité
Dans sa quête d'évolutivité, Polkadot n'a pas compromis la sécurité. La sécurité des rollups est garantie par la chaîne de relais, nécessitant seulement un ordonneur honnête pour maintenir la viabilité.
Grâce au protocole ELVES, Polkadot étend complètement sa sécurité à tous les rollups, en vérifiant tous les calculs sur le core, sans avoir à imposer de limites ou d'hypothèses 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'élasticité d'extension 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'élasticité d'extension, la quantité totale de calculs pouvant être exécutés dans un 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 du 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 s'appuyer sur des variables on-chain ou off-chain. Par exemple :
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é flexible n'affecte pas le débit des messages.
La communication des messages entre les rollups est réalisée par la couche de transport sous-jacente, et l'espace de bloc de communication de chaque rollup est fixe, indépendamment du nombre de cœurs qui lui sont alloués.
À l'avenir, Polkadot prendra également en charge la messagerie hors chaîne, avec la chaîne de relais comme interface de contrôle plutôt que comme interface de données. Cette mise à niveau améliorera la capacité de communication entre les rollups avec une extension élastique, renforçant ainsi la capacité d'extension verticale du système.
Compromis des autres protocoles
Comme tout le monde le sait, l'amélioration des performances est souvent obtenue au prix 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 degré de décentralisation plus faible, 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 à haute capacité de traitement à couche unique, s'appuyant sur la preuve historique, 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 préalablement divulgué et vérifiable :
L'histoire prouve que le traitement parallèle exige des ressources matérielles très élevées, ce qui entraîne une centralisation des nœuds de validation. Plus un nœud est staké, 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ésilience aux attaques pour poursuivre le TPS, son coefficient de Nakamoto n'étant que de 20, bien en dessous de celui de Polkadot qui est de 172.
TON
TON prétend que le TPS peut atteindre 104 715, mais ce chiffre a été atteint dans un réseau de test privé, avec 256 nœuds, dans des conditions de réseau et de matériel idéales. Pendant ce temps, 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 sera exposée à l'avance. Le livre blanc de TON indique également que cela peut optimiser la bande passante, mais peut aussi ê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 totalement contrôlé par lui ou bloquer les validateurs honnêtes par une attaque DDoS, altérant ainsi l'état.
En revanche, les validateurs de Polkadot sont attribués de manière aléatoire et révélés avec un délai, ce qui empêche les attaquants de connaître à l'avance l'identité des validateurs. Pour réussir une attaque, ils doivent parier sur le contrôle total et, dès qu'un validateurs 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 est composé de X-Chain (transferts, ~4 500 TPS), C-Chain (contrats intelligents, ~100-200 TPS), P-Chain (gestion des validateurs et des sous-réseaux).
Chaque TPS théorique de sous-réseau peut 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 à un sous-réseau, et le sous-réseau peut imposer des exigences géographiques, KYC, etc., sacrifiant ainsi la décentralisation et 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 garanties 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 essentiellement pas résolu le problème, mais a plutôt transféré le problème à la couche supérieure de la pile.
Rollup optimiste
Actuellement, la plupart des rollups optimistes sont centralisés, 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 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 très élevées, et le mécanisme de "winner takes all" peut facilement conduire à une centralisation du système. Pour garantir le TPS, les ZK rollups limitent souvent le volume de transactions par lot, ce qui peut provoquer des congestions réseau et une 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, le problème de la disponibilité des données dans les ZK rollups exacerbera également leurs inconvénients. Pour s'assurer que tout le monde puisse vérifier les transactions, il est toujours nécessaire de fournir des données de transaction complètes. Cela dépend généralement de solutions supplémentaires de disponibilité des données, ce qui augmente encore les coûts et les frais pour les utilisateurs.
Conclusion
La fin de l'évolutivité ne devrait pas être un compromis.
Comparé à d'autres blockchains, Polkadot n'a pas choisi de sacrifier la décentralisation pour des performances, ni de faire confiance à des systèmes prédéfinis pour l'efficacité. Il 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 est peut-être la véritable solution capable de soutenir le développement à long terme du Web3.