Таймлок-контракты: OpenZeppelin и кастомные решения с аудитом

Разработка таймлок-контрактов: где ломается логика блокировки

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

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

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

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

Мы берём проверенные библиотеки вроде OpenZeppelin как базу и дописываем логику под задачу: фиксируем права и расписание до кода, покрываем тестами каждую ветку. Цена ошибки — не ошибка в интерфейсе, а потерянные токены, поэтому сдаём контракт с отчётом по этим четырём точкам.

Что даёт таймлок казначейству и вестингу

В казначействе таймлок-контракт заменяет переписку, ручные подписи и таблицы выплат на правило, которое исполняется само. Ниже — что именно меняется в операциях и какие эффекты видно в метриках.

Расписание выплат вместо договорённостей на словах

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

Автоматическая блокировка активов убирает ручные операции

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

Сверка состояния — минуты вместо человеко-дней

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

Класс отказов «выплатили не тому и не тогда» закрывается

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

Варианты реализации: готовая библиотека, кастомная логика, гибрид

На практике выбор сводится к трём вариантам, и критерий здесь один: кто владеет правилами блокировки, начисления и отмены — проверенная библиотека или ваш собственный код. Таймлок-контракт редко живёт в вакууме: рядом выпуск токенов, график разблокировки для команды, выплаты из казны. Поэтому сравниваем не по объёму кода, а по предсказуемости поведения при отмене, переносе сроков и досрочном выводе.

Опора на OpenZeppelin закрывает типовой сценарий, но как только появляются свои правила начисления, её приходится расширять — и здесь начинается развилка.

Обновляемый таймлок собираем так, чтобы расписание хранилось отдельно от логики: тогда правка правил не сбрасывает уже запущенные блокировки. Роли администратора и отмены разводим, а все изменения пишем в события — по ним видно, почему срок сдвинулся и кто это инициировал.

Этапы внедрения: от схемы блокировки до аудита кода

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

1. Разбор задачи. Фиксируем, что именно блокируется — токены, права на управление или ликвидность, кто получатель, по какому событию открывается доступ, допускается ли досрочный вывод третьей стороной.
2. Схема блокировки на бумаге. Описываем состояния контракта: пополнение, ожидание, доступный вывод, отзыв, аварийная остановка. Переходы согласуем с заказчиком — на этом шаге снимается большинство спорных сценариев.
3. Реализация. За основу берём проверенную библиотеку стандарта — актуальная ветка OpenZeppelin — и дописываем только то, чего в ней нет: нестандартные графики разблокировки, мультиподпись на вывод, привязку к внешнему источнику времени.
4. Проверка на тестовой сети. Прогоняем развёртывание и все ветки переходов, включая пограничные: вывод ровно в момент открытия, повторный вызов, пополнение после старта. Граничные случаи закрываем тестами, а не надеждой на аккуратность пользователя.
5. Независимый аудит контракта. Код смотряет отдельная команда, которая не писала его: ищет обход условий по времени, ошибки округления, возможность вывести средства раньше срока.
6. Устранение замечаний. Каждую находку закрываем правкой с повторной проверкой — отчёт аудита публикуем вместе с контрактом, чтобы получатели видели, что замечания сняты.
7. Внедрение и сопровождение. Развёртываем в основной сети, передаём адреса, исходники и инструкцию по разблокировке, остаёмся на связи при изменении условий.

Ключевой результат этапов — не сам код, а предсказуемое поведение: сроки разблокировки соблюдаются, а обход условий закрыт ещё до того, как в контракте появились средства.

Состав поставки: код, схемы блокировки, документация

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

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

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

Кейс: убрали ручные выплаты из казначейства

До: ручные выплаты и один ключ

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

После: расписание и лимиты в контракте

Расписание, лимиты и адреса получателей перенесли в таймлок-контракт на базе OpenZeppelin: берём проверенные механики блокировки и высвобождения средств вместо самописной логики, которую пришлось бы защищать с нуля. Досрочно снять средства нельзя, а изменение параметров проходит только через несколько подписей. До запуска логику прогнали независимым аудитом и отдельно отрепетировали сценарии отката на копии сети.

Ручных операций осталось 3-4 в месяц — только внеплановые платежи. Выплата, которая раньше занимала дни, проходит в пределах 10-15 минут после наступления срока: контракт сам высвобождает средства, человек в цепочке не участвует. Закрылся целый класс отказов — двойной платёж по одному счёту, перевод на устаревший адрес и списание раньше согласованной даты. Состояние казначейства теперь читается из контракта, а не из выгрузки, поэтому реестр больше не расходится с фактом.

Чем отложенный вывод отличается от мультиподписи и эскроу?

Отложенный вывод (таймлок) — механизм, при котором распоряжение средствами исполняется не сразу, а по наступлении срока. Контракт принимает команду, ставит её в очередь и открывает окно, в течение которого выплату можно отменить. Защита направлена против мгновенного вывода: даже при компрометации ключа управляющего у команды остаётся время снять распоряжение до исполнения.

Мультиподпись закрывает другую угрозу — единоличное решение. Порог «M из N» означает, что операция валидна только при наборе подтверждений от разных держателей ключей, поэтому кража или потеря одного устройства не открывает доступ к средствам.

Эскроу привязывает расчёт не ко времени и не к подписям, а к исполнению сделки. Средства блокируются до подтверждения поставки, приёмки или решения арбитра, а правила спора и возврата прописаны в контракте заранее.

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

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

Сомнения по логике блокировки: аудит, обновление, доступ

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

Можно ли изменить расписание после запуска?

В неизменяемом варианте нет, и это зафиксировано в коде: функции правки срока отсутствуют, дата разблокировки записана при развёртывании. Обновляемый вариант допускает перенос, поэтому его ограничиваем контроллером с задержкой исполнения.

Зачем внешний аудит, если логика на проверенной библиотеке?

Библиотека OpenZeppelin закрывает стандартные роли и депонирование, но не вашу схему распределения. Аудит проверяет именно её: порядок вызовов, права на выпуск и граничные состояния.

Контракт обновляемый или неизменяемый?

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

Как контракт ведёт себя на границах — за день до разблокировки и при повторном вызове?

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

Обсудим задачу: соберём схему блокировки и план работ

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

• Сеть и окружение: где разворачивается контракт, нужна ли работа в нескольких сетях, есть ли уже выпущенные токены и связанные адреса.
• Объём и расписание: сколько получателей и долей, как часто выпускаются и высвобождаются средства, на какой горизонт строится график.
• Роли и доступы: кто владелец и оператор, кому разрешено продлевать или сокращать срок, нужна ли мультиподпись и разграничение прав.
• Сценарии отмены: возможен ли досрочный вывод, при каких условиях, есть ли аварийная остановка и кому она доступна.
• Логика высвобождения: линейный график, ступени или пауза перед первой выплатой, что происходит с нераспределённым остатком.
• Проверки и отчётность: нужна ли внешняя проверка кода, какие события должны быть видны во внешних системах учёта.

Опишите задачу в свободной форме либо пришлите текущий контракт и описание распределения долей. Обсудим таймлок-контракт предметно: где риски, что переиспользуем из проверенных библиотек, что пишем отдельно и почему. После этого вернёмся с оценкой разработки и планом работ.