Эта статья также опубликована в личном блоге Глеба здесь.

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

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

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

1 Введение

Защита от цензуры — одно из главных свойств биткоина. Мы даже считаем аксиомой, что биткоин хорошо сопротивляется государственному контролю, и в блокчейне биткоина цензура определенной транзакции невозможна.

Но что, если побудить майнеров биткоина игнорировать определенную транзакцию? Очевидно, что сторона, которая не хочет прохождения определенной транзакции, может просто предложить транзакцию с более высокой ценой, учитывая ограниченный размер блока. Мы называем этот и другие не принудительные методы игнорирования транзакции удержанием транзакции (или TxWithhold) — не путать с (принудительной) цензурой (хотя некоторые исследования, приведенные в разделе «История вопроса», называют это цензурой).

Очевидно, что устойчивость сети к удержанию не является аксиомой. В то же время мы считаем, что оно маловероятно в силу следующих двух наблюдений:

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

Тем не менее, попытки выполнить удержать вполне возможны, особенно под давлением регулирующих органов (см. ChainAncor).

В этой работе мы оспариваем второе предположение. Мы обсуждаем способы предотвращения майнинга транзакции в течение длительного времени (скажем, добычи 100 блоков), которое может быть мотивировано как минимум двумя причинами: 

1. Атака на протоколы, чувствительные ко времени (например, Lightning).
2. Политическое санкционирование определенных платежей

В этой статье мы рассматриваем удержание любых транзакций, а не только транзакций в двухсторонних протоколах на основе смарт-контрактов HTLC (Hash Time Lock Contract), и предполагаем, что злоумышленник не участвует в создании целевой транзакции.

Мы будем использовать «идеалистический» протокол биткоина, вместо того чтобы атаковать передачу биткоина или эксплуатировать недостатки мемпула. 

Сначала мы рассмотрим известные тривиальные способы удержания транзакции, а затем предложим смарт-контракт, в котором решены проблемы тривиальных подходов (а именно, высокие затраты и организация удержания).

Я выражаю благодарность Антуану Риарду за его вклад в написание этой статьи; а также Эрику Сириону, Рубену Сомсену и LLFOURN за рецензию. 

1.1 Основные термины

• Целевая транзакция: транзакция, которую нужно удержать
• Плата (комиссия) за целевую транзакцию: плата, которую жертва платит за включение целевой транзакции
• Злоумышленник: лицо, желающее удержать целевую транзакцию
• Жертва: лицо, расходующее целевую транзакцию
• Транзакция вознаграждения: транзакция выплаты вознаграждения майнеру, который удержал целевую транзакцию.

2 История вопроса

В статье «Атаки временной цензуры в присутствии рациональных майнеров» обсуждается теория игр и рационализм майнеров при использовании различных стратегий удержания (SimpleBribery, CompensationBribery, FeatherForkBribery). В отличие от нее, в нашей работе нет серьезного анализа теории игр, а основное внимание уделяется разработке контрактов с функцией удержания для биткоина с учетом возможностей Bitcoin Script. В моей работе также не учитывается форкинг блокчейна. Наши механизмы могут быть использованы для реализации чего-то подобного CompensationBribery в сети биткоина.

В работе «MAD-HTLC: потому что атака на контракты HTLC обходится супердешево» объясняется, почему контракты HTLC в двухсторонних протоколах уязвимы для удержания методом подкупа, что приводит к потере средств. Этот подкуп осуществляется с помощью тривиального смарт-контракта, выплачивающего средства, которые в противном случае были бы потеряны контрагентом. Авторы предлагают решить эту проблему с помощью альтернативной структуры HTLC: MAD-HTLC.

Авторы работы «He-HTLC: еще раз о стимулах в HTLC-контрактах» утверждают, что контракты MAD-HTLC также уязвимы для подкупа, если использовать для него TEE или ZKP. В качестве решения авторы предлагают усовершенствование конструкции He-HTLC.

В этих работах рассматриваются проблемы с конструкцией конкретных протоколов, а мы представляем обобщенный анализ, который можно применить к любым транзакциям. И MAD-HTLC, и He-HTLC можно рассматривать как решение общей проблемы удержания с помощью смарт-контрактов, хотя это выходит за рамки данной статьи.

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

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

В работе «CAT и манипуляции с подписью Шнорра II» упоминается, что биржи могут заставить пользователей удерживать средства, требуя от них нескольких подписей для подтверждения транзакции (и как этот метод может быть усилен ковенантами). В этой работе мы и мои соавторы предполагаем, что злоумышленник не участвует в создании транзакции.

3 Спам в мемпуле

Единственный способ цензурировать транзакцию внутри протокола — это предотвратить ее майнинг на уровне мемпула, вытеснив целевую транзакцию из шорт-листа, входящего в следующий блок. В контексте каналов сети Lightning этот метод известен как flood-and-loot («вытеснить и разграбить»).

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

• неясно, когда спамить сеть, поскольку блоки добываются через произвольные промежутки времени;
• иногда один блок сразу следует за другим, в этом случае злоумышленнику нужно заполнить мемпул на несколько блоков наперед, чтобы увеличить шансы на успех, но это также увеличивает затраты на атаку;
• если целевой протокол спроектирован продуманно, жертва может повышать свою комиссию в произвольное время (хотя злоумышленник может к этому приспособиться, особенно если для повышения комиссии используется программное обеспечение с открытым исходным кодом), что может привести к ситуации «выжженной земли».

Затраты на цензурирование одной транзакции на один блок зависит от комиссии за целевую транзакцию (и способности жертвы ее повысить) и места транзакции в мемпуле (а также загруженности мемпула).

Например, если комиссия составляет 200 сатоши, а целевая транзакция находится на #2000 месте в мемпуле, то потребуется 2000 * 200 = 400 000 сатоши, чтобы не пропустить целевую транзакцию в следующий блок.

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

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

4 Прямое обращение к майнерам

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

Это также гарантирует самые низкие затраты на атаку. Хотя неизвестно, насколько нужно переплатить комиссию, чтобы убедить майнера согласиться на такую атаку, теоретически она может стоить всего 1 сатоши сверх комиссии за целевую транзакцию (просто для увеличения прибыли майнера).

Основная проблема такого подхода заключается в невозможности координации действий со всеми майнерами:

• некоторые майнеры анонимны и с ними невозможно связаться;
• неясно, как платить майнерам с минимальным уровнем доверия (одна из сторон должна слепо доверять другой).

5 Использование другого блокчейна

Можно предположить, что смарт-контракты в другом блокчейне (например, Ethereum) достаточно продуманы для реализации TxWithhold в их самом простом виде: они действительно могли бы работать в Ethereum против Ethereum и, вероятно, их можно без труда перенести в блокчейн биткоина, используя смарт-контракт Ethereum, привязанный к статусу SPV (Simplified Payment Verification, упрощенная проверка платежей) в системе биткоина.

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

6 Смарт-контракты TxWithhold

Мы попытаемся объединить главные достоинства описанных выше подходов:

• минимум доверия: майнеры гарантированно получают вознаграждение посредством UTXO (и, возможно, от внешнего оракула);
• для получения вознаграждения майнеры должны «пропустить» только целевую транзакцию, что требует минимум усилий, и, как следствие, минимальных затрат на атаку.

Взаимодействие с майнерами сводится к публичным объявлениям злоумышленника (с использованием досок объявлений) о публикации целевой транзакции (или UTXO), вознаграждении за UTXO и других деталей сделки (например, продолжительности удержания), необходимых для получения вознаграждения UTXO.

Контракты TxWithhold должны предусматривать возврат вознаграждения злоумышленнику, если целевая транзакция будет добыта.

Структура контракта TxWithhold включает два компонента: доказательство того, что транзакция была добыта (или не добыта) и получение вознаграждения. 

Предлагаемая нами система должна работать в системе биткоина в ее нынешнем виде, хотя мы вкратце рассмотрим, какие изменения в системе биткоина позволили бы улучшить смарт-контракты TxWithhold.

6.1 Уровень валидации блока (не работает)

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

Но поскольку Bitcoin Script не позволяет проверять UTXO во время валидации транзакции, на сегодняшний день это невозможно.

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

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

6.2 Доказательство (не)майнинга

Мы нашли два способа, с помощью которых смарт-контракт может «проверить», не была ли добыта целевая транзакция (или не был ли потрачен выход UTXO целевой транзакции), и разблокировать вознаграждение, если условие выполнено.

6.2.1 Оракул, подтверждающий невключение транзакции (DLC)

Злоумышленник может попросить нескольких доверенных оракулов проследить за целевой транзакцией (или UTXO) и предоставить подписи, подтверждающие, что в момент времени T (или в блоке X) транзакция еще не была добыта.

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

Далее злоумышленник публично объявляет об используемых им оракулах и свои условия и создает выход UTXO, который может разблокировать оракул.

6.2.2 HTLC или магия Шнорра (не работает)

Если целевая транзакция заблокирована с помощью хэша, то предварительное изображение, которое раскрывается при ее расходовании, может заменить подпись оракула. В качестве альтернативы можно использовать подпись, необходимую для расходования целевой транзакции (хотя у нас нет точной структуры).

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

Иначе говоря, поскольку транзакция никак не меняется с момента публикации до момента майнинга, на этот метод нельзя положиться.

Но эта идея может быть полезна для оптимизации вознаграждений, о чем мы поговорим позже.

6.3 Предоставление вознаграждения

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

Очевидно, что в Bitcoin Script недостаточно выразительных средств, чтобы четко заявить о том, что «любой майнер, удержавший транзакцию, получит вознаграждение». Даже если изменить формулировку на «любой (доказавший удержание) может забрать средства, если только злоумышленник не представит доказательство включения и не получит средства раньше», проблема не будет решена. 

Поэтому мы рассматриваем потенциальные нетривиальные решения для реализации это метода на Bitcoin Script уже сегодня.

Предлагаемые нами механизмы требуют от злоумышленника создания (как минимум) одного UXO вознаграждения на блок удержания и предоставления некоторых дополнительных данных (например, условных заранее подписанных транзакций).

6.3.1 Объединение участников удержания

Решением для передачи вознаграждения может стать его распределение среди нескольких майнеров. Если предположить, что атака будет достаточно продолжительной (скажем, в течение добычи 100 блоков), то злоумышленник мог бы создать следующую схему вознаграждения UTXO: если оракул подтвердит удержание в последнем блоке, майнеры могут получить вознаграждение, потратив UTXO с использованием заранее подписанной транзакции пропорционально историческому распределению хэшрейта (при этом небольшой процент выделяется для *любого* ключа, что поощряет к участию в удержании анонимных майнеров).

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

Злоумышленник должен подтвердить UTXO, зависимый от подписи оракула, и опубликовать заранее подписанную транзакцию для распределения  вознаграждения. Злоумышленник заранее делает это для каждого блока удержания.Остается открытым вопрос, будут ли анонимные майнеры довольны вознаграждением, получение которого им не гарантировано, даже если они выполнят свою часть сделки.

6.3.2 Один DLC/TX на одного майнера

Злоумышленник может создать N-нное количество (скажем, N=10) UTXO, каждый из которых содержит открытые ключи конкретных майнеров, с соблюдением заданных правил:

• в блоке X майнер добывает нужную транзакцию;
• в блоке X+1 злоумышленник забирает средства обратно, если оракул докажет включение транзакции в блок;
• в противном случае майнер забирает средства в блоке X+1.

В качестве альтернативы этого можно достичь, генерируя один DLC для каждого майнера, отвечающий на вопрос «Добыл ли майнер XYZ последний блок?», в дополнение к DLC удержания.

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

• с помощью ковенанта, который гарантирует, что актив (положительную часть) транзакции может быть востребован только майнером транзакции первого уровня (например, путем просмотра дополнительного входа, добавленного майнером);
• с помощью ковенанта, который гарантирует, что в блоке X+1 забрать средства может только майнер, добывший блок X.

Оба ковенанта могут быть заменены контрактами DLC (Discreet Log Contract, скрытый контракт) хотя мы не уверены, что DLC можно привязать к заранее неизвестному открытому ключу.

7 Обсуждение

Повышение комиссии

Обнаружив удержание, жертва с большой вероятностью увеличит свою комиссию за транзакцию (хотя в настоящее время это не распространено), и смарт-контракты TxWithhold должны предусматривать возможность увеличения вознаграждения. Простейший способ это сделать — подтвердить UTXO другого вознаграждения, хотя это увеличивает затраты на атаку на величину комиссии за транзакцию, которая выплачивается за ее майнинг, что ослабляет позицию злоумышленника.

Эту проблему можно решить с помощью чего-то вроде однонаправленного платежного канала, хотя это потребует от злоумышленника выделения дополнительных средств заранее (что означает альтернативные издержки).

Конфликт интересов в отношении времени выплат

На практике существует такой конфликт интересов:

• злоумышленник обычно заинтересован в удержании типа «все или ничего»: атака должна либо длиться N блоков, либо не начинаться вообще (поэтому он не хочет платить за удержание в течение M<N блоков);
• майнер предпочитает получать оплату за каждый блок, чтобы меньше зависеть от поведения других майнеров (которые могут включить блок позже).

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

Похоже, это потребует усложнения структуры смарт-контрактов, поэтому мы оставляем этот вопрос для будущей работы.

Исключение случайных выплат

Дополнительный оракул, следящий за публикацией целевой транзакции, или манипуляции  с HTLC/подписью Шнорра могут гарантировать, что транзакция была отправлена и была удержана (ведь жертва могла и не отправить транзакцию).

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

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

Контракты TxWithhold вне блокчейна

Если предположить, что майнеры используют известные узлы Lightning, злоумышленник может связаться с ними напрямую, а не публиковать детали контракта на доске объявлений.

В этом случае злоумышленник может даже перевести смарт-контракты на уровень Lightning, незначительно изменив структуру HTLC.

Это снижает нагрузку на инфраструктуру досок объявлений, но в этом случае мы предполагаем, что все майнеры работают на открытых узлах Lightning. Кроме того, это исключает взаимодействие с анонимными/мелкими майнерами, которые могут заглянуть на доску объявлений.

Если это решение использует контракты DLC, то также потребуется один DLC на одного майнера, поскольку контракты, связанные с каждым конкретным каналом, должны быть изолированы.

Форкинг нежелательных транзакций

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

Мы считаем, что создание смарт-контракта, стимулирующего образование микрофорков по отношению к целевой транзакции, эквивалентно созданию смарт-контракта TxWithhold, поэтому все рассмотренные проблемы, аргументы и методы остаются в силе.

8 Заключение

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

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

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

Кроме того, остаются нерешенные проблемы с удобством использования и экономической целесообразностью (для злоумышленников). Некоторые из этих проблем можно «решить» с помощью ковенантов.