TL; Доктор

• Криптовалютний UX за замовчуванням сьогодні призначений для того, щоб користувачі завжди знали, з якою мережею вони взаємодіють. Однак користувачам Інтернету не обов'язково знати, з яким хмарним провайдером вони взаємодіють. Впровадження цього підходу до блокчейнів – це те, що ми називаємо абстракцією ланцюга.
• У цій статті представлено фреймворк CAKE, тобто ключові елементи ланцюгової абстракції. Він складається з чотирьох рівнів: «Програми», «Дозволи», «Рішення» та «Розрахунок», які разом полегшують безперебійні операції крос-ланцюг для користувачів.
• Досягнення ланцюгової абстракції вимагає використання складного набору технологій для забезпечення надійного, економічно ефективного, безпечного, швидкого та приватного виконання.
• Ми визначаємо крос-ланцюг компромісний простір у ланцюговій абстракції як трилему та пропонуємо шість дизайнів, кожен з яких пропонує унікальні переваги.
• Для ордер того, щоб успішно зробити стрибок у майбутнє ланцюгової абстракції, нам, як галузі, вкрай важливо визначити та прийняти загальний стандарт обміну повідомленнями між шарами CAKE. Відмінним еталоном є вишенька на торті. 🎂

Вступ

У 2020 році мережа Ethereum перейшла на дорожню карту масштабування, орієнтовану на rollup. Через чотири роки після цього рішення понад 50 роллапи (L2) вже запущені у виробництво. Незважаючи на те, що роллапи забезпечують таке необхідне горизонтальне масштабування для EVM блокового простору, воно повністю зіпсувало користувацький досвід.

Користувачі не повинні ні перейматися, ні знати, з яким ролапом вони взаємодіють. Крипто користувачі знають, з яким зведенням (Optimism або Base) вони взаємодіють, еквівалентно тому, що користувачі web2 знають, з яким хмарним провайдером (AWS або GCP) вони взаємодіють. Ланцюгова абстракція – це бачення, де інформація про ланцюжок абстрагується від користувача. Користувач лише підключає свій гаманець до dApp і підписує передбачувану операцію, деталі забезпечення правильного балансу користувача в цільовому ланцюжку, а потім виконання передбачуваної операції відбувається за лаштунками.

Протягом цієї статті ми побачимо, що ланцюгова абстракція є справді міждисциплінарною проблемою. Включає взаємодію з Рівень застосування, шаром дозволів, рівнем розв'язувача та шаром Розрахунок. Ми представляємо фреймворк Chain Abstraction Key Elements (CAKE 🎂), а потім глибше заглиблюємося в компроміси дизайну систем ланцюгової абстракції.

Знайомство з фреймворком CAKE

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

1. Рівень дозволів: користувач підключає свій гаманець до dApp і запитує цінову пропозицію для наміру користувача. Намір - це те, що користувач очікує (тобто результат) в кінці транзакції, а не кінцевий шлях, який проходить транзакція. Це може бути переказ USDT на адресу Tron або внесення USDC в стратегію отримання прибутку на Arbitrum. Гаманець повинен бути в змозі як знати активи користувачів (тобто стан зчитування), так і виконувати транзакції (тобто стан оновлення) у цільових ланцюжках.
2. Рівень розв'язувача: рівень розв'язувача оцінює комісію та швидкість виконання на основі початкового балансу та намірів користувача. Цей процес, званий розв'язанням, має вирішальне значення в умовах крос-ланцюг, коли транзакції стають асинхронними, а субтранзакції можуть зазнати невдачі під час виконання. Впровадження асинхронності створює трилему крос-ланцюг, пов'язану з комісіями, швидкістю виконання та гарантією виконання.
3. Розрахунок рівень: Після того, як користувач схвалює транзакцію за допомогою свого приватного ключа, розрахунковий шар забезпечує її виконання. Він включає два етапи: об'єднання активів користувача в цільовий ланцюг, а потім виконання транзакції. Якщо протокол використовує складні розв'язувачі для певних операцій, вони можуть привнести власну ліквідність і виконати операцію від імені користувача без необхідності мосту.

Досягнення Chain Abstraction означає об'єднання трьох вищевказаних рівнів інфраструктури в єдиний продукт. Ключовим висновком при об'єднанні цих шарів є різниця між передачею інформації та передачею цінності. Передача інформації між ланцюжками повинна бути без втрат і, таким чином, вимагає залежності від найбільш безпечних шляхів. Припустимо, що користувач намагається проголосувати «Так» під час голосування за управління від одного ланцюга до іншого, він не хоче, щоб його голос перетворився на голос «Можливо». З іншого боку, передача цінності може бути з втратами залежно від уподобань користувачів. Досвідчена третя сторона може бути використана, щоб надати користувачеві швидшу, дешевшу або гарантовану передачу вартості. Зверніть увагу, що 95% блокового простору ethereum (зваженого на комісію, сплачену валідатори) витрачається на передачу вартості.

Ключові проектні рішення

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

Рівень дозволів

Рівень дозволів містить закритий ключ користувача та підписує повідомлення від його імені, які потім виконуються у блокчейні як транзакції. CAF повинен підтримка схеми підписання та корисне навантаження транзакцій для всіх цільових ланцюгів, які він хоче підтримка. Наприклад, гаманець, що підтримує схему підпису ECDSA та EVM стандарт транзакцій, буде обмежений Ethereum, його L2s та сайдчейнами (наприклад, гаманцем Metamask). З іншого боку, гаманець, що підтримує як EVM, так і SVM (Solana VM), зможе підтримка обидві екосистеми (наприклад, гаманець Phantom). Важливо зазначити, що одна й та сама мнемоніка може бути використана для генерації гаманців як у EVM, так і в ланцюжках SVM.

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

1. Гаманці EOA — це програмне забезпечення гаманця, яке працює на комп'ютерах користувачів і зберігає їхні приватні ключі. Це можуть бути розширення на основі браузера (наприклад, Metamask і Phantom), мобільні додатки (наприклад, Coinbase Гаманець) або спеціальне обладнання (наприклад, Ledger). Гаманці EOA вимагають, щоб користувач окремо підписував кожну субтранзакцію, що наразі вимагає кількох кліків. Вони також вимагають, щоб користувач утримував залишки комісій у цільовому ланцюжку, що вносить значні тертя в процес. Однак тертя, пов'язане з кількома кліками, можна абстрагувати від користувача, дозволяючи йому підписувати кілька підтранзакцій одним клацанням миші.
2. У гаманцях Account Abstraction (AA) користувач все ще має доступ до свого приватного ключа, але вони відокремлюють підписувача корисного навантаження транзакції від виконавця транзакції. Надання можливості складним сторонам атомарно об'єднувати та виконувати транзакції користувачів (Avocado, Pimlico). Гаманці AA, як і раніше, вимагають, щоб користувач окремо підписував кожну субтранзакцію (наразі за допомогою кількох кліків), але не вимагають зберігання залишків комісій у кожному ланцюжку.
3. Агенти на основі політик зберігають закритий ключ користувача в окремому середовищі виконання та генерують підписані повідомлення від його імені на основі політик користувача. Боти Telegram, агрегатор Near Account або SUAVE TEE — це гаманці, засновані на правилах, тоді як Entropy або Capsule — це розширення гаманців на основі політики. Користувачеві просто потрібно підписати єдине схвалення, і подальше підписання субтранзакцій та управління комісією може здійснюватися цими агентами під час польоту.

Рівень розв'язувача

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

Намір складається з двох типів значень, які можна витягти (EV): EV_ordering і EV_signal. EV_ordering — це значення, специфічне для блокчейну, яке зазвичай видобувається сутностями, які виконують ордери користувачів, такими як конструктори блоків або валідатори. З іншого боку, EV_signal являє собою цінність, доступну будь-якій організації, яка спостерігає за ордер до того, як вона буде офіційно зафіксована в блокчейні.

Різні наміри користувачів мають різний розподіл між EV_ordering і EV_signal. Наприклад, намір обміняти монети на DEX зазвичай має високу EV_ordering, але низьку EV_signal. І навпаки, вхідна хакерська транзакція матиме вищий компонент EV_signal, оскільки вона поверне значно більше цінності, ніж її виконання. Важливо зазначити, що іноді EV_signal може бути негативним, наприклад, у випадку угод від маркет-мейкерів, коли суб'єкти, які виконують ці ордери, можуть зазнати збитків через краще розуміння маркет-мейкером майбутніх ринкових умов.

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

Обмін інформацією

Існує 3 методи обміну інформацією за допомогою розв'язувачів:

1. Публічний пул пам'яті: намір користувача транслюється публічно, або на загальнодоступний пул пам'яті, або на рівень DA. Перший розв'язувач, який зможе виконати запит, виконує ордер і стає переможцем. Ця система є дуже екстрактивною, оскільки користувачі розкривають як EV_ordering, так і EV_signal зі свого ордер. Прикладами цього типу аукціону є публічний пул пам'яті Ethereum та різні блокчейн-мости. У випадку мостів користувачі повинні розміщувати свої активи на умовному депонуванні, перш ніж передавати їх у цільовий ланцюжок як запобіжний захід від атак горя. Однак цей процес ненавмисно публічно викриває їхні наміри.
2. Часткове спільне використання: CAF може обмежити обсяг цінності, яку він розкриває учасникам торгів, обмеживши інформацію, що розкривається. Однак такий підхід призводить до прямої втрати оптимальності ціни та може призвести до інших проблем, таких як розсилка спаму ставками.
3. Приватні пул пам'яті: Нещодавні розробки в MPC та TEE відкривають можливість для створення повністю приватних мемпулів. Жодна інформація не просочується за межі середовища виконання, тому розв'язувачі кодують свої параметри, які зіставляються з кожним наміром. Незважаючи на те, що приватний пул пам'яті фіксує EV_ordering, він не може повністю передати цінність у EV_signal. Уявіть, що станеться, якщо на пул пам'яті буде відправлена хакерська транзакція. Перший, хто побачить цю ордер, може випередити потенційний продаж і захопити EV_signal. У приватному пул пам'яті інформація оприлюднюється лише після підтвердження блоку, а отже, той, хто бачить транзакцію, може захопити EV_signal. Можна уявити, як розв'язувачі обертаються атестація вузлах, щоб зловити EV_signal зі свіжих блоків, викарбуваних TEE, перетворюючи EV_signal захоплення на затримка перегони.

Список розв'язувачів

Крім того, CAF має вирішити, скільки учасників і яким учасникам дозволено брати участь в аукціоні. Загалом, варіанти такі:

• Відкритий доступ: Бар'єри для входу для можливості участі є якомога нижчими. Це схоже на публічний пул пам'яті і витоки як EV_signal, так і EV_ordering.
• Закритий доступ: Існує певний контроль за можливістю виконання ордер через білий список, систему репутації, комісію або аукціон місць. Механізм шлюзування повинен гарантувати, що розв'язувачі в системі не захоплюють EV_signal. Прикладами є аукціони 1inch Auction, Cowswap Auctions та аукціони Uniswap X. Конкуренція за виграш ордерів захоплює EV_ordering для користувача, тоді як механізм літінгу може захоплювати EV_signal для генератора ордер (Гаманець, dApps).
• Ексклюзивний доступ: Ексклюзивний доступ є окремим випадком аукціону сидячих розв'язувачів, де кожного періоду часу обирається лише один розв'язувач. Оскільки жодна інформація не просочується до інших розв'язувачів, немає несприятливого вибору та попередньої знижки. Оригінатор ордерфлоу фіксує очікуване значення EV_signal та EV_ordering, оскільки немає конкуренції, користувач може отримати лише виконання та підвищення ціни. Прикладами таких аукціонів є аукціони Robinhood і DFlow.

Розрахунок Рівень

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

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

Cross-Chain Oracle

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

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

Існує два типи оракулів:

1. Позапротокольний Oracle вимагає, щоб сторонні валідатори були відокремлені від тих, що працюють на консенсусі, для передачі інформації між ланцюгами. Потреба в додаткових валідатори збільшує вартість експлуатації Оракула. LayerZero, Wormhole, ChainLink і Axelar network є прикладами позапротокольних оракулів.
2. Внутрішньопротокольний оракул глибоко інтегрований в алгоритм консенсусу екосистеми та використовує набір валідаторів, що запускає консенсус, для передачі інформації. Cosmos має IBC для ланцюгів, що працюють на Cosmos SDK, екосистема Polygon працює над AggLayer, а Optimism працює над Superchain. Кожен оракул використовує виділений блоковий простір для передачі інформації між ланцюжками однієї екосистеми.
3. Спільні секвенсери — це сутності, що не входять до протокол, які мають права на замовлення транзакцій у протокол, тобто вони можуть забезпечувати об'єднання транзакцій у ланцюжках. Незважаючи на те, що секвенсери все ще знаходяться в розробці, їм не потрібно чекати певних підтверджень блоків, щоб знизити ризик реорганізації. Щоб по-справжньому забезпечити крос-ланцюг атомарність, секвенсери повинні вміти виконувати наступні транзакції, обумовлені успіхом попередніх транзакцій, перетворюючи їх в ланцюжок ланцюгів.

Мостові токени

У багатоланцюговому світі баланси токенів користувачів і комісій розподілені по всіх мережах. Перед кожною крос-ланцюг операцією користувачеві необхідно міст кошти з вихідного ланцюжка в цільовий. Наразі існує 34 активних мостів із загальною TVL $7,7 млрд та мостом об'єм $8,6 млрд за останні 30 днів.

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

Існує 2 види мостів:

1. Lock and Mint міст: Lock and мінт міст перевіряє депозити токенів у ланцюжку походження та карбує токени в цільовому ланцюжку. Хоча для запуску такого міст потрібен невеликий капітал, для безпечної передачі інформації про блокування між ланцюгами необхідні значні інвестиції. Порушення безпеки в цих мостах призвели до втрати мільярдів доларів для власників токенів.
2. Ліквідність мости: Ліквідність мости використовують пули ліквідності в початкових і цільових ланцюжках, а також алгоритм для визначення курсів конвертації між вихідними та цільовими токенами. Хоча ці мости мають вищу початкову вартість, вони вимагають нижчих гарантій безпеки. У разі порушення безпеки під загрозою опиняються лише кошти в пулах ліквідності.

В обох типах мостів є вартість ліквідності, яку повинен сплатити користувач. У мостах Lock and Mint вартість ліквідності відбувається під час свопу з загорнутий токен на бажаний токен (USDC.e до USDC) у цільовому ланцюжку, тоді як у Ліквідність мостах вартість ліквідності відбувається під час обміну з токена у ланцюжку походження на токен у цільовому ланцюжку.

Трилема крос-ланцюга

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

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

The Six Pieces Of CAKE

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

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

Токен Помазані мости

Екосистема узгоджена міст

Цінова конкуренція розв'язувачів

Гаманець контрольований обмін повідомленнями

Змагання швидкості розв'язувача

Ексклюзивні пакетні аукціони

мета

Дешеві кросчейн-перекази

Міжланцюговий дзвінок повідомлень

Дешеві кросчейн-свопи

Міжланцюговий дзвінок повідомлень

Швидкі крос-чейн перекази

Міжланцюговий дзвінок повідомлень

Приклади

CCTP, CCIP, xERC20

AggLayer, Superchain, IBC

Тарзанка, Джемпер, Uniswap X

Альфред, Авокадо, Ближній рахунок

Поперек, орбітальний апарат

Н.А.

гаманець

Будь-який

Будь-який

Залежить від реалізації

АА або на основі політики

Будь-який

Будь-який

Інформація, що передається

громадський

громадський

Залежить від реалізації

Залежить від реалізації

Все або нічого

Ніхто

Розв'язувач список

Залежить від реалізації

Залежить від реалізації

Закритий доступ

Залежить від реалізації

Залежить від реалізації

монопольний

Оракул

У протокол

У протокол

Поза протокол

Поза протокол

Поза протокол

Поза протокол

Токен Мости

Опік і мінт

Замок і мінт

Залежить від розв'язувача

Залежить від розв'язувача

Ліквідність міст

Залежить від реалізації

Токен Помазані мости

Існує особливий випадок блокування та мінт міст, який не оплачує вартість ліквідності, також звану спалюванням та мінт міст (напр. USDC ЦКТП). Команда токенів помазує канонічну адресу токена в кожному ланцюжку, в той час як міст має повноваження мінт токен, тобто токен, який потрібен користувачеві.

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

Міст, вирівняний за екосистемою

міст, вирівняний за екосистемою, дозволяє передавати довільні повідомлення між ланцюгами в межах однієї екосистеми. Він підпадає під категорію шляхів у протокол, надаючи пріоритет гарантії виконання та низьким комісіям над швидкістю. Приклади включають Cosmos IBC, Polygon AggLayer і Optimism Superchain.

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

Екосистема космосу складається з незалежних ланцюгів, що мають суверенну безпеку та швидку остаточність, що робить шлях крос-ланцюг обміну повідомленнями в протокол дуже швидким. З іншого боку, екосистема зведення залежить від закінчення періоду челенджу (Optimistic Rollups) або фіксації zk-proofs (Validity Rollups) для остаточності. Шляхи протокол для передачі повідомлень через екосистеми будуть повільними через ці обмеження остаточності.

Цінова конкуренція розв'язувачів

Цінова конкуренція розв'язувачів передбачає обмін ордер інформацією з усіма розв'язувачами. Розв'язувачі мають на меті включити очікуване значення (EV), згенероване наміром ордер, і надати його користувачам. Вибір виграшного розв'язувача в системі ґрунтується на максимальному підвищенні ціни користувача. Однак така конструкція несе в собі ризик невиконання і вимагає додаткових механізмів для забезпечення надійного включення замовлень. Прикладами таких механізмів є Uniswap X, Bungee та Jumper.

Гаманець Скоординовані повідомлення

Гаманець скоординований обмін повідомленнями використовує можливості, надані АА або гаманцями на основі правил, щоб запропонувати крос-ланцюг досвід, сумісний із будь-яким типом намірів. Він слугує найкращим агрегатором ЦС, перенаправляючи наміри користувачів між різними дизайнами ЦС для задоволення конкретних намірів. Приклади включають гаманець Avocado, агрегатор акаунтів Near і портфоліо Metamask.

Зазначимо, що за останнє десятиліття криптоекосистема зрозуміла, що відносини між користувачем та його гаманцем дуже складні. Особисто я відчуваю смертельний страх щоразу, коли думаю про перенесення моєї мнемоніки з Metamask на інший гаманець. Це також є причиною того, що навіть через 2,5 роки та за підтримки самого Віталік Бутерін EIP-4337 отримав мінімальне прийняття. Хоча новіші версії протоколів гаманців можуть надати користувачеві кращу ціну (абстрагування рахунку) або покращену простоту використання (гаманці на основі політики), перенесення користувача з його поточних гаманців є непростим завданням.

Змагання швидкості розв'язувача Змагання

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

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

Ексклюзивні пакетні аукціони Ексклюзивний пакетний

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

Висновок

Фреймворки ланцюгової абстракції (CAF) обіцяють забезпечити користувачам безперешкодну крос-ланцюг взаємодію. У цій статті ми вивчили дизайни, що знаходяться у виробництві та розробці кількома командами, які явно чи неявно намагаються вирішити проблему для Chain Abstraction. Ми вважаємо, що це буде рік CAF, і очікуємо, що в найближчі 6-12 місяців відбудеться значна конкуренція між різними проектами та їх реалізацією.

Передача вартості

Передача інформації

Шляхи в протокол

Токен помазаних міст

Екосистема узгоджена міст

Агрегація розв'язувачів

Цінова конкуренція розв'язувачів

Гаманець скоординований обмін повідомленнями

Конкурс на виконання

Змагання швидкості розв'язувача

Ексклюзивні пакетні аукціони

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

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

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

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