Автор: Chakra Research
На додаток до власного рішення розширення, згаданого в першому томі, інший шлях розширення для Bitcoin використовує додатковий рівень протоколу поверх Bitcoin, який називається Рівень 2. Двома найважливішими моментами рішення рівня 2 є безпечне двостороннє з’єднання та успадкування консенсусної безпеки біткойнів.
Бічний ланцюг
Походження концепції бічного ланцюга можна простежити до «Впровадження інновацій у блокчейні за допомогою прив’язаного бічного ланцюга», представленого blockStream у 2014 році. Це відносно простий план розширення.
принцип роботи
Бічний ланцюг — це блокчейн, який працює повністю незалежно від основного ланцюга. Він має власний консенсусний протокол і може використовуватися як експериментальне поле для інновацій основного ланцюга. Коли злоякісна подія виникає в бічному ланцюзі, пошкодження повністю обмежується самим бічним ланцюгом і не впливає на головний ланцюг. Бічний ланцюг може використовувати більш високий консенсусний протокол TPS, щоб збільшити можливості програмування в ланцюзі та досягти покращення BTC.
Бічний ланцюг може реалізовувати передачу біткойнів між різними блокчейнами через двосторонню прив’язку або односторонню прив’язку. Звичайно, фактично BTC може залишатися лише в мережі біткойн, тому нам потрібен механізм прив’язки, щоб зробити бічний ланцюг. BTC у ланцюжку підключено до BTC у мережі Bitcoin.
Одностороння прив’язка вимагає від користувачів надсилати BTC в основній мережі на недоступну адресу для знищення, а потім відповідну кількість BTC буде отримано на бічному ланцюзі, але процес не можна повернути назад. Двостороння прив’язка є подальшим оновленням односторонньої прив’язки, що дозволяє BTC рухатися вперед і назад між основним і бічними ланцюгами. Замість того, щоб надсилати його на недоступну адресу для знищення, двостороння прив’язка блокуватиме BTC за допомогою сценаріїв керування, таких як мультипідпис, і карбувати нові BTC у бічному ланцюзі. Коли користувач захоче повернутися до основної мережі, BTC у бічному ланцюзі буде спалено, а початково заблокований B TC буде випущено в основну мережу.
Реалізація односторонньої прив’язки набагато простіша, ніж двостороння прив’язка, оскільки немає потреби керувати відповідним станом у мережі біткойн, але активи бічного ланцюга, створені за допомогою односторонньої прив’язки, можуть бути марними через відсутність механізму зворотного кріплення.
Існують різні рішення та різні рівні безпеки для перевірки транзакцій блокування в основному ланцюзі та транзакцій знищення в бічному ланцюзі. Найпростішим є використання зовнішньої перевірки учасниками з кількома підписами, але ризик централізації є високим. Кращим варіантом є використання SPV Proof для досягнення децентралізованої перевірки. Звичайно, оскільки в основній мережі біткойн відсутні необхідні можливості програмування для перевірки SPV, можна вибрати лише інші методи, як правило, зберігання кількох підписів.
Питання та ідеї
Є дві основні проблеми, за які бічні ланцюги критикують:
Залежність міжланцюжкових активів від верифікаторів: оскільки основна мережа біткойн ще не в змозі реалізувати смарт-контракти, передача активів між ланцюжками не може бути оброблена за допомогою логіки контракту без довіри потрібно покладатися на групу верифікаторів, щоб завершити операцію, існує припущення про довіру та існує ризик шахрайства.
Бічний ланцюг не може успадкувати безпеку основного ланцюга: бічний ланцюг працює повністю незалежно від основної мережі та не може успадкувати безпеку основної мережі.
У цьому відношенні ідеї бічних ланцюгів включають опору на авторитет (тип альянсу), опору на економічну безпеку (PoS), опору на децентралізовані майнери біткойнів (Merged Mining), опору на апаратні модулі безпеки (HSM), зберігання коштів і бічний ланцюг на біткойнах. Різні ролі можуть відповідати за виробництво блоків ланцюжка, запроваджуючи таким чином більш складні механізми безпеки.
Введення кейсу
Рідина
Першою формою бічного ланцюга є бічний ланцюг альянсу, у якому кілька суб’єктів, вибраних заздалегідь, служать верифікаторами та відповідають за зберігання коштів основної мережі та виробництво блоків бічного ланцюга.
Liquid є представником стороннього ланцюга альянсу, з 15 учасниками, які виконують функції верифікаторів, метод управління закритими ключами не розголошується, а для перевірки потрібно 11 підписів. Блоки на бічній ланцюжку також обслуговуються 15 учасниками альянсу з невеликою кількістю вузлів, які можуть досягти вищих цілей розширення.
Підхід стороннього ланцюга альянсу має значні централізовані ризики безпеки.
Підщепа (РСК)
RSK також має 15 вузлів, які служать зберігачами фондів основної мережі, і для перевірки потрібно лише 8 підписів. Відмінність від Liquid полягає в тому, що мультипідписним ключем керує апаратний модуль безпеки HSM, а інструкція виведення підписується відповідно до консенсусу PoW, щоб запобігти маніпулюванню депонованими коштами верифікатору, який утримує ключ.
З точки зору консенсусу бічного ланцюга, RSK використовує обчислювальну потужність основної мережі для забезпечення безпеки транзакцій у бічному ланцюзі. Коли частка об’єднаної обчислювальної потужності в основній мережі є високою, це може краще запобігти стороні ланцюжок від зламу. RSK вніс удосконалення в Merged Mining, щоб забезпечити безпеку бічних ланцюжків за низьких хешрейтів. Він застосовує метод з урахуванням форка для виконання консенсусного втручання в поведінку форка та зменшення ймовірності подвійних витрат.
Однак Merged Mining змінює стимули майнерів і посилює ризики MEV, що в кінцевому підсумку може дестабілізувати систему. У довгостроковій перспективі Merged Mining може збільшити централізацію майнінгу.
Стеки
Стеки прив’язують історію ланцюжка біткойнів, надсилаючи хеш блоку біткойна. Він має таку саму фінальність, як і біткойн протистояти подвійним витратам.
sBTC представляє новий токен STX і модель стимулювання, використовуючи метод мосту застави, який дозволяє використовувати до 150 валідаторів основної мережі. У так званому стейкинг-бриджі валідаторам потрібно робити ставки на токени STX, щоб отримати дозвіл на затвердження депозитів і зняття коштів. Безпека заставного мосту значною мірою залежить від вартості заставлених активів. Коли вартість заставлених активів різко коливається, безпека крос-ланцюга BTC може бути легко пошкоджена. Якщо вартість заставлених активів нижча за вартість міжланцюжкових активів, валідатор має стимул чинити зло.
Є також кілька пропозицій сайдчейну, які широко обговорюються в спільноті.
Привідний ланцюг
Найбільшу увагу привернула Drivechain, запропонована Полом Шторцем у 2015 році. Ключовим технологіям у плані було призначено BIP 300 (механізм прив’язки) і BIP 301 (сліпий об’єднаний майнінг). BIP 300 детально визначає логіку додавання нового бічного ланцюга. Активація нового бічного ланцюга схожа на активацію софт-форка за допомогою сигналів майнера. BIP 301 дозволяє майнерам біткойнів ставати виробниками блоків сайдчейнів без перевірки конкретного вмісту транзакцій.
Майнери також відповідають за схвалення транзакцій зняття коштів. Майнери спочатку повинні створити вихідні дані OP_RETURN для блоку, який вони видобули. Після цього кожен майнер може проголосувати за вашу пропозицію може в будь-який момент проголосувати за або проти пропозиції. Щойно транзакція виведення коштів перевищує порогове значення (13150 блоків), транзакція виведення коштів офіційно виконується та підтверджується основним ланцюгом біткойнів.
Насправді майнери мають повний контроль над коштами на Drivechain. Якщо кошти вкрадено, користувачі можуть врятуватися лише через UASF (активований користувачем програмний форк), але це дуже важко досягти консенсусу. Крім того, унікальна позиція майнерів у Drivechain посилює ризики MEV, як це вже було продемонстровано в Ethereum.
Spacechain
Spacechain застосував інший підхід, використовуючи Perpetual 1 way peg (P1WP). Користувачі спалюють BTC, щоб отримати токени на Spacechain, безпосередньо пропускаючи проблему безпеки коштів. Цей токен можна використовувати лише для аукціону блокування простору в ланцюжку просторів і не має жодної функції зберігання вартості.
Щоб забезпечити безпеку бічного ланцюга, Spacechain використовує сліпий майнінг, а інші користувачі використовують ANYPREVOUT (APO), щоб публічно конкурувати за право створювати блоки без перевірки бічного ланцюга. Однак для запуску Spacechain потрібна підтримка Covanent, і біткойн-спільнота все ще обговорює необхідність програмного форка для додавання коду операції Covanent.
Загалом, Spacechain може реалізувати бічний ланцюг із такими ж властивостями децентралізації та стійкості до цензури, що й біткойн, і більшою програмованістю завдяки функції ставок для блоків біткойнів.
Софтчейн
Softchain — це пропозиція бічного ланцюга 2wp, запропонована автором Spacechain Рубеном Сомсеном. Він використовує механізм консенсусу PoW FP для забезпечення безпеки бічного ланцюга. За звичайних обставин повному вузлу біткойна потрібно лише завантажити заголовок блоку softchain і перевірити підтвердження роботи. Коли відбувається розгалуження, завантажте залишений блок і відповідне зобов’язання набору UTXO, щоб перевірити дійсність блоку.
Для механізму 2wp під час прив’язки транзакція депозиту створюється в основному ланцюжку, а транзакція основного ланцюга посилається на софтчейн для отримання коштів під час прив’язки, транзакція зняття створюється на софтчейні, а потім транзакція зазначена в основному ланцюжку, щоб отримати кошти, і процес виведення коштів потрібно чекати протягом тривалого періоду, перш ніж він може бути завершений. Спеціальні механізми закріплення та витягування вимагають підтримки м’якої вилки, тому рішення називається Softchain.
Рішення Softchain накладає додаткові витрати на перевірку повних вузлів основної мережі Bitcoin. Консенсусний поділ Softchain може вплинути на досягнення консенсусу основної мережі та стати можливим засобом атаки на основну мережу Bitcoin.
Мережа Lightning
Lightning Network випустила технічну документацію в 2015 році та була офіційно запущена в 2018 році. Будучи платіжним протоколом рівня 2 на біткойнах, він спрямований на передачу великої кількості транзакцій на невеликі суми з високою частотою для обробки поза мережею довгий час вона вважалася найпередовішою технологією в мережі Bitcoin.
основний модуль
Реалізація Lightning Network невіддільна від кількох важливих модулів у Bitcoin, які разом забезпечують безпеку транзакцій Lightning Network.
По-перше, це попередньо підписана транзакція. Попередньо підписані транзакції стали безпечними та доступними лише після оновлення SegWit. SegWit відокремлює підписи від решти даних транзакцій, вирішуючи такі проблеми, як потенційні циклічні залежності, підробка транзакцій третьою стороною та підробка транзакцій другою стороною. Безпека обчислень у ланцюжку Lightning Network гарантується безвідкличним зобов’язанням, наданим іншою стороною, і це зобов’язання реалізується через попередньо підписані транзакції. Після отримання попередньо підписаної транзакції, наданої іншою стороною, користувач може транслювати транзакцію в ланцюг у будь-який час, щоб завершити виконання обіцянки.
По-друге, мультипідпис. Часті перекази коштів між двома сторонами вимагають, щоб обидві сторони мали певні права контролю, тому, як правило, використовується мультипідпис 2/2, який забезпечує передачу коштів має бути здійснено за взаємною згодою обох сторін.
Однак мультипідпис 2/2 спричинить проблеми з живучістю, тобто якщо інша сторона не співпрацюватиме, користувач не зможе передати жодні активи з адреси мультипідпису, що призведе до втрати вихідних коштів. Блокування часу може вирішити проблему живучості. Попереднє підписання контракту з блокуванням часу для повернення коштів може гарантувати, що навіть якщо одна сторона стане неактивною, інша сторона зможе повернути початкові кошти.
Нарешті, є хеш-блокування, яке може з’єднати кілька каналів стану та побудувати мережу. Оригінальний образ хешу буде використовуватися як засіб зв’язку для координації правильної роботи кількох об’єктів.
Запустити процес
двосторонній канал
Обидві сторони, які використовують Lightning Network для проведення транзакцій, спочатку повинні відкрити двосторонній платіжний канал у біткойнах. Обидві сторони можуть проводити будь-яку кількість транзакцій поза мережею завершити розрахунок і закрити прохід.
Зокрема, впровадження платіжних каналів передбачає наступні ключові кроки:
Створіть адресу з кількома підписами. Обом сторонам каналу спершу потрібно створити адресу мультипідпису 2 із 2 як адресу блокування коштів каналу. Кожна сторона має закритий ключ підпису та надає власний відкритий ключ.
Ініціалізація каналу. Обидві сторони транслюють транзакцію в ланцюжку та блокують певну кількість біткойнів на адресу мультипідпису як початкові кошти каналу. Ця транзакція називається «якірною» транзакцією каналу.
Оновити статус каналу. Під час здійснення платежу в межах каналу обидві сторони оновлюють статус каналу шляхом обміну попередньо підписаними транзакціями. Кожне оновлення створюватиме нову «транзакцію зобов’язань», що представлятиме поточний статус розподілу коштів. Трансакція зобов’язань має два результати, що відповідають часткам фонду обох сторін.
Транслювати останній статус. Будь-яка сторона каналу може в будь-який час транслювати останню трансакцію зобов’язань у блокчейн, щоб вилучити свою частку коштів. Щоб запобігти трансляції старого статусу іншою стороною, кожна транзакція зобов’язань має відповідну «транзакцію покарання», якщо інша сторона обманює, ви можете отримати всі кошти іншої сторони.
Закрийте канал. Коли дві сторони вирішують закрити канал, вони можуть співпрацювати для створення «розрахункової транзакції», яка передає остаточний статус розподілу коштів у блокчейн. Таким чином кошти, заблоковані в адресі мультипідпису, повертаються на особисті адреси обох сторін.
Он-чейн арбітраж. Якщо дві сторони не можуть дійти згоди під час закриття каналу, будь-яка зі сторін може в односторонньому порядку оприлюднити останню трансакцію зобов’язань і розпочати арбітражний процес у мережі. Якщо протягом певного періоду часу (наприклад, 1 день) немає заперечень, кошти будуть надіслані обом сторонам відповідно до розподілу здійсненої транзакції.
платіжна мережа
Платіжні канали можуть бути з’єднані один з одним, щоб утворити мережу, яка підтримує маршрутизацію з кількома переходами, реалізовану через HTLC. HTLC використовує хеш-блокування як пряму умову та платіж підпису з блокуванням часу як резервну умову. Користувачі можуть взаємодіяти з вихідним зображенням хешу до закінчення терміну блокування.
Якщо між двома користувачами немає прямого каналу, платіж можна здійснити за допомогою HTLC між маршрутизаторами. Хеш-прообраз R відіграє ключову роль у всьому процесі, забезпечуючи атомарність платежу. У той же час блокування часу HTLC налаштовано на зменшення часу, гарантуючи, що кожен стрибок має достатньо часу для обробки та пересилання платежу.
Проблеми
По суті, Lightning Network обходить припущення зовнішньої довіри щодо перемикання активів через канали стану p2p, використовуючи сценарії блокування часу, щоб забезпечити максимальну гарантію активів і забезпечити захист від збоїв. Коли інша сторона втрачає активність і не співпрацює, односторонній вихід може бути завершений. Таким чином, Lightning Network має високу цінність у сценаріях оплати, але вона також має багато обмежень, зокрема:
Обмеження пропускної здатності каналу. Пропускна здатність платіжного каналу в Lightning Network обмежена початковими заблокованими коштами та не може підтримувати великі платежі, які перевищують пропускну здатність каналу. Це може обмежити певні сценарії застосування, наприклад торгівлю товарами.
Онлайн і синхронізовано. Щоб своєчасно отримувати та пересилати платежі, вузли Lightning Network повинні залишатися онлайн. Якщо вузол тривалий час перебуває в автономному режимі, він може пропустити деякі оновлення статусу каналу, що призведе до несинхронізації стану. Це може бути проблемою для окремих користувачів і мобільних пристроїв, а також збільшує вартість операцій вузла.
Управління ліквідністю. Ефективність маршрутизації мережі Lightning Network залежить від розподілу ліквідності каналів. Якщо кошти розподіляються нерівномірно, деякі способи оплати можуть не працювати, що вплине на взаємодію з користувачем. Управління балансом ліквідності каналу вимагає певних технічних і капітальних витрат.
Порушення конфіденційності. Щоб знайти доступні платіжні шляхи, алгоритм маршрутизації Lightning Network вимагає певного рівня знань про пропускну здатність каналу та інформацію про підключення. Це може виявити конфіденційність деяких користувачів, як-от розподіл коштів, контрагентів тощо. Відкриття та закриття платіжних каналів також може розкрити інформацію про відповідних учасників.
RGB
Початкову ідею протоколу RGB надихнули концепції верифікації клієнта та одноразового запечатування, запропоновані Пітером Тоддом. Його запропонував Джакомо Зукко в 2016 році. Це масштабований протокол другого рівня біткойн, який зберігає конфіденційність.
Головна думка
Перевірка клієнта
Процес перевірки блокчейну полягає в трансляції блоків, що складаються з транзакцій, усім, дозволяючи кожному вузлу обчислити транзакції в блоці та завершити перевірку. Це фактично створює суспільне благо, тобто вузли в мережі допомагають кожному, хто надсилає транзакцію, завершити перевірку, а користувачі надають BTC як комісію за обробку як стимул для допомоги з перевіркою. Перевірка на стороні клієнта не виконується глобально, а перевіряється особами, які беруть участь у певних переходах між станами. Це значно покращує конфіденційність навантаження на вузли та покращує масштабованість.
Одноразова пломба
Якщо користувачі не можуть зібрати повну історію переходів між станами, їх можуть ошукати та подвійно витратити. Для вирішення цієї проблеми пропонується одноразова пломбування, яка використовує спеціальний предмет, який можна використовувати лише один раз, щоб уникнути подвійних витрат і підвищити безпеку. UTXO біткойна є найбільш підходящим одноразовим запечатаним об’єктом, гарантованим механізмом консенсусу біткойна та обчислювальною потужністю всієї мережі, тому активи RGB можуть успадкувати безпеку біткойна.
Криптообіцянка
Одноразову печатку потрібно поєднати із зобов’язанням щодо шифрування, щоб переконатися, що користувач знає про перехід стану та уникнути виникнення атак подвійного витрачання. Так зване зобов'язання повідомити іншим про те, що щось трапилося і не може бути змінено пізніше, але немає необхідності розкривати конкретні події до моменту, коли буде потрібна перевірка, щоб взяти зобов'язання за допомогою хеш-функції. У RGB змістом зобов’язання є перехід стану. Через витрати UTXO одержувач активу RGB отримає сигнал передачі стану, а потім перевірить зобов’язання щодо конкретних даних, переданих поза ланцюгом споживачем. актив.
робочий процес
RGB використовує консенсус біткойнів для забезпечення безпеки подвійних витрат і стійкості до цензури, а всі перевірки державних переказів передаються за межі мережі та перевіряються лише клієнтом, який приймає платіж.
Для емітента активів RGB необхідно створити договір RGB шляхом ініціювання транзакції, у якій конкретне інформаційне зобов’язання зберігатиметься в сценарії OP_RETURN певної умови витрат у транзакції Taproot.
Коли власник активу RGB хоче витратити кошти, йому потрібно отримати відповідну інформацію від одержувача активу, створити транзакцію RGB, зафіксувати деталі транзакції RGB і розмістити значення зобов’язання в UTXO, указаному одержувачем активу. . і видати транзакцію, яка витрачає вихідний UTXO та створює UTXO, указаний одержувачем. Коли одержувач активу помічає, що UTXO, у якому спочатку зберігався актив RGB, витрачено, він може перевірити дійсність транзакції RGB через зобов’язання в транзакції біткойн. Коли перевірка стане дійсною, він вважає, що він справді отримав Ресурс RGB.
Для одержувача активів RGB платник повинен надати початковий стан і правила переходу між станами контракту, транзакції Bitcoin, які використовуються для кожного переказу, транзакції RGB, здійснені кожною біржею Bitcoin, і дійсність кожної транзакції Bitcoin, перевірено клієнтом одержувача на основі цих даних, перевіряє дійсність транзакції RGB. Серед них UTXO біткойна використовується як контейнер для збереження стану контракту RGB. Історію передачі кожного контракту RGB можна виразити як спрямований ациклічний графік. Одержувач активу RGB може отримати лише інформацію, пов’язану з RGB актив, який він має, і не може отримати доступ до інших гілок.
Переваги та недоліки
Легка перевірка
У порівнянні з повною перевіркою блокчейну, протокол RGB значно знижує вартість перевірки. Користувачам не потрібно переглядати всі історичні блоки, щоб отримати останній статус, а потрібно лише синхронізувати історичні записи, пов’язані з активами, які вони отримують для перевірки. ефективність транзакції.
Ця легка перевірка спрощує однорангові транзакції, додатково усуваючи потребу в централізованих постачальниках послуг і підвищуючи рівень децентралізації.
Масштабованість
Протокол RGB успадковує безпеку біткойна лише завдяки хешу. Через скрипти Taproot майже не споживається додатковий простір у ланцюжку біткойнів, що робить можливим комплексне програмування активів. Завдяки використанню UTXO як контейнера, активи RGB мають природний паралелізм на різних гілках передачі, і їх можна витрачати одночасно.
Конфіденційність
На відміну від загальних протоколів, лише одержувач активів RGB може отримати історичний статус передачі активів RGB. Після завершення витрат майбутній статус передачі отримати неможливо, що суттєво гарантує конфіденційність користувача. Немає кореляції між транзакцією активів RGB і передачею Bitcoin UTXO, і інші не можуть отримати сліди транзакцій RGB у ланцюжку Bitcoin.
Крім того, RGB також підтримує сліпі витрати, і платник не може знати, в який UTXO будуть виплачені активи RGB, що ще більше покращує конфіденційність і підвищує стійкість до цензури.
недостатній
Коли активи RGB багато разів переходять із рук в руки, нові користувачі, які отримують активи, будуть змушені перевіряти тривалу історію передачі, що призводить до більшого навантаження на перевірку, час перевірки може бути довшим, а можливість швидкого підтвердження втрачається. Для вузлів, які продовжують працювати в блокчейні, оскільки останній статус завжди синхронізується, час отримання швидкої передачі статусу перевірки нової зони щоразу обмежений.
Спільнота обговорює можливість повторного використання історичних обчислень, а рекурсивний ZK Proof має можливість досягти постійної перевірки стану часу та розміру.
Згорнути
Огляд
Rollup — це найкраще рішення для розширення екосистеми Ethereum після років досліджень, від державних каналів до Plasma і, нарешті, до Rollup.
Rollup — це незалежний блокчейн, який збирає транзакції поза ланцюжком біткойнів, пакетує кілька транзакцій у пакет і виконує його, а також передає зобов’язання щодо даних і статусу цього пакета в основний ланцюг, реалізуючи обробку поза ланцюгом транзакцій і оновлення статусу. Щоб досягти максимального розширення, на цій стадії Rollup зазвичай використовує централізований секвенсор, щоб підвищити ефективність виконання без втрати безпеки, оскільки безпека гарантується перевіркою переходів стану Rollup в основному ланцюзі.
Оскільки рішення Rollup для екосистеми Ethereum розвивається, екосистема Bitcoin також почала експериментувати з Rollup. Однак найбільш критичною відмінністю між біткойнами та Ethereum є відсутність можливостей програмування та неможливість виконання обчислень, необхідних для створення Rollup у ланцюжку. Це змушує людей наразі лише намагатися реалізувати суверенний Rollup та OP Rollup.
Класифікація
Відповідно до різних методів перевірки передачі стану, зведення можна розділити на дві основні категорії: оптимістичне зведення та зведення дійсності (ZK Rollup).
Optimistic Rollup використовує оптимістичний метод перевірки. Після надсилання кожного пакета транзакцій будь-хто може перевірити дані поза ланцюгом, висунути заперечення щодо проблемних пакетів транзакцій, надіслати докази шахрайства головному ланцюжку та позбутися секвенсора. Якщо після періоду оскарження немає дійсного доказу шахрайства, пакет транзакцій вважається дійсним, а оновлення статусу підтверджується в головному ланцюжку.
Validity Rollup використовує перевірку Validity Proof. Sequencer використовує алгоритм перевірки з нульовим знанням, щоб створити стисле підтвердження дійсності для кожної партії транзакцій, доводячи, що передача стану партії є правильною Основний ланцюг перевіряє доказ, а потім розуміє та підтверджує оновлення статусу.
Перевага Optimistic Rollup полягає в тому, що його відносно просто запровадити та вимагає менше модифікацій основного ланцюжка. Але він має довший час підтвердження транзакції (залежно від періоду заперечення) і вимагає більшої доступності даних. Транзакції Validity Rollup підтверджуються швидко, не покладаються на періоди заперечень, і дані транзакцій можуть залишатися конфіденційними, але створення та перевірка підтверджень з нульовим знанням вимагає великих обчислювальних витрат.
Celestia також запропонувала концепцію суверенного зведення, яке публікується в спеціальному блокчейні рівня DA, який відповідає за доступність даних, а сам суверенний зведений пакет відповідає за виконання та розрахунок.
Досліджуйте та обговорюйте
Зведення Bitcoin все ще знаходиться на ранніх стадіях через відмінності між обліковою моделлю та мовою програмування та Ethereum, тому важко безпосередньо скопіювати практичний досвід Ethereum.
Зведений суверенітет
5 березня 2023 року Rollkit було оголошено як першу структуру, яка підтримує суверенні зведені біткойни. Конструктори суверенних зведених акцій можуть публікувати дані про доступність біткойнів через Rollkit.
Rollkit натхненний Ordinals і публікує дані через транзакції Taproot. Стандартна транзакція Taproot через публічний mempool може містити до 390 КБ даних, а нестандартна транзакція Taproot, видана безпосередньо майнером, може містити майже 4 МБ довільних даних.
Фактична робота Rollkit полягає в тому, щоб забезпечити інтерфейс для суверенного Rollup для читання та запису даних у біткойн, надання послуг проміжного програмного забезпечення клієнтам і перетворення біткойна на рівень DA.
Ідея суверенного згортання була сприйнята з великим скептицизмом, і багато противників стверджували, що суверенний згортання біткойнів — це не що інше, як використання біткойна як дошки оголошень і абсолютно нездатний успадкувати безпеку біткойна. Насправді, якщо ви надсилаєте лише дані про транзакції в біткойн, ви можете лише підвищити ефективність, тобто всі користувачі зможуть отримати відповідні дані для перевірки через біткойн, але безпека може бути визначена лише суверенним зведеним пакетом і не може бути успадкована. Крім того, простір для блоків важливий для біткойнів, і подання повних даних про транзакції може бути невдалим рішенням.
OP Rollup & Validity Rollup
Хоча багато проектів другого рівня Bitcoin називають себе ZK Rollup, що, по суті, ближче до OP Rollup, але включає в процес технологію Validity Proof, можливостей програмування Bitcoin ще недостатньо для підтримки прямої перевірки Validity Proof.
В даний час набір кодів операцій Bitcoin дуже обмежений і не може навіть безпосередньо обчислити множення. Перевірка Validity Proof вимагає розширення кодів операцій, а також значною мірою залежить від реалізації рекурсивних контрактів, які зараз обговорюються в спільноті, включаючи OP_CAT, OP_CHECKSIG. OP_TXHASH тощо. Звичайно, якби ми могли додати OP_VERIFY_ZKP безпосередньо, можливо, нам не знадобилися б жодні інші модифікації, але це, очевидно, малоймовірно. Крім того, обмеження розміру стека також перешкоджають спробам перевірити підтвердження дійсності в сценаріях біткойн, і багато спроб досліджуються.
Отже, як працює Validity Proof? Більшість проектів публікують Statediff і Validity Proof пакетів транзакцій у біткойнах у вигляді написів і використовують BitVM для оптимістичної перевірки. Тут BitVM Bridge замінить традиційне рішення з кількома підписами. Перш ніж користувачі внесуть депозит, альянс повинен буде попередньо підписати UTXO, який буде згенерований, щоб гарантувати, що депозит може бути законно отриманий лише Оператором. Після отримання попереднього підпису BTC буде заблоковано на адресу Taproot із мультипідписом N/N.
Коли користувач надсилає запит на зняття коштів, Rollup надсилає підтвердження дійсності з коренем зняття в ланцюжок біткойнів. Оператор спочатку задовольнить потреби користувача з власної кишені, а потім перевірить дійсність через контракт BitVM. Якщо кожен Оператор вважає, що сертифікат дійсний, Оператору буде відшкодовано через мультипідпис; доки хтось вважає, що є шахрайство, буде здійснено процес оскарження, а неправильна сторона буде урізана.
Цей процес фактично такий самий, як і припущення довіри 1/N. Поки один верифікатор є чесним, протокол безпечний.
Однак при технічній реалізації цього рішення можуть виникнути труднощі. У проекті OP Rollup Ethereum Arbitrum розроблявся протягом багатьох років, і поточний Fraud Proof все ще надсилається дозволеними вузлами; Optimism лише нещодавно оголосив, що підтримує Fraud Proof, що показує, наскільки важко це реалізувати.
Що стосується попередньо підписаної операції в мосту BitVM, то за підтримки Bitcoin Covanent її можна реалізувати більш ефективно, що все ще чекає на консенсус спільноти.
З точки зору атрибутів безпеки, надсилаючи хеш блоку Rollup до біткойна, ви отримуєте стійкість до реорганізації та подвійних витрат, а використання Optimistic Bridge забезпечує припущення безпеки 1/N. Проте стійкість мосту до цензури все ще може чекати подальшого розвитку.
Висновок: Layer 2 не є панацеєю
Дивлячись на стільки рішень рівня 2, ми можемо легко виявити, що кожне рішення обмежене в задачах, які воно може виконати. За певних припущень про довіру ефекти, яких може досягти Рівень 2, значною мірою залежать від Рівня 1, тобто власних можливостей біткойна.
Без оновлень SegWit і тимчасових блокувань не можна успішно побудувати мережу Lightning;
Багато Bitcoin Maxi вважають, що біткойн ніколи не слід змінювати, а всі недоліки не слід вирішувати за допомогою рівня 2. Це не є панацеєю. Нам потрібен більш потужний Рівень 1, щоб створити більш безпечний, ефективний і масштабований Рівень 2.
У наступній статті ми розповімо про спроби покращити програмування на біткойнах, тож слідкуйте за оновленнями.
