Аннотация. В этой статье мы рассматриваем и объясняем предлагаемое обновление софтфорка биткоина, OP_CTV (Check Template Verify). Эта функция позволит пользователям фиксировать обязательства по расходованию выхода биткоина только в определенных условиях. Главный сторонник этого софтфорка, Джереми Рубин, недавно анонсировал скорый выпуск нового клиента с параметрами активации OP_CTV (смелый шаг!). Мы обсуждаем с Джереми предложенные механизмы активации софтфорка и задаем вопросы о самых спорных аспектах его предложения.
Вкратце об OP_CTV
Обновление OP_CTV (Check Template Verify) позволяет создать биткоин-адрес, связанный с хэшем обязательств некоторых компонентов потенциальной будущей транзакции, в первую очередь, с выходами транзакций. Этот хэш обязательств обычно раскрывается при погашении средств в поле свидетеля вместо цифровой подписи, и раскрытие хэша является разрешением на трату средств. Таким образом, если на этот адрес отправляются монеты, средства могут быть потрачены только при выполнении определенных условий — условий, которые уже зафиксированы в хэше. Такую схему иногда называют ковенантом.
Это относительно простое обновление, которое может расширить функционал биткоина с минимальными рисками, поэтому у этой идеи множество сторонников. Для работы OP_CTV нужен новый ОР-код (точнее, ужесточение условий, связанных с существующим неиспользуемым ОР-кодом, который Сатоши добавил в 2010 году), поэтому это обновление считается софтфорком протокола биткоина. ОР–код, о котором идет речь, — OP_NOP4.
Пробное использование и примеры
Тестовая сеть OP_CTV уже запущена. В приведенном ниже примере транзакции используется OP_CTV. Транзакцию, предшествующую этой, можно рассматривать как транзакцию обязательства. 15,00003992 BTC (в тестовой сети) были отправлены на адрес tb1qmce….vs4627. Средства можно было получить, только указав скрипт OP_CTV в поле свидетеля. Он содержит ОР-код «OP_NOP4» и следующий хэш обязательства:
a9a39b05196b80c94936432f6e59242e504a9c394e083da34adf6aaef5b29d2a
Источник: https://explorer.ctvsignet.com/tx/62292138c2f55713c3c161bd7ab36c7212362b648cf3f054315853a081f5808e
Хэш выходов и некоторые другие данные транзакции должны совпадать с этим значением. Это совпадение служит разрешением на выполнение транзакции, поэтому для авторизации трат не требуется цифровая подпись или закрытый ключ. Если хэш не совпадает, транзакция считается недействительной в соответствии с новыми предложенными правилами софтфорка.
В таблице ниже показано, какие компоненты транзакций с биткоином могут изменяться, а какие — нет, после использования хэша обязательств.
|
Данные транзакции, зафиксированные хэшем |
Данные транзакции, которые могут измениться |
|
|
Контроль загруженности сети
Самый популярный вариант использования OP_CTV, на котором мы и сосредоточимся в первую очередь, — для контроля загруженности сети. Возможно, это не самая полезная функция OP_CTV, но именно на ее примере можно лучше всего объяснить, как работает OP_CTV. Допустим, криптовалютная биржа хочет выполнить массовый вывод средств сразу нескольким клиентам (один вход и много выходов). Но комиссии на рынке очень жесткие, и биржа не хочет платить высокую комиссию. Поэтому биржа использует OP_CTV и создает две транзакции:
- Отправляет средства на один выход в транзакции с обязательствами и
- Расходует отправленные монеты в транзакции с несколькими выходами.
Транзакция 1 имеет небольшой размер, поэтому быстро подтверждается за небольшую комиссию. Транзакция 2 передается в пул памяти (обычно после подтверждения транзакции 1), так что клиенты биржи потенциально могут видеть транзакцию и выходы (суммы), которые они должны получить. Поскольку транзакция с обязательствами подтверждена, клиенты биржи знают, что они гарантированно получат средства или, по крайней мере, что биржа не сможет потратить их дважды. Через некоторое время, когда комиссия на рынке снизится, транзакция 2 подтверждается, и все получают свои деньги.
Считается, что система софтфорка OP_CTV превосходит альтернативы RBF и CPFP по следующим причинам:
-
Из транзакций OP_CTV можно построить дерево таким образом, чтобы хэши всех транзакций были привязаны к исходному хэшу обязательств в дереве Меркла. Подветви этого дерева могут иметь разные ставки комиссии (например, у клиентов с более высоким приоритетом комиссия может быть более высокой). С другой стороны, при пакетной RBF-транзакции все выходы должны иметь одинаковую ставку комиссии, что считается недостатком традиционной пакетной обработки
-
До тех пор пока первоначальная транзакция обязательств не подтверждена, биржа может продолжать добавлять новые выходы в структуру и заменять первоначальную транзакцию с помощью RBF. Без использования OP_CTV такая замена пакетной транзакции неосуществима, поскольку минимальное увеличение комиссии применяется ко всем выходам, и как следствие транзакция становится непомерно дорогой.
Несмотря на эти преимущества, на наш взгляд, контроль загруженности сети не кажется таким уж весомым аргументом для внедрения софтфорка, и вот почему:
- Текущие ставки комиссии на рынке нестабильны.
- Маловероятно, что условия на рынке комиссий изменятся достаточно сильно в течение периода, когда эта система будет актуальна, чтобы она стала полезной.
- Многие клиенты бирж хотят быстро получить средства, а не знать, что биржа обязуется их выплатить.
- Биржи недостаточно озабочены этим вопросом, чтобы начать использовать такое сложное решение.
- У нас уже естьдва метода ускорения транзакций: Replace-By-Fee (RBF) и Child pays for parent (CPFP).
- Насколько мы можем судить, транзакции OP_CTV будут рассматриваться клиентами как нестандартные. Поэтому владельцы кошельков, которые не установят это обновление, могут не увидеть входящую транзакцию до ее подтверждения, и таким образом преимущества предлагаемой системы не будут реализованы до тех пор, пока пользователи не обновят свои кошельки. Это кажется существенным потенциальным недостатком.
- Новый софтфорквводит новый класс входящих транзакций, и теперь у нас будет три класса транзакций: i. Подтвержденные, ii. Находящиеся в пуле памяти и iii. Зарезервированные с помощьюOP_CTV. Этот новый статус транзакции повышает сложностьпроцесса для пользователей, которые вряд ли смогут его понять.
Несмотря на наше скептическое отношение к эффективности софтфорка как средства контроля загруженности сети, OP_CTV—простое обновление, которое потенциально может повысить функционал и гибкость системы с минимальным риском. OP_CTV может добавить функции, о которых мы пока даже не знаем. Контроль загруженности сети следует рассматривать только как примерную функцию. Если учесть все это, становится понятна популярность предлагаемого обновления в техническом сообществе.
Хранилища
Возможно, более убедительным примером использования OP_CTV, имеющим большуюпрактическую пользу, являются хранилища. Мы хотим, чтобы биткоин внутри хранилища отправлялся на определенные адреса только при соблюдении определенных условий. Сейчас этого можно достичь с помощью предварительного подписания транзакций и последующего уничтожения закрытых ключей. Но факт уничтожения закрытого ключа может быть трудно доказать. При использовании OP_CTV ограничения действий, которые можно выполнять со средствами в хранилище, обеспечиваются самими правилами консенсуса биткоина, а не связанным с многочисленными проблемами хранением заранее подписанных транзакций. Трудно представить, как добиться такой возможности в системе биткоина без обновления вроде OP_CTV.
Пожалуй, наиболее полно и интересно этот потенциальный вариант использования описан в статье Джеймса О’Бирна.
Суета с софтфорками
17 апреля 2022 года самый значимый сторонник OP_CTV, в прошлом получатель гранта BitMEX Джереми Рубин, в своем блоге предложил параметры активации софтфорка и анонсировал планы по выпуску клиента активации. Если верить блогу, сборка программного обеспечения для клиента активации будет выпущена в воскресенье, 24 апреля 2022 года, или раньше. Этот неоднозначный шаг Джереми вызвал ожесточенные споры и море комментариев на форумах разработчиков системы биткоина. Поэтому мы решили взять у Джереми интервью и задать ему несколько непростых вопросов об активации OP_CTV.
Интервью Джереми Рубина в связи с активацией софтфорка
Период сигнализации начинается 5 мая 2022 года, всего через две недели после того, как вы опубликовали предложенный график активации. Почему бы не оставить хотя бы несколько месяцев между объявлением предлагаемых параметров активации и началом окна активации?
На самом деле ситуация обстоит не совсем так. Я анонсировал аналогичный график в декабре 2021 года. Он обсуждался и на встрече CTV 11 января, где я получил некоторую поддержку активации весной. На последующей встрече, 13 января, было высказано желание не проводить слияние с Core, а все мейнтейнеры негласно отказались отвечать на вопросы о том, что делать.
Одна из главных проблем с переносом активации на несколько месяцев в том, что — это мое мнение — у биткоина есть «реалистичные окна релизов» софтфорков, которые показывают, что для активации подходят только весна/осень — мы не хотим, чтобы сигнальный период или активация пришлись на День благодарения, Рождество, Новый год, китайский Новый год, День святого Валентина (шучу, если вы читаете этот пост, вы задрот, обреченный на вечное одиночество) и налоговые дни (в США это 15 апреля, в Китае — 31 марта…), потому что в это время не все могут посвятить все внимание процессу сигнализации или активации. Получается, активацию следует проводить в период с мая по начало ноября, и если мы хотим по-быстрому опробовать обновление в реальных условиях, то сигнализация должна проводиться раньше, а активация — позже. Поэтому, если в этом году сеть биткоина предпочтет формат Speedy Trial и CTV, то выбранные параметры, вероятно, совпадут с моими; не думаю, что кому-то важны фактические числа для нумерологии. Но если мы захотели бы отказаться от Speedy Trial (и, возможно, это не проблема?), мы могли бы оставить достижение минимального активного уровня (высоты) в ноябре и начать сигнализировать, например, 1 августа. Думаю, все равно все прошло бы нормально, просто иначе, чем с Taproot.
Кстати, если память мне не изменяет, параметры релиза Taproot были определены до выхода самого релиза.
Процесс начался 24 апреля 2021 года, а версия 0.21.1 вышла 29 апреля. Сами параметры активации были предложены (как PR к коду и BIP) 13–14 апреля, то есть всего за 10 дней до начала сигнализации.
Может быть, стоило бы сначала попытаться ввести код OP_CTV в Bitcoin Core без активации, а уже после работать над методологией активации (либо в Core, либо в других клиентах)? Разве не так проводилась активация Taproot и SegWit? Почему в этот раз все по-другому?
Мейнтейнеры не давали мне никаких указаний относительно того, какими должны быть критерии принятия, поэтому, пока нет ясности в этом вопросе, у меня сложилось впечатление, что в дальнейшем предпочтение будет отдаваться консенсусным изменениям, не затрагивающим Core.
Как вы считаете, некоторые люди выступают против активации OP_CTV из-за того, что вы, его автор и главный сторонник, — относительно молодой разработчик, если сравнивать с авторами предыдущего поколения софтфорков (сейчас они в основном неактивны)? Возможно, это символизирует «уход старой гвардии», что трудно пережить некоторым биткоинерам?
На днях мне кто-то сказал, что пытался объяснить механизм CTV одному из старожилов, кому-то «важному», кто не хотел разбираться в этом вопросе только из-за неприязни ко мне.
Кроме того, меня нельзя назвать «новичком» в биткоине — я изучаю его с 2011 года и начал заниматься разработкой продуктов для Bitcoin Core году в 2015-м. Так что вопрос в том, по сравнению с кем я «молодой»? Кто те суперактивные участники сообщества, которые тратят время на подобные сравнения?
Допустим, вы увидели предложение CTV. Имена каких разработчиков должны за ним стоять, чтобы вы его приняли? Понизили бы вы свои стандарты из-за чьей-то громкой репутации?
И разве «старая гвардия» не несет ответственность за состояние сети, если уходит на покой или больше не активна? Разве она не должна «передать эстафету»?
Что нас ждет, если технологи будут разбираться в технологии недостаточно хорошо, чтобы ее воспроизвести?
Если мы не ответим на эти вопросы и не улучшим наши инженерные компетенции, сеть биткоина закоснеет, и плоды этой косности могут оказаться ядовитыми. Да, мы работаем над тем, чтобы сделать биткоин еще более надежным, но горькая правда в том — независимо от того, кого вы поддерживаете — что ВТС очень и очень далек от совершенства. И когда «люди, которые его создали» окончательно отойдут от дел, если следующее поколение не будет обладать такими же навыками, биткоин превратится в систему, которой мы просто доверяем, но не проверяем…
Заключение
Насколько мы можем судить, большинство пользователей поддерживают OP_CTV или аналогичную технологию, так как она достаточно проста в реализации и требует минимальных изменений в коде консенсуса. Но есть и критики, и они, похоже, делятся на две категории:
- те, кто считает, что в активации обновления нет срочной необходимости из-за ограниченного спроса или ограниченных вариантов использования,
- те, кто считает, что в будущем может появиться или должно быть принято альтернативное решение-ковенант.
Как бы кто ни относился к самому обновлению OP_CTV, система и сроки его активации неизбежно вызовут массу споров; маловероятно, что техническое сообщество придет к согласию по этому вопросу — по крайней мере, в ближайшие 6 месяцев или около того.
Например, разработчик сети биткоина Мэтт Коралло объяснил свое решительное несогласие с позицией Джереми в рассылке для разработчиков биткоина от 21 апреля 2022 года:
«Учитывая различные предложения по ковенантам, которыми изобилует биткоин-пространство, а также тот факт, что мы пока находимся на очень ранних стадиях их согласования, а техническое сообщество ВТС (или, по крайней мере, те, кто хочет работать над ковенантами) даже не собираются объединиться вокруг какого-нибудь конкретного предложения, говорить о «прогрессе в отношении CTV», активации CTV или изобретении какого-то способа впихнуть его в биткоин на этом этапе — оскорбительно, глупо и недальновидно. Хуже того, это создает невероятно плохой прецедент нашего отношения к изменениям системы биткоина и поддержанию его культуры безопасности и тщательной разработки. Я потрясен тем, что мы вообще это обсуждаем, и еще больше удивлен тем, что (техническое) биткоин-сообщество не отвергло эту идею еще более резко и категорически».
В настоящее время неясно, будет ли предложение Джереми по активации успешным или получит ли сколько-нибудь значимую поддержку. Как бы там ни было, он определенно готов рискнуть и не боится спровоцировать скандал из-за правил консенсуса в сети биткоина. Как выше заметил Джереми, сейчас самое время для такой суеты. В конце концов, приближается лето.