Блок-обозреватель показывает погашение (redemption), почему же $BTC до сих пор не может быть освобождён
Транзакция Ethereum уже разослана, включена в блок, сформирован receipt, и даже можно найти redemption event — всё это лишь доказывает, что некий execution block содержит эту запись. Для текущего публичного тестнета TBV этого всё ещё недостаточно для освобождения BTC: нужно доказать, что этот блок относится к той истории Ethereum, которая была окончательно принята.
Погашение долга пользователем и withdraw Vault, либо завершение процесса ликвидации с передачей Vault последующему роли, которая выполняет redeem, — всё это вызовет redemption event. Внецепочечный prover SP1 строит доказательство в фиксированном порядке: сначала Beacon finality подтверждает, что beacon block уже зафиксирован на уровне консенсуса (finalized); затем Execution finality связывает этот зафиксированный beacon block с execution block, содержащим транзакцию погашения; наконец Receipt inclusion подтверждает, что нужный redemption log присутствует в transaction receipt этого блока. Groth16 лишь сжимает и агрегирует первые три слоя доказательств в компактный proof и не придаёт блоку окончательности (finality).
Эта многоуровневая структура изменила мою оценку: я больше не считаю, что «обозреватель уже видит транзакцию» само по себе означает, что межцепочечное погашение (cross-chain redemption) фактически состоялось. Теперь я проверяю две вещи, которые должны быть подтверждены одновременно — событие действительно включено, и несущий его execution block также уже признан окончательно фиксированным (finalized) на beacon chain. Первый слой отвечает на вопрос «что произошло», а второй — «стало ли это частью окончательного состояния Ethereum». Без второго слоя Bitcoin Payout может быть основан на внешней истории, которая ещё не стабилизировалась.
После завершения доказательств finality и inclusion claimer передаёт сжатое proof на сторону Bitcoin для Claim, Assert и периода challenge window. Подтверждение finality в Ethereum подтверждает, к какой окончательно принятой истории относится внешний event; проверка в Bitcoin challenge period — может ли доказательство, представленное на стороне Bitcoin, быть признано корректным. Это не один и тот же «ожидающий» период, и они не взаимозаменяемы: только если proof не будет эффективно опровергнут, Payout переходит к исполнению.
Границы тоже важно держать в голове: доказательство finalized redemption event означает, что этот log уже вошёл в окончательное состояние Ethereum, но это не означает, что вышестоящий смарт-контракт, оракулы или расчёты ликвидации обязательно были экономически корректными. Если в консенсусе Ethereum возникнет глубокий сбой, это тоже может привести к зависанию или ошибкам в верификации. @BabylonLabs_io устанавливает порог на уровне «события в окончательной истории», а не на уровне «события, видимого в обозревателе» — именно потому, что после освобождения Bitcoin не будет автоматически отменять Payout из‑за последующих изменений внешней цепочки. $ETH
$BABY
#baby
Транзакция Ethereum уже разослана, включена в блок, сформирован receipt, и даже можно найти redemption event — всё это лишь доказывает, что некий execution block содержит эту запись. Для текущего публичного тестнета TBV этого всё ещё недостаточно для освобождения BTC: нужно доказать, что этот блок относится к той истории Ethereum, которая была окончательно принята.
Погашение долга пользователем и withdraw Vault, либо завершение процесса ликвидации с передачей Vault последующему роли, которая выполняет redeem, — всё это вызовет redemption event. Внецепочечный prover SP1 строит доказательство в фиксированном порядке: сначала Beacon finality подтверждает, что beacon block уже зафиксирован на уровне консенсуса (finalized); затем Execution finality связывает этот зафиксированный beacon block с execution block, содержащим транзакцию погашения; наконец Receipt inclusion подтверждает, что нужный redemption log присутствует в transaction receipt этого блока. Groth16 лишь сжимает и агрегирует первые три слоя доказательств в компактный proof и не придаёт блоку окончательности (finality).
Эта многоуровневая структура изменила мою оценку: я больше не считаю, что «обозреватель уже видит транзакцию» само по себе означает, что межцепочечное погашение (cross-chain redemption) фактически состоялось. Теперь я проверяю две вещи, которые должны быть подтверждены одновременно — событие действительно включено, и несущий его execution block также уже признан окончательно фиксированным (finalized) на beacon chain. Первый слой отвечает на вопрос «что произошло», а второй — «стало ли это частью окончательного состояния Ethereum». Без второго слоя Bitcoin Payout может быть основан на внешней истории, которая ещё не стабилизировалась.
После завершения доказательств finality и inclusion claimer передаёт сжатое proof на сторону Bitcoin для Claim, Assert и периода challenge window. Подтверждение finality в Ethereum подтверждает, к какой окончательно принятой истории относится внешний event; проверка в Bitcoin challenge period — может ли доказательство, представленное на стороне Bitcoin, быть признано корректным. Это не один и тот же «ожидающий» период, и они не взаимозаменяемы: только если proof не будет эффективно опровергнут, Payout переходит к исполнению.
Границы тоже важно держать в голове: доказательство finalized redemption event означает, что этот log уже вошёл в окончательное состояние Ethereum, но это не означает, что вышестоящий смарт-контракт, оракулы или расчёты ликвидации обязательно были экономически корректными. Если в консенсусе Ethereum возникнет глубокий сбой, это тоже может привести к зависанию или ошибкам в верификации. @BabylonLabs_io устанавливает порог на уровне «события в окончательной истории», а не на уровне «события, видимого в обозревателе» — именно потому, что после освобождения Bitcoin не будет автоматически отменять Payout из‑за последующих изменений внешней цепочки. $ETH
$BABY
#baby