Интервью с Polyd: кроличья нора ковенантов

Интервьюер: Амели Хуа, писательница-фрилансер, независимая исследовательница. Х: @AmelieHua

Собеседник: Polyd, специалист по системам управления, обслуживает несколько распределенных систем управления (DCS), работал с другими системами (время безотказной работы 99,999%). Х: @Polyd_

Ковенанты – не новая, но актуальная тема. Еще в 2013 году разработчики начали обсуждать эту тему, и в последние годы было предложено множество BIP, направленных на реализацию ковенантов, что вызвало интенсивные дебаты и сделало эту тему одной из самых обсуждаемых.

Ковенанты заслуживают серьезного обсуждения из-за их мощного потенциала. Считается, что они открывают новые возможности для программирования Биткоина и позволяют использовать смартконтракты. Для Биткоина это, несомненно, палка о двух концах. В этой статье мы рассмотрим, что такое ковенанты, как они работают, их надежную функциональность и их значение для Биткоина. При обсуждении деталей в этой статье в качестве примера часто используется CTV, но CTV – не единственный метод реализации ковенантов.

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

1.

Амели: Прежде чем перейти к ковенантам, давайте проясним два вопроса, связанных с Биткоином, что поможет нам лучше понять ковенанты.

Мы знаем, что Биткоин использует язык сценариев, и известно, что языки сценариев поддерживают реализацию смартконтрактов. Однако на самом деле смартконтракты не были реализованы в мейнчейне Биткоина. Это создает ощущение, что реализация смартконтрактов в Биткоине сталкивается с некоторыми непреодолимыми препятствиями в сети Биткоина.

Однако многие могут не знать, что, хотя Биткоин можно запрограммировать с использованием языка сценариев, набор кодов операций крайне ограничен. Этот ограниченный набор кодов операций ограничивает возможности программирования Биткоина, а это означает, что, хотя язык сценариев может реализовывать смартконтракты, у программистов нет достаточных «инструментов» для реализации смартконтрактов.

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

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

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

С тех пор BCH преодолел это ограничение в своем собственном скрипте, показав, что скрипт не так слаб, как все предполагают, просто Биткоин всегда был медленнее из-за его децентрализации, а координация практически невозможна, за исключением длительных периодов времени. Также есть Taproot и Tapscript, которые облегчат многие проблемы, связанные с занимаемым пространством, и позволят использовать новые варианты взаимодействия, такие как BitVM, путем объединения контракта в подпись и его раскрытия только при необходимости.

Амели: Почему существуют строгие ограничения на коды операций? Можем ли мы использовать OP_CAT в качестве примера, чтобы прояснить этот момент?

Polyd: Итак, OP_CAT обманчиво прост: он берет две строки и складывает их вместе. Первоначально он был отключен, потому что у него были проблемы с ресурсами и он мог быть использован для сбоя узлов. Но я не уверен, что это полная история, поскольку Сатоши установил ограничение стека в 520 байт и отключил OP_CAT в том же коммите, так что это может быть нечто большее, чем просто истощение ресурсов.

Вот краткий список того, что может выполнять OP_CAT: ковенанты CTV/TXHASH, проверка доказательств SPV, защита от двойного расходования для TX 0-conf, 64-битная арифметика, хранилища, квантово-устойчивые подписи. Этот список можно продолжить: только OP_CAT может эмулировать транзакции в стиле CTV[CheckTemplateVerify] и TXHASH. Единственная проблема заключается в том, что он крайне неэффективен в том, как он выполняет эти действия, а это может сделать эти транзакции непопулярными, за исключением крупных пользователей, таких как хранители.

2.

Амели: Поговорим об еще одном «ограничении» Биткоина. Биткоин поддерживает только «верификацию» как форму вычислений и не может выполнять вычисления общего назначения.

Мы также знаем, что, например, смартконтракты на Ethereum содержат правила перехода состояний. Он завершает переход состояния посредством вычислений, обеспечивая функциональность смартконтрактов. Для сравнения, Биткоин не может выполнять вычисления общего назначения, то есть он не может самостоятельно осуществлять переходы между состояниями посредством вычислений. Правильно и я понимаю?

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

На самом деле я не такой уж большой поклонник того, как работает Ethereum. Из-за его вычислительной природы и встроенной проверки, если я попытаюсь совершить сделку, мое окно может сдвинуться, и у меня не получится торговать. Однако моя транзакция с попыткой торговать все еще будет действительна, поэтому мне все равно придется заплатить комиссию, тратя блоковое пространство для кого-то другого. Еще один странный аспект – оракулы в Ethereum. Оракулы должны платить газ, чтобы обновить цены, тогда как в Биткоин-DLC оракул просто предоставляет подпись и не может быть «закреплен» из-за изменения комиссий, а также не может быть нацелен на конкретные контракты.

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

3.

Амели: Давайте теперь обсудим ковенанты. Что это такое?

Polyd: Ковенантами (covenants) обычно называют ограничения на передачу монет. Слово «covenant» (с англ. соглашение, обязательство) уже несет в себе некую коннотацию, что помогает объяснить его как простые механизмы блокировки для вашей *собственной* монеты.

Внутри Биткоина уже есть два ковенанта, и они поддерживают сеть Lightning Network: CSV [CheckSequenceVerify] и CLTV [CheckLockTimeVerify]. Некоторые просто называют эти коды операций «примитивами смартконтрактов», поскольку они представляют собой простые блокировки по времени.

CTV [CheckTemplateVerify] – это предлагаемое обновление Биткоина, включенное в BIP 119. Оно отличается от CSV и CLTV. CTV можно описать как «блокировку TXID [Transaction ID]» или «блокировку UTXO», только эти TXID могут быть созданы из этой блокировки. Для CTV мы называем эту блокировку TXID «соглашениями о равенстве», поскольку результирующие транзакции должны быть равны исходным транзакциям, которые были зафиксированы. Его также называют соглашением об отсрочке обязательств, поскольку вы можете видеть, что ваш UTXO был принят, но еще не размещен в цепочке.

Наиболее известной альтернативой является SH_APO [любой предыдущий выход или AnyPrevOut], который обеспечивает обязательство по выплате, одновременно позволяя гибкие методы внесения. Обсуждаются также несколько других: OP_CCV [также известный как MATT], OP_EXPIRE, TXHASH и TEMPLATE KEY.

Амели: Когда вы говорите, что «ковенанты обычно относятся к ограничениям на передачу монет», можно ли понимать это так: ковенанты – это метод определения того, как можно использовать средства, или, другими словами, это способ ограничения того, где средства могут быть потрачены.

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

Когда UTXO создается ончейн, мы инстинктивно предполагаем, что этот UTXO хранится с помощью одного закрытого ключа. Но если это был UTXO, связанный с CTV, то когда UTXO будет потрачен, вы увидите дополнительный 32-байтовый хеш в паре с новой транзакцией, который представляет скрытое состояние внутри исходного UTXO.

Амели: Вы несколько раз упомянули «блокировку TXID/блокировку UTXO». Можно ли сформулировать это так: чтобы понимать, как CTV реализует свою функциональность, нужно понимать, что такое блокировка TXID и как она работает. Блокировка TXID – это ключевой механизм.

Polyd: Да, она создает прочную основу для построения дальнейших схем. TXID определяется содержимым tx. И если вы можете добавлять входные данные в tx, вы можете манипулировать TXID. CTV позволяет заблокировать количество входов и выходов. Таким образом можно гарантировать, что обязательства CTV не требуют доверия. Если бы TXID был податливым, вы потенциально могли бы украсть чьи-то средства. Если у вас есть механизм блокировки TXID, вы объединяете его с другими механизмами блокировки, такими как временные блокировки, для создания еще более эффективных смартконтрактов.

4.

Амели: Как вы думаете, почему ковенанты – это кроличья нора?

Polyd: Я называю ковенанты кроличьей норой, потому что с помощью простых ограничений на транзакции, таких как блокировка по времени или блокировка TXID, можно сделать очень многое. Нам удалось построить всю сеть Lightning с помощью простых блокировок по времени, и хотя она не идеальна, это единственная существующая по-настоящему децентрализованная сеть второго уровня. Мне не нравится, как все постепенно смещается в сторону кастодиального контроля, но именно поэтому я и начал спуск в эту кроличью нору: чтобы сделать смартконтракты более мощными. Мы называем блокировку TXID шаблоном. С Taproot мы получили возможность агрегировать подписи. Благодаря шаблонам и CTV мы получаем возможность агрегирования транзакций.

CTV служит заменой предварительно подписанному оракулу транзакций, что устраняет требования к доверию и интерактивности, необходимые для создания более сложных смартконтрактов, необходимых для таких вещей, как хранилища и платежные пулы. Хранилища и пулы, которые вы можете создать с помощью CTV, сегодня технически возможны, но в настоящее время они исключены из-за доверия или интерактивности, необходимых для их работы. Более того, с помощью CTV мы можем создавать фабрики каналов, дополнительные решения второгоуровня, такие как Ark, Timeout-Trees, Stakechains или Surfchains, а также решения JIT Fidelity Bond, такие как PathCoin.

Вероятно, моя любимая функция – это неинтерактивные каналы [NIC], которые мы также называем холодными каналами. Основная идея состоит в том, чтобы взять обычный канал Lightning и просто поместить его в шаблон CTV. Что отличает его от обычного канала Lightning, так это то, что ни одной из сторон на самом деле не нужно было находиться в сети для создания этого канала. Поэтому, если мне нужен канал с другим человеком, не нужно, чтобы он был онлайн, чтобы создать канал; мне даже не нужно говорить, что я это сделал, пока я не буду готов потратить из него деньги! Это позволяет использовать возможность холодного хранения на Lightning Network, поскольку мне не нужен узел для защиты моих средств в каналах, которые еще не активны. Сторонние координаторы также могут установить неинтерактивные каналы для двух человек, что обеспечивает большую гибкость в возможностях.

В нынешнем виде CTV не позволит создавать DEX ончейн, но я не думаю, что это так уж плохо, поскольку люди в настоящее время пытаются создать DEX оффчейн, используя Lightning Network, как это происходит сегодня. Я думаю, что это связано с дискуссией «Верификация против вычислений». Единственное, что меня беспокоит в отношении ончейн DEX, помимо чрезмерных обновлений в сети, приводящих к более высоким комиссиям, – это MEV (извлекаемая майнерами ценность). Мы уже заметили некоторую MEV от транзакций DEX BCH, и по мере развития рынка ситуация обязательно ухудшится.

Амели: Можете ли вы привести пример, который поможет нам понять, как работает CTV?

Polyd: Допустим, я должен получить 5 BTC, и на данный момент единственное, что я могу сделать, это получить платеж и проверить его в сети. С помощью CTV я могу свести все к простому публичному ключу, который я даю своему плательщику. Детали остаются конфиденциальным для всех, кроме меня. Как только я смогу подтвердить, что мне заплатили, все действия, которые я предпринял с использованием шаблона CTV, также вступают в силу.

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

Если бы это был общий UTXO с несколькими людьми, мы могли бы совместно закрывать наши транзакции, еще больше сокращая количество ончейн-транзакций.

5.

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

Polyd: Если мы вновь введем OP_CAT, я думаю, это позволит реализовать практически все возможные типы соглашений, поскольку можно будет эмулировать любую форму интроспекции для TXHASH. Более ограниченным методом было бы введение кодов операций, представляющих явное поведение, как в случае с CTV, CSFS или CheckSeperateSignature. CTV – это возможность делать отложенные выводы. CSFS – это возможность делать отложенные подписи, чтобы вы могли отложить сам платеж. Они звучат похоже и хорошо работают вместе как строительные блоки, обеспечивающие LN-симметрию, но обязательства выполняются на разных уровнях.

TXHASH и TEMPLATE KEY позволяют осуществлять интроспекцию и служат одной и той же цели, но TEMPLATE KEY использует однобайтовый режим, а TXHASH использует многобайтовые флаги. Это открывает гораздо более мощные возможности внутри скриптов и смартконтрактов, но многие обеспокоены возможными побочными эффектами. TXHASH и TEMPLATE KEY – это скорее CTVv2, который сделает CTV более мощным и выразительным.

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

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

Многие разработчики следят только за Lightning и за ее развитием. Они склонны отдавать предпочтение таким кодам операций, как SH_APO, поскольку он обеспечивает LN-симметрию. Многие разработчики, которым не особенно нравится Lightning из-за ее ограничений, таких как ограничения входящей ликвидности или требования быть онлайн, они отдают предпочтение таким кодам операций, как OP_CAT, TXHASH, как более выразительным решениям масштабирования. Разработчики, которые предпочитают CTV, более нейтральны и смотрят на это с системной точки зрения. Это значительно расширяет возможности каждого делать то, что он предпочитает, не создавая при этом рисков, которые невозможно измерить.

6.

Амели: Перед обсуждением ковенантов мы говорили о проблемах, связанных с кодами операций в языке сценариев, и о проблеме ограниченных вычислений, приводящих к переходу состояний. Мы уже знаем о взаимосвязи между ковенантами и операционными кодами. Теперь давайте углубимся в проблему перехода состояний. Я не уверена, что рассматривать ковенанты с точки зрения «перехода состояний» правильно, но эта перспектива действительно увлекательна.

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

Polyd: Ковенант – это шаблонная оболочка или «состояние». Внутри него вам нужно будет создать блокировки по времени и другие функции, чтобы обеспечить желаемую функциональность, будь то хранилище, канал Lightning или какое-либо другое решение второго уровня.

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

Хорошей темой для рассмотрения является Ark. Это гигантский смартконтракт, почти как гигантский coinjoin: тот, кто запускает протокол, создает новое состояние [или раунды, как его называют] каждые несколько секунд, чтобы участники могли платить другим по мере необходимости. Как только оператор Ark будет готов, он отправит транзакцию в мемпул, чтобы зафиксировать текущее состояние в цепочке. Эти заполнители в цепочке можно рассматривать как «переходные состояния». Оператору приходится постоянно пересчитывать новые состояния, чтобы представить их участникам Ark, и то, что отправляется в цепочку, является проверкой этого состояния.

Амели: Можно ли сказать, что ковенанты реализуют форму смартконтракта, основанную на проверке, а не на вычислениях?

Polyd: Да. Определенно. Этот смартконтракт просто сравнивает транзакцию с соответствующим хешем sha256. Проверка скорости блока фактически увеличится, поскольку нет никаких операций с подписью.

Амели: Одним из направлений развития блокчейнов является модульность, включая вычисления вне цепочки. Похоже, что Биткоин естественным образом создан для вычислений вне цепочки. Что вы думаете по этому поводу?

Polyd: Время – плоский круг. Кажется, мы прошли полный круг к тому, чего хотят от блокчейна. Но похоже, что у Биткоина все еще есть некоторые проблемы с модульностью и размером. Мне бы хотелось, чтобы у нас были лучшие сайдчейны, которые были бы не просто решениями с несколькими подписями, а использовали бы настоящие криптографические средства для защиты средств и позволяли бы односторонние выходы. Я думаю, что это поможет расширить границы модульности Биткоина. Taproot позволил проводить еще больше вычислений вне цепочки с помощью таких решений, как BitVM, что позволило бы нам вычислять практически все что угодно вне цепочки. Но, к сожалению, он не может эмулировать такие вещи внутри Биткоина, как CTV, так что, похоже, нам еще есть куда развиваться.

7.

Амели: Каких возможностей можно достичь путем объединения ковенантов с другими кодами операций, такими как DLC?

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

8.

Амели: Есть ли еще какие-то моменты, о которых вы хотели бы рассказать читателям?

Polyd: Мы рассмотрели множество концепций. Мы коснулись вопроса, как можно смягчить чрезмерный спрос на блоковое пространство и потенциальные DDoS-атаки. Мы обсудили, как можно экономить место, создавая неинтерактивные каналы. Я думаю, что еще один хороший вопрос для обсуждения – это «проблема выхода второго уровня». Если бы нам удалось вывести всех из базового уровня и переместить их на большой второй уровень, в настоящее время не существует хорошего способа ускорить вывод людей из этого второго уровня. В качестве второго уровня может послужить Lightning [мы называем потенциальный массовый исход из Lightning «проблемой громового стада»] или можно рассмотреть Coinbase, Binance или Liquid. На Coinbase миллионы людей, и я понятия не имею, как вывести их оттуда на Биткоин каким-либо упорядоченным образом в сегодняшних условиях. Попытка вывести людей из биржи приведет к задержке в мемпуле на 6 месяцев. CTV может это исправить.

Можно создать Ark или дерево тайм-аутов с помощью CTV. Биржа могла бы даже предлагать эту услугу напрямую. Каждый мог бы перейти из «общего UTXO» в соответствии с консенсусом Coinbase на «общий UTXO» с консенсусом по своему выбору, будь то простой пул или большое дерево тайм-аутов. Вот тут уж совсем мозг плавится, это был бы чистый переход L2L2. Не было бы никакого промежуточного шага, требующего сначала спуститься на базовый уровень. И я мог бы продолжать повторять этот процесс бесконечно, используя любой уровень по своему выбору. Нет необходимости возвращаться на базовый уровень, кроме как, например, из-за отказа от сотрудничества с моим каналом или, возможно, удаления из моего хранилища. Недостаток Ark и дерева тайм-аутов заключается в том, что у них есть требования к переносу средств: вам придется перемещать свои средства каждые несколько недель или месяцев, иначе вы их потеряете. Это не идеальное решение для долгосрочного хранения, но оно отлично работает для краткосрочного хранения и более крупных рынков.

Я хотел бы привести полный список всех концепций, которые были разработаны с использованием опкода CTV и его способности агрегировать предварительно подписанные транзакции: Non-Interactive Channels, Timeout-Trees, Ark, Darkpools, Payment Pools, Payment Channels, Ball Lightning, Congestion Control, Dpool's, Compaction, Tree Swaps, PathCoin, Stakechains, Surfchains. Это не независимые шаблоны: если у одного из них есть функция, которую вы хотите включить в другой шаблон, вы можете создать свой собственный шаблон.

Это гостевой пост Амели Хуа. Высказанные мнения являются ее собственными и не обязательно отражают точку зрения BTC Inc. или Bitcoin Magazine.