Как использовать time-locked транзакции для отложенных выплат

Представьте ситуацию: вы хотите отправить криптовалюту так, чтобы получатель смог забрать её только через определённое время. Или вам нужно организовать выплату токенов инвесторам с отсрочкой по датам. Или вы просто хотите застраховаться от собственных импульсивных решений и «заблокировать» средства на будущее. Для всего этого в блокчейне существует механизм time-locked транзакций — транзакций с временной блокировкой.

В этой статье я объясню, как это работает на практике, какие инструменты использовать и какие подводные камни ждут на пути. Без теории ради теории — только то, что реально пригодится при решении конкретных задач.

Что такое time-locked транзакция простыми словами

Time-locked транзакция — это транзакция, которая становится валидной (то есть может быть включена в блок) только после наступления определённого условия: либо конкретного времени, либо определённого количества блоков.

По сути, вы создаёте транзакцию, подписываете её, но сеть не принимает её до тех пор, пока не истечёт нужный срок. Это похоже на банковский депозит с фиксированным сроком — деньги лежат на счёте, но снять их можно только после даты погашения.

В Bitcoin этот механизм встроен прямо в язык скриптов (Script). В Ethereum аналогичная логика реализуется через смарт-контракты. Другие блокчейны тоже поддерживают подобные конструкции, хотя детали реализации различаются.

Два основных варианта: по времени и по блокам

Есть два способа задать условие блокировки, и важно понимать разницу между ними.

Locktime по времени (CLTV и nLockTime)

Вы задаёте конкретную метку времени (Unix timestamp) или дату. Транзакция не будет принята сетью, пока текущее время не превысит указанное. Например, вы хотите, чтобы средства стали доступны 1 января 2026 года в 00:00 UTC — именно это значение и указывается.

На практике это удобно, когда вы работаете с конкретными календарными датами: выплаты по контрактам, вестинг для команды, отложенные переводы между сторонами.

Locktime по блокам (CSV)

Вместо времени вы указываете количество блоков, которые должны быть добыты после того, как транзакция попадёт в мемпул. Например, «эта транзакция валидна через 1000 блоков после подтверждения родительской».

Этот вариант менее предсказуем в календарном смысле (время добычи блоков колеблется), но более устойчив к манипуляциям со стороны майнеров. Если вы работаете в Bitcoin, где интервал блоков относительно стабилен (~10 минут), можно примерно прикинуть: 100 блоков — это примерно 16–17 часов.

Как это работает в Bitcoin на уровне скрипта

Если вы разработчик и хотите понять механику, вот как выглядит базовый time-locked скрипт в Bitcoin:

OP_CHECKLOCKTIMEVERIFY (CLTV) проверяет, что значение в поле nLockTime транзакции больше или равно значению, указанному в скрипте. Если условие не выполнено — скрипт завершается ошибкой, и транзакция отклоняется.

OP_CHECKSEQUENCEVERIFY (CSV) работает аналогично, но использует относительное время — отсчёт идёт не от Unix-времени, а от момента подтверждения входной транзакции.

Простой пример использования CLTV в P2SH-скрипте:

OP_IF
  <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <pubkey> OP_CHECKSIG
OP_ELSE
  OP_RETURN
OP_ENDIF

Этот скрипт позволяет потратить выход либо после указанного времени (подпись от соответствующего приватного ключа), либо вообще не позволяет (OP_RETURN). Вариации могут быть разными — например, добавить второй путь с другим ключом для досрочного снятия.

Практические сценарии использования

1. Вестинг токенов для команды и инвесторов

Самый распространённый кейс. Вы раздаёте токены команде, но так, чтобы они не могли продать их сразу. Вместо того чтобы просто пообещать «не продавать до определённой даты», вы технически блокируете средства в смарт-контракте. Получатель может проверить код контракта и убедиться, что обойти блокировку невозможно.

2. Отложенные платежи между сторонами

Допустим, вы продаёте NFT или цифровой актив с отсрочкой передачи. Покупатель платит, но актив переходит к нему только через неделю. Или наоборот: вы отправляете средства другу, но он получает к ним доступ только на день рождения. Всё это — time-locked транзакции.

3. Накопительные стратегии

Вы хотите раз в месяц покупать Bitcoin на определённую сумму и не иметь возможности забрать накопления раньше чем через год. Можно настроить серию time-locked транзакций — каждая со своей датой разблокировки. Это работает как «копилка с замком».

4. Наследование цифровых активов

Один из самых неочевидных, но мощных сценариев. Вы создаёте time-locked транзакцию, которая переводит средства на адрес наследника, но только если вы не «обновите» транзакцию в течение определённого периода (например, года). Если вы не активны год — средства уходят наследнику. Это реализуется через комбинацию multisig и time-lock.

Инструменты для создания time-locked транзакций

В зависимости от вашего уровня технической подготовки и блокчейна, инструменты будут разными:

Инструмент / Платформа	Блокчейн	Уровень сложности	Что умеет
Bitcoin Core (RPC)	Bitcoin	Продвинутый	Создание raw-транзакций с nLockTime и CLTV-скриптами через командную строку
Electrum	Bitcoin	Средний	Поддержка транзакций с locktime через GUI, удобно для непрограммистов
Solidity + OpenZeppelin	Ethereum, EVM-совместимые	Продвинутый	Готовые контракты TimelockController, VestingWallet для вестинга и отложенных выплат
Safe (Gnosis Safe)	Ethereum и др.	Средний	Мультисиг-кошелёк с возможностью настройки периодов блокировки через модули
Solanas time-based programs	Solana	Продвинутый	Программы для вестинга и escrow с временными условиями через Clock sysvar

Пошаговый пример: создание time-locked транзакции в Bitcoin

Разберём конкретный сценарий: вы хотите отправить 0.01 BTC на адрес, но так, чтобы средства можно было потратить только после 1 июня 2025 года.

1. Определяем locktime. 1 июня 2025, 00:00 UTC — это Unix timestamp 1748736000.
2. Создаём raw-транзакцию с полем nLockTime = 1748736000. Используем Bitcoin Core:

bitcoin-cli createrawtransaction '[{"txid":"...","vout":0}]' '[{"address":0.0099}]' 1748736000

3. Подписываем транзакцию:

bitcoin-cli signrawtransactionwithwallet "signed_hex"

4. Проверяем результат. Получаем JSON, где поле complete = true, а в _hex-транзакции в поле locktime записано значение 1748736000 (в little-endian).
5. Пока не отправляем. Транзакция технически валидна, но сеть её не примет до наступления указанного времени. Храним hex локально.
6. После 1 июня 2025 года транслируем транзакцию в сеть:

bitcoin-cli sendrawtransaction "hex_from_step_3"

Важно: если вы используете CLTV на уровне скрипта (а не только nLockTime), то получатель при попытке потратить эти средства тоже должен предоставить скрипт с правильным locktime. Это уже более продвинутый уровень, и тут проще использовать готовые кошельки с поддержкой.

Вестинг через смарт-контракты на Ethereum

На Ethereum всё гибче, но и сложнее одновременно. Рассмотрим практический пример с OpenZeppelin VestingWallet — это стандартный аудированный контракт, который не нужно писать с нуля.

Сценарий: вы хотите выделить 1000 USDC сотруднику с линейным вестингом на 4 года и cliff в 1 год.

1. Деплоим контракт VestingWallet с параметрами: бенефициар — адрес сотрудника, start — текущий timestamp, duration — 4 года в секундах, cliff — 1 год в секундах.
2. Передаём токены на адрес контракта. С этого момента они заблокированы и начинают «размораживаться» по линейной кривой.
3. Сотрудник забирает доступные токены вызовом функции release(). Контракт сам рассчитывает, сколько можно забрать на текущий момент.

Преимущество такого подхода: бенефициар видит контракт в открытом блокчейне, может проверить код и убедиться, что условия не изменятся. Никакого доверия к отправителю не требуется — код гарантирует выполнение.

Частые ошибки при работе с time-locked транзакциями

Вот реальные проблемы, с которыми сталкиваются люди на практике:

• Путаница между абсолютным и относительным locktime. nLockTime и CLTV — абсолютные (от конкретной даты). CSV — относительные (от момента подтверждения). Если перепутать, средства могут заблокироваться не так, как вы ожидали.
• Забыли про комиссии. При создании raw-транзакции в Bitcoin нужно правильно рассчитать выходную сумму (вход минус комиссия). Если указать слишком маленькую комиссию, транзакция может застрять в мемпуле на неопределённый срок.
• Использование неаудированных контрактов. На Ethereum самописный контракт с time-lock — это минное поле. Ошибка в логике блокировки может привести к тому, что средства застрокают навсегда или, наоборот, кто-то их заберёт досрочно. Всегда используйте проверенные библиотеки (OpenZeppelin).
• Неправильный расёт времени. Unix timestamp считается в секундах, а не в миллисекундах. Ошибиться легко, особенно если вы автоматизируете процесс через скрипты. Проверяйте дважды.
• Отсутствие тестирования в testnet. Никогда не деплойте time-locked контракты и не создавайте time-locked транзакции в основной сети без предварительного тестирования. Одна ошибка — и средства невозможно вернуть.
• Игнорирование последствий для ликвидности. Если вы блокируете крупную сумму на длительный срок, учитывайте, что вы не сможете ей воспользоваться. Это кажется очевидным, но на практике люди забывают и потом оказываются в затруднительном положении.

Что выбрать в зависимости от вашей ситуации

Если вам нужно просто отправить криптовалюту с отсрочкой на конкретную дату — используйте кошелёк с поддержкой locktime (Electrum для Bitcoin). Это самый простой путь, не требующий технических знаний.

Если вы организуете вестинг для команды или инвесторов — используйте смарт-контракты с аудированными библиотеками (OpenZeppelin для EVM-сетей). Это даёт прозрачность и автоматизирует процесс.

Если вам нужна максимальная безопасность и децентрализация — Bitcoin с CLTV-скриптами остаётся золотым стандартом. Меньше поверхность атаки, нет рисков багов в смарт-контрактах.

Если вы работаете с большими суммами — рассмотрите комбинацию multisig + time-lock. Это добавляет дополнительный уровень защиты: даже если один ключ скомпрометирован, злоумышленник не сможет забрать средства до истечения срока блокировки.

Если вам нужна гибкость и возможность изменить условия — используйте управляемые контракты с функцией изменения параметров (но это требует доверия к администратору, учитывайте этот компромисс).

Как проверить, что time-lock работает корректно

Перед тем как доверять реальные средства time-locked механизму, убедитесь, что всё настроено правильно:

1. Проверьте locktime в транзакции. Для Bitcoin используйте блокчейн-эксплоратор или bitcoin-cli decoderawtransaction. Убедитесь, что значение locktime соответствует вашим ожиданиям.
2. Протестируйте в testnet. Отправьте тестовую транзакцию в тестовую сеть и попробуйте её потратить до и после указанного времени. Это единственный надёжный способ убедиться в корректности.
3. Проверьте код контракта. Для Ethereum — верифицируйте контракт в Etherscan и убедитесь, что исходный код совпадает с аудированной версией.
4. Симулируйте сценарии. Что произойдёт, если получатель попытается потратить средства раньше? Что будет, если комиссия резко вырастет? Продумайте крайние случаи.

Важные нюансы, о которых редко говорят

Майнеры могут влиять на locktime в Bitcoin. По правилам протокола, майнер может установить nLockTime блока на значение до 2 часов вперёд от своего локального времени. На практике это не создаёт серьёзных проблем для пользовательских транзакций, но если вам нужна точность до минуты — учитывайте этот допуск.

Relative locktime в Bitcoin считается по-разному для секунд и блоков. Если вы используете CSV, значение меньше 500 000 000 интерпретируется как количество блоков, а больше — как количество единиц по 512 секунд. Это неочевидная деталь, которая может привести к ошибке в расчётах.

На Ethereum блоки приходят примерно раз в 12 секунд, но это не гарантировано. Если вы используете block number вместо timestamp для условий в смарт-контракте, будьте готовы к отклонению в несколько минут. Для большого вестинга (месяцы и года) это несущественно, но для точных операций — может иметь значение.

Газовые затраты. Создание и исполнение time-locked транзакций на Ethereum требует газа. Если вы создаёте десятки или сотни таких контрактов, расходы на газ могут быть ощутимыми. Планируйте бюджет заранее.

Итог: что делать дальше

Time-locked транзакции — это мощный и проверенный инструмент для организации отложенных выплат. Вот краткая дорожная карта:

• Определите конкретную задачу: вестинг, отложенный перевод, накопление, наследование.
• Выберите блокчейн и инструмент под ваш уровень технической подготовки.
• Протестируйте всё в testnet с реальными сценариями до того, как задействуете основные средства.
• Используйте аудированные библиотеки и проверенные кошельки — не пишите критическую логику с нуля без крайней необходимости.
• Проверяйте locktime и условия блокировки перед отправкой реальных средств.

Если ваша задача простая — начните с Electrum для Bitcoin или OpenZeppelin для Ethereum. Это самые проверенные и понятные точки входа. Если задача сложная (комбинация multisig, кастомная логика вестинга, кросс-чейн сценарии) — имеет смысл привлечь разработчика с опытом работы с блокчейн-протоколами.

Информация в этой статье носит ознакомительный характер. Использование time-locked транзакций и смарт-контрактов сопряжено с финансовыми рисками, включая безвозвратную потерю средств при ошибках в настройке. Перед реализацией решений с крупными суммами рекомендуется проконсультироваться с профильным разработчиком или техническим специалистом.