Управление Uniswap рассматривает request for comments, или RFC, который ввел бы опциональный приватный путь исполнения внутри интерфейса Uniswap. Предложение предполагает использование Uniswap v4 hooks и UniswapX, чтобы сократить объем информации о транзакции, раскрываемой до исполнения свопа.

RFC, поданный SilentSwap, описывает предлагаемую функцию как опцию “Swap Privately”. Согласно предложению, стандартные свопы останутся без изменений, а комиссии пулов не будут затронуты. Предлагаемый дизайн опирается на zk-SNARKs и предварительную проверку соответствия требованиям перед исполнением, чтобы поддержать более приватную обработку сделок.

Пользовательская проблема, стоящая за техническим дизайном, проста: on-chain свопы прозрачны. Эта прозрачность является ключевой особенностью децентрализованных финансов, но она также может раскрывать намерение транзакции до исполнения. Когда такая информация становится видимой, боты и продвинутые трейдеры могут получить возможность осуществлять фронт-раннинг, sandwich-атаки или иным образом эксплуатировать пользователей.

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

Почему приватность свопов важна

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

MEV, sandwich-атаки и утечки исполнения уже много лет являются повторяющимися проблемами в DeFi. Термин MEV, сокращение от maximal extractable value, был формализован примерно в 2019 году и с тех пор стал признанной структурной проблемой в торговле на базе Ethereum. Инфраструктура, такая как Flashbots’ MEV-Boost, широко принятая после перехода Ethereum на proof-of-stake, была создана для решения отдельных аспектов этой проблемы на уровне построения блоков. Некоторые пользователи также полагаются на приватные RPC, агрегаторы, настройки проскальзывания или более продвинутые инструменты маршрутизации, чтобы снизить раскрытие информации. Другие не используют такую защиту либо потому, что не знают о ней, либо потому, что эти инструменты не входят в их обычный торговый процесс.

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

Добавление опции “Swap Privately” в массовый интерфейс приблизило бы защиту к точке, в которой пользователи инициируют сделки. RFC представляет функцию как опциональную, а не как замену стандартному исполнению свопов.

v4 Hooks поддержали бы более гибкий дизайн

Uniswap v4 hooks являются центральной частью предлагаемой архитектуры. Hooks позволяют разработчикам настраивать поведение пулов и логику исполнения вокруг свопов. Такая гибкость может поддерживать различные дизайны маршрутизации, структуры комиссий, механизмы обработки ордеров и функции, связанные с приватностью. Сам Uniswap v4 остается в разработке и еще не был развернут в mainnet, что означает, что техническая основа предлагаемой функции все еще проходит аудит и тестирование.

Согласно RFC, v4 hooks будут использоваться как часть архитектуры приватного исполнения. UniswapX также включен в дизайн, поскольку он уже поддерживает более гибкое исполнение свопов через аукционную систему маршрутизации с использованием внешних fillers. UniswapX был представлен в 2023 году и сам по себе включает определенные свойства защиты от MEV по дизайну, поскольку ордера исполняются off-chain через конкурентные аукционы, а не отправляются напрямую в публичный mempool. Вместе эти два компонента могли бы предоставить маршрут, при котором детали транзакции меньше раскрываются до исполнения, при сохранении опоры на ликвидность и интерфейс Uniswap.

Однако дизайн остается предметом обсуждения в управлении. RFC не является утвержденным изменением управления и не означает, что функция уже работает. Это предложение для рассмотрения, критики, доработки или отклонения сообществом.

Приватность и комплаенс рассматриваются вместе

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

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

Предлагаемое использование zk-SNARKs опирается на технологию, которая была проверена в проектах, таких как Zcash, запущенный в 2016 году, а также в Ethereum zero-knowledge rollups, получивших распространение с 2023 года. zk-SNARKs позволяют одной стороне доказать знание информации, не раскрывая саму информацию, что делает их релевантными как для приватности, так и для комплаенс-дизайнов с выборочным раскрытием.

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

Такой баланс сложен и, вероятно, останется предметом споров. Тот факт, что управление Uniswap обсуждает модель с участием zk-SNARKs и проверки соответствия требованиям, показывает, что разговор о приватности в DeFi стал более сложным.

Одобрение не гарантировано

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

Потенциальные вопросы включают техническую сложность, предположения о доверии, провайдеров проверки, юридические риски, стоимость и то, понимают ли пользователи, что означает “private” в данном контексте. Эти вопросы являются центральными для любой попытки добавить приватность исполнения в крупный интерфейс DeFi.

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

Роль Uniswap в рыночной структуре DeFi

Положение Uniswap в децентрализованной торговле придает предложению более широкую значимость. Когда Uniswap изучает новые модели исполнения, другие DeFi-протоколы, DEXs и агрегаторы, вероятно, оценивают последствия. Протокол и интерфейс глубоко встроены в то, как пользователи торгуют on-chain.

Другие децентрализованные торговые платформы уже применяют разные подходы к MEV и защите исполнения. CoW Swap использует пакетные аукционы с конкуренцией solver, чтобы снизить способность ботов переупорядочивать или вставлять сделки. 1inch интегрировал функции, предназначенные для смягчения фронт-раннинга. RFC Uniswap добавляет еще один проектный подход к продолжающейся отраслевой дискуссии.

Опция приватности внутри этого торгового процесса может повлиять на ожидания пользователей от других децентрализованных бирж и агрегаторов. Она также может внести вклад в более широкое обсуждение стандартов исполнения в DeFi.

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

На данный момент RFC остается лишь предложением. Он указывает на возможную модель, при которой свопы DeFi продолжают прозрачно рассчитываться on-chain, но раскрывают меньше информации в период, когда пользователи наиболее уязвимы к утечке исполнения.

Эта статья основана на RFC управления Uniswap о нативной приватности исполнения через v4 hooks и UniswapX. Оригинальный материал Bitcoinist был написан News Desk и отредактирован Samuel Rae, а также основан на информации, опубликованной в первичной документации.