Архитектура некастодиального трейдинга: как DEX исполняют сделки без KYC и посредников

Вводные данные (Контекст)
Классическая биржевая инфраструктура строится вокруг доверенного посредника: брокер хранит средства клиента, матчит заявки, проводит KYC/AML-проверки и отвечает за журнал ордеров. Децентрализованная биржа (DEX) убирает этот узел из архитектуры. Вместо централизованного сервиса, работающего как демон на выделенном сервере, исполнение сделки ложится на смарт-контракт, развернутый в EVM-совместимой сети. Участник взаимодействует с контрактом напрямую через кошелёк, подписывая транзакцию приватным ключом. Никаких аккаунтов, паспортных данных и API-ключей — только адрес, нонс и сигнатура.

Разбор архитектуры: пул ликвидности как очередь сообщений
Большинство современных DEX используют модель автоматического маркет-мейкера (AMM). Если проводить аналогию с классическим IT, пул ликвидности — это распределённая очередь сообщений (Message Queue), где каждый участник может либо добавить «сообщение» (ликвидность), либо забрать его (своп). Но вместо брокера-потребителя, который обрабатывает очередь, работает детерминированный алгоритм.

Базовый инвариант Uniswap V2 выглядит так: x * y = k. Здесь x и y — резервы двух токенов в пуле, k — константа для конкретной пары при отсутствии свопов. Когда пользователь отправляет в контракт токен A и забирает токен B, контракт пересчитывает резервы так, чтобы произведение x*y осталось равным k (с поправкой на комиссию). Это похоже на поддержание инварианта в структуре данных: каждая операция обязана оставить систему в согласованном состоянии, иначе транзакция откатывается.

Цена актива определяется не оракулом, а соотношением резервов: price = x / y (с учётом десятичных знаков). Это создаёт кривую «цена-скольжение»: чем больше объём свопа относительно ликвидности пула, тем сильнее отклонение от спотовой цены. Инженеру знакомо по амортизации буфера: если буфер почти пуст, операция вызывает резкий скачок метрик.

Контракты и потоки транзакций
С точки зрения EVM, каждый своп — это вызов функции swap() на контракте роутера (например, UniswapV2Router02). Роутер действует как фронтенд-фасад: он принимает параметры пути обмена (path), минимально допустимое количество получаемого токена (amountOutMin) и срок действия транзакции (deadline). Затем роутер вычисляет оптимальный маршрут через пулы и выполняет серию вызовов transferFrom и sync. Именно amountOutMin защищает пользователя от резкого проскальзывания: если алгоритм не может обеспечить указанный минимум, вся транзакция реверсится — это аналог проверки предусловий в критической секции кода.

Важно, что смарт-контракт не хранит приватные ключи. Кошелёк пользователя подписывает транзакцию локально (например, через MetaMask, аппаратный кошелёк или кастомный скрипт на web3.py), а нода сети проверяет сигнатуру и нонс. Отсутствие централизованного хранилища ключей означает: сервер не может заблокировать средства или потребовать KYC. Компромисс: если пользователь теряет ключ или мнемонику, восстановить доступ невозможно — ни поддержка, ни «админ» контракта не помогут.

Почему нет KYC: инженерный взгляд
KYC в классическом бэкенде — это обязательный этап регистрации: проверка личности перед выдачей токена сессии. В DEX такой проверки нет, потому что нет сессий и аккаунтов. Есть только пара «адрес + подпись». Смарт-контракты permissionless по своей природе: любой адрес может вызвать функцию swap. Верификация происходит не через паспорт, а через криптографию — владение приватным ключом. Это снимает целый класс проблем с утечками персональных данных из централизованных баз, но порождает другой: невозможно откатить мошенническую транзакцию или применить chargeback.

Тем не менее, называть DEX полностью анонимными технически неверно. Все транзакции записываются в публичный реестр (блокчейн). On-chain-аналитика, кластеризация адресов и эвристики типа «общий источник финансирования» позволяют деанонимизировать многих пользователей. Для инженера это как логировать все HTTP-запросы без маски IP: приватность не гарантируется, просто уровень абстракции смещается.

Анализ рисков и компромиссов
Первый риск — ошибки в смарт-контрактах. Классический пример — reentrancy: атакующий контракт вызывает функцию вывода средств повторно до обновления состояния. Это Race Condition в чистом виде; в традиционном ПО лечится мьютексом или транзакцией БД, в EVM — паттерном checks-effects-interactions или reentrancy guard. Ошибка в байт-коде может привести к полному дренажу пула, причём без возможности отката.

Второй риск — MEV (Maximal Extractable Value) и фронтраннинг. Поскольку pending-транзакции видны в мемпуле, боты могут вставить свою транзакцию с более высоким gas price перед пользовательской, изменяя курс в пуле. Это аналог гонки за приоритет в очереди задач, где арбитр — комиссия за газ. Для защиты используют private RPC, Flashbots или механизмы вроде лимитных ордеров с частичным исполнением.

Третий — непостоянные потери (impermanent loss) для поставщиков ликвидности. Если курс токенов в пуле меняется относительно внешнего рынка, доля LP в долларовом эквиваленте может оказаться ниже, чем при простом удержании активов. Это следствие автоматического ребалансирования портфеля: контракт алгоритмически продаёт дорожающий токен и покупает дешевеющий. Математически потери описываются формулой относительно начального соотношения цен; они «непостоянны», если курс вернётся, но фиксируются при выводе ликвидности.

Инженерные выводы и перспективы
DEX без KYC — это не столько «философия свободы», сколько перераспределение доверия: с людей и организаций на код и консенсус. Инженерная выгода очевидна: нет серверов с клиентскими данными, нет процедур комплаенса, нет единой точки отказа. Но плата за это — полная ответственность пользователя за управление ключами и невозможность внешнего вмешательства.

С точки зрения масштабируемости, AMM-модель упирается в пропускную способность блокчейна и стоимость газа. Решения второго уровня (rollups), батчинг транзакций и гибридные модели с офчейн-книгой ордеров (например, dYdX) — это попытка решить те же проблемы, что и шардирование или кэширование в классических распределённых системах. Пока же для DevOps-инженера торговля на DEX — это работа с RPC-нодами, газ-эстимацией и мониторингом мемпула, а не с биржевым API и вебсокетами ордербука.