Вступ

Випуск активів на основі BTC завжди був гарячою темою. Від першої появи кольорових монет у 2011 році до нещодавно популярного протоколу Ordinal Protocol спільнота BTC завжди могла залучати нових гравців і консенсусу. Однак мало хто витримав випробування часом. Оскільки амбіційна Lightling Labs оголосила про свій план створення стабільної монети на основі Taproot Assets, а Tether оголосив про вибір RGB для карбування USDT на першому рівні біткойна, стає зрозуміло, що колись відомий OmniLayer (Mastercoin) більше не є найбільшим гравець в екосистемі BTC. Протоколи перевірки активів на стороні клієнта (CSV) починають привертати увагу, відрізняючись від традиційних протоколів активів BTC також включають функції для масштабованості біткойна. Але зіткнувшись із такою кількістю протоколів активів в екосистемі BTC, потрібно запитати: у чому їх відмінності? І як нам вибрати та знайти власні можливості серед цих численних протоколів активів?

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

Кольорові монети

Ідею кольорових монет вперше запропонував Йоні Асія, нинішній генеральний директор eToro, у статті, написаній 27 березня 2012 року під назвою «біткойн 2.X (він же кольоровий біткойн)». У статті стверджується, що біткойн, як базова технологія, ідеальний, подібно до того, як HTTP є основою Інтернету. Тому на основі повторного використання BTC був розроблений протокол токенів Colored Coins.

Yoni Assia прагнув створити економіку BTC 2.0 за допомогою цього методу - будь-яка спільнота могла б створити різноманітні валюти таким чином. Цей підхід використання біткойна як базової технології для клірингу транзакцій і уникнення подвійних витрат, безсумнівно, був дуже сміливою ідеєю на той час.

Будучи протоколом для випуску активів на основі біткойнів, метод Кольорових монет полягає в «розфарбовуванні» певної кількості біткойнів для представлення цих активів. Ці позначені біткойни функціонально залишаються біткойнами, але вони також представляють інший актив або цінність. Але як цю ідею реалізувати на біткойнах?

3 липня 2014 року ChromaWay розробила протокол кольорових монет (EPOBC) на основі вдосконаленого хешування плати до сценарію (P2SH), який спростив для розробників процес створення кольорових монет. Це був найперший протокол, який застосував функцію OP_RETURN Bitcoin Script.

Остаточна реалізація показана на наступному зображенні:

)

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

Гомогенізовані токени та мінімальне значення прив’язки

У транзакції Genesis, якщо кольорова монета пов’язана з 1000 сат, найменша одиниця розділення цієї кольорової монети становить 1 сат. Це означає, що актив або токен можна розділити або розподілити на максимум 1000 частин (але це лише теоретично, щоб запобігти нападам пилу, наприклад, sat раніше встановлювався на 546 SAT, а пізніше – на порядковий номер, який є вищим ).

Проблеми перевірки

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

Потенційний ризик майнерської цензури

Завдяки відмінним характеристикам ColoredTransaction, які передбачають запис інформації метаданих у вихідні дані, існує ймовірність цензури майнерів.

Кольорові монети — це, по суті, система відстеження активів, яка використовує правила перевірки біткойнів для відстеження передачі активів. Однак, щоб довести, що будь-який конкретний результат (txout) представляє певний актив, потрібен увесь ланцюжок передачі від походження активу до теперішнього часу. Це означає, що для перевірки легітимності транзакції може знадобитися довгий ланцюжок доказів. Щоб вирішити цю проблему, була запропонована функція OP_CHECKCOLORVERIFY для безпосередньої перевірки правильності транзакцій кольорових монет у BTC, але ця пропозиція не була прийнята.

Перше ICO в індустрії криптовалют: Mastercoin

Початкову концепцію Mastercoin запропонував JR Willett. У 2012 році він опублікував офіційний документ під назвою «Друга біла книга про біткойн», в якому описував концепцію створення нових активів або токенів на існуючому блокчейні біткойна, пізніше відомому як «MasterCoin». Згодом він був перейменований на Omni Layer.

У 2013 році проект Mastercoin провів початковий продаж токенів (те, що ми сьогодні називаємо ICO або Initial Coin Offering), успішно зібравши мільйони доларів. Це вважається першим ICO в історії. Найвідомішим застосуванням Mastercoin є Tether (USDT), найвідоміший фіатний стейблкоїн, який спочатку випускався на Omni Layer.

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

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

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

Однак, щоб реалізувати складну логіку Mastercoin, користувачам потрібно довіряти стану в базі даних вузлів поза мережею або запускати власні вузли Omni Layer для перевірки.

Підсумовуючи:

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

Відповідно до інформації, наданої OmniBolt: Omni Layer пропонує новий протокол активів UBA (UTXO Based Asset) для Tether, який використовуватиме оновлення Taproot для кодування інформації про активи в tapleaf, уможливлюючи такі функції, як умовні платежі. Тим часом OmniBolt вводить Stark в інфраструктуру Lightning Network OmniLayer.

Концепція перевірки на стороні клієнта

Щоб зрозуміти концепцію перевірки на стороні клієнта, нам потрібно повернутися до року після появи кольорових монет і Mastercoin, а саме до 2013 року. Того року Пітер Тодд опублікував статтю: «Розв’язування майнінгу крипто-монет: відмітка часу, підтвердження публікації та перевірка». Хоча назва статті не здається безпосередньо пов’язаною з валідацією на стороні клієнта, уважне читання показує, що вона містить найдавніші думки про валідацію на стороні клієнта.

Пітер Тодд, перший дослідник біткойнів і криптографії, завжди шукав спосіб зробити роботу біткойнів більш ефективною. Він розробив більш складну концепцію клієнтської перевірки на основі концепції часових позначок. Крім того, він ввів концепцію «одноразової пломби», про яку буде згадано пізніше.

Дотримуючись думок Пітера Тодда, давайте спочатку розберемося з проблемами, які насправді вирішив BTC (Bitcoin). На думку Пітера Тодда, BTC вирішив три проблеми:

Підтвердження публікації

Суть proof-of-publication полягає у вирішенні проблеми подвійних витрат. Наприклад, у Аліси є кілька біткойнів, які вона хоче передати Бобу. Хоча вона підписує транзакцію для передачі Бобу, Боб може фізично не знати про існування транзакції. Отже, потрібне публічне місце для публікації транзакцій, де кожен може запитати їх.

Замовити Консенсус

У комп’ютерних системах фізичного часу, який ми зазвичай сприймаємо, не існує. У розподілених системах час часто представлено часовими мітками Лампорта, які не вимірюють наш фізичний час, а впорядковують наші транзакції.

Перевірка (необов'язково)

Валідація BTC стосується перевірки підписів і сум переказу BTC. Однак тут Пітер Тодд вважав, що ця перевірка не потрібна для створення системи токенів на основі BTC, а скоріше є оптимізацією.

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

Отже, як валідація на стороні клієнта ефективно підтверджує транзакції?

Давайте спочатку подивимося, що потрібно перевірити:

• Стан (перевірка логіки транзакції)

• Введіть валідність TxIn (для запобігання подвійним витратам)

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

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

Пітер Тодд запропонував таку структуру дерева зобов'язань:

CTxIn -> CTxOut -> <merkle path> <шлях Merkle> -> CTransaction -> <merkle path> <шлях Merkle> -> CTxIn

Але як зберегти таке дерево зобов’язань у ланцюжку? Це приводить нас до концепції одноразової пломби.

Одноразова печатка

Одноразова пломба є одним із основних понять для розуміння перевірки на стороні клієнта, подібно до фізичних одноразових пломб, які використовуються для захисту вантажних транспортних контейнерів у реальному світі. Одноразова печатка — це унікальний об’єкт, який може точно закрити повідомлення один раз. Коротше кажучи, одноразова печатка — це абстрактний механізм, який використовується для запобігання подвійним витратам.

Для SealProtocol є три елементи та дві дії.

Основні елементи:

1. л: печатка, тобто печатка
2. m: повідомлення, повідомлення
3. В: свідок, свідок

Основні операції: Існує дві основні операції:

1. Close(l,m) → w: у messagemupper, що закриває seal, згенеруйте свідок。
2. Перевірити(l,w,m) → bool: Перевірити seallВи в новинах?закрито.

Реалізація одноразової печатки з точки зору безпеки: два різних повідомлення не можуть бути знайдені зловмисником m1 і m2, і функція Verify повертає той самий sealtrueof.

Перш за все, Single-Use Seal — це концепція, яка гарантує, що певний актив або дані будуть використані або заблоковані лише один раз. У контексті біткойнів це зазвичай означає, що UTXO (невитрачений вихід транзакції) можна витратити лише один раз. Таким чином, вихід транзакції біткойн можна вважати одноразовою печаткою, і коли цей вихід використовується як вхідна інформація для іншої транзакції, печатка «зламана» або «використана».

Для активів CSV у BTC сам біткойн діє як одноразовий запечатаний «свідок». Це пояснюється тим, що для підтвердження транзакції біткойн вузол повинен перевірити, чи кожен вхід до транзакції посилається на дійсний і невитрачений UTXO. Якщо транзакція намагається подвоїти витрати UTXO, який уже був витрачений, правила консенсусу біткойна та чесні вузли в мережі відхилять транзакцію.

Чи можна простіше?

одноразова печатка Тобто будь-який блокчейн розглядається як база даних. Ми певним чином зберігаємо обіцянку певного повідомлення в цій базі даних і підтримуємо для нього статус використання або використання.

Так, це так просто.

Підводячи підсумок, активи, перевірені клієнтом, мають такі характеристики:

1. Зберігання даних поза ланцюгом: більшість історії транзакцій, прав власності та інших пов’язаних даних активів, перевірених клієнтом, зберігаються поза ланцюгом. Це значно зменшує потреби в зберіганні даних у мережі та покращує конфіденційність.
2. Механізм зобов’язань: хоча дані про активи зберігаються поза ланцюгом, зміни або перенесення цих даних реєструватимуться в ланцюзі через зобов’язання. Ці зобов’язання дозволяють транзакціям у ланцюзі посилатися на стани поза ланцюгом, таким чином забезпечуючи цілісність і відсутність підробки даних поза ланцюгом.
3. Свідок у ланцюжку (не обов’язково BTC): хоча більшість даних і перевірка здійснюється поза ланцюгом, активи, перевірені клієнтом, все ще можуть скористатися перевагами безпеки базового ланцюга (видача доказів, порядок транзакцій) завдяки зобов’язанням, вбудованим у - ланцюг.
4. Перевірка виконується на стороні клієнта: більша частина роботи з перевірки виконується на пристрої користувача. Це означає, що всім вузлам мережі не потрібно брати участь у перевірці кожної транзакції, тільки залучені учасники повинні перевірити дійсність транзакції.

Для тих, хто використовує перевірку активів на стороні клієнта, є ще один момент, на який слід звернути увагу:

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

Піонер у перевірці на стороні клієнта (CSV): RGB

Концепція RGB була запропонована Джакомо Зукко, відомою людиною в спільноті, після 2015 року. У зв’язку зі зростанням Ethereum і розповсюдженням ICO, а також до ICO багато людей намагалися робити щось поза межами біткойнів, наприклад проекти Mastercoin і Colored Coins. .

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

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

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

Механізм зобов'язання RGB: хеш Педерсена

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

Дизайн віртуальної машини RGB: від простоти до AluVM

Метою RGB є не лише реалізація перевіреного клієнтом протоколу активів, але й поширення на повне виконання віртуальної машини Тьюрінга та контрактне програмування. У ранньому дизайні RGB стверджувалося, що він використовує мову програмування під назвою Simplicity. Для цієї мови характерно генерування підтвердження виконання під час виконання виразів, що полегшує офіційну перевірку контрактів, написаних у ній (щоб уникнути помилок). Однак розвиток цієї мови не був ідеальним і з часом наштовхнувся на труднощі. Це безпосередньо призвело до важкого народження протоколу RGB того року. Зрештою, RGB почав використовувати AluVM, розроблений Maxim, з метою уникнення будь-якої невизначеної поведінки, подібної до початкової Simplicity. Кажуть, що нову AluVM у майбутньому буде замінено мовою програмування під назвою Contractum, яка зараз використовує Rust.

Напрямок розширення рівня 2 RGB: Lightning Network чи Sidechain?

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

RGB і Lightning Network

Простіше кажучи, принцип Lightning Network полягає в тому, що дві сторони, які беруть участь у транзакції, підписують купу контрактів (транзакцій зобов’язань) поза мережею. Вони гарантують, що якщо будь-яка сторона порушить контракт, потерпіла сторона може подати контракт (операцію зобов’язання) до BTC для врегулювання, повернути свої кошти та покарати іншу сторону. Іншими словами, Lightning Network забезпечує безпеку транзакцій поза ланцюгом через розробку протоколу та теорію ігор.

RGB може побудувати власну інфраструктуру Lightning Network, розробивши відповідні правила контракту платіжного каналу, але складність Lightning Network надзвичайно висока, і побудова цієї системи є непростим завданням. Однак, навпаки, Lightnling Labs розвиває цю сферу протягом багатьох років, і LND займає понад 90% ринку.

Сайдчейн RGB: Prime

LNP-BP, наразі підтримує протокол RGB, а Maxim випустив пропозицію під назвою Prime у червні 2023 року, перевірену клієнтом схему розширення активів. У ньому він розкритикував існуючі сайдчейн і схеми розширення Lightning Network як надто складні в розробці. Максим зазначив, що, на його думку, крім Prime, інші методи розширення включають багатовузлові канали Lightning NUCLEUS і фабрики каналів Ark/Enigma, для обох яких потрібно більше двох років розробки. Однак Prime може бути завершено всього за один рік.

Prime — це не традиційний дизайн блокчейну, а модульний рівень публікації доказів, призначений для перевірки клієнта, що складається з чотирьох частин:

1. Послуга часових позначок: визначення послідовності транзакцій всього за 10 секунд.

2. Підтвердження: зберігається у форматі PMT, створюється та публікується разом із заголовком блоку.

3. Одноразова печатка: абстрактний протокол одноразової печатки, що забезпечує захист від подвійних витрат. Якщо його реалізувати на біткойнах, його можна прив’язати до UTXO, подібно до поточного дизайну RGB.

4. Протокол смарт-контрактів: Контракти, які можна розділити - RGB (замінні).

Щоб вирішити проблему часу підтвердження транзакцій RGB, Prime використовує службу часових позначок для швидкого підтвердження транзакцій поза мережею та інкапсуляції транзакцій та ідентифікаторів у блоки. Водночас докази транзакцій на Prime можна додатково об’єднати через PMT, а потім прив’язати до BTC у спосіб, подібний до контрольних точок.

Протокол активів CSV на основі Taproot: активи Taproot

Taproot Assets — це протокол активів CSV, заснований на Taproot, який використовується для випуску перевірених клієнтом активів у блокчейні Bitcoin. Цими активами можна миттєво торгувати у великих обсягах і за низькою ціною через Lightning Network. Суть Taproot Assets полягає у забезпеченні безпеки та стабільності мережі Bitcoin, а також у швидкості, масштабованості та низькій вартості Lightning Network. Цей протокол був розроблений і розроблений технічним директором Lightnling Labs Roasbeef, який, можливо, є єдиною людиною на планеті, яка особисто керувала розробкою як клієнта Bitcoin (BTCD), так і клієнта Lightning Network (LND), і має глибоке розуміння BTC.

Транзакції Taproot несуть лише кореневий хеш сценарію ресурсу, що ускладнює зовнішнім спостерігачам визначення того, чи вони стосуються активів Taproot, оскільки сам хеш є загальним і може представляти будь-які дані. З оновленням Taproot біткойн отримав можливість смарт-контрактів (TapScript). Виходячи з цього, кодування активів Taproot Assets схоже на створення визначення маркера, подібного до ERC20 або ERC721. Таким чином, біткойн має не лише функцію визначення активів, але й здатність писати розумні контракти, закладаючи основу для інфраструктури розумних контрактів токенів на біткойнах.

Структура кодування Taproot Assets така: [Опис закінчується тут, вказуючи на те, що наступна частина статті, ймовірно, заглиблюється в технічні деталі структури кодування Taproot Assets.]

Зображення від технічного директора Lightning Labs roasbeef

Будучи протоколами активів CSV (CoinSwap), активи Taproot розроблені так, щоб бути більш оптимізованими порівняно з RGB. Вони максимально використовують поточні досягнення в екосистемі BTC, такі як оновлення Taproot і PSBT (частково підписані біткойн-транзакції). Найсуттєвіша відмінність між Taproot Assets і RGB з точки зору розширюваності програми полягає у виконанні VM (Virtual Machine). Активи Taproot використовують TaprootScriptVM, який є таким самим, як рідна віртуальна машина, яку використовує BTC. В останні роки багато інфраструктурних досліджень для BTC базувалися на TapScript. Однак через повільні темпи оновлення BTC ці дослідження не були швидко реалізовані, що робить Taproot Assets потенційним полігоном для випробування цих нових ідей.

Чим відрізняються Taproot Assets і RGB?

1. Перевірка транзакцій і зручність Light Node

Завдяки реалізації сумарного дерева Taproot Assets може похвалитися високою ефективністю та безпекою верифікації (перевірка та транзакція можуть бути виконані просто за допомогою підтвердження утримування, без перегляду всієї історії транзакцій). Навпаки, використання RGB зобов’язань Педерсена перешкоджає ефективній перевірці вхідних даних, вимагаючи від RGB відстежувати історію транзакцій, що з часом стає значним тягарем. Конструкція сумарного дерева Меркеля також полегшує легку перевірку вузлів у Taproot Assets, функції, якої немає в попередніх протоколах активів, побудованих на BTC.

1. Виконання ВМ

Taproot Assets з’явилися після оновлення Taproot. Вони використовують TaprootScriptVM, механізм виконання сценаріїв, властивий оновленню Bitcoin після Taproot, і vPSBT, варіант PSBT BTC. Щойно механізм каналу блискавки Taproot Assets буде завершено, він зможе негайно повторно використовувати всю поточну інфраструктуру LND і минулі продукти Lightning Labs (наразі LND домінує понад 90% мережі блискавки). Недавня пропозиція BitVM, також заснована на TaprootScript, теоретично підтримує Taproot Assets. Однак віртуальна машина RGB і правила перевірки (SCHEMA) є самодостатніми, утворюючи відносно закриту екосистему. Розвиток RGB значною мірою обмежується його екосистемою, і його інтеграція з екосистемою біткойн не така близька, як можна було б подумати. Наприклад, єдиним зв’язком RGB з оновленням Taproot є кодування даних зобов’язань ланцюжка в TapLeaf Witness.

1. Розумні контракти

У поточній реалізації RGB велике значення приділяється контрактам і віртуальній машині. Однак смарт-контракти в Taproot Assets ще не з’явилися. Наразі RGB не пояснює, як модифікації глобального стану синхронізуються з окремими фрагментами контракту (UTXO), а також як зобов’язання Педерсена, які лише гарантують загальну кількість активів, виявляють втручання в інші стани. Навпаки, Taproot Assets з їх простішим дизайном наразі зберігають лише баланси активів і не мають великого сховища стану, що робить обговорення розумних контрактів передчасним. Проте Lightning Labs вказала, що наступного року Taproot Assets зосередиться на розробці смарт-контрактів.

1. Центр синхронізації

Як зрозуміло з основних принципів перевірки активів на стороні клієнта, зберігання Доказу є таким же важливим, як і зберігання закритого ключа. Але що, якщо доказ втрачено на стороні клієнта користувача? У Taproot Assets цю проблему можна вирішити за допомогою «всесвіту». Всесвіт — це розріджене дерево Меркла, яке можна перевірити, і охоплює один або кілька активів. На відміну від звичайних дерев ресурсів Taproot, Всесвіт не містить ресурсів Taproot. Замість цього він фіксує підмножину однієї або кількох історій активів. У RGB цю роль відіграє Storm, який синхронізує дані перевірки поза мережею через P2P. Однак через історичні причини команд розробників RGB ці формати перевірки наразі несумісні. Повідомляється, що команда екосистеми RGB, DIBA, розробляє «carbonado» для вирішення цієї проблеми, хоча прогрес невідомий.

1. Інженерна реалізація

Усі бібліотеки, які використовує Taproot Assets, перевірені часом, оскільки Lightning Labs має власний біткойн-клієнт (BTCD), мережевий клієнт блискавки (LND) і численні реалізації бібліотеки гаманця. Навпаки, більшість бібліотек, які використовуються в RGB, є самовизначеними, і з точки зору промислового стандарту впровадження RGB все ще знаходиться на експериментальній стадії».

Коротка дискусія про майбутнє розширення BTC

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

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

Менше обчислень у ланцюжку, більше перевірки в ланцюжку

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

Де відбувається перевірка? Це важливо

Для розробників протоколів на основі біткойна питання про те, як використовувати біткойн для критично важливих валідацій або навіть розміщувати валідації поза ланцюгом, а також як розробляти схеми безпеки – це питання для самих розробників протоколів. Вони не повинні і не повинні бути пов’язані з самим ланцюгом. Таким чином, те, як реалізована перевірка, призведе до різних стратегій розширення для BTC.

Виходячи з перспективи впровадження валідації, ми маємо три напрямки розширення:

1. 1. Валідація в ланцюжку (OP-ZKP)
2. Якщо OP-ZKP реалізовано безпосередньо в TaprootScriptVM, це означає інтеграцію можливостей перевірки ZKP у сам BTC у поєднанні з деякими проектами Covenant для протоколів розрахунків, створення плану розширення Zk-Rollup, який успадковує безпеку BTC. Однак, на відміну від розгортання контракту перевірки на Ethereum, повільний процес оновлення BTC у поєднанні з таким спеціалізованим кодом операції, який потенційно потребує оновлення, робить його складним.
4. 2. Напівмережева перевірка (BitVM)
5. Конструкція BitVM не призначена для обслуговування звичайної логіки транзакцій. Робін Лінус також зазначив, що майбутнє BitVM полягає у створенні вільного міжланцюгового ринку для різних SideChains. Підхід BitVM вважається напів-ланцюгом, оскільки більшість цих обчислень перевірки відбуваються не в ланцюзі, а скоріше поза ланцюгом. Однак важливою причиною проектування навколо Taproot BTC є використання TapScriptVM для обчислювальної перевірки, коли це необхідно, теоретично успадковуючи безпеку BTC. Цей процес також створює довірчий ланцюжок перевірки. Наприклад, достатньо, якщо один із «n» валідаторів є чесним, подібно до Optimistic Rollups.
6. Витрати BitVM на ланцюжок високі, але чи може він використовувати докази шахрайства ZK для підвищення ефективності? Відповідь – ні, оскільки реалізація доказів шахрайства ZK базується на здатності виконувати перевірку ZKP у ланцюжку, що повертає нас до дилеми схеми OP-ZKP.
8. 3. Перевірка поза ланцюгом (перевірка на стороні клієнта, мережа Lightning)
9. Оскільки перевірка відбувається повністю поза мережею, ми повертаємося до раніше обговорених протоколів активів CSV і мережі Lightning. У попередніх обговореннях було зазначено, що в дизайні CSV ми не можемо повністю запобігти змові. Що ми можемо зробити, так це використовувати криптографію та розробку протоколів, щоб утримувати шкоду від зловмисної змови в контрольованому діапазоні, що робить таку поведінку невигідною.
10. Плюси та мінуси валідації поза мережею очевидні. Перевагою є мінімальне використання мережевих ресурсів із величезним потенціалом для розширення. Недоліком є те, що майже неможливо повністю використовувати безпеку BTC, що значно обмежує типи та методи транзакцій поза мережею. Крім того, перевірка поза мережею також означає, що дані зберігаються поза мережею, керуються користувачами, що вимагає вищих вимог до безпеки середовища виконання програмного забезпечення та стабільності програмного забезпечення.

Тенденція еволюції розширення

Зараз популярний Layer2 на Ethereum, по суті, використовує Layer1 для перевірки обчислювальної ефективності Layer2. Тобто обчислення стану переміщуються до рівня 2, але перевірка залишається на рівні 1. У майбутньому ми зможемо так само знизити обчислення перевірки поза ланцюгом, ще більше підвищуючи продуктивність поточної інфраструктури блокчейну.

Відмова від відповідальності:

1. Ця стаття передрукована з [дзеркало]. Усі авторські права належать оригінальному автору [Ben77]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.