Понимание программируемости системы требует от нас определения структурных особенностей системы. Изучение прикладного программирования на основе Bitcoin Script помогает нам понять базовую структуру CKB Cell и его парадигму программирования. Кроме того, он разбивает программные компоненты CKB на нужные части и помогает нам понять преимущества программируемости, которые приносит каждая часть.
I. Введение
«Программируемость» — это измерение, которое люди часто используют при сравнении блокчейн-систем. Тем не менее, часто возникают разногласия по поводу того, как описывается программируемость. Распространенным выражением является «XX блокчейн поддерживает Тьюринг-полные языки программирования» или «XX блокчейн поддерживает программирование общего назначения», что призвано указать, что «XX блокчейн» здесь обладает сильной программируемостью. В этих утверждениях есть доля правды: системы, поддерживающие полное по Тьюрингу программирование, как правило, легче программировать, чем те, которые этого не делают. Однако в структурных характеристиках системы смарт-контрактов есть много аспектов, и данное утверждение затрагивает только один из них, поэтому его недостаточно разбираться достаточно глубоко в силу того, что разработчики не руководствуются им, а на обычных пользователей нельзя положиться в отличии мошенничества.
К структурным особенностям системы смарт-контрактов можно отнести:
Основная форма выражения состояния (контракт) (счет vs. торговый выход)
Разрешено ли программировать произвольные вычисления (в этом и заключается термин «Тьюринг-полный»)
Создает ли процесс выполнения новые данные или просто выдает логические значения? (Вычисления и проверка)
Разрешать или не разрешать запись дополнительных состояний в контракте
Имеет ли контракт доступ к состоянию другого контракта при его исполнении
Поэтому, помимо «программируемых произвольных вычислений», существует как минимум четыре характеристики, влияющие на программируемость системы смарт-контрактов. Можно даже сказать, что эти другие особенности более важны, потому что они определяют на более глубоком уровне, чего легко достичь, а чего трудно; Что такое более экономичная реализация, а какая менее эффективная.
Например, Ethereum часто приводится в качестве примера хорошей программируемости, но основной формой выражения состояния в Ethereum является учетная запись, что затрудняет программирование одноранговых контрактов (например, платежных шлюзов, контрактов на ставки один к одному) — не абсолютно невозможно, просто неблагодарно. Экосистема Ethereum нередко пытается реализовать платежный канал/государственный канал, и было много теоретических дискуссий, но эти проекты, похоже, больше не активны — и это, очевидно, нельзя винить в отсутствии усилий со стороны разработчиков. Не случайно, что проекты, активные на Ethereum сегодня, принимают форму «пулов», а не «одноранговых контрактов». Точно так же люди могут быть довольны программируемостью Ethereum, но модель учетной записи по своей сути недостаточна для достижения «абстракции учетной записи» (которую также можно понимать как обобщение концепции кошелька).
Точно так же изучение программируемости CKB также требует от нас понимания структурных характеристик системы смарт-контрактов CKB в этих аспектах. Что мы уже знаем, так это то, что CKB позволяет программировать произвольные вычисления, позволяет записывать дополнительное состояние в контракте и позволяет одному контракту получать доступ к состоянию другого контракта при выполнении. Однако форма контракта представляет собой выход транзакции (называемой «ячейкой»), что принципиально отличает его от Ethereum. Таким образом, понимание системы смарт-контрактов Ethereum и экземпляров контрактов в ней не помогает нам понять, как CKB реализует эти структурные особенности, а также не помогает нам понять программируемость CKB.
К счастью, смарт-контракты на Биткойне, похоже, обеспечивают лучшую основу для понимания программируемости CKB. Это связано не только с тем, что основной формой представления состояния Биткойна также является выход транзакций (называемых «UTXO»), но и потому, что с помощью концепции, предложенной сообществом Биткойна под названием «ковенанты», мы можем понять, почему CKB обладает такими структурными характеристиками, и соответствующим образом разбить конечный эффект на несколько частей, определив преимущества программируемости, которые приносит каждая из них.
II. CKB против BTC: что еще?
(1) Базовая структура
В качестве основной формы представления состояния Биткойна, UTXO Биткойна («Неизрасходованный вывод транзакции») имеет два поля:
Сумма в сатоши указывает на стоимость биткоина, которой владеет UTXO;
Публичный ключ скрипта, также известный как скрипт блокировки, представляет собой условия, которые необходимо выполнить, чтобы потратить средства, то есть программу смарт-контракта, которая устанавливает условия разблокировки средств.
По сравнению с системами смарт-контрактов, которые появились позже, Bitcoin Script довольно ограничен:
Не позволяет программировать произвольные вычисления; Существует всего несколько практических расчетов, которые можно использовать для верификации (проверка подписи, предварительная проверка хэша, проверка времени)
Не позволяет записывать дополнительные состояния в рамках контракта; (Например, вы не можете использовать скрипт для ограничения пропорциональной/максимальной суммы денег, потраченной за один раз; Спрятать токен в нем тоже нет возможности)
Также не позволяет получить доступ к состоянию другого контракта в момент исполнения (каждый скрипт является отдельной вселенной и не зависит друг от друга).
Этот вид сценариев, хотя и ограничен, не лишен возможности программировать удивительные приложения, и это основа нашего исследования программируемости CKB. Позже будет раздел, в котором будут представлены два примера программирования Bitcoin Script.
В отличие от этого, единица состояния ЦКБ называется «ячейкой» и имеет четыре поля:
Емкость, аналогичная количеству UTXO, выражает объем пространства, которое может занимать ячейка, измеряемый в байтах.
Lock, аналогично публичному ключу скрипта UTXO, определяет принадлежность ячейки; Только после того, как предоставленные данные могут пройти через блокировку, ячейка может быть «обновлена» (или ячейка может быть освобождена, а емкость может быть использована для создания новых ячеек);
Данные, данные, произвольные данные, объем которых ограничен Емкостью;
Type, необязательный скрипт, задающий условия обновления Data.
Кроме того, Lock и Type могут быть запрограммированы для произвольных вычислений. Вы можете запрограммировать любой алгоритм проверки подписи, вы можете запрограммировать любой алгоритм хеширования для проверки прообразов и так далее.
Читатели легко видят, как программируемость Cell улучшается по сравнению с UTXO:
Ячейки могут быть запрограммированы с произвольными вычислениями, а не только с несколькими конкретными вычислениями; Проверка его права собственности будет более гибкой;
Из-за полей Data и Type ячейка может записывать дополнительные состояния; Это позволяет ячейке нести так называемый UDT (определяемый пользователем маркер).
В сочетании со структурой «транзакционного выхода» самой ячейки, преимущества этих двух точек сами по себе весьма и весьма существенны, но только из приведенного выше описания мы не знаем, как ячейка достигает «один контракт обращается к состоянию другого контракта во время выполнения». Для этого нужно опираться на концепцию, которая уже давно обсуждается в биткоин-сообществе: «ковенанты».
(2) Ограничения и самоанализ
Первоначальная цель ограничительной оговорки состоит в том, чтобы ограничить то, куда может быть потрачена денежная сумма. На текущий Биткойн (где не было предложено никаких ограничений) одна сумма денег, после разблокировки, может быть потрачена где угодно (она может быть выплачена на произвольный публичный ключ скрипта). Но идея оговорки об ограничении заключается в том, что они могут быть потрачены таким образом, чтобы ограничить их определенными местами, например, определенный UTXO будет потрачен только определенной транзакцией, так что даже если кто-то может предоставить подпись для UTXO, то, куда они могут быть потрачены, уже определено этой транзакцией. Это может показаться немного странным, но это может привести к некоторым интересным приложениям, которые будут рассмотрены в следующем разделе. Важно отметить, что это ключ к нашему дальнейшему пониманию программируемости CKB.
Расти Рассел справедливо отмечает, что ограничение можно понимать как способность к «интроспекции» торговли, т.е. когда UTXO A тратится на транзакцию B, оператор скрипта может прочитать некоторые (или все) транзакции B, а затем проверить, соответствуют ли они параметрам, предварительно запрошенным сценарием. Например, соответствует ли открытый ключ скрипта для первого вывода транзакции A тому, что требуется открытым ключом скрипта UTXO A (это то, что изначально означало ограничение).
Проницательный читатель поймет, что при полной интроспекции входные данные одной транзакции могут считывать состояние других входных данных той же транзакции, что позволяет одному контракту получить доступ к состоянию другого контракта во время выполнения. На самом деле, именно так и был разработан CKB Cell.
Исходя из этого, мы можем разделить эту полную интроспективную способность на четыре сценария:
Lock читает другие (входные и выходные) блокировки
Lock считывает Тип (а также Данные) другого (вход и выход)
Тип считывает другие (входные и выходные) блокировки
Тип считывает Тип (и Данные) другого (вход и выход)
Это позволяет нам проанализировать роль интроспективных возможностей каждой части в различных сценариях использования при определенных допущениях (разделение функций между Lock и Type), т.е. выигрыш в программируемости, который приносит нам каждая часть.
В следующих двух разделах мы рассмотрим текущее (и еще не предложенное) программирование Bitcoin Script и вероятную функциональность, которой, как ожидается, достигнет предлагаемое ограничение, чтобы дать конкретное понимание того, как можно запрограммировать и сделать CKB Cell лучше.
III. Программирование скриптов Биткоина
В этом разделе мы будем использовать «Lightning Channel/Lightning Network» и «Контракт Caution Journal (DLC)» в качестве примеров прикладного программирования на основе Bitcoin Script. Прежде чем мы перейдем к этому, давайте рассмотрим две вещи.
(1) ОП_IF и «Обязательственные сделки»
Первая концепция — это код операции управления потоком в Bitcoin Script, например: OP_IF, OP_ELSE. Эти коды операций ничем не отличаются от IF в компьютерном программировании, и их целью является выполнение различных операторов на основе разных входных данных. В контексте Bitcoin Script это означает, что мы можем установить несколько путей разблокировки средств; В сочетании с функцией блокировки времени это означает, что мы можем назначать приоритет действиям.
Возьмем в качестве примера знаменитый «Hash Timelock Contract (HTLC)», который переводится на разговорный язык:
В качестве альтернативы Боб мог бы раскрыть прообраз за решеткой H и поставить свою собственную подпись, что стоило бы денег
Или, Алиса может потратить деньги со своей подписью после определенного периода T
Это «или... или...» Эффект достигается за счет опкода управления процессом.
Наиболее заметным преимуществом > HTLC является то, что он может объединять несколько операций вместе и распылять их. Например, если Алиса хочет обменять BTC на CKB с Бобом, то Боб может сначала дать хеш-значение и создать HTLC в сети Nervos. Затем Алиса создает HTLC на Биткойне, который использует тот же хэш. В качестве альтернативы Боб берет BTC, оплаченные Алисой на биткойны, а также раскрывает прообраз, позволяя Алисе вывести CKB в сети Nervos. В любом случае, Боб не раскрывает оригинальное изображение, оба контракта истекают, и Алиса и Боб могут вернуть деньги, которые они вложили.
После активации софтфорка Taproot эта функция множественной разблокировки пути еще больше расширяется за счет введения MAST (Merkle Abstract Syntax Tree): мы можем превратить путь разблокировки в лист на дереве Меркла, каждый лист независим, поэтому больше нет необходимости использовать такой код операции управления потоком; Кроме того, поскольку один путь раскрывается, не раскрывая другие, мы можем добавить большее количество путей разблокировки к выходу, не беспокоясь об экономике.
Вторая концепция – это «торговля обязательствами». Идея зафиксированной транзакции заключается в том, что в некоторых случаях действительная транзакция Биткойна, даже если она не подтверждена блокчейном, так же реальна и обязательна.
Например, у Алисы и Боба общий UTXO, который требует, чтобы они оба были подписаны, чтобы тратить. В этот момент Алиса создает транзакцию, чтобы потратить его, передавая 60% его стоимости Бобу, а остальное себе; Алиса ставит свою подпись для транзакции, которая затем отправляется Бобу. Что ж, для Боба это не обязательно должно транслироваться в сеть Биткойна, и это не должно быть подтверждено блокчейном, и платежный эффект этой транзакции также реален и заслуживает доверия. Поскольку Алиса не может потратить UTXO самостоятельно (и, следовательно, не может потратить их повторно), а также потому, что подпись, предоставленная Алисой, действительна, Боб всегда может добавить свою подпись и транслировать транзакцию для выполнения платежа. Другими словами, Алиса предоставила Бобу «надежное обязательство» через эту действительную (вне сети) транзакцию.
Зафиксированные транзакции являются основной концепцией программирования приложений Биткойна. Как упоминалось ранее, контракт Биткойна основан на верификации, не имеет состояния и не допускает перекрестного доступа; Однако, если контракт не содержит состояний, где эти состояния хранятся и как контракт может безопасно двигаться вперед (изменять состояние)? Транзакции обязательств дают простой ответ: состояние контракта может быть выражено в виде транзакций, так что участники контракта могут сами сохранить состояние без необходимости отображать его в блокчейне; Проблема изменения состояния контракта также может трансформироваться в проблему того, как безопасно обновить совершенную транзакцию; Кроме того, если мы обеспокоены опасностями заключения контракта (например, заключение контракта, который требует, чтобы обе стороны подписали, чтобы потратить, и есть риск, что другая сторона не отреагирует и застрянет), то простое создание транзакции обязательства, которая заранее обойдется контракту, и получение подписи может снизить риск и устранить доверие к другим участникам.
(2) Канал Lightning и сеть Lightning
Канал молнии — это контракт «один к одному», в котором две стороны могут платить друг другу неограниченное количество раз без подтверждения блокчейном ни одного платежа. Как и следовало ожидать, он использует торговлю обязательствами.
В разделе «Зафиксированные транзакции» мы уже представили платежный канал. Тем не менее, этот тип контракта, который использует только мультиподпись 2 из 2, может обеспечить только односторонние платежи. То есть либо Алиса всегда платит Бобу, либо Боб всегда платит Алисе до тех пор, пока не израсходует свой остаток по контракту. Если это двусторонний платеж, это означает, что после обновления статуса у одной из сторон может быть меньше баланса, чем раньше, но у ЦА есть последняя зафиксированная транзакция, подписанная другой стороной - что можно сделать, чтобы ТА не транслировала старое обещание, а ЦА - только самую последнюю транзакцию обязательства?
Решение этой проблемы с каналом молнии называется «LN-Penalty». Теперь предположим, что у Алисы и Боба есть по 5 BTC в канале; Теперь Алиса хочет заплатить Бобу 1 BTC, поэтому подписывает обещанную транзакцию и отправляет ее Бобу:
Введите #0 и 10 BTC:
Выход Alie-Bob 2-of-2 с несколькими подписями (т.е. контракт канала)
Выход #0 , 4 BTC:
Единая подпись Алисы
Выход #1 , 6 BTC:
или
Федеративный эфемерный открытый ключ Алисы-Боба #1 с единственной подписью
или
T 1 timelock, Боб с одной подписью
Боб также подписывает обязательство (которое соответствует описанной выше транзакции) и отправляет его Алисе:
Введите #0 и 10 BTC:
Выход Alie-Bob 2-of-2 с несколькими подписями (т.е. контракт канала)
Выход #0 , 6 BTC:
Боб с односторонней подписью
Выход #1 , 4 BTC:
или
Федеративный эфемерный открытый ключ Боба-Алисы #1 с единственной подписью
или
T 1 timelock, Алиса с односторонней подписью
Хитрость здесь заключается в этом «совместном временном открытом ключе», который генерируется с использованием одного из ее собственных открытых ключей и открытого ключа, предоставленного другой стороной, например, совместный временный открытый ключ Алисы и Боба, который Алиса получает с помощью одного из своих собственных открытых ключей и открытого ключа, предоставленного Бобом, умножая каждый на хэш-значение. Когда генерируется такой публичный ключ, никто не знает его закрытого ключа. Однако, если Боб сообщит Алисе закрытый ключ открытого ключа, который он предоставил, Алиса сможет вычислить закрытый ключ федеративного временного открытого ключа. - Это ключ к тому, что Lightning Channel может «отменить» старое состояние.
В следующий раз, когда обе стороны захотят обновить статус канала (инициировать платеж), обе стороны обмениваются закрытым ключом временного открытого ключа, предоставленного друг другу в предыдущем раунде. Таким образом, участники больше не решаются транслировать последнюю обещанную транзакцию, которую они получили: выход этой обещанной транзакции, присваивающей ценность их собственной стороне, имеет два пути, а закрытый ключ пути временного открытого ключа уже известен другой стороне; Таким образом, как только транзакция старого обязательства будет транслироваться, другая сторона может немедленно использовать этот совместный временный закрытый ключ, чтобы забрать все средства в этом выходе. - Это и есть "LN-Penalty".
В частности, порядок взаимодействия следующий: сторона, инициирующая платеж, сначала запрашивает у другой стороны новый временный публичный ключ, а затем конструирует новую транзакцию обязательства и передает ее другой стороне; Сторона, получившая обещанную транзакцию, раскрывала другой стороне закрытый ключ временного открытого ключа, который она дала в предыдущем раунде. Такая последовательность взаимодействий гарантирует, что участники всегда получают новую транзакцию обязательства, прежде чем признать недействительной транзакцию обязательства, полученную ими в предыдущем раунде, и, следовательно, не требует доверия.
Таким образом, основными конструкциями канала молнии являются:
Обе стороны всегда используют сделки обязательств для выражения состояния в рамках контракта, а изменение суммы для выражения платежа;
Транзакции обязательств всегда стоят один и тот же вход (вход, который требует, чтобы обе стороны предоставляли подписи одновременно), поэтому все транзакции обязательств конкурируют друг с другом, и только одна из них может быть подтверждена блокчейном.
Два участника не подписывают одну и ту же сделку по обязательствам (хотя и состоят в паре); И то, что они подписывают, это всегда более выгодная для них сделка, иными словами, обещанная сделка, которую получают участники, всегда невыгодна для них самих;
Недостатком этого является то, что вывод, который присваивает себе значение, имеет два пути разблокировки: один путь может быть разблокирован своей собственной подписью, но ему нужно подождать некоторое время; Другой путь использует открытый ключ другой стороны, который защищен только в том случае, если один из его временных закрытых ключей не раскрыт.
При каждом платеже обе стороны обменивают временный закрытый ключ, использованный другой стороной в предыдущем раунде, на новую транзакцию обязательства, так что сторона, передавшая временный закрытый ключ, больше не осмеливается транслировать старую транзакцию обязательства, поэтому она «отменяет» предыдущую транзакцию обязательства и обновляет статус контракта; (На самом деле, все эти обещанные транзакции являются действительными транзакциями и могут транслироваться в блокчейн, но участники вынуждены быть наказаны и больше не осмеливаются транслировать)
Любая из сторон может отказаться от договора в любое время с обязательством, подписанным другой стороной; Однако, если обе стороны готовы сотрудничать, они могут подписать новую сделку, чтобы обе стороны могли немедленно вернуть свои деньги.
Наконец, поскольку HTLC также может быть помещен в зафиксированную транзакцию, канал Lightning также может пересылать платежи. Предполагая, что Алиса может найти путь, состоящий из каналов Lightning, соединяющихся до и после, чтобы связаться с Дэниелом, тогда можно достичь ненадежных многоскачковых платежей, не открывая канал с Дэниелом. Это Lightning Network:
Когда Алиса находит такой путь и хочет заплатить Дэниелу, она просит у Дэниела хэш, чтобы создать HTLC для Боба, и предлагает Бобу переслать сообщение Кэрол и предоставить тот же HTLC; В сообщении Кэрол предлагается переслать сообщение Дэниелу и предоставить тот же HTLC. Когда новости доходят до Дэниела, он раскрывает Кэрол прообраз, который дает ему ценность HTLC и обновляет состояние контракта. Кэрол сделала то же самое, получив деньги от Боба и обновив статус канала; Наконец, Боб показывает прообраз Алисе и обновляет статус. Из-за природы HTLC эта цепочка платежей либо успешна, либо терпит неудачу одновременно, и поэтому она не требует доверия.
Lightning Network состоит из одного канала, идущего один за другим, каждый из которых независим друг от друга. Это означает, что Алисе нужно знать, что происходит на ее канале с Бобом, независимо от того, сколько взаимодействий произошло на каналах других людей, какую валюту они используют и даже используют ли они канал на самом деле.
Масштабируемость Lightning Network отражается не только в том, что скорость платежей в канале Lightning ограничена только инвестициями аппаратных ресурсов обеими сторонами, но и в том, что благодаря децентрализованному хранению состояния один узел может использовать максимальное кредитное плечо с наименьшими затратами.
(3) Будьте осторожны с журнальными контрактами
Предостерегающий контракт журналирования (DLC) использует криптографическую технику, называемую «подписью адаптера», которая позволяет Bitcoin Script программировать финансовые контракты, зависящие от внешних событий.
Подписи адаптера позволяют подписи стать действительной подписью только после добавления закрытого ключа. Возьмем, к примеру, подпись Шнорра, где стандартная форма подписи Шнорра (R, s), где:
R = r.G
Значение nonce, используемое для подписи, умножается на точку генерации эллиптической кривой, которую также можно назвать открытым ключом r
s = r + Hash(R || m || ) *
p — закрытый ключ подписи, а P — открытый ключ
验证签名即验证 s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || ) * ПК
Допустим, я даю пару данных (R, s'), где:
R = R 1 + R 2 = r 1.G + r 2.G
s' = r 1 + Hash(R || m || ) *
Очевидно, что это не действительная подпись Шнорра, и она не проходит формулу валидации, но я могу доказать проверяющему, что она может быть действительной подписью, просто зная закрытый ключ R 2, r 2:
с'. G + R 2 = R 1 + Hash(R || m || P) * P + R 2 = R + Hash(R || m || ) *
Подписи адаптера делают действительность подписи зависимой от секретных данных и поддается проверке. Но какое это имеет отношение к финансовым контрактам?
Допустим, Алиса и Боб хотят сделать ставку на исход игры с мячом. Алиса и Боб поставили на победу Зеленого Гоблина и Алину соответственно со ставкой в 1 BTC. Кроме того, Carol, веб-сайт футбольных обзоров, пообещал использовать одноразовый R_c для публикации подписанного s_c_i результатов, когда будут объявлены результаты игры.
Как видно, есть три возможных исхода (таким образом, есть 3 варианта подписи Кэрол):
Зеленый гоблин выигрывает, Алиса выигрывает 1 BTC
Алина выигрывает, а Боб выигрывает 1 BTC
Ничья, средства двоих возвращаются одинаково
Для этого они создают сделку по обязательствам для каждого результата. Например, транзакция обязательства, созданная для первого результата, будет выглядеть следующим образом:
Введите #0 , 2 BTC:
Вывод мультиподписи Али-Боб 2 из 2 (т.е. контракт ставки)
Выход #0 , 2 BTC:
Единая подпись Алисы
Однако вместо (R, s) подпись Алисы и Боба, созданная для этой транзакции, является сигнатурой адаптера (R, s'); Другими словами, подписи, поставленные друг другу обеими сторонами, не могут быть использованы непосредственно для разблокировки контракта, но должны раскрывать тайную ценность. Эта тайная ценность является прообразом s_c_ 1.G, который является подписью Кэрол! Поскольку значение nonce сигнатуры Кэрол определено (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) Ончейн-наблюдатели (включая Кэрол) не смогут определить, какой веб-сайт они используют, благодаря исполнению контракта Алисы и Боба, или даже то, что их контракт является контрактом на ставки (а не каналом молнии).
IV. Введение в применение ограничений
(a) OP_CTV и контроль перегрузок
Разработчики биткоин-сообщества внесли ряд предложений, которые можно отнести к ограничительным оговоркам. На данный момент одним из самых известных предложений является OP_CHECKTEMPLATEVERIFY (OP_CTV), который популярен среди биткоин-сообщества своей простотой, но гибкостью благодаря своей простой концепции. Идея OP_CTV заключается в том, чтобы зафиксировать хэш в скрипте, чтобы ограничить, что средства могут быть потрачены только транзакциями, представленными этим хешем; Этот хеш обещает выход транзакции и большинство полей, но не вход транзакции, а только количество входов.
«Контроль перегрузки» является хорошим примером того, как можно продемонстрировать ОП_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 Кэрол.
То же самое, если Боб или Кэрол захотят вывести деньги. При выводе денег они смогут использовать только те транзакции, которые могут пройти соответствующую проверку OP_CTV, т.е. они смогут выплатить только соответствующую сумму себе, и не смогут произвольно вывести деньги; Оставшиеся средства пойдут в пул с блокировкой OP_CTV, что гарантирует, что оставшиеся пользователи могут быть размещены вне пула без доверия, независимо от порядка, в котором они выводятся.
Если говорить абстрактно, то роль OP_CTV здесь заключается в планировании пути к концу срока действия контракта для контракта, чтобы контракт пула здесь мог сохранять атрибут выхода без доверия, независимо от того, какой путь он выберет или в каком состоянии он находится.
Есть также очень интересное использование этого ОП_CTV: «односторонний платежный канал, который скрыт, но не раскрыт». Предположим, что Алиса формирует такой пул средств и гарантирует, что средства могут быть надежно выведены в вывод с помощью следующего скрипта:
или Алиса и Боб проводят его вместе
или, через некоторое время, Алиса может потратить его самостоятельно
Если бы Алиса не рассказала об этом Бобу, Боб бы не узнал о существовании такого выхода; Как только Алиса покажет его Бобу, Боб сможет использовать выходные данные в качестве чувствительного ко времени одностороннего платежного канала, который Алиса может использовать для немедленной оплаты Бобу, не дожидаясь подтверждения от блокчейна. Боб просто просит Алису поместить его транзакцию обязательств в цепочку, прежде чем Алиса сможет потратить ее самостоятельно.
(б) ОП_Vault и сейф
OP_VAULT — это предложение об ограничительной оговорке, специально разработанной для создания «хранилищ».
Контракт Vault разработан как более безопасная и продвинутая форма самостоятельного хранения. Несмотря на то, что текущий контракт с несколькими подписями может избежать единой точки отказа для одного закрытого ключа, если злоумышленник получит пороговое количество закрытых ключей, владелец кошелька будет беспомощен. Сейф хочет установить единый лимит расходов для ваших средств; В то же время, при снятии с него денег по обычному маршруту, операция вывода будет принудительно выполнять период ожидания; А в период ожидания операция вывода может быть прервана операцией экстренного восстановления кошелька. Даже если такой контракт будет нарушен, владелец кошелька может инициировать встречную операцию (с помощью ветки аварийного восстановления).
Теоретически OP_CTV тоже может запрограммировать такой контракт, но есть много неудобств, одним из которых является комиссия: совершая сделку, она также обещает комиссию, которую заплатит сделка. Учитывая назначение этого контракта, временной интервал между настройкой контракта и снятием денег должен быть очень длинным, поэтому предугадать соответствующую комиссию практически невозможно. Хотя OP_CTV не ограничивает входы, поэтому комиссия может быть увеличена за счет увеличения входа, все предоставленные входные данные станут комиссией, поэтому это нереально; Еще один способ – CPFP, который заключается в предоставлении комиссии на новые транзакции путем расходования выведенных средств. Кроме того, использование OP_CTV означает, что такой контракт Vault не может быть отозван массово (и, конечно, не может быть восстановлен массово).
Предложение OP_VAULT пытается решить эти проблемы, предлагая новые коды операций (OP_VAULT и OP_UNVAULT). OP_UNVAULT предназначен для пакетной устойчивости, поэтому мы пока не будем упоминать о нем. OP_VAULT ведет себя следующим образом: когда мы помещаем его в ветвь дерева скриптов, он может быть использован для фиксации в пригодный для использования код операции (например, OP_CTV) без конкретных параметров; При проведении этой ветки транзакции могут передаваться в определенных параметрах, но не в других ветках. В результате, ему не нужно устанавливать заранее установленную плату, и ее можно установить, когда ветка исчерпана; Предполагая, что ветка также имеет временную блокировку, она будет принудительно применена; Наконец, поскольку вы можете изменить только ветку, в которой вы находитесь, и никакая другая ветвь нового дерева сценариев (включая ветвь аварийного восстановления) не будет изменена, мы можем прервать такие выводы.
Кроме того, стоит упомянуть два момента: (1) опкод OP_VAULT ведет себя аналогично другому предложению ограничения: OP_TLUV; Джереми Рубин (Jeremy Rubin) справедливо отмечает, что это в определенной степени породило концепцию «вычисления»: OP_TLUV/OP_VAULT сначала обещает код операции, позволяющий потребителю обновить весь лист дерева скриптов, передавая параметры в код операции с новой транзакцией; Речь идет уже не о «проверке входящих данных на основе определенных критериев», а о «генерации новых значимых данных на основе входящих данных», хотя вычислительные возможности, которые он может включить, ограничены.
(2) Полное предложение OP_VAULT также использует некоторые предложения по политике мемпула (например, транзакции v3) для достижения лучших результатов. Это напоминает нам о том, что значение слова «программирование» может быть шире, чем мы думаем. (Похожий пример — Open Transaction в сети Nervos.) ）
V. Понимание CKB
В двух предыдущих разделах мы описываем, как мы можем создавать сценарии для интересных приложений на более ограниченной структуре (Bitcoin UTXO); Также были представлены предложения о том, чтобы попытаться добавить интроспекцию в такую структуру.
Несмотря на то, что UTXO могут программировать эти приложения, читатели могут легко заметить их недостатки или области, которые можно оптимизировать, например:
В LN-Punishment участники канала должны сохранять каждую прошлую совершенную транзакцию и соответствующее значение секрета штрафа, чтобы разобраться с мошенничеством оппонента, которое представляет собой бремя хранения. Если существует механизм, который гарантирует, что вступит в силу только самая последняя транзакция обязательства, а старая транзакция обязательств — нет, это может устранить это бремя, а также может устранить проблему случайного штрафа узлов за ошибочный ввод в цепочку более старой транзакции обязательства.
В DLC предполагается, что существует множество возможных исходов события, и есть много подписей, которые обе стороны должны заранее сгенерировать и передать друг другу, что также является огромным бременем; Кроме того, доход от DLC-контракта напрямую привязан к публичному ключу, поэтому его позицию непросто перенести, есть ли способ перенести позицию контракта?
На самом деле, биткоин-сообщество придумало ответы на эти вопросы, в основном связанные с предложением Сигаша (BIP-118 AnyPrevOut).
Однако, если бы мы программировали на CKB, то BIP-118 был бы доступен уже сейчас (такие сигашные теги можно было бы имитировать с возможностью интроспективной и целенаправленной проверки подписей).
Научившись программировать Bitcoin, мы не только знаем, как их можно запрограммировать в формате «Transaction Output» (что можно запрограммировать в CKB), но и как улучшить эти приложения (и как мы можем использовать возможности CKB для их улучшения, если запрограммируем их на CKB). Для разработчиков CKB программирование на основе Bitcoin Script может быть использовано в качестве учебного материала или даже ярлыка.
Ниже поочередно разберем программируемость каждого модуля программирования CKB. Давайте пока не будем рассматривать самоанализ.
Как упоминалось выше, UTXO не могут быть запрограммированы на произвольные вычисления. Lock, с другой стороны, означает, что Lock может программировать все (до развертывания ограничения) на основе UTXO, включая, помимо прочего, Lightning Channel и DLC, упомянутые выше.
Кроме того, эта возможность верифицировать произвольные вычисления также делает Lock более гибким, чем UTXO, с точки зрения методов аутентификации. Например, мы можем реализовать канал Lightning на CKB, где одна сторона подписывает ECDSA, а другая сторона использует RSA.
На самом деле, это одна из первых областей, которую люди начали исследовать в CKB: использование этой гибкой возможности аутентификации в самостоятельном хранении пользователя для обеспечения того, что известно как «абстракция счета» - авторизация действительности транзакций и восстановление контроля являются очень гибкими и практически неограниченными. В принципе, это комбинация «множественных трат ветвей» и «произвольных методов аутентификации». Примеры реализаций: кошелек joyid, UniPass.
Кроме того, Lock может реализовывать предложения eltoo, обеспечивая канал Lightning, который должен хранить только последнюю зафиксированную транзакцию (на самом деле, eltoo может упростить все одноранговые контракты).
(2) Программируемый произвольно вычисляемый тип
Как упоминалось выше, одним из основных применений Type является программирование определяемых пользователем функций. В сочетании с Lock это означает, что мы можем реализовать каналы молний на основе UDT (и другие типы контрактов).
На самом деле, разделение между Lock и Type можно рассматривать как обновление безопасности: Lock фокусируется на реализации методов хранения или договорных соглашений, в то время как Type фокусируется на определении определяемых пользователем функций.
Кроме того, возможность запускать проверки на основе определений UDT также позволяет UDT участвовать в контрактах аналогично CKB (UDT является гражданином первого класса).
Например, автор однажды предложил протокол для реализации доверительного кредитования под залог NFT на биткоине. Ключом к такому протоколу является зафиксированная транзакция, в которой стоимость входа меньше, чем стоимость выхода (поэтому она еще не является действительной транзакцией), но как только для транзакции может быть предоставлено достаточное количество входных данных, она становится действительной транзакцией: как только кредитор сможет погасить долг, кредитор не может забрать NFT в стейкинге для себя. Тем не менее, отсутствие доверия в этой транзакции обязательств основано на том, что транзакция проверяет количество входных и выходных данных, поэтому кредитор может использовать биткойн только для погашения кредита - даже если и кредитор, и кредитор готовы принять другую валюту (например, USDT, выпущенную в соответствии с протоколом RGB), транзакция обязательства биткойнов не гарантирует, что кредитор получит свой NFT обратно, если кредитор вернет полную сумму USDT, потому что транзакция Bitcoin понятия не имеет о статусе USDT! (Редакция: Другими словами, невозможно создать совершенную транзакцию, обусловленную погашением USDT.) ）
Если мы сможем инициировать проверку на основе определения UDT, мы сможем заставить кредитора подписать еще одну совершенную транзакцию, которая позволит кредитору использовать USDT для погашения кредита. Транзакция будет проверять количество введенных и выведенных USDT, предоставляя пользователям возврат USDT без доверия.
Поправка: Если предположить, что NFT, используемый в качестве залога, и токен, используемый для погашения, выпущены с использованием одного и того же протокола (например, RGB), то здесь проблема может быть решена, и мы можем построить транзакцию обязательства по протоколу RGB, чтобы переход состояния и погашение NFT могли происходить одновременно (два перехода состояния связаны с транзакциями внутри протокола RGB). Однако, поскольку транзакции RGB также зависят от транзакций Bitcoin, построение транзакций обязательств здесь будет несколько затруднительным. В общем, хотя проблема и решаема, но не может быть решена Токен — гражданин первого сорта.
Далее рассмотрим самоанализ.
(3) Блокировка читает другие блокировки
Это означает полный спектр возможностей программирования на Bitcoin UTXO после того, как предлагаемое ограничение будет реализовано. Это включает в себя упомянутые выше контракты Vault, а также приложения на основе OP_CTV (например, контроль перегрузки).
СюэЦзе как-то упомянул очень интересный пример: вы можете реализовать ячейку счета коллекции на CKB, при использовании такого рода ячейки в качестве входных данных транзакции, если выходная ячейка (ячейка, использующая ту же блокировку) имеет большую емкость, то вход не требует предоставления подписи и не влияет на действительность транзакции. На самом деле, такая клетка была бы невозможна без способности к самоанализу. Эта ячейка инкассового счета идеально подходит в качестве институционального метода получения денег, потому что она объединяет средства и имеет недостаток, заключающийся в отсутствии хорошего чувства конфиденциальности.
(4) Блокировка считывает другие типы (и данные)
Интересным применением этой возможности являются токены стейка. Lock будет решать, может ли он использовать свою собственную емкость, основываясь на количестве токенов в других входах и на то, куда его можно потратить (требуется возможность интроспектировать блокировку).
(5) Тип читает другие блокировки
Не уверен, но можно предположить, что полезно. Например, в Type можно проверить, что блокировки входов и выходов транзакции остаются неизменными.
(6) Тип Scirpt читает другие типы (и данные)
Коллекционные карточки? Соберите n жетонов в обмен на больший жетон :)
VI. Заключение
По сравнению с предыдущими системами смарт-контрактов, которые могут быть запрограммированы с произвольными вычислениями, такими как Ethereum, Nervos Network имеет другую структуру; В результате часто бывает трудно понять сеть Nervos, основываясь на знании систем смарт-контрактов прошлого. В данной работе предложен метод понимания программируемости CKB Cell, начиная с прикладного программирования структуры, которая более ограничена, чем CKB Cell, BTC UTXO. И, используя концепцию «интроспекции» для понимания возможностей «перекрестного доступа» клеток, мы можем разделить ситуации, в которых используются интроспективные способности, и определить их конкретное использование.
Редакция:
Независимо от возможностей перекрестного доступа Cell (т.е. возможностей интроспекции), блокировки можно рассматривать как Биткойн с возможностями состояния и программирования, которые достигли крайности, так что все приложения, основанные на Биткойне, могут быть запрограммированы только на этой основе;
Независимо от возможности перекрестного доступа (т.е. способности к самоанализу) ячейки, различие между блокировками и типами можно рассматривать как обновление безопасности: оно разделяет определение активов и метод хранения UDT; Кроме того, тип s (и данные) разоблачаемого государства достигают эффекта UDT является гражданином первого сорта.
Вышеупомянутые два пункта означают что-то с той же парадигмой, что и «BTC + RGB», но с большими возможностями программирования;
Учитывая интроспективную способность Cell, Cell может получить более сильные возможности программирования, чем пост-ковенанты BTC UTXO, и реализовать то, чего трудно достичь с помощью BTC + RGB (потому что BTC не может читать состояние RGB)
Конкретных примеров такого использования не так много, но это связано с непониманием автором экологии ЦКБ. Считается, что со временем в него будет вкладываться все больше фантазии, и будут составляться невообразимые сегодня приложения.
Благодарности
Спасибо Retric, Jan Xie и Xue Jie за их отзывы во время написания статьи. Конечно, я несу ответственность за все ошибки в тексте.
Список литературы
Учетные записи, списки строгого доступа и UTXO
Ограничения в Bitcoin: Таксономия для ознакомления
Модель ячейки
Nervos CKB в двух словах
Программируемость биткоина
Абстракция по счету (2022)
Что такое абстрактное синтаксическое дерево Bitcoin Merkelized?
BIP 345: Предложение OP_VAULT
Введение в коды операций ограничения TLUV
Компоненты, составляющие контракт, обновляются с помощью Биткойна
Элту объяснил
Договор займа под залог NFT, основанный на совершенных сделках · btc-study/OP_QUESTION · Дискуссия #7
Ссылка на оригинальную статью
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Понимание программируемости CKB из программирования приложений Bitcoin
Автор оригинала: Ajian
Резюме
Понимание программируемости системы требует от нас определения структурных особенностей системы. Изучение прикладного программирования на основе Bitcoin Script помогает нам понять базовую структуру CKB Cell и его парадигму программирования. Кроме того, он разбивает программные компоненты CKB на нужные части и помогает нам понять преимущества программируемости, которые приносит каждая часть.
I. Введение
«Программируемость» — это измерение, которое люди часто используют при сравнении блокчейн-систем. Тем не менее, часто возникают разногласия по поводу того, как описывается программируемость. Распространенным выражением является «XX блокчейн поддерживает Тьюринг-полные языки программирования» или «XX блокчейн поддерживает программирование общего назначения», что призвано указать, что «XX блокчейн» здесь обладает сильной программируемостью. В этих утверждениях есть доля правды: системы, поддерживающие полное по Тьюрингу программирование, как правило, легче программировать, чем те, которые этого не делают. Однако в структурных характеристиках системы смарт-контрактов есть много аспектов, и данное утверждение затрагивает только один из них, поэтому его недостаточно разбираться достаточно глубоко в силу того, что разработчики не руководствуются им, а на обычных пользователей нельзя положиться в отличии мошенничества.
К структурным особенностям системы смарт-контрактов можно отнести:
Поэтому, помимо «программируемых произвольных вычислений», существует как минимум четыре характеристики, влияющие на программируемость системы смарт-контрактов. Можно даже сказать, что эти другие особенности более важны, потому что они определяют на более глубоком уровне, чего легко достичь, а чего трудно; Что такое более экономичная реализация, а какая менее эффективная.
Например, Ethereum часто приводится в качестве примера хорошей программируемости, но основной формой выражения состояния в Ethereum является учетная запись, что затрудняет программирование одноранговых контрактов (например, платежных шлюзов, контрактов на ставки один к одному) — не абсолютно невозможно, просто неблагодарно. Экосистема Ethereum нередко пытается реализовать платежный канал/государственный канал, и было много теоретических дискуссий, но эти проекты, похоже, больше не активны — и это, очевидно, нельзя винить в отсутствии усилий со стороны разработчиков. Не случайно, что проекты, активные на Ethereum сегодня, принимают форму «пулов», а не «одноранговых контрактов». Точно так же люди могут быть довольны программируемостью Ethereum, но модель учетной записи по своей сути недостаточна для достижения «абстракции учетной записи» (которую также можно понимать как обобщение концепции кошелька).
Точно так же изучение программируемости CKB также требует от нас понимания структурных характеристик системы смарт-контрактов CKB в этих аспектах. Что мы уже знаем, так это то, что CKB позволяет программировать произвольные вычисления, позволяет записывать дополнительное состояние в контракте и позволяет одному контракту получать доступ к состоянию другого контракта при выполнении. Однако форма контракта представляет собой выход транзакции (называемой «ячейкой»), что принципиально отличает его от Ethereum. Таким образом, понимание системы смарт-контрактов Ethereum и экземпляров контрактов в ней не помогает нам понять, как CKB реализует эти структурные особенности, а также не помогает нам понять программируемость CKB.
К счастью, смарт-контракты на Биткойне, похоже, обеспечивают лучшую основу для понимания программируемости CKB. Это связано не только с тем, что основной формой представления состояния Биткойна также является выход транзакций (называемых «UTXO»), но и потому, что с помощью концепции, предложенной сообществом Биткойна под названием «ковенанты», мы можем понять, почему CKB обладает такими структурными характеристиками, и соответствующим образом разбить конечный эффект на несколько частей, определив преимущества программируемости, которые приносит каждая из них.
II. CKB против BTC: что еще?
(1) Базовая структура
В качестве основной формы представления состояния Биткойна, UTXO Биткойна («Неизрасходованный вывод транзакции») имеет два поля:
По сравнению с системами смарт-контрактов, которые появились позже, Bitcoin Script довольно ограничен:
Этот вид сценариев, хотя и ограничен, не лишен возможности программировать удивительные приложения, и это основа нашего исследования программируемости CKB. Позже будет раздел, в котором будут представлены два примера программирования Bitcoin Script.
В отличие от этого, единица состояния ЦКБ называется «ячейкой» и имеет четыре поля:
Кроме того, Lock и Type могут быть запрограммированы для произвольных вычислений. Вы можете запрограммировать любой алгоритм проверки подписи, вы можете запрограммировать любой алгоритм хеширования для проверки прообразов и так далее.
Читатели легко видят, как программируемость Cell улучшается по сравнению с UTXO:
В сочетании со структурой «транзакционного выхода» самой ячейки, преимущества этих двух точек сами по себе весьма и весьма существенны, но только из приведенного выше описания мы не знаем, как ячейка достигает «один контракт обращается к состоянию другого контракта во время выполнения». Для этого нужно опираться на концепцию, которая уже давно обсуждается в биткоин-сообществе: «ковенанты».
(2) Ограничения и самоанализ
Первоначальная цель ограничительной оговорки состоит в том, чтобы ограничить то, куда может быть потрачена денежная сумма. На текущий Биткойн (где не было предложено никаких ограничений) одна сумма денег, после разблокировки, может быть потрачена где угодно (она может быть выплачена на произвольный публичный ключ скрипта). Но идея оговорки об ограничении заключается в том, что они могут быть потрачены таким образом, чтобы ограничить их определенными местами, например, определенный UTXO будет потрачен только определенной транзакцией, так что даже если кто-то может предоставить подпись для UTXO, то, куда они могут быть потрачены, уже определено этой транзакцией. Это может показаться немного странным, но это может привести к некоторым интересным приложениям, которые будут рассмотрены в следующем разделе. Важно отметить, что это ключ к нашему дальнейшему пониманию программируемости CKB.
Расти Рассел справедливо отмечает, что ограничение можно понимать как способность к «интроспекции» торговли, т.е. когда UTXO A тратится на транзакцию B, оператор скрипта может прочитать некоторые (или все) транзакции B, а затем проверить, соответствуют ли они параметрам, предварительно запрошенным сценарием. Например, соответствует ли открытый ключ скрипта для первого вывода транзакции A тому, что требуется открытым ключом скрипта UTXO A (это то, что изначально означало ограничение).
Проницательный читатель поймет, что при полной интроспекции входные данные одной транзакции могут считывать состояние других входных данных той же транзакции, что позволяет одному контракту получить доступ к состоянию другого контракта во время выполнения. На самом деле, именно так и был разработан CKB Cell.
Исходя из этого, мы можем разделить эту полную интроспективную способность на четыре сценария:
Это позволяет нам проанализировать роль интроспективных возможностей каждой части в различных сценариях использования при определенных допущениях (разделение функций между Lock и Type), т.е. выигрыш в программируемости, который приносит нам каждая часть.
В следующих двух разделах мы рассмотрим текущее (и еще не предложенное) программирование Bitcoin Script и вероятную функциональность, которой, как ожидается, достигнет предлагаемое ограничение, чтобы дать конкретное понимание того, как можно запрограммировать и сделать CKB Cell лучше.
III. Программирование скриптов Биткоина
В этом разделе мы будем использовать «Lightning Channel/Lightning Network» и «Контракт Caution Journal (DLC)» в качестве примеров прикладного программирования на основе Bitcoin Script. Прежде чем мы перейдем к этому, давайте рассмотрим две вещи.
(1) ОП_IF и «Обязательственные сделки»
Первая концепция — это код операции управления потоком в Bitcoin Script, например: OP_IF, OP_ELSE. Эти коды операций ничем не отличаются от IF в компьютерном программировании, и их целью является выполнение различных операторов на основе разных входных данных. В контексте Bitcoin Script это означает, что мы можем установить несколько путей разблокировки средств; В сочетании с функцией блокировки времени это означает, что мы можем назначать приоритет действиям.
Возьмем в качестве примера знаменитый «Hash Timelock Contract (HTLC)», который переводится на разговорный язык:
Это «или... или...» Эффект достигается за счет опкода управления процессом.
Наиболее заметным преимуществом > HTLC является то, что он может объединять несколько операций вместе и распылять их. Например, если Алиса хочет обменять BTC на CKB с Бобом, то Боб может сначала дать хеш-значение и создать HTLC в сети Nervos. Затем Алиса создает HTLC на Биткойне, который использует тот же хэш. В качестве альтернативы Боб берет BTC, оплаченные Алисой на биткойны, а также раскрывает прообраз, позволяя Алисе вывести CKB в сети Nervos. В любом случае, Боб не раскрывает оригинальное изображение, оба контракта истекают, и Алиса и Боб могут вернуть деньги, которые они вложили.
После активации софтфорка Taproot эта функция множественной разблокировки пути еще больше расширяется за счет введения MAST (Merkle Abstract Syntax Tree): мы можем превратить путь разблокировки в лист на дереве Меркла, каждый лист независим, поэтому больше нет необходимости использовать такой код операции управления потоком; Кроме того, поскольку один путь раскрывается, не раскрывая другие, мы можем добавить большее количество путей разблокировки к выходу, не беспокоясь об экономике.
Вторая концепция – это «торговля обязательствами». Идея зафиксированной транзакции заключается в том, что в некоторых случаях действительная транзакция Биткойна, даже если она не подтверждена блокчейном, так же реальна и обязательна.
Например, у Алисы и Боба общий UTXO, который требует, чтобы они оба были подписаны, чтобы тратить. В этот момент Алиса создает транзакцию, чтобы потратить его, передавая 60% его стоимости Бобу, а остальное себе; Алиса ставит свою подпись для транзакции, которая затем отправляется Бобу. Что ж, для Боба это не обязательно должно транслироваться в сеть Биткойна, и это не должно быть подтверждено блокчейном, и платежный эффект этой транзакции также реален и заслуживает доверия. Поскольку Алиса не может потратить UTXO самостоятельно (и, следовательно, не может потратить их повторно), а также потому, что подпись, предоставленная Алисой, действительна, Боб всегда может добавить свою подпись и транслировать транзакцию для выполнения платежа. Другими словами, Алиса предоставила Бобу «надежное обязательство» через эту действительную (вне сети) транзакцию.
Зафиксированные транзакции являются основной концепцией программирования приложений Биткойна. Как упоминалось ранее, контракт Биткойна основан на верификации, не имеет состояния и не допускает перекрестного доступа; Однако, если контракт не содержит состояний, где эти состояния хранятся и как контракт может безопасно двигаться вперед (изменять состояние)? Транзакции обязательств дают простой ответ: состояние контракта может быть выражено в виде транзакций, так что участники контракта могут сами сохранить состояние без необходимости отображать его в блокчейне; Проблема изменения состояния контракта также может трансформироваться в проблему того, как безопасно обновить совершенную транзакцию; Кроме того, если мы обеспокоены опасностями заключения контракта (например, заключение контракта, который требует, чтобы обе стороны подписали, чтобы потратить, и есть риск, что другая сторона не отреагирует и застрянет), то простое создание транзакции обязательства, которая заранее обойдется контракту, и получение подписи может снизить риск и устранить доверие к другим участникам.
(2) Канал Lightning и сеть Lightning
Канал молнии — это контракт «один к одному», в котором две стороны могут платить друг другу неограниченное количество раз без подтверждения блокчейном ни одного платежа. Как и следовало ожидать, он использует торговлю обязательствами.
В разделе «Зафиксированные транзакции» мы уже представили платежный канал. Тем не менее, этот тип контракта, который использует только мультиподпись 2 из 2, может обеспечить только односторонние платежи. То есть либо Алиса всегда платит Бобу, либо Боб всегда платит Алисе до тех пор, пока не израсходует свой остаток по контракту. Если это двусторонний платеж, это означает, что после обновления статуса у одной из сторон может быть меньше баланса, чем раньше, но у ЦА есть последняя зафиксированная транзакция, подписанная другой стороной - что можно сделать, чтобы ТА не транслировала старое обещание, а ЦА - только самую последнюю транзакцию обязательства?
Решение этой проблемы с каналом молнии называется «LN-Penalty». Теперь предположим, что у Алисы и Боба есть по 5 BTC в канале; Теперь Алиса хочет заплатить Бобу 1 BTC, поэтому подписывает обещанную транзакцию и отправляет ее Бобу:
Боб также подписывает обязательство (которое соответствует описанной выше транзакции) и отправляет его Алисе:
Хитрость здесь заключается в этом «совместном временном открытом ключе», который генерируется с использованием одного из ее собственных открытых ключей и открытого ключа, предоставленного другой стороной, например, совместный временный открытый ключ Алисы и Боба, который Алиса получает с помощью одного из своих собственных открытых ключей и открытого ключа, предоставленного Бобом, умножая каждый на хэш-значение. Когда генерируется такой публичный ключ, никто не знает его закрытого ключа. Однако, если Боб сообщит Алисе закрытый ключ открытого ключа, который он предоставил, Алиса сможет вычислить закрытый ключ федеративного временного открытого ключа. - Это ключ к тому, что Lightning Channel может «отменить» старое состояние.
В следующий раз, когда обе стороны захотят обновить статус канала (инициировать платеж), обе стороны обмениваются закрытым ключом временного открытого ключа, предоставленного друг другу в предыдущем раунде. Таким образом, участники больше не решаются транслировать последнюю обещанную транзакцию, которую они получили: выход этой обещанной транзакции, присваивающей ценность их собственной стороне, имеет два пути, а закрытый ключ пути временного открытого ключа уже известен другой стороне; Таким образом, как только транзакция старого обязательства будет транслироваться, другая сторона может немедленно использовать этот совместный временный закрытый ключ, чтобы забрать все средства в этом выходе. - Это и есть "LN-Penalty".
В частности, порядок взаимодействия следующий: сторона, инициирующая платеж, сначала запрашивает у другой стороны новый временный публичный ключ, а затем конструирует новую транзакцию обязательства и передает ее другой стороне; Сторона, получившая обещанную транзакцию, раскрывала другой стороне закрытый ключ временного открытого ключа, который она дала в предыдущем раунде. Такая последовательность взаимодействий гарантирует, что участники всегда получают новую транзакцию обязательства, прежде чем признать недействительной транзакцию обязательства, полученную ими в предыдущем раунде, и, следовательно, не требует доверия.
Таким образом, основными конструкциями канала молнии являются:
Наконец, поскольку HTLC также может быть помещен в зафиксированную транзакцию, канал Lightning также может пересылать платежи. Предполагая, что Алиса может найти путь, состоящий из каналов Lightning, соединяющихся до и после, чтобы связаться с Дэниелом, тогда можно достичь ненадежных многоскачковых платежей, не открывая канал с Дэниелом. Это Lightning Network:
Когда Алиса находит такой путь и хочет заплатить Дэниелу, она просит у Дэниела хэш, чтобы создать HTLC для Боба, и предлагает Бобу переслать сообщение Кэрол и предоставить тот же HTLC; В сообщении Кэрол предлагается переслать сообщение Дэниелу и предоставить тот же HTLC. Когда новости доходят до Дэниела, он раскрывает Кэрол прообраз, который дает ему ценность HTLC и обновляет состояние контракта. Кэрол сделала то же самое, получив деньги от Боба и обновив статус канала; Наконец, Боб показывает прообраз Алисе и обновляет статус. Из-за природы HTLC эта цепочка платежей либо успешна, либо терпит неудачу одновременно, и поэтому она не требует доверия.
Lightning Network состоит из одного канала, идущего один за другим, каждый из которых независим друг от друга. Это означает, что Алисе нужно знать, что происходит на ее канале с Бобом, независимо от того, сколько взаимодействий произошло на каналах других людей, какую валюту они используют и даже используют ли они канал на самом деле.
Масштабируемость Lightning Network отражается не только в том, что скорость платежей в канале Lightning ограничена только инвестициями аппаратных ресурсов обеими сторонами, но и в том, что благодаря децентрализованному хранению состояния один узел может использовать максимальное кредитное плечо с наименьшими затратами.
(3) Будьте осторожны с журнальными контрактами
Предостерегающий контракт журналирования (DLC) использует криптографическую технику, называемую «подписью адаптера», которая позволяет Bitcoin Script программировать финансовые контракты, зависящие от внешних событий.
Подписи адаптера позволяют подписи стать действительной подписью только после добавления закрытого ключа. Возьмем, к примеру, подпись Шнорра, где стандартная форма подписи Шнорра (R, s), где:
Допустим, я даю пару данных (R, s'), где:
Очевидно, что это не действительная подпись Шнорра, и она не проходит формулу валидации, но я могу доказать проверяющему, что она может быть действительной подписью, просто зная закрытый ключ R 2, r 2:
Подписи адаптера делают действительность подписи зависимой от секретных данных и поддается проверке. Но какое это имеет отношение к финансовым контрактам?
Допустим, Алиса и Боб хотят сделать ставку на исход игры с мячом. Алиса и Боб поставили на победу Зеленого Гоблина и Алину соответственно со ставкой в 1 BTC. Кроме того, Carol, веб-сайт футбольных обзоров, пообещал использовать одноразовый R_c для публикации подписанного s_c_i результатов, когда будут объявлены результаты игры.
Как видно, есть три возможных исхода (таким образом, есть 3 варианта подписи Кэрол):
Зеленый гоблин выигрывает, Алиса выигрывает 1 BTC
Алина выигрывает, а Боб выигрывает 1 BTC
Ничья, средства двоих возвращаются одинаково
Для этого они создают сделку по обязательствам для каждого результата. Например, транзакция обязательства, созданная для первого результата, будет выглядеть следующим образом:
Однако вместо (R, s) подпись Алисы и Боба, созданная для этой транзакции, является сигнатурой адаптера (R, s'); Другими словами, подписи, поставленные друг другу обеими сторонами, не могут быть использованы непосредственно для разблокировки контракта, но должны раскрывать тайную ценность. Эта тайная ценность является прообразом s_c_ 1.G, который является подписью Кэрол! Поскольку значение nonce сигнатуры Кэрол определено (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) Ончейн-наблюдатели (включая Кэрол) не смогут определить, какой веб-сайт они используют, благодаря исполнению контракта Алисы и Боба, или даже то, что их контракт является контрактом на ставки (а не каналом молнии).
IV. Введение в применение ограничений
(a) OP_CTV и контроль перегрузок
Разработчики биткоин-сообщества внесли ряд предложений, которые можно отнести к ограничительным оговоркам. На данный момент одним из самых известных предложений является OP_CHECKTEMPLATEVERIFY (OP_CTV), который популярен среди биткоин-сообщества своей простотой, но гибкостью благодаря своей простой концепции. Идея OP_CTV заключается в том, чтобы зафиксировать хэш в скрипте, чтобы ограничить, что средства могут быть потрачены только транзакциями, представленными этим хешем; Этот хеш обещает выход транзакции и большинство полей, но не вход транзакции, а только количество входов.
«Контроль перегрузки» является хорошим примером того, как можно продемонстрировать ОП_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 Кэрол.
То же самое, если Боб или Кэрол захотят вывести деньги. При выводе денег они смогут использовать только те транзакции, которые могут пройти соответствующую проверку OP_CTV, т.е. они смогут выплатить только соответствующую сумму себе, и не смогут произвольно вывести деньги; Оставшиеся средства пойдут в пул с блокировкой OP_CTV, что гарантирует, что оставшиеся пользователи могут быть размещены вне пула без доверия, независимо от порядка, в котором они выводятся.
Если говорить абстрактно, то роль OP_CTV здесь заключается в планировании пути к концу срока действия контракта для контракта, чтобы контракт пула здесь мог сохранять атрибут выхода без доверия, независимо от того, какой путь он выберет или в каком состоянии он находится.
Есть также очень интересное использование этого ОП_CTV: «односторонний платежный канал, который скрыт, но не раскрыт». Предположим, что Алиса формирует такой пул средств и гарантирует, что средства могут быть надежно выведены в вывод с помощью следующего скрипта:
Если бы Алиса не рассказала об этом Бобу, Боб бы не узнал о существовании такого выхода; Как только Алиса покажет его Бобу, Боб сможет использовать выходные данные в качестве чувствительного ко времени одностороннего платежного канала, который Алиса может использовать для немедленной оплаты Бобу, не дожидаясь подтверждения от блокчейна. Боб просто просит Алису поместить его транзакцию обязательств в цепочку, прежде чем Алиса сможет потратить ее самостоятельно.
(б) ОП_Vault и сейф
OP_VAULT — это предложение об ограничительной оговорке, специально разработанной для создания «хранилищ».
Контракт Vault разработан как более безопасная и продвинутая форма самостоятельного хранения. Несмотря на то, что текущий контракт с несколькими подписями может избежать единой точки отказа для одного закрытого ключа, если злоумышленник получит пороговое количество закрытых ключей, владелец кошелька будет беспомощен. Сейф хочет установить единый лимит расходов для ваших средств; В то же время, при снятии с него денег по обычному маршруту, операция вывода будет принудительно выполнять период ожидания; А в период ожидания операция вывода может быть прервана операцией экстренного восстановления кошелька. Даже если такой контракт будет нарушен, владелец кошелька может инициировать встречную операцию (с помощью ветки аварийного восстановления).
Теоретически OP_CTV тоже может запрограммировать такой контракт, но есть много неудобств, одним из которых является комиссия: совершая сделку, она также обещает комиссию, которую заплатит сделка. Учитывая назначение этого контракта, временной интервал между настройкой контракта и снятием денег должен быть очень длинным, поэтому предугадать соответствующую комиссию практически невозможно. Хотя OP_CTV не ограничивает входы, поэтому комиссия может быть увеличена за счет увеличения входа, все предоставленные входные данные станут комиссией, поэтому это нереально; Еще один способ – CPFP, который заключается в предоставлении комиссии на новые транзакции путем расходования выведенных средств. Кроме того, использование OP_CTV означает, что такой контракт Vault не может быть отозван массово (и, конечно, не может быть восстановлен массово).
Предложение OP_VAULT пытается решить эти проблемы, предлагая новые коды операций (OP_VAULT и OP_UNVAULT). OP_UNVAULT предназначен для пакетной устойчивости, поэтому мы пока не будем упоминать о нем. OP_VAULT ведет себя следующим образом: когда мы помещаем его в ветвь дерева скриптов, он может быть использован для фиксации в пригодный для использования код операции (например, OP_CTV) без конкретных параметров; При проведении этой ветки транзакции могут передаваться в определенных параметрах, но не в других ветках. В результате, ему не нужно устанавливать заранее установленную плату, и ее можно установить, когда ветка исчерпана; Предполагая, что ветка также имеет временную блокировку, она будет принудительно применена; Наконец, поскольку вы можете изменить только ветку, в которой вы находитесь, и никакая другая ветвь нового дерева сценариев (включая ветвь аварийного восстановления) не будет изменена, мы можем прервать такие выводы.
Кроме того, стоит упомянуть два момента: (1) опкод OP_VAULT ведет себя аналогично другому предложению ограничения: OP_TLUV; Джереми Рубин (Jeremy Rubin) справедливо отмечает, что это в определенной степени породило концепцию «вычисления»: OP_TLUV/OP_VAULT сначала обещает код операции, позволяющий потребителю обновить весь лист дерева скриптов, передавая параметры в код операции с новой транзакцией; Речь идет уже не о «проверке входящих данных на основе определенных критериев», а о «генерации новых значимых данных на основе входящих данных», хотя вычислительные возможности, которые он может включить, ограничены.
(2) Полное предложение OP_VAULT также использует некоторые предложения по политике мемпула (например, транзакции v3) для достижения лучших результатов. Это напоминает нам о том, что значение слова «программирование» может быть шире, чем мы думаем. (Похожий пример — Open Transaction в сети Nervos.) ）
V. Понимание CKB
В двух предыдущих разделах мы описываем, как мы можем создавать сценарии для интересных приложений на более ограниченной структуре (Bitcoin UTXO); Также были представлены предложения о том, чтобы попытаться добавить интроспекцию в такую структуру.
Несмотря на то, что UTXO могут программировать эти приложения, читатели могут легко заметить их недостатки или области, которые можно оптимизировать, например:
На самом деле, биткоин-сообщество придумало ответы на эти вопросы, в основном связанные с предложением Сигаша (BIP-118 AnyPrevOut).
Однако, если бы мы программировали на CKB, то BIP-118 был бы доступен уже сейчас (такие сигашные теги можно было бы имитировать с возможностью интроспективной и целенаправленной проверки подписей).
Научившись программировать Bitcoin, мы не только знаем, как их можно запрограммировать в формате «Transaction Output» (что можно запрограммировать в CKB), но и как улучшить эти приложения (и как мы можем использовать возможности CKB для их улучшения, если запрограммируем их на CKB). Для разработчиков CKB программирование на основе Bitcoin Script может быть использовано в качестве учебного материала или даже ярлыка.
Ниже поочередно разберем программируемость каждого модуля программирования CKB. Давайте пока не будем рассматривать самоанализ.
(1) Программируемая произвольно рассчитанная блокировка
Как упоминалось выше, UTXO не могут быть запрограммированы на произвольные вычисления. Lock, с другой стороны, означает, что Lock может программировать все (до развертывания ограничения) на основе UTXO, включая, помимо прочего, Lightning Channel и DLC, упомянутые выше.
Кроме того, эта возможность верифицировать произвольные вычисления также делает Lock более гибким, чем UTXO, с точки зрения методов аутентификации. Например, мы можем реализовать канал Lightning на CKB, где одна сторона подписывает ECDSA, а другая сторона использует RSA.
На самом деле, это одна из первых областей, которую люди начали исследовать в CKB: использование этой гибкой возможности аутентификации в самостоятельном хранении пользователя для обеспечения того, что известно как «абстракция счета» - авторизация действительности транзакций и восстановление контроля являются очень гибкими и практически неограниченными. В принципе, это комбинация «множественных трат ветвей» и «произвольных методов аутентификации». Примеры реализаций: кошелек joyid, UniPass.
Кроме того, Lock может реализовывать предложения eltoo, обеспечивая канал Lightning, который должен хранить только последнюю зафиксированную транзакцию (на самом деле, eltoo может упростить все одноранговые контракты).
(2) Программируемый произвольно вычисляемый тип
Как упоминалось выше, одним из основных применений Type является программирование определяемых пользователем функций. В сочетании с Lock это означает, что мы можем реализовать каналы молний на основе UDT (и другие типы контрактов).
На самом деле, разделение между Lock и Type можно рассматривать как обновление безопасности: Lock фокусируется на реализации методов хранения или договорных соглашений, в то время как Type фокусируется на определении определяемых пользователем функций.
Кроме того, возможность запускать проверки на основе определений UDT также позволяет UDT участвовать в контрактах аналогично CKB (UDT является гражданином первого класса).
Например, автор однажды предложил протокол для реализации доверительного кредитования под залог NFT на биткоине. Ключом к такому протоколу является зафиксированная транзакция, в которой стоимость входа меньше, чем стоимость выхода (поэтому она еще не является действительной транзакцией), но как только для транзакции может быть предоставлено достаточное количество входных данных, она становится действительной транзакцией: как только кредитор сможет погасить долг, кредитор не может забрать NFT в стейкинге для себя. Тем не менее, отсутствие доверия в этой транзакции обязательств основано на том, что транзакция проверяет количество входных и выходных данных, поэтому кредитор может использовать биткойн только для погашения кредита - даже если и кредитор, и кредитор готовы принять другую валюту (например, USDT, выпущенную в соответствии с протоколом RGB), транзакция обязательства биткойнов не гарантирует, что кредитор получит свой NFT обратно, если кредитор вернет полную сумму USDT, потому что транзакция Bitcoin понятия не имеет о статусе USDT! (Редакция: Другими словами, невозможно создать совершенную транзакцию, обусловленную погашением USDT.) ）
Если мы сможем инициировать проверку на основе определения UDT, мы сможем заставить кредитора подписать еще одну совершенную транзакцию, которая позволит кредитору использовать USDT для погашения кредита. Транзакция будет проверять количество введенных и выведенных USDT, предоставляя пользователям возврат USDT без доверия.
Далее рассмотрим самоанализ.
(3) Блокировка читает другие блокировки
Это означает полный спектр возможностей программирования на Bitcoin UTXO после того, как предлагаемое ограничение будет реализовано. Это включает в себя упомянутые выше контракты Vault, а также приложения на основе OP_CTV (например, контроль перегрузки).
СюэЦзе как-то упомянул очень интересный пример: вы можете реализовать ячейку счета коллекции на CKB, при использовании такого рода ячейки в качестве входных данных транзакции, если выходная ячейка (ячейка, использующая ту же блокировку) имеет большую емкость, то вход не требует предоставления подписи и не влияет на действительность транзакции. На самом деле, такая клетка была бы невозможна без способности к самоанализу. Эта ячейка инкассового счета идеально подходит в качестве институционального метода получения денег, потому что она объединяет средства и имеет недостаток, заключающийся в отсутствии хорошего чувства конфиденциальности.
(4) Блокировка считывает другие типы (и данные)
Интересным применением этой возможности являются токены стейка. Lock будет решать, может ли он использовать свою собственную емкость, основываясь на количестве токенов в других входах и на то, куда его можно потратить (требуется возможность интроспектировать блокировку).
(5) Тип читает другие блокировки
Не уверен, но можно предположить, что полезно. Например, в Type можно проверить, что блокировки входов и выходов транзакции остаются неизменными.
(6) Тип Scirpt читает другие типы (и данные)
Коллекционные карточки? Соберите n жетонов в обмен на больший жетон :)
VI. Заключение
По сравнению с предыдущими системами смарт-контрактов, которые могут быть запрограммированы с произвольными вычислениями, такими как Ethereum, Nervos Network имеет другую структуру; В результате часто бывает трудно понять сеть Nervos, основываясь на знании систем смарт-контрактов прошлого. В данной работе предложен метод понимания программируемости CKB Cell, начиная с прикладного программирования структуры, которая более ограничена, чем CKB Cell, BTC UTXO. И, используя концепцию «интроспекции» для понимания возможностей «перекрестного доступа» клеток, мы можем разделить ситуации, в которых используются интроспективные способности, и определить их конкретное использование.
Редакция:
Вышеупомянутые два пункта означают что-то с той же парадигмой, что и «BTC + RGB», но с большими возможностями программирования;
Конкретных примеров такого использования не так много, но это связано с непониманием автором экологии ЦКБ. Считается, что со временем в него будет вкладываться все больше фантазии, и будут составляться невообразимые сегодня приложения.
Благодарности
Спасибо Retric, Jan Xie и Xue Jie за их отзывы во время написания статьи. Конечно, я несу ответственность за все ошибки в тексте.
Список литературы
Учетные записи, списки строгого доступа и UTXO
Ограничения в Bitcoin: Таксономия для ознакомления
Модель ячейки
Nervos CKB в двух словах
Программируемость биткоина
Абстракция по счету (2022)
Что такое абстрактное синтаксическое дерево Bitcoin Merkelized?
BIP 345: Предложение OP_VAULT
Введение в коды операций ограничения TLUV
Компоненты, составляющие контракт, обновляются с помощью Биткойна
Элту объяснил
Договор займа под залог NFT, основанный на совершенных сделках · btc-study/OP_QUESTION · Дискуссия #7
Ссылка на оригинальную статью