J’avais trop longtemps fixé le même graphique de BTC, alors je suis retourné dans la documentation de Babylon et j’ai commencé à suivre la façon dont ses points de contrôle atteignent réellement Bitcoin.

Je m’attendais à une transaction unique et propre : Babylon finalise un epoch, écrit la preuve sur Bitcoin, et c’est terminé.

Pas tout à fait.

À la fin d’un epoch, les validateurs de Babylon produisent des signatures BLS agrégées dans un point de contrôle compact. Mais ce point de contrôle doit encore être encodé sur deux transactions Bitcoin et diffusé par un programme distinct appelé le « Vigilante submitter ».

Honnêtement, je n’ai cessé de faire des allers-retours entre la documentation et un explorateur de blocs, parce que je pensais que la deuxième transaction n’était qu’une sorte de sauvegarde optionnelle. Ce n’est pas le cas. Les deux éléments font partie de la mise à disposition des données du point de contrôle sur Bitcoin.

La configuration est sans permission, ce qui sonne rassurant : n’importe qui peut exécuter un submitter. Mais l’architecture propre à Babylon a encore besoin d’au moins un de ceux-ci en ligne et en état de fonctionner pour que les points de contrôle continuent d’avancer.

Ainsi, Bitcoin fournit l’horodatage durable, tandis que la charge opérationnelle repose hors chaîne : surveiller les epochs, construire les deux transactions, payer les frais et les diffuser de manière fiable.

L’avantage sécurité est peut-être réel, mais la dépendance n’a pas disparu. Elle s’est déplacée vers la disponibilité du submitter et l’inclusion sur Bitcoin.

Est-ce que cela continuera de paraître léger lorsque les frais du mainnet augmenteront et que de nombreuses chaînes attendront des points de contrôle transmis en temps voulu ?
#baby $BABY @BabylonLabs_io