Оригінальний автор: Архів улюблених читань Mirror

Оригінальний збірник: Shenchao TechFlow

Резюме ключових моментів

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

• У цій статті представлено структуру ключових елементів абстракції ланцюга (CAKE). Фреймворк складається з чотирьох частин: рівня додатків, рівня дозволів, рівня розв’язувача та рівня розрахунків, які мають на меті надати користувачам безперебійну роботу між ланцюжками.

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

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

• Щоб успішно зробити стрибок до майбутнього прикутої абстракції, ми як індустрія повинні визначити та прийняти загальний стандарт для передачі інформації між шарами CAKE. Хороший стандарт – це вишенька на торті.

вступ

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

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

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

Представляємо структуру CAKE

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

• Рівень дозволів: користувачі підключають свої гаманці до dApps і запитують котирування для намірів користувача. Намір означає результат, який користувач очікує отримати в кінці транзакції, а не шлях транзакції. Наприклад, переведіть USDT на адресу Tron або внесіть USDC у стратегію отримання прибутку на Arbitrum. Гаманець повинен мати можливість читати активи користувача (тобто стан читання) і виконувати транзакції в цільовому ланцюжку (тобто стан оновлення).

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

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

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

ключові дизайнерські рішення

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

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

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

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

• Гаманець EOA — це програмне забезпечення гаманця, яке працює на комп’ютері користувача та містить його закритий ключ. Це можуть бути розширення на основі браузера, як-от Metamask і Phantom, мобільні програми, як-от Coinbase Wallet, або спеціалізоване обладнання, як-от Ledger. Гаманці EOA вимагають, щоб користувачі підписували кожну суб-транзакцію окремо, що наразі вимагає кількох кліків. Вони також вимагають від користувачів зберігати баланси комісії в цільовому ланцюжку, що створює значне тертя в процесі. Однак, дозволяючи користувачам підписувати кілька суб-транзакцій одним клацанням миші, користувач може відволіктися від численних клацань.

• У гаманці Account Abstraction (AA) користувачі все ще мають доступ до своїх закритих ключів, але вони відокремлюють підписувача корисного навантаження транзакції від виконавця транзакції. Дозволяє складним сторонам групувати та виконувати транзакції користувачів атомарно (Avocado, Pimlico). Гаманці AA все ще вимагають від користувачів підписувати кожну суб-транзакцію окремо (наразі за допомогою кількох клацань), але не вимагають утримання комісії в кожному ланцюжку.

• Агенти на основі політики зберігають закритий ключ користувача в окремому середовищі виконання та генерують підписані повідомлення від імені користувача на основі політики користувача. Telegram Bot, Near Account Aggregator або SUAVE TEE — це гаманці на основі стратегії, а Entropy або Capsule — це розширення гаманця на основі стратегії. Користувачам потрібно лише підписати форму схвалення, а подальше підписання субтранзакцій і управління витратами можуть бути завершені цими агентами під час операції.

шар вирішувача

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

Наміри складаються з двох типів витягуваних значень (EV): EV_ordering values ​​і EV_signal.

• EV_ordering — це специфічне для блокчейну значення, яке зазвичай витягується об’єктом, який виконує замовлення користувача (наприклад, конструктори блоків або валідатори).

• EV_signal представляє значення, яке доступне для будь-якої організації, яка виконує наказ, до того, як воно буде офіційно зареєстровано в блокчейні.

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

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

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

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

• Загальнодоступний Mempool: наміри користувача транслюються публічно до загальнодоступного mempool або рівня доступності даних, і перший розв’язувач, який може задовольнити запит, виконує замовлення та стає переможцем. Ця система дуже витягує інформацію користувача, оскільки користувачі розкривають свій EV_ordering і EV_signal. Наприклад, публічний mempool Ethereum і різні блокчейн-мости. У випадку з мостом користувачі повинні розмістити активи на депонуванні перед тим, як передати їх у цільовий ланцюг, щоб запобігти зловмисним атакам, але цей процес випадково робить їхні наміри публічними.

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

• Приватні мемпули: Останні розробки в MPC і TEE роблять можливими повністю приватні мемпули. Жодна інформація не витікає за межі середовища виконання, а розв’язувачі кодують свої уподобання та відповідають кожному наміру. Хоча приватний mempool фіксує EV_ordering, він не може повністю фіксувати EV_signal. Наприклад, якщо зламана транзакція надсилається до mempool, перша особа, яка побачить порядок, може випередити транзакцію та захопити EV_signal. У приватному mempool інформація оприлюднюється лише після підтвердження блокування, тому кожен, хто бачить транзакцію, може зафіксувати EV_signal. Цілком можливо, що розв’язувач встановить вузли автентифікації для захоплення EV_signal із нововиготовлених блоків TEE, перетворюючи захоплення EV_signal на відкладене змагання.

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

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

• Відкритий доступ: найнижчий можливий бар’єр для входу для можливості участі. Це схоже на розкриття mempool, який витікає EV_signal і EV_ordering.

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

• Ексклюзивний доступ: ексклюзивний доступ — це спеціальний формат аукціону, де за період часу обирається лише один розв’язувач. Оскільки інформація не просочується іншим розв’язувачам, немає несприятливого відбору та ранніх знижок. Ініціатор потоку ордерів фіксує очікувані значення EV_signal і EV_ordering, і оскільки конкуренції немає, користувачі отримують лише виконання, але не підвищення ціни. Прикладами таких аукціонів є аукціони Robinhood і DFlow.

розрахунковий шар

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

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

Міжланцюговий оракул

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

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

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

• Непротокольні оракули: мають бути відокремлені від сторонніх валідаторів, які керують консенсусом для передачі інформації між ланцюжками. Додаткові валідатори збільшують вартість роботи оракула. LayerZero, Wormhole, ChainLink і Axelar Networks є прикладами позапротокольних оракулів.

• Оракули в протоколі: глибоко інтегровані в алгоритм консенсусу екосистеми та передають інформацію за допомогою набору валідаторів, які запускають консенсус. IBC Cosmos використовується для ланцюгів, які працюють із Cosmos SDK, екосистема Polygon розробляє AggLayer, а Optimism розробляє Superchain. Кожен оракул використовує виділений блоковий простір для передачі інформації між ланцюжками в одній екосистемі.

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

перехідний токен

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

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

Існує два типи перехресних ланцюгових мостів:

• Міст Lock and Mint Bridge: Міст Lock and Mint Bridge перевіряє депозити жетонів у вихідному ланцюжку та карбує жетони в цільовому ланцюжку. Капітал, необхідний для запуску такого мосту, невеликий, але безпечна передача заблокованої інформації вимагає значних інвестицій. Порушення безпеки на цих мостах призвели до мільярдів доларів збитків для власників токенів.

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

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

Перехресна ланцюгова трилема

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

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

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

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

Шість складових ТОРТА

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

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

Жетон позначений міст

Існує особливий випадок lock-and-mint bridges, які не оплачують витрати ліквідності, також відомий як burn-and-mint bridges (наприклад, USDC CCTP). Команда токенів призначає канонічну адресу токена для кожного ланцюга, а міст має повноваження карбувати токени, які потрібні користувачеві.

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

Екосистемний координаційний міст

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

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

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

Цінова конкуренція Solver

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

Повідомлення звірки гаманця

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

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

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

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

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

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

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

на закінчення

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

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

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

Оригінальне посилання