Le développement de Parachains à la demande (également connu sous le nom de Parathreads) a commencé ! Beaucoup de gens attendent déjà le lancement des threads parallèles. Cet article partagera ce qu'est un thread parallèle ? Comment les parathreads obtiennent-ils le droit de produire des blocs ? Et le processus de vérification du collecteur, etc.
Les parachains à la demande sont la première variante d'une manière plus dynamique d'acquérir de l'espace de bloc. Les parachains existantes offrent un moyen très statique d'acquérir de l'espace de bloc, c'est-à-dire de gagner une enchère et d'avoir ensuite un espace de bloc garanti disponible pendant une longue période, comme un an. Actuellement, la parachain produit un bloc toutes les 12 secondes tout au long de la période. Cette garantie de produire régulièrement des blocs est en effet ce dont ont besoin certaines applications/chaînes, et c'est une des caractéristiques qui rendent les parachains supérieures aux contrats intelligents.
Mais d'un autre côté, du point de vue du réseau, c'est trop lourd pour certaines applications, et leur transformation en parachain entraînera beaucoup de gaspillage de ressources. Du point de vue de l'utilisateur, remporter une enchère est une barrière à l'entrée relativement élevée, ce qui rend difficile l'adhésion de nouveaux projets et idées au réseau. Avec les parachains à la demande, nous abaissons cette barrière et ouvrons le réseau à des applications moins gourmandes en ressources de manière plus efficace.
Alors, comment ça marche? Au lieu de programmer une génération de bloc toutes les 12 secondes, une parachain à la demande, si nécessaire, un assembleur commande un noyau (une opportunité de génération de bloc) et envoie une génération de bloc spéciale à la chaîne de relais de Polkadot. un noyau pour leur ParaId et inclut le prix maximum qu'ils sont prêts à payer.
Commander un noyau
L'exécution de la chaîne de relais calculera le meilleur prix actuel du noyau, si le prix le plus élevé d'une nouvelle commande est égal ou supérieur et que le compte dispose de fonds suffisants, il sera alors facturé en fonction du meilleur prix actuel et sera bientôt Le producteur de bloc organise l'autorité de bloc. Ce prix est calculé par la chaîne de relais en fonction de la demande actuelle. Il repose sur le même mécanisme que les frais, afin de réagir lentement à la demande pour éviter les fluctuations sauvages des prix.
Le co-fondateur de Polkadot, Robert, a ajouté à cette question, expliquant que dans le mécanisme de paiement des frais de Parathreads, quel que soit le prix le plus élevé qu'un soumissionnaire est prêt à payer, les frais payés sont les mêmes. Lorsque la demande de parachains à la demande est élevée, le prix du noyau augmentera lentement lors d'un ajustement automatique.
Il peut y avoir un problème "MEV" dans cette situation, qui fait référence aux revenus supplémentaires que les mineurs ou les validateurs peuvent obtenir en manipulant l'ordre des transactions ou les transactions incluses. Par exemple, les validateurs peuvent choisir de retarder le traitement des commandes avec des offres plus élevées afin de pouvoir collecter ou brûler plus de frais. Mais les "extrinsèques mortelles" de Polkadot limitent cette possibilité. Les "extrinsèques mortelles" sont des transactions avec un cycle de vie, ce qui signifie que ces transactions n'attendront pas indéfiniment pour être traitées, et seront automatiquement rejetées après un certain temps, limitant ainsi l'espace de fonctionnement du validateur.
Pour que les parathreads utilisent les mécanismes de sécurité existants lors de la demande d'autorisation de blocage, la transaction (extrinsèque) qu'ils envoient pour demander l'autorisation de blocage doit être signée. Un « extrinsèque signé » signifie que le compte qui a envoyé la transaction a signé la transaction avec sa propre clé privée. Ceci est conçu pour empêcher d'autres personnes d'envoyer des transactions en usurpant l'identité du compte, puisque personne d'autre que le propriétaire du compte ne peut générer une signature qui correspond à la clé publique du compte. Ainsi, lorsque la chaîne de relais reçoit une transaction signée, elle peut confirmer que la transaction a bien été envoyée par qui elle prétend être.
En outre, les transactions signées peuvent également contenir des informations supplémentaires, telles que nonce (utilisé pour empêcher les attaques par relecture) et tip (utilisé pour donner un pourboire au donneur de bloc). La chaîne de relais dispose déjà d'un mécanisme pour gérer ces informations, donc faire en sorte que les requêtes de blocage des parachains axées sur la demande utilisent des transactions signées leur permet de tirer directement parti de ces mécanismes existants sans avoir à développer de nouveaux mécanismes de sécurité.
Du point de vue de l'utilisateur, cela signifie que le prix total à payer se compose de trois parties : les frais de transaction traditionnels (qui servent à payer les ressources informatiques nécessaires au traitement de la transaction), un pourboire facultatif (qui sert à pour encourager les producteurs de blocs à prioriser leurs transactions), et le prix du cœur de souscription mentionné ci-dessus (c'est-à-dire le prix de la puissance du bloc).
Intégrer le mécanisme de commande dans le nœud collecteur
Le processus de création de bloc réel est exactement le même pour les validateurs (collators) que pour les parachains statiques. Les assembleurs sont des nœuds responsables de la collecte et de la création de blocs. Ils vérifient régulièrement l'état des parachains, en particulier les parachains dont ils sont responsables (identifiés par ParaId). S'ils constatent que la parachain correspondant à leur ParaId est sur le point d'atteindre le moment de créer un bloc, ils commenceront à générer un nouveau bloc. Après avoir généré le bloc, ils doivent générer une preuve (preuve de validité, appelée PoV), qui contient le contenu du bloc et les informations prouvant la validité du bloc. Ensuite, ils enverront cette preuve PoV au groupe de soutien assigné (Backing Group). Le groupe d'endossement est un groupe de nœuds chargés de vérifier et de confirmer la validité de ce bloc.
Bien que le processus de génération de blocs sur la parachain à la demande soit le même que celui sur la parachain statique, sur la parachain à la demande, nous devons introduire un nouveau mécanisme dans les assembleurs (Colllators), afin qu'ils puissent Lors de l'envoi de demandes de bloc opportunités de génération (c'est-à-dire les "commandes de base").
Il existe actuellement plusieurs stratégies possibles sur la façon de concevoir ce nouveau mécanisme (si vous êtes intéressé par ce problème, ou si vous avez une certaine connaissance de Cumulus, creuser ce problème sera un bon moyen de participer à ce projet, et d'aider sur- exigent que les parachains soient réalisés plus rapidement.
Cumulus est un framework de développement pour la construction de parachains sur les réseaux Polkadot et Kusama. Il a été développé par Parity Technologies, le principal développeur de Polkadot. Cumulus réduit la complexité pour les développeurs de construire des Parachains. Lorsque vous utilisez Cumulus pour créer une parachain, vous pouvez tirer parti de certaines logiques et fonctions partagées déjà implémentées dans Cumulus, telles que la communication avec la chaîne de relais, la vérification des blocs et le traitement de la finalité. Cela permet aux développeurs de se concentrer sur leur logique métier sans avoir à gérer ces problèmes de bas niveau.
Dans l'ensemble, l'objectif de Cumulus est de rendre la construction de parachains aussi simple que possible afin de promouvoir le développement de l'écologie Polkadot et Kusama.
Un autre rappel important est qu'il peut y avoir un risque de sécurité si l'assembleur fonctionne à partir d'un hot wallet (un portefeuille connecté au réseau). Par conséquent, nous fournirons un type de compte proxy dédié, qui n'a que l'autorité d'enchères principale sur la parachaîne à la demande, réduisant ainsi les risques de sécurité.
prise en charge asynchrone intégrée et plus de détails
Pour un public technique plus intéressé, le développement complet de la parachain à la demande est suivi ici.
Les sous-tâches peuvent être trouvées ici (en particulier pour l'intégration à venir du support asynchrone, certaines réflexions sont résumées dans ce commentaire (.
En bref, l'abstraction de base existante ne sera plus à 0 dimension, mais à 1 dimension. Cela peut signifier que le fonctionnement du système ou du modèle deviendra plus flexible ou complexe, permettant à ces « cœurs » ou à d'autres parties du système de connaître à l'avance ou de prédire les tâches ou les événements qui se produiront dans le futur. Il peut s'agir d'une optimisation ou d'une amélioration qui rend le système global plus apte à prévoir et à traiter l'activité future.
Dans Polkadot, un "noyau" est un nœud spécial responsable du traitement et de la vérification des transactions et d'autres activités sur les parachains, et "l'abstraction du noyau" fait généralement référence à une conception dans laquelle certains mécanismes internes complexes ou détails de mise en œuvre sont abstraits Caché sous une interface simple ou concept.
Mais assez de détails pour le moment. Nous sommes très enthousiasmés par les nouvelles possibilités qu'apporteront les parachaînes à la demande et nous avons hâte de les voir en direct !
Lien de référence du contenu :
Voir l'original
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.
Le développement du parathread Polkadot a commencé à comprendre son fonctionnement
Compilation : PolkaWorld
Le développement de Parachains à la demande (également connu sous le nom de Parathreads) a commencé ! Beaucoup de gens attendent déjà le lancement des threads parallèles. Cet article partagera ce qu'est un thread parallèle ? Comment les parathreads obtiennent-ils le droit de produire des blocs ? Et le processus de vérification du collecteur, etc.
Les parachains à la demande sont la première variante d'une manière plus dynamique d'acquérir de l'espace de bloc. Les parachains existantes offrent un moyen très statique d'acquérir de l'espace de bloc, c'est-à-dire de gagner une enchère et d'avoir ensuite un espace de bloc garanti disponible pendant une longue période, comme un an. Actuellement, la parachain produit un bloc toutes les 12 secondes tout au long de la période. Cette garantie de produire régulièrement des blocs est en effet ce dont ont besoin certaines applications/chaînes, et c'est une des caractéristiques qui rendent les parachains supérieures aux contrats intelligents.
Mais d'un autre côté, du point de vue du réseau, c'est trop lourd pour certaines applications, et leur transformation en parachain entraînera beaucoup de gaspillage de ressources. Du point de vue de l'utilisateur, remporter une enchère est une barrière à l'entrée relativement élevée, ce qui rend difficile l'adhésion de nouveaux projets et idées au réseau. Avec les parachains à la demande, nous abaissons cette barrière et ouvrons le réseau à des applications moins gourmandes en ressources de manière plus efficace.
Alors, comment ça marche? Au lieu de programmer une génération de bloc toutes les 12 secondes, une parachain à la demande, si nécessaire, un assembleur commande un noyau (une opportunité de génération de bloc) et envoie une génération de bloc spéciale à la chaîne de relais de Polkadot. un noyau pour leur ParaId et inclut le prix maximum qu'ils sont prêts à payer.
Commander un noyau
L'exécution de la chaîne de relais calculera le meilleur prix actuel du noyau, si le prix le plus élevé d'une nouvelle commande est égal ou supérieur et que le compte dispose de fonds suffisants, il sera alors facturé en fonction du meilleur prix actuel et sera bientôt Le producteur de bloc organise l'autorité de bloc. Ce prix est calculé par la chaîne de relais en fonction de la demande actuelle. Il repose sur le même mécanisme que les frais, afin de réagir lentement à la demande pour éviter les fluctuations sauvages des prix.
Le co-fondateur de Polkadot, Robert, a ajouté à cette question, expliquant que dans le mécanisme de paiement des frais de Parathreads, quel que soit le prix le plus élevé qu'un soumissionnaire est prêt à payer, les frais payés sont les mêmes. Lorsque la demande de parachains à la demande est élevée, le prix du noyau augmentera lentement lors d'un ajustement automatique.
Il peut y avoir un problème "MEV" dans cette situation, qui fait référence aux revenus supplémentaires que les mineurs ou les validateurs peuvent obtenir en manipulant l'ordre des transactions ou les transactions incluses. Par exemple, les validateurs peuvent choisir de retarder le traitement des commandes avec des offres plus élevées afin de pouvoir collecter ou brûler plus de frais. Mais les "extrinsèques mortelles" de Polkadot limitent cette possibilité. Les "extrinsèques mortelles" sont des transactions avec un cycle de vie, ce qui signifie que ces transactions n'attendront pas indéfiniment pour être traitées, et seront automatiquement rejetées après un certain temps, limitant ainsi l'espace de fonctionnement du validateur.
Pour que les parathreads utilisent les mécanismes de sécurité existants lors de la demande d'autorisation de blocage, la transaction (extrinsèque) qu'ils envoient pour demander l'autorisation de blocage doit être signée. Un « extrinsèque signé » signifie que le compte qui a envoyé la transaction a signé la transaction avec sa propre clé privée. Ceci est conçu pour empêcher d'autres personnes d'envoyer des transactions en usurpant l'identité du compte, puisque personne d'autre que le propriétaire du compte ne peut générer une signature qui correspond à la clé publique du compte. Ainsi, lorsque la chaîne de relais reçoit une transaction signée, elle peut confirmer que la transaction a bien été envoyée par qui elle prétend être.
En outre, les transactions signées peuvent également contenir des informations supplémentaires, telles que nonce (utilisé pour empêcher les attaques par relecture) et tip (utilisé pour donner un pourboire au donneur de bloc). La chaîne de relais dispose déjà d'un mécanisme pour gérer ces informations, donc faire en sorte que les requêtes de blocage des parachains axées sur la demande utilisent des transactions signées leur permet de tirer directement parti de ces mécanismes existants sans avoir à développer de nouveaux mécanismes de sécurité.
Du point de vue de l'utilisateur, cela signifie que le prix total à payer se compose de trois parties : les frais de transaction traditionnels (qui servent à payer les ressources informatiques nécessaires au traitement de la transaction), un pourboire facultatif (qui sert à pour encourager les producteurs de blocs à prioriser leurs transactions), et le prix du cœur de souscription mentionné ci-dessus (c'est-à-dire le prix de la puissance du bloc).
Intégrer le mécanisme de commande dans le nœud collecteur
Le processus de création de bloc réel est exactement le même pour les validateurs (collators) que pour les parachains statiques. Les assembleurs sont des nœuds responsables de la collecte et de la création de blocs. Ils vérifient régulièrement l'état des parachains, en particulier les parachains dont ils sont responsables (identifiés par ParaId). S'ils constatent que la parachain correspondant à leur ParaId est sur le point d'atteindre le moment de créer un bloc, ils commenceront à générer un nouveau bloc. Après avoir généré le bloc, ils doivent générer une preuve (preuve de validité, appelée PoV), qui contient le contenu du bloc et les informations prouvant la validité du bloc. Ensuite, ils enverront cette preuve PoV au groupe de soutien assigné (Backing Group). Le groupe d'endossement est un groupe de nœuds chargés de vérifier et de confirmer la validité de ce bloc.
Bien que le processus de génération de blocs sur la parachain à la demande soit le même que celui sur la parachain statique, sur la parachain à la demande, nous devons introduire un nouveau mécanisme dans les assembleurs (Colllators), afin qu'ils puissent Lors de l'envoi de demandes de bloc opportunités de génération (c'est-à-dire les "commandes de base").
Il existe actuellement plusieurs stratégies possibles sur la façon de concevoir ce nouveau mécanisme (si vous êtes intéressé par ce problème, ou si vous avez une certaine connaissance de Cumulus, creuser ce problème sera un bon moyen de participer à ce projet, et d'aider sur- exigent que les parachains soient réalisés plus rapidement.
Cumulus est un framework de développement pour la construction de parachains sur les réseaux Polkadot et Kusama. Il a été développé par Parity Technologies, le principal développeur de Polkadot. Cumulus réduit la complexité pour les développeurs de construire des Parachains. Lorsque vous utilisez Cumulus pour créer une parachain, vous pouvez tirer parti de certaines logiques et fonctions partagées déjà implémentées dans Cumulus, telles que la communication avec la chaîne de relais, la vérification des blocs et le traitement de la finalité. Cela permet aux développeurs de se concentrer sur leur logique métier sans avoir à gérer ces problèmes de bas niveau.
Dans l'ensemble, l'objectif de Cumulus est de rendre la construction de parachains aussi simple que possible afin de promouvoir le développement de l'écologie Polkadot et Kusama.
Un autre rappel important est qu'il peut y avoir un risque de sécurité si l'assembleur fonctionne à partir d'un hot wallet (un portefeuille connecté au réseau). Par conséquent, nous fournirons un type de compte proxy dédié, qui n'a que l'autorité d'enchères principale sur la parachaîne à la demande, réduisant ainsi les risques de sécurité.
prise en charge asynchrone intégrée et plus de détails
Pour un public technique plus intéressé, le développement complet de la parachain à la demande est suivi ici.
Les sous-tâches peuvent être trouvées ici (en particulier pour l'intégration à venir du support asynchrone, certaines réflexions sont résumées dans ce commentaire (.
En bref, l'abstraction de base existante ne sera plus à 0 dimension, mais à 1 dimension. Cela peut signifier que le fonctionnement du système ou du modèle deviendra plus flexible ou complexe, permettant à ces « cœurs » ou à d'autres parties du système de connaître à l'avance ou de prédire les tâches ou les événements qui se produiront dans le futur. Il peut s'agir d'une optimisation ou d'une amélioration qui rend le système global plus apte à prévoir et à traiter l'activité future.
Dans Polkadot, un "noyau" est un nœud spécial responsable du traitement et de la vérification des transactions et d'autres activités sur les parachains, et "l'abstraction du noyau" fait généralement référence à une conception dans laquelle certains mécanismes internes complexes ou détails de mise en œuvre sont abstraits Caché sous une interface simple ou concept.
Mais assez de détails pour le moment. Nous sommes très enthousiasmés par les nouvelles possibilités qu'apporteront les parachaînes à la demande et nous avons hâte de les voir en direct !
Lien de référence du contenu :