Solidity hints. Часть 3

Постепенно выходим из состояния выходного дня и принимается за работу.

Вообще, не смотря на сезон отпусков и желания провести время где-то у моря, уже третий год - лето у меня самый загруженный период. Вот и сейчас на следующие 2,5 месяца у меня следующие планы:

1. Подготовить крутую практическую программу для 2 модуля курса;
2. Запустить 8 недельный курс на все лето;
3. Разобрать 4-5 defi проекта (пока в планах, Uniswap V3, Compound, Euler и DyDx);
4. Вывести на зарубежный рынок свой проект по пре-аудиту протоколов;
5. Закончить соло аудит;

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

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

А пока, возвращаемся к разбору пунктов из репо Chinmaya:

4. Using low level functions to call a contract = handing over control to it

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

Это, вероятно, один из самых популярных вопросов базовой безопасности смарт контрактов, который изучают начинающие аудиторы на различных CTF - capture the flag - задачки по взлому контрактов.

Например, следующий код с уязвимостью реентранси демонстрирует эту проблему:

mapping (address => uint) private userBalances;

    function withdraw() public {
        uint256 bal = userBalances[msg.sender];
        require(bal > 0);

        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent, "Failed to send Ether");

        balances[msg.sender] = 0;
    }

Есть некий маппинг, где хранятся балансы пользователей, и функция вывода средств с контракта. Мы вызываем низкоуровневый call на msg.sende и передаем всю сумму с баланса.

Отправителем транзакции вполне может оказаться смарт контракт, который "ловит" внешние вызовы в него через функции receive() или fallback(). И уже в них он может реализовать какую-либо хакерскую атаку, например:

    fallback() external payable {
        if (address(etherStore).balance >= AMOUNT) {
            etherStore.withdraw();
        }
    }

т.е. он "ловит" call функцию, и перенаправляет вызов обратно в контракт для вывода остальных средств. В итоге это приведет к опустошению первого контракта. А следовательно другие пользователи потеряют все свои активы.

Вообще, всегда нужно быть аккуратными с низкоуровневыми вызовами call() и delegatecall(), желательно не давая пользователям контролировать адрес, куда идет вызов.

Там есть и другие проблемы с такими функциями и о них можно почитать в подборке Solodit.xyz или узнать больше на Ютуб каналах, посвященных безопасности.

Будьте аккуратны!

#call #delegatecall

Solidity hints. Часть 4

Идем дальше, и на очереди у нас пункт под номером пять:

5. Before using delegatecall, ensure that storage layout is in same order in both contracts

Используя функцию delegatecall(), убедитесь, что переменные состояния идут в одинаковом порядке.

Еще одна популярная проблема с низкоуровневыми функциями. Возьмем к примеру два контракта:

contract A {
    address public sender;
    address public owner;

    function setAddress(address _contract, address addr) public payable {
        (bool success, bytes memory data) = _contract.delegatecall(
            abi.encodeWithSignature("setAddress(address)", addr)
        );
    }
}

contract B {
    address public owner;
    address public sender;

    function setAddress(address addr) public payable {
        owner = msg.sender;
    }
}

Если вы не помните основную особенность delegatecall(), то напомню, что он "как бы забирает" функцию из другого контракта и выполняет ее в рамках контракта, где он был вызван.

Если мы вызовем функцию setAddress() в контракте А, то и изменение в памяти произойдет в контракте А, а не в контракте В, куда идет вызов.

В данном примере мы видим, что функция setAddress() в контракте В должна обновить переменную owner. Допустим, мы хотим обновить такую же переменную у себя в контракте А.

Сделав вызов функции А::setAddress(), транзакция пройдет успешно, но в А обновится переменная sender, а не owner, как это было запланировано!

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

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


#delegatecall

Программа летнего практического модуля

Сегодня я рад представить вам программу летнего модуля продолжительностью 8 недель!

Это будет крутой курс направленный прежде всего на практику с кодом и формирование правильных привычек разработки смарт контрактов. Вы узнаете не только про популярные стандарты ERC20, ERC721, ERC4626, но и научитесь сами понимать и разбирать менее изнвестные EIP.

Более того изучите популярные паттерны и сможете использовать их в своих проектах.

Это будет очень интенсивный модуль! Итак, программа практического модуля:

Неделя 1

Урок 1. Подготовка рабочего пространства
Урок 2. Плагины и настройки
Урок 3. Терминал, Node JS, NPM
Урок 4. Работа с GitHub

+ Интенсив с нуля для начинающих

Неделя 2

Урок 5. Стандарт ERC20. Разбор кода и EIP
Урок 6. ERC20 от Open Zeppelin
Урок 7. Свой токен и подключение OZ
Урок 8. ERC20. Особенности и разнообразие
Урок 9. ERC20. Проблемы безопасности

Неделя 3

Урок 10. ERC721. Разбор кода и EIP
Урок 11. ERC721. Использование в проектах
Урок 12. ERC721. Проблемы безопасности
Урок 13. Подключение токенов в свой проект

Неделя 4

Урок 14. Hardhat. Подключение и настройка
Урок 15. Hardhat. Подключение контрактов и чтение тестов
Урок 16. Foundry. Настройка и запуск
Урок 17. Foundry. Тесты

Практикум после 1-й части модуля


Неделя 5

Урок 18. Стандарт ERC4626
Урок 19. Стандарт ERC4907
Урок 20. Стандарт ERC6551

Неделя 6

Урок 21. Голландский аукцион
Урок 22. Multisig и Timelock
Урок 23. Commit/reveal
Урок 24. DAO и governance

Неделя 7

Урок 25. Ролевая система в контрактах
Урок 26. Файловый паттерн
Урок 27. Структуры storage
Урок 28. Селекторы функций и поинтеры

Неделя 8

Урок 29. Defi паттерн: стейкинг
Урок 30. Defi паттерн: ликвидации и займы
Урок 31. Базовая безопасность и аудит

Финальный практикум модуля 2

Старт обучения: 1 июля


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

#курс

Проблемы, когда пытаешься учиться сам

Пару месяцев назад, когда я начал на канале разбирать Uniswap V2, у меня появилось дикое желание углубиться в DeFi системы: разобрать их механику, принципы начисления процентов и другие математические операции, я столкнулся с той же проблемой, с какой сталкивался в самом начале своего обучения языку Solidity.

А именно, нет достаточно хорошей структурированной информации по defi протоколам. Такой, ну чтобы, постепенно изучаешь один протокол, переходишь к следующему. Когда идет от простого к сложному, с достаточным количеством объяснений.

Есть куча отдельных статей (спасибо RareSkills!), но собирать все вместе и обрабатывать бывает очень сложно. Я смотрел Compound, а потом такой: "Ну, глянем деривативы DyDx"... И все... И уже собираешь по кусочкам посты из разных уголков сети.

P.S. Если знаете вот прям хорошие статьи разборы по DyDx, Lido, GMX, Renzo, Balancer и других, буду признателен, если поделитесь в комментариях.

Или другой пример, вот изучил ты Uniswap V2 и что дальше лучше смотреть: перейти на Uniswap V3 или посмотреть более простой Balancer V2?

В общем, поиск и структурирование информации порой занимает больше времени, чем само обучение.

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

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

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

Тоже самое и с написание смарт контрактов. Начните с малого и до конца лета получите отличную базу знаний и практики!

Старт курса 1 июля!

#курс

Чем отличается джун от мидла?

Несколько раз этот вопрос был задан в чате в контексте того, что вакансий для джунов сейчас мало и берут, в основном, только мидлов и сеньоров. Так как же стать тем самым мидлом без опыта работы?!

На одной из моих старух работ в студии, у нас была ходила типа поговорка: "Джун знает, мидл практикует, сеньор знает, где погуглить". Думаю, она и сейчас не плохо отражает суть индустрии.

Как я сейчас вижу в вакансиях, для мидлов и джунов практически схожие требования: знание Solidity, понимание работы EVM, умение писать тесты, способность работать с современными стандартами EIP, некоторые знания в безопасности смарт контрактов, ну, и может еще в некоторых случаях знание js, react - для подключения фронта.

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

В некотором роде, эталоном хорошего разработчика можно считать его GitHub профиль и загруженные туда проекты.

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

Что можно сохранять на начальном уровне обучения?

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

2. Ваш первый токен или nft. Написали токен? Создайте файл "ERC20 practice" и тоже загрузите на Git.

3. По сути, изучая каждый новый ERC (подписи, vaults, прокси, и т.д.) вы можете создавать практический проект. Не волнуйтесь за качество своего кода. Так или иначе 100% безопасным его вы не сделаете, но при этом обязательно добавляйте комментарии! Это прям очень важно!

4. Когда вы изучите базис, то можете глянуть этот пост, где я предлагаю несколько проектов для практики: https://news.1rj.ru/str/solidityset/1112 Каждый из них покажет потенциальному работодателю ваши знания и навыки в программировании. А если еще к ним будут приложены хотя бы простые тесты - это сильно повысит шансы на получение работы.

На текущем модуле мы делаем акцент именно на практику. Если вы будете действительно выполнять каждое задание и практикумы, то в итоге в вашем GitHub может появиться более 14 практических проектов! И это за два месяца!

Работы будет очень много! Это будет серьезная прокачка навыков за лето!

Старт уже 1 июля!

#курс

А есть ли интенсивы для мидлов и сеньоров?

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

За весь период своего обучения я погружался во множество различных тем web3 и аудита: от простых CTF до расчетов в DeFi протоколах. Ну, т.е. я хочу сказать, что много знаний уже есть на более-менее базовом уровне. Но вот мне потребовалось на выходных найти информацию по работе с Gnosis Safe: подключение, нюансы безопасности, общая архитектура протокола. И в большинстве статей поисковой выдачи было что-то типа: "Первые упоминания о гречке датированы 8 веком до нашей эры...". Пришлось копаться в официальных доках.

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

А ведь сколько пользы было бы, если бы зарубежные компании выпускали небольшие курсы по определенным темам (например, как RareSkills). Вот мне было бы интересно узнать:

1. Как работает Gnosis Safe;
2. Как подключать OpenSea;
3. Тики Uniswap V3 и хуки Uniswap V4;
4. Абстрактные аккаунты и их безопасность;
5. Особенности деплоя контрактов на разные L2 сети;
6. Безопасные ликвидации в DeFi протоколах;
7. Что такое блобы и их практическое применение сегодня;

и еще много других нишевых тем с разбором документации, кода и вопросов безопасности.

С одной стороны, крутым разработчикам и аудиторам нафиг это не надо записывать интенсивы, но что насчет компаний, которые проводят стримы и обучающие сессии, те же RareSkills, Alchemy, Updraft?

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

А я пошел дальше работать над предстоящим модулем, старт которого уже на следующей неделе!

#обучение

Обучение в потоке

Хочу еще поделиться с вами некоторыми неожиданными открытиями, которые я получил, проведя уже 5 модулей - 4 от первого потока и 1 весенний.

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

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

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

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

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

3. "Мотивация быть в актуальных уроках". Для небольшого количества учеников играла роль небольшая конкуренция на модуле. В том плане, что если ты немного отстал от группы и затем увидел вопрос по актуальному уроку, то был заряд мотивации догнать остальных и идти в ногу.

4. "Профессиональное сообщество". Для многих играло значительную роль, что все они были на одном уровне в изучении Solidity и могли задавать вопросы друг другу. Никто не отвечал "свысока или снисходительно" и каждый для себя находил поддержку в группе.

5. "Структура и экономия времени!". Также для большинства учеников сыграло ключевую роль структурирование информации; многие говорили, что покупают курс только поэтому. Они не хотели сами составлять себе программу, искать информацию по темам и понятия не имели, как практиковаться с кодом. "Зачем я буду тратить половину времени на поиск, когда тут уже все сделано за меня?" - железный аргумент!

Здорово, что у нас получилось собрать столько учеников и пройти этот путь вместе!

У вас все еще есть время присоединиться к потоку!

Программа курса

Старт уже 1 июля!

#курс

На сколько будет доступ к каналу и материалам?

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

Как мне объяснил один из учеников, на некоторых других курсах, что он проходил, доступ к материалам был ограничен. Порой это был всего один месяц после завершения модуля, чаще - 3-6 месяцев. И если ты не успевал, то все - жди следующего запуска и покупай заново.

Ну, и, конечно, понятно волнение многих: "А что будет, если я не успею пройти модуль вместе со всеми? У меня же еще работа (учеба, дом, семья и т.д.). Могу ли в своем темпе проходить?".

Именно поэтому отвечаю на все эти вопросы в одном отдельном посте.

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

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

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

Надеюсь, теперь вам будет проще решиться для себя попробовать этот модуль.

Программа курса

Старт уже в понедельник!

#курс

Solidity hints. Часть 5

Спасибо всем, кто пережил неделю продаж и остался на канале, понимаю что для многих это действительно испытание. Мы возвращаемся в рабочий ритм и потихоньку продолжаем разбирать репо от Chinmaya, который делал свои заметки по Solidity во время своего обучения. И следующий пункт:

6. enum types are not part of the ABI, they are just a solidity abstraction

Тип данных enum не является частью ABI, это всего лишь абстракция Solidity.

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

Enum требуют наличия хотя бы одного значения и не могут иметь более 256 значений, что фактически означает равенство к типу данных uint8 (так он и будет отображаться в ABI).

Когда мы создаем enum, например:

enum ActionChoices { GoLeft, GoRight, GoStraight, SitStill }
ActionChoices choice;

а затем хотим получить значение choice:

function getChoice() public view returns (ActionChoices) {
    return choice;
}

в некотором роде, функция будет выглядеть как

getChoice() returns (uint8)

Значения в enum начинаются с 0, и если не установлено какое-либо другое значение, то функция или запрос к переменной вернем именно ноль. За этим необходимо следить в функциях, где от условия enum зависит ход ее исполнения.


7. Delete keyword is simply a reassignment of elements to their default values (ie.zero)

Ключевой метод delete в функциях фактически обнуляет значение, а не удаляет его.

При изучении Solidity нам часто говорили, что тут нельзя создать ни один тип данных с пустым или несуществующим значением. Например:

- boolean: false

- string: ""

- int / uint / enum: 0

- address: 0x0000000000000000000000000000000000000000 (or address(0))

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

#enum #default

Solidity hints. Часть 6

О, сегодня будет один интересный пункт, который порой упускают из виду даже опытные разработчики, и связан он с темой низкоуровневого вызова call.

8. call bypasses function existence check, type checking and argument packing

Вызов call пропускает проверку существования функции, проверку типа данных и упаковку аргументов. Что это означает?

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

Отправь его и он уйдет без вопросов...

Даже в самой документации есть специальная сноска по этому поводу:

The low-level functions call, delegatecall and staticcall return true as their first return value if the account called is non-existent, as part of the design of the EVM. Account existence must be checked prior to calling if needed.

Грубо говоря, что низкоуровневые языки всегда будут возвращать true как первое возвратное значение, даже если аккаунт, на который идет вызов, не существует. Так заложено в EVM и проверка на существование аккаунта ложится на плечи разработчика.

Также и с функциями. Посмотрите на два контракта:

contract Caller {

    function testCallFoo(address payable _addr) public payable {
        (bool success, bytes memory data) = _addr.call{
            value: msg.value,
            gas: 5000
        }(abi.encodeWithSignature("foo(string,uint256)", "call foo", 123));

    }

    function testCallDoesNotExist(address payable _addr) public payable {
        (bool success, bytes memory data) = _addr.call{value: msg.value}(
            abi.encodeWithSignature("doesNotExist()")
        );

    }
}

contract Receiver {
    event Received(address caller, uint256 amount, string message);

    fallback() external payable {
        emit Received(msg.sender, msg.value, "Fallback was called");
    }

    function foo(string memory _message, uint256 _x)
        public
        payable
        returns (uint256)
    {
        emit Received(msg.sender, msg.value, _message);

        return _x + 1;
    }
}

Из контракта caller мы делаем вызовы во второй контракт. И что самое удивительное, обе функции сработают с call, учитывая то, что в receiver нет функции doesNotExist(), которую мы пытаемся вызвать через testCallDoesNotExist().

А если убрать fallback(), куда падает вызов несуществующих функций, наш call все равно не откатится.

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

Кстати, для этих целей есть abi.encodeCall - который практически тоже самое, что и abi.encode, но только добавляет проверку типов данных на соответствие функции, которая была указана в аргументах. Результат кодирования схож с abi.encodeWithSelector.

Подводя итоги можно сказать сказать общепринятые правила в использовании call:

1. Всегда проверять успешность возвращаемого значения;
2. Знать наверняка или самому контролировать вопрос существования адреса, куда отправляется вызов;
3. Проверять правильность кодирования данных при отправке;

Это если и не избавит вас на 100% от ошибок и проблем с call вызовов, но значительно сократить их шанс.

Будьте аккуратны с низкоуровневыми вызовами!

#call

Solidity hints. Часть 7

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

9. The evm considers a call to non-existing contract to always succeed, so there is a check of extcodesize > 0 when making an external call. But call, staticcall, delegatecall, send, transfer do not include this check

11. extcodesize > 0 check is skipped by the compiler if the function call expects return data. the ABI decoder will catch the case of a non-existing contract Because such calls are followed up by abi decoding the return data, which has a check for returndatasize is being at least a non-zero number. So for empty contracts, they would always revert in the end.

Для начала необходимо разобраться вообще за что отвечает excodesize.

excodesize - это специальный опкод EVM, который проверяет, есть ли код у данного адреса или нет. Если код есть, то данный адрес является контрактом.

P.S. Далее прошу более опытных читателей канала поправить меня, если будут неточности.

Когда мы используем низкоуровневые вызовы, такие как call(), delegatecall(), send() и transfer() проверка на существование контракта опускается, т.е. excodesize не исполняется где-то в середине вызова, и EVM считает, что этот вызов по-любому успешный.

При этом, когда мы дополняем такие вызовы проверкой на успешность (bool success,), мы получаем специальные методы, которые могут дать понять, что вызов обвалился на каком-либо этапе. Делается это с помощью другого опкода returndatasize, который отвечает за возвращаемые данные после вызова.

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

contract Victim {

   bool public tricked; 

   function isContract(address _addToEval) public view returns(bool){
     // The code is only stored at the end of the
     // constructor execution. 
     //Thus extcodesize returns 0 for contracts in construction
     uint32 size;
     assembly {
       size := extcodesize(_addToEval)
     }
     return (size > 0);
   }

 function supposedToBeProtected() external {
  require(!isContract(msg.sender), "caller is not an EOA");
        tricked = true;
 }

}

contract Attacker {
  
   bool public successfulAttack;
   Victim v;
  
   constructor(address _v) {
       v = Victim(_v);
       // address(this) doesn't have code, yet. Thus, it will bypass 
       //isContract() check 
       v.supposedToBeProtected();
       //tricked was set to true on the above execution
       successfulAttack = v.tricked(); 
   }
}

Функцию supposedToBeProtected() должен вызывать только пользовательский адрес. Но с помощью конструктора хакер может обойти эту проверку.

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

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

#excodesize

Немного наблюдений из мира web3

"Привет всем аллергикам! Я с вами!" - именно так хочется начать этот пост, потому что уже несколько дней вместе с адской жарой в 36-37 градусов приходит и сезонная аллергия. Помимо того, что у тебя постоянно забит нос, так еще и фокусирование на информации нет никакого.

Пытаюсь вникнуть в код - и такой "а что такое uint?..", читаю репорты и просто не могу связать А с В. Короче, в следующем году надо планировать отпуск на весь этот сезон.

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

Вначале пара слов про тестирование смарт контрактов.

Осенью прошлого года я писал, что с развитием Foundry и любовью разработчиков к нему, придет новая профессия - тестировщик. И здесь я имел ввиду не разработчик - тестировщик, а именно отдельную специальность; людей, который будут только лишь писать разнообразные тесты для протоколов: юнит, фазз, инфариант и fv. В некотором роде, я оказался прав.

В компаниях, которые работали над собственным проектом, тесты писали и пишут сами разработчики. Но появились другие компании, тот же Trail of Bits, которые стали предлагать написание тестов, как услугу. Позже к ним присоединились и частные разработчики, которые предлагают нишевое тестирование: инварианты или формальную верификацию.

Открылся проект - Recon - от мощных аудиторов, который предлагает сервис по написанию инвариант тестов вкупе с программами Медуза и Foundry.

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

Или может инварианты и формальная верификации прерогатива крупных протоколов с хорошим финансированием?

Также, большую часть выходящих на конкурсные аудиты протоколов, составляют проекты в сфере DeFi. А в Твиттере в постах разработчиков и безопасников чаще появляются посты на тему расчетов, токеномики и финансовых механизмов.

Я бы сказал, что простые токены или NFT уже не так сильно интересны сообществу, как год-два назад. Многие хотят каким-либо образом "прикрутить" DeFi или даже GameFi к своим протоколам.

P.S. Я за игровой индустрией не очень слежу, поэтому приветствуются комментарии на эту тему.

В DeFi сейчас осваиваются темы интеграций с другими крупными протоколами, типа Uniswap, Lido, Aave, а также базовые механики ликвидаций и стейкинга ликвидности. Реже, когда проекты смотрят на деривативы или опционы.

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

В конкурсных аудитах также есть некоторые обновления.

Если раньше на конкурс выходили более простые протоколы, то сейчас стали появляться все чаще миллионники: то Euler, то MakerDao, то еще пара штук в прошлом году. Да, и более профессиональные протоколы, как Uniswap или Chainlink, облюбовали этот способ аудита.

Только на мой взгляд, это, скорее, не конкурсный аудит, а багбаунти ограниченное по времени. Такие протоколы зачастую прошли не один профессиональный аудит от топовых фирм (Spearbit, ToB, etc), поисправляли все что можно, и теперь хотят собрать массовый фидбек.

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

А что вы замечаете на рынке контрактов и аудитов? Куда, думаете, движется сфера web3?

#trend

Solidity hints. Часть 7

Понемногу выходим из состояния выходного дня и возвращаемся к работе, несмотря на лето и дару в 38...

Сегодня у нас по плану очередной пункт из репо Chinmaya и звучит он как:

10. On receiving funds from a selfdestruct / coinbase miner reward, the contract can not react to it, and it doesn’t require a contract to have receive or fallback functions.

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

Для того, чтобы контракт мог принимать нативный токен - Эфир - на свой счет, в нем должны быть функции receive или fallback, или какая-либо другая с модификатором payable. Однако существуют способы пополнить счет контракта, даже если он напрямую запрещает это.

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

Второй вариант - уничтожение контракта через selfdestruct. Другими словами, вы можете уничтожить свой контракт, на котором есть Эфир на балансе, и указать адрес другого контракта в сети. В этом случае тот также получит активы на свой счет, даже если нет необходимых функций.

Интересный факт о selfdestruct. Несмотря на то, что он был фактически упразднен при Шанхайском обновлении и его использование не рекомендуется в текущих версиях Solidity, начиная с 0.8.24 эту функцию можно использовать только в момент создания контракта (EIP-6780).

Звучит немного странно, но объясню, что это значит.

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

На самом деле, я пока не встречал практического применения создания/уничтожения контракта в одной функции в реальных протоколах, но уже были найдены уязвимости на этом поле! Удивительно, но факт!

Как думаете, в каких случаях можно использовать selfdestruct?

#selfdestruct

Программа Smart Contract Security Specialist

Друзья из Statemind попросили поделиться информацией об их fellowship программе Smart Contract Security Specialist, на которую сейчас проходит отбор.

Для того чтобы попасть в программу, вам нужно будет заполнить анкету и пройти небольшой тест. Он не для новичков в Solidity и в программировании в целом. Скорее подойдет для тех, кто с математикой на короткой ноге.

Немного о самом обучении:

• Обучение онлайн
• Длительность 4 недели
• Обучение на английском/русском языках
• Отбор проводим по входному тесту (в форме)
• После успешного прохождения программы проводим интервью и по результатам предлагаем возможность присоединиться к нашей команде в качестве интерна (мы работаем удаленно)
• Обучение с нашей стороны бесплатное, потому что основная наша задача - найти единомышленников, c которыми мы в дальнейшем будем работать над интересными проектами
• Помогаем с релокацией
• Поддерживаем с обучением и развитием (английский язык, ресерчи, тулзы)
В программе курса
• Introduction to blockchain
• DeFi primitives
• DeFi security

Подробная информация и форма для заполнения для тех, кому будет интересно
https://docs.google.com/forms/d/1fo1FtehBqyIzhp-8FVcfSiZbUZWap1nexAP7UYXT9hc/edit

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

#fellowship

Solidity hints. Часть 8

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

12. Always send 1 wei to precompiled contracts to activate them when testing in private blockchains, otherwise it may lead to OOG

Всегда отправляйте 1 wei на precompiled контракты в приватных сетях, чтобы активировать их и избежать ошибки OOG.

Для начала нужно разобраться, что такое precompiled контракты и OOG.

OOG - out of gas - ошибка, которая возникает в транзакции, когда расходуется больше газа, чем было разрешено.

Далее чуть сложнее, обратившись в yellow pages сети мы можем узнать, что

Precompiled контракты - это контракты, предназначенные для предварительной разработки архитектуры сети, которая впоследствии может стать родным расширением. Четыре контракта в адресах 1, 2, 3 и 4 выполняют функцию восстановления открытого ключа по эллиптической кривой, 256-битную хэш-схему SHA2, 160-битную хэш-схему RIPEMD и функцию идентификации соответственно.

Как я понял, на данный момент всего 9 таких контрактов:

1. Recovery of ECDSA signature
2. Hash function SHA256
3. Hash function RIPEMD160
4. Identity
5. Modular exponentiation (EIP 198)
6. Addition on elliptic curve alt_bn128 (EIP 196)
7. Scalar multiplication on elliptic curve alt_bn128 (EIP 196)
8. Checking a pairing equation on curve alt_bn128 (EIP 197)
9. BLAKE2b hash function (EIP 152)

А в этой статье можно прочитать больше о первых 4 контрактах:

https://medium.com/@rbkhmrcr/precompiles-solidity-e5d29bd428c4

А тут обо всех 9:

https://www.rareskills.io/post/solidity-precompiles

Далее по пункту, что мы разбираем, можно найти упоминание в официальной документации Solidity:

При выполнении функций sha256, ripemd160 или ecrecover на приватном блокчейне вы можете столкнуться с проблемой Out-of-Gas. Это происходит потому, что эти функции реализованы как "прекомпилированные контракты" и реально существуют только после получения первого сообщения (хотя код их контрактов жестко закодирован). Сообщения несуществующим контрактам стоят дороже, и поэтому при выполнении может возникнуть ошибка Out-of-Gas. Обходной путь решения этой проблемы - сначала отправить Wei (например, 1) каждому из контрактов, прежде чем использовать их в своих реальных контрактах.

Как я понял, precompiled контракты - это не совсем обычные контракты, которые мы с вами пишем на Solidity. Это специальные контракты, которые являются частью самой сети, и используются для каких-либо конкретных действий. Например, для восстановления подписи через ecrecover!

За весь период своего обучения всего пару раз сталкивался с этой темой и сегодня было достаточно интересно "покопаться в доках" и узнать немного нового.

#precompile

Solidity hints. Часть 9

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

13. Functions called from within an unchecked block do not inherit the property. Bitwise operators do not perform overflow or underflow checks

Функции, вызываемые из unchecked блока, не наследуют это свойство. Побитовые операторы не выполняют проверку на переполнение или недополнение.

Unchecked блок по своей задаче не выполняет проверки на overflow, поэтому если мы в функции:

    function g(uint a, uint b) pure public returns (uint) {
        return a - b;
    }

вычтем 3-4, то вернется огромное число приближенное к максимальному значению uint256.

Однако... Посмотрите на этот вариант:

contract Test {
function unsafe_subtract(uint a, uint b) pure public returns (uint) {
    unchecked {
      return subtract(a,b);
    }
  }

  function subtract(uint a, uint b) pure public returns (uint) {
    return a - b;
  }
}

в этом случае, несмотря на то, что исполнение функции subtract() происходит в unchecked блоке, проверка на переполнение будет все равно выполнена. Другими словами функция в блоке не будет наследовать от unchecked игнор проверки overflow.

Также, если мы используем побитовые операции или исполнение функции в assembly блоках, то в них НЕ будет проверки на переполнение.

#overflow

Solidity hints. Часть 10

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

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

А на канале мы продолжаем разбирать пункты из репо Chinmaya, и сегодня у нас по счету уже 14:

14. After a failed call, Do not assume that the error message is coming directly from the called contract: The error might have happened deeper down in the call chain and the called contract just forwarded it (bubbling up of errors)

что в переводе:

После неудачного вызова не думайте, что сообщение об ошибке пришло непосредственно от вызванного контракта: ошибка могла произойти глубже в цепочке вызовов, а вызванный контракт просто переслал ее.

В простых протоколах обычно вызовы могут идти в "соседний" контракт, например:

Контракт А => Контракт В

В более сложных протоколах, каких-нибудь DeFi, эти вызовы могут проходить через несколько контрактов, или даже протоколов:

А => В => С => А => Е

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

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

15. Calling a function on a different contract (instance) will perform an EVM function call and thus switch the context such that state variables in the calling contract are inaccessible during that call (except if you use delegatecall)

и перевод:

Вызов функции на другом контракте выполнит вызов функции EVM и, таким образом, переключит контекст так, что переменные состояния в вызывающем контракте будут недоступны во время этого вызова (не считая использования delegatecall)

Тут также все достаточно просто. Например, если мы делаем вызов из контракта А в контракт В, то переменные контракта А будут недоступны для изменения в контракте В, так как вызов "переключится" контекстом на В.

Еще проще, допустим у нас есть переменная owner в А. Мы делаем вызов из А в В и там вызываем функцию для изменения адреса владельца.

И несмотря на то, что вызов идет через А, переменная будет изменения в В.

При этом, если мы используем функция с delegatecall в А, делая вызов в В, то мы "как бы захватываем" функцию из В, переносим ее в А и изменяем уже состояние в памяти А.

Звучит немного запутано, но стоит разобраться с call() и delegatecall(), как все встанет на свои места!

#solidity #call #delegatecall

Solidity hints. Часть 11

Фух, лето... В моем городе на солнце уже +42, работать даже под кондиционером достаточно сложно. Но мы все равно понемногу повторяем азы Solidity, и переходим к следующему пункту:

16. After contract creation, The deployed code does not include the constructor code or internal functions only called from the constructor

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

Как вы можете уже знать, что при деплое контракта его код разделяется на две части: init code и runtime code. Например, возьмем самый простой контракт:

pragma solidity 0.8.17;// optimizer: 200 runscontract Minimal {
    constructor() payable {

    }
}

Когда мы выполним деплой контракта, его байткод будет следующим:

0x6080604052603f8060116000396000f3fe6080604052600080fdfea2646970667358221220d03248cf82928931c158551724bebac67e407e6f3f324f930c4cf1c36e16328764736f6c63430008110033

И можно разделить его на:

init code - 0x6080604052603f8060116000396000f3fe

runtime code - 6080604052600080fdfea2646970667358221220d03248cf82928931c158551724bebac67e407e6f3f324f930c4cf1c36e16328764736f6c63430008110033

P.S. Весь байткод, по сути, это перечисление опкодов и значений для него, но это слишком сложная тема для обсуждения в данном посте.

Вот этот вот runtime code появляется после выполнения init code и является уже нашим смарт контрактом, в котором мы можем вызывать различные функции.

В обсуждаемом пункте говорится о том, что действия контракта в конструкторе не включаются в итоговый код runtime, а используются исключительно в init code, в моменте создания самого контракта.

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

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

Ethereum smart contract creation code

#creationcode #runtime #init

Solidity hints. Часть 12

Сегодня чуть припозднился с постом. Иногда в репо встречаются какие-то обрывки из правил, и я трачу время, чтобы понять:

1) О чем вообще идет речь?
2) Откуда это он взял?

И вот сейчас пункт звучит:

17. Dont use this.f inside constructor

Кто это вообще использует? Я за все время ни разу не встречал в конструкторах this, а знаете почему?

Потому что его вообще нельзя использовать там!

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

Ну, в общем, рассказываю, что-о-чем тут.

Он читал официальные доки Solidity и встретил комментарий к коду:

State variables are accessed via their name and not via e.g. `this.owner`. Functions can be accessed directly or through `this.f`, but the latter provides an external view to the function. Especially in the constructor, you should not access functions externally, because the function does not exist yet.

Немного запутано написано, но я понял, что this, в этом случае, как бы выполняет вызов в функцию из вне создаваемого контракта, и так как последняя еще не существует, он выдает об этом ошибку.

При этом, если использовать туже функцию, но без this, то все работает нормально. Например:

contract TestThis {

    uint256 private num;

    // не работает
    constructor() {
        num = this.increment();
    }

    function increment() internal view returns(uint256){
        return  num + 5;
    }
}

contract TestThis {

    uint256 private num;

    // работает
    constructor() {
        num = increment();
    }

    function increment() internal view returns(uint256){
        return  num + 5;
    }
}

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

Ну, и еще один пункт напоследок:

18. Internal is the default visibility level for state variables.

Тут все просто, у каждого типа данных в Solidity есть некое значение по-умолчанию. У uint - это 0, у bool - false и т.д.

И у каждой переменной состояния есть область видимости: public, external, internal и private. Если мы не указываем нужную нам область, то по умолчанию устанавливается internal, что запрещает обращаться к ней из других внешних контрактов.

#constructor #visibility

Solidity hints. Часть 13

Понемногу движемся дальше и сегодня на очереди у нас:

19. Internal function calls do not create an EVM message call. They are called using simple jump statements. Same for functions of inherited contracts.

что в переводе:

Internal функции не создают EVM вызов, а используют внутренние опкоды jump. Тоже самое актуально и для наследуемых контрактов.

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

У нас есть 4 области видимости для функций: public, external, internal и private. Первые две - открытые для доступа других контрактов, вторые - закрыты.

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

Доступ к внутренним функциям возможен только внутри текущего контракта или контрактов, вытекающих из него. Они не могут быть доступны извне. Поскольку они не открыты для внешнего доступа через ABI контракта, они могут принимать параметры внутренних типов, таких как mapping или storage references.

Внутренние функции вызываются через инструкции опкоды JUMP / JUMPI, просто перепрыгивая в другую точку текущего кода. Это имеет смысл, потому что внутренние функции не меняют контекст (то есть остаются внутри одного и того же контракта при вызове).

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

Думаю, можно подытожить: если мы можем вызывать функцию извне, то это EVM вызов, если же она предназначена только для внутреннего использования - то это работа опкодов.

Следующий пункт:

20. If you have a public state variable of array type, then you can only retrieve single elements of the array via the generated getter function.

что в переводе и полной версии из документации звучит как:

Если у вас есть публичная переменная состояния типа массив, то вы можете получить только отдельные элементы массива через сгенерированную функцию getter. Этот механизм существует для того, чтобы избежать высоких газовых затрат при возврате целого массива. Вы можете использовать аргументы, чтобы указать, какой отдельный элемент возвращать, например myArray(0). Если вы хотите вернуть весь массив за один вызов, то вам нужно написать функцию, например:

contract arrayExample {

    uint[] public myArray;
    function myArray(uint i) public view returns (uint) {
        return myArray[i];
    }

    function getArray() public view returns (uint[] memory) {
        return myArray;
    }
}

Также немного запутанный пункт и документация для начинающих разработчиков.

Смотрите, когда мы создаем переменную с областью видимости public, EVM также создает для нее специальный геттер, по которому можно прочитать значение этой переменной. Проще всего это будет понять, попытавшись создать в Ремиксе контракт с двумя переменными public и internal.

Для первой переменной у вас появится кнопка в левой панели Ремикса, для того чтобы посмотреть ее значение, но для internal - ее не будет.

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

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

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

#array #getter #jump #external