С точки зрения программирования приложений Bitcoin, подробно объясняется программирование CKB.

Следующий контент взят из форума Nervos Talk, автор Ajian (главный редактор платформы по контенту о биткойне BTC Study).

Резюме

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

1. Введение

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

Система смарт-контрактов имеет следующие структурные особенности:

• Базовая форма выражения состояния (контракт) (счет vs. выходной транзакции)
• Разрешить ли произвольные вычисления в программировании (вопрос связан с понятием "Тьюринг завершенности")
• Может ли процесс выполнения создавать новые данные или только возвращать логическое значение? (Вычисление против проверки)
• Разрешено ли записывать дополнительное состояние в контракте
• Может ли контракт получить доступ к состоянию другого контракта во время выполнения

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

Приведу пример: люди часто используют Ethereum как пример хорошей программироваемости, но основной формой выражения состояния Ethereum является счет, который сложно программировать для точка-точку контрактов (например, платежные каналы, парные контракты на ставки) - это не абсолютно невозможно, просто неэффективно. В экосистеме Ethereum были проекты, пытающиеся реализовать платежные каналы/каналы состояния, также было много теоретических исследований, но на сегодняшний день эти проекты, кажется, неактивны - это, очевидно, не из-за недостаточных усилий разработчиков. Сегодня проекты, активные на Ethereum, используют форму "финансового пула", а не форму "точка-точка контрактов", и это не случайно. Точно так же, возможно, люди удовлетворены программироваемостью Ethereum, но для реализации "абстрагирования счета" (также можно понимать как обобщение понятия кошелька), модель счета, можно сказать, изначально недостаточна.

Таким образом, изучение программирования CKB также требует понимания структурных особенностей системы смарт-контрактов CKB в этом аспекте. Как известно, CKB позволяет программировать произвольные вычисления, позволяет записывать дополнительное состояние в контракте, а также позволяет контракту при выполнении получить доступ к состоянию другого контракта. Однако форма его контракта является выходом транзакции (называемым "Ячейкой"), что приводит к фундаментальным различиям с Ethereum. Поэтому понимание системы смарт-контрактов Ethereum и примеров контрактов в ней не поможет нам понять, как CKB реализует эти структурные особенности, и не поможет нам понять программирование CKB.

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

二. CKB v.s. BTC：лонг了什么？

Основная структура

В качестве основной формы выражения состояния биткойна, UTXO (невыполненный вывод транзакции) биткойна имеет два поля:

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

По сравнению с более поздними системами смарт-контрактов, скрипт биткойна довольно ограничен:

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

Этот сценарий, хотя и ограниченный, обладает способностью создавать удивительные приложения программирования и является основой для исследования программной возможности CKB. В следующем разделе будет представлены два примера программирования сценария Bitcoin.

Соответственно, структурный элемент CKB называется "ячейка" и имеет четыре поля:

• Capacity, подобно сумме UTXO, выражает размер пространства, которое может занимать данный Cell, в байтах (Bytes);
• Lock, похожий на UTXO, скрипт открытого ключа, определяет владение этой ячейкой; только предоставленные данные могут обновить эту ячейку через Lock (или освободить эту ячейку и использовать эту ёмкость для майнтинга новой ячейки);
• Данные, данные, любые данные, их объем ограничен Capacity;
• Тип, необязательный сценарий, используемый для установки условий обновления данных.

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

Читателю легко заметить, что Cell в сравнении с UTXO улучшает программную возможность:

• Cell может программировать любые вычисления, а не только определенные; его проверка прав собственности будет более гибкой;
• Из-за полей Data и Type, Cell может записывать дополнительное состояние, что позволяет Cell нести так называемый "UDT (пользовательский токен)".

结合 Cell 本身的 “交易输出” 结构，这两点本身能带来的好处已然非常非常巨大，但是，仅从上面的描述，我们尚不知晓 Cell 是如何实现 “一个合约在运行时访问另一个合约的状态” 的。为此，我们需要借助比特币社区探讨了很长时间的一个概念：“限制条款（covenants）”。

Условия ограничения и самопросмотр

Оригинальный текст: "Ограничение смысла ограничения того, куда может быть потрачены деньги. В текущей реализации биткойна (пока не внедрены предложения об ограничениях), как только средства разблокированы, их можно потратить куда угодно (их можно перевести на любой открытый ключ сценария). Но идея ограничения заключается в том, что можно как-то ограничить их использование только на определенные места, например, один UTXO может быть потрачен только одной транзакцией, так что, даже если кто-то сможет подписать этот UTXO, куда его потратить уже решено этой транзакцией. Эта функция выглядит немного странно, но может привести к некоторым интересным применениям, о которых будет специальная секция позже. Важно, что это ключ к дальнейшему пониманию программирования CKB."

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

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

基于此，我们又可以将这种完全的内省能力分成四种情形：

• Чтение блокировки других (вводных и выходных) блокировок
• Чтение типа (и данных) других (входных и выходных)
• Тип 01928374656574839201 других (ввода и вывода) блокировки
• Введите другой (ввод и вывод) типа (и данные)

Это позволяет нам анализировать роль интроспективных возможностей каждой части в различных сценариях применения на основе некоторых предположений (разделение функций Lock и Type) и анализировать преимущества программирования, которые каждая часть приносит нам.

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

Три. Программирование скриптов биткойна

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

OP_IF и "Сделка обязательства"

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

Согласно примеру известного контракта "Хэшированный контракт TimeLock (HTLC)", этот сценарий можно перевести на понятный язык как:

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

В противном случае, Алиса может потратить эту сумму после времени T, предъявив свою собственную подпись.

Эффект "либо ... либо ..." достигается с помощью операции управления потоком.

HTLC самое выдающееся преимущество заключается в том, что оно может объединять несколько операций вместе и обеспечивать их атомарность. Например, Алиса хочет обменяться с Бобом CKB на BTC, поэтому Боб может сначала предоставить хэш-значение и создать HTLC на сети Nervos Network; затем Алиса создает HTLC на биткоине с использованием того же хэш-значения. Либо Боб забирает BTC, которые заплатила Алиса, и одновременно раскрывает хеш-значение, позволяя Алисе забрать CKB на сети Nervos Network. Либо Боб не раскрывает хеш-значение, оба контракта истекают, и Алиса и Боб могут вернуть свои вложенные средства.

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

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

Например, Алиса и Боб имеют общий UTXO, который требует подписи обеих сторон для того, чтобы потратить его. В этом случае Алиса создает транзакцию для его потрачивания, переводит 60% его стоимости Бобу и оставшиеся 40% себе. Алиса подписывает эту транзакцию и отправляет ее Бобу. Для Боба нет необходимости транслировать эту транзакцию в сеть биткойна или дожидаться ее подтверждения в блокчейне, так как эта транзакция является реальной и достоверной. Это связано с тем, что Алиса не может одна потратить этот UTXO (или повторно его потратить), а также потому, что подпись, предоставленная Алисой, действительна. Боб в любой момент может добавить свою подпись и транслировать эту транзакцию, чтобы осуществить этот платеж. Таким образом, Алиса предоставляет Бобу "доверенное обещание" через эту действительную (не включенную в блокчейн) транзакцию.

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

Сеть Lighting каналы и сеть Lighting

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

В разделе, посвященном "сделкам обязательств", мы уже рассказали о одном из способов оплаты. Однако этот контракт, который использует только двухсторонние многосторонние соглашения, может обеспечить только однонаправленную оплату. Другими словами, либо Алиса постоянно выплачивает Бобу, либо наоборот, пока не исчерпает свой остаток на счету по контракту. Если речь идет о двунаправленной оплате, это означает, что после обновления статуса баланс одной из сторон может уменьшиться, но у нее все равно есть предыдущая сделка обязательств, подписанная другой стороной - как можно предотвратить широковещание старой сделки обязательств и заставить широковещание только самой последней сделки обязательств?

Метод решения этой проблемы, используемый в молнии, называется "LN-Penalty". Предположим, что у Элис и Боба есть по 5 BTC в канале. Теперь Элис хочет заплатить Бобу 1 BTC, поэтому она подписывает такую обязательную транзакцию и отправляет ее Бобу:

Введите #0, 10 BTC: Alie-Bob 2-of-2 мультиподписной вывод (т.е. контракт канала)

Вывод #0, 4 BTC: Alice одно подпись

Вывод #1, 6 BTC: либо совместный временный открытый ключ #1 с односторонней подписью Alice-Bob, либо временная блокировка T1 с односторонней подписью Bob

Боб также подписывает обещающую транзакцию (соответствующую вышеупомянутой транзакции) и отправляет ее Алисе:

Ввод #0, 10 BTC: Выход Alie-Bob 2-of-2 с мультиподписью (то есть, канальный контракт)

Вывод #0,6 BTC: Bob односторонняя подпись

Вывод #1, 4 BTC: либо совместный временный открытый ключ #1 Bob-Alice с односторонней подписью, либо временная блокировка T1 с односторонней подписью Alice.

Здесь секрет в "временном совместном открытом ключе", который генерируется с использованием собственного открытого ключа и открытого ключа, предоставленного другой стороной. Например, временный совместный открытый ключ Alice-Bob генерируется путем умножения открытого ключа Alice на открытый ключ Bob, а затем сложения полученных результатов с хеш-значением. При генерации такого открытого ключа никто не знает его закрытый ключ. Однако, если Bob сообщит Alice закрытый ключ открытого ключа, предоставленного им, Alice сможет вычислить закрытый ключ этого временного совместного открытого ключа. - Это ключевой момент, позволяющий "отменить" старое состояние в молниеносном канале.

В следующий раз, когда стороны обновляют состояние канала (инициируют платеж), они обмениваются закрытым ключом временного открытого ключа, переданным другой стороне в предыдущем раунде. Таким образом, участник больше не осмеливается транслировать обещанную транзакцию, полученную им в предыдущей сделке: в этой обещанной транзакции для распределения значения своего вывода есть два пути, и закрытый ключ временного открытого ключа уже известен другой стороне; поэтому как только транслируется старая обещанная сделка, другая сторона может сразу же использовать этот общий временный закрытый ключ, чтобы забрать все средства из этого вывода. - Это и есть суть "LN-Penalty".

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

综上，ключевыми элементами дизайна молниеносного канала являются:

Две стороны всегда используют обязательства по сделкам для выражения внутреннего состояния контракта и представления платежей в виде изменения суммы;

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

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

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

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

任何一方随时都可以拿对方签过名的承诺交易退出合约；但是，如果双方愿意合作，他们可以签名一笔新的交易，让双方都可以立即拿回属于自己的钱。

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

Алиса -- HTLC --\u003e Боб -- HTLC --\u003e Кэрол -- HTLC --\u003e Дэниел

Alice \u003c-- Оригинал -- Bob \u003c-- Оригинал -- Carol \u003c-- Оригинал -- Daniel

Когда Alice находит такой маршрут и хочет заплатить Daniel, она запрашивает у Daniel хеш-значение, чтобы создать HTLC для Bob и просит Bob передать сообщение Carol и предоставить тот же HTLC; сообщение просит Carol передать сообщение Daniel и предоставить тот же HTLC. Когда сообщение доходит до Daniel, он раскрывает исходное изображение, чтобы получить стоимость HTLC и обновить состояние контракта; Carol делает то же самое, получает платеж от Bob и обновляет состояние канала; в конце концов, Bob раскрывает исходное изображение, обновляя состояние. Благодаря свойствам HTLC этот последовательный платеж либо выполнится вместе, либо провалится, поэтому он является доверенным.

Сеть Lighting состоит из множества каналов, каждый из которых (или контракт) является независимым. Это означает, что Алисе нужно знать только о событиях в своем канале с Бобом, и ей не обязательно знать, сколько взаимодействий произошло в чужих каналах, какая валюта была использована в этих взаимодействиях, и даже нужно ли знать, действительно ли они использовали канал.

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

Осторожный журнал контракта

Осторожный контракт журнала (DLC) использует криптографический прием, называемый "подпись адаптера (adaptor signature)", чтобы сделать возможным программирование биткоин-скриптов для создания финансовых контрактов, зависящих от внешних событий.

Адаптерная подпись позволяет сделать подпись действительной только после добавления приватного ключа. Например, для сигнатуры Schnorr стандартной формой является (R, s), где:

R = r.G # Значение nonce, используемое для подписи, r умножается на точку, сгенерированную эллиптической кривой, также можно сказать, что это открытый ключ r

s = r + Hash(R || m || P) \* p # p is the signing private key, P is the public key

Проверка подписи означает проверку s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

假设我给出了一对数据(R, s')，其中：

R = R1 + R2 = r1.G + r2.G

s' = r1 + Hash(R || m || P) * p

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

s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P

适配器签名让一个签名的有效性依赖于一个秘密数据，并且是可验证的。但是，这跟金融合约有什么关系呢？

Предположим, что Алиса и Боб хотят сделать ставку на результат игры. Алиса и Боб ставят на победу команды "Зеленые Дьяволы" и команды "Арлинна". Ставка составляет 1 BTC. Кроме того, сайт судей Кэрол обещает опубликовать подпись s_c_i результата с использованием случайного числа R_c, когда результат игры будет объявлен.

Можно увидеть, что есть три возможных результата (таким образом, у Кэрол есть 3 возможных подписи):

• Зеленый маг побеждает, Алиса выигрывает 1 BTC
• Алина выигрывает, Боб выигрывает 1 BTC
• Ничья, средства двух лиц возвращаются по исходному маршруту

为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：

Ввод #0,2 BTC: выход с мультиподписью Alie-Bob 2 из 2 (т.е. контракт на ставку)

Вывод #0, 2 BTC: Alice одиночная подпись

Но подпись, созданная Alice и Bob для этой транзакции, не является (R, s), а является адаптерной подписью (R, s'). Другими словами, подписи, предоставленные обеими сторонами, не могут быть непосредственно использованы для разблокировки этого контракта, и необходимо раскрыть секретное значение. Это секретное значение является образом s\_c\_1.G, то есть подписью Carol! Поскольку значение nonce для подписи Carol уже известно (это R\_c), то s\_c\_1.G можно построить (s\_c\_1.G = R\_c + Hash(R\_c || '绿魔胜出' || PK\_c) \* PK\_c).

Когда результат будет объявлен, предположим, что зеленые волшебники победят, тогда Кэрол опубликует подпись (R_c, s_c_1), и Алиса и Боб смогут завершить адаптерную подпись противника, добавить свою собственную подпись и сделать эту транзакцию действительной, а затем распространить ее по сети, вызвав эффект расчета. Но если зеленые волшебники не победят, Кэрол не опубликует s_c_1, и эта обещанная сделка не сможет стать действительной.

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

Самая важная особенность осторожного журнального контракта по сравнению с другими формами реализации заключается в его конфиденциальности: (1) Алиса и Боб не обязаны сообщать Кэрол о том, что они используют данные Кэрол, что не влияет на выполнение контракта. (2) Наблюдатели в блокчейне (включая Кэрола) также не могут определить, какой веб-сервис используют Алиса и Боб через их контрактные транзакции, даже не могут установить, является ли их контракт контрактом на ставки (а не молниеносным каналом).

Четвертый. Введение в применение ограничений.

OP_CTV и контроль за заторами

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

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

Допустим, Алиса, Боб, Кэрол хотят вывести с бирж 5 BTC, 3 BTC и 2 BTC соответственно. Затем биржа можете сделать 10 BTC на выходе с 3 ветвями OP_CTV. Предположим, что Алиса хочет снять деньги, она может использовать ветвь 1, и транзакция, представленная значением хеш, используемым OP_CTV этой ветви, сформирует два выхода, один из которых — выделить Алисе 5 BTC; Другой выход, в свою очередь, представляет собой пул, который также использует OP_CTV для фиксации транзакции, позволяя Бобу извлечь только 3 BTC и отправить оставшиеся 2 BTC Кэрол.

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

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

OP_CTV имеет очень интересное применение: "односторонний платежный канал с скрытым раскрытием". Предположим, что Алиса создает такой фонд и гарантирует, что средства могут быть безопасно выведены из него в выход с таким сценарием: "01928374656574839201".

要么， Alice 和 Bob 一起花费它要么，一段时间后，Alice 可以独自花费它

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

OP_Vault и сейф

OP_VAULT - это предложение о ограничительных условиях, специально разработанное для создания "хранилищных контрактов (vaults)".

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

В теории, OP_CTV также может быть программируемым для создания такого контракта, но это неудобно по многим причинам, в том числе из-за комиссии: в то время как он обещает сделку, он также обещает комиссию, которую эта сделка должна оплатить. Учитывая назначение этого контракта, интервалы времени для установки и снятия контракта должны быть очень длинными, поэтому практически невозможно предсказать подходящую комиссию. Хотя OP_CTV не ограничивает ввод, поэтому можно увеличить комиссию, добавив вводы, однако все предоставленные входные данные станут комиссией, поэтому это нереально. Другой способ - это CPFP, то есть предоставление комиссии в новой сделке, используя потраченные средства после снятия. Кроме того, использование OP_CTV означает, что такой контракт сейфа не может быть снят пакетно (и, конечно же, не может быть пакетно восстановлен).

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

此外, есть два важных момента, которые стоит отметить: (1) Действие кода операции OP_VAULT аналогично предложению другого ограничительного условия: OP_TLUV; Джереми Рубин правильно указал, что это в некоторой степени уже приводит к понятию "вычисления": OP_TLUV/OP_VAULT обещает код операции, позволяющий пользователям передавать аргументы для этого кода операции через новую транзакцию, чтобы обновить всё дерево скриптовых листьев; это уже не "проверка входных данных в соответствии с определенным условием", а "генерация новых значимых данных на основе входных данных", хотя возможности этого вычисления ограничены.

完整ное предложение OP_VAULT также использует предложения на основе политики пула транзакций (mempool policy), таких как транзакции формата v3, для достижения лучших результатов. Это напоминает нам, что значение "программирования" может быть гораздо шире, чем мы представляем. (Аналогичный пример - открытые транзакции в сети Nervos Network.)

5. Понимание CKB

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

UTXO虽然不乏编程出这些应用的能力，但读者也很容易觉察出它们的缺点，或者说可以优化的地方，比如：

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

На самом деле, сообщество Биткойна уже предложило ответы на эти вопросы, в основном связанные с предложением Sighash (BIP-118 AnyPrevOut).

Однако, если мы программировали на CKB, тогда BIP-118 уже доступен (можно использовать способность имитации таких меток Sighash с помощью интроспекции и целевой проверки подписи).

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

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

Программируемый блокировщик для произвольных вычислений

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

Кроме того, возможность проверки произвольных вычислений делает Lock более гибким и предоставляет больше способов аутентификации, чем UTXO. Например, мы можем реализовать молниеносный канал на CKB, где одна сторона использует подпись ECDSA, а другая - подпись RSA.

Фактически, это одна из областей, которую люди начали исследовать на CKB: использование этой гибкой возможности аутентификации в пользовательском самостоятельном управлении для достижения так называемой "абстракции счета" - авторизация и восстановление контроля за действительностью транзакции являются очень гибкими и почти не имеют ограничений. В принципе, это сочетание "множественных ветвей расходов" и "любых средств аутентификации". Примеры реализации: кошелек JoyID, UniPass.

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

Программируемый тип произвольных вычислений

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

Фактически, разделение на Lock и Type можно рассматривать как повышение безопасности: Lock сосредоточен на реализации метода хранения или контрактного протокола, а Type сосредоточен на определении UDT.

Кроме того, возможность запуска проверки на основе определения UDT также позволяет UDT участвовать в контрактах аналогично CKB (UDT - гражданин первого класса).

Пример: Ранее автор предложил протокол для обеспеченного займа NFT без доверия на основе биткойна. Ключевым элементом этого протокола является обещательная сделка, в которой входящая стоимость меньше исходящей (поэтому она не считается действительной сделкой), но как только можно предоставить достаточное количество входов для этой сделки, она становится действительной: как только заемщик сможет погасить долг, залоговая NFT не может быть присвоена кредитором. Однако бездоверительность этой обещательной сделки основана на проверке суммы входных и выходных данных, поэтому заемщик может использовать только биткойн для погашения долга - даже если заемщик и кредитор согласны принять другую валюту (например, USDT, выпущенный по протоколу RGB), обещательная сделка биткойна не может гарантировать, что вернув достаточное количество USDT, заемщик получит свою NFT, потому что биткойн-транзакция не знает о состоянии USDT! (Поправка: другими словами, невозможно создать обещательную сделку с условием погашения в USDT.)

Если мы сможем провести проверку на основе определения UDT, заемщик сможет подписать еще одну обязательную транзакцию, которая позволит заемщику использовать USDT для погашения кредита. Транзакция будет проверять количество введенных и выводимых USDT, чтобы обеспечить доверие пользователям при использовании USDT для погашения кредита.

修订：Предположим, что здесь используемый в качестве залога NFT и токен для погашения выпущены с использованием одного и того же протокола (например, RGB), тогда проблема здесь может быть решена. Мы можем построить обязательную сделку на основе протокола RGB, чтобы синхронизировать изменение статуса NFT и погашение (связывая два изменения статуса с помощью транзакции внутри протокола RGB). Однако, поскольку транзакции RGB также зависят от транзакций биткойна, построение такой обязательной сделки будет иметь определенные трудности. В конечном счете, хотя проблема может быть решена, токен не может быть признан полноправным участником.

接下来我们再考虑内省能力。

锁 它读取其他锁。

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

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

Чтение других типов s (а также Data) блокировки

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

Type 01928374656574839201

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

Чтение других типов Type s (а также Data) в TypeScript

集换卡？集齐 n 个 token 可以换取更大的一个 token : )

Шесть. Вывод

与此前出现的Смарт-контракт的Смарт-контракты的Смарт-контракт（如以太坊）相比，Nervos Network 采取了不同的结构；因此，对以往那些Смарт-контракт系统的了解，往往难以成为理解 Nervos Network 的基础。本文从一种比 CKB Cell 更为受限的结构 —— BTC UTXO —— 的应用编程出发，提出了一种理解 CKB Cell 可编程性的方法。并且，运用 “内省” 的概念来理解 Cell 的 “跨合约访问” 的能力，我们可以划分运用内省能力的情形，并为它们确定具体的用途。

"Исправления:"

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

2. Не учитывая способность к перекрестному доступу Cell (т.е. способность к самоанализу), различие между lock s и type s можно рассматривать как улучшение безопасности: это разделяет определение активов UDT и метод их хранения; кроме того, type s, открывающий состояние (а также Data), реализует эффект "UDT is first-class citizen".

Вышеуказанные два аспекта означают что-то, что имеет тот же формат, что и "BTC + RGB", но с более сильной программной способностью;

3. Учитывая способность к интроспекции ячейки, она может обладать более мощной программной способностью, чем UTXO BTC после обязательств, и реализовывать некоторые вещи, которые трудно реализовать с помощью BTC + RGB (поскольку BTC не может считывать состояние RGB).

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

Благодарность

感谢 Retric，Jan Xie и Xue Jie за обратную связь в процессе написания статьи. Конечно, все ошибки в тексте я несу на себе.

Ссылки:

5._07_05_введение_в_модель_проверки_программирования_CKB/

6.（два）Осторожные логические контракты (DLC)

13.\_ВОПРОС/обсуждения/7