Interprétation du nouveau Livre blanc de Sei : Quelles innovations technologiques sont introduites par la mise à niveau Giga ?

Rédigé par : Pavel Paramonov, fondateur de Hazeflow

Compilation : PANews

Sei a publié un nouveau livre blanc, dans lequel il présente la dernière mise à niveau Giga. La plupart des lecteurs trouvent que les 17 pages de contenu technique approfondi sont difficiles à lire. Par conséquent, cet article expliquera le contenu de cette mise à jour et comment améliorer les performances de la blockchain à différents niveaux.

Génération de blocs par exécution asynchrone

La principale idée et la base de Giga sont les suivantes :

« Si notre liste de transactions est ordonnée 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 parviendront au même état final. »

Dans ce cas, le résultat dépend uniquement de l'état initial et de l'ordre des transactions. Cela signifie que le consensus n'a besoin de s'accorder que sur l'ordre des transactions dans le bloc, chaque nœud pouvant calculer l'état final de manière indépendante.

Dans ce modèle, la consensus est séparé de l'exécution, permettant l'exécution asynchrone des blocs.

Une fois que le bloc est finalisé, les nœuds le traiteront et soumettront son état dans les blocs suivants.

Puis le bloc est validé par consensus d'état pour s'assurer que tous les nœuds ont calculé le bon état final.

Un détail important ici est que l'exécution et le consensus (la génération) se déroulent en parallèle. Les nœuds reçoivent d'autres blocs tout en exécutant le calcul d'un bloc.

Ainsi, les blocs sont en réalité exécutés dans un ordre total (et non en parallèle), tandis que le processus de génération des blocs se produit effectivement en parallèle avec le consensus. Cependant, pour un bloc donné, ces processus sont complètement asynchrones.

Il est évident qu'il semble impossible d'atteindre un consensus et d'exécuter le même bloc en même temps. Par conséquent, lors de l'exécution du bloc n, le nœud recevra le bloc n+1 pour la prochaine étape.

Si un désaccord de consensus se produit (par exemple, si un tiers des nœuds du réseau agissent de manière malveillante), la chaîne sera suspendue, ce qui est similaire aux protocoles BFT standard.

Les transactions échouées lors de l'exécution dans un bloc ne rendent pas ce bloc invalide, elles restent simplement dans un état d'échec, car la génération et l'exécution des blocs sont séparées, et l'état final du bloc courant sera soumis dans les blocs suivants.

Comment le modèle de plusieurs proposeurs est-il mis en œuvre et qu'est-ce qu'Autobahn ?

Le protocole de consensus lui-même est appelé « Autobahn » (tout comme l'autoroute allemande sans limite de vitesse). Autobahn sépare la disponibilité des données et le tri des transactions, soutenu par un modèle intéressant.

Tout comme les voies d'une autoroute, il existe plusieurs voies, chaque nœud ayant son propre canal. Les nœuds utilisent ces canaux pour proposer des suggestions concernant le tri des transactions. Une proposition est simplement un ensemble ordonné de transactions.

Autobahn effectue parfois l'opération « tipcut », c'est-à-dire qu'il agrège plusieurs propositions pour finaliser l'ordre des transactions.

Comme mentionné précédemment, chaque validateurs a son propre canal pour proposer des lots de transactions.

Lorsqu'un nœud reçoit une proposition valide, il envoie un vote pour confirmer que la proposition a été reçue.

Après la collecte des propositions et le vote, une preuve d'utilisabilité (PoA) sera créée, garantissant que les données ont été reçues par au moins un nœud honnête dans le réseau.

Le temps de survenue du Tipcut est exprimé en millisecondes, et les multiples propositions provenant d'Autobahn seront finalement « cut. ».

Le proposeur a l'incitation à attendre la publication d'un bloc et, si possible, à publier un seul bloc, mais la limite de temps d'exécution pour chaque bloc (similaire à la limite de Gas) modifie légèrement cette dynamique.

Une proposition sur un canal correspond généralement à un bloc, ce qui signifie que lorsque Tipcut se produit, plusieurs blocs sont coupés simultanément.

Par la suite, le leader de ce slot envoie le Tipcut à d'autres nœuds pour finaliser le tri. Les nœuds, en votant effectivement sur un seul Tipcut, se préparent déjà pour le prochain Tipcut.

Les nœuds manquants dans le lot peuvent obtenir des données de manière asynchrone auprès des validateurs listés dans le PoA : c'est la raison fondamentale pour laquelle la disponibilité des données est nécessaire.

Dans des conditions de synchronisation, si le leader est correct, Autobahn terminera la confirmation de la proposition en deux tours de communication. Si le leader échoue, ce mécanisme élira un nouveau leader pour maintenir le processus.

La prochaine proposition de tip-cut peut en réalité commencer dès la phase de soumission du tip-cut actuel, réduisant ainsi le délai, car l'exécution se fait en parallèle avec la génération.

En réalité, l'ensemble du modèle est un modèle multi-proposition, où de nombreux nœuds peuvent proposer simultanément des propositions de tri pour leurs blocs. Chaque validateurs propose son propre bloc et reçoit la preuve de possession de ces blocs (PoA) du réseau, ce qui contribue à améliorer le débit et l'efficacité globale du réseau.

Exécution parallèle et ses cas d'application

Comme mentionné précédemment, le processus d'exécution des blocs et le consensus se produisent en parallèle, bien que le bloc lui-même soit en réalité exécuté séquentiellement. Vous vous demandez peut-être si cela constitue une véritable exécution parallèle.

La réponse est à la fois affirmative et négative.

Bien que les blocs soient exécutés dans l'ordre, les transactions à l'intérieur d'un bloc peuvent en effet être exécutées en parallèle. Si les transactions ne modifient pas (n'écrivent pas) le même état et qu'un résultat de transaction n'affecte pas une autre transaction, alors elles peuvent être exécutées en parallèle.

En résumé, leurs chemins d'exécution ne devraient pas dépendre les uns des autres. Giga n'a pas de pool de mémoire, les transactions sont immédiatement incluses par les nœuds.

Giga suppose qu'il n'y a pas de conflits entre la plupart des transactions et traite ces transactions simultanément sur plusieurs cœurs de processeur.

Les modifications de chaque transaction sont temporairement stockées dans un tampon privé et ne sont pas immédiatement appliquées à la blockchain.

Après le traitement, le système vérifiera si la transaction entre en conflit avec des transactions précédentes.

En cas de conflit, la transaction sera retravaillée. S'il n'y a pas de conflit, ses modifications seront appliquées à la blockchain et finalisées.

Il peut également y avoir des situations de conflits fréquents, dans ce cas, le système passera à un traitement d'une transaction à la fois pour garantir que la transaction puisse progresser.

En termes simples, l'exécution parallèle attribue des transactions à plusieurs cœurs, permettant aux transactions sans conflit de s'exécuter simultanément.

Problèmes de stockage et optimisation

En raison du volume élevé des transactions, les données doivent être à la fois sécurisées et faciles d'accès, c'est pourquoi leur mode de stockage doit être légèrement différent de celui du stockage traditionnel sur blockchain. Giga stocke les données au format clé-valeur (key-value) simple, qui est une structure relativement plate, aidant à réduire le nombre de mises à jour ou de vérifications nécessaires lors des modifications de données.

De plus, Giga utilise une approche de stockage hiérarchique : les données récentes sont conservées sur SSD (rapides), tandis que les données moins utilisées sont transférées vers un système de stockage plus lent et plus rentable.

Si un nœud échoue, il peut rejouer 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.

Ce système de stockage utilise un accumulateur cryptographique (Cryptographic Accumulator) qui permet de prouver l'exactitude des données sans effectuer de calculs lourds. L'accumulateur est mis à jour par traitement par lots, permettant aux validateurs et aux nœuds légers de parvenir rapidement à un consensus sur l'état actuel de la blockchain.

Que signifie devenir une blockchain EVM L1 avec plusieurs propositions ?

L'infrastructure L1 peut subir de nombreuses améliorations, et différents L1 font face à divers défis techniques, allant de problèmes économiques tels que MEV à des problèmes techniques tels que la gestion des états.

En tant que première chaîne L1 à prendre en charge plusieurs propositions, cela représente un défi, surtout pour les L1 EVM, car la conception de l'EVM n'était pas initialement destinée à soutenir un système à plusieurs propositions.

Cependant, Sei essaie différentes approches pour conserver l'EVM ainsi que de nombreux outils que les développeurs ont l'habitude d'utiliser.

L'exécution parallèle des transactions, l'atteinte du consensus pendant le processus d'exécution et l'opération parallèle de plusieurs proposeurs contribuent à améliorer les performances, avec un débit d'exécution pouvant augmenter d'environ 50 fois. Cependant, ces améliorations peuvent également être confrontées à certains des risques mentionnés ci-dessus.

C'est la deuxième mise à jour majeure de Sei, après que Sei est passé de la chaîne Cosmos à la chaîne EVM, Sei a maintenant lancé un client d'exécution optimisé pour la vitesse.

Le développement à venir ainsi que les effets ultérieurs de ces mesures d'optimisation méritent d'être suivis de près.