GavinWood propose de minimiser la chaîne de relais

La chaîne de relais est la partie centrale du réseau Polkadot, qui contient la logique principale du réseau. Il est nécessaire que la chaîne de relais assume cette logique de base avant que la parachaîne puisse commencer à fonctionner et que XCM puisse être développé. Mais avec le développement du temps, maintenant ces logiques de base peuvent être considérées comme migrées vers la parachain du système! En conséquence, le Dr Gavin Wood et Joe Petrowski de la Fondation Web3 ont lancé la RFC-32, proposant de migrer la logique de plusieurs sous-systèmes de la chaîne de relais vers la « parachaîne système » qui, ensemble, forment l’ensemble du réseau Polkadot.

Alors, pourquoi décomposer une partie de la logique de la chaîne de relais en parachaînes de système? Quelles caractéristiques sont décomposées en premier ? Découvrez les informations importantes compilées par PolkaWorld ci-dessous!

Pourquoi voulez-vous faire cela? **

Le réseau Polkadot est conçu pour évoluer et permettre à plusieurs machines d’état indépendantes (c’est-à-dire des parachaînes) de fonctionner sous une garantie de sécurité et de validité commune. Pour obtenir cette garantie, la chaîne de relais dispose d’un ensemble de validateurs qui sont principalement responsables de la sécurité de la chaîne de relais. Cependant, tous les validateurs ne traitent pas directement des transitions d’état pour les parachains. Chaque transition d’état de la parachaîne est gérée par un sous-ensemble de validateurs, appelé groupe de soutien. Cela signifie que tous les validateurs ne traitent pas directement de chaque transition d’état de la parachain, seul un sous-ensemble d’entre eux est responsable de la gestion des transitions d’état.

Mais lorsque des transitions d’état se produisent sur la chaîne de relais, tous les validateurs doivent être impliqués dans l’exécution pour assurer la cohérence et la sécurité du réseau. Cependant, un effet secondaire de cette conception est un goulot d’étranglement des performances, car chaque changement d’état nécessite une validation à l’échelle du réseau, ce qui augmente la latence et limite le débit.

Mais si la transition d’état de la chaîne de relais peut être effectuée sur la parachain, cela libérera des ressources. Cela signifie que la partie des ressources du validateur qui serait autrement utilisée pour les transitions d’état de la chaîne de relais peut être réutilisée, offrant ainsi au réseau plus de temps de cœur, c’est-à-dire plus d’espace de bloc.

En général, il existe plusieurs raisons principales de migrer une partie de la logique de la chaîne de relais vers la parachain système :

1. Performance et évolutivité: En migrant certaines logiques et responsabilités sur une parachaîne système, la chaîne relais peut se concentrer sur ses responsabilités principales, améliorant ainsi les performances et l’évolutivité de l’ensemble du réseau.
2. Optimisation des ressources : lorsqu’une partie de la logique est migrée vers la parachain système, la chaîne de relais peut libérer plus de ressources pour d’autres tâches, telles que le traitement de la messagerie inter-chaînes ou la sécurité d’un plus grand nombre de parachains.
3. Modularité et flexibilité: La conception modulaire facilite la modification, la mise à niveau ou l’ajout de nouvelles fonctionnalités sans interférer avec le fonctionnement principal de la chaîne de relais. Cela offre une plus grande flexibilité pour l’innovation future et l’expansion des fonctionnalités.
4. Sécurité : La séparation de parties de la logique de la chaîne de relais réduit le risque d’un point de défaillance unique. Sur une parachain système distincte, si une parachain est attaquée ou échoue, il est peu probable que cela affecte la chaîne de relais ou d’autres parachains.
5. Plus d’opportunités de parachain : En libérant les ressources de la chaîne de relais, le réseau Polkadot peut prendre en charge davantage de rejoindre les parachaînes, élargissant ainsi son écosystème.
6. Optimisation de fonctionnalités spécifiques: Au fur et à mesure que Polkadot évolue, certaines fonctionnalités ou logiques peuvent nécessiter des optimisations spécialisées ou des méthodes de traitement spécialisées. Le déplacement de ces fonctions vers des parachains système spécialisées garantit qu’elles sont traitées et optimisées de manière optimale.

**Quelles fonctions seront décomposées en parachaînes système ? **

Les modules et sous-systèmes suivants sont des options possibles pour la migration hors de la chaîne de jonction :

1.Identité

2. Soldes

3. Jalonnement (jalonnement)

Frapper

Fournisseur d’élections

Liste des sacs

NIS

Bassins de mise en candidature

Départicipation rapide

4. Gouvernance

Trésorerie et primes

Vote de conviction

Référendum

Remarque : Les modules actuels d’enchères et de crowdlending ne seront plus utilisés, mais seront remplacés par un nouveau système appelé Coretime. Les détails sur la chaîne système de Coretime et ses interfaces sont décrits dans RFC-1 et RFC-5, respectivement. Polkadot Fellowship développe également des parachains Coretime. Pour plus de progrès de Polkadot, veuillez consulter Polkadot Q3 Progress: 5 nouvelles parachains lancées, USDC entre dans l’écosystème, les enjeux, les comptes séparés et les événements en chaîne augmentent considérablement.

Comment migrer ? **

Certains sous-systèmes peuvent être migrés de la chaîne de relais vers d’autres emplacements relativement simplement. En utilisant l’authentification comme exemple, vous pouvez simplement bloquer les changements d’état sur la chaîne de relais et définir l’état initial de la nouvelle chaîne à l’aide de l’état associé à l’authentification. Cet état initial et la logique associée, ou modules, sont ensuite utilisés pour démarrer une nouvelle chaîne.

Cependant, certains sous-systèmes ne peuvent pas avoir de temps d’arrêt pendant le processus de migration, car ils sont essentiels au bon fonctionnement de l’ensemble du réseau, tels que le jalonnement et la gouvernance. Même dans ce cas, ces sous-systèmes critiques peuvent coexister avec d’autres chaînes de systèmes avec des autorisations similaires pendant un certain temps. Tout comme « Gov1 » et « OpenGov » ont coexisté lorsque ce dernier a été introduit.