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