Мне кажется, что воз все-таки двигается. С 2012 года и обменники децентрализованные подъехали во главе с Uniswap(c новой моделью AMM), на базе них агрегаторы появились(например 1INCH), кошельки развивались всякие разные, которым сейчас нету счета(metamask в 2016 году только появился), лендинг протоколы крупные(Aave, Compound, MakerDao со своим стейблкоином), сколько всяких блокчейнов появилось(и l2 и самостоятельные, не факт что нужные, но все же), да даже бум нфт и маркетплейсов это тоже определенная веха развития. В общем прогресс есть, он не нулевой, но наверное все-таки хотелось бы конечно чего-то большего для Web3 и не только вокруг крипты)
По поводу slippage на uniswap. Он проверяется не только на клиенте. Если посмотреть смарт-контракты uniswap v2, то там используется аргумент amountOutMin(минимально желаемая сумма пользователем на выходе после обмена). Этот аргумент как раз и регулирует проскальзывание. Если фактическая сумма будет меньше, то транзакция откатится. В контрактах unsiwap v3 посложнее, там подобный аргумент уже упакован в дополнительную структуру ExactInputSingleParams например.
По поводу бота, что, если он послал транзакцию, а транзакция жертвы не прошла. Я не большой специалист в реализации подобных ботов, но я думаю, что это риск на который бот идет для совершения своих транзакций. Также я думаю для минимизации этого риска, в теории, бот может следить за транзакцией жертвы и в случае необходимости отменить свою транзакцию, но только пока она в статусе pending. Если она исполнится отменить ее уже нельзя будет. Я отменами не занимался, но знаю, что например кошелек metamask и другие позволяют это делать, а значит и техническая возможность этого есть.
1) Тут вы правы, не сходится, но это только потому что я округлил до 9%. На самом деле там получается не ровно 9%. 1500 / 16500 = 0.0909090909. И тогда получается все верно и без потерь.
2) здесь все верно. При добавлении ликвидности к уже существующей паре придется сохранять первоначально заданное соотношение токенов. Модно добавлять на любую сумму, но сохранив соотношение. В данном примере это 1500 1inch к 1 usdt.
На цену можно повлиять только изменив соотношение токенов в паре. А для этого нужно делать обмен одного токена на другой(swap).
Спасибо за отзыв! В планах есть написание подобного обзора по агрегаторам DEX, но боюсь, что это может быть не скоро, зависит от загрузки по проектам. В любом случае раньше хабра это появится в репозитории.
Это в принципе уже частично так и работает. Mempool нельзя рассматривать, как общую буферную зону для всех транзакций перед тем, как они попадут в блокчейн. Каждая нода настраивает свои правила для мемпула. А после попадания транакции в мемпул ноды должна происходить своего рода синхронизация с другими нодами сети. Получается, что может быть некая абстрактная нода, которая первой получила транзакцию в свой mempool и не распространила ее на остальную сеть. Более того все ноды могут иметь значительно отличные мемпулы из-за задержек сети например.
Поэтому, я думаю, технически ограничить доверенных участников внутри сети реально. На сколько это сложно и практикуется ли в таком виде я к сожалению не подскажу. Если кто-то знает пишите в комментарии.
Я думаю, что для подобной задачи, больше подходит приватный блокчейн с доверенными узлами и менее децентрализованным консенсусом. Например, proof of authority. И видимо mempool должен быть закрытым, чтобы боты не могли считывать транзакции на ожидании и успевать манипулировать ценой.
Сам инструмент orderbook технически сложнее, поэтому вся система будет сложнее, чем AMM. Необходимо решать вопросы с ценой сделок(оплата за газ), сопоставление ордеров, реализовывать дополнительные инструменты в виде отложенных ордеров различных типов и тому подобное. Без этого сложно представить биржу на базе orderbook. Особенности блокчейна конечно накладывают свои ограничения, не без этого. Но решение на базе orderbook есть, например биржа dydx. Она была запущена в 2019. Поэтому я думаю немного не правильно сказать, что идея dex на orderbook плохая, она просто сложнее в реализации. Однако она довольна интересна для пользователя.
Как одно из решение да, ордера остаются навечно. Альтернативно можно удалять ордера, тем самым освобождая storage и даже получать небольшую компенсацию за удаление в виде частичного рефанда газа.
Этот вопрос открытый) Решение в лоб - это гибридное решение, когда часть логики выносится off-chain, а в блокчейн записываются только результирующие транзакции. Решение сложнее - это использование layer 2 блокчейна для проведения более дешевых промежуточных транзакций и с записью результирующей в основную сеть. Но мне сложно сказать на сколько второе решение жизнеспособно)
Если полностью on-chain DEX на orderbook разрабатывать, то да, хранить все ордера нужно будет внутри сети. На счет распухнет в разы, я не думаю, что с точки зрения всей цепочки блоков такая биржа сильно повлияет на увеличение размеров блокчейна. Но подобное решение точно будет требовать больше места для хранения данных, чем DEX на AMM.
Это очень хороший вопрос, спасибо, что подсветили. Здесь, для простоты понимания операций и работы AMM я довольно грубо округлил значения 91 и 76(после первого и второго обмена) до целого. На самом деле мы получаем дробные числа и если не делать округления, то по исходу двух обменов в пуле останется не 833 токена Y, а 833.333333333. Возьмем это значение и подставим в формулу 833.333333333(токена Y) × 1200(токена X) = 1000000. Таким образом постоянная K сохранена.
Прекрасная статья! Узнал много новых инструментов! Мне интересно на сколько популярное решение BUIDLer by Etherspot для абстракции аккаунта? Есть уже примеры использования на боевых проектах?
Мне кажется, что воз все-таки двигается. С 2012 года и обменники децентрализованные подъехали во главе с Uniswap(c новой моделью AMM), на базе них агрегаторы появились(например 1INCH), кошельки развивались всякие разные, которым сейчас нету счета(metamask в 2016 году только появился), лендинг протоколы крупные(Aave, Compound, MakerDao со своим стейблкоином), сколько всяких блокчейнов появилось(и l2 и самостоятельные, не факт что нужные, но все же), да даже бум нфт и маркетплейсов это тоже определенная веха развития. В общем прогресс есть, он не нулевой, но наверное все-таки хотелось бы конечно чего-то большего для Web3 и не только вокруг крипты)
По поводу slippage на uniswap. Он проверяется не только на клиенте. Если посмотреть смарт-контракты uniswap v2, то там используется аргумент amountOutMin(минимально желаемая сумма пользователем на выходе после обмена). Этот аргумент как раз и регулирует проскальзывание. Если фактическая сумма будет меньше, то транзакция откатится.
В контрактах unsiwap v3 посложнее, там подобный аргумент уже упакован в дополнительную структуру ExactInputSingleParams например.
По поводу бота, что, если он послал транзакцию, а транзакция жертвы не прошла. Я не большой специалист в реализации подобных ботов, но я думаю, что это риск на который бот идет для совершения своих транзакций. Также я думаю для минимизации этого риска, в теории, бот может следить за транзакцией жертвы и в случае необходимости отменить свою транзакцию, но только пока она в статусе pending. Если она исполнится отменить ее уже нельзя будет. Я отменами не занимался, но знаю, что например кошелек metamask и другие позволяют это делать, а значит и техническая возможность этого есть.
В стандартах токенов есть опечатка. Не взаимозаменяемый токен описан erc-721 стандартом
1) Тут вы правы, не сходится, но это только потому что я округлил до 9%. На самом деле там получается не ровно 9%. 1500 / 16500 = 0.0909090909. И тогда получается все верно и без потерь.
2) здесь все верно. При добавлении ликвидности к уже существующей паре придется сохранять первоначально заданное соотношение токенов. Модно добавлять на любую сумму, но сохранив соотношение. В данном примере это 1500 1inch к 1 usdt.
На цену можно повлиять только изменив соотношение токенов в паре. А для этого нужно делать обмен одного токена на другой(swap).
Спасибо за отзыв! В планах есть написание подобного обзора по агрегаторам DEX, но боюсь, что это может быть не скоро, зависит от загрузки по проектам. В любом случае раньше хабра это появится в репозитории.
Что за нюанс? Расскажите для непосвященных:)
Это в принципе уже частично так и работает. Mempool нельзя рассматривать, как общую буферную зону для всех транзакций перед тем, как они попадут в блокчейн. Каждая нода настраивает свои правила для мемпула. А после попадания транакции в мемпул ноды должна происходить своего рода синхронизация с другими нодами сети. Получается, что может быть некая абстрактная нода, которая первой получила транзакцию в свой mempool и не распространила ее на остальную сеть. Более того все ноды могут иметь значительно отличные мемпулы из-за задержек сети например.
Поэтому, я думаю, технически ограничить доверенных участников внутри сети реально. На сколько это сложно и практикуется ли в таком виде я к сожалению не подскажу. Если кто-то знает пишите в комментарии.
Я думаю, что для подобной задачи, больше подходит приватный блокчейн с доверенными узлами и менее децентрализованным консенсусом. Например, proof of authority. И видимо mempool должен быть закрытым, чтобы боты не могли считывать транзакции на ожидании и успевать манипулировать ценой.
Сам инструмент orderbook технически сложнее, поэтому вся система будет сложнее, чем AMM. Необходимо решать вопросы с ценой сделок(оплата за газ), сопоставление ордеров, реализовывать дополнительные инструменты в виде отложенных ордеров различных типов и тому подобное. Без этого сложно представить биржу на базе orderbook. Особенности блокчейна конечно накладывают свои ограничения, не без этого. Но решение на базе orderbook есть, например биржа dydx. Она была запущена в 2019. Поэтому я думаю немного не правильно сказать, что идея dex на orderbook плохая, она просто сложнее в реализации. Однако она довольна интересна для пользователя.
Как одно из решение да, ордера остаются навечно. Альтернативно можно удалять ордера, тем самым освобождая storage и даже получать небольшую компенсацию за удаление в виде частичного рефанда газа.
Этот вопрос открытый) Решение в лоб - это гибридное решение, когда часть логики выносится off-chain, а в блокчейн записываются только результирующие транзакции. Решение сложнее - это использование layer 2 блокчейна для проведения более дешевых промежуточных транзакций и с записью результирующей в основную сеть. Но мне сложно сказать на сколько второе решение жизнеспособно)
Если полностью on-chain DEX на orderbook разрабатывать, то да, хранить все ордера нужно будет внутри сети. На счет распухнет в разы, я не думаю, что с точки зрения всей цепочки блоков такая биржа сильно повлияет на увеличение размеров блокчейна. Но подобное решение точно будет требовать больше места для хранения данных, чем DEX на AMM.
Это очень хороший вопрос, спасибо, что подсветили. Здесь, для простоты понимания операций и работы AMM я довольно грубо округлил значения 91 и 76(после первого и второго обмена) до целого. На самом деле мы получаем дробные числа и если не делать округления, то по исходу двух обменов в пуле останется не 833 токена Y, а 833.333333333. Возьмем это значение и подставим в формулу 833.333333333(токена Y) × 1200(токена X) = 1000000. Таким образом постоянная K сохранена.
Прекрасная статья! Узнал много новых инструментов! Мне интересно на сколько популярное решение BUIDLer by Etherspot для абстракции аккаунта? Есть уже примеры использования на боевых проектах?