Un explorateur de blocs voit un rachat : pourquoi $BTC ne peut‑il toujours pas être libéré ?
La transaction Ethereum a été diffusée, incluse dans un bloc, un receipt a été généré, et l’on peut même y retrouver un événement de redemption. Cela ne prouve qu’une chose : qu’un bloc d’exécution contient bien cette trace. Pour le TBV du testnet public actuel, cela ne suffit pas à libérer du BTC, car il faut encore prouver que ce bloc fait partie de l’historique finalement adopté par Ethereum.
Le fait que l’utilisateur ait remboursé sa dette et withdraw le Vault, ou que le processus de liquidation transfère le Vault à un rôle de redemption en aval, déclenche tous deux un événement de redemption. Le prover hors chaîne (SP1) construit la preuve dans un ordre fixe : d’abord, la finalité Beacon confirme que le bloc beacon a été finalisé par la couche de consensus ; ensuite, la finalité de l’Execution relie ce bloc beacon finalisé au bloc d’exécution qui contient la transaction de redemption ; enfin, l’inclusion du receipt confirme que le log redemption cible existe bien dans le receipt de transaction de ce bloc. Groth16 compresse et agrège uniquement les trois couches de preuves en une preuve compacte (proof), mais ne confère pas une finalité au bloc.
Cet empilement m’a fait changer d’avis : je ne considère plus qu’« un navigateur a déjà vu la transaction » suffise pour établir le fait transchain du rachat. Je vérifierai plutôt deux choses qui doivent être prouvées simultanément : l’événement est bien inclus, et le bloc d’exécution qui le porte a aussi été reconnu par la chaîne Beacon finalisée. La première répond à « qu’est‑ce qui s’est passé », la seconde à « est‑ce que cela fait désormais partie de l’état final d’Ethereum ». En manquant la seconde couche, un Payout Bitcoin pourrait s’appuyer sur un historique externe qui n’est pas encore stabilisé.
Une fois les preuves de finalité et d’inclusion établies, le claimer ne transmet la proof compressée qu’aux côtés Bitcoin pour le Claim, l’Assert et la fenêtre de challenge. La finalité Ethereum confirme à quelle tranche d’historique final l’événement appartient côté externe ; la période de contestation Bitcoin vérifie si la proof soumise côté Bitcoin peut être confirmée. Les deux ne portent pas sur la même attente, ne se substituent pas l’une à l’autre, et tant que la proof n’a pas été valablement réfutée, le Payout peut entrer en exécution.
Il faut aussi garder les limites en tête : la preuve qu’un événement de redemption est finalisé prouve que ce log a atteint l’état final d’Ethereum, mais cela ne signifie pas nécessairement que le contrat en amont, l’oracle ou la décision de liquidation soit économiquement correcte. Si le consensus Ethereum connaît un défaut profond, la vérification peut aussi s’arrêter ou produire une erreur. @BabylonLabs_io fixe le seuil sur « un événement dans l’historique finalisé », et non sur « un événement visible par un navigateur » : c’est précisément parce qu’après la libération de Bitcoin, elle ne sera pas automatiquement annulée par les changements ultérieurs de la chaîne externe. $ETH
$BABY
#baby
La transaction Ethereum a été diffusée, incluse dans un bloc, un receipt a été généré, et l’on peut même y retrouver un événement de redemption. Cela ne prouve qu’une chose : qu’un bloc d’exécution contient bien cette trace. Pour le TBV du testnet public actuel, cela ne suffit pas à libérer du BTC, car il faut encore prouver que ce bloc fait partie de l’historique finalement adopté par Ethereum.
Le fait que l’utilisateur ait remboursé sa dette et withdraw le Vault, ou que le processus de liquidation transfère le Vault à un rôle de redemption en aval, déclenche tous deux un événement de redemption. Le prover hors chaîne (SP1) construit la preuve dans un ordre fixe : d’abord, la finalité Beacon confirme que le bloc beacon a été finalisé par la couche de consensus ; ensuite, la finalité de l’Execution relie ce bloc beacon finalisé au bloc d’exécution qui contient la transaction de redemption ; enfin, l’inclusion du receipt confirme que le log redemption cible existe bien dans le receipt de transaction de ce bloc. Groth16 compresse et agrège uniquement les trois couches de preuves en une preuve compacte (proof), mais ne confère pas une finalité au bloc.
Cet empilement m’a fait changer d’avis : je ne considère plus qu’« un navigateur a déjà vu la transaction » suffise pour établir le fait transchain du rachat. Je vérifierai plutôt deux choses qui doivent être prouvées simultanément : l’événement est bien inclus, et le bloc d’exécution qui le porte a aussi été reconnu par la chaîne Beacon finalisée. La première répond à « qu’est‑ce qui s’est passé », la seconde à « est‑ce que cela fait désormais partie de l’état final d’Ethereum ». En manquant la seconde couche, un Payout Bitcoin pourrait s’appuyer sur un historique externe qui n’est pas encore stabilisé.
Une fois les preuves de finalité et d’inclusion établies, le claimer ne transmet la proof compressée qu’aux côtés Bitcoin pour le Claim, l’Assert et la fenêtre de challenge. La finalité Ethereum confirme à quelle tranche d’historique final l’événement appartient côté externe ; la période de contestation Bitcoin vérifie si la proof soumise côté Bitcoin peut être confirmée. Les deux ne portent pas sur la même attente, ne se substituent pas l’une à l’autre, et tant que la proof n’a pas été valablement réfutée, le Payout peut entrer en exécution.
Il faut aussi garder les limites en tête : la preuve qu’un événement de redemption est finalisé prouve que ce log a atteint l’état final d’Ethereum, mais cela ne signifie pas nécessairement que le contrat en amont, l’oracle ou la décision de liquidation soit économiquement correcte. Si le consensus Ethereum connaît un défaut profond, la vérification peut aussi s’arrêter ou produire une erreur. @BabylonLabs_io fixe le seuil sur « un événement dans l’historique finalisé », et non sur « un événement visible par un navigateur » : c’est précisément parce qu’après la libération de Bitcoin, elle ne sera pas automatiquement annulée par les changements ultérieurs de la chaîne externe. $ETH
$BABY
#baby