Введение в намерения и интенто-ориентированные архитектуры
Все приложения имеют один общий примитив: намерение. Децентрализованные механизмы выполнения намерений зависят от конкретного приложения, и никто еще не предложил обобщенный механизм, способный выполнить любое намерение.
На данный момент все архитектуры децентрализованных приложений ориентированы на блокчейн, где все вращается вокруг существования и необходимости блокчейна, что серьезно ограничивает пространство для проектирования – устанавливая потолок< /span>какие приложения могут быть созданы на их основе. свойства, которые могут предложить архитектуры, и ограничение
Anoma — это первая архитектура, ориентированная на намерения, которая освобождается от любых существующих ограничений, в том числе, если нам с самого начала нужен блокчейн (для чего-то, кроме расчетов). Вместо этого отправной точкой является вопрос: что нужно приложениям?В этом поиске мы принимаем во внимание все виды приложений, существующие сегодня: децентрализованные, централизованные и даже те, которые невозможно построить на архитектуре web2 или web3.
Оказывается, все приложения имеют один общий примитив: намерение.
Намерения и приложения могут иметь произвольную сложность.
Децентрализованные механизмы выполнения намерений зависят от конкретного приложения, и никто еще не предложил обобщенный механизм, способный выполнить любое намерение.
Преимущество архитектуры, ориентированной на намерения, заключается в том, что она обеспечивает свойства обобщенных намерений, обнаружения контрагентов, решения и расчетов, чего достаточно для работы всех существующих приложений, но со сквозной децентрализацией.
Архитектуры, ориентированные на намерения, совместимы с архитектурами, ориентированными на блокчейн, и могут использоваться разными способами: L1, L1.5 или даже L2 — все зависит от разработчиков dApp.
Они также предоставляют новые свойства, которые могут использовать dApps, о которых мы даже не думали, и еще слишком рано говорить, где находятся ограничения.
Что такое намерения?
Намерение – это выражение желаемого конечного состояния(й) человека. Всякий раз, когда человеку что-то нужно, он подсознательно генерирует в голове виртуальное намерение. Это может быть что угодно: желание рыбы, кофе, пиццы или даже NFT:
Намерения были всегда, мы просто не знали о них. Люди начали использовать намерения задолго до того, как начали взаимодействовать с программным обеспечением, компьютерами, деньгами и бартерными системами – и прямо сейчас каждый генерирует намерения в своей голове.
Что радикально изменилось, так это количество и разнообразие механизмов, которые люди могут использовать для реализации своих намерений. По сравнению с 6000 г. до н.э. в Месопотамии, когда появилась первая бартерная система, сегодня у нас есть гораздо больше механизмов, включая бумажные валюты, инфраструктуру TradFi, Биткойн и Эфириум:
Все существующие механизмы невзаимозаменяемы, они с разными свойствами и компромиссами; и они неисключаемы, то есть люди используют несколько механизмов одновременно, в зависимости от того, какой из них обеспечивает наилучшие свойства и компромиссы для каждого намерения они хотят завершить.
Эта статья посвящена намерениям, связанным с децентрализованными приложениями (dApps) и децентрализованными механизмами которые способны выполнить намерение.
Намерения и децентрализованные приложения
Есть приложения, которые достаточно просты, и их можно включить с одним намерением. Существуют также более сложные приложения, которые можно активировать с помощью одного намерения, поскольку намерение может содержать произвольные уровни сложности:
Вы можете не согласиться с некоторыми сравнениями на рисунке 3, но, по крайней мере, легко согласиться с тем, что намерение платежа (покупка пиццы за BTC) намного проще, чем квадратичное голосование за финансирование. Что интересно, самое простое приложение, требующее только одного намерения, — это платеж.Любое другое децентрализованное приложение потребует более одной стороны, а также больше классов намерений:
Возможно, трудно согласиться с позицией каждого dApp на рисунке 4, но легко согласиться с тем, что платеж в ETH dApp существенно проще, чем в Gitcoin Quadratic Funding раунд на Ethereum или денежная система на основе SALSA, например Plural Money.
Еще одно наблюдение: чем проще dApp, тем больше механизмов существуют для их завершения; чем сложнее dApp, тем меньше механизмов существует сегодня для их завершения .
Например, намерение платежа может быть выполнено с помощью множества механизмов: бумажных валют, систем TradFi, таких как банковские переводы или кредитные карты, или просто криптовалюты. и это лишь некоторые из них – каждый из которых имеет разные свойства и компромиссы. Но варианты значительно сокращаются, когда дело доходит до механизмов, которые могут облегчить более сложные приложения, такие как комбинаторные аукционы и их намерения< /span>Гетеротопия (деньги без масштаба). или CoFi, Множественные деньги, таких как экономических системах нового века, игре B, и варианты становятся еще менее ясными, когда мы говорим об
Очень важное наблюдение заключается в том, что потенциально существуют еще более интересные и сложные приложения и намерения, о которых мы еще не думали. И последний, но фундаментальный вывод: любое приложение может быть представлено намерениями (см. намерения как CSP) a>).
Существует множество децентрализованных механизмов, которые могут реализовать цели, специфичные для приложения – но никто еще не предложил механизм, который является универсальным и достаточно масштабируемым для реализации любого намерения и включения любого децентрализованного приложения, независимо от его сложности, количество уникальных вовлеченных сторон, отдельные категории участвующих сторон и общий объем намерений, участвующих в приложении.
Намеренно-ориентированные архитектуры
Архитектура, ориентированная на намерения, — это архитектура, в которой наиболее фундаментальным примитивом является намерение , а намерения не являются специфичными для приложения, а обобщены. В архитектурах, ориентированных на намерения, пользователи определяют одно или несколько конечных состояний, которых они хотят достичь, и архитектура спроектирована так, чтобы реализовать намерение, соблюдая при этом ограничения, которые определил пользователь.
Другой способ взглянуть на архитектуру, ориентированную на намерения, — это проект полностью обобщенного механизма завершения намерений.
Интенто-ориентированные архитектуры имеют множество преимуществ:
Предоставляет все свойства, необходимые существующим децентрализованным приложениям: обобщенные намерения, обнаружение контрагентов, решение и расчет
Предоставляет новые свойства для dApps: включая локальную и глобальную масштабируемость, управление информационными потоками, настраиваемый порядок, настраиваемый расчет и композиционная идентичность
Применяет декларативную парадигму для приложений
Приводит к максимально децентрализованным рыночным структурам с учетом экзогенных ограничений, таких как ограничения распределенных систем и физики, в которых пользователи своими намерениями и действиями определяют, какие рыночные структуры они хотят
Здесь есть что раскрыть, но в этой статье я сосредоточусь на (1) ориентированных на намерения архитектурах, обеспечивающих все необходимые свойства для существующих dApps.
Какие свойства нужны децентрализованным приложениям?
Я определяю свойство как функцию, которую архитектура или протокол инфраструктуры предоставляет dApps. Например, программируемыйрасчет является ключевым свойством, которое блокчейн-ориентированные архитектуры, такие как Ethereum, обеспечивают для dApps.
Отправной точкой архитектуры, ориентированной на намерения, являются какие свойства нужны децентрализованным приложениям?
Можно ответить на этот вопрос, рассмотрев архитектуру самых сложных dApps в экосистеме Ethereum: торговые площадки NFT (OpenSea, Blur), DEX на основе книги заказов или DEX с поддержкой MEV (0x, 1inch, CoWSwap). , Quadratic Funding (Gitcoin), все они требуют следующих свойств: намерения, обнаружение контрагентов, решение и расчет.
Намерения, обнаружение контрагентов, решение и урегулирование в рамках архитектур, ориентированных на блокчейн.
Архитектуры, ориентированные на блокчейн, такие как Ethereum, предоставляют одно ключевое свойство: программируемый расчет, которого достаточно для обеспечения сквозной работы приложений. децентрализовано, когда намерения, обнаружение контрагентов и решение применяются в блокчейне. Этого достаточно для некоторых dApps, например создания взаимозаменяемых и невзаимозаменяемых токенов, DAO или простых форм DeFi, таких как продажа токенов, аукционы или DEX на основе AMM. К настоящему времени разработчики dApp проверили границы того, какие приложения могут быть полностью созданы на Ethereum, и самоесложное и практичное в использовании комплексное dApp. на сегодняшний день это Uniswap 3.
Но этот путь неприменим для более сложных dApps в экосистеме Ethereum. Вместо этого они следуют тому, что я называю архитектурой поколения 2.5, где окончательная транзакция совершается в Ethereum, но для определения намерений и обнаружения контрагентов полагаются на компоненты Web2. и решение.
Чтобы смягчить проблемы централизации, все большее количество dApps поколения 2.5 следует по пути проектирования «блокчейн-децентрализация-X», который заключается в развертывании суверенной цепочки, которая обеспечивает необходимые свойства для dApp, помимо расчетов на Ethereum.
Развертывание блокчейна кажется простым в модернизации решением, которое может смягчить проблемы централизации сегодня, но оно обеспечивает только намерения, специфичные для приложения в единой модели безопасности (также известной как домен, например Ethereum), которая также имеет структурные ограничения: потеря возможности компоновки и сетевых эффектов, а также более сложный UX для пользователей, обусловленных большей сложностью архитектуры приложений. Более того, это существенно расширяет объем задач каждой команды децентрализованных приложений, которая прошла путь от создания приложений (Solidity и интерфейсных частей) до управления целый блокчейн.
Намерения, обнаружение контрагентов, решение и расчет в архитектурах, ориентированных на намерения
Одним из преимуществ архитектуры, ориентированной на намерения, является то, что она с самого начала обеспечивает необходимые свойства (намерения, обнаружение контрагентов, решение и расчет) для любого существующего dApp. Вот как я определяю свойства:
Обобщенные намерения: способность архитектуры обрабатывать произвольные намерения и не ограничиваться намерениями, специфичными для приложения или особым случаем
Обнаружение контрагентов: децентрализованный процесс, посредством которого отдельные намерения могут быть раскрыты и доступны решателям
Решение: децентрализованный процесс, посредством которого намерения объединяются и вычисляются с помощью действительного решения (транзакции), которое может быть урегулировано
Урегулирование: проверка и доработка решений в сети
Поскольку архитектура спроектирована так, чтобы предоставлять dApps больше свойств, сфера деятельности конструктора dApp, ориентированного на намерения, ограничивается намерением шаблоны и соответствующие предикаты на уровне расчетов. Пользователям архитектуры, ориентированной на намерения, нужно беспокоиться только об определении своих намерений, которые являются обязательными обязательствами для желаемого конечного состояния(й).
DApps на архитектурах, ориентированных на намерения, имеют множество последствий, но ключевое отличие состоит в том, что намерения полностью компонуются. Поскольку намерения можно обобщить, решателям предстоит определить, какие намерения могут сформировать правильное решение. Это означает, что один решатель может предложить решение, включающее 10 намерений, ограниченных торговлей взаимозаменяемыми токенами, а другой решатель может предложить решение, включающее 1000 намерений, причем некоторые из них выглядят как торговля взаимозаменяемыми токенами, другие — как сделки NFT или комбинации последнее в дополнение к намерениям, связанным с другими приложениями.
Другим следствием является то, что это можно обобщить для всех моделей безопасности (также известных как домены), а это означает, что приложения больше не привязаны к домену или блокчейну, это интересный результат того, что я называю архитектурами Gen 2++.
Архитектуры поколения 2++ характеризуются теми же архитектурными особенностями, что и Ethereum, с вариациями конкретных примитивов, например другого консенсуса (Накамото консенсус, например, консенсус BFT), механизм сопротивления сивилле (от PoW до PoS), конфиденциальность (прозрачная для частного исполнения); или оптимизация конкретных свойств, таких как пропускная способность. Solana, Polkadot, Avalanche — примеры Gen 2++. Однако большинство приложений, созданных на каждой архитектуре Gen 2++, по логике аналогичны приложениям, созданным на Ethereum, только с разными языками для разных виртуальных машин.
Даже если пользователи (A , B, C, D) и dApps одинаковы (Uniswap, OpenSea, CoWSwap, Gitcoin), поскольку dApps зависят от блокчейна, намерения пользователя и приложения фрагментированы по каждому домену и не могут быть объединены друг с другом. Вместо этого в архитектуре, ориентированной на намерения, dApps полностью универсальны для всех моделей безопасности. Вместо того, чтобы заставлять пользователя взаимодействовать с четырьмя различными архитектурами с небольшими вариациями, гораздо проще стандартизировать один язык для намерений и один интерфейс для создания намерений:
В приведенных выше примерах я думал о реализации архитектуры, ориентированной на намерения, в виде суверенной цепи или L1. Но еще одним преимуществом архитектур, ориентированных на намерения, является то, что они предлагают спектр свойств, но разработчики dApp сами решают, какие свойства заимствовать. Кроме того, они совместимы с существующими архитектурами, ориентированными на блокчейн.
Например, dApp может извлечь выгоду из обобщенных намерений, обнаружения контрагентов и свойств решения из архитектуры, ориентированной на намерения, но решить использовать расчет в другой суверенной цепочке, что означает, что архитектура, ориентированная на намерения, используется как L1.5:
Приложения в этой модели написаны стандартным образом и не зависят от модели развертывания или от того, какой уровень расчетов используется, чего нельзя сказать о том, как пишутся dApps на Ethereum или на Solana.
Другой способ использования dApps архитектур, ориентированных на намерения, — это L2.0 или объединение. В этой модели dApps будут вычислять полный переход состояния (Anoma, Ethereum или любой другой цепочки) в архитектуре, ориентированной на намерения, и развертывать верификатор ZK для получения безопасности в другом блокчейне, например Ethereum:
Какие приложения могут реализовать архитектуры, ориентированные на намерения?
Первое поколение архитектур было разработано Биткойном, и основным свойством, которое Биткойн и др. для децентрализованных приложений было регулирование на основе сценариев. Скриптовые расчеты позволили процветать нескольким децентрализованным приложениям: децентрализованная эмиссия валют и платежи с помощью криптовалюты с различными свойствами (например, конфиденциальностью). Но этих свойств было недостаточно для других децентрализованных приложений, которые многие предполагали, таких как цветные монеты или фондовая биржа Биткойн, которые могут быть построены на основе скриптовых расчетных архитектур, но были ограничены и непрактичны в использовании.
Ethereum стал пионером второго поколения архитектуры программируемых расчетов, которая обеспечила большую выразительность уровню расчетов и позволила использовать больше видов dApps, чем поколение 1, например, взаимозаменяемые и невзаимозаменяемые токены, DAO или простые формы DeFi, такие как продажа токенов, аукционы или DEX на основе AMM. К настоящему времени разработчики dApp проверили границы того, какие приложения могут быть полностью созданы на Ethereum (и практичны в использовании), и самым сложным и используемым dApp на сегодняшний день является AMM, в частности Uniswap v3. Архитектуры поколения 2.5 зависят от приложения, но эта архитектура позволяет использовать больше приложений, которые не могут быть полностью созданы на Ethereum, например торговые площадки NFT, основанные на книге заказов или DEX с поддержкой MEV.
Третье поколение архитектур, ориентированных на намерения, позволяет использовать все приложения поколений 1, 2 и 2.5 со сквозной децентрализацией – если рассматривать только базовые свойства обобщенных намерения, выявление контрагентов, решение и урегулирование. Интенто-ориентированные архитектуры также предоставляют новые свойства, о которых разработчики dApp еще даже не задумывались, включая: локальную и глобальную масштабируемость, управление информационными потоками, настраиваемый порядок, настраиваемый расчет и композиционную идентичность, что может позволить создавать dApps, которые невозможно построить на основе существующих. архитектуры.
Заключение
Подобно тому, как Ethereum был представлен миру, использующему только биткойны, где было неясно, какие виды dApps можно создавать с помощью новой парадигмы, мы только поверхностно рассмотрели, какие приложения можно создавать с помощью намерений и третьего подхода. поколение архитектур.