Передмова

Випуск активів на основі BTC завжди був гарячою темою. Від найдавніших кольорових монет у 2011 році до нещодавно популярного протоколу Ordinal, спільнота BTC постійно знаходила нових гравців і досягла консенсусу, але мало хто залишився. Проте Lightning Labs оприлюднила амбітні плани щодо розробки стейблкойнів на основі Taproot Assets. Tether також оголосив, що буде використовувати протокол RGB для карбування USDT на рівні 1 біткойна.

Це означає, що колись відомий OmniLayer (раніше Mastercoin) більше не є найбільшим гравцем в екосистемі BTC. І протоколи перевірки активів на стороні клієнта (CSV) починають входити в поле зору кожного. Ці протоколи не тільки зберігають цілісність традиційних протоколів активів Bitcoin, але й підвищують масштабованість. Проте низка протоколів активів в екосистемі біткойн викликає доречні запитання: чим вони відрізняються один від одного, і як слід орієнтуватися та використовувати можливості в цьому ландшафті?

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

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

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

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

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

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

Результат виглядав так:

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

1. Взаємозамінність і проблема мінімальної прив’язки Прив’язуючи 1000 sats до транзакції genesis для кольорової монети, мінімальна одиниця цієї кольорової монети стає 1 sat. Це означає, що теоретично актив або токен можна розділити на максимум 1000 одиниць (але на практиці це менше, щоб запобігти атакам пилу). Наприклад, колись мінімальне значення сатоші було встановлено на рівні 546 SAT, а для ординалів воно навіть вище).
2. Проблеми перевірки Щоб визначити автентичність і право власності на кольорову монету, її історію транзакцій потрібно відстежити та підтвердити від транзакції походження до поточного UTXO. Тому потрібно розробити спеціальні гаманці, повні вузли та навіть сканер.
3. Потенційний ризик цензури майнера. ColoredTransaction має відмінні характеристики, наприклад запис метаданих у вихідні дані, що створює можливість цензури майнера.

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

Перше ICO в Crypto: Mastercoin

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

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

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

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

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

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

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

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

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

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

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

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

Щоб слідувати думкам Пітера Тодда, нам спочатку потрібно зрозуміти, яку проблему насправді вирішує біткойн. За словами Пітера Тодда, біткойн вирішує три проблеми:

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

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

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

Спочатку розглянемо, що потрібно перевірити:

1. Стан (перевірка логіки транзакції)
2. Переконайтеся, що вхідні дані (TxIn) дійсні, щоб запобігти подвійному витрачанню.

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

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

Структура дерева зобов’язань, запропонована Пітером Тоддом, виглядає наступним чином:

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

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

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

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

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

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

1. л: печатка
2. m: повідомлення, яке є інформацією або транзакцією
3. w: свідок, хтось або щось, що може підтвердити печатку

Основні операції: Є дві основні дії:

1. Close(l, m) → w: закриває печатку l на повідомленні m, створюючи свідка w.
2. Verify(l, w, m) → bool: перевірити, чи закрито печатку l у повідомленні m.

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

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

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

Якщо говорити ще простіше:

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

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

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

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

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

RGB, піонер CSV

Концепція RGB була запропонована Джакомо Зукко, відомою людиною в спільноті, після 2015 року. Це був період, коли Ethereum був на підйомі, ICO (Initial Coin Offerings) поширювалися, і було зроблено багато спроб створити проекти, окрім Bitcoin, такі як Mastercoin і Colored Coins.

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

Крім згаданих раніше характеристик активів, які використовують перевірку на стороні клієнта, основною відмінністю від RGB і попередніх протоколів активів є додавання віртуальної машини виконання (Virtual Machine) для виконання контракту за Тьюрингом. Для забезпечення безпеки даних контракту розроблено схему та інтерфейс. Схема, подібно до схеми Ethereum, декларує зміст і функції контракту, тоді як інтерфейс відповідає за реалізацію певних функцій, подібних до інтерфейсів у мовах програмування.

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

Механізм зобов'язання, що використовується в RGB, Педерсен Хеш

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

Дизайн віртуальної машини для RGB Simplicity → AluVM

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

Напрямок масштабування рівня RGB 2: мережа Lightning чи Sidechain?

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

RGB і Lightning Network

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

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

Sidechain Prime від RGB

LNP-BP, поточний супроводжувач протоколу RGB, у червні 2023 року оприлюднив пропозицію Maxim щодо перевіреного на стороні клієнта рішення масштабування активів під назвою Prime. У ньому Максим розкритикував існуючі сайдчейн і рішення масштабування 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, призначений для випуску активів у блокчейні біткойн. Цими активами можна миттєво торгувати у великих обсягах і за низькою ціною через Lightning Network. Основою Taproot Assets є використання безпеки та стабільності Bitcoin разом із швидкістю, масштабованістю та низькою вартістю Lightning Network. Протокол був розроблений і розроблений roasbeef, технічним директором Lightning Labs. Роасбіф, ймовірно, єдина людина на планеті, яка особисто керувала розробкою як клієнта Bitcoin (BTCD), так і клієнта Lightning Network (LND), демонструючи глибоке розуміння BTC.

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

Структура кодування Taproot Assets така:

Роасбіф, технічний директор Lighting Labs

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

Відмінності між Taproot Assets і RGB

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

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

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

Taproot Assets було розроблено у відповідь на оновлення Taproot мережі Bitcoin. Він використовує TaprootScriptVM, який є механізмом виконання сценаріїв, який постачається з біткойнами після оновлення Taproot. Крім того, він використовує vPSBT, варіант PSBT Bitcoin, що вказує на те, що після розробки механізму каналу блискавки Taproot Assets він може негайно повторно використовувати всю поточну інфраструктуру LND (Lightning Network Daemon), а також попередні продукти від Lightning Labs (LND). в даний час займає понад 90% частки ринку в мережі Lightning). Крім того, нещодавня популярна пропозиція BitVM базується на TaprootScript, що теоретично означає, що всі ці вдосконалення зрештою можуть принести користь Taproot Assets.

Однак RGB працює дещо інакше. Його віртуальна машина та правила перевірки (SCHEMA) є частиною автономної системи, утворюючи дещо закриту екосистему. RGB працює у власній екосистемі, і його зв’язок із ширшою екосистемою біткойнів не такий тісний, як дехто міг би подумати. Наприклад, щодо оновлення Taproot, єдиною реальною взаємодією RGB є кодування даних зобов’язань у блокчейні в Witness TapLeaf. Це показує, що RGB і оновлення Taproot лише мінімально пов’язані.

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

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

З іншого боку, Taproot Assets має простіший дизайн, але наразі лише зберігає баланси активів і не обробляє складніші стани, що робить обговорення розумних контрактів передчасними. Однак, згідно з Lightning Labs, наступного року планується зосередитися на розробці смарт-контрактів для Taproot Assets.

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

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

У системі RGB цю роль виконує Storm, який синхронізує дані перевірки поза ланцюгом через однорангову (p2p) мережу. Однак через історичні причини, пов’язані з командою розробників RGB, ці групи наразі використовують несумісні формати перевірки. Команда екосистеми RGB, DIBA, зазначила, що розробить « карбонадо » для вирішення цієї проблеми, але прогрес у цьому невідомий.

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

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

Короткий погляд на майбутнє масштабування BTC

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

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

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

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

Де відбувається перевірка? Це має вирішальне значення.

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

З точки зору реалізацій на основі перевірки, у нас є три напрямки масштабування:

1. Верифікація on-chain (ОП-ЗКП)

Впровадження OP-ZKP безпосередньо в TaprootScriptVM наділило б сам біткойн можливістю виконувати перевірку ZKP. Це, у поєднанні з деякими протоколами врегулювання дизайну Covenant, може створити рішення для масштабування Zk-Rollup, яке успадкує безпеку біткойна. Однак, на відміну від розгортання контракту перевірки на Ethereum, оновлення Bitcoin за своєю суттю відбуваються повільно, і додавання такого спеціалізованого операційного коду, який потенційно потребує оновлення, неминуче буде складним завданням.

2. Верифікація в напівланцюжку (BitVM)

Конструкція BitVM гарантує, що вона не призначена для звичайної логіки транзакцій. Робін Лінус також зазначив, що майбутнє BitVM полягає у створенні вільного міжланцюгового ринку для різних SideChains. Підхід BitVM вважається напів-ланцюгом, оскільки більшість обчислень перевірки відбуватимуться не в ланцюзі, а поза ланцюгом. Важливою причиною проектування навколо Taproot Bitcoin є використання TapScriptVM для обчислювальної перевірки, коли це необхідно, теоретично успадковуючи безпеку Bitcoin. Цей процес також створює довірчий ланцюжок перевірки, наприклад, потрібен лише один чесний верифікатор серед 'n' верифікаторів, відомий як Optimistic Rollups.

BitVM несе значні накладні витрати на мережу, але чи може вона використовувати докази шахрайства ZK для підвищення ефективності? Відповідь – ні, оскільки впровадження доказів шахрайства ZK залежить від здатності виконувати перевірку ZKP у мережі, що повертає нас до труднощів підходу OP-ZKP.

3. Перевірка поза мережею (перевірка на стороні клієнта, мережа Lightning)

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

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

Тенденція еволюції масштабування

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

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

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