Комментарии 5
а есть возможность делать отдельный mempool для доверенных участников?
(т.е. чтобы если транзакция прошла - то она была в общем блокчейне, но чтобы исключить ботов. Понятно, что так меньше прибыли для майнера, но если это майнер биржи\торговой площадки - может недополученная прибыль не будет настолько большой?)
Это в принципе уже частично так и работает. Mempool нельзя рассматривать, как общую буферную зону для всех транзакций перед тем, как они попадут в блокчейн. Каждая нода настраивает свои правила для мемпула. А после попадания транакции в мемпул ноды должна происходить своего рода синхронизация с другими нодами сети. Получается, что может быть некая абстрактная нода, которая первой получила транзакцию в свой mempool и не распространила ее на остальную сеть. Более того все ноды могут иметь значительно отличные мемпулы из-за задержек сети например.
Поэтому, я думаю, технически ограничить доверенных участников внутри сети реально. На сколько это сложно и практикуется ли в таком виде я к сожалению не подскажу. Если кто-то знает пишите в комментарии.
Я думаю, что для подобной задачи, больше подходит приватный блокчейн с доверенными узлами и менее децентрализованным консенсусом. Например, proof of authority. И видимо mempool должен быть закрытым, чтобы боты не могли считывать транзакции на ожидании и успевать манипулировать ценой.
По поводу Front-running
Внутри транзакции указывается slippage tolerance ? Если нет, то как проводится эта транзакция если бот видит нужную транзакцию, посылает свою с большим MEV , но потом транзакция жертвы отменяется из за slippage tolerance.
Почему я спрашиваю , на uniswap понажимал , и вижу что проверка slippage tolerance просто перед транзакцией стучится на какой то API и возвращается ответ. Тоесть работает только на клиенте?!
По поводу slippage на uniswap. Он проверяется не только на клиенте. Если посмотреть смарт-контракты uniswap v2, то там используется аргумент amountOutMin(минимально желаемая сумма пользователем на выходе после обмена). Этот аргумент как раз и регулирует проскальзывание. Если фактическая сумма будет меньше, то транзакция откатится.
В контрактах unsiwap v3 посложнее, там подобный аргумент уже упакован в дополнительную структуру ExactInputSingleParams например.
По поводу бота, что, если он послал транзакцию, а транзакция жертвы не прошла. Я не большой специалист в реализации подобных ботов, но я думаю, что это риск на который бот идет для совершения своих транзакций. Также я думаю для минимизации этого риска, в теории, бот может следить за транзакцией жертвы и в случае необходимости отменить свою транзакцию, но только пока она в статусе pending. Если она исполнится отменить ее уже нельзя будет. Я отменами не занимался, но знаю, что например кошелек metamask и другие позволяют это делать, а значит и техническая возможность этого есть.
Крутая статья, спасибо!
Подводные камни децентрализованной торговли