#baby $BABY Aujourd’hui, j’ai passé quelque temps à lire comment Babylon gère le pointage Bitcoin (checkpointing), et un détail a vraiment retenu mon attention.
Au début, je me demandais pourquoi Babylon utilise deux transactions Bitcoin pour un seul checkpoint. Après avoir lu la documentation, cela a du sens. Un OP_RETURN Bitcoin standard ne peut contenir que jusqu’à 80 octets, tandis qu’un checkpoint Babylon inclut plusieurs éléments d’information comme l’ID d’époque, le hachage du checkpoint, la bitmap de signature et la signature BLS agrégée. Le checkpoint complet est tout simplement trop volumineux pour tenir dans un seul OP_RETURN.
Plutôt que de modifier les règles de Bitcoin, Babylon fonctionne dans le cadre de celles-ci en répartissant le checkpoint sur deux transactions. J’aime cette approche parce qu’elle respecte le design existant de Bitcoin tout en permettant tout de même un checkpointing sécurisé.
Apprendre de petits détails d’implémentation comme celui-ci me donne encore plus d’appréciation pour l’ingénierie derrière l’infrastructure blockchain.
@BabylonLabs_io $BABY #baby
Au début, je me demandais pourquoi Babylon utilise deux transactions Bitcoin pour un seul checkpoint. Après avoir lu la documentation, cela a du sens. Un OP_RETURN Bitcoin standard ne peut contenir que jusqu’à 80 octets, tandis qu’un checkpoint Babylon inclut plusieurs éléments d’information comme l’ID d’époque, le hachage du checkpoint, la bitmap de signature et la signature BLS agrégée. Le checkpoint complet est tout simplement trop volumineux pour tenir dans un seul OP_RETURN.
Plutôt que de modifier les règles de Bitcoin, Babylon fonctionne dans le cadre de celles-ci en répartissant le checkpoint sur deux transactions. J’aime cette approche parce qu’elle respecte le design existant de Bitcoin tout en permettant tout de même un checkpointing sécurisé.
Apprendre de petits détails d’implémentation comme celui-ci me donne encore plus d’appréciation pour l’ingénierie derrière l’infrastructure blockchain.
@BabylonLabs_io $BABY #baby