Je suis retourné aux spécifications d’architecture technique de @BabylonLabs_io aujourd’hui pour examiner comment les sorties d’un vault s’exécutent réellement sur Bitcoin L1 sans covenants natifs.
Cela vaut le coup de comprendre la mécanique ici. Bitcoin n’a pas encore de covenants natifs (OP_COVENANT). Donc comment un Trustless Bitcoin Vault impose-t-il des timelocks et du slashing sans une machine virtuelle de smart contract ?
Il s’appuie sur des arbres de transactions Taproot pré-signées construits au moment exact où vous verrouillez votre BTC.
Mon hypothèse initiale était qu’une fois l’expiration du timelock atteinte ou qu’une condition de slashing se déclenche, la transaction se dépose simplement et sans friction sur Bitcoin L1.
Pas automatiquement.
Comme ces transactions sont pré-signées à l’avance, leurs frais de mineur (sat/vB) sont calibrés selon les environnements de frais au moment de la création du vault.
Si le mempool de Bitcoin L1 subit un pic massif de congestion pendant un krach boursier — passant de 15 sat/vB à 250+ sat/vB — une transaction de déliaison (unbonding) ou de slashing pré-signée peut rester bloquée dans le mempool à moins que des mécanismes d’ajustement des frais comme CPFP (Child-Pays-For-Parent) ou RBF soient activement invoqués.
La cryptographie derrière EOTS et les chemins de dépense du script Taproot est entièrement trustless et sans faille.
Mais l’exécution sur Bitcoin L1 dépend toujours, en aval, de l’économie des frais du mempool.
Si les frais L1 s’envolent pendant un événement de liquidation du marché, la garantie cryptographique compte-t-elle si la transaction est mise en file derrière des milliers d’ordinals et de transferts ?
C’est toute la nuance entre validité cryptographique et priorité dans le mempool.
Lors de l’évaluation de l’architecture du $BABY vault, quel est selon vous le plus gros goulot d’étranglement pendant une forte congestion sur L1 ? #baby $BABY
Cela vaut le coup de comprendre la mécanique ici. Bitcoin n’a pas encore de covenants natifs (OP_COVENANT). Donc comment un Trustless Bitcoin Vault impose-t-il des timelocks et du slashing sans une machine virtuelle de smart contract ?
Il s’appuie sur des arbres de transactions Taproot pré-signées construits au moment exact où vous verrouillez votre BTC.
Mon hypothèse initiale était qu’une fois l’expiration du timelock atteinte ou qu’une condition de slashing se déclenche, la transaction se dépose simplement et sans friction sur Bitcoin L1.
Pas automatiquement.
Comme ces transactions sont pré-signées à l’avance, leurs frais de mineur (sat/vB) sont calibrés selon les environnements de frais au moment de la création du vault.
Si le mempool de Bitcoin L1 subit un pic massif de congestion pendant un krach boursier — passant de 15 sat/vB à 250+ sat/vB — une transaction de déliaison (unbonding) ou de slashing pré-signée peut rester bloquée dans le mempool à moins que des mécanismes d’ajustement des frais comme CPFP (Child-Pays-For-Parent) ou RBF soient activement invoqués.
La cryptographie derrière EOTS et les chemins de dépense du script Taproot est entièrement trustless et sans faille.
Mais l’exécution sur Bitcoin L1 dépend toujours, en aval, de l’économie des frais du mempool.
Si les frais L1 s’envolent pendant un événement de liquidation du marché, la garantie cryptographique compte-t-elle si la transaction est mise en file derrière des milliers d’ordinals et de transferts ?
C’est toute la nuance entre validité cryptographique et priorité dans le mempool.
Lors de l’évaluation de l’architecture du $BABY vault, quel est selon vous le plus gros goulot d’étranglement pendant une forte congestion sur L1 ? #baby $BABY
