Повестка дня

Проблема

1. Определение конечного состояния: что делает криптовалютные приложения «пригодными для использования»

2. Почему «цепная абстракция» является решением проблемы UX, возникающей из фундаментальной топологии модульных блокчейнов

3. Почему полезные криптовалютные приложения должны быть построены на основе инфраструктуры абстракции цепи

Пространство решений

1. Как архитектура, основанная на намерениях, приведет к абстрагированию цепочки

2. Понимание того, что рынки намерений работают наилучшим образом, когда сеть решателей большая и конкурентоспособная

3. Загрузка сети решателей намерений требует привлечения большего количества приложений, которые будут создавать намерения

Предложение

1. Почему нам нужен стандарт намерений межцепочной связи, который отдает предпочтение «UX решателя», чтобы развить рынок решателей и намерений достаточного масштаба для достижения сетевых эффектов

Пригодные для использования криптографические приложения не могут быть построены без абстракции цепочки

Являются ли наши лучшие и самые яркие здания избыточной инфраструктурой?

Многие жалуются, что лучшие инженеры в сфере криптовалют и наиболее обоснованные мыслители перераспределяют внимание и энергию в направлении предоставления большего блокчейна конечным пользователям. Эта критика имеет право на существование; слишком много L2 доступны для конечных пользователей по сравнению с их спросом.

Тем не менее, я отвергаю утверждение, что в настоящее время не существует никаких полезных криптовалютных приложений.

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

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

1. Скорость: Приложения должны работать так же быстро, как приложения веб-2.
2. Стоимость: В отличие от веб2, все взаимодействия веб3 должны иметь определенную стоимость, но «стоимость за клик» должна быть незначительной.
3. Устойчивость к цензуре («безразрешительность»): Любой, у кого есть кошелек, должен иметь возможность взаимодействовать с приложением, если у него есть возможность нажать.
4. Безопасность: Нажатия должны выполнять то, что от них ожидают пользователи, и не откатываться - все обновления web3 должны быть постоянными.

Это свойства "пригодных" крипто-приложений.

Мы долгое время пытались создать удобную криптовалюту

Сегодняшние модульные решения блокчейн предлагают потребителям все эти свойства, но они не все доступны в одном месте.

В 2020 году блокчейны были монолитными, предлагая два из трех свойств конечным пользователям: скорость, стоимость или безопасность. Мы тогда представили себе а роллап-центрическое или модульное будущеекоторый бы одновременно разблокировал все три свойства.

Сегодня мы создали основу для этой инфраструктуры, сосредоточенной на rollup. L2 предлагают дешевое и быстрое пространство блоков, и большинство из них предлагают открытое пространство блоков. В отличие от этого, L1 предлагает устойчивое к WW3 безопасное пространство блоков. (Вы можете узнать больше о компромиссе между безопасностью и UX, предлагаемом L1 и L2 в моя короткая статья-опрос). Эти L2s подключаются к L1 по защищенным каноническим сообщениям, положив основу для модульной, но взаимосвязанной сети. За последние четыре года мы построили оптоволоконный кабель между блокчейнами, который когда-нибудь поддержит полезные криптоприложения. Но почему модульные блокчейны настолько неиспользуемы?

Неизбежность модульных блокчейн-сетей заключается в том, что капитальные активы будут накапливаться на самых безопасных уровнях, в то время как клики пользователей будут накапливаться на более быстрых и дешевых уровнях.

Модульная топология блокчейна способствует предоставлению безопасного блокчейна на другом уровне, чем дешевый и быстрый блокчейн. Пользователи естественным образом предпочтут хранить свои ценности на самых безопасных сетях, но они будут требовать взаимодействия в основном с дешевыми и быстрыми сетями.По дизайну, канонические пути между L2 и L1 медленные и/или дорогие. Эти явления объясняют, почему пользователи должны проходить через эти канонические пути, чтобы оплатить взаимодействия L2 с использованием активов L1. Это приводит к «неиспользуемому» крипто UX.

Виталик о различных типах L2s

Цель абстракции цепочки - уменьшить трение при передаче стоимости по этим путям внутри протокола от пользователя.Цепные абстракторыпредположим, что пользователи предпочитают указывать свои желаемые конечные состояния для dapps как «намерения», и ответственность за выполнение их намерений лежит на dapp. Пользователям не следует идти на компромисс в отношении безопасного хранения своих активов, чтобы получить доступ к низким комиссиям и низкой задержке.

Следовательно, абстракция цепив значительной степени зависит от того, насколько пользователи могут безопасно, дешево и быстро передавать значение между сетями. Обычный поток пользователей сегодня заключается в том, что пользователь с балансом USDC на «безопасной» цепи, такой как Ethereum, хочет создать NFT или обменять его на новые токены на более новой цепи, такой как Blast или Base. Способ сделать это за наименьшее количество шагов - последовательно выполнить серию транзакций Bridge→Swap→Mint (или Swap→Bridge→Mint).

В этом примере намерение пользователя состоит в использовании своих USDC на безопасной цепи для создания NFT на другой цепи. Пользователь будет удовлетворен, пока он получит NFT и его баланс USDC будет уменьшен в том месте, где он выберет хранение.

Архитектура, основанная на намерениях, - единственный способ построения абстракции цепи

Абстракция цепочки зависит от передачи стоимости между цепочками, но отправка стоимости через канонические пути передачи сообщений либо дорога, либо медленная. «Быстрые мосты» предлагают дешевые и быстрые альтернативы для пользователей, чтобы отправлять стоимость по сетям, но они вводят новые предположения о доверии. Передача сообщений - наиболее интуитивный способ построения быстрого моста, потому что он моделируется по архитектуре TCP/IP; он зависит от протокола моста, действующего как маршрутизатор TCP для соединения двух цепочек.

Диаграмма TCP/IP от ResearchGate

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

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

С этой архитектурой есть несколько фундаментальных проблем:

1. Механизм верификации должен дожидаться полной окончательности перед отправкой сообщения на контракт протокола цепи назначения. Это может занять до семи дней для L2 с оптимистичными периодами окончательности.
2. Одно межцепочное сообщение отправляется за одну транзакцию моста ИЛИ сообщения пакетируются вместе, но пакет можно отправить только после завершения последнего сообщения в пакете.
3. Мост имеет ограниченную способность привлекать внешнюю ликвидность для улучшения цен для пользователя, поскольку он должен быть декларативным относительно пути выполнения намерения пользователя.

Быстрые мосты передачи сообщений будут либо небезопасными, медленными, либо дорогими в зависимости от механизма проверки. Рынки намерений представляют собой альтернативную архитектуру для быстрого моста, которая возникает из ключевого понимания:

Значение обладает свойством фунгибельности, и для получателя не должно иметь значения, каким образом осуществляется передача этого значения, главное, чтобы он получил средства

Может ли мост передать ценность опытному агенту, чтобы увеличить скорость и снизить стоимость? Ликвидность динамична как внутри, так и вне цепи, и улучшение цены может быть достигнуто, если у механизма моста есть гибкость выбора оптимального пути исполнения в момент передачи через мост.

Механизмы намерений позволяют пользователям указывать точные условия или договоренности, в рамках которых может быть выполнена их транзакция передачи стоимости.

Минимально жизнеспособный намерение - это приказ заплатить X токенов с цепи A, чтобы получить Y токенов на цепи B.

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

Протоколы расчетов намерений

Протоколы моста на основе намерений могут быть более точно обозначены как протоколы урегулирования намерений, которые отвечают за то, чтобы решатели не нарушали указанные пользователем условия. Протоколы урегулирования намерений предлагают решателям безопасность, что им будут возмещены затраты и вознаграждены за выполнение намерений пользователя. Для этого протоколы урегулирования намерений должны обратиться к оракулу, чтобы проверить подлинность выполнения намерения. Безопасность оракула может быть обоснована оптимистичным периодом вызова, порогом свидетелей или основана на доказательстве корректности ZK, например.

Протоколы урегулирования намерений предлагают быстрые и дешевые переводы стоимости, потому что отдельные решатели могут взять на себя риск окончательной уверенности и определить оптимальные пути выполнения

Мосты передачи сообщений могут взаимодействовать только с той скоростью, с которой достигается окончательность исходной цепочки. Время завершения составляет семь дней для оптимистичных роллапов и один час для ZK-роллапов сегодня. Несмотря на то, что это время завершения должно иметь тенденцию к снижению после более широкого внедрения технологии легких клиентов ZK и достижений в технологии предварительного подтверждения совместного секвенирования, маловероятно, что время завершения для всех блокчейнов когда-либо будет казаться пользователям «мгновенным», что предполагает постоянную потребность в быстрых решениях для мостов. Невозможно ретранслировать сообщение быстрее, чем период завершения, не принимая на себя риск окончательности, который выходит за рамки моста передачи сообщений, если только мост не захочет добавить в путь ретрансляции дополнительного доверенного агента, который будет поддерживать потери из-за реорганизации цепочки.

Ускорение, предлагаемое архитектурой на основе намерений, возникает потому, что отдельные решатели в гетерогенной сети решателей могут принимать больше риска окончательности, чем это может делать протокол передачи сообщений, и удовлетворять намерение пользователя до полного исчезновения риска переорганизации цепи. Решатели впоследствии будут взимать плату у пользователей за этот риск окончательности, который они принимают в обмен на более быстрые времена заполнения.

Передача выполнения намерений межцепочкового аутсорсинга агенту также в среднем приводит к улучшению цен для пользователей. В мостах на основе намерений решатели, которые фронтят ордера пользователей на желаемой цепи назначения, впоследствии получают вознаграждение от системы после проверки их выполнения. Эти расчеты намерений могут быть объединены для амортизации затрат. Заполнители, в отличие от пользователей, не требуют мгновенного возмещения и будут взимать соответствующие платежи у пользователей за предоставление им капитала. Групповой расчет не уникален для архитектуры на основе намерений, но архитектура более синергетична с групповым расчетом, потому что она отделяет этап возмещения от этапа выполнения намерений.

Большая часть улучшения цены исходит из интуиции, что стоимость является обмениваемой, и поиск лучшего пути в нужный момент обычно превосходит передачу стоимости. (Однако некоторые пути будут невозможны для преодоления по стоимости в нужный момент, например, когда мост USDC через CCTP.)

Мосты передачи сообщений должны закодировать, как они будут передавать значение пользователю. Некоторые выбирают отправку токенов из пула ликвидности по предопределенному обменному курсу, в то время как другие чеканируют представительные токены для получателей, которые затем должны обменять их на желаемый канонический токен-актив.

При выполнении намерения пользователя агент может получать ликвидность из комбинации ликвидности onchain и offchain. Сети конкурентных решателей предлагают пользователям в теории неограниченные источники ликвидности (но даже эти источники ликвидности могут быстро исчерпаться, когда объем движется в одном направлении во время высокой волатильности событий onchain, таких как популярные выпуски NFT, воздушные сбросы и rug pulls).

Подача кросс-цепочечного ордера как намерения позволяет решателям внедрить сгенерированный MEV ордера как улучшение цены.

Архитектура, основанная на намерениях, в основном разработана для обеспечения безопасности

Мосты на основе намерений могут быть построены безопасно, потому что они разделяют срочные требования пользователя от сложных требований сети расчетов. Решатели могут ждать возврата, в отличие от пользователей, и они будут взимать плату с пользователей за время, которое протокол расчетов заставляет их ждать возврата. Поэтому намеренные расчеты могут быть проверены с использованием очень надежных механизмов без строгого временного ограничения. Это предпочтительно с точки зрения безопасности, поскольку проверка выполнения намерения интуитивно сложна.

В качестве примера проверки намерений в производстве, Черезпроверяет и возвращает заполнители пакетами в течение 90-минутного оптимистичного периода вызова. Конечно, сети расчетов должны стремиться возвращать заполнители как можно быстрее, чтобы снизить комиссии конечных пользователей. Улучшением оптимистичного механизма вызова был бы механизм доказательства ZK допустимости, который потребовал бы кодирования логики проверки намерения в цепочку ZK. По моему мнению, неизбежно, что механизмы доказательства допустимости заменят оптимистичные механизмы вызова и позволят сетям расчетов намерений быстрее возвращать пользователей.

Итак, как возникает цепная абстракция из архитектуры, основанной на намерениях?

Помните, что абстракция цепочки требует быстрого и дешевого перекрестного передачи стоимости. Это также не должно требовать от пользователя отправки ончейн-транзакции в сети, где хранятся их активы.

Намерение пользователя не требуется отправлять onchain пользователем, если оно содержит Разрешение2илиEIP3074Подпись. Это верно как для мостов на основе передачи сообщений, так и для мостов на основе намерений. Обе архитектуры могут воспользоваться шаблоном Permit2, чтобы позволить пользователю подписать вне цепи количество токенов, которые они готовы заплатить с кошелька своей исходной цепи.

Маркетплейсы намерений лучше всего поддерживают абстракцию цепочки, потому что они предлагают дешевый и быстрый кросс-цепочечный перевод стоимости. Представьте себе мир, где пользователь мог бы запросить решателя дать им котировку для входа в позицию стейкинга WETH на Arbitrum, используя свои USDC на Optimism в качестве оплаты. Пользователь мог бы отправить это намерение офчейн на аукцион RFQ, где решатели могли бы делать ставки на него. Победивший решатель аукциона затем мог бы получить подписанное намерение пользователя, содержащее разрешение на расходование их USDC на Optimism, желаемое количество WETH для получения на Arbitrum и вызываемые данные, необходимые для депонирования этого WETH в позицию стейкинга на Arbitrum. Затем решатель мог бы отправить эту транзакцию на Optimism (от имени пользователя), чтобы инициировать кросс-цепочечное намерение и забрать USDC с кошелька пользователя на Optimism. Наконец, решатель мог бы заполнить намерение пользователя на Arbitrum, отправив им WETH и передавая вызываемые данные для включения пользователя в ончейн позицию стейкинга.

Построение инфраструктуры абстрагирования цепочки означает, что этот пользовательский поток кажется мгновенным и дешевым, не требуя от них отправки транзакции onchain. Давайте завершим эту статью обсуждением препятствий для более широкого принятия намерений.

Архитектура намерений от Across

Для лучшего опыта использования случая, чтобы материализовывалась абстракция цепи на основе намерения, нам нужна конкурентная сеть решателей

Связь с намерениями зависит от сетевых эффектов решателя, чтобы работать лучше, чем варианты передачи сообщений. Это основной компромисс между намерением и архитектурой передачи сообщений. В реальности не все приложения, производящие намерения, будут нуждаться в доступе к полностью конкурентному набору решателей, и некоторые могут предпочесть направлять свои намерения волигополистические солверные сетиОднако текущее состояние сетей решателей незрелый и не близок к выполнению предположений о живучести сети решателей, от которой зависят рынки намерений.

Мы не хотим мира, в котором каждое доп прикладное программное обеспечение направляет намерения в изолированные сети решателей. Лучший сценарий для пользовательского опыта - это когда множество допов взаимодействуют с одними и теми же пулами решателей, и все допы имеют свободу изменять, каким пулам решателей они направляют свои намерения.

Как мы начинаем работу сети решателей?

Мы должны отдавать приоритет пользовательскому интерфейсу решателя.

Запуск решателя намерений сложен и требует опыта в создании высокопроизводительного программного обеспечения, а также управления риском кросс-цепочечного инвентаря. Естественно, будет ограниченное количество заинтересованных сторон, готовых оплатить стартовые затраты на запуск этого кода. В лучшем случае решатель, написанный для одного dapp, например, решатель UniswapX, может быть повторно использован для решения проблем других dapp, таких как Across и CowSwap.

Нам действительно нужно увеличить агрегированную капитальную эффективность сети решателей для всех приложений на основе намерений. Для этого потребуется решить проблемы, мешающие запуску решателя.

Для этого нам понадобятся dapps, производящие намерения, видимые для любого решателя, и обеспечить доступ к множеству дифференцированных и конкурентоспособных сетей для урегулирования намерений. Это даст уверенность решателям, что они могут выбрать сеть урегулирования, которой доверяют. Конкуренция между сетями урегулирования также снизит затраты для решателей.

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

Выбор расчетной сетью намерений решателем повлияет на его способность предлагать пользователям комиссии и гарантии времени исполнения. Некоторые расчетные сети могут предлагать эксклюзивные периоды для решателей, которые будут поддерживать развитие оффчейн-аукционов, где решатели и пользователи могут вести переговоры и брать на себя обязательства по уплате комиссий за ретрансляцию. (Кроме того, эти аукционы намерений могут предлагать экономически связанные предварительные подтверждения, что еще больше улучшает UX. Чтобы узнать больше о пользовательском потоке с обнаружением намерений с помощью аукционов и предварительных подтверждений, я рекомендую следующее: доклад от Картика из Sorella.)

Некоторые сети расчетов могут предлагать истечение намерения (т. е. возврат значения пользователям после истечения срока выполнения), обеспечение намерения (т. е. сеть расчетов использует собственный балансовый отчет для выполнения намерения пользователя, если ни один решатель этого не делает) или гибкую цепочку погашения (т. е. позволяющую решателю получить погашение на своей выбранной цепочке).

В конечном итоге сети расчетов будут жестоко конкурировать за быструю и дешевую выплату решателям, не compromisant sur la sécurité. В свою очередь, решатели отправят свой ордерфлоу в сети расчетов, которые позволят им предлагать самые дешевые комиссии пользователям, чтобы они могли выиграть ордерфлоу dapp. Конкуренция в сетях расчетов и решателей зависит от того, что все стороны в цепи поставок намерены координировать, чтобы говорить на одном языке, и конкуренция приведет к лучшему UX для перекрестного передачи ценности.

Ясно, что нам нужен стандарт для намерений межцепочечного взаимодействия

Если решатели могут предполагать, что намерения будут иметь общие элементы, то они могут повторно использовать свой код для решения намерений, созданных различными dapp, и впоследствии снизить свои затраты на настройку. Если различные dapp создают намерения, соответствующие одному стандарту, то все они могут направлять свои намерения в одни и те же пулы решателей. Это поможет привлечь следующее поколение dapp, предоставив им возможность непосредственно подключать свои межцепочные намерения к существующему и зрелому пулу решателей. Новые dapp не будут должны индивидуально привлекать решателей и, вместо этого, получат доступ к дешевым, быстрым, безопасным и бесразрешенным переводам стоимости.

Трекинговое программное обеспечение сторонних разработчиков также сможет более легко отслеживать статусы намерений для любого нового dapp, если они соответствуют стандарту.

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

Я предполагаю, что конкурирующие протоколы расчетов, такие как SUAVE, Across, Anoma и Khalani, будут предлагать дифференцированные функции для решателей намерений. В зависимости от того, какая расчетная сеть погашает решатель, решатель может предложить владельцу намерения различные гарантии цены и времени. Децентрализованное приложение и решатель могут договориться о том, чтобы направить намерение пользователя в расчетную сеть, которой они доверяют, чтобы избежать цензуры, сохранить конфиденциальность данных, а также быть достаточно безопасными, чтобы им можно было доверять, чтобы они выплатили решателю.

Закрепляя выбор сети расчетов в самом заказе, решатель может заложить эту уверенность в котировку, которую он покажет пользователю. Решатель и пользователь могли бы устранить неопределенность относительно ценообразования моста до подачи намерения onchain, снижая затраты.

В сотрудничестве с Uniswap и на основе обратной связи от рабочей группы по CAKE, Across и я предлагаем следующий стандарт намерений межцепочного приоритетизации UX решателя:

///@titleТип CrossChainOrder

///@noticeСтандартная структура заказа, которую подписывают обменивающиеся стороны, распространяют на заполняющих и отправляют на расчетные контракты

структура CrossChainOrder {

/// @dev Адрес контракта, по которому должен быть завершен заказ./// Заполнители отправляют этот заказ по этому адресу контракта на исходной цепочкеaddress settlementContract;/// @dev Адрес пользователя, который инициирует своп,/// чьи входные токены будут взяты и помещены в депозитaddress swapper;/// @dev Нонс для защиты от повторной передачи заказаuint256 nonce;/// @dev Идентификатор исходной цепочкиuint32 originChainId;/// @dev Временная метка, к которой должен быть инициирован заказuint32 initiateDeadline;/// @dev Временная метка, к которой заказ должен быть заполнен на целевой цепочкеuint32 fillDeadline;/// @dev Произвольные данные, специфические для реализации/// Может использоваться для определения токенов, сумм, целевых цепочек, сборов, параметров расчетов,/// или любой другой информации, специфичной для типа заказаbytes orderData;

}

Этот стандарт разработан для упрощения работы решателя. Одним из определенных выборов, которые он делает, является поддержка Permit2/EIP3074 нативно с nonce и initiateDeadline, что дает заполнителям некоторые гарантии, такие как сумма, которую они получат обратно из сети расселения, и формат намерения пользователя, который они могут отслеживать. Более того, в стандарте определена функция инициализации, которая критически позволяет заполнителю, тому, кто приведет ордер onchain, указать дополнительные «fillerData» onchain, о которых пользователь не знал в момент подписания CrossChainOrder. Это позволяет заполнителю убедиться, что он будет вознагражден контрактом расселения за представление мета-транзакции пользователя и также установить информацию о конкретном возврате, такую как цепь возврата.

Этот стандарт также разработан для упрощения отслеживания статуса выполнения намерений dapps на протяжении всего его жизненного цикла. Любой договор по расчетам, реализующий этот стандарт, должен создавать пользовательский подтип ResolvedCrossChainOrder, который может быть разобран из произвольного поля orderData. Это может включать информацию, такую как токены, участвующие в свопе, цепочки назначения и другие ограничения выполнения. В стандарт включена функция разрешения, чтобы позволить dapps понимать, как отображать статусы намерений пользователям, и солверам знать точную структуру порядка намерения, с которым они работают.

/// @titleТип ResolvedCrossChainOrder

/// @noticeОбобщенное представление заказа, не зависящее от реализации

///@devОпределяет все требования к заполнению заказа путем разбора специфических для реализации данных заказа.

/// @devПредназначен для улучшения обобщения интеграции, позволяя заполнителям вычислять точную информацию ввода и вывода любого порядка

структура ResolvedCrossChainOrder {

/// @dev Адрес контракта, по которому должен быть осуществлен расчет. Адрес расчетного контракта;/// @dev Адрес пользователя, инициирующего обмен. Адрес переключателя;/// @dev Нонс, который будет использоваться в качестве защиты от повторной передачи для заказаuint256 nonce;/// @dev Идентификатор цепи исходного блокаuint32 originChainId;/// @dev Временная метка, по которой заказ должен быть инициированuint32 initiateDeadline;/// @dev Временная метка, по которой заказ должен быть заполнен на целевой цепи(цепях)uint32 fillDeadline;/// @dev Входные данные, которые должны быть взяты у переключателя в качестве части инициирования заказаInput[] swapperInputs;/// @dev Выходные данные, которые должны быть предоставлены переключателю в качестве части выполнения заказаOutput[] swapperOutputs;/// @dev Выходные данные, которые должны быть предоставлены заполнителю в качестве части расчета заказаOutput[] fillerOutputs;

}

/// @noticeТокены, отправленные обменником в качестве входных данных для ордера

struct Input {

/// @dev Адрес токена ERC20 на исходной цепочкеадрес токена;/// @dev Сумма токена для отправкиuint256 сумма;

}

///@noticeТокены, которые должны быть получены для корректного выполнения заказа

структура Output {

/// @dev Адрес токена ERC20 на целевой цепи/// @dev адрес(0) используется как маркер для основного токенаaddress token;/// @dev Сумма токена, которая должна быть отправленаuint256 amount;/// @dev Адрес для получения выходных токеновaddress recipient;/// @dev Целевая цепь для этого выводаuint32 chainId;

}

Реализация соглашения о расчетах в соответствии с требованиями ДОЛЖНА реализовывать интерфейс ISettlementContract:

///@titleISettlementContract

/// @noticeСтандартный интерфейс для расчетных контрактов

interface ISettlementContract {

/// @notice Запускает урегулирование кросс-цепочечного ордера/// @dev Должен быть вызван заполнителем/// @param order Определение кросс-цепочечного ордера/// @param signature Подпись свопера на ордер/// @param fillerData Любые данные, определенные заполнителем и требуемые урегулировщикомfunction initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;/// @notice Разрешает конкретный кросс-цепочечный ордер в обобщенный ResolvedCrossChainOrder/// @dev Предназначен для улучшения стандартизированной интеграции различных типов ордеров и контрактов на урегулировании/// @param order Определение кросс-цепочечного ордера/// @param fillerData Любые данные, определенные заполнителем и требуемые урегулировщиком/// @returns ResolvedCrossChainOrder - гидрированные данные ордера, включая входы и выходы ордераfunction resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);

}

Цели разработки этого стандарта заключались в улучшении пользовательского интерфейса решателя, облегчении для них поддержки нескольких расчетных сетей и детерминированном вычислении своих наград. Я верю, что это позволит им давать пользователям более точные и жесткие котировки. Вы можете прочитать более подробные сведения об этом стандарте, кодовое имя которого ERC7683.в этом X/Twitter постеи обсуждение, окружающее этона форуме Ethereum Magicians.

Заключительные мысли

«Намерения» вводят в заблуждение, потому что они не определены, и отсутствие определения создает реальные дефекты пользовательского опыта.

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

По моему мнению, более податливым подходом будет для dapps, которые уже имеют много пользовательского трафика и порождают много пользовательских намерений, согласиться соблюдать некоторый минимальный стандарт, который примут их существующие решатели. Это позволит сформировать новый и более крупный пул решателей. Получив доступ к объединенному объему ордеров уже известных площадок, этот новый пул решателей будет зарабатывать больше прибыли и сможет предложить лучшие цены конечным пользователям. В конечном итоге, новые dapps также будут требовать маршрутизации своих намерений к этому пулу решателей и поддерживать его стандарт намерений.

Для того чтобы запустить нас, Across и Uniswap совместно предложение стандартадля всех участников цепочки поставок использовать при обработке заказов пользователей для отправки токенов X с цепи A и получения токенов Y на цепи B. Порядок выполнения, проходящий через UniswapX (имеющий сравнительное преимущество в дизайне аукционов и исходных намерениях) и Across (имеющий сравнительное преимущество в урегулировании выполнения намерений), может объединиться и начать процесс развития более крупной и конкурентоспособной сети решателей.

Отказ от ответственности:

1. Эта статья перепечатана из [ Зеркало], Все авторские права принадлежат оригинальному автору[Ник Пай]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они оперативно разберутся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционными советами.
3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.