El navegador de bloques ve el reembolso, ¿por qué $BTC todavía no puede liberarse?
La transacción de Ethereum ya se transmitió, se incluyó en un bloque, se generó el receipt e incluso se puede consultar el redemption event. Todo esto solo prueba que algún execution block contiene ese registro. Para el TBV de la red de pruebas pública actual, todavía no es suficiente para liberar BTC, porque además hay que demostrar que ese bloque pertenece al historial final adoptado por Ethereum.
Pagar la deuda y hacer withdraw del Vault, o que el proceso de liquidación entregue el Vault al rol de redención posterior, activará un redemption event. El prover SP1 fuera de la cadena construye la prueba en un orden fijo: la finality del Beacon primero confirma que el beacon block ya fue finalizado por la capa de consenso; luego la finality del Execution conecta ese beacon block finalizado con el execution block que contiene la transacción de redención; por último, la inclusión del receipt confirma que el log de redemption objetivo existe en el transaction receipt de ese bloque. Groth16 solo comprime y agrega las tres capas de pruebas en un proof compacto, y no otorga finalización final al bloque.
Esta segmentación cambió mi criterio: ya no considero que “el navegador ya vio la transacción” como un hecho establecido para el reembolso entre cadenas. En cambio, comprobaría si dos cosas pueden probarse simultáneamente: que el evento efectivamente esté incluido, y que el execution block que lo contiene también haya sido aceptado por la beacon chain finalizada. La primera responde “qué pasó”, y la segunda responde “si eso se convirtió en el estado final de Ethereum”. Al faltar la capa posterior, el Bitcoin Payout podría basarse en un historial externo que aún no es estable.
Después de completar las pruebas de finality e inclusión, el claimer recién introduce el proof comprimido en el lado de Bitcoin para Claim, Assert y la ventana de challenge. La finality de Ethereum confirma a qué tramo del historial final pertenece el evento externo; el periodo de challenge de Bitcoin comprueba si el proof enviado al lado de Bitcoin es válido. No se trata del mismo “tramo en espera” y no se pueden sustituir mutuamente; solo si el proof no es refutado de forma efectiva, el Payout pasa a ejecución.
También hay que dejar claro el límite: el redemption event finalizado demuestra que ese log ya entró en el estado final de Ethereum, pero no significa necesariamente que el contrato upstream, el oráculo o las decisiones de liquidación sean económicamente correctas; si el consenso de Ethereum sufre fallas profundas, también podría hacer que la validación se detenga o falle. @BabylonLabs_io coloca el umbral en “el evento dentro del historial final”, en lugar de “el evento visible en el navegador”, precisamente porque, después de que Bitcoin libere, no se revoca automáticamente debido a cambios posteriores en la cadena externa. $ETH
$BABY
#baby
La transacción de Ethereum ya se transmitió, se incluyó en un bloque, se generó el receipt e incluso se puede consultar el redemption event. Todo esto solo prueba que algún execution block contiene ese registro. Para el TBV de la red de pruebas pública actual, todavía no es suficiente para liberar BTC, porque además hay que demostrar que ese bloque pertenece al historial final adoptado por Ethereum.
Pagar la deuda y hacer withdraw del Vault, o que el proceso de liquidación entregue el Vault al rol de redención posterior, activará un redemption event. El prover SP1 fuera de la cadena construye la prueba en un orden fijo: la finality del Beacon primero confirma que el beacon block ya fue finalizado por la capa de consenso; luego la finality del Execution conecta ese beacon block finalizado con el execution block que contiene la transacción de redención; por último, la inclusión del receipt confirma que el log de redemption objetivo existe en el transaction receipt de ese bloque. Groth16 solo comprime y agrega las tres capas de pruebas en un proof compacto, y no otorga finalización final al bloque.
Esta segmentación cambió mi criterio: ya no considero que “el navegador ya vio la transacción” como un hecho establecido para el reembolso entre cadenas. En cambio, comprobaría si dos cosas pueden probarse simultáneamente: que el evento efectivamente esté incluido, y que el execution block que lo contiene también haya sido aceptado por la beacon chain finalizada. La primera responde “qué pasó”, y la segunda responde “si eso se convirtió en el estado final de Ethereum”. Al faltar la capa posterior, el Bitcoin Payout podría basarse en un historial externo que aún no es estable.
Después de completar las pruebas de finality e inclusión, el claimer recién introduce el proof comprimido en el lado de Bitcoin para Claim, Assert y la ventana de challenge. La finality de Ethereum confirma a qué tramo del historial final pertenece el evento externo; el periodo de challenge de Bitcoin comprueba si el proof enviado al lado de Bitcoin es válido. No se trata del mismo “tramo en espera” y no se pueden sustituir mutuamente; solo si el proof no es refutado de forma efectiva, el Payout pasa a ejecución.
También hay que dejar claro el límite: el redemption event finalizado demuestra que ese log ya entró en el estado final de Ethereum, pero no significa necesariamente que el contrato upstream, el oráculo o las decisiones de liquidación sean económicamente correctas; si el consenso de Ethereum sufre fallas profundas, también podría hacer que la validación se detenga o falle. @BabylonLabs_io coloca el umbral en “el evento dentro del historial final”, en lugar de “el evento visible en el navegador”, precisamente porque, después de que Bitcoin libere, no se revoca automáticamente debido a cambios posteriores en la cadena externa. $ETH
$BABY
#baby