Um navegador de blockchains vê o resgate; por que o $BTC ainda não pode liberar?
A transação do Ethereum já foi transmitida, empacotada em um bloco, gerou receipt e até dá para consultar o redemption event. Isso só prova que algum bloco de execução contém esse registro. Para o TBV do atual testnet público, isso ainda não é suficiente para liberar BTC, porque é necessário provar que aquele bloco pertence ao histórico final que o Ethereum realmente adotou.
O fato de o usuário ter quitado a dívida e withdraw do Vault, ou o processo de liquidação transferir o Vault para o agente de resgate subsequente, também vai disparar um redemption event. O prover SP1 off-chain constrói as provas em uma ordem fixa: a finalidade do Beacon primeiro confirma que o beacon block foi finalizado pelo nível de consenso; a finalidade da Execution então conecta esse beacon block finalizado ao execution block que contém a transação de resgate; e a inclusão do receipt por fim confirma que o redemption log alvo existe no transaction receipt daquele bloco. O Groth16 apenas comprime e agrega as três primeiras camadas em uma proof compacta, mas não confere finalidade ao bloco.
Esse empilhamento mudou meu julgamento: eu não trato mais “o navegador já viu a transação” como fato estabelecido para resgate cross-chain. Em vez disso, verifico se duas coisas podem ser provadas ao mesmo tempo — o evento foi de fato incluído, e o execution block que o carrega também já foi reconhecido pela beacon chain como final. A primeira responde “o que aconteceu”; a segunda responde “se isso se tornou o estado final do Ethereum”. Sem a segunda camada, um Bitcoin Payout pode acabar se baseando em um histórico externo que ainda não está estável.
Depois de concluir as provas de finality e de inclusion, o claimer só então leva a proof compactada para o lado do Bitcoin no Claim, Assert e na challenge window. A finalidade do Ethereum confirma a qual trecho do histórico final um evento externo pertence; a janela de desafio do Bitcoin verifica se a proof submetida ao lado do Bitcoin pode se sustentar. As duas não são a mesma parte de espera e não podem substituir uma à outra; só quando a proof não for efetivamente refutada é que o Payout entra em execução.
Também é preciso manter as fronteiras claras: provar um finalized redemption event significa que aquele log já entrou no estado final do Ethereum, mas não equivale a afirmar que o contrato upstream, o oráculo ou a decisão do processo de liquidação esteja economicamente correta. Se o consenso do Ethereum enfrentar uma falha profunda, a validação também pode travar ou dar erro. @BabylonLabs_io coloca o limiar em “o evento no histórico final”, e não em “o evento visível no navegador”, justamente porque depois que o Bitcoin libera, o Payout não será automaticamente desfeito por mudanças posteriores na cadeia externa. $ETH
$BABY
#baby
A transação do Ethereum já foi transmitida, empacotada em um bloco, gerou receipt e até dá para consultar o redemption event. Isso só prova que algum bloco de execução contém esse registro. Para o TBV do atual testnet público, isso ainda não é suficiente para liberar BTC, porque é necessário provar que aquele bloco pertence ao histórico final que o Ethereum realmente adotou.
O fato de o usuário ter quitado a dívida e withdraw do Vault, ou o processo de liquidação transferir o Vault para o agente de resgate subsequente, também vai disparar um redemption event. O prover SP1 off-chain constrói as provas em uma ordem fixa: a finalidade do Beacon primeiro confirma que o beacon block foi finalizado pelo nível de consenso; a finalidade da Execution então conecta esse beacon block finalizado ao execution block que contém a transação de resgate; e a inclusão do receipt por fim confirma que o redemption log alvo existe no transaction receipt daquele bloco. O Groth16 apenas comprime e agrega as três primeiras camadas em uma proof compacta, mas não confere finalidade ao bloco.
Esse empilhamento mudou meu julgamento: eu não trato mais “o navegador já viu a transação” como fato estabelecido para resgate cross-chain. Em vez disso, verifico se duas coisas podem ser provadas ao mesmo tempo — o evento foi de fato incluído, e o execution block que o carrega também já foi reconhecido pela beacon chain como final. A primeira responde “o que aconteceu”; a segunda responde “se isso se tornou o estado final do Ethereum”. Sem a segunda camada, um Bitcoin Payout pode acabar se baseando em um histórico externo que ainda não está estável.
Depois de concluir as provas de finality e de inclusion, o claimer só então leva a proof compactada para o lado do Bitcoin no Claim, Assert e na challenge window. A finalidade do Ethereum confirma a qual trecho do histórico final um evento externo pertence; a janela de desafio do Bitcoin verifica se a proof submetida ao lado do Bitcoin pode se sustentar. As duas não são a mesma parte de espera e não podem substituir uma à outra; só quando a proof não for efetivamente refutada é que o Payout entra em execução.
Também é preciso manter as fronteiras claras: provar um finalized redemption event significa que aquele log já entrou no estado final do Ethereum, mas não equivale a afirmar que o contrato upstream, o oráculo ou a decisão do processo de liquidação esteja economicamente correta. Se o consenso do Ethereum enfrentar uma falha profunda, a validação também pode travar ou dar erro. @BabylonLabs_io coloca o limiar em “o evento no histórico final”, e não em “o evento visível no navegador”, justamente porque depois que o Bitcoin libera, o Payout não será automaticamente desfeito por mudanças posteriores na cadeia externa. $ETH
$BABY
#baby