SEI introduit des mécanismes tels que l’exécution asynchrone, le consensus multi-proposants, le parallélisme des transactions et l’optimisation du stockage dans la mise à niveau Giga. Cet article est écrit par Pavel Paramonov, fondateur de Hazeflow, et est compilé, compilé et contribué par Felix, PANews. (Synopsis : $SEI 70% en un seul mois !) Lancement de la proposition SIP-3 : transition vers l’EVM pur, visant 100 000 transactions par seconde) (Contexte ajouté : MetaMask soutiendra le portefeuille MetaMask du réseau Solana « première chaîne non EVM » hors de la zone de confort d’Ethereum en mai) Sei a publié un nouveau livre blanc qui présente la dernière mise à niveau Giga. La plupart des lecteurs trouvent difficile la lecture de 17 pages de contenu technique approfondi. Par conséquent, cet article expliquera en quoi consiste cette mise à jour et comment améliorer les performances de la blockchain à différents niveaux. 1. Les principales idées et fondements de la génération de blocs giga pour l’exécution asynchrone sont les suivants : « Si notre liste de transactions est en ordre et que l’état initial de la blockchain est cohérent, et que tous les nœuds honnêtes traitent ces transactions dans le même ordre, alors les nœuds atteindront le même état final. » Dans ce cas, le résultat ne dépend que de l’état initial et de l’ordre des transactions. Cela signifie que le consensus n’a besoin de se mettre d’accord que sur l’ordre des transactions au sein du bloc, et que chaque nœud peut calculer l’état final indépendamment. Dans ce modèle, le consensus est séparé de l’exécution, ce qui permet aux blocs de s’exécuter de manière asynchrone. Une fois le bloc finalisé, le nœud le traite et commet son état dans les blocs suivants. Le bloc est ensuite validé par consensus d’état pour s’assurer que tous les nœuds ont calculé l’état final correct. Un détail important ici est que l’exécution et le consensus (génération) se déroulent en parallèle. Lorsqu’un nœud effectue le calcul d’un bloc, il reçoit également d’autres blocs. En conséquence, les blocs sont en fait exécutés dans l’ordre total (plutôt qu’en parallèle), tandis que le processus de génération de blocs lui-même se déroule en parallèle avec le consensus. Cependant, pour un bloc donné, ces processus sont complètement asynchrones. De toute évidence, le consensus et l’exécution du même bloc en même temps semblent impossibles. Par conséquent, lorsque le bloc n est exécuté, le nœud reçoit le bloc n+1 pour l’étape suivante. Si le consensus est faussé (par exemple, un tiers des nœuds du réseau agissent de manière malveillante), la chaîne est suspendue, comme c’est le cas pour le protocole BFT standard. L’exécution d’une transaction ayant échoué au sein d’un bloc n’invalide pas le bloc, mais reste simplement dans un état d’échec, car la génération et l’exécution du bloc sont distinctes et l’état final du bloc actuel est validé dans les blocs suivants. 2 Comment le modèle multi-proposants est-il mis en œuvre et qu’est-ce qu’Autobahn ? Le protocole de consensus lui-même s’appelle « Autobahn » (comme l’autoroute allemande sans limite de vitesse). Autobahn sépare la disponibilité des données de la commande de transactions, et il y a un modèle intéressant derrière cela. Comme les voies de n’importe quelle autoroute, il y a plusieurs voies, chaque nœud ayant son propre passage. Les nœuds utilisent ces canaux pour faire des propositions concernant l’ordre des transactions. Une proposition n’est qu’un ensemble ordonné de transactions. Autobahn effectue parfois une opération de « tipcut », où plusieurs propositions sont agrégées pour finaliser l’ordre des transactions. Comme mentionné précédemment, chaque validateur dispose de son propre canal pour proposer un grand nombre de transactions. Lorsqu’un nœud reçoit une proposition valide, il envoie un vote pour confirmer que la proposition a été reçue. Une fois qu’une proposition est recueillie pour un vote, une preuve de disponibilité (PoA) est formée, garantissant que les données ont été reçues par au moins un nœud honnête du réseau. Les coupures de pourboires se produisent en quelques millisecondes, et finalement plusieurs propositions d’Autobahn sont « coupées ». Les proposants sont incités à attendre que les blocs soient libérés et à libérer des blocs individuels lorsque cela est possible, mais la limite de temps d’exécution pour chaque bloc (similaire à la limite de gaz) modifie légèrement cette dynamique. Une proposition sur un canal est généralement équivalente à un bloc, ce qui signifie que lorsqu’une coupe de pointe se produit, plusieurs blocs sont coupés en même temps. Par la suite, le leader de la fente passe la coupe de pointe à d’autres nœuds pour terminer le tri. Le nœud vote en fait sur une seule coupe de pointe en même temps qu’il prépare déjà la prochaine coupe de pointe. Les nœuds qui manquent des lots peuvent être obtenus de manière asynchrone à partir des validateurs répertoriés dans le PoA : c’est l’essence même du besoin de disponibilité des données. Dans des conditions synchrones, si le leader est correct, Autobahn complète la confirmation de la proposition en deux tours de communication. Si un leader échoue, le mécanisme élit un nouveau leader pour maintenir le programme en ordre. La proposition de coupe de pourboire suivante peut en fait démarrer pendant la phase de validation de la coupe de pourboire actuelle, ce qui réduit la latence car l’exécution se produit en parallèle avec la construction. En fait, l’ensemble du modèle est un modèle multi-proposants où de nombreux nœuds peuvent faire des propositions pour leur commande de blocs en même temps. Chaque validateur propose ses propres blocs et reçoit la preuve que le réseau est propriétaire de ces blocs (PoA), ce qui permet d’améliorer le débit et l’efficacité globale du réseau. 3 L’exécution parallèle et son application Comme mentionné précédemment, le processus d’exécution des blocs se déroule en parallèle avec le consensus, bien que les blocs eux-mêmes soient en fait exécutés séquentiellement. Vous vous demandez peut-être s’il s’agit d’une véritable exécution parallèle. La réponse est à la fois oui et non. Bien que les blocs soient exécutés de manière séquentielle, les transactions à l’intérieur des blocs peuvent en effet être exécutées en parallèle. Si les transactions ne modifient pas (écrivent) le même état et que le résultat d’une transaction n’en affecte pas une autre, elles peuvent être exécutées en parallèle. En bref, leurs chemins d’exécution ne doivent pas dépendre les uns des autres. Giga n’a pas de mempool et les transactions sont immédiatement incluses par le nœud. Giga suppose qu’il n’y a pas de conflits entre la plupart des transactions et les traite simultanément sur plusieurs cœurs de processeur. Les modifications apportées à chaque transaction sont temporairement stockées dans un tampon privé et ne sont pas immédiatement appliquées à la blockchain. Une fois le traitement terminé, le système vérifie si la transaction entre en conflit avec les transactions précédentes. En cas de conflit, la transaction sera retraitée. S’il n’y a pas de conflits, ses modifications sont appliquées à la blockchain et finalisées. Il peut également y avoir des collisions à haute fréquence, auquel cas le système passe au traitement d’une transaction à la fois pour s’assurer que la transaction peut aller de l’avant. En termes simples, l’exécution parallèle répartit les transactions sur plusieurs cœurs, ce qui permet aux transactions qui ne sont pas en conflit de s’exécuter simultanément. 4. Problèmes de stockage et optimisation En raison du volume élevé de transactions, les données doivent être à la fois sécurisées et facilement accessibles, elles doivent donc être stockées d’une manière légèrement différente du stockage blockchain traditionnel. Gigas stocke les données dans un format clé-valeur simple, une structure relativement plate qui permet de réduire le besoin de plusieurs mises à jour ou vérifications lorsque les données changent. De plus, Giga utilise un stockage hiérarchisé : les données récentes sont conservées sur des SSD (haut débit), tandis que les données moins utilisées sont migrées vers des systèmes de stockage plus lents et plus rentables. Si un nœud se bloque, il peut lire les journaux pour restaurer l’état correct et appliquer les mises à jour à RocksDB, une base de données spécialisée, pour organiser les données. Le système de stockage utilise un accumulateur cryptographique qui prouve l’exactitude des données sans calculs lourds. Les accumulateurs sont mis à jour par lots, ce qui permet aux validateurs et aux nœuds légers de se mettre rapidement d’accord sur l’état actuel de la blockchain. 5. Devenir un bloc EVM L1 multi-proposants...
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Interprétation du nouveau livre blanc de Sei : Quelles innovations technologiques sont introduites par la mise à niveau Giga ?
SEI introduit des mécanismes tels que l’exécution asynchrone, le consensus multi-proposants, le parallélisme des transactions et l’optimisation du stockage dans la mise à niveau Giga. Cet article est écrit par Pavel Paramonov, fondateur de Hazeflow, et est compilé, compilé et contribué par Felix, PANews. (Synopsis : $SEI 70% en un seul mois !) Lancement de la proposition SIP-3 : transition vers l’EVM pur, visant 100 000 transactions par seconde) (Contexte ajouté : MetaMask soutiendra le portefeuille MetaMask du réseau Solana « première chaîne non EVM » hors de la zone de confort d’Ethereum en mai) Sei a publié un nouveau livre blanc qui présente la dernière mise à niveau Giga. La plupart des lecteurs trouvent difficile la lecture de 17 pages de contenu technique approfondi. Par conséquent, cet article expliquera en quoi consiste cette mise à jour et comment améliorer les performances de la blockchain à différents niveaux. 1. Les principales idées et fondements de la génération de blocs giga pour l’exécution asynchrone sont les suivants : « Si notre liste de transactions est en ordre et que l’état initial de la blockchain est cohérent, et que tous les nœuds honnêtes traitent ces transactions dans le même ordre, alors les nœuds atteindront le même état final. » Dans ce cas, le résultat ne dépend que de l’état initial et de l’ordre des transactions. Cela signifie que le consensus n’a besoin de se mettre d’accord que sur l’ordre des transactions au sein du bloc, et que chaque nœud peut calculer l’état final indépendamment. Dans ce modèle, le consensus est séparé de l’exécution, ce qui permet aux blocs de s’exécuter de manière asynchrone. Une fois le bloc finalisé, le nœud le traite et commet son état dans les blocs suivants. Le bloc est ensuite validé par consensus d’état pour s’assurer que tous les nœuds ont calculé l’état final correct. Un détail important ici est que l’exécution et le consensus (génération) se déroulent en parallèle. Lorsqu’un nœud effectue le calcul d’un bloc, il reçoit également d’autres blocs. En conséquence, les blocs sont en fait exécutés dans l’ordre total (plutôt qu’en parallèle), tandis que le processus de génération de blocs lui-même se déroule en parallèle avec le consensus. Cependant, pour un bloc donné, ces processus sont complètement asynchrones. De toute évidence, le consensus et l’exécution du même bloc en même temps semblent impossibles. Par conséquent, lorsque le bloc n est exécuté, le nœud reçoit le bloc n+1 pour l’étape suivante. Si le consensus est faussé (par exemple, un tiers des nœuds du réseau agissent de manière malveillante), la chaîne est suspendue, comme c’est le cas pour le protocole BFT standard. L’exécution d’une transaction ayant échoué au sein d’un bloc n’invalide pas le bloc, mais reste simplement dans un état d’échec, car la génération et l’exécution du bloc sont distinctes et l’état final du bloc actuel est validé dans les blocs suivants. 2 Comment le modèle multi-proposants est-il mis en œuvre et qu’est-ce qu’Autobahn ? Le protocole de consensus lui-même s’appelle « Autobahn » (comme l’autoroute allemande sans limite de vitesse). Autobahn sépare la disponibilité des données de la commande de transactions, et il y a un modèle intéressant derrière cela. Comme les voies de n’importe quelle autoroute, il y a plusieurs voies, chaque nœud ayant son propre passage. Les nœuds utilisent ces canaux pour faire des propositions concernant l’ordre des transactions. Une proposition n’est qu’un ensemble ordonné de transactions. Autobahn effectue parfois une opération de « tipcut », où plusieurs propositions sont agrégées pour finaliser l’ordre des transactions. Comme mentionné précédemment, chaque validateur dispose de son propre canal pour proposer un grand nombre de transactions. Lorsqu’un nœud reçoit une proposition valide, il envoie un vote pour confirmer que la proposition a été reçue. Une fois qu’une proposition est recueillie pour un vote, une preuve de disponibilité (PoA) est formée, garantissant que les données ont été reçues par au moins un nœud honnête du réseau. Les coupures de pourboires se produisent en quelques millisecondes, et finalement plusieurs propositions d’Autobahn sont « coupées ». Les proposants sont incités à attendre que les blocs soient libérés et à libérer des blocs individuels lorsque cela est possible, mais la limite de temps d’exécution pour chaque bloc (similaire à la limite de gaz) modifie légèrement cette dynamique. Une proposition sur un canal est généralement équivalente à un bloc, ce qui signifie que lorsqu’une coupe de pointe se produit, plusieurs blocs sont coupés en même temps. Par la suite, le leader de la fente passe la coupe de pointe à d’autres nœuds pour terminer le tri. Le nœud vote en fait sur une seule coupe de pointe en même temps qu’il prépare déjà la prochaine coupe de pointe. Les nœuds qui manquent des lots peuvent être obtenus de manière asynchrone à partir des validateurs répertoriés dans le PoA : c’est l’essence même du besoin de disponibilité des données. Dans des conditions synchrones, si le leader est correct, Autobahn complète la confirmation de la proposition en deux tours de communication. Si un leader échoue, le mécanisme élit un nouveau leader pour maintenir le programme en ordre. La proposition de coupe de pourboire suivante peut en fait démarrer pendant la phase de validation de la coupe de pourboire actuelle, ce qui réduit la latence car l’exécution se produit en parallèle avec la construction. En fait, l’ensemble du modèle est un modèle multi-proposants où de nombreux nœuds peuvent faire des propositions pour leur commande de blocs en même temps. Chaque validateur propose ses propres blocs et reçoit la preuve que le réseau est propriétaire de ces blocs (PoA), ce qui permet d’améliorer le débit et l’efficacité globale du réseau. 3 L’exécution parallèle et son application Comme mentionné précédemment, le processus d’exécution des blocs se déroule en parallèle avec le consensus, bien que les blocs eux-mêmes soient en fait exécutés séquentiellement. Vous vous demandez peut-être s’il s’agit d’une véritable exécution parallèle. La réponse est à la fois oui et non. Bien que les blocs soient exécutés de manière séquentielle, les transactions à l’intérieur des blocs peuvent en effet être exécutées en parallèle. Si les transactions ne modifient pas (écrivent) le même état et que le résultat d’une transaction n’en affecte pas une autre, elles peuvent être exécutées en parallèle. En bref, leurs chemins d’exécution ne doivent pas dépendre les uns des autres. Giga n’a pas de mempool et les transactions sont immédiatement incluses par le nœud. Giga suppose qu’il n’y a pas de conflits entre la plupart des transactions et les traite simultanément sur plusieurs cœurs de processeur. Les modifications apportées à chaque transaction sont temporairement stockées dans un tampon privé et ne sont pas immédiatement appliquées à la blockchain. Une fois le traitement terminé, le système vérifie si la transaction entre en conflit avec les transactions précédentes. En cas de conflit, la transaction sera retraitée. S’il n’y a pas de conflits, ses modifications sont appliquées à la blockchain et finalisées. Il peut également y avoir des collisions à haute fréquence, auquel cas le système passe au traitement d’une transaction à la fois pour s’assurer que la transaction peut aller de l’avant. En termes simples, l’exécution parallèle répartit les transactions sur plusieurs cœurs, ce qui permet aux transactions qui ne sont pas en conflit de s’exécuter simultanément. 4. Problèmes de stockage et optimisation En raison du volume élevé de transactions, les données doivent être à la fois sécurisées et facilement accessibles, elles doivent donc être stockées d’une manière légèrement différente du stockage blockchain traditionnel. Gigas stocke les données dans un format clé-valeur simple, une structure relativement plate qui permet de réduire le besoin de plusieurs mises à jour ou vérifications lorsque les données changent. De plus, Giga utilise un stockage hiérarchisé : les données récentes sont conservées sur des SSD (haut débit), tandis que les données moins utilisées sont migrées vers des systèmes de stockage plus lents et plus rentables. Si un nœud se bloque, il peut lire les journaux pour restaurer l’état correct et appliquer les mises à jour à RocksDB, une base de données spécialisée, pour organiser les données. Le système de stockage utilise un accumulateur cryptographique qui prouve l’exactitude des données sans calculs lourds. Les accumulateurs sont mis à jour par lots, ce qui permet aux validateurs et aux nœuds légers de se mettre rapidement d’accord sur l’état actuel de la blockchain. 5. Devenir un bloc EVM L1 multi-proposants...