#Тулзы
Поиск Mev хешей в блоках
https://www.zeromev.org/
Арби сканер
https://eigenphi.io/
Разбор транз
https://metablock.dev/tools/mev/ (иногда данные показывает не корректно, лучше перепроверять через эксплорер)
Поиск мев ботов
https://ultrasound.money/
Хехная тулза Южный парк и мемпул
https://txstreet.com/v/eth-btc
Поиск Mev хешей в блоках
https://www.zeromev.org/
Арби сканер
https://eigenphi.io/
Разбор транз
https://metablock.dev/tools/mev/ (иногда данные показывает не корректно, лучше перепроверять через эксплорер)
Поиск мев ботов
https://ultrasound.money/
Хехная тулза Южный парк и мемпул
https://txstreet.com/v/eth-btc
👍18
Собрал публичную базу данных из чата, внутренних заметок и т.д. Буду добавлять новые ресурсы, по мере обнаружения. Если вдруг у кого-то будет желание помочь в хосте базы - пишите мне @gohles, облегчите мою учесть🤣.
https://mev101diggers.notion.site/MEV-6122a1c969944ab3903c1e5bbbdfa998 (у кого с ноушн проблемы нажимайте в низу таблицы на loadmore)
https://mev101diggers.notion.site/MEV-6122a1c969944ab3903c1e5bbbdfa998 (у кого с ноушн проблемы нажимайте в низу таблицы на loadmore)
👍21
Dark forest pinned «Собрал публичную базу данных из чата, внутренних заметок и т.д. Буду добавлять новые ресурсы, по мере обнаружения. Если вдруг у кого-то будет желание помочь в хосте базы - пишите мне @gohles, облегчите мою учесть🤣. https://mev101diggers.notion.site/MEV-…»
Обгоняем Noxx!
Относительно недавно мы наткнулись на материал от товарища Noxx, а в последствии этот материал был переведен Ortomich.
В этой огромной статье автор попытался объяснить – как найти разницу в цене между LP, совершить сделку и получить некоторую прибыль, также показать как он это делает, не просто на словах, а дать некоторые алгоритмы.
Итак, автор решает задачу через максимизацию общей стоимости всех токенов в долларах, полученной после проведения всех сделок, представляя задачу как проблему выпуклой оптимизации. И все было бы не плохо, но можно было лучше, а если точнее - быстрее.
Мы провели некоторые эксперементы со скриптом, предложенным в статье от Noxx и на деле - на расчет 10 пар было затрачено 70 миллисекунд (запускали в google colab), что по-нашему мнению совершенно неконкурентноспособно. А причиной этому является необходимость каждый раз решать множество уравнений.
Как известно поиск MEV – это действительно высококонкурентная среда и победитель будет только один. Следовательно, у нас возник вопрос, как мы сможем ускорить производительность?
Мы решили использовать другой алгоритм – Дейкстры, у которого нет проблем со скоростью (около миллисекунды на выполнение в google colab на данных о 36 тикерах). Итак, вкратце, что это за Дейкстра?
Спойлер: сейчас будет немного сложно для не технической публики.
Дейкстра - это алгоритм поиска кратчайшего пути в графе. Здесь мы рассмотрим реализацию с графой в формате списка смежности и бинарной кучей, имеющей скорость (E+V)LogV, где V-количество вершин, а E-количество рёбер.
Если перевести с эльфийского языка, суть его работы заключается в том, чтобы найти кратчайший путь из начальной вершины (к примеру какой-то стейблкоин) – до другой вершины в графе, при этом каждая вершина является каким-то токеном/клином.
Усовершенствовав алгоритм, можно строить пути от одного тикера из данного нами списка до того же, или другого тикера из данного нами списка. Естественно усовершенстовать алгоритм вы должны самостоятельно🙂
Основным преимуществом данного алгоритма является практически непревзойденная скорость, однако при этом он не умеет работать с рёбрами отрицательного веса и очень чувствителен к выбору начальной вершины, что часто может привести к тому, что какие-то профитные маршруты не будут найдены.
Наш алгоритм работает за одну миллисекунду на 36 парах/тикерах, в той же среде в которой был протестирован алгоритм от Noxx.
Напомним, что алгоритм от Noxx выдал 70 миллисекунд для 10 пар. Следовательно, алгоритм Дейкстры быстрее в 70 раз и обрабатывает в 3 раза больше информации.
И как вывод…..хотя вывода не будет– все итак понятно. Ortomich’у желаем учить математику 😉
Разбор базовой Дийкстры тут
Относительно недавно мы наткнулись на материал от товарища Noxx, а в последствии этот материал был переведен Ortomich.
В этой огромной статье автор попытался объяснить – как найти разницу в цене между LP, совершить сделку и получить некоторую прибыль, также показать как он это делает, не просто на словах, а дать некоторые алгоритмы.
Итак, автор решает задачу через максимизацию общей стоимости всех токенов в долларах, полученной после проведения всех сделок, представляя задачу как проблему выпуклой оптимизации. И все было бы не плохо, но можно было лучше, а если точнее - быстрее.
Мы провели некоторые эксперементы со скриптом, предложенным в статье от Noxx и на деле - на расчет 10 пар было затрачено 70 миллисекунд (запускали в google colab), что по-нашему мнению совершенно неконкурентноспособно. А причиной этому является необходимость каждый раз решать множество уравнений.
Как известно поиск MEV – это действительно высококонкурентная среда и победитель будет только один. Следовательно, у нас возник вопрос, как мы сможем ускорить производительность?
Мы решили использовать другой алгоритм – Дейкстры, у которого нет проблем со скоростью (около миллисекунды на выполнение в google colab на данных о 36 тикерах). Итак, вкратце, что это за Дейкстра?
Спойлер: сейчас будет немного сложно для не технической публики.
Дейкстра - это алгоритм поиска кратчайшего пути в графе. Здесь мы рассмотрим реализацию с графой в формате списка смежности и бинарной кучей, имеющей скорость (E+V)LogV, где V-количество вершин, а E-количество рёбер.
Если перевести с эльфийского языка, суть его работы заключается в том, чтобы найти кратчайший путь из начальной вершины (к примеру какой-то стейблкоин) – до другой вершины в графе, при этом каждая вершина является каким-то токеном/клином.
Усовершенствовав алгоритм, можно строить пути от одного тикера из данного нами списка до того же, или другого тикера из данного нами списка. Естественно усовершенстовать алгоритм вы должны самостоятельно🙂
Основным преимуществом данного алгоритма является практически непревзойденная скорость, однако при этом он не умеет работать с рёбрами отрицательного веса и очень чувствителен к выбору начальной вершины, что часто может привести к тому, что какие-то профитные маршруты не будут найдены.
Наш алгоритм работает за одну миллисекунду на 36 парах/тикерах, в той же среде в которой был протестирован алгоритм от Noxx.
Напомним, что алгоритм от Noxx выдал 70 миллисекунд для 10 пар. Следовательно, алгоритм Дейкстры быстрее в 70 раз и обрабатывает в 3 раза больше информации.
И как вывод…..хотя вывода не будет– все итак понятно. Ortomich’у желаем учить математику 😉
Разбор базовой Дийкстры тут
🔥8❤3
Кто знает или засекал с какой частотой идёт забор timestamps у Uni v.2 для TWAP?
https://twitter.com/fintechintern/status/1579487695575060487
Твитор спэйс 12 октября 2 pm utc, The block x Hasu. Будут разговаривать за Mev. Стоит послушать. Возможно позже сделаем транскриб и перевод
Твитор спэйс 12 октября 2 pm utc, The block x Hasu. Будут разговаривать за Mev. Стоит послушать. Возможно позже сделаем транскриб и перевод
🔥11
Состояние MEV дел на Co-smosis
С момента запуска Osmosis поисковики MEV получили примерно 7 млн$ профита, при этом заплатив комиссий за транзакции на 50к$.
При том, что половину общего профита делят 5 ботов. 16% от всех транзакций на osmosis пришлись на MEV и 87% (из тех 16%) были фиктивными, что приводит к пустой трате места в блоке, высокие комиссии и т.д
Относительно недавно, кофаундер Osmosis Sunny Aggarwal дал интервью, где рассказал планы Osmosis относительно использования MEV самим Osmosis, а также поделился некоторыми мыслями относительно MEV:
1) Разбор ключевых проблем, который несет MEV для конечных пользователей сети
2) Как MEV может быть дополнительным источником прибыли для блокчейна и почему dYdX все-таки выбрали билдить свой блокчейн.
3) Концепция разделения блоков на обычную и специальную, под нужды Mev и высвобождение места в блоке
4) Кросчейн ликвидации на протоколе Mars, а также упомянули некоторые проекты, которые сейчас работают в MEV направлении, в экосистеме Cosmos.
Более подробную информацию по состоянию MEV дел на Osmosis можно посмотреть тут. Включая аккумуляцию, таблицу лидеров, последние и самые прибыльные сделки.
С момента запуска Osmosis поисковики MEV получили примерно 7 млн$ профита, при этом заплатив комиссий за транзакции на 50к$.
При том, что половину общего профита делят 5 ботов. 16% от всех транзакций на osmosis пришлись на MEV и 87% (из тех 16%) были фиктивными, что приводит к пустой трате места в блоке, высокие комиссии и т.д
Относительно недавно, кофаундер Osmosis Sunny Aggarwal дал интервью, где рассказал планы Osmosis относительно использования MEV самим Osmosis, а также поделился некоторыми мыслями относительно MEV:
1) Разбор ключевых проблем, который несет MEV для конечных пользователей сети
2) Как MEV может быть дополнительным источником прибыли для блокчейна и почему dYdX все-таки выбрали билдить свой блокчейн.
3) Концепция разделения блоков на обычную и специальную, под нужды Mev и высвобождение места в блоке
4) Кросчейн ликвидации на протоколе Mars, а также упомянули некоторые проекты, которые сейчас работают в MEV направлении, в экосистеме Cosmos.
Более подробную информацию по состоянию MEV дел на Osmosis можно посмотреть тут. Включая аккумуляцию, таблицу лидеров, последние и самые прибыльные сделки.
👍7
MEV в эпоху Proof-of-Stake ч.1
С блоком 15 537 393 Ethereum завершил переход на proof-of-stake. Если на уровне dApps все осталось более или менее без изменений, то консенсус Ethereum был полностью переработан.
Ethereum 2.0 отличается не только улучшенной безопасностью и централизацией, но и новой терминологией, которую необходимо знать при анализе данных.
В последние недели я начал копаться в данных, которые вместе производят цепочка beacon- и цепочка eth1. В большинстве случаев все казалось довольно знакомым, однако возникли совершенно новые проблемы.
MEV последние годы была широко обсуждаемой темой. В MEV игре доминировали несколько специализированных игроков, в то время как обычные пользователи могли только надеяться, что их не затронут негативные внешние эффекты.
С переходом Ethereum на Proof-of-Stake и введением Proposer-Builder-Separation (PBS) – игра была перетасована, что позволило небольшим валидаторам самим получать выгоду от MEV.
Далее мы проведем количественный анализ MEV, MEV-Boost и влияния PoS-переключения на MEV. Эта статья может послужить руководством к действию, чтобы начать копать глубже в массивах данных, которые ежедневно производит Ethereum. В этих сериях статьей мы затронем:
• Введение в MEV и MEV-Boost
• Сбор данных и предварительная обработка данных
• Анализ MEV после слияния
• Общие вводные
• Количественная оценка MEV
• Цензурирование транзакций
• Перестановка последовательности блоков
Введение в MEV.
MEV расшифровывается как Maximal Extractable Value и представляет собой стоимость, которая возникает в результате упорядочивания транзакций. Это может привести к различным стратегиям, таким как арбитраж, бэкран, фронтран и тд, которые направлены на оптимизацию (максимизацию) общего дохода на блок.
В эпоху PoW, майнеры самостоятельно определяли окончательный порядок транзакций. Это давало им потенциальные преимущества. Майнеры могли продавать место в блоке желающим или сами заниматься извлечением MEV.
В большинстве случаев за MEV-возможности конкурировали различные участники, а именно MEV-боты (поисковики/секвенсоры), которыми в основном управляли узкоспециализированные команды. Больше всего страдали мелкие участники рынка, которые не могли выдержать конкуренцию по программному и аппаратному обеспечению и, как следствие, были выброшены на обочину MEV игры более сильными и подготовленными коллегами.
Также MEV потенциально может привести к негативным внешним эффектам, например к перегрузке сети.
Более того, передача создания блоков в руки нескольких организаций, которые принимают решение о содержании блоков, открывает систему для цензурирования транзакций и атак со стороны государственных субъектов.
С блоком 15 537 393 Ethereum завершил переход на proof-of-stake. Если на уровне dApps все осталось более или менее без изменений, то консенсус Ethereum был полностью переработан.
Ethereum 2.0 отличается не только улучшенной безопасностью и централизацией, но и новой терминологией, которую необходимо знать при анализе данных.
В последние недели я начал копаться в данных, которые вместе производят цепочка beacon- и цепочка eth1. В большинстве случаев все казалось довольно знакомым, однако возникли совершенно новые проблемы.
MEV последние годы была широко обсуждаемой темой. В MEV игре доминировали несколько специализированных игроков, в то время как обычные пользователи могли только надеяться, что их не затронут негативные внешние эффекты.
С переходом Ethereum на Proof-of-Stake и введением Proposer-Builder-Separation (PBS) – игра была перетасована, что позволило небольшим валидаторам самим получать выгоду от MEV.
Далее мы проведем количественный анализ MEV, MEV-Boost и влияния PoS-переключения на MEV. Эта статья может послужить руководством к действию, чтобы начать копать глубже в массивах данных, которые ежедневно производит Ethereum. В этих сериях статьей мы затронем:
• Введение в MEV и MEV-Boost
• Сбор данных и предварительная обработка данных
• Анализ MEV после слияния
• Общие вводные
• Количественная оценка MEV
• Цензурирование транзакций
• Перестановка последовательности блоков
Введение в MEV.
MEV расшифровывается как Maximal Extractable Value и представляет собой стоимость, которая возникает в результате упорядочивания транзакций. Это может привести к различным стратегиям, таким как арбитраж, бэкран, фронтран и тд, которые направлены на оптимизацию (максимизацию) общего дохода на блок.
В эпоху PoW, майнеры самостоятельно определяли окончательный порядок транзакций. Это давало им потенциальные преимущества. Майнеры могли продавать место в блоке желающим или сами заниматься извлечением MEV.
В большинстве случаев за MEV-возможности конкурировали различные участники, а именно MEV-боты (поисковики/секвенсоры), которыми в основном управляли узкоспециализированные команды. Больше всего страдали мелкие участники рынка, которые не могли выдержать конкуренцию по программному и аппаратному обеспечению и, как следствие, были выброшены на обочину MEV игры более сильными и подготовленными коллегами.
Также MEV потенциально может привести к негативным внешним эффектам, например к перегрузке сети.
Более того, передача создания блоков в руки нескольких организаций, которые принимают решение о содержании блоков, открывает систему для цензурирования транзакций и атак со стороны государственных субъектов.
❤🔥6
MEV в эпоху Proof-of-Stake ч.2
Что такое MEV-Boost?
MEV-Boost создан компанией Flashbots и представляет собой дополнительное программное обеспечение, использующее разделение инициации и создания (Proposer-builder separation или PBS).
Валидаторы могут использовать MEV-Boost, чтобы самостоятельно идентифицировать MEV в предлагаемых ими блоках. Его цель - демократизировать процесс извлечения MEV, открыв его для обычных валидаторов и создав конкурентные рынки в блочном пространстве.
В теории, PBS призван решить централизацию в MEV, разделяя производство и предложение блоков. Валидаторы (которые в конечном итоге предлагают блок) имеют доступ к рынку блоков и выбирают те блоки, которые приносят наибольшую прибыль. Следовательно, производители блоков оказываются на конкурентном рынке, где им приходится соревноваться с себе подобными, чтобы в конечном итоге валидировать.
Этот механизм приводит к тому, что (часть) захваченного MEV переходит от создателей блоков к валидаторам. PBS помогает демократизировать наиболее прибыльный блок или MEV для любого валидатора, однако вводит новые риски, такие как централизация.
Например, представьте создателя блока B, который создал оптимизированный по доходам блок, в котором было извлечено количество Х: соответсвенно B заплатил бы до Y, в качестве вознаграждения, валидатору за то, что его выбрали.
Предполагается, что процесс торгов будет проходить как аукцион с закрытыми ставками, в результате которого участники, предложившие наивысшую ставку, должны представить предложение, близкое к реальной стоимости.
Если очень простым языком, то MEV-Boost представляет собой рынок блоков, находясь между валидатором и создателями блоков.
MEV-Boost также может быть настроен на подключение к нескольким реле которые, в свою очередь, могут подключаться к нескольким билдерам.
С другой стороны, есть поисковики, которые создают пакеты транзакций, которые в конечном итоге включаются в блок строителем.
Пакет транзакций (Bundles of transactions) - это последовательность транзакций, которые выполняются в заранее определенном порядке. Это может быть сэндвич-атака, состоящая из 3 транзакций: транзакция жертвы + фронт и бэк ран.
Технически, валидаторы могут подключиться к одному реле, даже не используя MEV-Boost: в этом случае они могут упустить возможность получить наиболее доходный блок, поскольку задача MEV-Boost - выбрать наиболее выгодный блок из всех подключенных к реле. Однако, в случае отказа реле, валидаторы будут вынуждены добывать блоки локально, используя транзакции, которые есть в mempool’e.
Одна из проблем, которая на данный момент активно обсуждается - это закрытый ордер флоу (Exclusive order flows или EOF) и их потенциальная угроза для блочного пространства.
Каждый создатель блока зависит от транзакций, которые он получает. Это означает, что чем "лучше" транзакции, к которым имеет доступ создатель блока, тем лучше конечные блоки.
Поскольку нет ничего лучше прозрачного и открытого мем-пула, включающего все транзакции, создатели блоков могут заключать приватные соглашения с третьими сторонами (которые производят транзакции с высоким профитом), чтобы получать исключительно их транзакции.
Причина, по которой создатели блоков могут пойти на это, заключается в увеличении их прибыли и репутации. Более того, создатели блоков могут заниматься манипулированием рынком, включая в него только транзакции лица X и игнорируя транзакции лица конкурента Y.
Продолжение следует...
Что такое MEV-Boost?
MEV-Boost создан компанией Flashbots и представляет собой дополнительное программное обеспечение, использующее разделение инициации и создания (Proposer-builder separation или PBS).
Валидаторы могут использовать MEV-Boost, чтобы самостоятельно идентифицировать MEV в предлагаемых ими блоках. Его цель - демократизировать процесс извлечения MEV, открыв его для обычных валидаторов и создав конкурентные рынки в блочном пространстве.
В теории, PBS призван решить централизацию в MEV, разделяя производство и предложение блоков. Валидаторы (которые в конечном итоге предлагают блок) имеют доступ к рынку блоков и выбирают те блоки, которые приносят наибольшую прибыль. Следовательно, производители блоков оказываются на конкурентном рынке, где им приходится соревноваться с себе подобными, чтобы в конечном итоге валидировать.
Этот механизм приводит к тому, что (часть) захваченного MEV переходит от создателей блоков к валидаторам. PBS помогает демократизировать наиболее прибыльный блок или MEV для любого валидатора, однако вводит новые риски, такие как централизация.
Например, представьте создателя блока B, который создал оптимизированный по доходам блок, в котором было извлечено количество Х: соответсвенно B заплатил бы до Y, в качестве вознаграждения, валидатору за то, что его выбрали.
Предполагается, что процесс торгов будет проходить как аукцион с закрытыми ставками, в результате которого участники, предложившие наивысшую ставку, должны представить предложение, близкое к реальной стоимости.
Если очень простым языком, то MEV-Boost представляет собой рынок блоков, находясь между валидатором и создателями блоков.
MEV-Boost также может быть настроен на подключение к нескольким реле которые, в свою очередь, могут подключаться к нескольким билдерам.
С другой стороны, есть поисковики, которые создают пакеты транзакций, которые в конечном итоге включаются в блок строителем.
Пакет транзакций (Bundles of transactions) - это последовательность транзакций, которые выполняются в заранее определенном порядке. Это может быть сэндвич-атака, состоящая из 3 транзакций: транзакция жертвы + фронт и бэк ран.
Технически, валидаторы могут подключиться к одному реле, даже не используя MEV-Boost: в этом случае они могут упустить возможность получить наиболее доходный блок, поскольку задача MEV-Boost - выбрать наиболее выгодный блок из всех подключенных к реле. Однако, в случае отказа реле, валидаторы будут вынуждены добывать блоки локально, используя транзакции, которые есть в mempool’e.
Одна из проблем, которая на данный момент активно обсуждается - это закрытый ордер флоу (Exclusive order flows или EOF) и их потенциальная угроза для блочного пространства.
Каждый создатель блока зависит от транзакций, которые он получает. Это означает, что чем "лучше" транзакции, к которым имеет доступ создатель блока, тем лучше конечные блоки.
Поскольку нет ничего лучше прозрачного и открытого мем-пула, включающего все транзакции, создатели блоков могут заключать приватные соглашения с третьими сторонами (которые производят транзакции с высоким профитом), чтобы получать исключительно их транзакции.
Причина, по которой создатели блоков могут пойти на это, заключается в увеличении их прибыли и репутации. Более того, создатели блоков могут заниматься манипулированием рынком, включая в него только транзакции лица X и игнорируя транзакции лица конкурента Y.
Продолжение следует...
👍16
MEV в эпоху Proof-of-Stake ч.3
Сбор данных
Прежде чем приступить к анализу MEV-Boost, мы должны определить конечный набор данных. Такие как информацию консенсус уровня (builder_publickey, proposer_payment или slotnr), а также данные экзекюшн уровеня (eth1_fee_recipient), и информацию о каждой транзакции, включенной в соответствующие блоки. Можно использовать Relay API для анализа каждого блока с момента слияния и сборе информации о валидаторе / создателе соответствующего блока. Так как сушествует несколько ретрансляторы, мы должны получить данные из всех доступных нам, чтобы получить полную картину. Актуальные ретрансляторы: flashbots, bloxroute#1, bloxroute#2, bloxroute#3, manifold, eden, blocknative
Формат: файлы .csv с информацией, полученной от Data API. Запросы могут выполняться в фоновом режиме, что позволяет пользователям поддерживать актуальную информацию о блоках с MEV-бустом. Пример
Сбор данных на уровне исполнения
Когда речь идет о данных уровня исполнения, таких как информация о транзакциях или, более конкретно, о взаимодействии контрактов, можно использовать архивную ноду для доступа к необходимым данным. Более того, использование библиотеки web3 + Infura может быть наиболее простым способом, однако Infura не поддерживает исторические данные по контрактам без платной подписки.
Другой вариант это - Ethereum-datafarm. Это инструмент командной строки, написанный на Python, который использует Etherscan API для разбора журналов контрактов непосредственно в файлы .csv. Для этого не требуется ничего, кроме бесплатного ключа API Etherscan (в имит по запросам не упрешся).
С помошью Ethereum-datafarm мы сможем собрать интересуюшие нас данные по контракту протокола А. Например получить список всех хэшей транзакций с момента мерджа, в которых было зафиксировано событие пополнения или снятия средств по протоколу А (Transfer для $Atoken). Это позволит нам узнать, какие ретрансляторы и создатели включают эти транзакции, а какие цензурируют сеть, активно игнорируя их. Дополнительную информацию об использовании Ethereum-datafarm см. в этом руководстве.
Чтобы собрать информацию о ревардах за блок, мы снова используем Etherscan API. Это можно сделать и с помощью Infura, но это требует большого количества запросов, поскольку для определения общего вознаграждения блока необходимо запросить каждую транзакцию в блоке. К сожалению, такая информация недоступна непосредственно в блоке. Для этого пришлось бы агрегировать gas_used*gas_price для каждой транзакции в данном блоке, а затем вычесть базовый берн ревард (EIP-1559). Пример
Далее мы используем Web3.py вместе с конечной точкой RPC Infura для получения информации о блоках. Основная цель - разделение платежей от участников на MEV и транзакционные сборы, чтобы определить теоретический MEV за блок.
Сбор данных
Прежде чем приступить к анализу MEV-Boost, мы должны определить конечный набор данных. Такие как информацию консенсус уровня (builder_publickey, proposer_payment или slotnr), а также данные экзекюшн уровеня (eth1_fee_recipient), и информацию о каждой транзакции, включенной в соответствующие блоки. Можно использовать Relay API для анализа каждого блока с момента слияния и сборе информации о валидаторе / создателе соответствующего блока. Так как сушествует несколько ретрансляторы, мы должны получить данные из всех доступных нам, чтобы получить полную картину. Актуальные ретрансляторы: flashbots, bloxroute#1, bloxroute#2, bloxroute#3, manifold, eden, blocknative
Формат: файлы .csv с информацией, полученной от Data API. Запросы могут выполняться в фоновом режиме, что позволяет пользователям поддерживать актуальную информацию о блоках с MEV-бустом. Пример
Сбор данных на уровне исполнения
Когда речь идет о данных уровня исполнения, таких как информация о транзакциях или, более конкретно, о взаимодействии контрактов, можно использовать архивную ноду для доступа к необходимым данным. Более того, использование библиотеки web3 + Infura может быть наиболее простым способом, однако Infura не поддерживает исторические данные по контрактам без платной подписки.
Другой вариант это - Ethereum-datafarm. Это инструмент командной строки, написанный на Python, который использует Etherscan API для разбора журналов контрактов непосредственно в файлы .csv. Для этого не требуется ничего, кроме бесплатного ключа API Etherscan (в имит по запросам не упрешся).
С помошью Ethereum-datafarm мы сможем собрать интересуюшие нас данные по контракту протокола А. Например получить список всех хэшей транзакций с момента мерджа, в которых было зафиксировано событие пополнения или снятия средств по протоколу А (Transfer для $Atoken). Это позволит нам узнать, какие ретрансляторы и создатели включают эти транзакции, а какие цензурируют сеть, активно игнорируя их. Дополнительную информацию об использовании Ethereum-datafarm см. в этом руководстве.
Чтобы собрать информацию о ревардах за блок, мы снова используем Etherscan API. Это можно сделать и с помощью Infura, но это требует большого количества запросов, поскольку для определения общего вознаграждения блока необходимо запросить каждую транзакцию в блоке. К сожалению, такая информация недоступна непосредственно в блоке. Для этого пришлось бы агрегировать gas_used*gas_price для каждой транзакции в данном блоке, а затем вычесть базовый берн ревард (EIP-1559). Пример
Далее мы используем Web3.py вместе с конечной точкой RPC Infura для получения информации о блоках. Основная цель - разделение платежей от участников на MEV и транзакционные сборы, чтобы определить теоретический MEV за блок.
🔥9
25 января всем известный агрегатор 1inch представил свое обновление под названием Fusion.
Этот мод должен облегчить пользовательский опыт, а также сэкономить деньги пользователей.
Fusion-мод, частично основанный на уже существующих технологиях (1inch Limit Order Protocol, 1inch Aggregation Protocol, 1inch Swap Engine) – позволяет пользователям размещать свои ордера, с указанной ценой и временным диапазоном, не платя газ. А исполнением этих ордеров занимаются, так называемые, резольверы или маркетмейкеры.
Теперь углубимся в систему исполнения ордеров.
Маркетмейкеры (резольверы) распределены по уровням и получают доступ к потоку ордеров, один за другим (в зависимости от количества застейканных ими нативных токенов 1inch, соответственно, чем больше токенов у маркетмейкера, тем быстрее он получит доступ к ордеру, конечно ещё есть вопросы как они ранжируються, так как эта информация закрыта).
Это означает, что в течение первой минуты после размещения ордера только ОДИН маркетмейкер может замэтчить и исполнить ордер. Чтобы предотвратить извлечение стоимости первым маркетмейкером, текущий ордер повторяет кривую цены в стиле голландского аукциона, начиная с высокой (выше рыночной) цены и линейно снижаясь с течением времени (3-10 минут), пока цена в конечном итоге не достигает цены достаточно низкой, чтобы ордер мог быть исполнен.
Также нужно учитывать, что конечный пользователь (трейдер) платит комиссию в токенах, которые используются в ордере вместо ETH за газ и не несут никаких дополнительных затрат.
А теперь из минусов:
так как маркетмейкеры пытаются исполнить ордер по очереди, это увеличивает время ожидания исполнения, и если пользователь действительно хочет совершить обмен по справедливой цене, то ему нужно установить аукционный метод в интерфейсе, который увеличит время ожидания.
Следующий минус – фьюжн мод работает очень ограниченно, по большей части только на крупных парах, и на каких-то более менее экзотических парах уже все.
Также, чтобы получить справедливую цену и быстрое исполнение – легче использовать обычный свап и заплатить за газ, так как очень часто фьюжн мод обходится дороже, чем обычный свап.
А также, фьюжн мод у всех пользователей выставлен по дефолту, в целом – это очень странный UI/UX, плюс из-за аукционного метода свапы через фьюжн мод не позволяют выставить допустимое проскальзывание.
Как итог – непонятно для чего этот мод нужен, когда есть эта же лимитка от того же 1inch.
Этот мод должен облегчить пользовательский опыт, а также сэкономить деньги пользователей.
Fusion-мод, частично основанный на уже существующих технологиях (1inch Limit Order Protocol, 1inch Aggregation Protocol, 1inch Swap Engine) – позволяет пользователям размещать свои ордера, с указанной ценой и временным диапазоном, не платя газ. А исполнением этих ордеров занимаются, так называемые, резольверы или маркетмейкеры.
Теперь углубимся в систему исполнения ордеров.
Маркетмейкеры (резольверы) распределены по уровням и получают доступ к потоку ордеров, один за другим (в зависимости от количества застейканных ими нативных токенов 1inch, соответственно, чем больше токенов у маркетмейкера, тем быстрее он получит доступ к ордеру, конечно ещё есть вопросы как они ранжируються, так как эта информация закрыта).
Это означает, что в течение первой минуты после размещения ордера только ОДИН маркетмейкер может замэтчить и исполнить ордер. Чтобы предотвратить извлечение стоимости первым маркетмейкером, текущий ордер повторяет кривую цены в стиле голландского аукциона, начиная с высокой (выше рыночной) цены и линейно снижаясь с течением времени (3-10 минут), пока цена в конечном итоге не достигает цены достаточно низкой, чтобы ордер мог быть исполнен.
Также нужно учитывать, что конечный пользователь (трейдер) платит комиссию в токенах, которые используются в ордере вместо ETH за газ и не несут никаких дополнительных затрат.
А теперь из минусов:
так как маркетмейкеры пытаются исполнить ордер по очереди, это увеличивает время ожидания исполнения, и если пользователь действительно хочет совершить обмен по справедливой цене, то ему нужно установить аукционный метод в интерфейсе, который увеличит время ожидания.
Следующий минус – фьюжн мод работает очень ограниченно, по большей части только на крупных парах, и на каких-то более менее экзотических парах уже все.
Также, чтобы получить справедливую цену и быстрое исполнение – легче использовать обычный свап и заплатить за газ, так как очень часто фьюжн мод обходится дороже, чем обычный свап.
А также, фьюжн мод у всех пользователей выставлен по дефолту, в целом – это очень странный UI/UX, плюс из-за аукционного метода свапы через фьюжн мод не позволяют выставить допустимое проскальзывание.
Как итог – непонятно для чего этот мод нужен, когда есть эта же лимитка от того же 1inch.
👍4☃2🤯1🌚1
https://quantpedia.com если у кого-то имеется подписка или планирует покупать, есть предложение пошейрить оплату
Пишите @isop9
Пишите @isop9