Поза блокчейном розширення Глибина аналізу

1. Необхідність розширення

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

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

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

• Безпека: Чим вищі витрати на отримання контролю над системою, тим вища безпека, ланцюг може витримувати атаки більшої частини учасників.

• Масштабованість: здатність блокчейну обробляти велику кількість транзакцій.

Перший значний жорсткий форк мережі Біткойн виник через проблему масштабування. Зі збільшенням кількості користувачів та обсягів транзакцій мережа Біткойн з обмеженням у 1 МБ на блок почала стикатися з проблемою заторів; з 2015 року в спільноті Біткойн існували розбіжності щодо проблеми масштабування, одна сторона підтримувала розширення блоку, а інша вважала, що слід використовувати рішення Segwit для оптимізації структури основного ланцюга. 1 серпня 2017 року Bitcoin ABC, який підтримував розширення блоку, запустив власну 8МБ клієнтську систему, що призвело до першого значного жорсткого форка в історії Біткойн, внаслідок чого з'явилася нова криптовалюта BCH.

Мережева Ethereum також вибирає жертвувати частиною масштабованості для забезпечення безпеки мережі та децентралізації. Хоча мережа Ethereum не обмежує обсяги транзакцій, як мережа Bitcoin, шляхом обмеження розміру блоку, вона фактично змінює це на встановлення верхньої межі для вартості пального, яку може містити один блок, але мета залишається тією ж: досягнення Trustless Consensus та забезпечення широкого розподілу вузлів.

З моменту появи CryptoKitties у 2017 році, через літо DeFi, а потім через зростання таких децентралізованих застосувань, як GameFi та NFT, ринок постійно збільшує попит на пропускну здатність, але навіть Тьюринг-повноцінний Ethereum може обробляти лише 15~45 транзакцій (TPS) на секунду, що призводить до зростання вартості транзакцій, збільшення часу розрахунків, більшість Dapps важко витримують витрати на експлуатацію, вся мережа стає повільною і дорогою для користувачів, проблема масштабування блокчейна потребує термінового вирішення. Ідеальне рішення для масштабування полягає в тому, щоб максимізувати швидкість транзакцій та пропускну здатність мережі без жертвування децентралізації та безпеки.

2. Категорії планів розширення

Ми поділяємо плани розширення на дві основні категорії: розширення на основному ланцюзі та розширення поза блокчейном, ґрунтуючись на критерії "чи змінювати один рівень основної мережі".

2.1 Розширення на ланцюзі

Основна концепція: рішення, яке досягає ефекту масштабування шляхом зміни одного з протоколів основної мережі, наразі основним рішенням є шардинг.

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

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

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

Зміна коду протоколу основної мережі може призвести до непередбачуваних негативних наслідків, оскільки будь-яка незначна вразливість безпеки на нижньому рівні може серйозно загрожувати безпеці всієї мережі, і мережа може бути змушена до розгалуження або переривання ремонту та оновлення. Наприклад, інцидент з інфляційною вразливістю Zcash у 2018 році: код Zcash базується на модифікації коду Bitcoin версії 0.11.2, у 2018 році один інженер виявив, що в його базовому коді є небезпечна вразливість, а саме, токени можуть бути безмежно надруковані, після чого команда витратила 8 місяців на таємне виправлення, а інцидент було опубліковано лише після виправлення вразливості.

2.2 поза блокчейном розширення

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

поза блокчейном рішення з масштабування можна додатково поділити на Layer2 та інші рішення:

! Глибокий звіт про дослідження на 10 000 слів: комплексний аналіз офчейн-експансії

3. Позаблокчейном розширення рішення

3.1 Державні канали

3.1.1 Резюме

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

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

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

3.1.2 Таймлайн

• 2015/02, Джозеф Пун і Тадеуш Дріджа опублікували чорновик білого паперу про мережу Lightning.
• 2015/11, Джефф Колман вперше систематично підсумував концепцію State Channel, запропонувавши, що Payment Channel біткойна є підвипадком концепції State Channel.
• 2016/01, Joseph Poon та Thaddeus Dryja офіційно опублікували білу книгу «The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments», в якій запропонували рішення для масштабування біткоїн-мережі - Payment Channel (, яке призначене лише для обробки платежів у біткоїн-мережі.
• У листопаді 2017 року були представлені перші проектні специфікації Sprites для State Channel, основані на фреймворку Payment Channel.
• 2018/06, Counterfactual запропонував дуже детальний дизайн Generalized State Channels, це перший повністю пов'язаний з каналами стану дизайн.
• У жовтні 2018 року в статті «Узагальнені державні мережі каналів» була запропонована концепція мереж державних каналів і віртуальних каналів.
• 2019/02, концепція статус-каналів розширюється на N-Party Channels, Nitro є першим протоколом, створеним на основі цієї ідеї.
• 2019/10, Pisa розробила концепцію Watchtowers, щоб вирішити проблему постійної онлайн присутності всіх учасників.
• 2020/03, Hydra запропонувала Швидкі ізоморфні канали.

)# 3.1.3 Технічні принципи

Рисунок 1 демонструє робочий процес на традиційній ланцюговій платформі: Аліса та Боб взаємодіють зі смарт-контрактом, розгорнутим в основній мережі, користувачі змінюють стан смарт-контракту, надсилаючи транзакції в ланцюг. Недоліком є виникнення обговорених вище проблем з часом та витратами.

! [Звіт про глибоке дослідження на 10 000 слів: комплексний аналіз офчейн-експансії]###https://img-cdn.gateio.im/webp-social/moments-087d35594a04d33375b8199b93eb355e.webp(

Рисунок 2 демонструє загальний робочий процес, якому слідує більшість протоколів каналу стану: в оптимістичному випадку, Аліса та Боб повинні виконати ті ж дії, що й раніше, але цього разу вони використовують канал стану, а не взаємодіють з контрактом на ланцюзі.

• Перший крок, Аліса та Боб взаємодіють, вносячи кошти з їхніх особистих EOA на адрес контракту поза блокчейном ), 1,2(, ці кошти блокуються в контракті, поки баланс не буде повернуто користувачеві після закриття каналу; після підписання підтвердження, стан каналу між ними офіційно відкритий.
• Другий крок, Аліса і Боб теоретично можуть проводити необмежену кількість угод поза блокчейном через цей канал ) синя пунктирна лінія (, учасники спілкуються один з одним за допомогою зашифрованих підписаних повідомлень ), а не з мережею блокчейну (. Обидва користувачі повинні підписати кожну угоду, щоб уникнути подвійного витрачання. Через ці повідомлення вони пропонують оновлення стану своїх рахунків і приймають оновлення стану, запропоновані іншою стороною.
• Третій крок, якщо Аліса хоче закрити канал і завершити транзакцію з Бобом, Аліса повинна подати остаточний стан свого рахунку ) взаємодія 3( до контракту. Якщо Боб підпише та затвердить, контракт звільнить заблоковані кошти відповідно до остаточного стану та поверне їх відповідному користувачу ) взаємодія 4,5(. Якщо Боб не відповість на підпис, контракт звільнить заблоковані кошти відповідно до остаточного стану після закінчення періоду оскарження.

![Тисячослівний звіт про дослідження: всебічний аналіз поза блокчейном розширення])https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(

Рисунок 3 показує робочий процес каналу стану в песимістичному випадку: спочатку двоє учасників вносять кошти ) взаємодія 1, 2(, після чого починають обмінюватися оновленнями стану ) синя пунктирна лінія (. Припустимо, в якийсь момент часу Боб у своєму раунді не відповідає на підписане оновлення стану, надіслане Алісою ) взаємодія 3(, в цей момент Аліса може ініціювати виклик, подавши до контракту своє останнє дійсне стан ) взаємодія 4(, це дійсне стан також містить попередній підпис Боба, що доводить, що остання транзакція була затверджена Бобом, фінальний стан був підтверджений Бобом. Після цього контракт дозволяє Бобу протягом певного часу відповідати, подавши наступний стан до контракту; якщо Боб відповідає, то обидва можуть продовжити торгівлю в каналі стану; якщо Боб не відповідає протягом цього періоду, контракт автоматично закриває канал стану та повертає кошти Алісі ) взаємодія 5(.

![Великий звіт про Глибину: всебічний аналіз поза блокчейном])https://img-cdn.gateio.im/webp-social/moments-ad088ac016d75b1ae0b0eda699e74709.webp(

)# 3.1.4 Плюси та мінуси

Переваги:

• Висока масштабованість: можна здійснювати необмежену кількість транзакцій
• Низька затримка: угоди виконуються миттєво
• Низька вартість: поза блокчейном торгівля майже безкоштовна
• Приватність: поза блокчейном транзакції не будуть записані в основній ланцюжку
• Доступність: навіть якщо основний ланцюг має проблеми, канали стану все ще можуть використовуватися

Недолік:

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

3.1.5 Застосування

Біткоїн-мережа блискавки

Огляд:

Мережева блискавка є каналом малих платежів у мережі біткойн, її загальна технологічна еволюція проходить через: 2/2 мультипідпис, що будує односторонній платіжний канал, після додавання RSMC###Revocable Sequence Maturity Contract( можна створити двосторонній платіжний канал, а потім, додавши HTLC)Hash Time Lock Contract(, розширити платіжний канал на багатосторонні платежі, зрештою створивши платіжну мережу, тобто мережу блискавки. Через позаблокчейн канали малих платежів, а потім завдяки посередникам формується торговельна мережа, що може вирішити проблему розширення мережі біткойн. Загальне використання мережі блискавки дотримується процесу "депозит)створення каналу(→транзакція мережі блискавки)оновлення стану каналу(→повернення/розрахунок)закриття каналу("; теоретично мережа блискавки може обробляти мільйон транзакцій за секунду.

Часова лінія:

• У лютому 2015 року Джозеф Пун і Таддеус Дріджа опублікували чернетку білого паперу Lightning Network;
• У січні 2016 року було опубліковано офіційну версію білого паперу та засновано Lightning Labs;
• 15 березня 2018 року компанія Lightning Labs випустила першу версію основної мережі Lightning Network Daemon )LND( версії 0.4.
• На початку 2021 року публічна ємність мережі Lightning становила )TVL( лише близько 40 мільйонів доларів.