Переслати оригінальний заголовок 'RGB++ та ізоморфний зв'язок: CKB, Cardano та Fuel, як вони забезпечують потужність екосистемі біткойну'

У керівництві CKB було запропоновано протокол активів RGB++, який сутність ідеї "ізоморфного зв'язування" полягає в тому, щоб використовувати CKB, Cardano, Fuel та інші блокчейни на основі моделі програмування UTXO як функціональний розширювальний шар, який несе "контейнери" активів RGB. Це ізоморфне зв'язування також застосовується до екологічних протоколів активів Bitcoin з характеристиками UTXO, таких як Atomical та Runes, що ускладнює побудову позланкового рівня розумних контрактів для Bitcoin.

· У протоколі RGB++, користувачам не потрібно запускати клієнт для особистої перевірки даних транзакції, і вони можуть передати завдання, такі як перевірка валідності активів та зберігання даних, ланцюгам UTXO, таким як CKB та Cardano. Достатньо мати «оптимістичне» ставлення і вважати, що безпека вищезазначених громадських ланцюгів відносно надійна, не потрібно перевіряти це самостійно;

Протокол RGB++ підтримує користувачів у переході до режиму перевірки клієнта. На цей момент ви все ще можете використовувати CKB як сховище даних/шар DA, не зберігаючи дані самостійно. Протокол RGB++ не вимагає крос-ланцюжкових активів, може працювати з активами на ланцюжку CKB через облікові записи Bitcoin, та може зменшити частоту видання зобов'язань на ланцюжку Bitcoin, що також сприяє підтримці сценаріїв Defi;

· Якщо це підпадає під систему контрактів EVM, багато функцій RGB++ важко підтримати. Загалом, публічний ланцюжок / розширення функцій, яке підходить для реалізації ізоморфного зв'язування, повинно мати наступні характеристики:

1. Використовуйте модель UTXO або схожу схему зберігання стану;

2. Має значну програмованість UTXO, що дозволяє розробникам писати сценарії розблокування;

3. Є простір стану, пов'язаний з UTXO, де можна зберігати статус активу;

4. Воно може підтримувати роботу легких вузлів Біткойн через смарт-контракти або інші засоби;

· Крім CKB, Cardano та Fuel також можуть підтримувати ізоморфне зв'язування. Однак у останніх двох можуть бути деякі проблеми з мовою розумних контрактів та деталями дизайну контракту. Наразі, здається, що CKB більше підходить, ніж останні дві, як шар розширення функцій для ізоморфно зв'язаних протоколів активів Bitcoin.

У 2017 році Сайфер, співзасновник Nervos CKB, вперше запропонував ідею продукту ізоморфного зв'язування. Порівняно з іншими рішеннями для другого рівня Bitcoin, ізоморфне зв'язування може краще сумісно працювати з протоколами активів, такими як RGB, Runes та Atomical, і може уникнути факторів, таких як активи міжланцюгового зв'язування, які створюють додаткові обтяження з безпеки.

Просто кажучи, ізоморфне зв'язування використовує UTXO на ланцюгах CKB та Cardano як “контейнери” для вираження активів UTXO, таких як RGB, тим самим додаючи програмованість і більш складні сценарії. Раніше Geek web3 з'явився у “Від BTC до Sui, ADA та Nervos: модель UTXO та пов'язані розширенняПісля узагальнення ряду блокчейнів, які підтримують програмовані UTXO, ця стаття подальше досліджуватиме, чи можуть ці блокчейни адаптуватися до ізоморфної схеми зв'язування.

RGB++ та ізоморфне зв'язування

Перед аналізом сумісності різних ланцюгів UTXO з ізоморфним зв'язуванням, спочатку ми повинні ввести принцип ізоморфного зв'язування. Ізоморфне зв'язування - це концепція, запропонована командою CKB у протоколі RGB++, тому тут ми використовуємо робочий процес RGB++, щоб ввести те, що таке ізоморфне зв'язування на основі CKB.

Перш ніж вводити протокол RGB++, давайте коротко розберемося з протоколом RGB. RGB - це протокол активів / P2P мережа, що працює під ланцюгом Bitcoin, трохи схожий на мережу Lightning. Крім того, RGB також є паразитним протоколом активів на основі Bitcoin UTXO. Так зване паразитування означає, що клієнт RGB буде декларувати під ланцюгом Bitcoin, до якого UTXO певні активи RGB прив'язані на ланцюзі Bitcoin. Якщо у вас є цей UTXO, активи RGB, прив'язані до нього, також перебувають під вашим контролем.

Протоколи активів, такі як протокол RGB та ERC-20, працюють дуже по-різному. Контракт ERC-20 на Ethereum реєструє статус активів всіх користувачів, а клієнт вузла Ethereum синхронізує та перевіряє всю інформацію про переказ, і реєструє оновлення статусу після переказу в контракт активів. Це відомо людям вже давно, і це ніщо інше, як покладання на процес консенсусу Ethereum для забезпечення плавних змін статусу активів. Оскільки консенсус вузлів Ethereum є дуже надійним, користувачі можуть вважати платформу зберігання активів на основі контрактів ERC-20 як "немає проблем", навіть якщо вони не запускають клієнт.

Але протокол RGB дуже дивний. Щоб підвищити конфіденційність, він просто видаляє згоду вузла/клієнта, що є звичайною річчю у світі блокчейн. Користувачі повинні самостійно запускати клієнт RGB та отримувати та зберігати "дані активів, пов’язані з ними". Вони не можуть бачити, що зробили інші. На відміну від Ethereum та ERC-20, тут є всі видимі записи про трансфер на ланцюжку.

У цьому випадку, якщо хтось переказує вам деякі активи RGB, ви не знаєте заздалегідь, як була створена грошова одиниця та з ким вона перейшла власність. Якщо людина з іншого боку оголошує актив з повітря та потім передає вам частину цього, як ви впораєтеся з цим зловісним сценарієм контрафактного виготовлення валюти?

Протокол RGB відстоює цю ідею: Перш ніж кожен переказ набуде чинності, отримувач спочатку просить відправника представити всю історію активу. Наприклад, від етапу створення до сьогодення, хто видав ці активи, хто ними користувався, і чи кожен переказ активу, що відбувається між цими людьми, не порушує стандартів обліку (один додає, один віднімає).

Таким чином, ви можете знати, чи є гроші, які вам надали іншою стороною, "підозрілими грошима", отже, суть RGB полягає в тому, щоб дозволити сторонам угоди запустити клієнт для верифікації. На основі режиму верифікації клієнта, що відповідає припущенню гри раціональної особи, за умови, що сторони, які беруть участь, раціональні, а програмне забезпечення клієнта працює належним чином, можна гарантувати, що проблемний перехід активів не відбудеться або не буде визнаний іншими.

Варто зауважити, що протокол RGB стисне дані транзакцій під ланцюгом Bitcoin в Зобов'язання (в основному merkle root) та завантажить їх на ланцюг Bitcoin. Це дозволить з'єднати записи про перекази під ланцюгом безпосередньо з головною мережею Біткоїна. Встановіть з'єднання.

(RGB протокол взаємодії діаграми)

Оскільки серед клієнтів RGB немає консенсусу, реліз RGB контракту на активи не може бути поширений на всі вузли «дуже надійно». Видавці контрактів та користувачі просто дізнаються деталі контракту на активи RGB спонтанно через електронну пошту або Twitter, і форма дуже неофіційна.

На наведеній нижче фігурі показано сценарій зловмисного переказу RGB-активів. Як користувач RGB, нам потрібно зберігати відповідний до RGB-активу смарт-контракт локально на нашому клієнті. Коли інші переказують нам гроші, ми можемо знати, чи порушує поточний переказ правила, визначені в контракті, на основі вмісту локально збереженого контракту активу. Згідно з інформацією про джерело активу (історичний запис), наданою на протилежному боці, ви можете підтвердити, чи є які-небудь проблеми з джерелом активів іншої сторони (чи воно було оголошене з ніоткуда)

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

Це типовий острів даних, тобто дані, збережені кожним, не узгоджені. Хоча теоретично це може покращити конфіденційність, воно також приносить багато неприємностей. Вам потрібно зберігати дані активів RGB локально на своєму клієнті. Якщо ці дані втрачені, це призведе до серйозних наслідків (актив буде недоступним). Але насправді, якщо ви добре зберігаєте місцеві дані, протокол RGB може забезпечити вам безпеку, яка в основному еквівалентна мережі Bitcoin.

Також протокол Вифрост, який використовується для зв'язку між клієнтами RGB, допоможе користувачам у взаємодії з іншими клієнтами p2p. Вони можуть зашифрувати свої активи та розповсюдити їх на інші вузли, та попросити їх допомогти зберегти ці дані. (Зауважте, що це зашифровані дані, інша сторона не знає звичайного тексту). Якщо ви не втратите ключ, коли місцеві дані втрачені, ви можете відновити активи, які ви спочатку володіли через інші вузли в мережі.

Проте недоліки початкового протоколу RGB все ще очевидні. По-перше, кожна транзакція потребує кількох комунікацій між двома сторонами. Одержувач повинен спочатку перевірити джерело активів відправника, а потім надіслати квитанцію для підтвердження запиту на переказ відправника. Під час цього процесу між сторонами мають бути передані принаймні три повідомлення. Цей вид "інтерактивного переказу" серйозно не відповідає "неінтерактивному переказу", з яким звикли більшість людей. Чи можете уявити, що коли хтось хоче передати вам гроші, вони повинні надіслати вам дані транзакції для перевірки. Чи можуть вони завершити процес переказу лише після отримання вашого квитанції? (Діаграму потоку можна побачити в попередній статті)

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

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

(Схема взаємодії протоколу RGB ++ [коротка версія])

у попередніх статтях«Від RGB до RGB++: Як CKB надає можливості протоколу екологічного активу Bitcoin», ми коротко популяризували «ізоморфне зв'язування» RGB++. Тут ми швидко його переглянемо:

CKB має свій власний розширений UTXO, який називається Cell, і є більш програмованим, ніж UTXO на ланцюзі BTC. «Ізоморфне зв'язування» полягає в тому, щоб використовувати Cell на ланцюзі CKB як «контейнер» для даних RGB активів, і записати ключові параметри RGB активу в Cell.

Оскільки існує зв'язок між RGB активами та Bitcoin UTXO, логічна форма активу має характеристики UTXO. а також Cell, який також має характеристики UTXO, природно підходить як "контейнер" для RGB активів. Кожен раз, коли відбувається транзакція з RGB активами, відповідний контейнер Cell також може мати схожі характеристики, так само як відносини між сутностями та тінями. Це суть "ізоморфного зв'язку".

Наприклад, якщо Аліса володіє 100 токенами RGB та UTXO A на ланцюгу Біткойн, і має Клітину на ланцюгу CKB, ця Клітина позначена як "Баланс токенів RGB: 100", а умови розблокування пов'язані з UTXO A.

Якщо Еліс потрібно надіслати 30 токенів Бобу, вона може спочатку згенерувати Зобов'язання. Відповідне заявлення: передача 30 токенів RGB, пов'язаних з UTXO A, Бобу, та передача 70 іншим UTXO, які вона контролює.

Після цього Еліс витрачає UTXO A на ланцюгу Bitcoin, публікує вищезазначене заяву, а потім ініціює транзакцію на ланцюгу CKB для споживання контейнера Cell, який несе 100 токенів RGB та генерує два нових контейнера, один з утриманням 30 токенів (для Боба), один тримає 70 токенів (контрольований Еліс). У цьому процесі завдання перевірки достовірності активів Еліс та достовірності заяви про транзакцію завершується вузлами мережі CKB через консенсус, без втручання Боба. CKB зараз діє як шар верифікації та шар DA під ланцюгом Bitcoin.

Це схоже на те, що кожен раз, коли змінюється статус контракту ERC-20 Ethereum, користувачу не потрібно запускати перевірку клієнта. Принцип схожий. Протокол консенсусу та вузлова мережа замінюють перевірку клієнта. Крім того, дані про активи RGB кожного зберігаються на ланцюжку CKB, що є глобально перевірним, що сприяє реалізації сценаріїв Defi, таких як ліквідність пулів та протоколи забезпечення активів.

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

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

Просто кажучи, Ізоморфне зв'язування застосовується не лише до RGB, але й до різних протоколів активів з характеристиками UTXO, таких як Runes та Atomic., воно передає всі статуси активів, історичні дані та відповідні смарт-контракти, збережені локально на клієнті користувача, на громадські ланцюги UTXO, такі як CKB або Cardano для зберігання та хостингу. Вищезгаданий протокол активів UTXO може використовувати модель UTXO CKB або Cardano як „контейнер“, щоб показати форму та статус активу. Це зручно співпрацювати з сценаріями, такими як смарт-контракти.

За протоколом ізоморфного зв'язування користувачі можуть безпосередньо використовувати свої облікові записи Bitcoin для управління контейнерами RGB своїх активів на ланцюгах UTXO, таких як CKB, без перетину ланцюга. Вам потрібно лише використовувати функцію UTXO Cell, щоб встановити умови розблокування контейнера Cell, що пов'язаний з певною адресою Bitcoin/Bitcoin UTXO. Оскільки ми вже пояснили характеристики Cell у популярно-науковій статті RGB++ від Geekweb3, ми тут не будемо детально розглядати.

Якщо обидві сторони, які беруть участь в операціях з активами RGB, можуть довіряти безпеці CKB, їм навіть не потрібно буде часто випускати зобов'язання в ланцюжку Bitcoin. Після того, як буде здійснено багато переказів RGB, зобов'язання може бути надіслано в ланцюжок Bitcoin. Це називається функцією «згортання транзакцій». Може зменшити витрати на використання.

Проте слід зауважити, що «контейнер», який використовується в ізоморфному зв'язуванні, часто потребує публічного ланцюга, який підтримує модель UTXO, або інфраструктуру зі схожими характеристиками у сховищі стану, і ланцюг EVM очевидно не підходить, і виникнуть технічні проблеми з реалізації. Зіткнулися з багатьма пастками. По-перше, як вже зазначалося, RGB++ «може працювати з контейнерами активів на ланцюгу CKB без міжланцюжного зв'язку», що в принципі неможливо реалізувати на ланцюгу EVM; навіть якщо це буде примусово впроваджено, витрати можуть бути дуже великі;

Крім того, в протоколі RGB++ багатьом людям не потрібно запускати клієнт або зберігати дані активів локально. Якщо для запису балансу активів кожного використовується метод ERC-20 у цьому контракті, і хтось хоче повернутися до режиму самоперевірки клієнта та запропонувати перевірити джерело чиїхось активів, на цей момент йому може доведеться сканувати всі транзакційні записи, що взаємодіють з контрактами активів, що призведе до великого тиску.

Щоб виразитися прямо, контракти активів, такі як ERC-20, зв'язують і зберігають статус активів кожного. Якщо ви хочете індивідуально перевірити історію змін активів одного з них, це стане важким. Точно так само, як у загальному чаті, якщо ви хочете дізнатися, хто надсилав повідомлення Ван Гану, вам доведеться перегортати записи повідомлень у всьому чаті. UTXO схоже на приватний один до одного чат-канал, і легко перевірити історію.

Таким чином, відкритий шар розширення ланцюга/функції, придатний для реалізації ізоморфного зв'язування, повинен мати такі характеристики:

1. Використовуйте модель UTXO або подібну схему зберігання стану;
2. Має значну програмованість UTXO, що дозволяє розробникам писати сценарії розблокування;
3. Є простір стану, пов'язаний з UTXO, який може зберігати статус активу;
4. Є мости або світлові вузли, пов'язані з Біткоїном;

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

Наразі блокувальний скрипт UTXO на CKB є програмованим, і офіційний також сумісний з схемами підпису різних публічних ланцюгів. Для ізоморфного зв'язку мережа CKB в основному відповідає вищезазначеним характеристикам. Що на рахунок інших публічних ланцюгів на основі UTXO? Ми провели попередній огляд Fuel та Cardano та вважаємо, що теоретично вони можуть підтримувати ізоморфний зв'язок.

Паливо: Ethereum OP Rollup на основі UTXO

Fuel - це Ethereum OP Rollup, заснований на UTXO, і є піонером у введенні концепції доказу шахрайства в екосистему Ethereum Layer 2. Для підтримки нормальної функції UTXO, Fuel в основному узгоджується з BTC.

Fuel розділяє свої внутрішні UTXO на наступні три категорії:

Вхідна монета: стандартний UTXO, що використовується для представлення активів користувача, має власний часовий замок та дозволяє користувачам записувати передумови розблокування скрипта;

Вхідний контракт: UTXO, який використовується для викликів контрактів, містить дані, такі як кореневий стан контракту та контрактні активи;

Повідомлення введення: UTXO, що використовується для передачі інформації, в основному містить поля, такі як отримувач інформації;

Коли користувач витрачає UTXO, виробляється наступний вивід:

Вивід монети: Для стандартних переказів активів;

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

Створено вихідний контракт: Спеціальний UTXO є вихідним, створеним при створенні контракту, який містить ідентифікатор та кореневий стан контракту;

На відміну від Клітини CKB, яка містить всі внутрішні стани контракту, UTXO Fuel фактично не несе всі становища контракту, пов'язані з транзакцією. Fuel містить лише корінь стану контракту Stateroot в UTXO, який є коренем дерева стану. Повний стан контракту зберігається всередині бібліотеки стану Fuel і належить смарт-контракту.

Варто зазначити, що, щодо обробки статусу розумних контрактів, контракт Fuel та контракт solidity ідеологічно сумісні та навіть відносно близькі за формою програмування. На рисунку нижче показано контракт лічильника, написаний мовою Sway від Fuel. Контракт містить лічильник. Коли користувач викликає функцію increment_counter, лічильник, збережений у контракті, збільшується на 1.

Ми бачимо, що логіка написання контракту Sway схожа на загальний контракт Solidity. Спочатку ми надаємо ABI контракту, потім змінні стану контракту, а потім конкретну реалізацію контракту. Усі процеси написання коду не включають в себе UTXO-систему Fuel.

Таким чином, досвід програмування контрактів Fuel відрізняється від мов програмування UTXO, таких як CKB та Cardano. Fuel надає досвід, близький до програмування та розробки розумних контрактів EVM. Розробники також можуть використовувати мову Sway для побудови сценаріїв розблокування для впровадження спеціальної логіки перевірки алгоритму підпису або складної логіки розблокування з багатьма підписами.

Засновним є впровадження ізоморфного зв'язування в межах Fuel, проте все ще існують наступні проблеми:

Мова коливань, використовувана паливом, ближча до ланцюга EVM у плані проектування смарт-контрактів, ніж до BTC, CKB та Cardano. Емітенти активів UTXO, таких як RGB та Atomics, повинні спеціально побудувати смарт-контракт на паливі. CKB та інші ланцюги використовують інший, який досить складний.

Cardano: публічний ланцюжок eUTXO на основі POS

Cardano - це ще один блокчейн, який використовує модель UTXO, але, на відміну від Fuel, він є публічним ланцюгом 1-го рівня. Cardano використовує eUTXO (розширена UTXO) для посилання на модель програмування UTXO в своєму системі. У порівнянні з CKB, eUTXO в Cardano містить наступні структури:

Сценарій: Розумні контракти використовуються для перевірки можливості розблокування UTXO та виконання переходів стану;

Редімери: Дані, надані користувачами для розблокування UTXO, як правило, є дані підпису, схожі на Свідка Біткойну;

Дані: Простір стану смарт-контрактів може зберігати дані, такі як статус активів;

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

Розробники можуть використовувати мову PlutusCore для програмування UTXO на ланцюгу Cardano. Так само, як і з CKB, розробники можуть писати сценарії розблокування та деякі функції для оновлення статусу.

Ми представляємо модель програмування UTXO від Cardano з процесом аукціону на основі UTXO. Припустимо, що нам потрібно реалізувати DAPP аукціону активів, для якого користувачам потрібно давати ставки перед завершенням аукціону. Зокрема, користувач витрачає свій власний UTXO, укладає контракт UTXO з цим аукціоном, а потім генерує новий UTXO. Коли хтось дає вищу ставку, крім генерації нового UTXO контракту аукціону, буде згенеровано також UTXO повернення для попередньої особи. Конкретний процес виглядає наступним чином:

Для впровадження вищезазначеного процесу аукціону, деякі стани потрібно зберігати в UTXO умовного розумного контракту аукціону, такі як найвища ціна поточного аукціону та особа, яка зробила ставку. На рисунку нижче показано заяву про стан всередині PlutusCore. Ми бачимо, що bBidder та bAmount показують аукціонну пропозицію та адресу гаманця, яка зробила ставку. Параметри аукціону містять основну інформацію про аукціон.

Коли користувач витрачає цей UTXO, ми можемо оновити стан у межах контракту. На малюнку нижче показано деякі конкретні оновлення статусу та бізнес-логіку у межах контракту аукціону. Наприклад, логіка перевірки ставок користувача та перевірка того, чи триває поточний аукціон. Звичайно, оскільки PlutusCore - це мова програмування Haskell, яка є чисто функціональною мовою програмування, більшість розробників можуть не змогти безпосередньо зрозуміти її значення.

Можливо побудувати ізоморфні зв'язки на Cardano. Ми можемо використовувати Датум для зберігання статусу активів і писати конкретні скрипти, які будуть сумісні з алгоритмами підпису, пов'язаними з Біткойном. Проте серйозна проблема полягає в тому, що більшість програмістів можуть не впоратися з використанням PlutusCore для програмування контрактів. Крім того, його середовище програмування важко налаштувати і не є дружнім до розробників.

Узагальнити

Ізоморфне зв'язування передбачає, щоб ланцюг мав наступні властивості:

1. Використовуйте модель UTXO
2. Має значну програмованість UTXO, що дозволяє розробникам писати сценарії розблокування
3. Існує простір стану, пов'язаний з UTXO, який може зберігати статус активу
4. Воно може підтримувати роботу легких вузлів Біткойн через смарт-контракти або інші засоби.

Через особливість своїх ідей щодо програмування розумних контрактів, Fuel сумісний з ізоморфним зв'язуванням, але він все ще приносить певні недоліки; тим часом Cardaon використовує мову програмування Haskell для програмування контрактів, що ускладнює швидкий старт для більшості розробників. На підставі вищезазначених причин CKB, який використовує набір інструкцій RISC-V та є більш збалансованим у характеристиках UTXO програмування, може бути шаром розширення функцій, більш підходящим для ізоморфного зв'язування.

Disclaimer：

1. Ця стаття розміщена з [Geek Web3].Переслати оригінальний заголовок 'RGB++ та ізоморфний зв'язок: CKB, Cardano та Fuel, як вони надають екосистемі біткойну потужність'. Усі права на авторське право належать оригінальному автору [Shew]. Якщо є зауваження до цього повторного друку, будь ласка, зв'яжіться з Gate Навчаннякоманду, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять будь-яких інвестиційних порад.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.