Обновляемые контракты (Transparent proxy). Часть 3
AdminProxy
Ниже приведен код из OpenZeppelin AdminProxy. Обратите внимание, что есть только одна функция upgradeAndCall(), которая может вызывать upgradeToAndCall() только на прокси.
Существует распространенное заблуждение, что администратор Transparent proxy не может использовать контракт, потому что его вызовы переадресуются на upgrade. Однако владелец AdminProxy может использовать Proxy без проблем, как показано на диаграмме на скрине.
На самом деле, существует механизм, позволяющий администратору ProxyAdmin сделать произвольный вызов прокси, как следует из названия функции upgradeToAndCall().
Сделать прокси non-upgradeable?
Если владелец будет изменен на нулевой адрес или другой смарт-контракт, который не сможет правильно использовать функцию upgradeAndCall() (или изменить владельца), то Transparent proxy больше не будет обновляемым. Это может произойти, например, если владельцем AdminProxy будет установлен другой контракт AdminProxy.
TUP от OpenZeppelin реализует стандарт с помощью трех контрактов:
1. Proxy.sol
2. ERC1967Proxy.sol (наследует Proxy.sol)
3. TransparentUgradeableProxy.sol (наследует ERC1967Proxy.sol)
Базовым контрактом является Proxy.sol. Получив адрес реализации, он отправляет delegate call в Логику. Функция _implementation() не реализована в Proxy - она переопределена и реализована его дочерним ERC1967Proxy, что позволяет ему вернуть соответствующий слот хранения.
ERC1967Proxy.sol наследует от Proxy.sol. Он добавляет (и переопределяет) внутреннюю функцию _implementation(), которая возвращает адрес реализации, хранящийся в слоте, указанном ERC-1967. Однако Transparent proxy не будет использовать эту функцию - вместо этого он использует свою собственную неизменяемую переменную.
А о самом TransparentUpgradeableProxy.sol мы поговорим в следующий раз.
#proxy #transparent
AdminProxy
Ниже приведен код из OpenZeppelin AdminProxy. Обратите внимание, что есть только одна функция upgradeAndCall(), которая может вызывать upgradeToAndCall() только на прокси.
pragma solidity ^0.8.20;
import {ITransparentUpgradeableProxy} from "./TransparentUpgradeableProxy.sol";
import {Ownable} from "../../access/Ownable.sol";
contract ProxyAdmin is Ownable {
string public constant UPGRADE_INTERFACE_VERSION = "5.0.0";
constructor(address initialOwner) Ownable(initialOwner) {}
function upgradeAndCall(
ITransparentUpgradeableProxy proxy,
address implementation,
bytes memory data
) public payable virtual onlyOwner {
proxy.upgradeToAndCall{value: msg.value}(implementation, data);
}
}
Существует распространенное заблуждение, что администратор Transparent proxy не может использовать контракт, потому что его вызовы переадресуются на upgrade. Однако владелец AdminProxy может использовать Proxy без проблем, как показано на диаграмме на скрине.
На самом деле, существует механизм, позволяющий администратору ProxyAdmin сделать произвольный вызов прокси, как следует из названия функции upgradeToAndCall().
Сделать прокси non-upgradeable?
Если владелец будет изменен на нулевой адрес или другой смарт-контракт, который не сможет правильно использовать функцию upgradeAndCall() (или изменить владельца), то Transparent proxy больше не будет обновляемым. Это может произойти, например, если владельцем AdminProxy будет установлен другой контракт AdminProxy.
TUP от OpenZeppelin реализует стандарт с помощью трех контрактов:
1. Proxy.sol
2. ERC1967Proxy.sol (наследует Proxy.sol)
3. TransparentUgradeableProxy.sol (наследует ERC1967Proxy.sol)
Базовым контрактом является Proxy.sol. Получив адрес реализации, он отправляет delegate call в Логику. Функция _implementation() не реализована в Proxy - она переопределена и реализована его дочерним ERC1967Proxy, что позволяет ему вернуть соответствующий слот хранения.
ERC1967Proxy.sol наследует от Proxy.sol. Он добавляет (и переопределяет) внутреннюю функцию _implementation(), которая возвращает адрес реализации, хранящийся в слоте, указанном ERC-1967. Однако Transparent proxy не будет использовать эту функцию - вместо этого он использует свою собственную неизменяемую переменную.
А о самом TransparentUpgradeableProxy.sol мы поговорим в следующий раз.
#proxy #transparent
1👍5
Обновляемые контракты (Transparent proxy). Часть 4
TransparentUpgradeableProxy.sol наследует от ERC1967Proxy.sol. В конструкторе этого контракта разворачивается ProxyAdmin и устанавливается как адрес неизменяемого admin (первая переменная в контракте).
Рассмотрим случай, когда отправителем msg.sender является _proxyAdmin. В этом случае вызов направляется в _dispatchUpgradeToAndCall(), но _fallback() сначала проверяет, что предоставленный селектор функций является селектором функций для upgradeToAndCall.
«Селектор» здесь не является "настоящим" селектором, поскольку Transparent Upgradeable Proxy не имеет публичных функций. Однако, чтобы позволить ProxyAdmin сделать вызов интерфейса (вызов высокого уровня), он должен принять от ProxyAdmin кодированные ABI calldata для upgradeToAndCall().
Напомн, что ProxyAdmin делает интерфейсный вызов upgradeToAndCall в прокси, хотя у прокси нет публичных функций, кроме fallback (код ProxyAdmin показан далее):
Выше представлено видео, демонстрирующее все три блока кода рядом друг с другом и то, как различные контракты в цепочке наследования (Proxy, ERC1967Proxy и TransparentUpgradeableProxy) взаимодействуют друг с другом.
В следующем посте поговорим о том, почему функция называется upgradeToAndCall(), а не просто upgradeTo().
#proxy #transparent
TransparentUpgradeableProxy.sol наследует от ERC1967Proxy.sol. В конструкторе этого контракта разворачивается ProxyAdmin и устанавливается как адрес неизменяемого admin (первая переменная в контракте).
contract TransparentUpgradeableProxy is ERC1967Proxy {
address private immutable _admin;
error ProxyDeniedAdminAccess();
constructor(address _logic, address initialOwner, bytes memory _data) payable ERC1967Proxy(_logic, _data) {
_admin = address(new ProxyAdmin(initialOwner));
// Set the storage value and emit an event for ERC-1967 compatibility
ERC1967Utils.changeAdmin(_proxyAdmin());
}
function _proxyAdmin() internal view virtual returns (address) {
return _admin;
}
function _fallback() internal virtual override {
if (msg.sender == _proxyAdmin()) {
if (msg.sig != ITransparentUpgradeableProxy.upgradeToAndCall.selector) {
revert ProxyDeniedAdminAccess();
} else {
_dispatchUpgradeToAndCall();
}
} else {
super._fallback();
}
}
function _dispatchUpgradeToAndCall() private {
(address newImplementation, bytes memory data) = abi.decode(msg.data[4:], (address, bytes));
ERC1967Utils.upgradeToAndCall(newImplementation, data);
}
}
Рассмотрим случай, когда отправителем msg.sender является _proxyAdmin. В этом случае вызов направляется в _dispatchUpgradeToAndCall(), но _fallback() сначала проверяет, что предоставленный селектор функций является селектором функций для upgradeToAndCall.
«Селектор» здесь не является "настоящим" селектором, поскольку Transparent Upgradeable Proxy не имеет публичных функций. Однако, чтобы позволить ProxyAdmin сделать вызов интерфейса (вызов высокого уровня), он должен принять от ProxyAdmin кодированные ABI calldata для upgradeToAndCall().
Напомн, что ProxyAdmin делает интерфейсный вызов upgradeToAndCall в прокси, хотя у прокси нет публичных функций, кроме fallback (код ProxyAdmin показан далее):
contract ProxyAdmin is Ownable {
string public constant UPGRADE_INTERFACE_VERSION = "5.0.0";
constructor(address initialOwner) Ownable(initialOwner) {}
function upgradeAndCall(
ITransparentUpgradeableProxy proxy,
address implementation,
bytes memory data
) public payable virtual onlyOwner {
@> proxy.upgradeToAndCall{value: msg.value}(implementation, data);
}
}Выше представлено видео, демонстрирующее все три блока кода рядом друг с другом и то, как различные контракты в цепочке наследования (Proxy, ERC1967Proxy и TransparentUpgradeableProxy) взаимодействуют друг с другом.
В следующем посте поговорим о том, почему функция называется upgradeToAndCall(), а не просто upgradeTo().
#proxy #transparent
👍6
Что по аудитам?
Прервусь на день с темой обновляемых контрактов, чтобы рассказать снова про конкурсные аудиты. Если помните, то в конце ноября прошлого года я решил заново научиться проводить аудит протокола. Моей основной идеей тогда было научиться понимать протокол за максимально короткое время, так как я не могу уделять больше 2-3 часов в день на такую работу.
Тогда мне очень помогла привычка вести заметки в физическом блокноте, выделяя некоторые моменты в контрактах, на которые нужно обратить внимание, разными цветами ручки.
До большого отпуска я успел поучаствовать в 4,5 конкурсных аудитах. В общей сложности они принесли мне всего ~ $960. Точнее, их мне принесли всего два аудита и 2 High / 1 Med / 3 Low из двух конкурсов. В Sablier - отличная кодовая база была и он был первый, в котором я решил поучаствовать с заметками. Итог - 0 находок. Другой был на Шерлоке - это отдельная история, вскоре сделаю пост на тему конкурсов там. И еще один, тот 0,5 аудит - смотрел в поезде в течение часа. Нашел только один Med, который нашли еще 90% участников конкурса, поэтому выплат не было.
Вообще заметки очень и очень сильно помогают и прокачивают вашу работу с чтением кода. Просматривать функцию, видеть трансфер токенов - это одно, а понимать, как он влияет на балансы пользователей и контрактов - совершенное другой уровень.
В январе у меня была другая цель: вместе с заметками научиться генерировать идеи для репортов. В смысле, стараться за небольшое время, найти как можно больше проблемных точек в контракте. Я хочу сформировать у себя некую насмотренность контрактов, чтобы появился "паттерн проблемных мест". Вообще не знаю, что получится. Может это и глупо, а может и сработает для меня. Буду смотреть по результатам.
Пока что, получилось принять участие в 4 конкурсах и отправить 20 репортов: 7-6-6-1. Обычно же отправлял 3-4 репорта на конкурс.
Также подтверждаю, что с заметками и постоянной практикой, становится намного легче читать и понимать код.
Насколько все сработает буду уже судить по результатам конкурса.
В идеале ставлю себе цель, чтобы как минимум 75% от репортов были валидными High/Med. На данный момент, это около +-30%.
Хочу особо подчеркнуть, что это результаты моего пути и бекграунда. У вас может получиться куда успешнее путь, если у вас техническое образование или вы были разработчиком, тестером или работали с безопасностью кода. И наоборот, занять немного больше времени, если начинаете путь с нуля.
#audit
Прервусь на день с темой обновляемых контрактов, чтобы рассказать снова про конкурсные аудиты. Если помните, то в конце ноября прошлого года я решил заново научиться проводить аудит протокола. Моей основной идеей тогда было научиться понимать протокол за максимально короткое время, так как я не могу уделять больше 2-3 часов в день на такую работу.
Тогда мне очень помогла привычка вести заметки в физическом блокноте, выделяя некоторые моменты в контрактах, на которые нужно обратить внимание, разными цветами ручки.
До большого отпуска я успел поучаствовать в 4,5 конкурсных аудитах. В общей сложности они принесли мне всего ~ $960. Точнее, их мне принесли всего два аудита и 2 High / 1 Med / 3 Low из двух конкурсов. В Sablier - отличная кодовая база была и он был первый, в котором я решил поучаствовать с заметками. Итог - 0 находок. Другой был на Шерлоке - это отдельная история, вскоре сделаю пост на тему конкурсов там. И еще один, тот 0,5 аудит - смотрел в поезде в течение часа. Нашел только один Med, который нашли еще 90% участников конкурса, поэтому выплат не было.
Вообще заметки очень и очень сильно помогают и прокачивают вашу работу с чтением кода. Просматривать функцию, видеть трансфер токенов - это одно, а понимать, как он влияет на балансы пользователей и контрактов - совершенное другой уровень.
В январе у меня была другая цель: вместе с заметками научиться генерировать идеи для репортов. В смысле, стараться за небольшое время, найти как можно больше проблемных точек в контракте. Я хочу сформировать у себя некую насмотренность контрактов, чтобы появился "паттерн проблемных мест". Вообще не знаю, что получится. Может это и глупо, а может и сработает для меня. Буду смотреть по результатам.
Пока что, получилось принять участие в 4 конкурсах и отправить 20 репортов: 7-6-6-1. Обычно же отправлял 3-4 репорта на конкурс.
Также подтверждаю, что с заметками и постоянной практикой, становится намного легче читать и понимать код.
Насколько все сработает буду уже судить по результатам конкурса.
В идеале ставлю себе цель, чтобы как минимум 75% от репортов были валидными High/Med. На данный момент, это около +-30%.
Хочу особо подчеркнуть, что это результаты моего пути и бекграунда. У вас может получиться куда успешнее путь, если у вас техническое образование или вы были разработчиком, тестером или работали с безопасностью кода. И наоборот, занять немного больше времени, если начинаете путь с нуля.
#audit
🔥13
Обновляемые контракты (Transparent proxy). Часть 5
Почему функция называется upgradeToAndCall(), а не просто upgradeTo()?
При обновлении контракта Логики можно сделать вызов, как если бы ProxyAdmin был msg.sender и транзакция делегировала вызов в Логику, как если бы это было обычное взаимодействие с прокси. Конечно, внутри fallback() этого не произойдет, потому что вызовы ProxyAdmin направляются в логику обновления.
Приведенный ниже код взят из ERC1967Utils.sol, с которым TransparentUpgradeableProxy компонуется для обеспечения возможности обновления слота Логики. Библиотека предоставляет внутреннюю вспомогательную функцию для обновления слота, содержащего адрес Логики.
Он будет выполнять delegatecall в контракт Логики только в том случае, если data.length > 0.
upgradeToAndCall() также выполняет delegatecall от прокси к Логике в той же транзакции, что и обновление. Это то же самое, как если бы ProxyAdmin вызвал прокси, используя любые calldata, указанные в data, а затем прокси сделал бы delegatecall в самой Логике.
Таким образом, ProxyAdmin может делать произвольные вызовы прокси.
Обратите внимание, что upgradeToAndCall не требует, чтобы обновленный контракт был другой реализацией - можно «обновиться» до той же самой Логики.
Из этого следует, что контракт ProxyAdmin может делать произвольные delegatecall в контракт Логики через прокси - но отправителем msg.sender с точки зрения Transparent Proxy является ProxyAdmin.
Единственное ограничение, которое накладывает ProxyAdmin на обновление, заключается в том, что он не может обновить пустой контракт (адрес без байткода). Функция _setImplementation проверяет, что длина кода новой реализации больше нуля.
Подведем итоги:
1. Transparent Upgradeable Proxy - это шаблон проектирования для предотвращения столкновения селекторов функций между прокси и Логикой;
2. Функция fallback является единственной публичной функцией в Transparent Upgradeable Proxy;
3. Функциональность обновления может быть вызвана только администратором через функцию fallback. Все вызовы с неадминистративных адресов превращаются в delegatecalls в прокси;
4. Transparent Upgradeable Proxy использует неизменяемую переменную для хранения адреса администратора, чтобы сэкономить газ. Для того, чтобы соответствовать ERC-1967, он хранит адрес администратора в слоте admin, указанном в ERC-1967, даже если он никогда не читает из этого слота;
5. Поскольку администратор не может быть изменен, он устанавливается в смарт-контракт под названием AdminProxy. AdminProxy раскрывает единственную функцию upgradeAndCall(), которая может быть вызвана только владельцем AdminProxy. Владелец AdminProxy может быть изменен.
#proxy #transparent
Почему функция называется upgradeToAndCall(), а не просто upgradeTo()?
При обновлении контракта Логики можно сделать вызов, как если бы ProxyAdmin был msg.sender и транзакция делегировала вызов в Логику, как если бы это было обычное взаимодействие с прокси. Конечно, внутри fallback() этого не произойдет, потому что вызовы ProxyAdmin направляются в логику обновления.
Приведенный ниже код взят из ERC1967Utils.sol, с которым TransparentUpgradeableProxy компонуется для обеспечения возможности обновления слота Логики. Библиотека предоставляет внутреннюю вспомогательную функцию для обновления слота, содержащего адрес Логики.
/**
* @dev Performs implementation upgrade with additional setup call if data is nonempty.
* This function is payable only if the setup call is performed, otherwise `msg.value` is rejected
* to avoid stuck value in the contract.
*
* Emits an {IERC1967-Upgraded} event.
*/
function upgradeToAndCall(address newImplementation, bytes memory data) internal {
_setImplementation(newImplementation);
emit IERC1967.Upgraded(newImplementation);
if (data.length > 0) {
Address.functionDelegateCall(newImplementation, data);
} else {
_checkNonPayable();
}
}
Он будет выполнять delegatecall в контракт Логики только в том случае, если data.length > 0.
upgradeToAndCall() также выполняет delegatecall от прокси к Логике в той же транзакции, что и обновление. Это то же самое, как если бы ProxyAdmin вызвал прокси, используя любые calldata, указанные в data, а затем прокси сделал бы delegatecall в самой Логике.
Таким образом, ProxyAdmin может делать произвольные вызовы прокси.
Обратите внимание, что upgradeToAndCall не требует, чтобы обновленный контракт был другой реализацией - можно «обновиться» до той же самой Логики.
Из этого следует, что контракт ProxyAdmin может делать произвольные delegatecall в контракт Логики через прокси - но отправителем msg.sender с точки зрения Transparent Proxy является ProxyAdmin.
Единственное ограничение, которое накладывает ProxyAdmin на обновление, заключается в том, что он не может обновить пустой контракт (адрес без байткода). Функция _setImplementation проверяет, что длина кода новой реализации больше нуля.
/**
* @dev Stores a new address in the ERC-1967 implementation slot.
*/
function _setImplementation(address newImplementation) private {
if (newImplementation.code.length == 0) {
revert ERC1967InvalidImplementation(newImplementation);
}
StorageSlot.getAddressSlot(IMPLEMENTATION_SLOT).value = newImplementation;
}
Подведем итоги:
1. Transparent Upgradeable Proxy - это шаблон проектирования для предотвращения столкновения селекторов функций между прокси и Логикой;
2. Функция fallback является единственной публичной функцией в Transparent Upgradeable Proxy;
3. Функциональность обновления может быть вызвана только администратором через функцию fallback. Все вызовы с неадминистративных адресов превращаются в delegatecalls в прокси;
4. Transparent Upgradeable Proxy использует неизменяемую переменную для хранения адреса администратора, чтобы сэкономить газ. Для того, чтобы соответствовать ERC-1967, он хранит адрес администратора в слоте admin, указанном в ERC-1967, даже если он никогда не читает из этого слота;
5. Поскольку администратор не может быть изменен, он устанавливается в смарт-контракт под названием AdminProxy. AdminProxy раскрывает единственную функцию upgradeAndCall(), которая может быть вызвана только владельцем AdminProxy. Владелец AdminProxy может быть изменен.
#proxy #transparent
👍5
Интенсив по Foundry с нуля
В начале года я писал, что хочу провести небольшой интенсивный модуль по работе с Foundry с нуля. Сейчас я заканчиваю его создание и расскажу вам, что он будет включать и как проходить.
Прежде всего интенсив будет рассчитан на три недели ежедневных уроков с практикой, плюс пара бонусных. Теория будет основана на опубликованном ранее на канале цикле постов про Foundry, но гораздо лучше структурирована и дополнена новой информацией. Кроме того, будут идти практические задания, чтобы вы на простых примерах научились писать тесты, как для своего протокола, так и POC-примеры для конкурсов по аудиту.
О самих темах я расскажу чуть позже, но пока могу сказать, что точно не будет уроков по сложному тестированию: инварианты, формальная верификация и дифференциальные тесты. Это уже более продвинутые знания и нужно уметь обращаться с Foundry на хорошем уровне, чтобы начать писать такие тесты.
Модуль будет рассчитан на тех, кто ни разу не работал с Foundry или только изучал некоторую информацию из открытых источников. По примеру нашего основного курса по Solidity, это будет интенсив в формате текстовых постов с практическими заданиями.
Стоимость будет будет около 4000 рублей для всех и 3000 рублей для тех, кто приходил хотя бы на один обучающий модуль курса ранее.
У нас также будет открыт чат для вопрсов-ответов. Материалы с интенсива останутся у вас навсегда, каналы с модулями не удаляются. В любой момент вы сможете вернуться к источнику и пройти урок заново.
По датам пока не могу сказать точно. Разработчики Foundry очень скоро хотят выпустить новую версию программы с многими крутыми фишками, и я планирую подождать до релиза, изучить нововведения и также дополнить курс этими материалами. Именно по этому интенсив может быть запущен в начале марта.
Сейчас хотел бы узнать, кто планирует пойти на модуль? Прошу пройти опрос ниже.
#foundry
В начале года я писал, что хочу провести небольшой интенсивный модуль по работе с Foundry с нуля. Сейчас я заканчиваю его создание и расскажу вам, что он будет включать и как проходить.
Прежде всего интенсив будет рассчитан на три недели ежедневных уроков с практикой, плюс пара бонусных. Теория будет основана на опубликованном ранее на канале цикле постов про Foundry, но гораздо лучше структурирована и дополнена новой информацией. Кроме того, будут идти практические задания, чтобы вы на простых примерах научились писать тесты, как для своего протокола, так и POC-примеры для конкурсов по аудиту.
О самих темах я расскажу чуть позже, но пока могу сказать, что точно не будет уроков по сложному тестированию: инварианты, формальная верификация и дифференциальные тесты. Это уже более продвинутые знания и нужно уметь обращаться с Foundry на хорошем уровне, чтобы начать писать такие тесты.
Модуль будет рассчитан на тех, кто ни разу не работал с Foundry или только изучал некоторую информацию из открытых источников. По примеру нашего основного курса по Solidity, это будет интенсив в формате текстовых постов с практическими заданиями.
Стоимость будет будет около 4000 рублей для всех и 3000 рублей для тех, кто приходил хотя бы на один обучающий модуль курса ранее.
У нас также будет открыт чат для вопрсов-ответов. Материалы с интенсива останутся у вас навсегда, каналы с модулями не удаляются. В любой момент вы сможете вернуться к источнику и пройти урок заново.
По датам пока не могу сказать точно. Разработчики Foundry очень скоро хотят выпустить новую версию программы с многими крутыми фишками, и я планирую подождать до релиза, изучить нововведения и также дополнить курс этими материалами. Именно по этому интенсив может быть запущен в начале марта.
Сейчас хотел бы узнать, кто планирует пойти на модуль? Прошу пройти опрос ниже.
#foundry
🔥10
Solidity. Смарт контракты и аудит pinned «Планируете пойти на интенсив?»
Найти работу или получать заказы?
Пока идет голосование по интенсиву Foundry (приятно, что все же больше людей хотят попасть на модуль), хочу поднять с вами не очень популярную тему среди людей, и еще менее популярную среди разработчиков. А именно тему личного бренда и проявленности в соцсетях.
Буквально вчера я спорил с разработчиком Rust/Solidity, который утверждал, что если ты крутой разработчик, то с легкость найдешь хорошо оплачиваемую работу и иметь присутствие в сети вовсе не обязательно, ну, понятное дело, за исключением профиля на LinkedIn и GitHub.
P.S. По GitHub помню, что обещал сделать пост по оформлению, но пока не могу накопать достаточно инфы по тому, как рекрутеры отбирают профили, на что смотрят и где поискать примеры вдохновения. Но однажды напишу хороший гайд.
Я же утверждал, что это касается только разработчиков уровня мидл и сеньор, которые имеют уже должностной список в популярных компаниях, где все друг друга знают и могут спокойно порекомендовать. Или же отъявленный кодер, который знает нужный язык программирования на уровне его создателей, и может писать крутой код без помощи гугла или gpt.
Во всех других случаях, каждый соискатель (работы или заказов) должен хоть как-то проявляться в сети и говорить, что вы можете делать.
Обычный канал с заметками по Solidity, который вы будете вести в процессе обучения, может стать отличным началом. Особенно, если вы, как и я, полагаете, что фото и видео тема вам трудно даются.
Если же наоборот, то делайте записи экрана и скрины, выкладывайте в соцсетях с небольшим описанием, пусть люди знают, что по этой теме могут обратиться к вам.
Количество подписчиков вообще не играет роли. Нужно только чтобы потенциальный заказчик или рекрутер нашел ваш профиль и изучил его.
Начать вести соцсети очень легко, сложно будет не прекратить это делать через пару недель, когда, как вам покажется, закончились все темы.
Расскажите, как вас впервые посетила идея научиться программировать, как искали инфу по языку и обучающие материалы, какие трудности были на пути, что вам привлекло в коде, какие бывают сложности в изучении и т.д.
Только благодаря этому каналу я смог получить первые заказы на аудит, только благодаря ведению Твиттера я получил первый заказ на пре-аудит. На разработку протокола я получаю предложения раз в 3-4 недели.
Да, это заняло у меня более двух лет. Но сейчас я точно могу быть уверен, что не останусь без работы и денег в случае чего.
И это только с текстовых форматов. Если вы сможете все рассказывать в видео/фото формате, то продвинетесь намного скорее.
Что думаете, по этому поводу? Ведете свой канал или планируете начать? Или уверены, что получится найти работу и без этого всего?
#pb
Пока идет голосование по интенсиву Foundry (приятно, что все же больше людей хотят попасть на модуль), хочу поднять с вами не очень популярную тему среди людей, и еще менее популярную среди разработчиков. А именно тему личного бренда и проявленности в соцсетях.
Буквально вчера я спорил с разработчиком Rust/Solidity, который утверждал, что если ты крутой разработчик, то с легкость найдешь хорошо оплачиваемую работу и иметь присутствие в сети вовсе не обязательно, ну, понятное дело, за исключением профиля на LinkedIn и GitHub.
P.S. По GitHub помню, что обещал сделать пост по оформлению, но пока не могу накопать достаточно инфы по тому, как рекрутеры отбирают профили, на что смотрят и где поискать примеры вдохновения. Но однажды напишу хороший гайд.
Я же утверждал, что это касается только разработчиков уровня мидл и сеньор, которые имеют уже должностной список в популярных компаниях, где все друг друга знают и могут спокойно порекомендовать. Или же отъявленный кодер, который знает нужный язык программирования на уровне его создателей, и может писать крутой код без помощи гугла или gpt.
Во всех других случаях, каждый соискатель (работы или заказов) должен хоть как-то проявляться в сети и говорить, что вы можете делать.
Обычный канал с заметками по Solidity, который вы будете вести в процессе обучения, может стать отличным началом. Особенно, если вы, как и я, полагаете, что фото и видео тема вам трудно даются.
Если же наоборот, то делайте записи экрана и скрины, выкладывайте в соцсетях с небольшим описанием, пусть люди знают, что по этой теме могут обратиться к вам.
Количество подписчиков вообще не играет роли. Нужно только чтобы потенциальный заказчик или рекрутер нашел ваш профиль и изучил его.
Начать вести соцсети очень легко, сложно будет не прекратить это делать через пару недель, когда, как вам покажется, закончились все темы.
Расскажите, как вас впервые посетила идея научиться программировать, как искали инфу по языку и обучающие материалы, какие трудности были на пути, что вам привлекло в коде, какие бывают сложности в изучении и т.д.
Только благодаря этому каналу я смог получить первые заказы на аудит, только благодаря ведению Твиттера я получил первый заказ на пре-аудит. На разработку протокола я получаю предложения раз в 3-4 недели.
Да, это заняло у меня более двух лет. Но сейчас я точно могу быть уверен, что не останусь без работы и денег в случае чего.
И это только с текстовых форматов. Если вы сможете все рассказывать в видео/фото формате, то продвинетесь намного скорее.
Что думаете, по этому поводу? Ведете свой канал или планируете начать? Или уверены, что получится найти работу и без этого всего?
#pb
👍22🔥3
Минимальные требования для работы
Вчера со мной поделились вакансией на позицию "Аудитор смарт контрактов". Хоть я и не ищу ни работы, ни заказов сейчас, было интересно прочитать современные требования для соискателей. В итоге я подумал, что вообще мне следовало бы погуглить открытие вакансии и посмотреть, что сейчас актуально, что рассказать об этом на канале.
В целом я заметил некую тенденцию, которая меня сильно раздражала в описании вакансий в России и СНГ в целом. Иногда складывалось впечатление, что описания пишутся HR, которые только на Ютубе слышали о существовании web3. Они стараются в требования впихнуть вообще все, что только можно.
Грубо говоря, на позицию мидла ищут разработчика, который знает:
- Python, C+, JS (включая 3-4 популярных фрейма типа TypeScript, Next, React, Vue и т.д.);
- Solidity, Rust, Ton;
- Hardhat, Foundry, Truffle (!!!);
- Имеет степень бакалавра компьютерных наук;
и т.д.
Вроде как, мы ищем спеца на все руки, собеседование вы не пройдете, а если случится обратное - ну, что же, простенький сайтик с подключенным смарт контрактов написать дадим.
И это не мировые компании типа того же Uniswap, Open Zeppelin, Aave и других. О многих из них никто даже не слышал.
Я всегда бы за четкое разделение знаний на позициях. Если у компании нет денег на оплату двух позиций: Фронтенда и Web3 разработчика, то с зп вероятнее всего будут проблемы.
Разработчик смарт контрактов может должен знать язык под задачу (Solidity, Rust), уметь ответить за свою работу (написать тесты и показать, что все работает) и постоянно изучать новое в сфере блокчейна. Ему не нужно знать, как написать лендинг и связать его.
Фронтенд разработчик должен знать свой язык и набор библиотек для связи с блокчейном. Ему нафиг не нужно уметь писать DeFi протоколы!
Это хорошо, когда разработчик знает другой язык и может выполнить некоторые действия (устанавливать плагины на Python, подключать библиотеки, читать конфиги и т.д.), но он вовсе не обязан быть сеньором во всех языках, как требуют того некоторые вакансии.
Я пишу этот пост с обращением ко всем соискателям. Не нужно искать работу в web3, где требуется "мастер на все руки". Многих это может напугать, а другим сбить фокус - и вы начнете изучать все, чтобы соответствовать требованиям.
Для хорошей работы Solidity разработчиком нужно всего три вещи:
1. Отличное знание Solidity и современных паттернов разработки;
2. Навыки тестирования смарт контрактов;
3. Базовые аспекты безопасности кода;
Да, в процессе обучения вы познакомитесь с JS и с Python, но тут не потребуется "навыков работы 3+ лет".
В общем, делайте фокус именно на смарт контрактах, и не старайтесь изучить вообще все, чтобы получить работу в непонятной компании.
#job
Вчера со мной поделились вакансией на позицию "Аудитор смарт контрактов". Хоть я и не ищу ни работы, ни заказов сейчас, было интересно прочитать современные требования для соискателей. В итоге я подумал, что вообще мне следовало бы погуглить открытие вакансии и посмотреть, что сейчас актуально, что рассказать об этом на канале.
В целом я заметил некую тенденцию, которая меня сильно раздражала в описании вакансий в России и СНГ в целом. Иногда складывалось впечатление, что описания пишутся HR, которые только на Ютубе слышали о существовании web3. Они стараются в требования впихнуть вообще все, что только можно.
Грубо говоря, на позицию мидла ищут разработчика, который знает:
- Python, C+, JS (включая 3-4 популярных фрейма типа TypeScript, Next, React, Vue и т.д.);
- Solidity, Rust, Ton;
- Hardhat, Foundry, Truffle (!!!);
- Имеет степень бакалавра компьютерных наук;
и т.д.
Вроде как, мы ищем спеца на все руки, собеседование вы не пройдете, а если случится обратное - ну, что же, простенький сайтик с подключенным смарт контрактов написать дадим.
И это не мировые компании типа того же Uniswap, Open Zeppelin, Aave и других. О многих из них никто даже не слышал.
Я всегда бы за четкое разделение знаний на позициях. Если у компании нет денег на оплату двух позиций: Фронтенда и Web3 разработчика, то с зп вероятнее всего будут проблемы.
Разработчик смарт контрактов может должен знать язык под задачу (Solidity, Rust), уметь ответить за свою работу (написать тесты и показать, что все работает) и постоянно изучать новое в сфере блокчейна. Ему не нужно знать, как написать лендинг и связать его.
Фронтенд разработчик должен знать свой язык и набор библиотек для связи с блокчейном. Ему нафиг не нужно уметь писать DeFi протоколы!
Это хорошо, когда разработчик знает другой язык и может выполнить некоторые действия (устанавливать плагины на Python, подключать библиотеки, читать конфиги и т.д.), но он вовсе не обязан быть сеньором во всех языках, как требуют того некоторые вакансии.
Я пишу этот пост с обращением ко всем соискателям. Не нужно искать работу в web3, где требуется "мастер на все руки". Многих это может напугать, а другим сбить фокус - и вы начнете изучать все, чтобы соответствовать требованиям.
Для хорошей работы Solidity разработчиком нужно всего три вещи:
1. Отличное знание Solidity и современных паттернов разработки;
2. Навыки тестирования смарт контрактов;
3. Базовые аспекты безопасности кода;
Да, в процессе обучения вы познакомитесь с JS и с Python, но тут не потребуется "навыков работы 3+ лет".
В общем, делайте фокус именно на смарт контрактах, и не старайтесь изучить вообще все, чтобы получить работу в непонятной компании.
#job
👍32🥰4❤3
Media is too big
VIEW IN TELEGRAM
Пробы записи видео и разбор функций
Вот выдалось немного свободного времени потренироваться с записью видео, и решил, что некоторым будет интересно узнавать об интересных функциях или реализациях в смарт контрактах, что я встречаю на конкурсных аудитах.
Вообще у меня по задумке два направления на этот год: необычные функции и реализации, а также "по следам аудита", где хочу проходить по уже подтвержденным багам. Там и я сам буду проводить хорошую работу над ошибками и, возможно, начинающим аудиторам будет полезно узнавать моменты, на которые стоит обращать внимание.
Вообще пишу я лучше, чем говорю, поэтому видео формат для меня настоящий челлендж. Это первый такой, тренировочный, ролик, чтобы узнать ваше мнение.
Сейчас пара вопросов:
1. Как вообще видео по формату? Удобно ли смотреть с телефона, не раздражает ли что, все ли четко и по делу?
2. Что надо улучшить (субтитры, крупнее код, подсвечивать код или что-то другое)?
Я только учусь, поэтому любой фидбек будет ценен для меня.
По данному видео, вот ссылки на протокол и функцию из видео.
#video
Вот выдалось немного свободного времени потренироваться с записью видео, и решил, что некоторым будет интересно узнавать об интересных функциях или реализациях в смарт контрактах, что я встречаю на конкурсных аудитах.
Вообще у меня по задумке два направления на этот год: необычные функции и реализации, а также "по следам аудита", где хочу проходить по уже подтвержденным багам. Там и я сам буду проводить хорошую работу над ошибками и, возможно, начинающим аудиторам будет полезно узнавать моменты, на которые стоит обращать внимание.
Вообще пишу я лучше, чем говорю, поэтому видео формат для меня настоящий челлендж. Это первый такой, тренировочный, ролик, чтобы узнать ваше мнение.
Сейчас пара вопросов:
1. Как вообще видео по формату? Удобно ли смотреть с телефона, не раздражает ли что, все ли четко и по делу?
2. Что надо улучшить (субтитры, крупнее код, подсвечивать код или что-то другое)?
Я только учусь, поэтому любой фидбек будет ценен для меня.
По данному видео, вот ссылки на протокол и функцию из видео.
#video
❤11👍4🔥3
Тестирование != тестирование
Сегодня хотел поделиться кейсом, который встретился в одном из недавних аудитов, а также обсудить тему правильного тестирования.
В конкурсе протокола Diva, который проходил на платформе CodeHawks, был занятный баг, который пропускался даже в тестах, не смотря на то, что был в конструкторе контракта.
Суть его была в том, что в одном контракте в конструкторе также создавался и другой:
Обратите внимание, что аргументы передаются в не совсем верном порядке: адреса aave и diva перепутаны местами.
Хоть его и засчитали как Medium (по предварительным результатам), мне кажется, что правильнее было бы установить как Low. Контракты сразу после деплоя были бы не рабочими и, вроде как, ни к каким другим последствиям, кроме как ре-деплой, это бы не привело. Но примечательно другое.
Разработчики написали тесты, которые успешно проходили!
В общем, они были написаны правильно: тестировались необходимые функции и ветки, но что-то все же пропустилось... И это случилось у хороших разработчиков.
Разработчикам, которые только начинают писать тесты для своих контрактов, бывает сложно понять саму суть проводимых тестов. Они пишут unit тесты и стараются получить 100% coverage в итоге, не представляя, что тестирование может быть вне рамок кода.
Например, когда мы пишем тест для проверки реверта в require, в итоге нам нужно получить не сообщение об ошибке, которое порождается этой проверкой, а такие состояния кода, при которых она возникает. А это может быть не совсем директивное поведение пользователя.
Или также дело обстоит с проверками if/else. Тут тесты пишутся не только на два условия, но и для всех состояний, ролей и временных отрезков, которые могут повлиять на эту проверку.
Именно поэтому, на 1000 строк кода контракта мы можем встречать 5000+ строк тестов.
Если вы хотите стать лучше в этом деле, то уже с момента написания самого контракта, начните вести файл, куда будете записывать проверки. Пишем "pragma ..." - думаем на каких сетях это будет работать, какие проблемы есть в текущей версии языка. Пишем "MyContract is..." - думаем над порядком наследований и передачей параметров, пишем переменную - думаем на размерностью и слотом в памяти.
Это сложно, но так вы и сами сможете написать более безопасный код и более подробную документацию, которая поможем аудиторам в скором будущем.
Пишите правильные тесты!
#testing
Сегодня хотел поделиться кейсом, который встретился в одном из недавних аудитов, а также обсудить тему правильного тестирования.
В конкурсе протокола Diva, который проходил на платформе CodeHawks, был занятный баг, который пропускался даже в тестах, не смотря на то, что был в конструкторе контракта.
Суть его была в том, что в одном контракте в конструкторе также создавался и другой:
constructor(address _aaveV3Pool, address _diva, address _owner) AaveDIVAWrapperCore(_aaveV3Pool, _diva, _owner) {}
constructor(address diva_, address aaveV3Pool_, address owner_) Ownable(owner_) {}
Обратите внимание, что аргументы передаются в не совсем верном порядке: адреса aave и diva перепутаны местами.
Хоть его и засчитали как Medium (по предварительным результатам), мне кажется, что правильнее было бы установить как Low. Контракты сразу после деплоя были бы не рабочими и, вроде как, ни к каким другим последствиям, кроме как ре-деплой, это бы не привело. Но примечательно другое.
Разработчики написали тесты, которые успешно проходили!
В общем, они были написаны правильно: тестировались необходимые функции и ветки, но что-то все же пропустилось... И это случилось у хороших разработчиков.
Разработчикам, которые только начинают писать тесты для своих контрактов, бывает сложно понять саму суть проводимых тестов. Они пишут unit тесты и стараются получить 100% coverage в итоге, не представляя, что тестирование может быть вне рамок кода.
Например, когда мы пишем тест для проверки реверта в require, в итоге нам нужно получить не сообщение об ошибке, которое порождается этой проверкой, а такие состояния кода, при которых она возникает. А это может быть не совсем директивное поведение пользователя.
Или также дело обстоит с проверками if/else. Тут тесты пишутся не только на два условия, но и для всех состояний, ролей и временных отрезков, которые могут повлиять на эту проверку.
Именно поэтому, на 1000 строк кода контракта мы можем встречать 5000+ строк тестов.
Если вы хотите стать лучше в этом деле, то уже с момента написания самого контракта, начните вести файл, куда будете записывать проверки. Пишем "pragma ..." - думаем на каких сетях это будет работать, какие проблемы есть в текущей версии языка. Пишем "MyContract is..." - думаем над порядком наследований и передачей параметров, пишем переменную - думаем на размерностью и слотом в памяти.
Это сложно, но так вы и сами сможете написать более безопасный код и более подробную документацию, которая поможем аудиторам в скором будущем.
Пишите правильные тесты!
#testing
🔥11👍3
Ловушка аудитора и недостаток валидации
Хочу поделиться с вами небольшими результатами своего "переобучения" в качестве аудитора за последние пару месяцев.
Как вы знаете, я решил научиться аудировать протоколы заново и с конца ноября экспериментировал с заметками. Основной целью я ставил перед собой - в короткое время научиться разбирать протокол и понимать, что за что отвечает.
В январе-начале февраля была немного другая цель - быстро генерировать потенциальные проблемы в контракте и отправлять максимум репортов. "Максимум" складывался за счет поиска паттернов, на основе прочитанных репортов и догадок, в ущерб валидации.
Что же можно сказать по итогам этого периода?
В общем плане, за два-три месяца скорость понимания кода значительно повысилась. Если раньше на 1000 строк могло уходить до 4-5 дней, то сейчас уже 1-2 дня. Когда я говорю про "понимание", то имею ввиду, что я могу, смотря на функцию, хорошо знать:
- что она делает;
- какие служебные вызывает;
- какие состояния контракта изменяет;
- куда и откуда переводятся токены;
- какие проверки есть или нет;
- есть ли зеркальные функции;
и т.д.
Заниматься по 3-4 часа в день, вполне адекватная нагрузка.
С репортами и поиском багов стало немного хуже.
За 4 недели (с 13.01 по 05.02) я посмотрел 5 конкурсных аудитов и написал 28 отчетов. Результатов еще официальный нет, но предварительные не особо радуют. Примерно 10 штук - это "дизайн протокола" - когда протокол понимает, что этот код может привести к проблемам, но берет ответственность за свои действия и не будет ничего менять в коде, около 6 репортов - уже известные проблемы, около 4 - из Med в Low/Info, еще 4 - валидные и остальные - не валидные.
Другими словами, из 28 отчетов будут приняты около 3-4.
Когда я провожу реальный аудит, я читаю документацию, повторяю EIP, которые используются в протоколе, смотрю тесты и комментарии, построчно иду по коду и часто пишу заказчикам, чтобы удостовериться в каком-либо моменте. Если не могу доказать баг тестами, то в репорте веду отдельный блок с комментариями по коду, на что нужно обратить внимание.
В конкурсных же аудитах я "забил" на валидацию в пользу количества репортов и затраченного времени.
Как вы сами можете видеть, это не окупается ни по работе, ни по оплате.
Короче - не делайте так. Репорты с недостаточной валидацией - отстой!
На ближайшее время хочу попробовать другой подход: вместо поиска паттернов и максимума отчетов, генерировать возможные пути атаки и валидировать их. Это сложно объяснить, но, например, вместо поиска слабых мест в контракте и его логике, искать способы атаки на эти места. Если не могу на 100% доказать такой факт, то репорт - мимо.
⚡️ И небольшое предложение для всех:
Если тоже учитесь аудитам и уже пробовали себя в конкурсах, то предлагаю "поковырять" один небольшой баг баунти с Immunefi. Создадим закрытый чат, скину репо и каждый день будем в чате обмениваться ходом аудита.
Что скажете, кто-нибудь хочет поучаствовать?
#audit
Хочу поделиться с вами небольшими результатами своего "переобучения" в качестве аудитора за последние пару месяцев.
Как вы знаете, я решил научиться аудировать протоколы заново и с конца ноября экспериментировал с заметками. Основной целью я ставил перед собой - в короткое время научиться разбирать протокол и понимать, что за что отвечает.
В январе-начале февраля была немного другая цель - быстро генерировать потенциальные проблемы в контракте и отправлять максимум репортов. "Максимум" складывался за счет поиска паттернов, на основе прочитанных репортов и догадок, в ущерб валидации.
Что же можно сказать по итогам этого периода?
В общем плане, за два-три месяца скорость понимания кода значительно повысилась. Если раньше на 1000 строк могло уходить до 4-5 дней, то сейчас уже 1-2 дня. Когда я говорю про "понимание", то имею ввиду, что я могу, смотря на функцию, хорошо знать:
- что она делает;
- какие служебные вызывает;
- какие состояния контракта изменяет;
- куда и откуда переводятся токены;
- какие проверки есть или нет;
- есть ли зеркальные функции;
и т.д.
Заниматься по 3-4 часа в день, вполне адекватная нагрузка.
С репортами и поиском багов стало немного хуже.
За 4 недели (с 13.01 по 05.02) я посмотрел 5 конкурсных аудитов и написал 28 отчетов. Результатов еще официальный нет, но предварительные не особо радуют. Примерно 10 штук - это "дизайн протокола" - когда протокол понимает, что этот код может привести к проблемам, но берет ответственность за свои действия и не будет ничего менять в коде, около 6 репортов - уже известные проблемы, около 4 - из Med в Low/Info, еще 4 - валидные и остальные - не валидные.
Другими словами, из 28 отчетов будут приняты около 3-4.
Когда я провожу реальный аудит, я читаю документацию, повторяю EIP, которые используются в протоколе, смотрю тесты и комментарии, построчно иду по коду и часто пишу заказчикам, чтобы удостовериться в каком-либо моменте. Если не могу доказать баг тестами, то в репорте веду отдельный блок с комментариями по коду, на что нужно обратить внимание.
В конкурсных же аудитах я "забил" на валидацию в пользу количества репортов и затраченного времени.
Как вы сами можете видеть, это не окупается ни по работе, ни по оплате.
Короче - не делайте так. Репорты с недостаточной валидацией - отстой!
На ближайшее время хочу попробовать другой подход: вместо поиска паттернов и максимума отчетов, генерировать возможные пути атаки и валидировать их. Это сложно объяснить, но, например, вместо поиска слабых мест в контракте и его логике, искать способы атаки на эти места. Если не могу на 100% доказать такой факт, то репорт - мимо.
Если тоже учитесь аудитам и уже пробовали себя в конкурсах, то предлагаю "поковырять" один небольшой баг баунти с Immunefi. Создадим закрытый чат, скину репо и каждый день будем в чате обмениваться ходом аудита.
Что скажете, кто-нибудь хочет поучаствовать?
#audit
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍9
Программа интенсива по Foundry для новичков
По прошедшему ранее опросу, 35 участников канала хотели бы пойти на интенсив и еще 25 - подумают об этом! Это прекрасное количество, чтобы провести модуль немного раньше, чем я планировал.
Сегодня хочу представить вам программу интенсива, которая подойдет для тех, кто только учится тестированию или хотел бы перейти с Hardhat.
Я постарался структурировать информацию из открытого цикла постов по Foundry, который уже был на канале пару дет назад, обновив и дополнив многие моменты. Кроме того, добавлена практическая часть для получения навыков работы с системой приложений Foundry и написанием современных тестов.
Интенсив рассчитан на 3 недели. На 4 неделе будет пара бонусных постов и финальный практикум.
Хочу подчеркнуть, что данный интенсив для новичков в тестировании и работе с Foundry. Более продвинутые темы, такие как инвариант тестирование, формальная верификации, работа с обновляемыми контрактами, фаззинг значений из служебных функций, подключение сторонних плагинов - еще в разработке и, скорее всего, будет выпущен в конце года.
А пока, вот список тем по неделям:
Неделя 1
1. Установка Foundry: что входит в программу и для чего это нужно
2. Знакомство с cast командами. Чем они нужны и как работают
3. Сложные команды cast, которые пригодятся разработчику
4. Работа с chisel. Побитовые сдвиги и форк сети
5. Настройки Foundry: профили, библиотеки, пути
Неделя 2
6. Какие тесты бывают: правила написания и формирования папки проекта
7. Создание setUp() функции для удобного написания тестов. Роли пользователей, управление временем в тестах
8. Логика assert условий
9. Работа с ошибками и событиями в тестах
10. Логирование результатов теста и вывод в консоль
Неделя 3
11. Фазз тесты
12. Форк тесты. Интеграции с другими протоколами
13. Мутационные тесты
14. Тестирование подписей в контрактах
15. Деплой в разные сети. Написание простых скриптов
Неделя 4. Бонусные уроки
16. Интеграция с Hardhat
17. Хранение приватных ключей
18. Современные программы тестирования
19. Финальный практикум
Какие знания потребуются для прохождения интенсива:
- Знание Solidity на среднем уровне;
- Понимание популярных ERC - ERC20, ERC721, ERC712, ERC4626;
- Навыки работы с консолью / терминалом;
- Умение подключать зависимости в протокол;
- Знакомство с популярными протоколами типа Uniswap/Chainlink;
По стоимости будет 3000 рублей для тех, кто присоединялся хотя бы к одному из основных модулей курса, или 4000 рублей для всех других желающих.
Начать думаю в первых числах марта. О старте продаж будет еще отдельный пост на канале.
Если есть какие-либо вопросы, буду рад ответить в комментариях!
#foundry
По прошедшему ранее опросу, 35 участников канала хотели бы пойти на интенсив и еще 25 - подумают об этом! Это прекрасное количество, чтобы провести модуль немного раньше, чем я планировал.
Сегодня хочу представить вам программу интенсива, которая подойдет для тех, кто только учится тестированию или хотел бы перейти с Hardhat.
Я постарался структурировать информацию из открытого цикла постов по Foundry, который уже был на канале пару дет назад, обновив и дополнив многие моменты. Кроме того, добавлена практическая часть для получения навыков работы с системой приложений Foundry и написанием современных тестов.
Интенсив рассчитан на 3 недели. На 4 неделе будет пара бонусных постов и финальный практикум.
Хочу подчеркнуть, что данный интенсив для новичков в тестировании и работе с Foundry. Более продвинутые темы, такие как инвариант тестирование, формальная верификации, работа с обновляемыми контрактами, фаззинг значений из служебных функций, подключение сторонних плагинов - еще в разработке и, скорее всего, будет выпущен в конце года.
А пока, вот список тем по неделям:
Неделя 1
1. Установка Foundry: что входит в программу и для чего это нужно
2. Знакомство с cast командами. Чем они нужны и как работают
3. Сложные команды cast, которые пригодятся разработчику
4. Работа с chisel. Побитовые сдвиги и форк сети
5. Настройки Foundry: профили, библиотеки, пути
Неделя 2
6. Какие тесты бывают: правила написания и формирования папки проекта
7. Создание setUp() функции для удобного написания тестов. Роли пользователей, управление временем в тестах
8. Логика assert условий
9. Работа с ошибками и событиями в тестах
10. Логирование результатов теста и вывод в консоль
Неделя 3
11. Фазз тесты
12. Форк тесты. Интеграции с другими протоколами
13. Мутационные тесты
14. Тестирование подписей в контрактах
15. Деплой в разные сети. Написание простых скриптов
Неделя 4. Бонусные уроки
16. Интеграция с Hardhat
17. Хранение приватных ключей
18. Современные программы тестирования
19. Финальный практикум
Какие знания потребуются для прохождения интенсива:
- Знание Solidity на среднем уровне;
- Понимание популярных ERC - ERC20, ERC721, ERC712, ERC4626;
- Навыки работы с консолью / терминалом;
- Умение подключать зависимости в протокол;
- Знакомство с популярными протоколами типа Uniswap/Chainlink;
По стоимости будет 3000 рублей для тех, кто присоединялся хотя бы к одному из основных модулей курса, или 4000 рублей для всех других желающих.
Начать думаю в первых числах марта. О старте продаж будет еще отдельный пост на канале.
Если есть какие-либо вопросы, буду рад ответить в комментариях!
#foundry
🔥11👍1
Обязательный Foundry
В прошлую среду я предложил разобрать один bug bounty и этот процесс натолкнул меня на написание этого поста.
Сам протокол написан с использованием обновляемых контрактов UUPS, да еще и с Beacon Proxy. При том, что я понимаю как работают паттерны этих прокси, но в данном случае была какая-то авторская разработка и мне пришлось потратить пару часов, чтобы разобраться как все там работает.
В процессе разбора были такие моменты, когда казалось, что "Вот! Здорово! Баг найден! Это по-любому приведет к взлому и можно писать отчет." А для отчета нужен PoC...
Сидишь такой, пишешь тесты, и оказывается, что бага нет. В какой-то момент происходит реверт, отрабатывая require в коде, или переменная состояния не позволяет выполнить действие. И казалось бы 100% баг перестает быть таковым... Обидно, досадно, но ладно.
В целом, я не особо люблю писать тесты в конкурсных протоколах, так как это занимает время самого аудита. И мы возвращаемся к описанной ранее в постах проблеме недостаточной валидации.
Foundry давно стал стандартом написания тестов в мире аудита. Immunefi, портал для bug bounty, требует к каждому репорту добавлять функциональный PoC. Платформа для конкурсов Cantina стала требовать у своих аудиторов с определенной бальной системой добавление тестов к отчетам. Скоро и другие платформы сделают это обязательным условием для участия в конкурсах, либо будут резать выплаты находкам без тестов.
Тесты - это как железобетонные доказательства. Для разработчиков - что функция отрабатывает так как надо, для аудиторов - что баг действительно есть.
Пару лет назад, в вакансиях доминировали Truffle и Hardhat, потом основным стал Hardhat и Truffle и немного Foundry. Потом все начали забывать о Truffle и в вакансиях требовались знания или/или - Hardhat/Foundry. Теперь же Foundry чуть больше доминирует на рынке из-за своего более простого освоения.
Foundry уже не опция для знаний разработчика, а обязанность. Даже если вы мастер JavaScript и можете без проблем написать тесты на Hardhat.
Уже в прошлом году стали появляться компании, которые выводят Foundry на новый уровень, упрощая разработку инвариант тестов и проверок формальной верификации. В этом году будет еще больше "движений" в эту сторону.
И если вы будете откладывать изучение Foundry, то в какой-то момент нужно будет учить его не по чуть-чуть, вместе с развитием программы, а сразу большим объемом.
#foundry
В прошлую среду я предложил разобрать один bug bounty и этот процесс натолкнул меня на написание этого поста.
Сам протокол написан с использованием обновляемых контрактов UUPS, да еще и с Beacon Proxy. При том, что я понимаю как работают паттерны этих прокси, но в данном случае была какая-то авторская разработка и мне пришлось потратить пару часов, чтобы разобраться как все там работает.
В процессе разбора были такие моменты, когда казалось, что "Вот! Здорово! Баг найден! Это по-любому приведет к взлому и можно писать отчет." А для отчета нужен PoC...
Сидишь такой, пишешь тесты, и оказывается, что бага нет. В какой-то момент происходит реверт, отрабатывая require в коде, или переменная состояния не позволяет выполнить действие. И казалось бы 100% баг перестает быть таковым... Обидно, досадно, но ладно.
В целом, я не особо люблю писать тесты в конкурсных протоколах, так как это занимает время самого аудита. И мы возвращаемся к описанной ранее в постах проблеме недостаточной валидации.
Foundry давно стал стандартом написания тестов в мире аудита. Immunefi, портал для bug bounty, требует к каждому репорту добавлять функциональный PoC. Платформа для конкурсов Cantina стала требовать у своих аудиторов с определенной бальной системой добавление тестов к отчетам. Скоро и другие платформы сделают это обязательным условием для участия в конкурсах, либо будут резать выплаты находкам без тестов.
Тесты - это как железобетонные доказательства. Для разработчиков - что функция отрабатывает так как надо, для аудиторов - что баг действительно есть.
Пару лет назад, в вакансиях доминировали Truffle и Hardhat, потом основным стал Hardhat и Truffle и немного Foundry. Потом все начали забывать о Truffle и в вакансиях требовались знания или/или - Hardhat/Foundry. Теперь же Foundry чуть больше доминирует на рынке из-за своего более простого освоения.
Foundry уже не опция для знаний разработчика, а обязанность. Даже если вы мастер JavaScript и можете без проблем написать тесты на Hardhat.
Уже в прошлом году стали появляться компании, которые выводят Foundry на новый уровень, упрощая разработку инвариант тестов и проверок формальной верификации. В этом году будет еще больше "движений" в эту сторону.
И если вы будете откладывать изучение Foundry, то в какой-то момент нужно будет учить его не по чуть-чуть, вместе с развитием программы, а сразу большим объемом.
#foundry
❤5👍3🔥3💯1
Проблемы с обучением и прохождением курсов
Вчера в разговоре со знакомым аудитором речь зашла о возрасте аудиторов и их успехах на поприще поиска багов в конкурсах и баг баунти. Я жаловался, что не получается уделять больше 3-4 часов в день на изучение протоколов, так как помимо этого есть еще и другие дела ежедневно требующие внимания. Легко в этом плане некоторым молодым людям, до 25 лет, у которых еще нет стабильной работы, семьи, детей, и т.д. Они ищут себя, могут много учиться и уделять время тому, что действительно зажигает. Многих могут так или иначе поддерживать родители, и не нужно думать, где взять денег на оплату квартиры и еды.
Не хочу никого обидеть в возрастном плане или в жизненной ситуации, просто говорю, что, если у человека меньше повседневных забот, он может больше времени уделять своему обучению и профессии. Намного проще и быстрее стать хорошим аудитором или разработчиком, если можете без труда уделять 8-10 часов в день своему обучению или аудиту.
Мне повезло, что на момент своего переобучения в web3 я, во-первых, уже был разработчиком, и во-вторых, мог в течение года уделять достаточно времени обучению.
Но вчера я понял, что изучение Solidity/Foundry и чего-то еще может быть трудной задачей, когда ты работаешь на тяжелой (эмоционально и физически) работе, по паре часов тратишь время на дорогу, вечером нужно провести время с семьей, детьми или просто второй половинкой. К тому же постоянно приходят счета на оплату, случаются мелкие неприятности и т.д. И это все намного важнее web3 и порой "выбивает из времени и пространства"...
Я пишу посты на двух каналах и только сейчас задумался об этом.
Что могло бы помочь вам в обучении? Может какой-то формат постов, которые можно читать в метро или автобусе? Мелкие задания на закрепления материалов?
Если и делать далее какие-нибудь модули, то так, чтобы было удобно и практично в любой момент.
Можете поделиться своими способами обучения? Как вам удобнее всего изучать новый материал?
У нас тут большой канал с техническими постами, и, думаю, есть много участников, которые постоянно чему-то учатся. Буду рад услышать ваши лайфхаки.
#learn
Вчера в разговоре со знакомым аудитором речь зашла о возрасте аудиторов и их успехах на поприще поиска багов в конкурсах и баг баунти. Я жаловался, что не получается уделять больше 3-4 часов в день на изучение протоколов, так как помимо этого есть еще и другие дела ежедневно требующие внимания. Легко в этом плане некоторым молодым людям, до 25 лет, у которых еще нет стабильной работы, семьи, детей, и т.д. Они ищут себя, могут много учиться и уделять время тому, что действительно зажигает. Многих могут так или иначе поддерживать родители, и не нужно думать, где взять денег на оплату квартиры и еды.
Не хочу никого обидеть в возрастном плане или в жизненной ситуации, просто говорю, что, если у человека меньше повседневных забот, он может больше времени уделять своему обучению и профессии. Намного проще и быстрее стать хорошим аудитором или разработчиком, если можете без труда уделять 8-10 часов в день своему обучению или аудиту.
Мне повезло, что на момент своего переобучения в web3 я, во-первых, уже был разработчиком, и во-вторых, мог в течение года уделять достаточно времени обучению.
Но вчера я понял, что изучение Solidity/Foundry и чего-то еще может быть трудной задачей, когда ты работаешь на тяжелой (эмоционально и физически) работе, по паре часов тратишь время на дорогу, вечером нужно провести время с семьей, детьми или просто второй половинкой. К тому же постоянно приходят счета на оплату, случаются мелкие неприятности и т.д. И это все намного важнее web3 и порой "выбивает из времени и пространства"...
Я пишу посты на двух каналах и только сейчас задумался об этом.
Что могло бы помочь вам в обучении? Может какой-то формат постов, которые можно читать в метро или автобусе? Мелкие задания на закрепления материалов?
Если и делать далее какие-нибудь модули, то так, чтобы было удобно и практично в любой момент.
Можете поделиться своими способами обучения? Как вам удобнее всего изучать новый материал?
У нас тут большой канал с техническими постами, и, думаю, есть много участников, которые постоянно чему-то учатся. Буду рад услышать ваши лайфхаки.
#learn
🔥13❤4🤔2🙏2
Постфикс и префикс в Solidity
Продолжаю свои попытки в видео формат. В этот раз добавил субтитры, на случай если ролик будут смотреть без звука.
Сложно подобрать какие-либо визуальные выделения кода на видео (обводка функций, подчеркивание, увеличение "под лупу"). Одной программы не достаточно, а при нескольких переводов из одной программы в другую, сильно падает качество видео. И если, скажем, для съемок природы или кошко-девочки это будет не критично, то для отображения кода в редакторе - просто жесть...
Но это так, просто делюсь процессом и трудностями.
Если захотите покопаться в коде протокола с видео, то вот ссылка на контаркт:
https://github.com/code-423n4/2025-01-liquid-ron/blob/main/src/ValidatorTracker.sol#L36
Всем приятной пятницы и отличных выходных!
P.S. Буду также признателен комментариям по формату видео: что можно улучшить, что добавить или вообще убрать.
#video
Продолжаю свои попытки в видео формат. В этот раз добавил субтитры, на случай если ролик будут смотреть без звука.
Сложно подобрать какие-либо визуальные выделения кода на видео (обводка функций, подчеркивание, увеличение "под лупу"). Одной программы не достаточно, а при нескольких переводов из одной программы в другую, сильно падает качество видео. И если, скажем, для съемок природы или кошко-девочки это будет не критично, то для отображения кода в редакторе - просто жесть...
Но это так, просто делюсь процессом и трудностями.
Если захотите покопаться в коде протокола с видео, то вот ссылка на контаркт:
https://github.com/code-423n4/2025-01-liquid-ron/blob/main/src/ValidatorTracker.sol#L36
Всем приятной пятницы и отличных выходных!
P.S. Буду также признателен комментариям по формату видео: что можно улучшить, что добавить или вообще убрать.
#video
🔥10❤3
Обучающий модуль по Foundry?
Новый месяц, новые знания и цели!
Прежде всего, ниже будет еще один опрос для желающих пройти интенсив по работе с Foundry, и прошу всех, кто точно планирует зайти на него, проголосовать.
Если будет небольшое количество желающих, то мы перенесем его на более поздний срок. Если же группа наберется, то мы начнем уже со следующей неделе, а продажи откроем в эту среду.
Больше информации о самом интенсиве можно найти в этом посте:
https://news.1rj.ru/str/solidityset/1310
Я провожу опрос, чтобы распределить свою нагрузку на этот месяц: либо отменю часть работ и большую часть времени буду уделять ученикам и ответам на вопросы, либо сам больше буду принимать участие в bug bounty программах и конкурсах по аудиту, а на канале будем разбирать интересные темы с delegatecall.
Также напоминаю, что я еще веду параллельно небольшой канал по Defi:
https://news.1rj.ru/str/defisolset
Недавно мы закончили делать разбор протокола Torando Cash, а после рассмотрели темы процентной ставки AAVE V3 и Compound, а также ликвидации и залога. Сейчас знакомимся с Aave v3.
Это, скорее, канал для продвинутых разработчиков, которые уже знают Solidity, и которым интересна тема DeFi протоколов.
Всем приятной недели и легкого обучения!
#offtop
Новый месяц, новые знания и цели!
Прежде всего, ниже будет еще один опрос для желающих пройти интенсив по работе с Foundry, и прошу всех, кто точно планирует зайти на него, проголосовать.
Если будет небольшое количество желающих, то мы перенесем его на более поздний срок. Если же группа наберется, то мы начнем уже со следующей неделе, а продажи откроем в эту среду.
Больше информации о самом интенсиве можно найти в этом посте:
https://news.1rj.ru/str/solidityset/1310
Я провожу опрос, чтобы распределить свою нагрузку на этот месяц: либо отменю часть работ и большую часть времени буду уделять ученикам и ответам на вопросы, либо сам больше буду принимать участие в bug bounty программах и конкурсах по аудиту, а на канале будем разбирать интересные темы с delegatecall.
Также напоминаю, что я еще веду параллельно небольшой канал по Defi:
https://news.1rj.ru/str/defisolset
Недавно мы закончили делать разбор протокола Torando Cash, а после рассмотрели темы процентной ставки AAVE V3 и Compound, а также ликвидации и залога. Сейчас знакомимся с Aave v3.
Это, скорее, канал для продвинутых разработчиков, которые уже знают Solidity, и которым интересна тема DeFi протоколов.
Всем приятной недели и легкого обучения!
#offtop
🔥4
Foundry откладывается, но будет что-то интересное!
К сожалению, проголосовавших за участие в модуле не набралось достаточного количества, поэтому я принял решение немного повременить с данным интенсивом. Скорее всего, теперь он будет включен в большой Летний Практический модуль. Те, кто хотел зайти на него в этот раз, просто смогут докупить его отдельно.
При этом дела у нас всегда есть: на канале будут дальше выходить посты про Solidity, я по не многу буду записывать видео про всякие интересные штуки в коде, и подумываю сделать долгий цикл постов про создание dApp.
За все три года, что ведется этот канал, я никогда не поднимал тему, как создавать свои проекты, которые будут взаимодействовать с блокчейном: как написать сайт на react, как подключить регистрацию через кошелек, как делать вызовы в сеть и отслеживать результат, и т.д.
И решил, что было бы полезно написать цикл постов, в котором буду показывать как создать простой проект: от идеи до запуска. Мы будем обсуждать идеи, решения и проблемы безопасности. Вы увидите полный цикл создания dApp.
Основной идеей будет сделать так, чтобы все стало понятно новичку: самый базовый код JS, бэкенд и все остальное, чтобы вы могли по моим стопам делать свой собственный продукт.
Это цикл постов на полгода-год, так как буквально будет включать каждый этап разработки. Выходить посты будут по мере возможностей, так как делать их буду в свободное от основной работы время.
Пока как-то так! Возвращаемся в "задротное русло".
#offtop
К сожалению, проголосовавших за участие в модуле не набралось достаточного количества, поэтому я принял решение немного повременить с данным интенсивом. Скорее всего, теперь он будет включен в большой Летний Практический модуль. Те, кто хотел зайти на него в этот раз, просто смогут докупить его отдельно.
При этом дела у нас всегда есть: на канале будут дальше выходить посты про Solidity, я по не многу буду записывать видео про всякие интересные штуки в коде, и подумываю сделать долгий цикл постов про создание dApp.
За все три года, что ведется этот канал, я никогда не поднимал тему, как создавать свои проекты, которые будут взаимодействовать с блокчейном: как написать сайт на react, как подключить регистрацию через кошелек, как делать вызовы в сеть и отслеживать результат, и т.д.
И решил, что было бы полезно написать цикл постов, в котором буду показывать как создать простой проект: от идеи до запуска. Мы будем обсуждать идеи, решения и проблемы безопасности. Вы увидите полный цикл создания dApp.
Основной идеей будет сделать так, чтобы все стало понятно новичку: самый базовый код JS, бэкенд и все остальное, чтобы вы могли по моим стопам делать свой собственный продукт.
Это цикл постов на полгода-год, так как буквально будет включать каждый этап разработки. Выходить посты будут по мере возможностей, так как делать их буду в свободное от основной работы время.
Пока как-то так! Возвращаемся в "задротное русло".
#offtop
1👍13🔥5❤2❤🔥1😱1