Cosmos: Еволюція IBC
Основні пункти
- До цього IBC в основному використовувався для переказів токенів; тепер він розвивається, поширюючись на нові варіанти використання, такі як Interchain Security і Interchain Accounts
- Interchain Security (міжчейнова безпека) — це рішення для усунення вузьких місць початкового завантаження Cosmos, що дозволяє Cosmos Hub масштабувати нові функції
- Interchain Accounts (міжчейнові облікові записи) дозволяють мережам відкривати та контролювати облікові записи в інших мережах, значно збільшуючи масштаб і складність взаємодії між мережами
Міжчейнова безпека: вирішення вузького місця завантаження
Міжчейнова безпека (Interchain Security) — це версія спільної безпеки від Cosmos, але є деякі важливі відмінності від того, що ми зазвичай думаємо, коли говоримо про спільну безпеку. На платформі смарт-контрактів, як-от Solana або Ethereum, спільна безпека означає, що програми розгортаються як смарт-контракти з єдиним станом. Найбільшою перевагою тут є те, що програмам не потрібно турбуватися про завантаження набору валідаторів, вузьке місце в Cosmos.
Міжчейнова безпека — це рішення Cosmos для вирішення проблеми завантаження безпеки. Замість того, щоб запускати звичайну мережу Cosmos із власним набором валідаторів, проекти можуть орендувати валідатори іншої мережі. Цей чейн називається “чейн провайдерів”, оскільки він забезпечує безпеку чейну, який його споживає, “чейну споживачів”.
Тут важливо зазначити, що компроміс між платформами міжчейнової безпеки і смарт-контрактами відрізняється. Dapps на платформах смарт-контрактів зазвичай мають один і той самий ринок комісій, оскільки всі вони спільно використовують обмежений блоковий простір. У рішенні безпеки між чейнами валідатори чейнів постачальників збільшують свої ресурси для перевірки нових чейнів споживачів. Незважаючи на те, що це дозволяє мережам споживачів зберігати незалежні ринки комісій, це все-таки встановлює суворіші вимоги до валідаторів мережі провайдерів.
Хоча теоретично чейни споживачів не мають верхньої межі для масштабування, на практиці валідатори потребують набагато більше роботи, тому їм може знадобитися інвестувати в більше комп’ютерів, щоб запускати всі ці чейни паралельно. В обмін на цю послугу споживчі мережі надсилатимуть частину плати за газ та інфляцію токенів до валідаторів мережі постачальників.
Одним із ризиків для чейну провайдерів є централізація валідаторів: якщо перевірка всіх чейнів споживачів стане непомірно дорогою, більші оператори почнуть складати більшу загальну частку, а менші відпадуть. Це також може бути перешкодою для чейнів споживачів, які не генерують достатнього доходу від плати за газ, і, можливо, доведеться компенсувати це вищою інфляцією токенів, щоб перевірка того вартувала.
У версії 1 будь-який чейн споживачів, який приймається керівництвом, має бути захищений усіма валідаторами чейна постачальників. У версії 2 (без часової шкали) окремі валідатори зможуть погоджуватися/відключатися, а також валідатори за межами чейну постачальників також можуть погоджуватися.
Розрізняють два види чейнів споживачів: контрактні та кастомні.
- Контрактний чейн споживачів: ці чейни працюють із ізольованим середовищем смарт-контрактів (наприклад, CosmWasm або EVM). Хоча валідаторам чейну постачальників їх набагато легше оцінити як кандидатів, вони втрачають певну гнучкість. Мережі споживачів використовують токен чейну постачальника (наприклад, ATOM) як газ. 25% комісії надходить до мережі постачальників, а решта (~75%) йде до DAO розробника, який керується власним токеном мережі споживачів.
- Кастомний чейн споживачів: повністю настроюваний чейн, розроблений за допомогою Cosmos SDK. Токен газу може бути власним токеном чейну, і чейн має повний настроюваний бінарний файл, що дозволяє розробникам вирішувати такі речі, як вимірювання газу та те, як транзакції збираються в блоки. З точки зору валідаторів чейнів постачальників, ці чейни є більш ризикованими для борту, оскільки з необмеженими можливостями існують необмежені атаки (як будь-який автономний чейн додатків Cosmos). Валідатори можуть ізолювати ризики цих чейнів, перевіряючи їх на окремому комп’ютері (більше горизонтального масштабування!). Ці чейни виглядають як стандартний чейн додатків Cosmos, не потребуючи власних валідаторів.
Якщо розглядати dYdX, то вони починали як чейн додатків Ethereum L2 і тепер переходять до Cosmos. Однак, оскільки вони були повністю побудовані в Cairo з переходом до іншої екосистеми, їх перехід до Cosmos займе додатковий час на розробку. Якби мережі споживачів були активними, коли dYdX починався, і вони запускалися як одне ціле, процес переходу до власної мережі Cosmos був би набагато простішим. Щоб перейти від чейну споживачів до автономного, їм потрібно лише отримати власних валідаторів. Все інше було б уже побудовано. Чейни споживачів можна розглядати як спосіб для додатків, які хочуть бути власними чейнами, щоб зробити це за власної зручності, чекаючи, поки у них буде PMF (і більша ринкова капіталізація), щоб здійснити перехід.
Міжчейнова безпека — це великий крок для Cosmos, але це не просто спосіб завантаження нових чейнів. Це спосіб масштабувати функції для Cosmos Hub, щоб нарешті приділити йому необхідну увагу.
Міжчейнові облікові записи: компонування в Cosmos
Додатки, будучи автономними чейнами, допомагають упоратися з перевантаженістю та масштабованістю, але є компроміс, і це синхронна комбінованість: взаємодія між двома або більше різними програмами, які відбуваються в одному блоці. Смарт-контракти в одному чейні матимуть можливість синхронного компонування, і це необхідно для певних дій, як-от флеш-позики, оскільки позика має бути погашена в межах одного блоку. Але скільки програм насправді потребують синхронного компонування? dYdX і його виконавці добре працюють самі по собі, а асинхронне компонування Cosmos буде працювати досить добре для багатьох випадків використання.
Однією з проблем, пов’язаних із IBC у минулому, була обмежена функціональність крос-чейнів. IBC використовує стандарти додатків під час певних взаємодій, таких як передача токенів (ICS-20) і передача NFT (ICS-721), але що робити, якщо немає стандарту для транзакції, що стосується конкретної програми? Скажімо, один чейн хоче здійснити перехресний своп або відкрити кредитну позицію для іншого. Для цього немає ICS. Вам потрібно буде розробити новий стандарт, але розробка ICS потребує багато часу та пов’язана з власними ризиками та не може відповідати конкретним вимогам кожного чейну програм.
Ось тут вступають у гру міжчейнові облікові записи (Interchain Accounts (ICA)). ICA надає чейнам можливість відкривати та контролювати обліковий запис в іншому чейні, дозволяючи їм виконувати будь-яку транзакцію, яка є рідною для цього чейну, без необхідності розробки нового стандарту.
Аналогія, яка часто використовується, полягає в тому, що транзакція Interchain Account — це лист у конверті в боксі.
- Чейн A надсилає бокс до чейну B через IBC
- Модуль IBC у чейні B відкриє бокс та надішле конверт на контрольований обліковий запис чейну A у чейні B
- Interchain Account відкриє конверт, прочитає лист і виконає необхідне завдання чейну B.
Лист, надісланий із чейну A, має той самий формат, що й будь-яка інша транзакція чейну B, таким чином усуваючи потребу в новому ICS і дозволяючи чейну A контролювати облікові записи в чейні B, не виходячи з чейна A. Ця транзакція є не-IBC транзакцією, яка загорнута в транзакцію IBC, значно підвищуючи можливість компонування між чейнами/зонами та дозволяючи набагато більш масштабоване рішення, ніж створення нових стандартів.
Зони можуть бути хостами, контролерами або обома. Хости зберігатимуть облікові записи з інших зон, слухатимуть інструкції IBC, а потім виконуватимуть транзакції. Контролери створюють облікові записи в чейнах хостів і керують/контролюють їх. На малюнку вище чейн A — це зона контролера, а чейн B — зона хоста. Нижче наведено кілька прикладів міжчейнового компонування, яке буде ввімкнене за допомогою міжчейнових облікових записів:
- Мульти-чейн DAO: DAO можуть керувати всіма своїми активами з одного чейну, але брати участь у діяльності в інших екосистем, як-от нативний стекінг, забезпечення ліквідності за допомогою казначейських активів, запуск NFT тощо.
- CDP: користувачі можуть брати позику в одному блокчейні, використовуючи заставу в іншому.
- Управління крос-чейном: платформа ліквідних ставок Quicksilver використовуватиме міжчейнові облікові записи, щоб дозволити користувачам, які тримають qAssets (токени ліквідних ставок), голосувати в мережах, де користувачі розмістили активи. Користувачі зазвичай відмовляються від прав голосу з ліквідними токенами, але IA можуть їх зберегти.
- Сховища DeFi: у пізнішій версії Sommelier, яку буде запущено на Osmosis, використовуючи IA для надсилання стратегій, обчислених поза мережею, до облікового запису на Osmosis.
- Обміни токенів: обмін активами в різних зонах за допомогою Osmosis у фоновому режимі.
Дійсно, усе, що ми робимо в DeFi сьогодні, окрім деяких взаємодій, які потребують синхронного компонування, може бути досягнуто. Міжчейнові облікові записи також забезпечують більш зручну роботу кінцевого користувача; користувачам не потрібно залишати чейн, щоб виконувати дії на інших. Це створює кращий UX і пом’якшує потенційні операційні ризики та ризики безпеки, як-от перенесення активів між мережами вручну, керування різними гаманцями для різних мереж тощо.
Interchain Accounts і Interchain Security є двома найбільшими каталізаторами в екосистемі Cosmos на сьогоднішній день, і можливість компонування в Cosmos ледве подряпала поверхню. Ми торкнулися Cosmos Hub, але в екосистемі є й інші потенційні хаби, які, ймовірно, приймуть один або обидва ці примітиви.