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

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

Передумови

Вам слід було прочитати й зрозуміти наші сторінки про масштабування Ethereum та шар 2.

Що таке канали?

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

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

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

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

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

Канали peer-to-peer особливо корисні в ситуаціях, коли певні заздалегідь визначені учасники бажають здійснювати транзакції з високою частотою, не несучи видимих накладних витрат. Канали блокчейну поділяються на дві категорії: платіжні канали та канали стану.

Платіжні канали

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

Оновлення балансу реєстру (тобто стану платіжного каналу) вимагають схвалення всіх сторін у каналі. Оновлення каналу, підписане всіма учасниками каналу, вважається остаточним, так само як транзакція в Ethereum.

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

Канали стану

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

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

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

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

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

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

Як працюють канали стану

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

У наступному розділі описано основний робочий процес каналу стану:

Відкриття каналу

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

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

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

Використання каналу

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

Nonce, який діє як унікальний ідентифікатор для транзакцій та запобігає атакам повторного відтворення. Він також визначає порядок, у якому відбувалися оновлення стану (що важливо для вирішення спорів)
Старий стан каналу
Новий стан каналу
Транзакція, яка викликає перехід стану (наприклад, Аліса надсилає 5 ETH Бобу)

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

Закриття каналу

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

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

Описаний вище сценарій показує, що відбувається в позитивному випадку. Іноді користувачі не можуть дійти згоди та фіналізувати канал (негативний випадок). Будь-що з наступного може бути правдою щодо ситуації:

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

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

Врегулювання спорів

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

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

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

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

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

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

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

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

Як канали стану взаємодіють з Ethereum?

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

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

Канали стану покладаються на основний протокол Ethereum для наступного:

1. Живучість

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

2. Безпека

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

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

3. Завершеність

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

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

Віртуальні канали стану

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

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

Ця система покладається на існування так званих «каналів-реєстрів», які були профінансовані в мережі. Віртуальні канали між двома сторонами можуть бути побудовані поверх існуючого каналу-реєстру, при цьому власник(-и) каналу-реєстру виступатиме посередником.

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

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

Віртуальні платіжні канали

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

Застосування каналів стану

Платежі

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

Платежі на основі каналів мають такі переваги:

Пропускна здатність: кількість транзакцій поза мережею на канал не пов’язана з пропускною здатністю Ethereum, на яку впливають різні фактори, особливо розмір блоку та час блоку. Виконуючи транзакції поза мережею, канали блокчейну можуть досягти вищої пропускної здатності.
Конфіденційність: оскільки канали існують поза мережею, деталі взаємодії між учасниками не записуються в публічному блокчейні Ethereum. Користувачам каналу потрібно взаємодіяти в мережі лише під час фінансування та закриття каналів або врегулювання спорів. Таким чином, канали корисні для осіб, які бажають більш приватних транзакцій.
Затримка: транзакції поза мережею, що проводяться між учасниками каналу, можуть бути врегульовані миттєво, якщо обидві сторони співпрацюють, що зменшує затримки. На відміну від цього, надсилання транзакції в основній мережі вимагає очікування, доки вузли оброблять транзакцію, створять новий блок із транзакцією та досягнуть консенсусу. Користувачам також може знадобитися дочекатися більшої кількості підтверджень блоку, перш ніж вважати транзакцію завершеною.
Вартість: канали стану особливо корисні в ситуаціях, коли набір учасників буде обмінюватися багатьма оновленнями стану протягом тривалого періоду. Єдині витрати — це відкриття та закриття смартконтракту каналу стану; кожна зміна стану між відкриттям і закриттям каналу буде дешевшою за попередню, оскільки вартість розрахунків розподіляється відповідно.

Впровадження каналів стану в рішеннях шару 2, як-от зведення, може зробити їх ще привабливішими для платежів. Хоча канали пропонують дешеві платежі, витрати на налаштування контракту в мережі на Mainnet на етапі відкриття можуть стати значними — особливо коли різко зростають комісії за газ. Зведенняopens in a new tab на основі Ethereum пропонують нижчі комісії за транзакції та можуть зменшити накладні витрати для учасників каналу, знизивши комісію за налаштування.

Мікротранзакції

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

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

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

Децентралізовані програми

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

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

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

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

Інші можливі варіанти використання програм каналів стану включають володіння іменами ENS, реєстри NFT та багато іншого.

Атомарні перекази

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

Маршрутизовані платежі, які зазвичай називають «багатострибковими переказами», є атомарними (тобто або всі частини транзакції проходять успішно, або вона повністю зазнає невдачі). Атомарні перекази використовують контракти з тимчасовим блокуванням із хешуванням (HTLC)opens in a new tab для забезпечення того, щоб платіж було здійснено лише за дотримання певних умов, тим самим зменшуючи ризик контрагента.

Недоліки використання каналів стану

Припущення щодо живучості

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

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

Деякі канали використовують «сторожові вежі» — суб’єкти, відповідальні за спостереження за подіями суперечок у мережі від імені інших і вжиття необхідних заходів, як-от сповіщення зацікавлених сторін. Однак це може збільшити витрати на використання каналу стану.

Недоступність даних

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

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

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

Проблеми з ліквідністю

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

Однак канали-реєстри, керовані постачальником послуг поза мережею (OSP), можуть зменшити проблеми з ліквідністю для користувачів. Два учасники, підключені до каналу-реєстру, можуть створити віртуальний канал, який вони можуть відкривати та фіналізувати повністю поза мережею, коли захочуть.

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

Атаки скорботи (griefing attacks)

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

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

Заздалегідь визначені набори учасників

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

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

Паралельна обробка транзакцій

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

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

Використовуйте канали стану

Кілька проектів надають реалізацію державних каналів, які ви можете інтегрувати у свої додатки:

Для подальшого читання

Базові канали

Огляд рішень для масштабування шару 2 в Ethereum: канали стану, Plasma та Truebitopens in a new tab — Джош Старк, 12 лютого 2018 року
Канали стану — поясненняopens in a new tab 6 листопада 2015 року — Джефф Коулман
Основи каналів стануopens in a new tab District0x
Канали стану блокчейну: сучасний станopens in a new tab

Знайшли ресурс, який допоміг з цією темою? Відредагуйте цю сторінку і додайте його!