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

ICS-02 наводить вимоги до побудови легкого клієнта, включаючи те, як IBC управляє даними легкого клієнта. Для роботи IBC потрібні клієнти, які є довільними алгоритмами верифікації для підтвердження інформації on-chain, яка зазвичай кодується в форматі IBC, з одного місця в інше.

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

Підтвердження доказу одностайності

Примітка про алгоритми консенсусу

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

Алгоритми консенсусу зазвичай відрізняються за своїми наборами правил та пріоритетами. Проте гетерогенність двох різних алгоритмів консенсусу може ускладнити комунікацію ланцюгів через IBC. Наприклад, ланцюжки Cosmos використовують алгоритм консенсусу Tendermint, який має однослотову остаточність, відому також як швидка остаточність. З іншого боку, консенсус Ethereum не має однослотової остаточності, тому його остаточність повільніша, оскільки він цінує активність більше, ніж безпеку, тоді як IBC найбільше сумісний з алгоритмами консенсусу, які цінують безпеку. Через цю різницю у тому, коли блоки вважаються 'остаточними', ускладнюється спосіб, яким два ланцюжки можуть надсилати та перевіряти блоки один від одного.

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

Легкі клієнти: Машини станів

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

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

тип клієнта" проти інстанції клієнта"

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

Легкі клієнти: Одноманітні машини

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

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

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

Перевірка Поза Переконаннями Доказів

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

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

ZK-IBC: Обчислення клієнта відбуваються поза ланцюжком та перевіряються на ланцюжку за допомогою ZKPs. Немає мінімальної затримки, а вартість нижча, ніж у випадку наївної перевірки. Однак перевірка ZK може бути дорогим процесом на ланцюжку, і немає максимальної затримки, що означає, що користувач може довго чекати на підтвердження. Також можуть виникнути проблеми з несумісністю, якщо схема підпису не є SNARK-дружньою.

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

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

Безпека та погана поведінка

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

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

Будівництво з легкими клієнтами

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

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

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

Цю статтю спонсорувала Polymer для підтримки освіти спільноти щодо IBC та дійсно децентралізованої взаємодії.

Polymer Labs, що складається з кваліфікованих інженерів розподілених систем та інфраструктури, піонерів криптовалют і досвідчених бізнес-операторів, знаходиться в авангарді розвитку сумісності Ethereum з IBC. Завдяки технічним цінностям, заснованим на TCP/IP, місія Polymer полягає в тому, щоб створити наступне покоління Інтернету, гарантуючи, що рівень сумісності децентралізованої мережі є нейтральним, відкритим, інклюзивним і уніфікованим для всіх екосистем. Як творці Ethereum Interoperability Hub, першого рівня 2, зосередженого на забезпеченні сумісності IBC, Polymer встановлює новий стандарт у технології блокчейн.

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

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