Майбутнє блокчейну — це грандіозна візія: децентралізація, безпека та масштабованість; але зазвичай блокчейн може реалізувати лише два з цих аспектів, а задовольнити всі три вимоги називається проблемою неможливого трикутника блокчейну. Протягом багатьох років люди досліджували, як вирішити цю проблему, як підвищити пропускну здатність та швидкість транзакцій блокчейну, гарантуючи децентралізацію та безпеку, тобто вирішення проблеми масштабування, є однією з актуальних тем обговорення в процесі розвитку блокчейну.
Давайте спочатку загально визначимо децентралізацію, безпеку та масштабованість блокчейну:
Децентралізація: будь-хто може стати вузлом, що бере участь у виробництві та верифікації блочної системи, чим більше вузлів, тим вищий рівень децентралізації, що забезпечує, щоб мережа не потрапила під контроль невеликої групи великих централізованих учасників.
Безпека: Чим вищими є витрати на отримання контролю над системою блокчейн, тим вищою є безпека, отже, ланцюг може протистояти значній частині учасників, які намагаються його атакувати.
Масштабованість: здатність блокчейну обробляти велику кількість транзакцій.
Перше значне жорстке розгалуження мережі біткойн виникло через проблему розширення. Зі зростанням кількості користувачів біткойн та обсягу транзакцій мережа біткойн, обмежена 1 МБ на блок, почала стикатися з проблемою заторів; з 2015 року у спільноті біткойн існують розбіжності щодо проблеми розширення: одна сторона, яку представляє Bitcoin ABC, підтримує розширення блоків, а інша сторона, представленна Bitcoin Core, вважає, що слід використовувати рішення Segwit для оптимізації структури основного ланцюга. 1 серпня 2017 року клієнтська система Bitcoin ABC, розроблена до 8 МБ, почала працювати, що призвело до появи першого значного жорсткого розгалуження в історії біткойн, а також до виникнення нової криптовалюти BCH.
Також мережа Ethereum вибрала пожертвувати частиною масштабованості, щоб забезпечити безпеку та децентралізацію мережі; хоча мережа Ethereum не обмежує обсяг транзакцій, як це робить мережа Bitcoin шляхом обмеження розміру блоку, а натомість перетворюється на встановлення верхньої межі на витрати пального, які можуть бути прийняті в одному блоці, мета залишається реалізація Trustless Consensus і забезпечення широкого розподілу вузлів ( незалежно від того, чи скасують або підвищать ліміт, це призведе до виведення з експлуатації багатьох менших вузлів з недостатньою пропускною здатністю, пам'яттю та обчислювальною потужністю ).
Від CryptoKitties 2017 року, через літо DeFi, до подальшого зростання застосувань GameFi та NFT, ринок постійно зростає попит на пропускну спроможність. Але навіть найбільш досконалий Ethereum може обробляти лише 15~45 транзакцій на секунду (TPS), що призводить до постійного зростання витрат на транзакції, збільшення часу розрахунків, більшість Dapps важко витримувати витрати на експлуатацію, а вся мережа стає повільною та дорогою для користувачів. Проблему масштабування блокчейну необхідно терміново вирішити. Ідеальний варіант масштабування полягає в тому, щоб, не жертвуючи децентралізацією та безпекою, максимально підвищити швидкість транзакцій у мережі блокчейн ( коротший час фіналізації ) та пропускну спроможність транзакцій ( вищий TPS ).
2. Категорії планів розширення
Ми поділяємо плани розширення на дві великі категорії: розширення на основному ланцюгу та розширення поза блокчейном, відповідно до критерію "чи змінюється один рівень основної мережі".
2.1 розширення на ланцюзі
Основна концепція: рішення, яке досягає ефекту масштабування шляхом зміни одного рівня протоколу основної мережі, наразі основним рішенням є шардінг.
Розширення на блокчейні має кілька варіантів, у цій статті не розглядатимемо їх детально, нижче коротко перераховані два варіанти:
Варіант один – це розширення простору блоків, тобто збільшення кількості транзакцій, які упаковуються в кожен блок, але це підвищить вимоги до обладнання високопродуктивних вузлів, підвищить бар'єр для входу вузлів і зменшить рівень "децентралізації".
Варіант другий - шардінг, розділяє блокчейн-реєстр на кілька частин, більше не кожен вузол бере участь в усіх записах, а різні шардінги, тобто різні вузли, відповідають за різні записи, паралельні обчислення можуть одночасно обробляти кілька транзакцій; це знижує обчислювальне навантаження на вузли та поріг входження, підвищує швидкість обробки транзакцій та рівень децентралізації; але це означає, що обчислювальна потужність всієї мережі розподіляється, що знижує "безпеку" всієї мережі.
Зміна коду основного протоколу мережі може призвести до непередбачуваних негативних наслідків, оскільки будь-яка незначна вразливість у базовому рівні серйозно загрожує безпеці всієї мережі; мережа може бути змушена до розгалуження або переривання оновлення. Наприклад, інцидент з інфляційною вразливістю Zcash у 2018 році: код Zcash був змінений на основі коду версії Bitcoin 0.11.2, у 2018 році інженер виявив у базовому коді вразливість високого ризику, що дозволяє безкінечно випускати токени, і команда витратила 8 місяців на таємне виправлення, після чого інцидент був розкритий.
2.2 поза блокчейном розширення
Основна концепція: рішення для масштабування, яке не змінює існуючий протокол основної мережі першого рівня.
поза блокчейном рішення для розширення можна ще поділити на Layer2 та інші рішення:
Статевий канал передбачає, що лише під час відкриття, закриття або вирішення спірних питань користувачам потрібно взаємодіяти з основною мережею, а взаємодії між користувачами відбуваються поза блокчейном, що дозволяє знизити витрати часу та коштів для користувачів, а також реалізувати необмежену кількість транзакцій.
Статевий канал є простим 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/11, перша дизайнерська специфікація State Channel на основі фреймворка Payment Channel, Sprites, була запропонована.
2018/06, Counterfactual запропонував дуже детальний дизайн Generalized State Channels, це перший повністю пов'язаний з каналами стану дизайн.
У жовтні 2018 року в статті «Узагальнені державні мережі каналів» була запропонована концепція державних канальних мереж і віртуальних каналів.
2019/02, концепція каналів стану розширена до N-Party Channels, Nitro є першим протоколом, створеним на основі цієї ідеї.
2019/10, Pisa для вирішення проблеми постійної онлайн присутності всіх учасників розширила концепцію Watchtowers.
Рисунок 1 демонструє робочий процес на традиційній ланцюговій системі: Аліса та Боб взаємодіють зі смарт-контрактом, розгорнутим в основній мережі, користувачі змінюють стан смарт-контракту, надсилаючи транзакції на ланцюг. Недоліком є проблеми з часом та витратами, про які говорилося вище.
! [Глибокий звіт про дослідження на 10 000 слів: комплексний аналіз масштабування поза мережею]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
Рисунок 2 демонструє загальний робочий процес, якому слідує більшість протоколів каналів стану: в оптимістичному випадку Аліса та Боб повинні виконати ті ж самі дії, але цього разу вони використовують канал стану, а не взаємодіють з контрактом на блокчейні.
Перший крок, Аліса та Боб взаємодіють, вносячи кошти зі своїх особистих EOA на адрес контракту поза блокчейном ), ці кошти блокуються в контракті, поки канал не закриється, після чого залишок повертається користувачу; після підтвердження підписів обох сторін, статус-канал між ними офіційно відкривається.
Другий крок, Аліса та Боб теоретично можуть проводити необмежену кількість транзакцій поза блокчейном через цей канал ( блакитна пунктирна лінія ), учасники обмінюються зашифрованими підписаними повідомленнями (, а не спілкуються з мережею блокчейну ). Обидва користувачі повинні підписати кожну транзакцію, щоб запобігти подвійному витраті. За допомогою цих повідомлень вони пропонують оновлення стану своїх рахунків і приймають запропоновані оновлення стану з боку один одного.
Третій крок, якщо Аліса хоче закрити канал і завершити угоду з Бобом, Аліса повинна подати остаточний стан свого рахунку ( для взаємодії 3) до контракту. Якщо Боб підпише та схвалить, контракт звільнить заблоковані кошти відповідно до остаточного стану, повернувши їх відповідному користувачу ( для взаємодії 4,5). Якщо Боб не відповість на підпис, контракт звільнить заблоковані кошти відповідно до користувача після завершення періоду виклику.
Рисунок 3 демонструє робочий процес каналу стану в песимістичному варіанті: спочатку два учасники вносять кошти (, взаємодія 1, 2), а потім починають обмін станами ( синя пунктирна лінія ). Припустимо, в якийсь момент часу Боб не відповідає на підписаний стан оновлення, що надіслав Аліса (, взаємодія 3), в цей момент Аліса може ініціювати виклик, подавши свою останню дійсну стану в контракт (, взаємодія 4), ця дійсна стан також містить підпис Боба, що свідчить про те, що остання транзакція отримала затвердження Боба, і останній стан отримав підтвердження Боба. Потім контракт дозволяє Бобу протягом певного часу відповісти, подавши наступний стан у контракт; якщо Боб відповідає, то обидва можуть продовжити торгівлю в каналі стану; якщо Боб не відповідає в цей період часу, контракт автоматично закриває канал стану та повертає кошти Алісі (, взаємодія 5).
(# 3.1.4 Плюси та мінуси
Переваги:
Висока миттєвість транзакцій, підходить для високочастотних малих платежів
Низькі комісії за транзакції
Висока конфіденційність, поза блокчейном транзакції не будуть опубліковані
Висока масштабованість, теоретично безмежна TPS
Недоліки:
Потрібно заблокувати кошти
Під час закриття каналу потрібне підтвердження поза блокчейном
Учасники повинні залишатися онлайн
Не підходить для великих або малочастих угод
Існує ризик крадіжки коштів
)# 3.1.5 Додаток
Біткойн мережа блискавки
Огляд:
Ліхтарна мережа є каналом мікроплатежів у мережі Біткоїн, її загальна технологічна еволюція проходить через: 2/2 багатопідписне створення одностороннього платіжного каналу, після додавання RSMC###Revocable Sequence Maturity Contract### можна побудувати двосторонній платіжний канал, далі додається
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
4
Поділіться
Прокоментувати
0/400
ShitcoinConnoisseur
· 07-16 20:47
Занадто важко, наступний
Переглянути оригіналвідповісти на0
AirdropHunter420
· 07-16 20:38
Як вирішити трикутник? поза блокчейном теж не допомагає.
Переглянути оригіналвідповісти на0
mev_me_maybe
· 07-16 20:35
Не жартуй, це ж той трикутник. Вивчаємо його стільки часу, а досі не вирішили.
Глибокий аналіз: як рішення для розширення поза блокчейном можуть подолати трилему блокчейну
《поза блокчейном розширення Глибина аналізу》
Автор: дослідницька команда
1. Необхідність розширення
Майбутнє блокчейну — це грандіозна візія: децентралізація, безпека та масштабованість; але зазвичай блокчейн може реалізувати лише два з цих аспектів, а задовольнити всі три вимоги називається проблемою неможливого трикутника блокчейну. Протягом багатьох років люди досліджували, як вирішити цю проблему, як підвищити пропускну здатність та швидкість транзакцій блокчейну, гарантуючи децентралізацію та безпеку, тобто вирішення проблеми масштабування, є однією з актуальних тем обговорення в процесі розвитку блокчейну.
Давайте спочатку загально визначимо децентралізацію, безпеку та масштабованість блокчейну:
Перше значне жорстке розгалуження мережі біткойн виникло через проблему розширення. Зі зростанням кількості користувачів біткойн та обсягу транзакцій мережа біткойн, обмежена 1 МБ на блок, почала стикатися з проблемою заторів; з 2015 року у спільноті біткойн існують розбіжності щодо проблеми розширення: одна сторона, яку представляє Bitcoin ABC, підтримує розширення блоків, а інша сторона, представленна Bitcoin Core, вважає, що слід використовувати рішення Segwit для оптимізації структури основного ланцюга. 1 серпня 2017 року клієнтська система Bitcoin ABC, розроблена до 8 МБ, почала працювати, що призвело до появи першого значного жорсткого розгалуження в історії біткойн, а також до виникнення нової криптовалюти BCH.
Також мережа Ethereum вибрала пожертвувати частиною масштабованості, щоб забезпечити безпеку та децентралізацію мережі; хоча мережа Ethereum не обмежує обсяг транзакцій, як це робить мережа Bitcoin шляхом обмеження розміру блоку, а натомість перетворюється на встановлення верхньої межі на витрати пального, які можуть бути прийняті в одному блоці, мета залишається реалізація Trustless Consensus і забезпечення широкого розподілу вузлів ( незалежно від того, чи скасують або підвищать ліміт, це призведе до виведення з експлуатації багатьох менших вузлів з недостатньою пропускною здатністю, пам'яттю та обчислювальною потужністю ).
Від CryptoKitties 2017 року, через літо DeFi, до подальшого зростання застосувань GameFi та NFT, ринок постійно зростає попит на пропускну спроможність. Але навіть найбільш досконалий Ethereum може обробляти лише 15~45 транзакцій на секунду (TPS), що призводить до постійного зростання витрат на транзакції, збільшення часу розрахунків, більшість Dapps важко витримувати витрати на експлуатацію, а вся мережа стає повільною та дорогою для користувачів. Проблему масштабування блокчейну необхідно терміново вирішити. Ідеальний варіант масштабування полягає в тому, щоб, не жертвуючи децентралізацією та безпекою, максимально підвищити швидкість транзакцій у мережі блокчейн ( коротший час фіналізації ) та пропускну спроможність транзакцій ( вищий TPS ).
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 Хронологія
)# 3.1.3 Технічні принципи
Рисунок 1 демонструє робочий процес на традиційній ланцюговій системі: Аліса та Боб взаємодіють зі смарт-контрактом, розгорнутим в основній мережі, користувачі змінюють стан смарт-контракту, надсилаючи транзакції на ланцюг. Недоліком є проблеми з часом та витратами, про які говорилося вище.
! [Глибокий звіт про дослідження на 10 000 слів: комплексний аналіз масштабування поза мережею]###https://img-cdn.gateio.im/webp-social/moments-ead28de03be9fc22dcfe3f679ee36bc5.webp(
Рисунок 2 демонструє загальний робочий процес, якому слідує більшість протоколів каналів стану: в оптимістичному випадку Аліса та Боб повинні виконати ті ж самі дії, але цього разу вони використовують канал стану, а не взаємодіють з контрактом на блокчейні.
Рисунок 3 демонструє робочий процес каналу стану в песимістичному варіанті: спочатку два учасники вносять кошти (, взаємодія 1, 2), а потім починають обмін станами ( синя пунктирна лінія ). Припустимо, в якийсь момент часу Боб не відповідає на підписаний стан оновлення, що надіслав Аліса (, взаємодія 3), в цей момент Аліса може ініціювати виклик, подавши свою останню дійсну стану в контракт (, взаємодія 4), ця дійсна стан також містить підпис Боба, що свідчить про те, що остання транзакція отримала затвердження Боба, і останній стан отримав підтвердження Боба. Потім контракт дозволяє Бобу протягом певного часу відповісти, подавши наступний стан у контракт; якщо Боб відповідає, то обидва можуть продовжити торгівлю в каналі стану; якщо Боб не відповідає в цей період часу, контракт автоматично закриває канал стану та повертає кошти Алісі (, взаємодія 5).
(# 3.1.4 Плюси та мінуси
Переваги:
Недоліки:
)# 3.1.5 Додаток
Біткойн мережа блискавки
Огляд:
Ліхтарна мережа є каналом мікроплатежів у мережі Біткоїн, її загальна технологічна еволюція проходить через: 2/2 багатопідписне створення одностороннього платіжного каналу, після додавання RSMC###Revocable Sequence Maturity Contract### можна побудувати двосторонній платіжний канал, далі додається