Чем я занимался 2 месяца [part 2]

Как примерно работает моя логика? В первую очередь софт хранит все действия которые были выполнены на кошельке. К примеру, минт NFT X. Это уникальное действие, которое можно сделать 1 раз. После того как софт сминтил NFT - он записал это в БД. Если софт вылетел и вы заново его запустили - он больше не будет минтить NFT X он уже знает что для этого кошелька он её заминтил.

И это проявляется во всем. Софт сам генерирует задачи для каждого кошелька на основе действий, которые он уже выполнял, он понимает что не делал бридж - он запланирует это действие на кошельке.

Лично я прошу указать лишь действия которые нужно будет сделать и количество транзакций. Расчеты сумм происходят непосредственно внутри софта, генерация задач, назначение даты и времени. Для набива объемов нужно указать к примеру только сумму какую вывести с биржи и какой объем набить в $.

Софт не будет в продаже (или будет или он нахуй никому не нужен), но пока не будет

Почему cli-интерфейсы это хорошо

Давно хотел уйти от нескольких исполнительных файлов по типу main.py \ withdrawal.py к более удобному формату. И cli-интерфейсы мне помогли. Мы не заставляем пользователя искать исполняемые файлы, запускать их, вместо этого они могут просто в терминале ввести подходящую команду.

Coinbase wallet moment

Для UI выбрал Сoinbase wallet, поскольку его проще автоматизировать нежели Metamask с его защитами. И вот значит все вообще отлично, все уже написано.

Пытаюсь в конце подписать транзакцию для бриджа 7$ (на балансе 20$) и в момент подписи вылезает ошибка. 10 раз руками пересоздаю транзакцию и с 10 раза мне дает подписать транзакцию.

Насколько нужно быть даунами, чтобы во-первых криво рассчитывать газ, во-вторых запрещать пользователю отправлять транзакцию с любым газом. Помимо этого отредактировать газ нельзя, только отменить транзакцию.

Это настолько сюр, что вообще пиздец. Вывод: не юзайте Сoinbase wallet

Оптимизация запросов к блокчейну

Тема на самом деле интересная. Почти в каждой сети существует multicall-контракты, которые уже внутри блокчейна делают нужные вам запросы.

Это выглядит примерно следующем образом:
1. Мы передаем в multicall-контракт список контрактов и функции (а так же их аргументы)
2. Внутри блокчейна multicall собирает нужную инфу и возвращает в виде массива

Тем самым одним запросом мы получаем дохуя много данных. Ответ выглядит примерно так:

[
{
"status": true,
"data": {"возвращаемые данные функции"},
},
{
"status": true,
"data": {"возвращаемые данные функции"},
},
]

Почему юзать multicall - тру?
Такие запросы значительно разгрузят ноду, к тому же вы не будете упираться в рейт лимиты, я уже не говорю о скорости обработки таких запросов.

Как это можно использовать?
Тут вынужден разочаровать - такие контракты не изменяют состояние блокчейна, а значит мы можем вызывать только .call (get-запросы). Я думаю каждый сам поймет как это можно адаптировать под собственные задачи, вот парочку: получать балансы токенов для нескольких сотен/тысяч кошельков (либо балансы нескольких тысяч токенов для кошелька), чекать пулы ликвидности сразу в нескольких дексах для тысяч токенов и т.д.

Большинство агрегаторов, DeFi-дашбордов используют multicall-контракты. Примеры как работать с такими контрактам есть в этой статье.

Почему вы до сих пор неправильно используете getAmountOut и slippage?

Мне часто скидывают паблик/приватные скрипт на ресерч и я ни разу не увидел правильного использования getAmountOut. Это особенно актуально сейчас, когда в каждом софте полно мусорных дексов, с нулевыми пулами.

Вот пример транзакции, где произошел скам-свап 0.1 $ETH на 26$ стейбла. Я думаю многие понимают откуда берется amountOutMin (как правило значение получается коллом функции getAmountOut). Основная проблема в том, что кодеры сами придумали что значение должно возращаться только по актуальной стоимости. Хотя это логически невозможно, функция просто возвращает сумму согласно текущей ликвидности.

Если вы захотите обменять 1 $ETH на 2000 $USDT, а ликвидности нет, то при запросе getAmountOut вам не вернется False, вам просто вернется сумма, к примеру 1000 $USDT и все, дальше большинство софтов сделает обмен и потеряет 1к баксов.

Как реализовать функцию правильно?

Одно из решений это сравнивать цену с API (пример: coingecko). Я думаю с реализацией проблем не возникнет. Слипаж тут нужно накидывать на цену с coingecko и сравнивать цены.

Если вы любите стабильность и делаете двойные свапы, то можете сравнивать значения до и после свапов. Вот вам пример. Мы сначала узнаем сколько мы получим токена_2 (пусть будет K) при обмене N количества токена_1, затем узнаем сколько мы получим токена_1(пусть будет X) при обмене K количества токена_2. И вот тут только мы накидываем к X слиппаж и сравниваем X с начальным количеством N токена_1.

Я думаю разберетесь, всем DYOR

Пора поделиться новостями чем я занимался последние 4 месяца

В июле, после отдыха, я начал планировать софт под ZkSync. Хотелось сделать что-то годное, ведь на текущий момент объективно из всех софтов выделяется только софт от Leo и его команды. Мне хотелось именно задать планку, использовать более сложные решения (БД, UI)

В августе, когда я приступил к написанию, я начал понимать что моих знаний в программировании с опытом в полгода вообще не хватает. Я нашел на аутсорсе senior-кодера и мы начали сотрудничать, искать пути для реализации моих идей. Мне хотелось создать очень плотный, универсальный шаблон для софта, максимально отделить web3 часть от шаблона и в итоге под новые блокчейны кодить только web3, параллельно усиливая шаблон. В итоге около 2х недель я рисовал блок-схемы как это должно было работать

В сентябре, мы закончили с основной работой (большую часть писал senior), далее в процессе тестов я уже сам переписал примерно 40% кода, т.к. либо находил лучшее решение, либо там было много ошибок. К этому моменту шаблон состоял из UI и базы данных, а так же часть логики была зашита уже в шаблон.

К октябрю меня уже окончательно заебал ZkSync, софт хотелось переписать, т.к. к этому времени я значительно апнулся в программировании и те идеи что я видел в августе, казалось все можно было улучшить/обновить. Здесь же я решил перенести софт полностью в UI и пилить сразу под Scroll, проект свежий, не так много контрактов и удобно тестить софт.

И вот мы потихоньку приходим к тому, что мне уже нравится и я хотел бы этим поделиться.

soon...

Дизайн за 100$ VS 500$

Написал статью о моем опыте работы с дизайнерами. В статье вы найдете:

✔️ Как я планировал потратить неделю на дизайн, а потратил месяц
✔️ Сравнение опыта работы с разными дизайнерами (+ скриншоты)
✔️ Как я заплатил 50$ за 1 страницу, где по итогу внесли 3 правки

И наконец как dsgn.harmony смог спасти положение и со своей командой отрисовать что-то нереальное.

В общем думаю будет интересно...

LayerZero

После последних новостей стало интересно что с моими акками, на которых я не делал ончейн-активностей последние 3 месяца. Сейчас основной процент аккаунтов не входят даже в лям. (понятно что чекеры тема субъективная и не факт что мультипликаторы будут такими, но все же)

Меня сильно напрягла эта тема, поскольку на текущий момент в L0 инвестировал больше 20к$ и крайне не хотелось бы оказаться в числе побритых, поэтому решил заинвестить еще 5к$ и до марта загнать акки в 600-800к ранги.

Последние полторы недели переписывал софт для прогона объемов, чтобы прогнать на аккаунтах новые сети. В целом получилось имбово, удалось реализовать:
1. Симуляции транзакций для расчета необходимых сумм
для более точных расчетов необходимого кол-ва нативок

2. 4 возможных варианта пополнения сеть нативками:
докупка за USDC/USDT, вывод с бирж, бридж ETH через Stargate, бридж через Merkly

3. Полный круг с OKX
вывод, обратный депозит стейблов

4. Новый генератор машрутов, который постоянно меняет маршруты стейблов, дабы пути не были одинаковыми

Помимо этого сделал минимальную БД для хранения состояния софта на случай, когда софт стопается из-за ошибки/вылетает/комп ребутается и т.п., при повторном запуске он продолжает с последнего места.

В целом меня радует что мой текущий уровень позволяет делать настолько сложные софты под web3.

Кстати, для повторных активностей еще летом я написал софт.

Вы указываете количество действий на каждом кошельке и в течение какого времени софт должен выполнить действия (к примеру в течение 2 недель). Далее софт раскидывает timestamp для каждого кошелька и ждет ближайшего.

В назначенное время софт берет пул задач и поочерёдно проверяет/пытается сделать, пока не сделает указанное количество действий.

Это удобно, поскольку пул задач в основном копеечный и состоит из легкий действий: найти стейблы и забриджить через stargate, найти и забриджить BTC.b, купить, бридж в/из core, testnet и т.д.

Каждое действие можно настроить, указать сети, убрать из пула.

Его до нового года тоже хочу обновить, расширить пул задач и переделать логику.

В целом для дешевых повторных активностей пойдет, задачи везде разные, выполняются в разные дни/время.

Не что я потратил 2 дня - Notcoin

В целом я с асинкой в принципе не работал, поэтому было сложно вдуплить что к чему. Переписал софт nazavod'a, т.к. очень накладно было слать клики даже с 300 аккаунтов, Cloudfare палил и блочил половину запросов, пытался юзать Semaphore, но я плохо вообще понял логику, поэтому не срослось.

Сначала я полностью поменял логику, добавил прокачку аккаунта с 0 (до покупки автокликера), затем добавил клейм с бота токенов каждые 8-12 часов. Логика позволила разгрузить запросы и теперь уверен что 1000 аккаунтов софт точно сможет держать. Дополнительно кстати клейм ревардов за лиги/сквад и т.п. сделал

В общем по моим подсчетам бот фармит 174 000 коинов в 12 часов на 1 аккаунте. При 500 аккаунтов это примерно 174 миллиона в сутки, что считаю неплохо при вложениях в 400$. Думаю на днях догоню до 1000 (надеюсь не побреют)

Я очень люблю дашборды, поэтому и сюда прикрутил. А как у вас дела?

В целом ожидания от проекта не прям большие

Кстати, если хотите снифать запросы, особенно когда нужно с телефона (как с Notcoin), крайне рекомендую HTTP Toolkit. Использовал NOX в качестве эмулятора, HTTP Toolkit инжектится автоматически в профиль по нажатию 1 кнопки.

К слову пытался я разными способами и все они не такие простые и рабочие

Как без посредников принимать оплату в крипте

Идея очевидная:

1. Создаем кошелек для оплаты (библиотека web3→ eth-keys)
2. Просим пользователя перевести на созданный кошелек N-количество N-токена.
3. В цикле проверяем баланс токена и сравниваем с суммой оплаты (можно поставить ограничение на 1 час до оплаты, чтобы не застревать в цикле)
4. После оплаты трансферим на кошелек немного нативок (или принимаем сразу в нативках) и трансферим на мейн-кошелек.

В идеале накатить легкую БД, например SQLite, хранить и хранить в ней как минимум ID оплаты, адрес, приватник, сумму, идентификатор пользователя.

В целом можно использовать и пул адресов для оплаты, главное правильно реализовать статусы.

Красиво написать бек можно за час. Пользуйтесь.

Готовые решения для кодеров

Есть идея создать список готовых функций/классов для быстрой сборки проекта, очень часто сталкиваюсь с тем, что банальные вещи просто адаптирую под каждый проект, заебало, хочу написать универсальные решения. С сегодняшнего дня этим и займемся.

Залил на гист пока два готовых решения, которые будут полезны каждому.

check_version: проверка текущей версии Python
Меня порой заебывают ошибками, спустя какое-то время выясняется что чел пытается завести скрипт на Python 3.10 или 3.12 (я сейчас работаю онли с 3.11), хотя казалось в readme всегда указываю необходимую версию. Чтобы избежать лишней траты времени написал функцию check_python_version.

ProxyManager: класс для работы с Proxy
Пока лучшее решение что реализовал для себя, работает асинхронно в паре с better_proxy. При необходимости сам добавляет префикс, поэтому пользователь может грузить прокси вообще в любом удобном формате (главное чтобы http/https). Запускайте через run, функция вернет список валидных прокси в python-формате или None, если валидных прокси не оказалось.

Дальше постараюсь расширить этот список и запушить в полноценный проект/бибилиотеку.

Основной канал | О web3 | Мои софты