З Bitcoin програмування застосунків, тисячі слів докладно пояснюють програмованість CKB

Наступний вміст є перепостом з форуму Nervos Talk, автор - Аджан (головний редактор платформи з контенту про Біткойн BTC Study).

Опис

Розуміння програмованості системи вимагає розпізнавання її структурних особливостей. Дослідження програмування за допомогою біткоїнового скрипту допомагає нам зрозуміти основну структуру CKB Cell та її програмувальні парадигми. Крім того, це дозволяє розкласти програмові компоненти CKB на відповідні частини і допомагає зрозуміти зростання програмованості кожної частини.

1. Вступ

01928374656574839201

“«Програмованість» є одним з аспектів, який люди часто використовують для порівняння систем блокчейну. Однак, існує багато різних способів опису програмованості. Один з поширених варіантів - «Блокчейн XX підтримує мову програмування, що є повноцінною за Тюрінгом», або «XX блокчейн підтримує загальне програмування», що позначає, що блокчейн XX має велику програмованість. Ці висловлення мають свою логіку: системи, які підтримують повноцінне програмування, зазвичай є легше в програмуванні, ніж ті, які не підтримують. Однак, структурні характеристики системи смарт-контрактів мають багато аспектів, і цей вислів стосується лише одного з них, тому він не дає достатньо глибокого розуміння: розробники не отримують з нього настанови, а звичайні користувачі не можуть використовувати його для розпізнавання шахрайства.”

Смарт-контракт системи має такі структурні особливості:

• Основна форма вираження стану (контракт) (рахунок проти виведення операції)
• Чи дозволяється будь-який обчислення програмувати (це стосується аспекту, який відноситься до “повноти за Тюрінгом”)
• Виконавчий процес може створювати нові дані або лише повертати булеве значення? (Обчислення vs. Перевірка)
• Чи дозволяється записувати додатковий стан в контракті
• Чи може контракт отримати доступ до стану іншого контракту під час виконання 01928374656574839201

Таким чином, окрім “можливості програмування обчислень”, є щонайменше чотири інші аспекти, які впливають на можливість програмування системи смарт-контрактів. Можна сказати, що ці інші аспекти навіть важливіші, оскільки вони глибше визначають, що легко реалізувати, а що складно; що є більш економічним для реалізації, а що є менш ефективним для реалізації.

“Наприклад, Ethereum часто використовується як приклад гарної програмованості, але його базова форма вираження стану - це рахунок, що ускладнює програмування контрактів точка-точка (наприклад, платіжні канали, контракти на парі) - не є абсолютно неможливим, але дуже складним і неефективним. В екосистемі Ethereum були проекти, які намагалися реалізувати платіжні канали / канали стану, і було багато теоретичних досліджень, але на сьогодні ці проекти, здається, неактивні - це, очевидно, не через недостатнє зусилля розробників. Зараз активні проекти на Ethereum використовують форму “фінансового басейну”, а не “точка-точка контракти”, і це не випадково. Так само, хоча, можливо, багато людей задоволені програмованістю Ethereum, але якщо ми хочемо реалізувати “абстракцію рахунку” (або узагальнення поняття гаманця), модель рахунку, мабуть, має вроджену недолік.”

Так само, для дослідження програмованості CKB, нам потрібно зрозуміти структурні особливості системи смарт-контрактів CKB в цих аспектах. Ми вже знаємо, що CKB дозволяє програмувати будь-який обчислення, дозволяє записувати додатковий стан у контракті та дозволяє контракту отримувати доступ до стану іншого контракту під час виконання. Однак, його форма контракту є вихідним транзакції (відомого як “Cell”), що робить його фундаментально відмінним від Ethereum. Тому розуміння системи смарт-контрактів Ethereum та її контрактних екземплярів не допоможе нам зрозуміти, як CKB реалізує ці структурні особливості та не допоможе нам усвідомити його програмованість.

Щасливо, інтелектуальні контракти на біткойн, здається, надають найкращу основу для розуміння програмованості CKB. Це стосується не лише того, що основною формою вираження стану біткойн є вихід транзакції, відомий як “UTXO”, але й того, що за допомогою концепції “обмежувальних умов” (covenants), запропонованої спільнотою біткойн, ми можемо зрозуміти причини наявності таких структурних особливостей в CKB і розбити кінцевий ефект на кілька частин, поступово розпізнавши приріст програмованості, якими кожна з них володіє.

2. CKB v.s. BTC: що додається?

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

Як основна форма вираження стану біткойна, UTXO (невитрачений вихід транзакції) біткойна має два поля:

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

У порівнянні з пізніше з’явившоюся системою смарт-контрактів, біткойн-скрипт є досить обмеженим:

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

Цей сценарій, хоч і обмежений, але має здатність до створення захоплюючих застосувань програмування. Він є основою для дослідження можливостей програмованості CKB. Наступний розділ присвячений двом прикладам програмування скриптів Bitcoin.

Навпаки, станова одиниця CKB називається “Cell” і має чотири поля:

• Ємність, схожа на UTXO, виражає розмір простору, який може займати цей Cell, в байтах (байтів).
• Lock, схожий на скриптовий публічний ключ UTXO, визначає власність цієї комірки; тільки дані, які надаються при замиканні, можуть “оновити” цю комірку (або, можна сказати, звільнити цю комірку та використати цю ємність для мінтингу нової комірки);
• Дані, дані, будь-які дані, їх обсяг обмежується ємністю;
• Type ，додатковий скрипт, який використовується для встановлення умов оновлення даних.

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

Читач легко помітить, що Cell порівняно з UTXO покращується у програмованості:

• Cell може програмувати будь-який обчислювальний процес, а не лише деякі конкретні; його перевірка власності буде більш гнучкою;
• Через Data та Type поля, Cell може зберігати додатковий стан; це дозволяє Cell нести так званий “UDT (користувацький визначений токен)”.

Комбінування самої структури «виходу транзакції» Cell може призвести до значних переваг. Однак лише з цього опису ми не знаємо, як саме Cell реалізує «доступ до стану одного контракту під час виконання іншого контракту». Для цього нам потрібно скористатися концепцією, яку спільнота Біткойн вже давно обговорює: “обмежувальні умови (covenants)”.

Умови обмеження та внутрішня перевірка

Обмеження відноситься до обмеження того, куди можуть бути витрачені гроші. У поточній реалізації Bitcoin (яка ще не має жодних пропозицій щодо обмежень), як тільки кошти розблоковані, їх можна витратити куди завгодно (на будь-який відкритий ключ сценарію). Але ідея обмежень полягає в тому, що можна обмежити їх витрачання лише на певні цілі, наприклад, певний UTXO може бути витрачений тільки певною транзакцією, тому навіть якщо хтось може підписати цей UTXO, місце витрати вже визначено цією транзакцією. Ця функція, схоже, є трохи дивною, але вона може призводити до цікавих застосувань, про які буде окремий розділ пізніше. Важливо, що це ключ для подальшого розуміння програмованості CKB.

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

Проникливий читач помітить, що якщо має повну здатність до самоаналізу, то вхід операції може отримувати стан іншого входу цієї ж операції, що, як ми вже говорили, є здатністю “доступ до стану одного контракту під час виконання іншого контракту”. Насправді, саме так і розроблено CKB Cell.

За цим ми можемо розподілити цю повну здатність до самоаналізу на чотири ситуації.

• Замок зчитує інші (вхідні та вихідні) замки
• Lock 01928374656574839201其它（输入和输出）的 Type （以及 Data）
• Type 讀取其它（輸入和輸出）的 Lock
• Тип 读取其它（输入和输出）的 Type （以及 Data）

Це дозволяє нам аналізувати роль внутрішніх можливостей кожної частини в різних сценаріях за умови певних припущень (функціональне розподіл замків та типів). Іншими словами, аналізується зростання програмованості, яке надають нам кожна частина.

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

Третє. Програмування скриптів Bitcoin

Цей розділ буде використовувати “канали миттєвих платежів / мережу Lightning” та “контрактів уважних журналів (DLC)” як приклади програмування додатків на основі скриптів Bitcoin. Перш ніж розглядати це питання, спочатку слід розібратися з двома концепціями.

OP_IF та “Угода про обіцяну операцію”

Перший концепт - це операційний код у скрипті біткоїна для керування потоком, наприклад: OP_IF, OP_ELSE. Ці операційні коди нічим не відрізняються від умовного оператора IF у комп’ютерному програмуванні, їх функція полягає в виконанні різних операторів в залежності від введених значень. У контексті скрипта біткоїна це означає, що ми можемо встановити кілька шляхів розблокування коштів; у поєднанні з функцією блокування за часом, це означає, що ми можемо призначити пріоритет дій.

Зазначений “Хешований контракт TimeLock (HTLC)” - лише один з прикладів цього скрипта, який можна перекласти простою мовою.

Або Боб може розкрити оригінал зашифрованого значення H, надати свій підпис і витратити ці кошти.

Або Аліса може витратити ці кошти, підписавши їх після періоду T.

Цей ефект “або … або …” реалізується за допомогою операційного коду управління процесом.

HTLC найбільш виразна перевага полягає в тому, що вона може зв’язати кілька операцій разом та забезпечити їх атомізацію. Наприклад, Еліс хоче обміняти CKB на BTC з Бобом, тоді Боб може спочатку надати хеш-значення та створити HTLC на мережі Nervos; після цього Еліс створює HTLC на біткоїні з використанням того ж самого хеш-значення. Або Боб отримує BTC, які оплатила Еліс, на біткоїні та одночасно розкриває походження, що дозволяє Еліс забрати CKB на мережі Nervos. Або Боб не розкриває походження, обидва контракти закінчуються та Еліс та Боб можуть повернути свої вкладені кошти.

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

Друга концепція - “обіцянкова угода”. Ідея обіцянкової угоди полягає в тому, що у деяких випадках ефективна транзакція біткоїном, навіть якщо вона не отримує підтвердження в ланцюжку блоків, все одно є реальною і зобов’язуючою.

Наприклад, Аліса та Боб спільно володіють UTXO, для витрати цього UTXO потрібно підписи обох. В цей момент Аліса створює транзакцію для витрати, переказуючи 60% її вартості Бобу, а решту переказує собі. Аліса підписує цю транзакцію й надсилає її Бобу. Для Боба немає необхідності транслювати цю транзакцію в мережу біткоїна або чекати на підтвердження в блокчейні, ефект оплати цієї транзакції є реальним і надійним. Це через те, що Аліса не може витратити цей UTXO самостійно (таким чином, не може подвійно витратити), і через те, що підпис, який надає Аліса, є дійсним. Боб може в будь-який момент додати свій підпис і транслювати цю транзакцію, щоб здійснити цю оплату. Тобто Аліса через цю дійсну (але не у ланцюжок) транзакцію надала Бобу “надійне зобов’язання”.

Обіцянка угоди - це основна концепція програмування застосунків Біткоїн. Як вже зазначалося, контракти Біткоїну базуються на перевірці, без стану та без можливості перерваного доступу; проте, якщо контракт не має стану, то де зберігаються ці стани і як контракт безпечно продовжується (зміна стану)? Обіцянка угоди надає пряму відповідь: стани контракту можна виразити у формі угод, тому учасники контракту можуть зберігати стани самостійно, не показуючи їх у ланцюжку блоків; проблема зміни стану контракту також може бути перетворена на питання зміни обіцянки угоди з безпечним оновленням; крім того, якщо ми турбуємося про вхід до контракту через ризик (наприклад, вхід до контракту, де потрібен підпис обох сторін для витрати, стикається з ризиком блокування через відсутність відповіді від іншої сторони), то достатньо завчасно згенерувати обіцянку угоди на витрати з контракту та отримати підпис, щоб уникнути ризику та позбавитися відповідальності перед іншими учасниками.

Спалаховий канал та мережа спалахів

“Спалаховий канал - це контракт один до одного, в якому сторони можуть безліч разів здійснювати платежі одна одній, не потребуючи підтвердження від блокчейну. Як ви вже здогадалися, це використовує обіцянкові транзакції.”

У розділі, що пояснює “транзакції на зобов’язання”, ми вже розглянули один канал платежів. Однак цей контракт, який використовує лише 2-of-2 багатопідписні контракти, дозволяє здійснювати лише односторонні платежі. Це означає, що або постійно Аліса платить Бобу, або постійно Боб платить Алісі, поки не вичерпає свій залишок в контракті. Якщо платежі двосторонні, це означає, що після оновлення стану баланс однієї сторони може стати меншим, але у неї все ще є підписана інша стара транзакція на зобов’язання - як можна запобігти тому, щоб вона транслювала стару транзакцію на зобов’язання і транслювала лише найновішу транзакцію на зобов’язання?

“LN-Penalty” розв’язує цю проблему. Нехай, наприклад, Еліс і Боб володіють по 5 BTC в одному каналі. Тепер Еліс хоче заплатити Бобу 1 BTC, тому вона підписує таку зобов’язальну транзакцію і надсилає її Бобу:

Введіть #0, 10 BTC: Alie-Bob 2-of-2 вихід з багатьох підписів (тобто канальний контракт)

Виведення #0, 4 BTC: Аліса односторонній підпис

Виведення №1, 6 BTC: або спільний тимчасовий відкритий ключ Аліси-Боба #1 з одноразовим підписом, або часовий замок T1 з одноразовим підписом Боба.

Боб також підписує транзакцію з обіцянкою (відповідно до вищезгаданої транзакції) і відправляє її Алісі:

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

Виведення #0,6 BTC: Боб одноособовий підпис

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

Цей секрет полягає в “спільному тимчасовому відкритому ключі”, який генерується за допомогою власного відкритого ключа та відкритого ключа, наданого іншою стороною. Наприклад, спільний тимчасовий відкритий ключ Alice-Bob отримується шляхом множення власного відкритого ключа Alice та наданого відкритого ключа Bob на хеш-значення та їх додавання. Такий відкритий ключ ніхто не знає його приватного ключа при генерації. Але якщо Bob повідомить Alice приватний ключ свого наданого відкритого ключа, Alice зможе обчислити приватний ключ цього спільного тимчасового відкритого ключа. Це саме те, що робить можливим “скасування” старого стану в мережі Lightning.

Під час оновлення стану каналу наступного разу (під час ініціювання платежу), сторони обмінюються приватним ключем тимчасового публічного ключа, який був переданий одній стороні протягом попереднього раунду. Таким чином, учасник не буде розголошувати попередню обіцянку про транзакцію, яку він отримав: ця обіцянка має два шляхи для розподілу вартості виходів, але приватний ключ тимчасового публічного ключа вже відомий іншій стороні. Тому якщо стара обіцянка транслюється, інша сторона може негайно використовувати цей об’єднаний приватний тимчасовий ключ, щоб забрати всі кошти з цього виходу. - Ось що означає “LN-Penalty”.

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

Узагальнюючи, ключовими елементами дизайну мережі Lightning є:

Обидві сторони завжди використовують обіцянкову угоду для вираження внутрішнього стану контракту, і використовують зміни сум для вираження оплати;

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

Дві підписані учасниками операції не є однаковою угодою (хоча вони є парними); але завжди підписана транзакція є вигідною для самого учасника, іншими словами, учасник завжди отримує угоду, яка не вигідна для нього.

Цей недолік проявляється ​​в тому, що вихід, який призначає власну вартість, має два шляхи розблокування: один шлях може бути розблокований за допомогою власного підпису, але потребує деякого часу; другий шлях використовує публічний ключ іншої сторони і захищений, лише якщо мій тимчасовий приватний ключ не розкривається.

У кожній операції обидві сторони обмінюються новою угодою про зобов’язання для обміну тимчасовими приватними ключами, які використовувалися у попередньому раунді. Таким чином, сторона, яка віддає тимчасовий приватний ключ, більше не намагається транслювати стару угоду про зобов’язання, тому “скасовує” попередню угоду про зобов’язання та оновлює стан контракту; (фактично ці угоди про зобов’язання є дійсними угодами, які можна транслювати на ланцюжку блоків, але учасники відмовляються від цього через страх покарання).

Будь-яка сторона може вийти з контракту в будь-який момент, пред’явивши обіцянку, підписану протилежною стороною. Однак, якщо обидві сторони бажають співпрацювати, вони можуть підписати нову угоду, яка дозволить обом сторонам одразу повернути свої гроші.

Нарешті, оскільки в обіцянці угоди також можна вставити HTLC, мережу Lightning також можна використовувати для пересилання платежів. Припустимо, що Еліс зможе знайти шлях, що складається з послідовно з’єднаних каналів мережі Lightning і досягне Даніеля, тоді, без необхідності відкривати канал з Даніелем, можна здійснити багатохоповий платіж без довіри. Ось що означає мережа Lightning:

Аліса – HTLC –\u003e Боб – HTLC –\u003e Карол – HTLC –\u003e Даніель

Alice <-- image – Bob <-- image – Carol <-- image – Daniel

Коли Еліса знайшла такий шлях і хоче заплатити Даніелю, вона запитує у Даніеля хеш-значення для створення HTLC для Боба і просить Боба перенаправити повідомлення Керол і надати той самий HTLC; повідомлення також просить Керол перенаправити повідомлення Даніелю і надати той самий HTLC. Коли повідомлення доходить до Даніеля, він розкриває Керолі вихідний образ, отримує вартість HTLC, оновлює стан контракту; Керол також робить те саме, отримує платіж від Боба і оновлює стан каналу; нарешті, Боб розкриває образ Елісі, оновлює стан. Завдяки властивостям HTLC, ці послідовні платежі або вдало здійснюються разом, або не здійснюються взагалі, тому вони безпечні.

Lightning Network складається з безлічі каналів, кожен з яких (контракт) є незалежним. Це означає, що Еліс достатньо знати, що відбувається в її каналі з Бобом, і їй не потрібно замислюватися про кількість взаємодій у каналах інших людей, не обов’язково знати, якою валютою були здійснені ці взаємодії, навіть не потрібно знати, чи використовувалися ці канали насправді).

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

Обережний контракт журналу

Обережний угода журналу (DLC) використовує криптографічний трюк, який називається “підпис адаптера (adaptor signature)”, що дозволяє програмувати біткоїновий сценарій для фінансової угоди, залежної від зовнішніх подій.

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

R = r.G # Відкритий ключ r, який використовується для підпису, множиться на точку, що генерується на еліптичній кривій, також можна сказати, що це відкритий ключ r

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

s = r + Hash(R || m || P) \* p # p - це приватний ключ підпису, P - це публічний ключ

Перевірка підпису означає перевірку 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

Адаптерів підпису робить валідність підпису залежною від секретних даних та піддається перевірці. Але як це стосується фінансових контрактів?

Alice і Bob вирішили зробити ставку на результат футбольного матчу. Alice поставила на перемогу “Зелених Демонів”, а Bob - на перемогу “Арлінни”. Ставка складає 1 BTC. Крім того, веб-сайт з футбольними прогнозами Carol обіцяв опублікувати підпис s_c_i результату за допомогою nonce R_c після оголошення результату матчу.

можна побачити, що існує три можливі результати (тому у Карол є три можливі підписи):

• Зелений переміг, Аліса виграла 1 BTC
• Арінна перемагає, Боб виграє 1 BTC
• Нічия, гроші двох осіб повертаються вихідним шляхом.

Для цього кожен з них створює угоду для кожного можливого результату. Наприклад, угода, яку вони уклали для першого результату, виглядає наступним чином:

Введіть #0, 2 BTC: Alie-Bob 2-of-2 багатопідписний вихід (тобто, контракт на ставку)

Виведено #0,2 BTC: Alice односигнатурний

Але підпис, створений Алісою та Бобом для цієї транзакції, не є (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).

Коли результат стане відомим, якщо припустити, що Green Magic виграє, Керол випустить підпис (R_c, s_c_1), тоді як Еліс або Боб можуть додати відсутній підпис адаптера свого опонента, а також свій власний підпис, щоб зробити вищезазначену транзакцію дійсною та розповсюдити її по мережі для спровокування розрахункового ефекту. Але якщо Green Magic не перемагає, Керол не випускає s_c_1, і ця обіцянка транзакція не може стати дійсною.

Таким чином, ще дві угоди також працюють. Таким чином, Аліса та Боб зробили виконання цього контракту залежним від зовнішніх подій (точніше, від того, як агент передає зовнішні події, у формі підпису), причому не потрібно довіряти співробітникам. Різні фінансові контракти, такі як ф’ючерси, опціони, можуть бути реалізовані цим способом.

У порівнянні з іншими формами реалізації, особливості обережного лог-контракту полягають в його конфіденційності: (1) Аліса та Боб не повинні повідомляти Кероліну, що вони використовують її дані, це абсолютно не впливає на виконання контракту; (2) спостерігачі на ланцюжку (включаючи Кероліну) не можуть визначити, який веб-сайт надає послуги Аліси та Боба через виконання їх контракту, навіть не можуть впевнитись, що їх контракт - це гральний контракт (а не мережа миттєвих платежів).

Четвертий. Вступ до застосування обмежень

OP_CTV та контроль заторів

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

““Регулювання пробок” є хорошим прикладом, що демонструє функції OP_CTV. Його основний сценарій застосування полягає в допомозі багатьом користувачам вийти з біржі (надійне середовище) до пулу коштів; оскільки цей пул використовує OP_CTV для планування майбутніх витрат, він забезпечує можливість безпечного виходу користувачів з цього пулу без довіри до будь-якої сторони; крім того, цей пул представлений лише як UTXO, що уникне необхідності платити велику кількість комісій при високому попиті на транзакції на ланцюжку (з n виходів до одного виходу; з n транзакцій до однієї транзакції). Користувачі в пулу можуть знову вийти з нього, якщо знайдуть відповідний момент.”

Припустимо, Аліса, Боб, Керол хочуть вивести з бірж 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.

Або Аліса та Боб разом витратять його, або через певний час Аліса зможе витратити його сама.

Якщо Аліса не розкриє Бобу, Боб не знатиме про існування такого виводу; якщо Аліса розкриє Бобу, Боб зможе використовувати цей вивід як односторонній платіжний канал з обмеженою дієздатністю, Аліса може негайно сплатити Бобу кошти з нього, не чекаючи підтвердження в блокчейні. Бобу просто потрібно, щоб Аліса внесла обіцяну транзакцію до ланцюжка до того, як Аліса зможе витратити його самостійно.

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 також використовує деякі пропозиції щодо пулу транзакцій (політики мемпулу), наприклад, пропозиції щодо транзакцій у форматі v3, щоб досягти кращого ефекту. Це нагадує нам, що значення “програмування” може бути ширшим, ніж ми уявляємо. (Схожий приклад - Open Transaction у мережі Nervos Network).

П’яте. Розуміння CKB

У зазначених двох розділах ми висвітлили, як ми програмуємо цікаві застосування за допомогою скриптів на більш обмеженій структурі (Bitcoin UTXO), а також представили пропозиції щодо надання цій структурі інтроспективних можливостей.

UTXO, хоча має здатність програмувати такі застосунки, але читачі також дуже легко помічають їхні недоліки або місця, які можна оптимізувати, наприклад:

• У LN-Penalty учасники каналу повинні зберігати кожну зобов’язуючу угоду та відповідне секретне значення покарання для протидії шахрайству суперника, це створює навантаження на зберігання. Якщо існує механізм, що гарантує, що діятиме лише остання зобов’язуюча угода, а старі угоди не будуть діяти, то це звільнить від цього навантаження, а також усуне проблему ненавмисного покарання випадкової вузла через помилкове розміщення старіших зобов’язуючих угод на ланцюжок.
• У DLC, припустимо, що є багато можливих результатів події, тому обидві сторони повинні заздалегідь згенерувати багато підписів, які вони мають передати один одному, що також є великим тягарем; Крім того, прибуток від контракту DLC безпосередньо пов’язаний з відкритим ключем, тому їхню позицію важко переносити. Чи є спосіб перенесення позиції контракту?

Фактично спільнота Bitcoin вже висунула відповіді на ці питання, які в основному стосуються пропозиції Sighash (BIP-118 AnyPrevOut).

Але якщо ми програмуємо на CKB, то BIP-118 вже доступний (можна симулювати цей тип мітки Sighash здатністю до інтроспекції та перевірки підпису).

Через вивчення програмування Біткойна, ми не тільки дізнаємося, як програмувати у форматі “вихідний вивід” (що може програмувати CKB), але й як поліпшити ці застосування (як ми можемо використовувати можливості CKB для поліпшення цих застосувань, якщо ми програмуємо їх на CKB). Для розробників CKB це може бути не тільки навчальним матеріалом, але й скороченням.

Нижче ми розглянемо можливість програмування кожного модуля CKB окремо. Спочатку ми не будемо розглядати вміння самоаналізу.

Програмованість Lock для довільних обчислень

Як вже зазначено, 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 на основі Bitcoin без довіри. Ключовою особливістю цього протоколу є угода про транзакцію, в якій вхідна вартість менша за вихідну (тому вона не є дійсною транзакцією), але, якщо забезпечена достатньою вхідною сумою, стає дійсною транзакцією: якщо позичальник здатний повернути позику, то кредитор не може привласнити заставлені NFT. Однак, надійність цієї угоди залежить від перевірки величини вхідних та вихідних сум, тому позичальник може повернути позику лише у Bitcoin, навіть якщо позичальник та кредитор погоджуються прийняти іншу валюту (наприклад, USDT, які випущені за допомогою протоколу RGB), угода про Bitcoin не може гарантувати, що позичальник отримає свої NFT, якщо він поверне достатню кількість USDT, оскільки Bitcoin-транзакції не відомі щодо стану USDT! (Виправлення: з інших слів, неможливо створити угоду про транзакцію з умовою повернення за допомогою USDT).

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

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

Далі ми розглянемо здатність до самоаналізу.

Lock читает другие Lock s

Це означає, що після впровадження пропозиції щодо обмежень, всі можливості програмування на UTXO біткоїн будуть припинені. Це включає сейфовий контракт, згаданий вище, а також застосунки на базі OP_CTV, такі як контроль нагромадження.

XueJie колись згадував дуже цікавий приклад: ви можете реалізувати рахунок отримання Cell на CKB, і коли використовуєте цей Cell як вхід для угод, якщо вихідний Cell (з використанням того ж самого Lock) має більшу ємність, то цей вхід не потребує підпису і не впливає на дійсність угоди. Фактично, без здатності до внутрішнього відображення цей Cell не можна реалізувати. Цей рахунок отримання Cell дуже підходить для використання як спосіб отримання коштів для установ, оскільки він може акумулювати кошти, але має недолік у низькій приватності.

Lock 讀取其他类型s（以及数据）

Цікавим застосуванням такої можливості є токен акцій. Lock буде вирішувати, чи можна використовувати свою власну ємність, а також куди можна витратити цю ємність, враховуючи кількість токенів з інших вхідних джерел (потрібна здатність до самоаналізу Lock).

Попередній перегляд 01928374656574839201

Не впевнений, але можна припустити, що це корисно. Наприклад, ви можете перевірити умову, що блокування вводу та виводу транзакції залишаються незмінними в типі “Type”.

Читання інших типів Type Script (та Data)

Збірна картка? Зібравши n токенів, можна обміняти їх на більший токен : )

6. Висновок

На відміну від раніше відомих систем інтелектуальних контрактів з програмованою обчислювальною здатністю (наприклад, Ethereum), Nervos Network використовує іншу структуру, тому розуміння попередніх систем інтелектуальних контрактів часто не є основою для розуміння Nervos Network. У цій статті ми пропонуємо метод розуміння програмованості CKB Cell з використанням структури, яка обмежена в порівнянні зі структурою BTC UTXO. Крім того, застосовуючи концепцію “інтроспекції” для розуміння можливостей “міжконтрактного доступу” в Cell, ми можемо виділити ситуації, в яких застосовується здатність до інтроспекції і визначити їх конкретне використання.

“Виправлення:”

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

2. Не враховуючи здатність до хрестового доступу до Cell (тобто внутрішньої здатності), розрізнення між lock s та type s може бути сприйняте як підвищення рівня безпеки: воно розділяє визначення активів UDT та методи зберігання; крім того, реалізація type s (а також Data) з відкритим станом досягає ефекту того, що UDT є громадянином першого класу.

Вищевказане означає щось, що має таку ж саму парадигму, як “BTC + RGB”, але з більшими можливостями програмування.

3. При розгляді внутрішньої здатності Cell, Cell може отримати більш потужні можливості програмування, ніж post-covenants BTC UTXO, а також здійснити деякі речі, які важко впровадити з використанням BTC + RGB (тому що BTC не може читати стан RGB).

Щодо цих застосувань, у цій статті не можна навести багато конкретних прикладів, але це через недостатнє розуміння екосистеми CKB з боку автора. За деякий час люди, я впевнений, будуть вкладати все більше уяви, щоб створити застосування, які зараз важко уявити.

Дякуємо

Дякую Retric, Jan Xie та Xue Jie за відгуки під час написання статті. Звісно, я відповідаю за всі помилки у тексті.

“Джерела:”

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

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

13.\_ПИТАННЯ/обговорення/7