Только что снова перечитал те несколько фрагментов о процессе клиринга @BabylonLabs_io и внезапно понял одну вещь, которой раньше не уделял должного внимания: хранилище, по сути, заранее подписанный и неизменяемый кем-либо скрипт. Так как же оно "знает", когда именно выпускать BTC?
Раньше я думал, что рядом есть нечто вроде оракула: в офчейне отправляют сигнал, а в чейне выполняется действие. Но после проверки оказалось, что дело совсем не так — подход TBV обратный: не заставлять биткоин сам по себе чувствовать, что происходит с хостчейн, а наоборот — сторона, которая хочет использовать BTC, должна сама перевести уже произошедшее на хостчейне в криптографическое доказательство, которое можно проверить биткоин-скриптом, и затем подать это доказательство наверх.
Сам скрипт от начала до конца ничего не понимает в заимствованиях, клиринге и ценах. Он делает только одно — проверяет, удовлетворяет ли предоставленное доказательство заранее определённому пути расходов.
Вот почему в whitepaper и существует эта конструкция с «признанием (claim)» и «оспариванием (challenge)». Заёмщик хочет забрать свои BTC — сначала отправляет claim. Если никто не спорит, после timelock всё проходит. Но если кредитор подозревает проблему, он может инициировать challenge и заставить заёмщика прямо на месте раскрыть подписанное ZK-доказательство: если доказательство валидно — выпуск разрешён, если доказательство невалидно — секрет извлекается из запутывающей схемы и выводится напрямую, блокируя этот вывод.
На протяжении всего процесса в биткоин-чейне нет никакого третьего лица, которое вынесло бы решение. Власть арбитра прописана в условиях скрипта, а не передана человеку.
Если так посмотреть, TBV изменяет не то, «существует ли BTC», а то, что впервые биткоин получает возможность давать проверяемую реакцию на внешнее событие, которое он сам полностью не может понять: не нужно верить словам — нужно лишь удостовериться, достаточно ли предоставленное доказательство квалифицировано.
Насколько долго выставлен timelock в конкретном окне оспаривания — я в документации не нашёл единого значения. Возможно, это настраивается разными интегрированными приложениями по-своему; пока не проверял. Если бы вам нужно было спроектировать длительность окна оспаривания, вы бы предпочли оставить подольше для безопасности или покороче для удобства?#baby $BABY
Раньше я думал, что рядом есть нечто вроде оракула: в офчейне отправляют сигнал, а в чейне выполняется действие. Но после проверки оказалось, что дело совсем не так — подход TBV обратный: не заставлять биткоин сам по себе чувствовать, что происходит с хостчейн, а наоборот — сторона, которая хочет использовать BTC, должна сама перевести уже произошедшее на хостчейне в криптографическое доказательство, которое можно проверить биткоин-скриптом, и затем подать это доказательство наверх.
Сам скрипт от начала до конца ничего не понимает в заимствованиях, клиринге и ценах. Он делает только одно — проверяет, удовлетворяет ли предоставленное доказательство заранее определённому пути расходов.
Вот почему в whitepaper и существует эта конструкция с «признанием (claim)» и «оспариванием (challenge)». Заёмщик хочет забрать свои BTC — сначала отправляет claim. Если никто не спорит, после timelock всё проходит. Но если кредитор подозревает проблему, он может инициировать challenge и заставить заёмщика прямо на месте раскрыть подписанное ZK-доказательство: если доказательство валидно — выпуск разрешён, если доказательство невалидно — секрет извлекается из запутывающей схемы и выводится напрямую, блокируя этот вывод.
На протяжении всего процесса в биткоин-чейне нет никакого третьего лица, которое вынесло бы решение. Власть арбитра прописана в условиях скрипта, а не передана человеку.
Если так посмотреть, TBV изменяет не то, «существует ли BTC», а то, что впервые биткоин получает возможность давать проверяемую реакцию на внешнее событие, которое он сам полностью не может понять: не нужно верить словам — нужно лишь удостовериться, достаточно ли предоставленное доказательство квалифицировано.
Насколько долго выставлен timelock в конкретном окне оспаривания — я в документации не нашёл единого значения. Возможно, это настраивается разными интегрированными приложениями по-своему; пока не проверял. Если бы вам нужно было спроектировать длительность окна оспаривания, вы бы предпочли оставить подольше для безопасности или покороче для удобства?#baby $BABY