Дэвид «JoelKatz» Шварц предложил план резервирования транзакций для XRP Ledger после новых заявлений о том, что пользователи по-прежнему могут столкнуться с атаками типа front-running и сэндвич-атаками на платежи, пересечение ордеров, DEX-сделки и AMM-свапы.
Дискуссия началась после того, как XRPresso заявила, что некоторые участники могут просматривать ожидающие транзакции до закрытия реестра и использовать эту информацию для целенаправленных сделок.
«На XRPL продолжается серьёзная проблема front-running, которая ставит обычных пользователей в невыгодное положение.» XRPresso сообщила, что валидаторы и хорошо подключённые узлы могут просматривать транзакции в очереди предварительной валидации, а затем отправлять собственные транзакции для получения более выгодной позиции в итоговом порядке реестра.
XRPresso отметила, что проблема наиболее актуальна для пользователей, торгующих через кошельки и dApp. Согласно публикации, итоговый порядок внутри каждого реестра следует известному детерминированному процессу, а повторные отправки могут повысить вероятность оказаться рядом с целевой сделкой. Это может ухудшить проскальзывание для исходного трейдера в случае успеха сэндвич-стратегии.
«По причинам, которые я объяснил, меня не слишком беспокоит эта проблема.» Шварц написал, что проблема всё же заслуживает практического ответа. Затем он предложил схему резервирования транзакций, которая позволила бы раскрытой транзакции выполняться раньше любой транзакции, сформированной после того, как она стала видимой.
План предусматривает добавление нового объекта реестра под названием ReservedTxns. Этот объект будет хранить порядковый номер реестра и массив ID транзакций. Новая транзакция TxnReserve позволит пользователю зарезервировать слот для транзакции в будущем реестре при условии, что запрос соответствует правилам комиссии, сроков и исполнения.
Шварц сказал, что резервирование должно стоить как минимум вдвое больше обычной комиссии за транзакцию. Целевой реестр должен быть больше текущего и не более чем на 16 реестров впереди. Каждый зарезервированный объект будет содержать менее 32 ID транзакций, если только проект впоследствии не расширит этот лимит.
Согласно предложению, зарезервированная транзакция будет транслироваться в момент, близкий к тому, когда становятся известны предложения предыдущего реестра. Шварц сказал, что программное обеспечение XRPL может добавить функцию удержания таких транзакций и их высвобождения только при выполнении этого условия. Транзакция также должна устанавливать свой последний действительный реестр как реестр, в котором она ожидается к исполнению.
Когда этот реестр выполняется, сеть сначала проверяет, существует ли объект ReservedTxns для данного порядкового номера реестра. Если он существует, сеть выполняет перечисленные транзакции из набора консенсуса раньше остальных транзакций. Затем она удаляет их из набора, чтобы предотвратить повторное выполнение, и удаляет объект резервирования.
Документация XRPL гласит, что каноническое упорядочивание создано детерминированным, эффективным и устойчивым к манипуляциям. Документация по DEX также указывает, что порядок транзакций разработан для противодействия front-running, поскольку сделки исполняются при закрытии нового реестра. Однако документация по алгоритмической торговле XRPL отмечает, что front-running затруднён, но не невозможен.
Это происходит в то время, когда разработчики XRPL продолжают расширять DeFi-стек сети. Фонд XRPL недавно предложил AMM Swappable Curves — черновое обновление, которое добавит опции StableSwap и концентрированной ликвидности к нативному AMM. XRPL также готовит нативные инструменты кредитования и программируемого эскроу.
Эти обновления могут принести больше торговой, кредитной и расчётной активности на блокчейне в XRPL. Недавние публикации также показали институциональные сценарии использования, включая токенизированный расчёт с казначейскими облигациями с участием Ripple и JPMorgan. По мере роста активности упорядочивание транзакций и видимость ожидающих сделок могут привлечь больше внимания со стороны разработчиков, трейдеров и валидаторов.
Шварц также затронул возможные риски атак типа «отказ в обслуживании». Он сказал, что злоумышленник может попытаться заполнить слоты резервирования в нескольких реестрах, однако растущие комиссии сделают это затратным. В одном из примеров комиссии начнут расти после заполнения 16 слотов и могут достичь нескольких базовых резервов при около 30 слотах. Предложение пока не является официальной поправкой, но даёт сообществу XRPL чёткий технический путь для рассмотрения.

