Манипуляция оракулами

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

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

awesome-oracle-manipulation

P.S. Возможно, вы его уже видели на других каналах, но тут я еще не выкладывал.

#oracle #manipulation

Уязвимость в древе Мерка в Open Zeppelin

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

Так получилось и с их контрактом древа Меркла.

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

В общем, Daniel Cohen Hillel нашел проблему в контракте OZ, сообщил в компанию и сделал разбор с показательными видео.

Ветка в Твиттер с разбором уязвимости

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

#merkle #tree #merkletree #oz

Код - это не только ход, но и состояние

Не могу молчать.

Вышел аудиторский отчет по конкурсы Ajna, в котором я хотел поучаствовать, но ничего не нашел. А там 11 High и 14 Med проблем!

Я читаю отчет и такой постоянно: "Ну, блин! Я же мог такое найти! Ну, блин...". И такая досада берет.

А все потому, что я постоянно забываю, что код контракта - это не просто вектор выполнения проверок и функций в нем, а еще и состояние памяти на момент исполнения! Сейчас постараюсь объяснить, что я имею ввиду.

Мы привыкли искать уязвимости в коде по нескольким общим критериям:

1. Наличие необходимых проверок перед исполнением функций;
2. Валидация аргументов в функции;
3. Контроль доступа;
4. Наличие проблемных зон в подключенных контрактах и проектах;
5. Переменные и инварианты;

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

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

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

Пошел дальше читать отчет и учиться на ошибках...

P.S. Отчет Ajna, для любопытствующих.

#audit

Заметка про Uniswap V4

Да, я опоздал на пару недель с момента выхода новости о V4. Тем не менее, многие могли упустить этот момент или как-то не правильно понять. Я постарался собрать свои сохранения и выделить их в один пост.

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

1. Хуки. Это некий функционал, который позволяет реализовать для пулов ликвидности совершенно новые функции вроде динамической корректировки комиссий, создания различных типов ордеров (например, лимитных), автоматические депозиты для протоколов кредитования и многое другое.

2. TWAMM (A time-weighted average market maker, средневзвешенный по времени маркетмейкер). Разработчики смогут создавать TWAMM, которые позволят пользователям продавать большие объемы криптовалюты небольшими партиями с течением времени. Это может помочь трейдерам избежать опережения ботов EVM или неблагоприятных колебаний цен. Также будут возможны лимитные ордера на блокчейне, поскольку пулы смогут включать логику, которая позволяет им выполнять ордер только тогда, когда цена токена достигает определенного значения.

3. Singleton. В Uniswap v3 для каждого пула развертывается отдельный смарт-контракт. В v4 для этого будет использоваться один контракт.

P.S. Привет, Balancer v2!

4. Экономия газа и гибкость. Благодаря новой архитектуре проекта и Singleton контракту будет достигнута невероятная экономия газа, по сравнению с контрактами V3. Более того, это также позволит избежать перерасхода газа на роутинг транзакций и управление ликвидностью пула.

5. ERC1155 вместо ERC721 будут использоваться минта позиций в LP и другого функционала.

6. DAO. V4 также будет управляться Uniswap DAO и будет включать переключатель protocol-fee, который может быть активирован держателями $UNI для каждого пула.

7. Поддержка ETH. Теперь V4 может работать в парах с нативным Эфиром вместо WETH, что также облегчает торговлю и снижает затраты.

При этом всем некоторые пользователи критикуют Uniswap по основным двум моментам:

1. Не смотря на то, что протокол позиционирует себя как полностью opensource, в V4 предусмотрена лицензия ограничения использования кода до 2027 года (BSL license).

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

Ссылка на Uniswap V4-core.

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

Посмотрим, что из этого получится.

P.S. Если у вас еще что-то ест добавить, оставьте комментарий. Будет интересно почитать. Новость-то уже не новая...

#uniswap #v4

Двойной overflow

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

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

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

Ссылка на статью.

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

#overflow

Организация prank в Foundry

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

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

vm.startPrank(user);

и в завершении:

vm.stopPrank();

Порой для тестов это приходится прописывать довольно часто. Так вот, в этом контракте придумали поместить это все в модификатор:

modifier prank(address from) {
  vm.startPrank(from);
  _;
  vm.stopPrank();
}

А потом использовать его, как обычно, в функциях:

function test_addLiquidity() public prank(user) {}

На мой взгляд достаточно элегантное решение.

#foundry #test #modifier #prank

Работа с памятью в Solidity. Большой сборник

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

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


На русском языке:

1. Большая заметка канала по работе с памятью. Тут я собрал краткие сведения по storage, memory, stack и code для удобства.

2. Структура. Хранение данных. Видео с канала Ильи

3. Memory и calldata. Видео с канала Ильи

4. Динамические массивы и мэппинги в storage. Видео с канала Ильи


На английском языке:

5. Solidity Tutorial: All About Stack

6. Understanding Ethereum Smart Contract Storage

7. Solidity Tutorial: All About Calldata

8. Solidity Tutorial: All About Code

9. Solidity Tutorial: All About Memory

10. All About Solidity Data Locations — Storage

11. Solidity Tutorial: All About Data Locations

12. Guide To Advanced Calldata


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

Приятного обучения и хорошей недели!

#storage #memory #stack #code #calldata

Чаты и каналы

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

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

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

Итак, поехали:


Чаты на тему разработки:

1. Solidity DEV (Ethereum)

2. Ethereum Ru - самый большой чат

3. Ethereum Newbie

4. Ethereum — Jobs & CVs - тут, кстати, можно найти вакансии

5. крипта и web3 чат

6. Learn solidity audit - тут можно задавать вопросы по аудиту и безопасности

7. DEV: Рубиновые тона: ЧАТ - чат от канала Ильи


Пара классных каналов:

8. Kotya security

9. Rektoff Foundation

10. DEFI Scam Check

11. Officer's Channel

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

#chat

🌟🌟🌟 День Рождения канала! 🌟🌟🌟

Сегодня ровно год, как был создан этот канал!

Когда только появилась идея учить Solidity в группе, я был абсолютно уверен, что это будет всего лишь до конца лета. Открывая канал, я был в полной уверенности, что к осени закрою его. Но все пошло куда интереснее!

На сегодняшний момент вышло более 800 постов! Практически 2,5 поста в день в течение года! Да, у меня были и недельные каникулы тишины на канале, но порой тут выходило и по 18 постов в день. До сих пор не могу поверить!

За этот год вместе с вами я прошел путь с нуля до аудитора, ежедневно обучаясь шаг за шагом. Возможно, это лучшее подтверждение принципа "Лучше регулярно, чем интенсивно".

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

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

С Днем Рождения, друзья!

Интересный баг в протоколе EigenLayer

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

Вот ссылка на него.

Дело в том, что разработчики создавали цикл for и уже внутри него были условия if/esle. И если для условия else они поставили ++i, т.е. переход на следующий шаг цикла, то для if условия - забыли. В итоге получилось, что цикл исполнялся один раз в if, что приводило к проблемам в дальнейшем коде.

Много раз встречал, что для экономии газа, инкремент прохода в цикл лучше ставить в unchecked в конце кода вместо установки его в аргументах for, но никогда не задумывался, что может однажды случиться такой прецедент.

Будьте внимательны с циклами!

#for #loop

Контроль доступа и голосование за предложения

Интересную реализацию задумки голосования встретил в конкурсном протоколе Axelar. Опишу кратко.

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

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

В Axelar голосование происходит в модификаторе!

P.S. Я сделаю более упрощенное описание процедуры для понимания ее сути.

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

Далее авторизованным пользователям можно вызывать функцию, типа как:

function execute(
address target,
bytes calldata callData,
uint256 nativeValue
) external payable onlySigners {
...
}

Обратите внимание на модификатор onlySigners, там и происходит все действие!

modifier onlySigners() {
if (!signers.isSigner[msg.sender]) revert NotSigner();

bytes32 topic = keccak256(msg.data);
Voting storage voting = votingPerTopic[signerEpoch][topic];

if (voting.hasVoted[msg.sender]) revert AlreadyVoted();

voting.hasVoted[msg.sender] = true;

uint256 voteCount = voting.voteCount + 1;

if (voteCount < signers.threshold) {
voting.voteCount = voteCount;
return;
}

voting.voteCount = 0;

uint256 count = signers.accounts.length;

for (uint256 i; i < count; ++i) {
voting.hasVoted[signers.accounts[i]] = false;
}

emit MultisigOperationExecuted(topic);

_;
}

Другими словами, в модификаторе мы проверяем авторизацию пользователя, через аргументы в функции execute мы передаем данные по предложению в msg.data, который позже вытаскивается из памяти контракта.

Далее фиксируется голос пользователя. Если проходного минимума не хватает, то идет return и до выполнения самой функции execute дело не доходит!

Если же голоса набраны, то модификатор делает свое дело и execute срабатывает!

По моему, сделано прикольно! Такого я еще ни разу не видел.

#modifier

Вышла новая версия Solidity - 0.8.21

Вчера была выпущена новая версия Solidity с большим количеством исправлений текущих багов и некоторыми улучшениями. Основные из них это:

1. Доступ к событиям из контракта. Как мы знаем, ранее доступ к событиям можно было получить через специальный журнал событий, используя разные библиотеки, например ethers.js. Теперь контракты могут брать события через emit Contract.EventName() из внешних контрактов/либ/интерфейсов.

2. Упрощения для установки immutable переменных. Ранее имелись проблемы с установкой таких переменных через try/catch или for циклов. Теперь вы также можете указать их значение изначально в контракте, а затем переустановить в конструкторе. Более того были поправлены и другие баги связанные с их инициализацией.

3. Исправлены ошибки в Code Generator и Yul Optimizer.

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

#solidity

Различные abi.encode

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

1. abi.encode - кодирует параметры, используя ABI specs. Сами закодированные параметры занимают по 32 байта. Возвращает байтовый массив данных. Если мы, к примеру, попробуем зашифровать строку "Hello" через abi.encode, то получим следующие зашифрованные данные:

1. Первые 32 байта - это, так называемый, offset (смещение), которые указывает, где начинаются данные.
2. Вторые 32 байта - размер строки.
3. Третьи 32 байта - значение строки.

Пример:

function getEncode(address _add, uint256 _value) pure public returns(bytes memory){
return abi.encode(_add, _value);
}

2. abi.encodePacked - тоже, что и abi.encode, только параметры пакуются, чтобы занимать меньше места. Например, если мы зашифруем туже строку "Hello", то вместо 3 слотов по 32 байта, получим всего 1 слот со значением строки.

function getEncodePacked(address _add, uint256 _value) pure public returns(bytes memory){
return abi.encodePacked(_add, _value);
}

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

3. abi.encodeWithSignature - тоже, что и abi.encode, но добавляется еще подпись функции, как первый параметр.

function getEncodeWithSignature(address _add, uint256 _value) pure public returns(bytes memory){
bytes memory data = abi.encodeWithSignature("transfer(address,uint)",_add,_value);
return data;
}

4. abi.encodeWithSelector - тоже, что и abi.encode, но добавляется еще селектор функции, как первый параметр. Сам селектор кодируется с помощью keccak256 и берутся первые 4 байта.

function getEncodeWithSelector(address _add,uint256 _value) pure public returns(bytes memory){
bytes4 selector = bytes4(keccak256(bytes("transfer(address,uint)")));
bytes memory data = abi.encodeWithSelector(selector,_add,_value );
return data;
}

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

function encodeCallData(address _to, uint _value) public pure returns (bytes memory) {
return abi.encodeCall(IERC20.transfer, (_to, _value));
}

6. abi.decode() - служит для расшифровывания байтовых массивов указанных выше. Принимает в качестве аргументов байтовый массив и ожидаемые типы данных.

function decodeData(bytes memory data) pure public returns(address, uint256){
(address add, uint256 value) = abi.decode(data, (address,uint256));
return (add,value);
}

Вроде как, вспомнил все abi.encode. Если что-то забыл или успели появиться новые с обновлениями языка, дайте знать в комментах.

#abi #encode

Организация storage в прокси контракте

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

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

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

Итак, у нас есть прокси контакт - NFTBoostVault, который наследует функции от двух библиотек, которые и позволяют работать с памятью контракта так, чтобы при обновлениях не было коллизии в данных - Storage и NFTBoostVaultStorage.

Примечательно здесь то, что базовые типы данных, например address и uint, которые не поддерживают определенные места хранения в storage (как mapping), хранятся в структуре с одноименным названием, например:

struct Address {
address data;
}

Так в конструкторе или функции мы можем установить / обновить для них значения с помощью:

Storage.set(Storage.uint256Ptr("locked"), 1);

где Storage.uint256Ptr("locked") - место в памяти, а 1 - значения для установки.

Или также для типов address:

Storage.set(Storage.addressPtr("manager"), manager);

где manager - тип address из аргументов функции.

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

function getIsLocked() public view override returns (uint256) {
return Storage.uint256Ptr("locked").data;
}

т.е. мы запрашиваем в storage слот с хешем uint256Ptr("locked") и достаем оттуда необходимые данные.

Но еще интереснее дела обстоят с работой mapping. Посмотрите на следующий код:

NFTBoostVaultStorage.Registration storage registration = _getRegistrations()[msg.sender];

Здесь мы достаем структурные данные из памяти, которые хранятся в виде mapping! Вот его другие функции:

function _getRegistrations() internal pure returns (mapping(address => NFTBoostVaultStorage.Registration) storage) {
return NFTBoostVaultStorage.mappingAddressToRegistrationPtr("registrations");
}

function mappingAddressToRegistrationPtr(
string memory name
) internal pure returns (mapping(address => Registration) storage data) {
bytes32 offset = keccak256(abi.encodePacked(REGISTRATION_TYPEHASH, name));
assembly {
data.slot := offset
}
}

Я и сейчас на 100% не уверен как работает "под капотом" преобразование данные в _getRegistrations()[msg.sender], так, чтобы получился mapping. Но выглядит интересно.

Solidity не перестает меня удивлять!

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

P.S. Отдельное спасибо @elawbek, что помог мне чуть лучше понять, как это все работает.

#storage #mapping #proxy

RACE #19 Of The Secureum Bootcamp

Ранее, в начале июля, прошел 19 Race, создателем которого стал популярных аудитор Pashov. Только сейчас получилось добраться до конкурса из-за большой нагрузки этого лета, и могу сказать, что это довольно интересный тест, скорее, на внимательность, чем знание каких-либо нюансов языка.

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

Ссылка на Race 19.

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

#race

Двойной тернарный

Вчера узнал, что в Solidity можно использовать двойной тернарный оператор. Например,

uint a = 100;
uint b = 10;

bool aIsSmallerOrMultiple = a < b ? true : a % b == 0 ? true : false;

(return: true)

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

#ternary

Бешеное лето и материалы июля

У меня выдается какое-то бешеное лето! Когда я взял небольшой отпуск в конце мая на неделю, то и представить не смог, что после не будет ни минуты передышки!

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

Далее крутым событием для меня стал запуск курса! В конце июня было сделано первое объявление об этом и уже в начале июля пошли первые занятия! Там было написано 19 уроков, 2 практикума и 52 финальных вопроса для самопроверки! Ребята, бы большие молодцы, что решились на что-то новое, так держать!

К концу курса я прошел собеседование и попал на испытательный срок в крутую компанию, на позицию Security Engineer. Уже прошла первая неделя и я в полном восторге от этой работы! То, что хотел с первого дня, как решил стать аудитором!

Жаль лишь то, что из-за основной работы и курса, куда я стараюсь вкладываться по максимуму, не хватает времени на конкурсные аудиты. С начала июня на каждый из них уходит всего по несколько часов. Тем не менее, первые небольшие результаты уже есть: нашел и первые high issues, и несколько med. Очень надеюсь, что скоро все чуть устаканится и я смогу выделять больше времени на это.

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

И все это, не считая своих обычных, вне-солидитишных дел!

Фух, бешеное лето!

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

1. Нюансы при аудите контрактов с подключенным Uniswap V3

2. Манипуляция оракулами

3. Уязвимость в древе Мерка в Open Zeppelin

4. Заметка про Uniswap V4

5. Двойной overflow

6. Организация prank в Foundry

7. Работа с памятью в Solidity. Большой сборник

8. Интересный баг в протоколе EigenLayer

9. Контроль доступа и голосование за предложения

10. Различные abi.encode

11. Организация storage в прокси контракте

12. RACE #19 Of The Secureum Bootcamp

13. Двойной тернарный

14. Необычный require и работа с ошибками

Продолжаем учиться и работать!

#retro

Курс Модуль 2

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

Представляю вам обновленную программу 2 модуля:

Неделя 5

20. Транзакции: общее.
21. Глобальные переменные msg
22. Наследование
23. Интерфейсы

Неделя 6

24. Библиотеки
25. Библиотеки openzeppelin и solmate
26. Низкоуровневые вызовы: call, staticcall
27. Низкоуровневые вызовы: delegatecall

Неделя 7

28 . Стандарт ERC20. Разбор кода и EIP
29. ERC20. Особенности и разнообразие
30. ERC20. Проблемы безопасности
31. ERC20 от Open Zeppelin

Неделя 8

32. ERC721. Разбор кода и EIP
33. ERC721. Использование в проектах
34. ERC721. Проблемы безопасности
35. Другие стандарты ERC
36. Практикум

Почему были внесены изменения?

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

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

Ориентировочный старт: 14 августа
Старт продаж: 9 августа
Стоимость: 2000 рублей, 25 USDT / USDC / DAI

#курс

Самопроверка перед 2 модулем курса

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

Вопросы для самопроверки:

1. На каких языках пишут сети блокчейна?
2. На каких языках пишут смарт контракты?
3. Какие есть сети блокчейна?
4. Дайте определение языку Solidity. Что такое статическая типизация?
5. Что такое полнота по Тьюрингу?
6. Что такое высокоуровневый язык?
7. В чем особенность смарт контрактов в блокчейне?
8. Что такое трилемма блокчейна?
9. Варианты решения трилеммы?
10. Что такое сайдчен?
11. Какие существуют сети L2?
12. Что такое роллапы? Какие виды существуют?
13. Что такое мост в блокчене?
14. Примеры использования смарт контрактов.
15. Из чего состоит смарт контракт?
16. Что такое компиляция и деплой смарт контракта?
17. Что такое газ?
18. Что такое обновление "Лондон"?
19. Что такое базовая и приоритетная комиссия?
20. Какие переменные бывают?
21. Какие бывают области видимости переменных?
22. Расскажите о типе данных bool?
23. Какое значение по умолчанию в bool?
24. Можно ли сравнивать строки? Почему?
25. Можно ли соединять строки?
26. Какие два вида адресов бывают?
27. Собственные методы адреса?
28. Что такое размерность uint?
29. Какое значение по умолчанию в uint?
30. Сколько байтов в uint128?
31. Что такое overflow?
32. Что такое кастинг uint?
33. Есть ли числа с точкой в Solidity?
34. Какие типы данных left-padded и какие right-padded?
35. Какие бывают массивы?
36. Можно ли создать динамический массив в функции?
37. Как записать значение в динамический массив?
38. Какие способы есть удаления данных из массива?
39. Что такое enum?
40. Какое значение по умолчанию в enum?
41. Для чего применяются enum?
42. Зачем нужны mapping?
43. Значение по умолчанию в mapping?
44. Можно ли сделать итерацию по мэппингу?
45. Какой тип данных может храниться в ключе и в значении мэппинга?
46. Какие бывают области видимости у функций? Чем отличаются?
47. Заем нужны view и pure функции? Их отличия?
48. Зачем нужен модификатор payable в функции?
49. Что такое receive и fallback функции?
50. Зачем нужны модификаторы в функциях?
51. Что такое struct?
52. Что такое вложения в мэппингах и структурах?

P.S. Это список вопросов из первого модуля. Такие будут после второго тоже.

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

#курс

Курс Solidity разработчик с нуля. Как догнать?

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

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

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

С первым модулем вы сможете сами в своем темпе проходить уроки, или вспомнить какой-то основной материал, а со вторым продолжить учиться.

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

Если же хотите сами попробовать подготовиться ко 2 модулю, то рекомендую к просмотру канал Ильи. Даже в своих уроках я рекомендую его видео к просмотру, так как считаю, что он лучший русскоговорящий учитель на Ютуб. Вы можете просмотреть его уроки с 1 до 7, исключая 5. Тогда вы начнете представлять, о чем будет идти речь на курсе.

Старт продаж уже завтра! Будет возможность оплатить как на карту, так и криптой. Вся информация будет завтра.


Программа курса! Описание курса


Продажи будут открыты до конца недели!

#курс