Обещал рассказать, как получать монеты в Dater без NFT аватара.

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

По умолчанию звонки в Дейтере по 3 минуты.
Если собеседник скучный, то 3 минуты тянутся вечно.
Но если интересный - то не заметишь, как пролетят.
А потом захочется еще, но собеседники-то выбираются случайно.

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

А еще скоро появятся аукционы, где можно торговаться за право попасть на звонок с крутым дейтером.
И этот дейтер тоже получает коины с аукциона.

Кстати, всем, кто зайдет сегодня в дейтер, дадут по миллиону дейтеркоинов (ШУТКА).

А еще сегодня вечеринка. Тема - "Протри фронталку, плохо видно" (НЕ ШУТКА) 😎

В общем, начал я собеседоваться в Biconomy.

По классике, сначала HR, потом с технической командой. Тут все прошло ок.
А чтобы перейти на следующий этап мне дали домашнее тестовое.

Полное задание на скрине, но суть такая: склепать контракт(ы), который позволяет юзеру создавать smart contract wallet, депозитить в него нативные токены (eth, matic) и ерс20 токены на определенный срок, а потом снимать депозит. И сделать ко всему этому интерфейс, чтобы взаимодействовать с контрактом.

А, главное, cделать это безгазово, используя их инфраструктуру.

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

В итоге технически решил так:

- Есть основной смарт-контракт со всей логикой
- Под каждого пользователя по запросу деплоится минимал прокси. Это и будет его кошелек.
- Адрес этого прокси прописывается в систему Бикономи
- Также соответствие этого адрес и адреса EOA пользователя пишется в мою базу, чтобы узнавать пользователя в следующий раз
- Ну и все, дальше пользователь вызывает функции контракта через бикономи, и комиссия берется с моего счета, так как его кошелек есть в системе

Контракты можно посмотреть тут.

И вот видос, как это все работает вживую.

Если честно, я был очень доволен тем, как я выполнил тестовое.
Просто до тестового я ни про какие смарт-контракт кошельки и минимал прокси почти ничего не знал, потому что в основном мой опыт был в NFT.

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

Но в итоге, они сказали, что им все понравилось, и позвали на следующее интервью - с CTO.
Потом было собеседование с тремя ко-фаундерами. И потом финальное с двумя HR.

Итого я прошел 5 интервью на английском и выполнил тестовое.
После этого, у меня запросили референс леттер.
Что хорошо, благодаря моей работе в HyperCube у меня было кого попросить о рекомендации.

Ну и все, через несколько часов после получения рекомендационного письма Biconomy сказали, что готовы сделать мне оффер.
Оффер я принял 16 декабря и договорились, что с 16 января я начинаю работу.

Вот так я меньше, чем за два года с нуля дорос до Senior Blockchain Developer.
Ну и за 2.5 месяца нашел работу.

Но на этом моя история с собеседованиями не заканчивается 👀

Скоро расскажу про еще одно прикольное собеседование и разберу тестовое задание в одну из самых крупных блокчейн компаний в мире.

Да, я видел в твиттере и более динамичные карьеры у разрабов.

Но в целом, я считаю эту позицию блокчейн дева в Бикономи большой удачей для себя.
У меня был очень специфический опыт в разработке смарт-контрактов - в основном в NFT.
А в конце 2022 года разработка в сфере NFT, сами понимаете, почти никому не была нужна.
Если бы я только кодил, а не запускал проекты - я бы мог научиться за 2 года гораздо большему. А я еще строил команду, искал нишу продукта, занимался маркетингом, проводил ама сессии и твиттер спейсы.
Так что честно говоря, я до последнего не верил, что смогу быстро найти работу.

Что в итоге, как мне кажется, помогло мне получить эту позицию:

- Желание учиться. Сколько раз я тратил часы на то, чтобы разобраться с моментами, которые напрямую к моему текущему проекту не относились. А еще я учился прямо в процессе поиска работы и интервью, что помогло мне адаптироваться к рынку.
- Английский, который я подтянул на тех самых АМА. Понятно, что от разрабов супер английского не ждут. Но когда ты можешь с HR еще и за жизнь немного поболтать, и в целом бегло самопрезентуешься - это придает уверенности. Думаю, интервьюеры это тоже ценят.
- Занудный подход к тестовым. Я всегда старался выполнить все так, как будто это скоро пойдет в продакшн.
- Тот факт, что я оформил свою придумку с lockable NFT как Ethereum Improvement Proposal. Это реально требует много времени, но показывает, что ты реально хочешь делать вклад в экосистему и не просто кодишь, а думаешь как изобретатель и инноватор.
- Более или менее оформленный гитхаб.

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

Частные аудиторы в твиттере be like

Еще один сын маминой подруги.

Мне это напоминает, как в начале NFT хайпа набирали аудиторию с помощью флекс твитов типа «Я сегодня продал свою работу за 100500 эфиров! Лайкните и подпишитесь, и я куплю вашу NFT»

Доброго пятничного утра!

Один проект на L2 решении zkSync поднял $1.7М на токенсейле, но не может вывести деньги с контракта.

Потому что функция transfer (внезапно) не работает на zkSync.

Надо сказать, что и там, где она работает, считается плохой практикой использовать transfer, лучше использовать call 🧐

Если вы еще не в курсе.

Bitcoin Whitepaper - ну то есть практически криптобиблия, поставляется в комплекте с каждым маком.

Если у вас мак, откройте терминал и введите:

open /System/Library/Image\ Capture/Devices/VirtualScanner.app/Contents/Resources/simpledoc.pdf

Если не читали, приятно вам провести вечер пятницы 🤓

Обещал еще про одно собеседование рассказать и разобрать тестовые задания. Заданий в этот раз было целых два.

В общем, уже после того, как я принял оффер от Biconomy, со мной связались Safe.
Раньше они назывались Gnosis Safe и это одна из самых крупных компаний в крипте.
Мне кажется, каждый криптан слышал про их основной продукт : Multisig Wallet , который позволяет реализовать очень важную функцию - управлять кошельком нескольким людям. Например, у кошелька три владельца, и транзакция будет отправлена, только если ее подтвердят 2 из 3.

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

Задание было такое:

У Safe кошельков есть система модулей. Мне было предложено написать простой модуль, которому позволено осуществлять транзакции с основного safe аккаунта, но с альтернативной системой авторизации этих транзакций.

А именно: владелец основного счета может выдавать криптоподписи для перевода определенного количества токенов. Любой, у кого есть эта подпись может снять токены с основного счета и отправить на кошелек по своему выбору. По сути, это такой аналог чековой книжки.

Полное задание в pdf прикладываю.

Мое решение тут: https://github.com/filmakarov/safe-test-module

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

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

А где эта подпись у нас может засветиться? Ну конечно же в мемпуле транзакций.
То есть, если Боб отправит транзакцию на вывод токенов с этой подписью, а Чарли ее увидит в мемпуле, Чарли может отправить другую транзакцию с такой же подписью, но своим кошелельком в качестве получателя токенов. И поставить выше цену за газ.
Таким образом, он опередит Боба и снимет деньги. А Боб снять уже не сможет.

Это называется frontrun атака. И по сути именно этим занимаются MEV боты.

От нее легко защититься, если чек будет именной: т.е. в подписываемых данных будет содержаться адрес получателя средств или адрес того, кто будет использовать чек (подпись).

Но я все сделал точно по заданию, а уязвимость просто описал в комментариях.

Видимо, их это устроило, потому что потом меня пригласили еще на два собеседования - технические. И там было еще одно интересное задание.

Кстати, если вы (или ваши друзья) развиваете проект в веб3, то вы можете получить поддержку от Biconomy.

Мы недавно анонсировали программу акселерации Pioneers of AA 👨‍🚀

Она предназначена для команд, делающих децентрализованные приложения (dApps), которые могут выиграть от внедрения Account Abstraction.
А с учетом того, что Account Abstraction - это технология, которая улучшает ux для пользователей, выиграть от ее внедрения может почти любой дэпп.

Что получат команды, которые пройдут отбор в программу:

- Помощь в разработке идеального UX c использованием AA
- Всесторонняя поддержка инженеров Biconomy в разработке продукта и внедрении АА
- Возможности для роста: совместный маркетинг и кампании в соц сетях
- Дополнительные плюшки будут объявлены по ходу программы

Если вам актуально, заполняйте заявку тут
https://t.co/Ip0PEB4RQJ

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

Второе задание с собеседования на Senior Blockchain Developer в Safe Global (бывший Gnosis Safe).

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

Вот сам контракт: https://hackmd.io/@rimeissner/ByXSCKaj5

Давайте вместе сделаем мини-аудит.

Я начну с первой уязвимости, а вы пишите в комменты остальные.
Что не найдем в комментах, я буду разбирать в следующих постах.

Первая уязвимость:
В структуре Entry - две переменных типа bytes подряд: title и description.
Само по себе - ничего криминального.
Но в строке 22 видим, что entry упаковывается с помощью encodePacked и хэш используется в качестве ключа в мэппинге - id каждой записи о депозите.
Теперь представим ситуацию, что у нас есть два Entry, полностью одинаковые, за исключением title и description.

Пусть в первом объекте
Title:'deafbeef'
Description: 'decaf'

А во втором
Title:'deaf'
Description: 'beefdecaf'

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

Всем шашлык 🍖

Следующая уязвимость в контракте с собеседования, или, скорее, несовершенство контракта - отсутствие поддержки Smart Contract Signatures по стандарту EIP-1271.

Вообще, в чем предназаначение этого контракта?
Это простейший escrow контракт - то есть кто-то может задепозитить нативный токен, а другой человек, имея криптографическую подпись, сможет этот депозит снять.

А что если депозитор - смарт-контракт? Смарт контракт не имеет приватного ключа, а, значит, не сможет сделать подпись, которая при использовании в ecrecover вернет адрес контракта в качестве подписанта. То есть смарт-контрактные кошельки пользоваться этим escrow не смогут. Точнее, задепозитить-то они смогут, а вот снять депозит уже нет. Так что вполне возможна потеря средств.

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

Чтобы добавить поддержку 1271 сюда, достаточно было бы проверять extcodesize !=0 для entries[id].issuer и если это так, то использовать не ecrecover, а entries[id].issuer.isValidSignature.

Я пока описываю наименее очевидные улучшения, жду более очевидные в комментариях.

Да, кстати, в комментариях уже нашли Re-entrancy уязвимость.
Надо в деталях расписать, как это работает и почему ее можно устранить просто поменяв местами строки 42 и 43?

Надо расписать => 👍
Все и так понятно => 🔥

Что такое Re-entrancy уязвимость

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

В нашем конкретном случае на строке 42 мы отправляем средства с депозита тому, кто вызвал функцию payout c помощью низкоуровневого вызова, т.е. метода .call.

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

Например, он может сделать так, что метод receive будет заново вызывать метод payout нашего escrow смарт-контракта c теми же самыми данными.
То есть 43 строка из исходного вызова payout не исполнится до тех пор, пока функция payout не отработает еще раз.
А поскольку именно 43 строка отвечает за то, чтобы пометить депозит как неактивный (то есть деньги с которого сняты), проверка на 40 строке для второго (злоумышленного) вызова payout снова пройдет и позволит снова отправить деньги с того же самого депозита.

Таким образом можно зациклить исполнение payout и выдоить почти все средства с нашего escrow.

Исправляется это в нашем случае очень просто - достаточно поменять местами строки 42 и 43, то есть помечать депозит как использованный ДО того, как отправлять средства через .call.
В таком случае при попытке повторного вызова payout из receive проверка на 40 строке не пройдет и вся транзакция будет отменена. Это называется “checks-effects-interactions pattern” - то есть сначала проверка, потом эффект действия и только потом взаимодействие со сторонними адресами.

Самое громкое использование этой уязвимости случилось в 2016 году, знаменитый The DAO hack. Который кстати вызвал аж целый хардфорк всего блокчейна эфира.

Но что самое интересное, это никак не помешало разработчикам снова и снова допускать ту же самую ошибку, а хакерам на ней наживаться.

Из последнего:
Uniswap/Lendf.Me (Апрель 2020) – $25 Миллионов, атака через re-entrancy
The BurgerSwap (Май 2021) – $7.2М фейковый токен контракт, эксплуатирующий re-entrancy
The SURGEBNB hack (August 2021) – $4М атакая с манипуляцией ценой, также основанная на re-entrancy паттерне
CREAM FINANCE hack (August 2021) – $18.8М re-entrancy для повторного займа
Siren protocol hack (September 2021) – $3.5М атакая на АММ пулы с помощью re-entrancy

Что интересно, re-entrancy потенциально может встретиться и в NFT-based протоколах. Потому что по стандарту ERC-721 в смарт-контракте должен быть метод safeTransferFrom, который прежде чем отправить NFT - запрашивает у принимающей стороны, готова ли та его принять. То есть как раз открывается потенциал для выполнения неизвестно какого кода, который в теории может в выполнение текущей функции перезайти.

Конечно, сейчас re-entracy - это одна из самых известных уязвимостей и все аудиторы довольно быстро ее видят. Но все же про нее лучше знать и не допускать, чем потом краснеть на аудите.

Кстати про последствия взлома The DAO