Блокчейн/Уровень IV · Глубины протокола/4.1 Script/Урок 4
Таймлоки: CLTV и CSV
Часы, которые нельзя перевести назад, и медиана, которая не даёт им врать
МатериалыОбозреватель блоков с подробным просмотром транзакций (например, mempool.space или blockchain.com)Калькулятор, способный обрабатывать временные метки UnixСпецификации BIP65, BIP68 и BIP113
Любопытство
- Зачем в транзакции существует поле для отсрочки траты, если новая транзакция всегда может его обойти?
- Как отдельный майнер может лгать о времени, не нарушая консенсус для всех остальных?
- В чём разница между ожиданием до определённого года и ожиданием двух лет начиная с этого момента?
Исследование
- Каждая транзакция Bitcoin содержит поле nLockTime — четырёхбайтовое значение, не позволяющее включить транзакцию в блок раньше определённого момента. Если значение меньше 500,000,000, оно обозначает высоту блока; если равно этому порогу или больше — временную метку Unix. Однако этот механизм действует только для данного конкретного экземпляра транзакции. Пользователь всегда может создать новую транзакцию с теми же входами и нулевым locktime и немедленно потратить монеты. Само по себе nLockTime не обеспечивает защиты будущих условий, поскольку не привязывает сам выход.
- OP_CHECKLOCKTIMEVERIFY (CLTV), предложенный Питером Тоддом в BIP65 и активированный в декабре 2015 года, меняет эту картину. CLTV — опкод скрипта, сравнивающий nLockTime транзакции со значением в стеке. Если locktime меньше требуемого значения, выполнение завершается ошибкой. Поскольку проверка происходит в запирающем скрипте выхода, каждая попытка потратить этот конкретный непотраченный выход транзакции (UTXO) должна удовлетворять условию. Так создаётся абсолютный таймлок: монеты нельзя потратить, пока не наступит глобальный, общий для консенсуса момент времени или высота блока.
- Относительные таймлоки работают иначе: они измеряют длительность, а не абсолютные моменты. BIP68 переосмысляет поле nSequence во входах транзакции, ранее не использовавшееся для этой цели, чтобы кодировать относительные задержки. OP_CHECKSEQUENCEVERIFY (CSV), определённый в BIP112 и активированный вместе с BIP68 в июле 2016 года, сравнивает значение sequence входа с требуемой длительностью. Это позволяет скриптам задавать условия вроде «этот выход нельзя потратить раньше чем через 144 блока после его подтверждения». Задержка отсчитывается от подтверждения конкретного UTXO, что делает её идеальной для путей восстановления по времени или истечения срока платёжных каналов.
- Блокировки по времени также давали майнерам стимул манипулировать временными метками. Майнеры могли ставить метки блоков на срок до двух часов вперёд, чтобы включать больше транзакций с таймлоками раньше задуманного. BIP113, активированный одновременно с относительными таймлоками в июле 2016 года, ввёл медианное время прошлого (Median Time Past, MTP). Теперь проверки таймлоков используют медиану временных меток последних одиннадцати блоков, а не метку самого блока. Это гарантирует, что ни один майнер не может существенно повлиять на часы; MTP обычно отстаёт от реального времени примерно на час, обеспечивая стабильную и проверяемую точку отсчёта для всех расчётов таймлоков.
- Эти механизмы лежат в основе сложных приложений, таких как платёжные каналы и протоколы наследования. В каналах Lightning платежи в процессе передачи используют абсолютные таймлоки (CLTV), чтобы невостребованный платёж можно было вернуть по истечении срока, а относительные задержки (CSV) на собственных выходах стороны дают другой стороне время наказать за публикацию устаревшего состояния канала. Для наследования скрипты могут сочетать требования мультиподписи с таймлоками: например, для повседневного доступа нужны два ключа, но после года бездействия к кворуму через условие CSV присоединяется третий ключ (наследника). Эти параметры фиксируются при создании кошелька и не могут быть изменены после блокировки средств.
- Таймлоки — это неизменные ограничения: они снимаются в заданное время, но не дают возможности снова заблокировать средства или продлить задержку после срабатывания. Если скрипт кодирует значение sequence в 100 блоков, монеты становятся доступными для траты ровно тогда, когда с момента подтверждения пройдёт эта относительная высота. Ошибки в кодировании могут сделать средства недоступными дольше задуманного или, наоборот, разблокировать их слишком рано. Чтобы проверить это на практике, откройте любую недавнюю транзакцию в обозревателе блоков и посмотрите поле nLockTime. Большинство кошельков устанавливают его равным текущей высоте блока, поэтому транзакцию нельзя поместить в блок с меньшей высотой; это устраняет один из стимулов для майнеров переписывать последний блок, чтобы забрать его комиссии («fee sniping»).
Ключевые факты
- Значения nLockTime ниже 500,000,000 интерпретируются как высота блока; значения, равные этому порогу или выше, — как временные метки Unix.
- OP_CHECKLOCKTIMEVERIFY (BIP65) был активирован в декабре 2015 года и обеспечивает соблюдение абсолютных таймлоков на уровне скрипта.
- OP_CHECKSEQUENCEVERIFY (BIP112) и BIP68 были активированы в июле 2016 года, что сделало возможными относительные таймлоки через поле nSequence.
- Медианное время прошлого (Median Time Past, MTP), введённое в BIP113, использует медиану последних одиннадцати блоков, чтобы не дать майнерам манипулировать временем.
- Задержки CSV отсчитываются от высоты или времени подтверждения конкретного расходуемого UTXO.
- Кошельки обычно устанавливают nLockTime равным текущей высоте блока, чтобы снизить риск fee sniping.
Упражнение девять, шесть, три, один
9СобратьПеречислите 9 описанных применений таймлоков, которые вам удастся найти (Lightning, хранилища-«волты», наследование, эскроу, атомарные свопы и другие), отметив, используется ли в каждом абсолютная или относительная блокировка.
6СгруппироватьРаспределите эти 9 по 6 группам по назначению: возврат средств, окно для наказания, наследование, блокировка сбережений, крайний срок контракта или другое.
3Выделить главноеСведите 6 групп к 3 причинам, по которым таймлок должен находиться в скрипте выхода, а не только в тратящей транзакции.
1КристаллизоватьНапишите одно предложение о том, как MTP превращает таймлоки из модели доверия майнерам в детерминированное правило консенсуса.
Проверка фактов
Даты, цифры и утверждения были проверены по приведенным ниже опубликованным источникам.
- P. Todd, BIP65: OP_CHECKLOCKTIMEVERIFY (2014)
- M. Friedenbach, BtcDrak, N. Dorier & kinoshitajona, BIP68: Relative lock-time using consensus-enforced sequence numbers (2015)
- BtcDrak, M. Friedenbach & E. Lombrozo, BIP112: CHECKSEQUENCEVERIFY (2015)
- Bitcoin Core source code, policy/policy.cpp and script/interpreter.cpp
- A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7