Намерения нереальны

Намерения, день 0: новая психологическая операция

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

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

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

Это все огромная психологическая операция. Намерения ненастоящие.

Оглавление

(Намерения: прошлое, настоящее и усилие; Будущее

Утро началось с презентации Christopher Goes из Heliax. Кристофер начал с краткого обсуждения истории намерений.

Этимология и концептуальная история намерений

• март 2009 г. & Раньше - начиная с A commitment folk theorem моделирования условных обязательств в стратегических играх. Ранее упоминалась Agoric Open Systems Papers и Program Equilibriumлитература.
• Февраль 2018 г. – The Wyvern protocol – где задача протокола — сопоставлять намерения покупателя и продавца в цепочке, чтобы передача активов и оплата происходили атомарно.
• Март 2019 г. — идея Вирджила Гриффита о Ethereum is game-changing technology, literally — надежном механизме обязательств, который превращает некооперативные игры в кооперативные. Отправьте ему Mail.
• Август 2022 г. — The Anoma white paper представил архитектуру Anoma, ориентированную на намерения, и описал намерение как подписанное сообщение вне цепочки, которое кодирует переходы состояний, которых хочет достичь пользователь.< /а>
• Май 2023 г. — Research Day в Нью-Йорке прошла вечеринка в широком исследовательском сообществе.for intents
• Август 2023 г. – Intents Day 0 и далее.

Активность

Чтобы завершить вводное занятие, Кристофер взял и прочитал карточки из стеклянной чаши, которую гости заполняли по прибытии. Карточки были заполнены ответами на вопрос «Что такое намерение?»

(1) Намерения в отношении блокчейнов

Цель: Нарисовать картину того, как намерения понимаются и обрабатываются в экосистемах блокчейна.

Это был первый сегмент сессии. У нас было отличное представительство из разных проектов, включая Cosmos, Ethereum, Celestia & Анома.

(1.1) Вертикально интегрированная цепочка поставок намерений

Этот трек начался с презентации 0xbrainjar, который вновь представил Composable Finance как механизм обработки намерений пользователей. Их тезис прост; выполнение транзакций в блокчейнах должно быть независимым от экосистемы, бесплатным и конфиденциальным.

Предлагаемое Composable решение этой проблемы называется MANTIS, что означает многоцепочечное независимое нормализованное урегулирование намерений с минимизированным доверием. Это решение состоит из:

• Связь в X-домене (IBC везде)
• Мультидоменные аукционы
• Язык исполнения
• Подтверждаемый расчет

Архитектура

Предложенная архитектура реализована как космическая цепочка Centari , которая пытается удовлетворить предпочтения пользователя с помощью программируемых решений. В частности, некоторые из решений включают Cows, RFQ и & Маршрутизация CFMM.

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

Дорожная карта

Наконец, презентация завершилась исследованием заслуживающих доверия схем обязательств, таких как MEV-Boost ++ и PEPC-Boost. Composable стремится создать новое реле, которое позволило бы создавать частичные блоки. Было предложено использовать перераспределение ставок на собственном уровне, чтобы сделать этот стимул совместимым для различных агентов в цепочке поставок.

(1.2) Намерения и усилия; Typhon

Далее Исаак Шефф из Heliax представил Typhon, универсальную машину заказа Anoma, состоящую из мемпула (. и ) и механизм выполнения. Презентация была посвящена жизненному циклу намерений Heterogeneous Narwhal-Rider), консенсус (Heterogenous Paxosp2p layerChimera Chains

Упрощен жизненный цикл намерения

• Пользователи создают (и подписывают) намерения
• Намерения передаются одному или нескольким решателям, которые пытаются их сопоставить и найти решения.
• Эти решения называются транзакциями, которые необходимо отправить для внесения изменений в состояние.
• Где-то кто-то поддерживает официальное заявление о том, что все эти намерения касаются всех этих намерений, и им необходимо совершать эти транзакции, разрешая любые конфликты.

Уровень P2P Anoma

Уровень P2P Anoma построен на архитектуре, которую мы называем P2P Overlay Domains with Sovereignty или PODS. Основная идея заключается в том, что любая группа узлов может работать как практически независимая оверлейная сеть, называемая доменом, используя любые протоколы широковещания или выбора соседей, которые им нравятся. Домены могут использоваться решателями или пользователями, интересующимися конкретными темами.

Цепи Химеры

Химерная цепь — это тип боковой цепи, который позволяет выполнять атомарные транзакции на objects из базовых цепей. Он несет в себе дополнительный механизм консенсуса, который зависит от консенсуса базовых цепей.

Заключение

В конечном итоге платформа Anoma позволит людям создавать космические блокчейны с использованием Typhon и использовать цепочки-химеры. Цепи Химеры — это то, чего еще никто не делал. Скоро у нас будет полное предложение по спецификациям. Более подробную информацию о том, как принять участие, см. в объявлении RFC.

(1.3) Намерения, накопительные пакеты на основе и amp; Выражение предпочтения

Джон Адлер & C-Node из Celestia провел сеанс с доской. Джон обсудил намерения, решения, риски и язык намерений. C-Node обсуждал объединение на основе и выражение предпочтений на Celestia.

Намерения

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

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

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

Проблемы, на которые следует обратить внимание при использовании намерений, — это DOS attack векторы для решателей.

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

Накопительные пакеты на основе & Выражение предпочтения

Based rollups  не используйте секвенсоры. Эти типы объединений наследуют жизнеспособность и полную децентрализацию L1. Объединение основано, когда следующий предлагающий L1 может без разрешения включить следующий блок объединения как часть следующего блока L1.

Как выбрать, какие капли выбрать из Celestia в виде накопительного пакета?

• Вы можете сделать что-то простое, например выбрать блок, который сжигает больше всего газа. Этот механизм может тратить токены уровня DP на блоки, которые не выиграют.
• Вместо этого вы можете предпочесть систему, в которой вы говорите: «Это моя заблокированная заявка, и вы можете взимать с меня плату только в том случае, если моя заявка включена».

Если у вас есть выражение предпочтений для уровня публикации данных (nee-data availability), нет необходимости отправлять проигрышную отправку. Это уменьшает количество недействительных блоков. Эти сводные данные передают все MEV на уровень DP. В «Селестии» есть один лидер, который принимает решение о заказе, как и в любой сети CometBFT.

(1.4) PBS & Сессия PEPC с доской

Alex Stokes и Barnabé Monnot из Ethereum Foundation обсудили разделение предлагающих и создателей (PBS) и amp; обязательства предлагающего протокола (PEPC).

Сначала Алекс разобрал PBS, объяснив мотивы и текущий дизайн MEV-Boost, а затем кратко перешел к ePBS.

Мотивации

Мотивацией PBS является противодействие централизации MEV путем сохранения децентрализации валидаторов.

• Брандмауэр отделяет предлагающего от застройщика. Поступая таким образом, роль валидатора может оставаться «тупой»; и не нужно запускать сложные алгоритмы поиска MEV.
• Улучшите доступ к MEV для валидаторов, которым нужно принять только самую высокую ставку от строителя блоков.
• Передайте централизацию специализированным участникам, которых можно использовать для более эффективного построения блоков, выборки доступности данных, безгражданства и дополнительных услуг по сборке.
• Устраните зависимость от доверенного ретранслятора, хотя в некоторых случаях он все еще может существовать.designs

MEV-Boost

MEV-Boostявляется внепротокольной версией PBS, созданной Flashbots и существующей с Merge. MEV-Boost ввел в цепочку поставок роль реле и строителя. Optimistic relaying — недавнее нововведение.

ePBS

ePBS — это закрепленная (с учетом протокола) версия разделения предлагающего и создателя. Продолжается дискуссия об идеальной реализации.

• Исходная 2 slot версия
• Новые предложения комитетов по своевременности полезной нагрузки(PTC)

Затем Барнабе взял на себя управление и обсудил PEPC, который можно условно описать как намерения для предлагающих блоки. PEPC («pepsi») задуман как встроенный протокольный гаджет, который позволяет предлагающим блоки брать на себя обязательные обязательства в отношении производимых ими блоков.

Цели PBS,:

• Обобщить PBS, разрешить справедливый обмен между предлагающим и некоторыми строителями на любой объект; например, целый блок, частичные блоки, списки включения
• Перевести некоторые варианты использования собственного слоя из оптимистического режима отказа в пессимистический режим отказа; например, достоверность блока зависит от выполнения обязательств, а не от условия сокращения для отклонения.

Как PEPC связан с ABCI++

Есть некоторое сходство между PEPC и x/builder Skip module, который включается ABCI++. Однако последний является общим, поскольку он устанавливает глобальные предпочтения для всех блоков данной цепочки, в то время как PEPC представляет собой систему локальных решений, принимаемых  предложителями каждого блока.

Диета PEPC

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

• PEPC-Boost
• PEPC-DVT

(2) Намерения для пользователей

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

(2.1) Намерения ≠ Запросы цен

Khushi WadhwaВторая сессия дня началась с презентации, посвященной запросу (RFQ) на аукционы котировок, намерениям и их взаимосвязи.

Запросы цен

An RFQ price auction — это система определения цены свопа. Для выполнения свопов он использует подписанные сообщения и код контракта. Маркет-мейкеры из белого списка обеспечивают ликвидность, и лучшая цена выигрывает в торгах. Например, в 0x protocol поток сообщений будет выглядеть так.

• Пользователи запрашивают цену из интерфейса приложения.
• API запрашивает информацию о ценах у сетевых AMM и маркет-мейкеров.
• Маркет-мейкеры могут ответить подписанной котировкой.
• Пользователь получает котировку, которая может включать несколько источников ликвидности.
• Затем пользователь подписывает и отправляет транзакцию в цепочке.

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

Намерения

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

• Многоуровневые запросы.  с помощью намерений на основе контекста вы можете использовать историю цепочки, чтобы определить, какие запросы пользователей' идеальное предпочтение. Это трудно.
• Создание-фильтрация сообщений – аналогично Google Flights. Решатели Находят наилучшие возможные пути выполнения, которые удовлетворяют намерению, и позволяют пользователю фильтровать и выбирать свои предпочтения.

Запросы цен ⊆ Намерения

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

(2.2) Цель предложений

Dean Tribble из Agoric представил следующую часть семинара. Презентация Дина была посвящена тому, что не так с пользовательским интерфейсом и как мы можем это исправить с помощью Offer Safety.

Что такое Agoric?

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

• Смарт-контракты JavaScript: используйте имеющиеся у вас знания языка.
• Лучшая в своем классе модель компонентов — основа инноваций для всех уровней квалификации
• Интегрированная экономика – экономические услуги и amp; собственный IST стабильный токен для сборов за развитие богатой экономики
• Уникальное предложение свойств безопасности - безопасность, надежность выплат, безопасные разделы

Что не так с UX?

Текущий пользовательский опыт работы с кошельками и приложениями неприемлем для большинства людей. Например, пользователи не знают никого с именем 0x69e2..e108. Это позволяет легко допускать ошибки при отправке средств на адрес или взаимодействии со смарт-контрактом.

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

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

Обеспечьте безопасность

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

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

• Предложение содержит суммы «дай» и «хочу».
• Предложение содержит приглашение для конкретной точки входа в конкретный контракт, предложение, платежи и настраиваемые аргументы.
• Проверка предложения: предложение имеет свойства, необходимые для приглашения, платежи совпадают.
• Предоставленные активы депонируются асинхронно
• Функция контракта JavaScript для приглашения выполняется.

Предложить разборчивость?

Читабельность предложения — «может ли пользователь понять, какое предложение он одобряет?»

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

Дополнительные свойства безопасности Zoe

• Животность выплат – пользователь должен предоставить Zoe proposal, чтобы указать, когда и как они могут выйти из контракта.
• Безопасность partitioning –  разделяет депонирование и перераспределение активов от принятия решения о перераспределении с помощью ограничений.

Расширения

Что предложения могут сделать для вас?

• Текстовый режим подписи — позволяет кошелькам предоставлять удобочитаемое описание того, что будет выполнять данное взаимодействие с контрактом.
• Шаблоны желаний — позволяет пользователям определять конкретные условия, которые они хотят видеть в потенциальном предложении.
• Multiples — несколько форм поведения для одного пакета состояний.
• Кусочно-линейная кривая предпочтений — фиксируйте предпочтения пользователя в разных точках
• Синтетические комбинированные предложения

Заключение

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

(2.3) Пользователь сталкивается с намерениями с разрешениями

Nitya Subramanian из Capsule представлено следующим. Capsule — это набор инструментов (SDK) для подписания и разрешения транзакций, который позволяет разработчикам создавать собственные кошельки с различными highly functional capabilities.

Web 2

В мире Web 2 пользователи нажимают кнопки, и что-то происходит. Вы можете выражать желания действия (намерения!), не указывая, какие вычисления выполняются. Кроме того, пользователям не важно, где происходит выполнение: GCP, AWS или Azure не имеет значения. Возьмем, к примеру, Slack, где вы можете нажать кнопку и опубликовать сообщение. Вы можете запланировать публикацию на потом или даже создать бота, который будет публиковать сообщения от вашего имени.

Транзакции

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

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

Кошельки делают слишком много

Основная ответственность	Описание
Пользовательские интерфейсы	Все, что происходит до того, как приложение поддерживает кошелек
Аутентификация	Свидетельства о праве собственности на адреса, которые подписываютtx
TxФормирование	Какой контракт и параметры? Сколько бензина платить?
TxПроверка	Это безопасно? Это верно?
TxПодписание	Утвердить
Нодовая инфраструктура	Отправьте tx он-чейн

Введите программируемый MPC

ПрограммируемыйMPC обеспечивает безопасность средств пользователей и гарантирует, что ключи могут авторизовать только те транзакции, для которых они предназначены. Пользователи могут, например, создать кошелек с адресом электронной почты и использовать проверку стиля single sign-on (SSO) для выполнения подписи в фоновом режиме.

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

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

Открытые вопросы

Сопоставление намерений <> Транзакция(и)

• Как пользователь может убедиться, что его намерение было оптимально решено?

Возможность обновления

• Способность действительных «намеренных решений» быстро меняться — это особенность. Как лучше всего отразить эти изменения?

Кошельки

• Каковы особенности кошелька в пост-намеренной парадигме?
• Нужны ли вообще автономные кошельки по сравнению с приложениями напрямую?

(2.4) Аргументы в пользу курирования

В заключительном сегменте Намерения для пользователей Sean Braithwaite из Mekatek обсудили, как курирование играет ключевую роль в intent supply chain.

Намерения

Намеренияreal. Есть несколько действующих products, которые улучшают взаимодействие с пользователем. Эти продукты обеспечивают маршрутизацию, объединение и агрегацию как услуги, абстрагирующие детали инфраструктуры. Пользователям больше не придется беспокоиться о газе, мостах и ​​других дырявых абстракциях.

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

Маховик куратора

Открытие ⇒ Обязательство ⇒ Исполнение ⇒ Урегулирование ⇒ Открытие

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

Новая цепочка поставок намерений

Этап	Описание	Взаимодействующий агент
Курирование	Узнайте предпочтения пользователей с помощью исторических данных по цепочке и LLM.	LLM, Профили данных
Происхождение	Пользовательский интерфейс для построения намерений	Кошельки, децентрализованные приложения
Соответствие	Выявление контрагентов, доведение намерений до сведения заинтересованных лиц	Мемпул, Сеть сплетен, OFA
Исполнение	Необходимое действие для реализации намерения	Решатели, строители, исполнители
Урегулирование	Используйте предикаты и материализованное состояние, чтобы продемонстрировать выполнение намерения, посредством которого решатель может получить свой платеж.	Верификация, Платежи

Намерений недостаточно для информирования пользователей в мире изобилия. Таким образом, может помочь процесс обнаружения, управляемый курированием flywheel. Курирование должно быть частью цепочки поставок, которой владеет пользователь.

(3) Назначение MEV экстракторов решателей

Цель: в этом сегменте дня было нарисовать картину того, как решатели думают о намерениях и как намерения изменят экономику решателя.

(3.1) Подотчетность в цепочке поставок транзакций

Далее Sam Hart от Skip изложил структуру подотчетности для решателей, как сделать участников вне сети более подотчетными. Более подробное объяснение см. в статье Сэма recap.

Постановка задачи

Намерения предоставляют решателям определенную степень свободы для повышения эффективности, UX и других условий удовлетворения. Здесь мы представляем principal-agent problem (PAP) с решателями.

Варианты решения этой проблемы

1. Вновь ввести ограничения
2. Изменить структуру информации
3. Измените структуру выплат
4. Превратитесь в повторяющуюся игру

Система подотчетности

В литературе по институциональной теории существует понятие accountability.

A несет ответственность перед B, когда A обязан информировать B о действиях и решениях A (прошлых или будущих), оправдывать их и понести наказание в случае возможного проступка.

• Ответственность – обоснование поведения, атрибутирование действий.
• Правоприменение – предотвращайте злоупотребления с помощью реальных угроз, вознаграждайте за соблюдение и наказывайте за отклонения.

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

Моделирование подотчетности

Если пользователь взаимодействует с системой напрямую, PAP отсутствует. Когда пользователь делегирует полномочия решателю, он должен создать систему подотчетности, чтобы безопасно делегировать принятие решений.

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

В Cosmos можно считать, что цепи обладают агентством, которое они могут делегировать;

• Решатели – способность выполнять некоторые вычисления, которые в противном случае выполнялись бы конечным автоматом.
• Пользователи - возможность обеспечивать соблюдение, только подписывать сообщения о выделении средств, которые удовлетворяют желаемому намерению.

Система подотчетности dYdX

• dYdX использует метрику order-book discrepancy, созданную и отслеживаемую с помощью Skip, для измерения прибылей и убытков валидатора по сравнению с ожидаемыми. Статистическая оценка такого поведения обеспечивает основу для ответственности, которую можно использовать для построения accountability system

Система репутации 

Валидаторы в Cosmos — отличные кандидаты для делегирования определенных задач благодаря своей репутационной сети в экосистеме.

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

Заключение

За что мы возлагаем ответственность на валидаторов, решателей или ретрансляторов?

Как разработчики протоколов и члены сообщества, мы должны тщательно подумать о том, что это за система behavior we want to elicit 2 и как предоставлять правильную информацию, чтобы поведение было измеримым и ответим.

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

(3.2) Решатели, LST и amp; Мем-монеты

Sun RaghupathiСледующим выступил из Seven Seas. Seven Seas управляет стратегической программой в экосистеме Sommelier.

Решатели

Решатель — это универсальное средство для участника, который использует оффчейн-инфраструктуру для улучшения взаимодействия с пользователем в сети. Искатели — решатели.

Система намерений

Сегодня в системах намеренийCEX-DEX в системах RFQ доминирует арбитраж. Прямая маршрутизация в цепочке невыгодна из-за увеличения затрат на получение ликвидности в цепочке. Чтобы противостоять этому, следующая волна DEX innovation направлена ​​на предоставление более выгодных цен для неосведомленного потока заказов (розничная торговля).

Сегодня существует два основных сетевых рынка: Meme coins и LSTs.

Мем-монеты

• Торговля мем-монетами обеспечивает пользователям наиболее враждебный опыт.
• Институциональный капитал редко затрагивает эти активы, поэтому вполне вероятно, что ландшафт решателей для активов с длинным хвостом останется распределенным.
• Это является убедительным аргументом в пользу существования AMM, например, 99.9% всех токенов имеет возможность обнаружения цен в цепочке.
• Вполне возможно, что системы RFQ также будут фиксировать поток заказов. Участники, готовые принять на себя риск, связанный с запасами, будут иметь преимущество; например.,jaredfromsubway.eth

LST

Токены ликвидного ставок (LST) являются крупнейшим ончейн-рынком. Они крайне неэффективны и страдают от резкого снижения привязки во время волатильности. Большая часть ликвидности токенов LST — это пассивные LP в AMM. В системах RFQ практически отсутствует ликвидность.

Чему мы можем научиться на рынках LST?

• Решающая среда все еще относительно незрела
• Существует нехватка ончейн-инфраструктуры для решателей.
• Специализированные знания примитивов DeFi являются преимуществом

Заключение

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

(4) Намерения для математиков (Теория намерений)

Цель: нарисовать картину того, как намерения могут быть математически формализованы и поняты, и как они связаны с MEV.

(4.1) Завершение изображения намерений ✅

Первый доклад секции «Теория намерений» представил Quintus Kilbourn из Flashbots.

Часть 1: Намерения Отпустить

В первой части намерения были описаны как:

• В общих чертах намерения: «сообщения, которые не обязательно должны быть исполняемыми изолированно».
• Намерения — это сообщения, требующие агрегации.
• Намерения уменьшают трение для экосистемы посредников (задачи агентов)

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

Часть 2: MEV Восстановление контроля

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

• Задержка из-за времени генерации доказательства
• Потеря возможности обнаружения контрагентов из-за слишком большой конфиденциальности
• DoS-риски для посредника

(4.2) Сеанс «Намерения и перегрузка сети»

K Kulkarniиз Беркли и Гаунтлет провели следующую сессию с доской. Он представил идеи Фрэнка Келли, посвященные маршрутизации интернет-пакетов и контролю перегрузок. Келли предложил основу для управления перегрузкой сети в статье под названием:  Charging and rate control for elastic traffic.

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

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

Проблема оптимизации:

маИксИкс​∑я​тыя​(Икся​)маxИкс​​∑я​​Uя​​(xя​​)

При условии:

∑яИкся≤С∑я​Икся​≤С

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

Лагранжиан:

л(Икс,�)"="∑я​тыя​(Икся​)+�(∑я​Икся​−С)L(x,λ)"="∑я​​Uя​​(xя​​)+λ(∑я​​xя​​−C)

Где:

• тыя(Икся)тыя​(xя​)представляет полезность пользователя$я$для передачи со скоростьюИкся​Икся​​.
• ИксяИкся​это скорость, с которой пользователь$я$передает пакеты данных.
• $\lambda$– это множитель Лагранжа, который можно интерпретировать как цену или штраф за нарушение ограничения пропускной способности сети.$С$.

Как это связано с намерениями?

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

(4.3) Машины намерения

Заключительный доклад этого раздела произнес Кристофер Гоес, который представил кандидатский формализм для машин намерений.

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

Формализм

• Исправить тип состояния T
• Намерение — это функция типа
    - T -> Т -> 0|1
• Машина намерений представляет собой потенциально недетерминированную функцию типа

    - (T, Set I) -> (T, Набор I)
      - Первый кортеж: предшествующее состояние и намерения-кандидаты
      - Второй кортеж: апостериорное состояние и обработанные намерения

• Ключевое свойство: приверженность намерению
    - для всех i в обработке . i ранее = 1

Разложение

Без ограничения общности эту функцию можно разложить на два этапа:

• Перечисление: вычисление набора кортежей (состояние-кандидат, обработанное), которые удовлетворяют соблюдению намерения.
• Выбор: выбор одного из кортежей для возврата

Ограничения

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

• Функция перехода состояния внутреннего EVM удовлетворена
• Линейность ресурса & логика удовлетворена

Функция выбора

Выбор выбирает одну пару из набора допустимых вариантов. Вся интересная структура находится здесь.

выберите :: Set (T, Set I) -> (Т, набор I)

Типы функций выбора

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

Распределение

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

• Различные стороны выполняют перебор и выбор.
• Консенсус, чтобы договориться о том, какое новое государство будет выбрано.

Всё роздано!

• Состояние
• Вычисление
• Перечисление
• Выбор
• Проверка

Распределенная композиция

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

(4.4) Изложите свои намерения (вариант 2)

После этого Кристофер, Квинтус и К. приняли участие в световой панели, чтобы обсудить мемы, выбранные мной. Действительно, название вдохновлено оригинальной панелью State Your Intents на MEVday Paris. Это была забавная дискуссия.

Мемы

• Каковы внешние эффекты «we're all building одного и того же»?
• Почему Anoma и Suave было трудно объяснить?
• Intents are just Txs, это решено, да?
• Как не дать MEV dystopia войти через парадную дверь?

Открытые вопросы

• Каковы были бы ваши цели в отношении намеренного формализма?
• Как вы думаете, этот вариант имеет смысл?
• Какие части ясны/неясны?
• Существуют ли другие убедительные кандидатские формализмы?

(5) Заключительные замечания

Awa Sun Yin, строитель общественных благ, поблагодарил всех за участие в мероприятии, а затем завершил свое выступление размышлениями.

(5.1) Продолжение

Спасибо за чтение. Если у вас есть FOMO, и вы заинтересованы в участии в продолжении, не волнуйтесь, оно будет. Если вы хотите выступить на следующем дне намерений, обратитесь в X- preference для FUD.

Скоро – День намерений 1: FUDent Xmas

(5.2) Благодарности

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

0xbrainjar, Исаак Шефф, Джон Адлер, C-Node, Алекс Стоукс, Барнабé Моннот, Кхуши Вадхва, Дин Триббл, Нитья Субраманиан , Шон Брейтуэйт, Сэм Харт, Сан Рагхупати, Квинтус Килборн, К. Кулкарни и др. Кристофер Гоес.  

Спасибо Аве Сун Инь, Кристоферу Гоэсу, Заки Маниану, Коби Гуркану, Таруну Читре и Нику Уайтуe за помощь в координации. Особая благодарность Заки за организацию ужина.

С уважением к лордам мемов; Джон Чарб, Дэниел Марзек, SxySun1, Velvet Milkman и FrankieIsLost

Привет всем, кто занимается созданием общественных благ Heliax. У нас замечательная команда.

(6) Слайды и усилители; Доски

Намерения для блокчейнов

• Вертикально интегрированная цепочка поставок намерений
• Намерения и усилители; Тифон
• Намерения, накопительные пакеты на основе и amp; Сеанс доски для выражения предпочтений
• PBS & Сессия PEPC с доской

Намерения для пользователей

• Намерения != Запросы предложений
• Цель предложений
• Пользователь сталкивается с намерениями с разрешениями
• Аргументы в пользу курирования

Намерения для экстракторов MEV «хороших решателей»

• Подотчетность в цепочке поставок транзакций
• Решатели, LST и мемкойны

Теория намерений

• Завершение замысла Изображение
• Намерения и усилители; Перегрузка сети
• Машины намерений