Discreet Log Contracts (DLC) на биткоине: оракулы, адаптор‑подписи и CET/рефанд‑транзакции

В этой статье вы узнаете:

• Что такое DLC простыми словами: как оракул публикует исход, а стороны заранее готовят траты под все сценарии.
• Минимальные/максимальные суммы, структура комиссий (sat/vB), почему “пыль” UTXO удорожает расчёт.
• Какие кошельки/клиенты и функции обязательны: предподписанные CET, рефанд‑транзакции, RBF/CPFP, управление UTXO.
• Пошаговую инструкцию: от выбора оракула и формирования контрактов до получения аттестации и закрытия.
• Расширенные риски: задержка/ошибка оракула, множественные оракулы (AND/OR), зависание в mempool, конфликты комиссий.
• Контекст по РФ и праздники: как не попасть на пиковые комиссии и дефицит внимания контрагентов/оракулов.

Что такое DLC простыми словами

DLC — это двухсторонний ончейн‑контракт на биткоине, где выплаты зависят от результата внешнего события (например, цены актива в момент T). Стороны заранее готовят набор CET (Contract Execution Transactions) — по одной на каждый возможный диапазон исходов — и подписывают их так, что завершить любую из них можно только при наличии подписи оракула под “правильным” исходом. Оракул публикует краткую аттестацию (обычно дискретный логарифм‑подпись по неизвестному заранее nonce), и эта подпись “раскрывает” ровно ту CET, которая соответствует реальному исходу. Оракул не получает доступ к средствам, он лишь публикует факт. Доверие — к его корректной публикации. Подробнее о DLC читайте на сайте.

Минимальные/максимальные суммы, комиссии и UTXO‑гигиена

• Минимум. Экономический порог часто начинается от ~$50–$100 эквивалента: вам нужно профинансировать вход(ы) контрактного выхода, заплатить комиссию L1 (sat/vB) за создание и последующее закрытие, иметь буфер на RBF/CPFP в случае перегрузки mempool. Чем дробнее ваши входы (“пыль”), тем больше размер транзакции и комиссия в сатоши — консолидацию лучше делать заранее в “тонкие” окна.
• Максимум. Технически не ограничен, но большие суммы дробят на несколько DLC с одинаковыми условиями, чтобы снизить операционный риск и зависимость от одной гигантской транзакции. Также это облегчает RBF/CPFP: поднимать комиссию точечно дешевле и быстрее.
• Комиссии. Планируйте:

1. Создание контракта (funding) — одна транзакция с входами/выходом скрипта DLC.
2. Исполнение CET — одна транзакция.
3.  Рефанд (на случай отсутствия оракула к дедлайну) — запасная транзакция с CSV/CLTV временем. В спокойные окна берите “среднюю” ставку sat/vB. В пиковые — включайте RBF сразу, чтобы иметь право на замену.

Требования к кошельку/клиенту и безопасные опции

Клиент должен уметь:

1. Генерировать и хранить предподписанные CET и рефанд‑транзакцию, сверяя суммы, locktime и скрипты.
2. Импортировать публичные параметры оракула (публичный ключ, схему аттестации, формат исхода).
3. Готовить funding‑транзакцию из “чистых” UTXO средней величины.
4. Включать RBF на всех отправляемых транзакциях и иметь CPFP‑механику (подталкивание дочерним выходом).
5. Поддерживать мульти‑оракульные схемы (AND/OR), если вы страхуете один источник другим
   вести журнал TXID/параметров, чтобы обе стороны могли реконструировать состояние.

Пошаговая инструкция

1. Дизайн контракта. Согласуйте с контрагентом: размер, срок (T), источник данных (оракул), тип исхода (бинарный, диапазонный, непрерывный — с разбивкой на “корзины”), формулу выплат, дедлайн рефанда и схему комиссий (кто платит за funding/CET, как делите RBF/CPFP).
2. Выбор оракула и параметры исхода. Получите публичный ключ оракула, формат аттестации и график публикации результата. Для важного контракта рассмотрите 2–3 оракула со схемами AND (всем доверяем) или OR (любой из списка).
3. UTXO‑подготовка. Сконсолидируйте входы в 1–2 UTXO (например, по 0.01–0.05 BTC каждая, в зависимости от объёма) в спокойные часы mempool. Избегайте десятков мелких входов. Проверьте dust‑порог: CET не должны создавать “пылевые” выходы.
4. Генерация и обмен CET/рефандами. Клиент вычисляет все CET (по одному на “корзину”) и рефанд с отложенной блокировкой (CLTV/CSV), стороны обмениваются и верифицируют скрипты/суммы/времена. На этом шаге ошибки недопустимы — проверьте шесть раз.
5. Funding‑транзакция. Соберите funding‑TX из “чистых” UTXO, включите RBF, поставьте адекватный sat/vB, подпишите и отправьте. Дождитесь 1–3 подтверждений (зависит от доверенности контрагента).
6. Получение исхода и аттестации. После T оракул публикует подпись (или вектор подписей для числового исхода). Верифицируйте её и “раскройте” соответствующую CET. Если mempool перегружен — используйте RBF для CET сразу, или CPFP — при запаздывании.
7. Исполнение или рефанд. Если оракул опоздал — действуйте по дедлайну рефанда: по истечении CLTV/CSV вы имеете право вернуть средства. Это должно быть оговорено заранее, чтобы стороны не спорили о комиссиях и сроках.

Расширенные риски и как их снижать

• Оракул не публикует исход/ошибается. Иметь резервного оракула, OR‑схему и чёткий план коммуникации. Для рыночных исходов — использовать источники с регулярной историей публикаций.
• Конфликт комиссий при CET. Если обе стороны подают CET с разными комиссиями, в блок попадёт более выгодная для майнеров. Согласовывайте sat/vB заранее. При RBF — информируйте контрагента.
• Зависание в mempool. Всегда включайте RBF на funding/CET. Держите небольшой “кошелёк комиссий” с возможностью CPFP.
• “Пыль” входов. Внедрите политику: не держать крошечные UTXO, раз в неделю консолидировать в “окне” низких комиссий.

Контекст по РФ и праздники

Не ставьте дедлайны публикации исходов/закрытия на Новый год/майские/ноябрьские длинные выходные: сети перегружены, реакция людей и оракулов медленнее. Создавайте/закрывайте DLC за 1–3 дня до пиков, держите запас BTC на комиссии, фиксируйте контакты на случай внеплановой RBF.

FAQ

• Можно ли закрыть контракт раньше? Только если предусмотрена CET на досрочную дату/диапазон или подписан отдельный кооперативный выход.
• Сколько CET нужно? Для диапазонных исходов — по “корзине”. Чем мельче сетка — тем больше CET и размер хранения/проверок.
• Два оракула с разными исходами — что делать? Следовать заранее оговорённой логике AND/OR; отсутствие такой логики — причина споров, поэтому задаётся при создании.

Заключение

DLC — мощный способ перенести деривативы в ончейн‑рамки BTC без кастоди. Успех — в подготовке: чистые UTXO, проверенные CET/рефанды, резервные оракулы и план комиссий (RBF/CPFP). Введите операционный чек‑лист и репетицию на тестовой сумме, и вы сведёте риски к минимуму.

Подробнее о дисциплине UTXO, выборе sat/vB, RBF/CPFP вы можете прочитать в этой статье.