Последнюю неделю думаю над новым продуктом, ресерчу.
 
Смотрел Gelato – децентрализованный бекенд для web3.
 
Бывает у вас такое, что заходите на страницу проекта, и не совсем понимаете, что же он делает? Программисты говорят "просто покажи код". Я такой же – пока не увижу хоть какой-то простой сниппет, мне сложно понять миссию проекта.
 
Теперь мне в этом помогает ChatGPT. Простой запрос "Please show me some pseudocode on how to work with Gelato" выдал вот такое (картинка). Просто и понятно.
 
А вообще, Gelato, судя по всему, классная вещь, если вам нужно делать отправку транзакций по расписанию, реагировать на ончейн-события, отправлять gasless транзакции (чтобы юзеру не нужно было платить за газ) – и все это без создания своего бекенда. Если будет реальный опыт – отпишу в деталях.

Если бы я сейчас делал с нуля веб3 приложение на EVM-блокчейне, я бы использовал ThirdWeb SDK (есть для React, Go и проч.), а не Ethers.js.
 
Очень классно сделано, много низкоуровневых деталей затипизировано и скрыто.
 
Вот как, например, выглядит получение баланса токена. Не требуется работать с ABI, для всего стандартного есть типизация.
 
Если провести аналогию с БД, то ethers можно сравнить с SQL запросами, а ThirdWeb SDK – с ORM.
 
Рекомендую!

Где я был эти три месяца?
 
Произошло столько событий, попробую вспомнить:
 
1. После удачного проекта расширения для Dune Analytics словил почти двухмесячный "творческий кризис" – не понятно было, чем заняться дальше. Не было большой идеи. Пет-проекты не радовали, не видел в них перспективы.
 
2. Благодаря удачному стечению цепочки обстоятельств и знакомств залетел в крипто проект Yoki.finance – протокол подписок и рекуррентных платежей – в качество ко-фаундера и CTO. Мы поучаствовали в хакатоне от Polygon, сейчас готовимся к публичному запуску MVP. Заняли 3-е место на хакатоне Dora DAO (но это вряд ли моя заслуга). Общаемся с партнерами, т.к. значительная часть нашего проекта – это B2B. Опыт включал в себя вход в проект при наличии в некотором смысле устаканившейся команды, ее переформатирование, онбоардинг новых людей. Кстати, вот канал моего партнера и CEO проекта Константина: @yokifinance
 
3. Выбирал (и выбрал) хостинг для проекта, чтобы он был дружественен к части команды из России, а также можно было оплачивать из юрисдикций Гонконг или Дубай. По этим причинам отпали Amazon, Azure, Yandex.Cloud, остановился на Alibaba Cloud и пока все нравится.
 
4. Настроил CI/CD Next.js фронт части проекта на Github Actions + Bash + Docker compose с максимальной независимостью от Github Actions, чтобы можно было при необходимости перенести на любую другую платформу (например, если захочется Jenkins / Gitlab on premise). По сути, на Github хранятся только настройки, секреты и окружения, все остальное делается bash скриптами. Пока билдим на Гитхабе, т.к. получили год бесплатного Enterprise. Это дает 50 000 билд минут в месяц, что для нас на текущем этапе овердофига.
 
5. В нашей студии веб-разработки недавно приняли с партнерами важные решения. Одно из них – запустили процесс найма директора. Старый вскоре перейдет руководить новым направлением, и мы ищем, кому передать руководство операционным бизнесом. У нас уже был удачный опыт найма директора, поэтому с перспективой смотрим в будущее.
 
Так что, web3/крипто из моей жизни не уходит, просто разрастается "в ширину". Буду писать по мере решения различных проблем в более широком формате. Если что-то интересно из тем выше, дайте знать, раскрою в отдельном сообщении/статье.
 
Let's rock!
 
@web3dev_notes

Сегодня копал Web3Auth, который сильно упрощает регистрацию криптокошелька для новичка. Сейчас, чтобы создать криптокошелек, требуется установить Метамаск или аналог, записать seed phrase, вот это вот все.
 
Web3Auth предлагает "web2" подход к созданию кошелька.
 
Кто подзабыл, то в Ethereum нет как такового "создания кошелька". Off-chain создается случайный 256-битный приватный ключ (если быть точным, то в MM он генерируется на основе seed phrase), потом алгоритмом ECDSA генерируется публичный ключ, из которого получается адрес взятием последних 20 байт keccak256 хэша публичного ключа и прибавлением "0x".

Упрощенно:
Private_Key = random_bits(256)
Public_Key = EDCSA(Private_Key)
Public_Key_Hash = keccak256(Public_Key)
Address = "0x" + Public_Key_Hash[-20:]
 
И этим Private_Key можно подписывать транзакции от имени Address.

Подход Web3Auth: 
1. Пользователь нажимает "Войти":
2. Создается приватный ключ.
3. Ключ делится на 3 части.
4. Части раскидываются – локальная машина, привязка к логину на внешнем сервисе (Oauth) – Google/Twitter/etc, привязка к контрольному вопросу/паролю (можно добавить СМС и много чего еще).
5. При необходимости подписать транзакцию приватный ключ собирается из частей, не сохраняясь нигде целиком.

Каждой из этих трех частей недостаточно, чтобы сконструировать приватный ключ, поэтому утечка одной из них не страшна. И это очень классная фича, ведь, по сути, приватный ключ/seed phrase нигде не хранится отдельно.
 
У них есть наглядная демка – генерация и восстановление приватного ключа. Подробнее механика работы описана тут. Такая технология позволяет не возиться с установкой кошелька. Можно подписывать транзакции без подтверждений MM, т.к. фронтенд всегда может сконструировать приватный ключ самостоятельно.
 
Но сразу возникают вопросы:
1. Что мешает авторам dApp проводить нежелательные транзакции от имени пользователя?
2. Как проконтролировать, какие транзакции будет подписывать приложение? (пример с подтверждением allowance, когда приложение может поставить любой allowance без ведома юзера, что создает возможную дыру в безопасности).
3. Как снять деньги с такого кошелька? (Если в приложении будет опция Withdraw, приложение может взять любую комиссию).
 
То есть non-custodial, но не совсем.
 
При этом Метамаск три дня назад твитил, что вряд ли seed phrase будет достаточно, чтобы заонбоардить миллиард новых пользователей, намекая на движение в ту же сторону.
 
Возможно, мы придем к гибридному варианту, когда "продвинутые" будут делать подтверждения, контролируя каждую транзакцию dApp, а "обычные" будут пользоваться упрощенным вариантом. Такие мысли.
 
А вы что думаете по этому поводу? Есть те, кто регулярно пользуется dApp'ами с Web3Auth входом?

Простите, что опять про ChatGPT, но до сих пор большинство разрабов его не используют, и я не понимаю, почему. Ведь это отличный буст продуктивности.

Одно из неочевидных применений – трансформация данных по заданному алгоритму.
Например, у меня был список пакетов из package.json и нужно было перечислить их имена в одной строке, разделенной пробелами. Конечно, можно потратить несколько минут на работу пальцами, но это не наш метод – см. картинку.

Кстати, у меня уже спрашивали, как я вызываю ChatGPT. Прямо из Chrome, расширение Sider.

Всем эффективного кодинга!

Последний месяц пилим пилотный проект для клиента по приему подписок в крипте (yoki.finance). Go, NestJS, проектирование базы и API, согласования между членами команды – разработческая рутина, но интересная и бодрая. Вместе с тем, это пока не сильно "вебтришно". Когда запилим интересное, то поделюсь. Планируем спонсирование транзакций на ERC 4337, чтобы с газом людей не напрягать. Мелочь, а приятно должно быть.
 
В процессе работы возникли идеи потенциальных опенсорс проектов. Первая – простая альтернатива WalletConnect/Web3Modal (популярная абстракция, чтобы разные криптокошельки подключать), который недавно заблокировал (а потом через 3 дня разблокировал) пользователей из РФ, но осадочек-то остался. Забавно, что называющий себя "децентрализованным" WalletConnect представляет собой клиентскую библиотеку, обращающуюся к собственному уникальному облачному API.
 
Вторая идея – упрощенный вариант gelato automate/web3 functions для автоматизации повторяющихся веб3 задач, опять же self-hosted, а не как у gelato. События последних пары лет показали, что децентрализация рулит, и не только для веб3, поэтому я все больше придерживаюсь такой концепции, выбирая децентрализованные решения где только возможно.

Еще один пост про SuperDAO (простите, побуду немного стартапером).
 
Довольно хайповый проект, стартовавший в 2021ом как платформа для создания и поддержки DAO (децентрализованных организаций), несколько дней назад закрылся. Юрий Лившиц, фаундер, любезно поделился с сообществом опытом, что мне показалось очень занятным. Интересующимся рекомендую ознакомиться, полезная информация также в pre-seed/seed memo (понять, как делается позиционирование для инвестора, сравнение с другими проектами). Запали две мысли:
 
1. В 2021ом было популярно мнение, что крипто/веб3 изменит разные отрасли (игры, недвижимость, спорт, программы лояльности и тд), люди из разных отраслей будут создавать DAO, чего в итоге не случилось, только крипто + финансы оказалось рабочей связкой.
2. Клиенты, которые использовали DAO для своих компаний, не получали лучших операционных метрик по сравнению с традиционным (еще и более понятным) способом организации юрлица.
 
В итоге, в такой рыночной коньюнктуре, SuperDAO не мог построить устойчивый бизнес и ребята решили закрыть проект. Хочу пожелать им удачи и уверен, что следующий проект у них точно получится – они супер крутые.

Почему вам не нужен account abstraction (AA) если вы не делаете свой кошелек
 
Про AA в двух словах. Есть два подхода к кошелькам в Ethereum:
 
1️⃣ традиционный – Externally Owned Accounts, EOA – пара адрес/приватный ключ, который невозможно поменять. Кошелек инициирует транзакции, подписывая их приватником. Но чтобы отправить транзу, нужен газ. Если приватник засветился или потерялся, то туши свет. Такие в целом минусы.
 
2️⃣ современный – Smart Contract Accounts (SCA). Это когда создается кошелек – смарт контракт, и на него закидываются средства. И вот тут уже можно прикрутить разные интересные штуки, типа multisig (чтобы отправить транзу, нужны например, подписи двух его владельцев), или можно авторизацию по email прикрутить. А вот чтобы отправить транзакцию от имени этого смарт-контракта, как будто от EOA, и придумали AA. Сейчас стандарт ERC4337.
 
Осенью мы в Yoki начали разработку пилота по приему платежей для клиента. В то время я думал, как прикрутить AA, чтобы улучшить качество продукта. А именно – у нас решение некастодиальное – чтобы газ спонсировать для клиента, или чтобы для оплаты газа было достаточно купленного через fiat on ramp стейблкоина, например. Думал про создание смарт аккаунта, чтобы юзер закидывал туда средства на подписки.
 
Далее, после раздумий и обсуждения с партнером, стало понятно, что юзеры побоятся отправлять средства на смарт-контракт, созданный пока никому не известным протоколом Yoki finance.
 
❗️Следовательно, чтобы решить часть задач, лучше всего сделать, чтобы наш dApp бесшовно работал со Smart Contract Wallets, т.е. кошельками на основе SCA. Соответственно, мы имеем плюшки типа мультисига, логина по email, оплату газа любым токеном, fiat-on-ramp, предоставляемых привычным юзеру кошельком и все это в нашем dApp как бы

Я тестил Safe и Ambire, и остановился на последнем, т.к. там есть оплата газа стейблкоинами, что мне и нужно было для тестирования приложения. Пока тестируем на нем, смотрим как работает, про AA не вспоминаем. Такие дела.
 
P.S. Если вам зачем-то понадобится информация про AA, то вот тут люди целую гитхаб репу запилили.

После прочтения текста выше могло показаться , что мы интегрируемся только с Ambire. Нет, будем работать с любым Smart Contract Wallet, поддерживающим WalletConnect (лидеры все поддерживают). Нужно только убедиться , что все сделали правильно, и интеграция работает.

ERC2612 и dApp UX
 
Тут разраб из твиттера запилил сервис на Ethereum для получения газового токена, если у вас его нет. Например, купили USDC на бирже, перевели на кошелек, воспользовались сервисом и счастье – есть чем за газ платить.
 
Хорошая идея! Начал разбираться, как реализовано. Оказалось, стандартом ERC2612, который позволяет делать gasless approvals. В двух словах, юзер оффчейн подписывает "документ" со сроком действия, который криптографически подтверждает разрешение снятия (аппрув) контрактом-ботом определенного количества токенов с дедлайном. Далее этот документ-разрешение передается боту, который вызывает permit у токена (дает аппрув, проверяя документ), снимает нужное количество с кошелька, меняет на газовый токен, берет свою комиссию.
 
Классное решение! – подумал я. Стало интересно, какие популярные токены так могут. Сделал простейшую аналитику на наличие permit в коде, см. картинку.
 
Негусто! – почесал репу. И запилил прототип, посмотреть как работает на примере Polygon USDC.e, который был у меня кошельке и… потратив чуть ли не день, с удивлением обнаружил – чтобы корректно поддерживать ERC2612, токен должен корректно реализовывать и EIP712, а с этим у USDC.e проблема. Он пытается его реализовать, но domain separator конструируется не по стандарту, соответственно, подпись, сделанная кошельком по EIP712, не проходит. Получилось допилить ethers.js, чтобы принимал захардкоженный domain separator, который можно дернуть с токена, но на UI это, по видимому, невозможно… В итоге все заработало на обычном USDC, поэтому из таблицы часть "зеленых" – это никакие не зеленые, а прикидывающиеся зелеными (тема отдельной проверки). Если будет интерес, то напишу статью на эту тему.
 
Прочитал в Сети мнение, что в Эфире только ERC20 нормально сделан, а остальное стагнирует, в том числе из-за легаси. Интересно, есть ли не-EVM блокчейны, где функции для UX побогаче, с учетом полученного на Ethereum опыта? Думаю, настало время попробовать что-то еще.
 
Не одним эфиром, как говорится.

Запоздалый анонс. Кто пришел не с Хабра – тему с ERC2612 я раскрыл в статье там.
 
Так что, если хотите подробнее узнать, как работают gasless approvals и выдача разрешений – приятного чтения.

Вышли в прод…
 
Нелегко писать о своих успехах, но я попробую, к тому же это непосредственно связано с тем, то что сам программирую. В марте наш протокол крипто-нативных подписок @yokifinance (автор сих строк – кофаундер/CTO) вышел в продакшен эксплуатацию, мы подключили двух клиентов 🎉🎉:
 
–  Крупнейший русскоязычный подкаст про блокчейн – Базовый Блок,  где можно оформить подписку на эксклюзивный/ранний доступ к материалам и поддержать ребят за их просветительскую деятельность

– Web3 Growth Agency Altcoin Edge. У ребят есть закрытый клуб с отобранным контентом для крипто-инвесторов для глубокого погружения в крипто-проекты, и Yoki используется для подписки на этот контент.
 
Самое приятное, что пошли подписки, и через нас прошло более $300. Да, это слезы, но сам факт радует. Хотел бы поблагодарить всю нашу команду (ребята, вы космос!), и клиентов за оказанное доверие.
 
Для разработчиков (и не только), как это работает:
1️⃣ Пользователь подключает кошелек и дает аппрув на снятие (по умолчанию это 6 периодов подписки, минимальный – один период – для тех, кто хочет проверить) на определенный контракт подписки.
2️⃣ Контракт подписки определяет токен и объем списания, а также частоту (контролируется он-чейн). Также, куда идут деньги после снятия (мерчанту и нам чуть-чуть в виде комиссии).
3️⃣ Пп. 1-2 приводят к полной ончейн прозрачности. Пользователь видит контракт, и сколько и как часто могут сняться средства. Не может быть, что сегодня снимали 10 USDT / месяц, а завтра 100 USDT – параметры зашиты ончейн. Мы также не просим закидывать средства куда-либо.
4️⃣ В отличие от почти всех протоколов, которые обычно запрашивают аппрув на максимальную сумму, мы по умолчанию ставим шесть (минимум один) периодов.
 
Ну и по хорошей традиции – репо с нашими смарт-контрактами

Первый веб3 хакатон
 
На выходных хакатонил в Frameworks от ETHGlobal. Создавали фреймы и инструменты для хайповой последнее время соцсети Farcaster – очень похожа на X, только с элементами децентрализации.
 
Фрейм – это мини-приложение, которое появляется в ленте, только еще с привязкой к криптокошельку. Можно сминтить NFT или сделать другое ончейн действие. Я делал, чтобы можно было поддержать автора, донатя каждый месяц определенную сумму через @yokifinance (сюрприз!).
 
Мой фоллоу-ап в рандомном порядке, пишу для себя на будущее; может и вам будет полезно 👇

1. Лучше узнавать о хакатоне заранее. У меня получилось так, что первый день (из двух) ушел на чтение теории. Теорию надо изучать заблаговременно, чтобы в момент Х старта хакатона сразу начать создавать продукт.

2. Проект был небольшой, необходимости привлекать второго программиста не было. Но, как оказалось, был очень нужен дизайнер – нарисовать красивые картинки, а также помочь оформить проект при отправке его в системе – логотипы, скриншоты, обложку. Если бы дизайнер прочитал правила, разобрался как сабмитить решение заранее, то вообще цены бы ему не было 🥰 но пришлось все делать самому, т.к. позвать дизайнера я не догадался.

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

4. Проект делал на Pinata.cloud, frog, viem. Pinata по факту особо не юзал, но подался в их partner prizes, как оказалось зря. Frog – довольно сырая штука, у меня не проходил простейший approve (ну или я чего-то накосячил), пришлось делать демо без аппрува.

5. Много слышал про vercel, наконец-то попробовал его – очень удобно деплоить маленькие pet-проекты, даже не попросил карту, просто логин через гитхаб, выбор репозитория – и деплой в один клик/коммит! Особенно порадовала функция вставки нескольких переменных окружения через CTRL-C - CTRL-V из .env файла. Удобные логи. Видно что продумывали.

6. Так и не понял толком связку кошелек – Фаркастер, надо изучить. Были места, когда нужно вводить кошелек текстом во фрейме. Сейчас кошелек привязывается, когда надо сделать транзакцию, а как привязать его заранее?

7. В случае участия в основном треке (где надо лично докладывать проект) – лучше заранее подумать, кто ближе по таймзоне и будет докладывать. В ретроспективе понятно, что мой проект имел больше шансы на выигрыш в основном треке, но я выбрал партнерский трек еще и потому, что не смог бы сделать презу после 12ти часов нон-стоп кодинга, еще и ночью.
 
Кому сильно интересно – видео демо и код.

Запустил Ethereum ноду
 
Эпопея растянулась на пару месяцев. Сначала казалось, что делов на пару дней (есть же документация). Как это было:
 
1. В качестве клиентов взял Geth и Prysm. Да, лучше взять другие для client diversity, но я решил начать с самых популярных, чтобы набрать опыт (более популярные -≥ больше вопросов/ответов).
Т.к. разворачивал на сервере компании, а не на отдельной машине, принял решение разбить на 3 докер сервиса:
– geth – execution client (одноименный Geth).
– beacon – beacon (consensus) client (Prysm).
– ubuntu – сервисный для доступу к первым двумя внутри докер сети, а также для Clef, чтобы подписывать транзакции.
 
2. Железо – SSD Samsung 870 EVO MZ-77E2T0B/EU 2ТБ, 2.5", Intel Xeon E5620 @ 2.40GHz, 16 cores, 48Gb RAM. На 2 апреля 2024 занятое место на диске – 1,2 ТБ, snap sync. Geth использует 11 GiB, beacon – 9,5 GiB RAM.
 
3. Синхронизировалось все за несколько дней, использовал checkpoint sync, то есть синхронизировался не с генезиса (начала), а с текущего момента - чекпоинта.
 
4. Основной геморрой был с тем, чтобы заставить работать Geth и Prysm в докере, т.к. документация расчитана на локальную установку. По умолчанию geth-Prysm связываются через IPC (взаимодействие процессов), а нужно было настроить на общение через http. Соответственно, параметры geth --ipcdisable и --http, также нужно настроить порты, адреса прослушивания – все это значит менять дефолтные параметры, которые заточены на localhost. В docker compose все это учел. Но очень много времени потратил на выяснение, почему сервис не отвечает на портах.
 
5. Вынес все persistent данные из докер контейнеров на хост машину через volumes докера.

6. Clef (которым подписываются транзакции и управляются аккаунты) запустил без проблем, видимо сказался полученный опыт. Также общение через http. Он не обязательно должен быть запущен постоянно, только когда подписываете что-то, так что окей запускать его в ubuntu сервисе.
 
8. Хороший туториал для проверки работы ноды, мне очень помог; имейте в виду, что он тоже на локалхост рассчитан, нужно свои имена хостов (сервисов) подставлять.
 
Теперь могу использовать свою ноду для RPC API – вдруг на определенном моменте понадобится. Понимание работы блокчейна также улучшилось. Но еще больше улучшилось понимание Докера и сетевых моментов, хоть я в этом и не совсем новичок. Надежность сети чуть улучшил. А в целом вывод – свои ноды оправданы для больших проектов с огромной нагрузкой, для небольших стартапов точно лучше подойдут облачные провайдеры.
 
Docker compose файл в гитхабе + более технические моменты. PR велкам.

Где я был этот месяц
 
Расскажу в рандомном порядке, что произошло в апреле. Было не так много веб3, но было интересно.
 
1. В @yokifinance запилил интеграцию со Stipe. Если быть точнее, MVP, осталось принимать данные от Yoki, а не вручную. Переделал модель базы данных, чтобы соответствовать сущностям Страйпа – надеюсь, это упростит подключение для тех, кто уже имел опыт с ним.
Идея интеграции была в том, что если у мерчанта забиты продукты в Страйпе, и есть интеграция через вебхуки, то мы автоматически создаем такие же продукты и цены в Yoki. Когда юзеры оплачивают криптой у нас, то мерчант получает уведомления через существующую инфру.
Потом пришла информация что Страйп летом выкатывает оплату в стейблах. Очень надеюсь, что это плюс для адопшена.
 
2. Нода эфира, про которую рассказывал в прошлом посте, работает. Знакомые ребята попросили дать доступ, чтобы проверить работу с self-hosted нодой для одного из своих проектов. Работает стабильно.
 
3. На Хабре запилил статью про то, как оптимизировал запросы к Ethereum JSON RPC на ethers.js. Главный вывод – все облачные решения разные, и когда речь идет о работе на пределе (не 2 юзера в час), то нужно затачиваться под конкретного провайдера.
И тут нода пригодилась, делал тесты, и остался доволен скоростью работы по сравнению с облачными решениями.
 
4. Мой партнер подал Yoki на грант от Gitcoin. Удивительно, но за нас голосуют рублем какие-то неизвестные замечательные люди, на текущий момент уже 1148 голоса на сумму $2200, при этом мы нигде не пиарили эту активность (кроме анонса в соцсетях), не делали накруток, платеж доступен только на Arbitrum, и даже это людей не останавливает. Ни на что не намекаю, но голоса всегда приветствуются 🙂
 
5. В свободное время читаю про системы распределенного реестра на примерах ENS и Farcaster. Очень простая и мощная концепция. На примере достаточно децентрализованной социальной сети: не обязательно хранить все данные ончейн. Достаточно, чтобы onchain хранилось соответствие имени пользователя серверу, где ему можно написать сообщение. Таким образом, сервер не сможет забанить юзера, поскольку юзер всегда сможет поменять запись в registry и перейти на другой сервер.

Лето в разгаре
 
Решил порадовать вас последними апдейтами из моей личной жизни.
По традиции, последнее время совсем немного веб3 – уже думаю над переименованием канала, но пока держусь – я же фул-стек или как?
 
Из интересного, чем занимался – все связано с Yoki:
1. Подключил к проекту систему продуктовой аналитики Posthog. В двух словах:
 – система понравилась, ориентирована на разработчиков, UI почти всегда интуитивно понятен.
 – чуть сыровата, но пока критичных багов не нашел.
 – лучше закладывать подключение аналитики на этапе проектирования приложения – у нас было Реакт приложение статика, пришлось мигрировать на Next.js (потребовалась серверная часть для бутстрапа флагов).
– опенсорс, что важно, особенно в крипте – при желании можно развернуть на своем сервере.
 – заняло 3 недели.
 – впервые в жизни реализовал A/B тестирование – получил ачивку. Концептуально это не сложно, но технически немного запарно.
 
TL;DR запилил статью на Хабр
 
2. Реализовал поддержку чекаут сессий, как в Страйпе, с кастомизациями и все такое.
 
3. Поучаствовал в качестве менеджера, продакт овнера или просто помогатора с такими задачами, как поддержка нескольких цветовых тем, бекапы баз, сбор статистики по тому, какими токенами пользователи хотят платить, подключение новых мерчантов.
 
4. Чуть не попался на развод – чувак из твиттера предложил поработать над проектом, а т.к. я никогда не отказываюсь от клиентов для нашей компании по заказухе, я согласился. Перед звонком он попросил меня скачать софт для телеконференции, что я почти сделал; оказалось, что это был троян.

В общем, лето продолжается, работаем дальше, и не забываем хоть немного отдыхать и набираться вдохновения на следующий сезон.

Работаю над проектом с децентрализованными биржами (DEX).
 
До этого работал с Uniswap. Сейчас с целым зоопарком – Uniswap, Curve, Sushiswap, Balancer, Bancor, Synapse, Dodo 🤯
 
Чтобы сделать обмен, сначала роутер (для Uniswap 1, 2) строит оптимальный путь обмена токенов. Пример – иногда может быть оптимальнее поменять USDT на USDC через промежуточный токен, или разделить (split) входную сумму на несколько частей.
 
Роутер строит оптимальный путь оффчейн, загружая информацию о текущих пулах через сеть с внешнего API (IPFS, TheGraph, …). То есть можно пользоваться DEXом, имея только доступ к ноде эфира, но оптимальный путь на больших объемах не получишь. У Sushi, Balancer, Dodo routing SDK не обнаружен, использовал внешнее API, которому говоришь – "дай мне оптимальный путь обмена USDT на WETH". Некоторые из таких API также имеют геоограничения – децентрализация в полный рост.
 
Оказалось, только Uniswap и Sushi имеют свою модель для оценки газа, который будет использован транзакцией обмена (в Uniswap это estimatedGasUsed ) – для меня было сюрпризом, что оценка делается не через eth_EstimateGas, а просто путем подсчетов в роутере. Быстрее и не всегда eth_EstimateGas может отработать – например, нет баланса или allowance. Для остальных пришлось строить модель оценки газа самостоятельно и это не всегда простая задача.
 
В сухом остатке – отрасль интересная, но все, что не Uniswap, сильно отстает по developer experience, поэтому нужно закладывать много времени на интеграцию.

⚡ Да, появилось свободное время, могу помочь вашему продукту консультациями или проектной работой в качестве разработчика/CTO в web3/crypto.

Интересен опен-сорс, developer tooling, DeFi, инфраструктура.

Связь @web3dev_notes_bot