Mesurez les transactions. Mesurez la proposition encodée. Vérifiez la limite d’époque. Répétez, car ces totaux n’étaient pas garantis identiques.
J’ai d’abord lu Babylon v4.3.1 comme un simple correctif comptable étroit. En regardant de plus près, je pense qu’il ferme un chemin de défaillance au niveau opérateur exactement au moment où les données de point de contrôle entrent dans une proposition de bloc.
Avant le correctif, le budget de reproécriture des points de contrôle de Babylon répartissait les transactions selon la longueur brute en octets, tandis que CometBFT validait la proposition encodée en protobuf, plus volumineuse. Un bloc pouvait réussir le premier calcul, échouer le second, puis faire planter le proposeur à la limite d’une époque.
v4.3.1 fait en sorte que PrepareProposal compte la même taille encodée que celle que CometBFT impose. Il ajoute aussi une dernière protection qui supprime les transactions non liées aux points de contrôle en fin de proposition tant que celle-ci n’est pas validée : on conserve le point de contrôle, tout en empêchant qu’un bloc trop grand soit renvoyé.
La chaîne corrigée a été testée à de vraies limites bbn-1 avec quatre validateurs, sur environ dix limites de points de contrôle dans des conditions d’inondation de transactions, sans crash du proposeur.
Pour un opérateur, cela élimine un décalage que le nœud ne devrait jamais avoir exporté comme risque opérationnel. Le constructeur de blocs dispose désormais d’une seule définition de « tient », et non d’une estimation avant encodage et d’une autre après soumission.
Le travail d’opérateur de Babylon est souvent discuté via les clés, la disponibilité et les responsabilités BLS. Rien de tout cela n’a d’importance si l’insertion des points de contrôle peut arrêter la production de blocs.
Cette version fait en sorte que cette limite se comporte comme une partie du protocole, et non comme un pari récurrent sur la capacité pour le proposeur.
@BabylonLabs_io $BABY #baby
J’ai d’abord lu Babylon v4.3.1 comme un simple correctif comptable étroit. En regardant de plus près, je pense qu’il ferme un chemin de défaillance au niveau opérateur exactement au moment où les données de point de contrôle entrent dans une proposition de bloc.
Avant le correctif, le budget de reproécriture des points de contrôle de Babylon répartissait les transactions selon la longueur brute en octets, tandis que CometBFT validait la proposition encodée en protobuf, plus volumineuse. Un bloc pouvait réussir le premier calcul, échouer le second, puis faire planter le proposeur à la limite d’une époque.
v4.3.1 fait en sorte que PrepareProposal compte la même taille encodée que celle que CometBFT impose. Il ajoute aussi une dernière protection qui supprime les transactions non liées aux points de contrôle en fin de proposition tant que celle-ci n’est pas validée : on conserve le point de contrôle, tout en empêchant qu’un bloc trop grand soit renvoyé.
La chaîne corrigée a été testée à de vraies limites bbn-1 avec quatre validateurs, sur environ dix limites de points de contrôle dans des conditions d’inondation de transactions, sans crash du proposeur.
Pour un opérateur, cela élimine un décalage que le nœud ne devrait jamais avoir exporté comme risque opérationnel. Le constructeur de blocs dispose désormais d’une seule définition de « tient », et non d’une estimation avant encodage et d’une autre après soumission.
Le travail d’opérateur de Babylon est souvent discuté via les clés, la disponibilité et les responsabilités BLS. Rien de tout cela n’a d’importance si l’insertion des points de contrôle peut arrêter la production de blocs.
Cette version fait en sorte que cette limite se comporte comme une partie du protocole, et non comme un pari récurrent sur la capacité pour le proposeur.
@BabylonLabs_io $BABY #baby