Solidity. Смарт контракты и аудит

Пробы записи видео и разбор функций

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

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

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

Сейчас пара вопросов:

1. Как вообще видео по формату? Удобно ли смотреть с телефона, не раздражает ли что, все ли четко и по делу?
2. Что надо улучшить (субтитры, крупнее код, подсвечивать код или что-то другое)?

Я только учусь, поэтому любой фидбек будет ценен для меня.

По данному видео, вот ссылки на протокол и функцию из видео.

#video

Минимальные требования для работы

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

В целом я заметил некую тенденцию, которая меня сильно раздражала в описании вакансий в России и СНГ в целом. Иногда складывалось впечатление, что описания пишутся 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

Найти работу или получать заказы?

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

Буквально вчера я спорил с разработчиком Rust/Solidity, который утверждал, что если ты крутой разработчик, то с легкость найдешь хорошо оплачиваемую работу и иметь присутствие в сети вовсе не обязательно, ну, понятное дело, за исключением профиля на LinkedIn и GitHub.

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

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

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

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

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

Количество подписчиков вообще не играет роли. Нужно только чтобы потенциальный заказчик или рекрутер нашел ваш профиль и изучил его.

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

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

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

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

И это только с текстовых форматов. Если вы сможете все рассказывать в видео/фото формате, то продвинетесь намного скорее.

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

#pb

Solidity. Смарт контракты и аудит pinned «Планируете пойти на интенсив?»

Интенсив по Foundry с нуля

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

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

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

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

Стоимость будет будет около 4000 рублей для всех и 3000 рублей для тех, кто приходил хотя бы на один обучающий модуль курса ранее.

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

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

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

#foundry

Обновляемые контракты (Transparent proxy). Часть 5

Почему функция называется 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

Что по аудитам?

Прервусь на день с темой обновляемых контрактов, чтобы рассказать снова про конкурсные аудиты. Если помните, то в конце ноября прошлого года я решил заново научиться проводить аудит протокола. Моей основной идеей тогда было научиться понимать протокол за максимально короткое время, так как я не могу уделять больше 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

Обновляемые контракты (Transparent proxy). Часть 4

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

Обновляемые контракты (Transparent proxy). Часть 3

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

Обновляемые контракты (Transparent proxy). Часть 2

Transparent Upgradeable Proxy - это паттерн, полностью исключающий возможность столкновения селекторов функций.

В частности, TUP предписывает, что в прокси контракте не должно быть никаких публичных функций, кроме fallback.

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

Ответ заключается в том, чтобы определить, является ли отправитель msg.sender администратором.

contract Proxy is ERC1967 {
    address immutable admin;

    constructor(address admin_) {
        admin = admin_
    }

    fallback() external payable {
        if (msg.sender == admin) {
            // upgrade logic
        } else {
            // delegatecall to implementation
        }
    }
}

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

Изменение неизменяемого администратора

В приведенном выше фрагменте кода администратор является неизменяемым. Это означает, что контракт технически не соответствует стандарту ERC-1967, который гласит, что администратор должен храниться в слоте хранения 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 или bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1).

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

Наличие адреса в этом слоте будет сигнализировать другим программам, что контракт является прокси (одна из целей ERC-1967). Однако чтение из хранилища при каждом обращении к прокси добавляет к вызову еще 2100 газа. Поэтому желательно использовать неизменяемую переменную.

«Смена» администратора

Однако все же желательно иметь возможность обновлять адрес администратора - но изначально это кажется невозможным.

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

Во-вторых, владелец ProxyAdmin является «истинным» администратором. ProxyAdmin просто направляет вызовы от владельца к прокси. «Истинный» администратор вызывает ProxyAdmin, а ProxyAdmin вызывает Transparent Proxy. Изменив владельца ProxyAdmin, мы можем изменить, кто имеет возможность обновлять Transparent Proxy.

Далее поговорим об этом интересном контракте.

#proxy #transparent

Обновляемые контракты (Transparent proxy). Часть 1

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

Transparent Upgradeable Proxy (далее TUP) - это паттерн для обновления прокси контрактов, исключающий возможность столкновения селекторов функций.

Хороший прокси контракт должен обладать как минимум двумя следующими характеристиками:

- слотом для хранения адреса контракта Логики;
- механизмом, позволяющим администратору изменять адрес Логики;

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

Столкновение селекторов функций (Function Selector Clashing)

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

Вот простой пример:

contract ProxyUnsafe {

    function changeImplementation(
            address newImplementation
    ) public {
        // some code...
    }

    fallback(bytes calldata data) external payable (bytes memory) {
        (bool ok, bytes memory data) = getImplementation().delegatecall(data);
        require(ok, "delegatecall failed");
        return data;
    }
}

contract Implementation {
    // an identical function is declared here -- they will clash
    function changeImplementation(
            address newImplementation
    ) public {

    }
    //...
}

Помните, что fallback всегда проверяется в последнюю очередь?

Перед вызовом fallback контракт прокси проверит, совпадает ли 4-байтовый селектор функции с changeImplementation (или любой другой публичной функцией в прокси).

И если в прокси объявлена публичная функция, могут возникнуть два вида столкновений селекторов функций:

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

2. Если в контракте Логики есть функция с тем же селектором функций, что и публичная функция в прокси, она также будет невызываемой по той же причине. Этот сценарий представляет собой столкновение селекторов функций. Вероятность того, что у двух разных функций будет одинаковый селектор, равна 1 к 4,29 миллиарда; селектор функции состоит из 4 байт, поэтому существует 4,29 миллиарда возможностей. Это небольшая вероятность, но не нулевая. Например, у clash550254402() тот же селектор функции, что и у proxyAdmin().

А далее мы поговорим, как TUP помогает решить эту проблему.

#proxy #transparent

Безопасная крипта

Мне снова требуется помощь сообщества.

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

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

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

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

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

1. Токены с такими же инициалами и названием легко создать в любой сети и обмануть пользователя;
2. Не на каждой сети может быть нужный токен;
3. Существуют обертки токенов (eBTC, WETH);
4. Нужно минимум два токена на кошельке (один дл оплаты комиссии и один требуемый);
5. Как проверить адрес токена;

Или также про владение кошельком:

1. Нельзя покупать уже готовый кошелек;
2. Нужно хранить секретную фразу от всех;
3. Нельзя заходить в чужие кошельки, если где-то встретили сид-фразу;

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

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

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

#safecrypto

Самые популярные типы DAO. Часть 3

С легкого поста мы начинаем неделю и заканчиваем рассказ про DAO, остались последние 4 вида.

Коллекционные DAO

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

Примеры коллекционных DAO

Такие известные DAO, как FlamingoDAO, возникли после бума NFT и собирали невероятно дорогие NFT от таких цифровых художников, как Pak, Hackatao, XCopy, а также CryptoPunk #2890 NFT, который был куплен в 2021 году за $760 тысяч долларов США.

Другая группа коллекционеров сформировала ConstitutionDAO в попытке купить Конституцию Соединенных Штатов. Примечательно, что ConstitutionDAO за одну неделю собрала ETH на сумму 47 миллионов долларов, чтобы попытаться купить копию Конституции США первого издания на аукционе Sotheby's.

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

Инвестиционные и венчурные DAO

Венчурные DAO объединяют капитал для инвестирования в стартапы ранней стадии web3, протоколы, offchain инвестиции и получают доступ к портфелям, недоступным в традиционном финансировании.

Примеры венчурных DAO

Krause House DAO - это венчурная DAO, которая пытается купить профессиональную команду NBA, состоящую из инвесторов и фанатиков баскетбола. Члены Krause House DAO будут участвовать в принятии решений, влияющих на операционные процедуры команды Национальной баскетбольной ассоциации, включая, помимо прочего, общее управление, продажу билетов, мерчендайзинг и партнерские отношения.

Среди других известных венчурных DAO можно отметить MetaCartel Ventures (MCV), которая является коммерческой DAO, созданной сообществом MetaCartel для инвестирования в децентрализованные приложения (DApps) на ранних стадиях, и BessemerDAO, которая была запущена венчурной фирмой Bessemer Venture Partners из Сан-Франциско для обсуждения тенденций в криптоиндустрии и обмена ресурсами.

Медиа DAO

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

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

Примеры медиа DAO

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

Decrypt - еще один пример медиа DAO, который позволяет пользователям голосовать за то, какой контент они хотят видеть.

Медиа DAO особенно эффективны для новых сообществ, которые хотят вознаградить своих пользователей по мере развития криптосообщества и культуры Web 3.0.

SubDAO

SubDAO - это новый вид DAO, который представляет собой подмножество членов DAO, организованных для управления конкретными функциями, такими как операции, партнерство, маркетинг, казначейство и гранты.

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

В результате единогласного голосования Balancer DAO успешно интегрировал subDAO в свою структуру и теперь может двигаться более эффективно как децентрализованная автономная организация.

Креативность сообщества - это действительно предел того, что можно создать в рамках DAO.

Возможно, один из этих DAO натолкнет вас на новую идею своего проекта и позволить помочь развитию web3!

#dao

Самые популярные типы DAO. Часть 2

Продолжаем разбирать разные форматы DAO.

Грантовые DAO

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

Примеры грантовых DAO

Aave Grants DAO - это программа под руководством сообщества, направленная на финансирование идей и проектов, способствующих развитию протокола Aave, с упором на поддержку более широкой сети разработчиков сообщества.

Гранты Aave выделяют определенную сумму финансирования в квартал. В число приемлемых заявок на гранты входят, но не ограничиваются ими: разработка Aave, интеграции, инструменты для разработчиков и многое другое.

Одним из примеров грантовой DAO, которая является отдельной организацией, является MetaCartel, которая предоставляет финансирование проектам и оказывает операционную поддержку dapp на ранних стадиях.

Задавшись целью ускорить создание Web3, MetaCartel выделяет гранты от 1 000 до 10 000 долларов на dApp, построенные на Ethereum, новые эксперименты с потребительскими кейсами, создание новых DAO, инициативы, ориентированные на сообщество, и многое другое.

Филантропические DAO

Филантропические DAO стремятся содействовать развитию социальной ответственности, организуясь вокруг общей цели для создания влияния в мире Web3.

Примеры филантропических DAO

Первая некоммерческая филантропическая DAO, Big Green DAO, связана с Big Green, национальной благотворительной организацией 501(c3), занимающейся вопросами продовольственной справедливости, которая учит людей выращивать продукты для повышения безопасности питания, улучшения психического здоровья и воздействия на климат. Big Green DAO присоединилась к благотворительной организации с десятилетней историей, чтобы реструктурировать процесс предоставления грантов и привести некоммерческую организацию в выгодное финансовое положение.

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

Социальные DAO

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

Хотя социальные DAO ориентированы на сообщество, обычно они имеют барьер для входа, например, владение определенным количеством токенов, владение NFT или личное приглашение.

Примеры DAO создателей

Developer DAO - это коллектив разработчиков web3, нацеленный на создание будущего web3. Чтобы присоединиться к Developer DAO, участники должны обладать NFT Genesis или быть одним из счастливчиков, приглашенных на частный сервер Discord.

Friends With Benefits - это DAO создателей web3, ориентированная на создание сообщества и развитие творчества. Вход в Friends With Benefits стоит 75 токенов FWB, и после приема участники получают полный доступ к общению со строителями, художниками, креативщиками и посещению эксклюзивных мероприятий.

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

И в понедельник узнаем о еще четырех видах популярных DAO.

#dao

Самые популярные типы DAO. Часть 1

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

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

Первая децентрализованная автономная организация

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

Первая децентрализованная автономная организация, получившая название «The DAO», была построена на основе смарт-контрактов, использовала фреймворк с открытым исходным кодом и была ориентирована на венчурный капитализм.

К сожалению, из-за ошибки в смарт-контракте The DAO потеряла 3,6 миллиона ETH и не смогла восстановиться в финансовом плане. Тем не менее, The DAO проложила путь для многих других успешных DAO.

Лето DeFi в 2018 году принесло на блокчейн Ethereum флагманские проекты децентрализованных финансов, такие как Compound Finance (COMP), Uniswap (UNI) и Aave (AAVE), которые предлагали участникам сообщества привлекательные способы продемонстрировать свою приверженность децентрализации с помощью токенов управления DAO.

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

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

Можно выделить следующий типы DAO:

1. Protocol DAOs
2. Grant DAOs
3. Philanthropy DAOs
4. Social DAOs
5. Collector DAOs
6. Venture DAOs
7. Media DAOs
8. SubDAOs

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

Protocol DAOs

Протокольный DAO - это тип DAO, который предназначен для управления децентрализованным протоколом, таким как приложение для займов/кредитования, децентрализованная биржа или другой тип dapp.

Примеры протокольных DAO

Три наиболее заметных примера протокольных DAO - MakerDAO, Uniswap и Yearn Finance.

MakerDAO

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

MakerDAO использует токены управления MKR, чтобы держатели могли голосовать за изменения в протоколе Maker, включая сумму обеспечения для залоговых долговых позиций (CDP), ежегодные займы и прекращение работы в случае краха Ethereum.

Держатели MKR также выступают в качестве покупателей последней инстанции для займов DAI (алгоритмический стейблкоин, созданный MakerDAO). Если стоимость ETH в хранилищах Maker Vaults не покрывает количество DAI в обращении, MKR создается и продается на долговом аукционе, чтобы привлечь необходимое количество средств.

Uniswap

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

Если держатели токенов хотят изменить Uniswap или ввести новые функции, для дальнейшего обсуждения необходимо подать предложение, набрав не менее 25 000 голосов «за» UNI.

Yearn Finance

Как и вышеупомянутые DAO с токенами управления, Yearn DAO делегирует финансирование DAO Vaults. Держатели YFI могут предоставлять средства DAO, одобренным для приема финансирования в экосистеме хранилищ DAO. Восполняя пробел в традиционной системе управления персоналом и начисления заработной платы, основатель YFI Андре Кронье создал Coordinape для автономного распределения средств и вознаграждения вкладчиков.

Далее поговорим про остальные виды.

#dao

Вредоносные плагины в VScode

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

#vscode

Выходим из отпуска и возвращаемся к работе

Фух, это был самый длинный мой отпуск за последние три года. Целый месяц практически без Solidity, аудитов, блога, сайта и всего другого связанного с web3. Голова немного проветрилась, мысли прояснились и появилась мотивация к новым действиям!

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

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

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

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

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

Также на DeFi канале мы закончим с разбором протокола Tornado Cash и его деревьями Меркла и начнем погружаться в тему: что такое perpetuals. Я вижу, что все больше протоколов так или иначе используют эти наработки и хочу сам разобраться в деталях.

Вместе с этим на канале будет выходить много постов про Solidity и разработку в целом. Мы поговорим про: обновляемые контракты, delegatecall, метадату и реорганизацию сетей. А на этой неделе, для легкого старта, поговорим про разные типы DAO систем.

В общем, год будет интересным! Приятного обучения!

#start

С Новым Годом 🎄🎄🎄

Каждый год встречаюсь с дилеммой: а когда же все таки слать поздравления: в канун Нового года, типа как "с наступающим", или уже когда он наступил, т.е. 1 января? И тем не менее...

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

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

Пусть каждый из вас не испугается объёма знаний, их сложности и продолжительности обучения! Пусть найдет то, что мотивирует двигаться дальше и зарабатывать большие деньги!

С Новым годом, друзья! Будьте счастливы в 2025 году!

🎄🎄🎄

Последний пост этого года

Уже около трех лет я в теме web3, solidity, сетей, аудита и хочу сказать, что до сих пор не могу назвать себя не то, что сеньором, а даже твердым мидлом. Каждый раз, когда я читаю статьи от RareSkills или ветки обсуждений каких-то нишевых особенностей сети или языка от зарубежных коллег, я всегда такой: "Вау! Я тоже хочу знать это, на том же уровне!". Это и дает мне заряд мотивации вести канал, делиться интересными постами, делать переводы и много чего еще.

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

На следующий год я для себя выделил три ключевых направления для собственного обучения:

1. Аудит и безопасность. Эта тема меня действительно зажигает! Мне нравится читать отчеты, порой участвовать в конкурсах и помогать делать протоколы более безопасными. Я хочу освоить скилл создания видео, где в формате коротких роликов показывал бы баги из репортов и моменты, на которые стоит обращать внимание при разработке смарт контрактов. Это поможет как развитию канала, так и начинающим web3 разработчикам совершать меньше ошибок.

2. Разбор DeFi протоколов. При том, что я понимаю и разбираюсь в общих чертах финансовых протоколов, например, могу рассказать, чем отличаются версии Balancer v1 и v2, у меня все равно пробелы в знаниях о том, как работает все на уровне кода, и, кроме того, в чем особенности экономической модели. В общем, буду подтягивать эту тему.

3. Видео... Долбанный видео формат, который мне никак не удается совместить с демонстрацией кода в вертикальном формате. У меня давно было желание записывать видео по темам Solidity, безопасность и какие-нибудь разборы. Получилось провести даже два стрима (большое спасибо за вашу поддержку еще раз!). Но этот формат все никак не дается мне: то код маленький, то не знаю, как нарисовать схему на экране, то нужно много переключений между вкладками... Поэтому буду учиться этому весь следующий год.

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

Размышляю также провести небольшой практический интенсив по Foundry. Открытие уроки уже выложены на канале, поэтому на интенсиве будет больше практической части: как писать unit / fuzz тесты, как делать форк сетей и интеграции с другими протоколами, как оптимизировать сами тесты и setup функцию, чтобы и вам, и другим разработчикам было удобнее работать с ними.

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

Спасибо всем, кто был со мной весь этот год! Спасибо всем, кто подписался на канал и комментировал посты! Спасибо всем, кто делился своими находками и материалами!

Встретимся с вами уже в Новом году! А я иду в долгожданный длинный отпуск!

#offtop

Про подготовку к аудиту

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

Пару дней назад начался конкурс для протокола SecondSwap. Это единственный конкурс на моей памяти, который переносился 4 раза! Изначально он должен был запуститься 24 ноября, потом его перенесли на 29, потом на 5 декабря, потом на 9!

Мне были очень интересны причины этого. И после старта они стали понятны. Подготовка к конкурсу просто ужасная. Пошли по порядку:

1. Отсутствие документации. Кроме как описания протокола на два абзаца и быстро сделанной схемы контрактов больше ничего нет. По ссылке на сайте проекта находится простой лендинг, без дополнительных ссылок на документацию или хотя бы на whitepaper протокола.

Да, аудитору, в целом, достаточно кода для хорошей проверки. При этом с подробной документацией он может сравнить "задумку" разработчиков с фактической реализацией, найти несоответствия или подсказать лучшие паттерны. Довольно часто в отчетах я встречал High/Med баги с ссылкой на формулировки в документации протокола.

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

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

3. Много рабочих комментариев от разработчиков по проблемам из аудиторского отчета, который не будет показан. Т.е. есть функция, в которой описан потенциальный баг: в одном случае он исправлен, в другом может быть нет, так как acknowledged. Это очень сильно сбивает с процесса.

Комментарии к коду при аудите должны быть чистыми и выверенными, которые помогут аудитору понять смысл function flow. Именно поэтому нужно фиксировать отдельный репо для аудита, а рабочие заметки держать у себя.

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

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

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

Вот есть отличный гайд о подготовке протокола к аудиту:

https://auditprofile.xyz/plan.php

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

#audit

RSA алгоритмы. Часть 4

Аннулирование открытого ключа с помощью шаблона метаморфного контракта

Смарт контракт создается путем загрузки байткода в память и возврата runtime кода. Когда смарт контракт создается с помощью команды create2, адрес контракта можно предсказать заранее. Адрес вычисляется из комбинации соли, деплоера и байткода инициализации. Если контракт самоуничтожится, то можно развернуть новый контракт по тому же адресу.

Обратите внимание, что адрес зависит от кода инициализации, а не от развертываемого кода. Можно развернуть разные байткоды, если код инициализации использует другой runtime код. Таким образом, мы можем иметь смарт контракт, первые k байт которого предназначены для самоуничтожения при определенном условии, а остальные байты - это открытый ключ RSA.

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

Экономим еще 100 единиц газа с помощью access lists

В EIP2930 добавлен новый тип транзакций, который позволяет пользователю заранее указать, к каким адресам и слотам хранения будет осуществляться доступ. Это позволяет узлам предварительно извлекать эти значения из хранилища, тем самым ускоряя время выполнения. Использование транзакции с access lists при вызове внешнего контракта позволяет сэкономить 100 газа. Обратите внимание, что эта экономия не распространяется на случаи, когда смарт контракт обращается к собственной переменной хранилища. Поскольку этот дизайн RSA presale airdrop полагается на внешний контракт для хранения открытого ключа, то использование списка доступа вполне уместно.

Бенчмарки: Затраты на газ в зависимости от размера ключа

Большая часть затрат на газ возникает из-за очень больших данных вызова в результате использования больших подписей. Если размер ключа установлен на 1024 бита, то данные вызова составят 128 байт. Каждый байт стоит 16 газа, так что общая стоимость газа для таких больших данных составляет 2 048 газа. По сравнению с большинством других сценариев использования, наш использует значительный объем памяти, и Ethereum взимает за это плату.

Почему это экономит газ по сравнению с ECDSA?

Из бенчмарков ясно, что чем больше ключ (и, следовательно, подпись), тем больше затраты на газ. Наш дизайн использует тот факт, что прекомпиляция назначает низкую цену за увеличение числа до низкой мощности. Стоимость выполнения прекомпилированного контракта в этих условиях при 0x05 составляет всего несколько сотен газа по сравнению с тысячами для выполнения прекомпиляции для ECDSA.

Выбор размера ключа

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

Контрольные показатели размера ключа

RSA-896 (газ: 26 850)
RSA-960 (газ: 26 925)
RSA-1024 (газ: 27 033)
RSA-2048 (газ: 29 271)

#rsa

RSA алгоритмы. Часть 3

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

Использование только 256 бит небезопасно

Для прояснения ситуации: количество «бит» относится к размеру открытого ключа. Поэтому, когда мы говорим «RSA 2048», это означает, что число n, модуль, имеет 2048 бит. Сравнивая размеры ключей, важно помнить, что каждый дополнительный бит удваивает размер числа. Таким образом, 700 бит экспоненциально более безопасны, чем 350 бит, но не в два раза.

Самый большой ключ, который удалось взломать (разложить) на данный момент, состоял из 829 бит, и для этого потребовался современный суперкомпьютер. Команда использовала примерно 2700 процессорных ячеек в год, используя процессор Intel Xeon Gold 6130 с частотой 2,1 ГГц. Стоимость самого дешевого 16-ядерного процессора на AWS составляет 0,40 цента в час, поэтому стоимость взлома этого ключа составляет порядка 9,4 миллиона долларов. Даже при условии щедрых скидок от облачного провайдера стоимость будет исчисляться миллионами.

Модульная арифметика с более чем 256 битами в Solidity

Ethereum поддерживает только 32-байтовые типы данных, поэтому по умолчанию мы не можем выполнить:

s ^ e % n

К счастью, блокчейн ethereum добавил в EIP-198 прекомпилированный контракт специально для поддержки модульной арифметики.

Для его использования необходимо загрузить в память базу, экспоненту и модуль в кодированном формате abi. Затем вызывается контракт, находящийся по адресу 0x05. Хранение открытого ключа становится некоторой проблемой, если вы используете безопасное количество бит. Если размер ключа составляет 1024 бита, то для хранения потребуется 4 слота. Чтобы посчитать открытый ключ из хранилища, потребуется четыре операции SLOAD, что в общей сложности составит 8 400 газа.

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

В традиционных ECDSA или деревьях Меркла мы бы просто заменили адрес подписи или корень Меркла. Это невозможно, если мы используем неизменяемую переменную. Однако ключевой идеей является хранение открытого ключа в байткоде, а не в памяти. Чтение байткода внешнего контракта (EXTCODECOPY) стоит 2 600 газа, что гораздо меньше, чем 8 400 газа при чтении каждой части открытого ключа в четырех экземплярах. Чтобы аннулировать открытый ключ, мы могли бы просто создать новый контракт и обновить переменную хранения, чтобы она указывала на новый адрес. Но это добавляет еще 2100 газа. И оказывается, что можно хранить адрес внешнего контракта (в байткоде которого хранится открытый ключ) в неизменяемой переменной, но при этом сделать открытый ключ недействительным, изменив байткод внешнего смарт-контракта.

Сложно, но интересно! Дальше больше!

#rsa

RSA алгоритмы. Часть 2

Алгоритм RSA

Если мы хотим существенно превзойти ECDSA, нам нужно найти другой криптографический алгоритм, позволяющий доказать принадлежность к членству. ECDSA - это фактически новая, более "клевая" версия оригинального алгоритма цифровой подписи RSA. ECDSA опирается на то, что дискретные логарифмы над эллиптическими кривыми являются жесткими (отсюда и название - алгоритм цифровой подписи на эллиптических кривых). RSA (названный по имени его авторов - Ривеста, Шамира и Адлемана) основан на том, что большие целые числа трудно считать. По возрасту RSA был опубликован в 1970-х годах, а ECDSA стал общепринятым в начале 2000-х.

Мы не будем супер подробно разбирать RSA, но некоторые предварительные условия необходимы. Подписывающий выбирает два больших простых числа p и q и перемножает их вместе, чтобы получить n. Этот n - первая часть открытого ключа. Во-вторых, подписывающий выбирает небольшое простое число e (для нашего случая можно зафиксировать 3) и публикует пару (n, e) в качестве открытого ключа. За кулисами подписывающий вычисляет

t = (p - 1) * (q - 1)
d = t^(-1) % n

Число d является закрытым ключом. Если бы кто-то мог разложить n на p и q, то вычисление d было бы простым делом. Но известно, что целочисленная факторизация сложна. Чтобы подписать сообщение, подписывающий хэширует сообщение m, получая h, и возводит h в степень d. То есть,

s = h(m) ^ d % n

Подписант публикует (m, s) как сообщение и подпись. Верификатор хэширует m и возводит его в степень e mod n. Помните, что e и n - это открытый ключ. Если и только если

s == s ^ e % n

то подпись действительна для открытого ключа (n, e). Обратите внимание, что если n очень велико, то вероятность того, что s == s ^ e % n по случайному стечению обстоятельств исчезающе мала. Если равенство подтверждается, то мы знаем, что подпись действительна для открытого ключа. Чтобы сделать это в Ethereum, мы просто подпишем адрес как

s = buyerAddress ^ d % n

и смарт-контракт будет проверять

msg.sender == s ^ e % n

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

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

#rsa

Упражнение для начинающих аудиторов

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

Во-первых, сам по себе он очень маленький, всего около 600 строк кода.

Во-вторых, там много "перекликаний" между контрактами.

В-третьих, есть интеграция с Uniswap V2.

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

Если захотите потренироваться сами, то вот репо протокола:

https://github.com/code-423n4/2024-12-lambowin

И вам нужно будет ответить на следующие вопросы:

1. Что такое Lambo токен и Veth?
2. Как происходит создание Lambo токена?
3. Как происходит покупка Lambo токена?
4. Где хранятся Lambo токены?
5. Как на Uniswap v2 появляется ликвидность?

***

1. От чего зависит цена Lambo токена?

Также нарисуйте схемы:

1. Создание нового Lambo токена;
2. От отправки пользователем Эфира до получения токена;
3. Кто является msg.sender в каждом внутреннем вызове при покупке токена;
4. Процесс вывода токена с Uniswap v2 - что пользователю нужно отправить и что получит в конце;

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

В общем, если вы хотите начать принимать участие в конкурсах, то это станет прекрасным упражнением!

#audit

RSA алгоритмы. Часть 1

Как и говорил ранее, мы разберем новую для канала тему, которая может быть кстати при изучении такого DeFi протокола, как Tornado Cash. Итак, поехали!

Введение в ECDSA и RSA

Создание контракта, предоставляющего определенным адресам прав, имеет несколько названий: airdrops, presale, whitelist, allowlist и так далее. Но суть идеи заключается в том, что есть набор адресов, которые имеют специальное разрешение на покупку токена высокого спроса по желаемой цене (иногда бесплатно). Для этого есть три устоявшихся решения: маппинги, деревья Меркла и ECDSA подписи.

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

Таким образом, только адреса, отмеченные как true, могут совершить покупку. Это очень экономит газ для покупателя, но сам продавец может потратить очень много газа на составление этих allowlist для тысяч адресов (добавление каждого адреса в allowlist обойдется минимум в 22 100 газа). Поэтому деревья Меркла и подписи ECDSA (с использованием ecerecover) часто предпочитаются маппингам.

Стоимость газа (для покупателя) при выполнении проверки подписи ECDSA составляет 29 293 газа. Сюда входит 21 000 на инициирование транзакции, поэтому стоимость ECDSA составляет 8 293. Обратите внимание, что сюда входит чтение адреса подписи из хранилища, но эти затраты необходимы, иначе мы не сможем признать подпись недействительной.

Деревья Меркла различаются по стоимости в зависимости от размера дерева (большие деревья требуют больших доказательств), но если в древе более 1 000 адресов, то проверка адреса обойдется как минимум в 32 000 газа (или больше). Такая стоимость явно уступает ECDSA.

Итак, наша задача состоит в том, чтобы побить ECDSA, который стоит 8 293 газа. Для того, чтобы решения не отличались друг от друга, альтернативное решение должно:

1. Уметь обнулять адреса из списка разрешенных. Деревья Меркла могут менять свой корень, ECDSA - адрес подписи, а маппинги - устанавливать значения true/false;
2. Не налагать существенного бремени расходов на продавца, как это делают маппинги;
3. Стоить менее 8 200 единиц газа для покупателя (включая нагрузку на хранилище);
4. Не подвергаться риску в плане безопасности;

И далее мы поговорим о самом RSA алгоритме.

#rsa

10 часов аудита, 1 High и $606

Вчера пришли результаты одного из конкурсов, с площадки CodeHawks. Мне засчитали 1 находку из 7, оценив ее в 606 USDC. Не плохо, но могло быть и лучше.

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

1. Подавай все, что считаешь валидным. Я уже писал за этот пункт и сам попался на него. Тогда я читал правила и отчеты с Шерлока, готовясь к конкурсу на их платформе, где проблемы с реорганизацией сети, форками с chainId и временными метками в подписях чаще всего признавались не валидными. И почему-то, решил, что и на CH будет так же. В итоге я просто не отправил два отчета, которые... сюрприз, оказались валидными тут. В общем, не делайте за судей их работу, и подавайте все, что считаете нужным.

2. Читайте описание протокола в конкурсе и его документацию. Меня интересовала практика "быстрее разобраться в коде", поэтому на описание и документация я забил. Один High был найден как раз из понимания документации и как должен работать протокол.

3. Лучше валидируйте свои находки. На один отчет я потратил не так много времени, не корректно описав ход исполнения функции. На это указал судья - кстати, еще один способ обучения (на codehawks и c4 судьи пишут, почему твоя находка не валидна, что помогает учится). Из-за этого в комментариях я указал на другую проблему в коде, но так как это было уже вне конкурса, понятное дело, находку не засчитали.

В итоге, только 1 High про невозможность обновлять прокси.

Единственное, что не понял, почему засчитали эту находку: https://codehawks.cyfrin.io/c/2024-11-one-world/s/885

Я много раз видел в протоколах такую функцию с такими же проверками и реализацией. И формулировка: "Манипулирование msg.value может привести к непреднамеренным изменениям состояния, неудачным внешним вызовам или даже потере средств, если логика контракта зависит от количества Эфира, отправленного с транзакцией." - на мой взгляд слишком размыта и не определенна. Более того, хакеру пришлось бы отсылать свой собственный Эфир для атаки... В общем, тут я бы оставил только Info статус, а не Low баг.

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

На с4 будут сразу два небольших конкурса, заходите и пробуйте!

#audit

Планы на две недели и отпуск

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

Также через две недели с 15 декабря, я решил взять долгий отпуск на целый месяц! У меня получился очень насыщенный год и хочу взять время отдохнуть, пересмотреть свои идеи, понять, чего хочу, и куда двигаться дальше, и уже с новыми силами врываться в новый год!

А на этой неделе планирую разобрать, что такое RSA подписи, прочитав статью с RareSkills: Solidity RSA signatures for aidrops and presales: Beating ECDSA and Merkle Trees in Gas Efficiency.

Вообще, на эту тему меня навела другая статья про Tornado Cash.

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

Сначала переносил туда некоторые статьи из этого, основного, канала, а с прошлой недели потихоньку начали разбирать новую тему - Tornado Cash.

В целом, пока что я планирую там пару раз в неделю размещать просто переводы статей о DeFi протоколах с различных ресурсов, например, RareSkills, Alchemy, Updraft и других. Если вам интересно, то присоединяйтесь:

https://t.me/+CTsJv2XzxacwM2Ji

Это будет абсолютно не спешные переводы и разборы.

А так, все прекрасной первой неделе зимы и легкого обучения!

#offtop

Конкурсные аудиты с пулом "по условию" - Conditional Pool

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

В последнее время в сфере конкурсных площадок все чаще проявляется такое сомнительное решение как Conditional Pool, или пул наград аудиторам, который может быть изменен в зависимости от найденных багов. Например, конкурс с наградой в 1 миллион: если в протоколе будут найдены криты, то размер пула - 1 млн, если только Med , то пул 250к, если Low - 50к. От этого раздувается рекламная кампания в соцсетях и многие восторгаются очередным "Рекордным конкурсом".

Но сколько в действительности получали аудиторы за такие конкурсы?

В одном посте в Твиттере пользователь с ником guhu сделал несколько примечательных выводов. Далее идет перевод:

Это в основном предупреждение для будущих участников. Знайте, чего ожидать, и корректируйте свой EV-калькулятор. Ниже приведены несколько примеров и «рекордов».

1. Uniswap

- Раздутый как крупнейший в истории конкурс на 2,35 млн, выплатил только 12% от суммы шумихи (300 тыс.)
- 🏆Рекорд побит: крупнейшее в истории завышенное обещание ✨ 2,050,000 в USDC!!! ✨ (маркетинг любит нули и запятые)
- 2 хая (ИМХО) понижены в рейтинге: одно отклонено, другое понижено. На обоих проект отменил решение судьи (назначив «независимую» комиссию из 3 анонов-судей). Я отстаивал один из выводов, вот откуда я знаю.
- Но есть и положительный момент: это, по крайней мере, полупублично, так что вы знаете, как ваши отчеты о вознаграждениях могут быть обработаны и опосредованы.

2. Euler

- В течение нескольких месяцев его рекламировали как (вы угадали!) крупнейший в истории конкурс на 1,25 млн.
- Результаты так сильно снизились, что по правилам они должны были выплатить всего 1% (!!!) от суммы шумихи (20k). От стыда добавили 180к (так что 16%).
- 🏆Рекорд побит: самое отвратительное понижение рейтинга в промышленных масштабах, которое я когда-либо видел. Тошнит от одного только чтения эскалаций.
- Понизили (ИМХО!) как минимум один хай до лоу (!), как минимум один средний.
- Опять же, полупублично, так что, по крайней мере, вы можете выбирать цели для баунти с умом.

3. Maker

- Отношение к проекту было на самом деле хорошим, этот в основном на Шерлоке.
- Раздули до 1,35М (самый большой в истории!!), а заплатили 0 ревьюверам! Вместо этого 430к были выплачены людям, которые ... застейкали поинты. Я считаю, что участникам было выплачено 0%, но вы можете считать это 31%, если хотите.
- Вот что: на 2 и 3 местах в итоговой таблице лидеров было по 0 заявок. А 2 место (с 0 заявок!) активно боролось с эскалациями против (!) других. Вот это действительно мышление атакующего, да?
- 🏆Побит рекорд: больше всего «Я даже не могу...»

4. Другие заметные ООООффффффы

- Balancer (еще в процессе): 500к, похоже, будет 25% (125к).
- Panoptic: рекламировался как 80k, заплатили только 6% (5k) от шумихи.
- Fluid: 250k, заплатили 20% (50k).
- AAVE: 150k, заплатили 13% (20k).

Далее от меня лично.

При этом всем, протоколы имеют доступ к вашим находкам и исправят все проблемы, которые посчитают нужными. И даже если вы нашли "твердый Med", который на судействе опустили до Low или даже Info, и вы не получили с него выплаты, протокол все равно будет в плюсе.

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

В противном случае - это просто превратится в цирк.

#audit

- Становление лучшим аудитором в CH в настоящее время не имеет никаких преимуществ. Здесь нет пригласительных аудитов, нет ведущего старшего Ватсона или других возможностей для лучших аудиторов.
- Малое количество конкурсов по сравнению с C4 или Шерлоком.
- Cyfrin пытается делать все. Иногда непонятно, что это - образовательная платформа с конкурсами или платформа для конкурсов с образованием.

3. Шерлок: «Хардкорное PvP»

Примечание: Если вы читаете X, то вскоре узнаете, что у Sherlock ужасная репутация, когда речь идет о судействе и эскалации. Хотя они, безусловно, заслужили такую репутацию, важно также признать, что они - единственная платформа, которая полностью прозрачна во всем. У других платформ также есть некоторые из этих проблем, но они держат их в секрете. Поэтому при сравнении платформ не следует рассматривать их как черно-белые, а скорее как светло-серые/темно-серые.

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

Основная ценность «Шерлока» - меритократия. Хотите стать LSW? Тогда победите его и займите его место. Хотите стать ведущим судьей? Тогда победите нынешнего судью и станьте судьей. Все - это соревнование, в котором побеждает тот, кто стоит первым.

Преимущества:

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

Недостатки:

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

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

- Каждая эскалация быстро превращается в перепалку между участниками, которые экономически стимулированы делать все, чтобы победить. Если вам удастся подтвердить недействительный вывод, судья потеряет деньги. Если вы можете признать недействительным чужой вывод, вы получаете деньги. В сущности, предательство выгодно, а «твоя потеря - моя выгода», так что это становится нормой.

- Эскалация может затянуться на недели.

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

4. Hats: «Скорость - это любовь, скорость - это жизнь»

Уникальная платформа Hats Finance полностью основана на скорости. Каждый конкурс - это гонка, в которой вознаграждается только тот, кто первым представит находку. Заявка подается на цепочке с доказательством концепции, и временная метка решает, получите ли вы все или ничего.

Преимущества:

- Если вы любите адреналин, то вам обязательно понравится Hats.
- Банк не разбавляется дубликатами. Так что если вы попали в банк, то вы попали в него по-крупному.
Многим не нравится давление, поэтому конкуренция намного ниже, чем на других платформах.

Недостатки:

- Высокая дисперсия. Вы можете подать 10 правильных заявок и получить 0 долларов только потому, что опоздали на 1 секунду.
- Психический стресс. Мало того, что вы не знаете, будет ли ваша находка признана достоверной, так еще и дополнительный стресс от того, что вы не знаете, были ли вы первыми.

5. Cantina: «There Be Dragons»

Роудмап: Как стать аудитором смарт контрактов. Часть 3. Боевое крещение

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

7. Чтение отчетов прошедших конкурсных аудитов

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

С помощью таких отчетов вы научитесь сразу нескольким вещам:

1. Понимать современные уязвимости;
2. Писать отчеты;
3. Разбирать доказательства багов (PoC);

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

В это нет ничего страшного или сложного.

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

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

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

Я бы назвал следующие темы багов популярными в современных аудитах:

1. Подписи;
2. Прокси и обновляемые контракты;
3. Интеграция с Uniswap v2/v3;
4. Различия l2 сетей, в частности zk synk и base;
5. Математические операции: потеря точности при делении, округление вверх/вниз;
6. Timelock и governance;

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

8. Участие в конкурсах и разбор протоколов

А тут самый первый вопрос будет: "Какую платформу выбрать для новичка?".

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

1. Code4rena : «Нежный гигант»

Изначальная конкурсная платформа, которая зажгла искру для всей индустрии web3-аудита, @code4rena приняла на работу тысячи и тысячи новых аудиторов и остается известным всем именем. Под руководством всегда приветливого sockdrawermoney, C4 продолжает внедрять новые продукты и идеи почти ежемесячно.

Преимущества:

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

Недостатки:

- Крайне переполненная площадка, 1000+ заявок на один конкурс - очень частое явление.
- Единственная платформа, где вы можете иметь 3 высоких и 2 средних балла и все равно не заработать достаточно, чтобы купить бургер в McDonalds.
- Пока вы не получите доступ за кулисы, вы не сможете присоединиться к PJQA и убедиться, что ваши заявки не были признаны недействительными по ошибке.

2. CodeHawks: "Занятие в школе"

Нельзя говорить о CodeHawks, не обсуждая Cyfrin Audits. Основанная Патриком Коллинсом и Алексом Роаном, компания Cyfrin является одновременно аудиторской, конкурсной и образовательной платформой. Сочетание солидных курсов от Cyfrin Updraft с «Первыми полетами» не вызывает сомнений, что это лучшее место для обучения.

Преимущества:

- «Первые полеты», обучающие аудиты, которые CH предлагает на ежемесячной основе, - отличный способ начать участвовать в конкурсах.
- Более мягкая платформа с меньшей конкуренцией, поскольку у высококвалифицированных аудиторов нет стимула фокусироваться исключительно на CH.

Недостатки:

Основанная элитной аудиторской компанией SpearbitDAO, Кантина - это конкурсная платформа, на которой элитные аудиторы соревнуются за код высочайшего качества.

Преимущества:

- Вы можете проверить свои силы в борьбе с легендами индустрии.
- Если у вас есть достоверные результаты, вознаграждение часто в 10 раз превышает вознаграждение на других платформах.
- Элитные исполнители могут получить приглашение на Spearbit.

Недостатки:

- Вы будете раздавлены легендами индустрии.
- Код часто сначала проверяется самим Spearbit, поэтому найти что-то гораздо сложнее.
- Полученные результаты сразу же становятся известны команде протокола, что может привести к нежелательным последствиям в крайних случаях.
- В настоящее время в общий доступ выкладывается очень мало информации о внутренней работе (выводы/суждения/эскалации), их админ заявил, что это работа в процессе.

6. Immunefi: «Охота на китов»

Хотя существует множество конкурсных платформ, для получения вознаграждений есть только одна. Immunefi предлагает сотни миллионов в виде багов за развернутые web3-контракты. С прошлого года они также начали проводить ограниченные по времени конкурсы Boosted и совсем недавно - Attackathons, которые сочетают в себе обширное обучение и конкурс.

Преимущества:

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

Недостатки:

- Чрезвычайная вариативность. Крупные выигрыши очень публичны, а месяцев, когда вы получали $0, - не так уж и много. Я знаю людей, которые в один год заработали 100 тысяч долларов, а в другой - 2 тысячи.
- Протоколы часто могут решить не платить за действительную заявку. Посредничество Immunefi делает все возможное, но часто вы оказываетесь во власти протокола.

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

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

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

#audit

Роудмап: Как стать аудитором смарт контрактов. Часть 2. Первичное знакомство с аудитом

Далее, после того, как мы изучили базовые контракты и стандарты, лучше всего будет продолжить свой путь с задач Capture The Flag - CTF.

4. Прохождение CTF

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

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

1. Умение читать и понимать контракты;
2. Понимание базовых проблем в протоколах;

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

Тут необходимо научиться изучать код контракта буквально на детали:

1. Отслеживать движение токенов;
2. Отслеживать, кто является msg.sender при вызовах функций;
3. Отслеживать несоответствия стандартам EIP;
4. Отслеживать изменения в памяти контракта, его переменных состояния;

Как понять для себя, что вы разобрались в контракте? Попробуйте на листке бумаги или в отдельном файле просто накидать его архитектуру и функции: что за что отвечает, что сохраняет и зачем это вообще надо. Справились? Супер, значит вы поняли суть контракта.

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

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

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

1. https://capturetheether.com/
2. https://ethernaut.openzeppelin.com/
3. https://www.damnvulnerabledefi.xyz/
4. https://cryptozombies.io/
5. https://speedrunethereum.com/
6. https://ciphershastra.com/
7. https://mrstealyocrypto.xyz/
8. https://cryptohack.org/challenges/
9. https://www.defihack.xyz/
10. https://etherhack.positive.com/#/
11. https://www.ctfprotocol.com/
12. https://github.com/minaminao/ctf-blockchain/

В обязательно порядке я бы порекомендовал пройти первые три. Остальные - на ваше усмотрение и свободное время.

5. Решение задач из сниппетов кода

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

Достаточно много задач по уровням вы можете найти тут:

https://auditprofile.xyz/challenges.php

либо на Твиттер аккаунте Шерлока, которые на момент ноября-декабря этого года, практически каждую неделю выставляют новую задачу, например:

https://x.com/sherlockdefi/status/1860668335777775786

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

6. Понимание чеклистов и weird erc20

Weird ERC20 Tokens - это сборник описаний токенов одного стандарта, но с разными поведениями при вызовах. Одни могут брать комиссию за перевод, другие менять балансы пользователей, третьи не возвращать ответ после трансфера и много чего еще. Всего на данный момент описано около 20 не стандартных поведений. Все их можно и нужно прочитать тут:

https://github.com/d-xo/weird-erc20

Как лучше работать с ними, чтобы понять потенциальную проблему?

Есть такой прекрасный сайт - Solodit.xyz - который собрал многие отчеты с конкурсных платформ и от частных аудиторов. Когда вы откроете его, в левой части экрана будет располагаться фильтр и поиск. С помощью него можно искать проблемы с различными токенами.

Например, вы вбиваете в поиск "fee-on-transfer" и медленно, вникая в проблему, начинаете изучать отчет. Так можно пройтись по всему списку Weird и научиться находить проблемы, связанные с разными токенами.

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

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

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

1. https://solodit.xyz/checklist
2. https://betterprogramming.pub/the-ultimate-100-point-checklist-before-sending-your-smart-contract-for-audit-af9a5b5d95d0
3. https://github.com/0xJuancito/multichain-auditor
4. https://github.com/spearbit/portfolio/blob/master/content/bridges/BridgeSecurityChecklist.md
5. https://x.com/sigp_io/status/1703363387592462633?s=20
6. https://officercia.mirror.xyz/d798TVQyA1ALq3qr1R9vvujdF7x-erXxK2wQWwbgRKY
7. https://github.com/Decurity/audit-checklists/blob/master/lsd.md
8. https://www.beirao.xyz/blog/Security-checklist
9. https://docs.layerzero.network/v1/developers/troubleshooting/integration-checklist
10. https://github.com/aviggiano/security/blob/main/audit-checklists/ERC-4337.md
11. https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md

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

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

#audit

Роудмап: Как стать аудитором смарт контрактов. Часть 1. Минимальный объем знаний

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

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

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

Так с чего же начать свой путь?

1. Изучение и понимание Solidity.

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

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

2. Изучение и понимание популярных EIP и Open Zeppelin контрактов.

Каждый хороший разработчик и, тем более, аудитор должен хорошо знать часто используемые EIP:

1. https://eips.ethereum.org/EIPS/eip-20
2. https://eips.ethereum.org/EIPS/eip-721
3. https://eips.ethereum.org/EIPS/eip-712
4. https://eips.ethereum.org/EIPS/eip-1155
5. https://eips.ethereum.org/EIPS/eip-4626
6. https://eips.ethereum.org/EIPS/eip-165
7. https://eips.ethereum.org/EIPS/eip-1967

При чтении этих Предложений необходимо уделять пристальное внимание всем "warning", "must", "should" и нюансам использования. Так, например, возникает очень много проблем с реализацией стандарта подписей (712): правильным хешированием данных, domain separator и составлению подписи.

Вам также необходимо знать часто используемые контракты от Open Zeppelin:

1. ECDSA,
2. MerkleProof,
3. Math,
4. SafeCast,
5. Address,
6. Context,
7. Create2,
8. ReentrancyGuard,
9. AccessControl,
10. Ownable,
11. Ownable2Step

Более того, обязательно знать реализации OZ контрактов из обозначенных выше EIP. Все их можно постепенно изучать в этом репо:

https://github.com/OpenZeppelin/openzeppelin-contracts

Также будет здорово, если вы будете понимать работу обновляемых контрактов от OZ:

https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable

И две другие библиотеки:

1. Solady - https://github.com/Vectorized/solady
2. Solmate - https://github.com/transmissions11/solmate

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

Это та база, на которую опираются 90% протоколов в своей разработке.

При изучении каждого контракта желательно обращать внимание на его версию и поискать, какие проблемы были обнаружены в предыдущей реализации. Например, почему нельзя использовать ECDSA от OZ ниже 4.8.2 версии. И не просто знать рекомендуемую версию, а именно "что было не так в предыдущей".

3. Изучение и понимание DeFi

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

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

1. Uniswap V2/V3 - чаще всего проекты интегрируются с ним;
2. Balancer - многие взяли идею мультипула;
3. Aave - кредитование;
4. Lido - первый, кто сделал рестейкинг ETH;

В случае с изучением Uniswap лучше всего будет, если будете также сразу искать популярные уязвимости при интеграции с ним: slippage, slot0, currentSqrtPriceX96 и другие. Важно понимать не только, в чем тут был баг, но и как должно быть исправлено в самом контракте.

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

Уже после этого вы можете рассмотреть и другие финансовые протоколы, типа dydx, Compound, MakerDAO, Curve...

Нужно добавить, что по Uniswap и Compound есть прекрасные разборы:

1. https://www.rareskills.io/uniswap-v2-book
2. https://uniswapv3book.com/
3. https://www.rareskills.io/compound-v3-book

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

https://www.youtube.com/watch?v=lsTouzJUsUk&list=PLO5VPQH6OWdW9b6GKJR4Dt9XZxQlJuVp_&ab_channel=SmartContractProgrammer

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

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

#audit #start

Коротко о двойных стандартах в конкурсных аудитах

При том, что мне нравится принимать участие в конкурсах, читать отчеты и следить за новыми уязвимостями, я никогда не планировал на 100% посвящать свое время этому. Постараюсь раскрыть свою току зрения на эту сферу.

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

Во-первых, каждая площадка в буквальном смысле воюет за своих топовых аудиторов. И, со стороны бизнеса, это правильно. Однако может вредить остальным участникам. Так, в одном случае площадка может отдавать львиную долю пула своему топу просто за его участие в конкурсе, и он получит выплату даже если ничего не нашел, другая - вводит обязательные POC для всех High/Med отчетов, но с условием, что если у вас более 80% валидных отчетов, то POC не нужен. А у кого этот процент? У своих топов. И так далее...

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

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

В-четвертых, описание условий конкурса, валидности багов и указание известных и Acknowledged проблем с предыдущих отчетов. Несколько раз встречал конкурсы с крайне скудным описанием. Практически только название протокола и scope. Никаких тебе setup указаний по запуску тестов, никаких ссылок на документацию и уж тем более прошедшие конкурсы. Но зато есть плашка - "Проблемы с предыдущих отчетов не считаются валидными". Серьезно? Это как в Инстаграме, когда видишь товар и готов его заказать, спрашиваешь цену и тебе говорят: "Ответил в личку"... И почему сами платформы допускают не полное описание конкурсов?!

В-пятых, отчеты с бот программ и chatGPT. После долго изучения отчетов, я для себя понял, что все статические анализаторы, по своей сути, обычные копи-паста условий кода, где может быть проблема. Где-то больше этих условий, где-то меньше. Популярный нынче бот Light Chaser - лучший анализатор, который используется практически для каждого конкурса на каждой аудит платформе. Всегда там присутствуют более 100 Low, пара Med и крайне редок High багов. Сколько из них дальше исправляются? 1-2%! Если вы запустите этот анализатор до конкурса, после и через год - в нем будут присутствовать примерно теже пункты. И стоит такое удовольствие около $1000 за прогон по контрактам.

Такая услуга может быть полезна для больших компаний, типа Lido, у которых человеко-часов уйдет больше, чем на $1000. А если вы небольшой протокол, то, блин, скачайте Slither, Slitherin, 4nali3er, изучите репорты Light Chaser и получите такие же репорты!

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

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

#audit

Нужно ли доводить аудит до конца?

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

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

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

Размер пула $20 250, из этой сумма сразу некоторая часть уйдет LSW, которому еще и потом, исходя из статистики предыдущих конкурсов, отдадут львиную часть. В итоге останется менее половины пула на всех участников конкурса. Кроме того, я пока не понял, как проходит судейство.

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

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

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

Во время аудита голова должна работать, а не болеть!

Надеюсь этот пост поможет вам проще относиться к конкурсным аудитам.

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

#audit

Аудит в коопе?

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

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

Если вы из тех, кто проголосовал за первый вариант (уже имеющие результаты) и хотите попробовать участие в команде, мы могли бы подумать, как это организовать. Напишите мне в личку (@zaevlad), приложив скрин с вашим ником и находками на любой конкурсной платформе. Когда желающих соберется хотя бы 3 человека, откроем мини группу.

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

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

Это пока просто мысли и желания. Мало ли, что-то да и получится.

Всем хорошего дня!

#audit

Челлендж: 50 не валидных репортов

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

Более 5 лет назад мне очень нравилось смотреть различные видео от TED, где люди делились своими идеями и историями. Некоторым из выступающих действительно удавалось "перевернуть мировоззрение" на какую-либо тему, после чего ты вдруг решал что-то делать по другому... К одним из таких прекрасных видео можно отнести "Что я выучил за 100 дней отказов".

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

И вот сейчас я предлагаю вам свой небольшой челлендж: "Получите 50 не валидных репортов".

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

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

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

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

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

Просто попробуйте!

#challenge

Заметки по аудиту vVv Launchpad

На прошлой неделе увидел, что на Шерлоке будет небольшой конкурс с четверга по воскресенье, всего 279 строк кода, и решил "залететь" на него.

К слову сказать, я не участвовал в аудитах на этой платформе около двух лет! Меня всегда сильно смущало разделение пула (когда его львиная доля уходит назначенному топу) и некоторые проблемы с судейством. Но это только мое мнение и мой выбор игнорирования этой площадки.

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

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

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

Из-за моего некоторого предубеждения к этой платформе, я потратил всего 3 часа на аудит и отправил 5 репортов. Один пометил как Low, и он не попал в список на судейство. Вообще не понял почему, и как это исправить, ведь теги к отчету нельзя менять после завершение конкурса. При этом я также не увидел никаких пунктов о том, что Low не попадают в общую базу для судейства...

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

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

Что я могу сказать по этому протоколу?

Если вы знаете самые распространенные проблемы с подписями и EIP712, то у вас могли бы быть первые зачтенные баги на этой платформе.

Вы можете и сейчас попрактиковаться с этим аудитом, зайдя на страницу:

https://audits.sherlock.xyz/contests/647?filter=scope

и изучив эти два контракта. Вот прям открывайте solodit и EIP712, и сверяйте код.

Еще одна подсказка по работе со сложными структурами.

В контракте был такой struct:

    struct InvestParams {
        uint256 investmentRound;
        uint256 investmentRoundLimit;
        uint256 investmentRoundStartTimestamp;
        uint256 investmentRoundEndTimestamp;
        address paymentTokenAddress;
        address kycAddress;
        uint256 kycAddressAllocation;
        uint256 amountToInvest;
        uint256 exchangeRateNumerator;
        uint256 feeNumerator;
        uint256 deadline;
        bytes signature;
    }

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

- что относится к инвестиционному раунду;
- что к пользователю;
- что к подписи (так как это структура для ser signature).

В итоге у меня получилось:

1. Round: limit, start/end, token;
2. User: address, max amount limit;
3. Token: fee, exchange;
4. Signature: deadline, sign;

Скажите же, что так проще ориентироваться?

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

Ну, что же, ждем результаты и движемся дальше!

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

#audit

Выводы и заметки по аудиту One World

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

В этот раз размер протокола был немного меньше, чем в прошлый раз - 541 строка кода против 699 в Sablier Flow, однако его качество было в разы хуже предыдущего. В итоге я потратил около 9-10 часов, понял примерно 98% кода и отправил 7 репортов. Ожидаю, что примут 2-3, а остальные будут в разряде "так запланировано протоколом". Я отправил все, так как указал бы те же самые проблемы, если бы делал соло аудит. Ждем предварительных результатов.

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

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

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

Другими словами это баги, которые остались в текущих контрактах.

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

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

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

В этот раз мне помогло некоторое разделение заметок по контрактам. Я писал название контракта, и затем то, что считал важным. Когда закончил уже со всеми контрактами, то делал общие заметки - кросс-функций и кросс-контрактов.

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

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

Ну, что же, ждем результатов.

P.S. Заметки очень сильно помогают быстрее понять контракт! Прям рекомендую делать их!

А можем вы хотите небольшое видео или стрим, по прошедшим аудитом с разбором и тем, как я это сам проходил?

#audit

Небольшая история о путешествии в мире аудита

Этот пост был написан прекрасным аудитором Charles Wang день или два назад. Он делится своим опытом в старте аудита смарт контрактов, и что сработало для него больше всего. Думаю, этот пост будет полезен всем, кто собирается стать аудитором и участвовать в конкурсах.

Первый шаг: Построчный аудит

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

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

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

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

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

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

Второй шаг: Внедрение перехода между функциями и дифференциации состояний

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

1. Лучшее понимание контекста: Понимая взаимосвязи между функциями, я смог выявить уязвимости при переходе от одного состояния контракта к другому.

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

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

Третий шаг: Первоначальная оценка через разделение state

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

1. Предварительная идентификация ошибок: Во время этой первоначальной оценки я уже мог находить ошибки, просто классифицируя и понимая состояния контракта. Процесс разделения и анализа этих состояний прояснил многие уязвимости с самого начала.

2. Распознавание паттернов и чувствительность: Опыт научил меня распознавать закономерности и определять области, которые могут содержать уязвимости. Определенные шаблоны кодирования или переходы состояний становились «красными флажками», и я интуитивно понимал, где искать. Не следует путать это с подбором шаблонов, чем в наши дни занимается большинство аудиторов.

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

Четвертый шаг: Свободный аудит и лиды, основанные на интуиции

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

1. Lead-Based Auditing: Вместо того чтобы систематически прорабатывать функции, я составлял список потенциальных зацепок, следуя своей интуиции в тех областях, которые, как я подозревал, могли иметь уязвимости. Интересно, что к тому времени интуиция была уже настолько развита, что я мог найти множество зацепок/потенциальных зацепок в течение первых нескольких минут.

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

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

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

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

Это не означает, что мой подход к аудиту в наши дни основан исключительно на интуиции. Это лишь одна из многих составляющих моей методологии полного аудита.

Размышления: Как опыт формирует подходы к аудиту

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

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

#audit

Что по аудиту? Sablier - результаты

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

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

Всего сейчас в конкурсе три подтвержденных находки уровня Low.

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

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

По своему первому репорту, я понадеялся, что "прокатит". Да, видел в репорте от LightChaser есть пункт на отсутствие проверки аргументов на нулевой адрес. При этом там были явно указаны некоторые функции, где такой проверки не было. Я же обратил внимание на ситуацию, которая не была описана в отчете. Судьи посчитали, что это "проблема одной сути" (что по факту так и есть) и поставили invalid.

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

Когда я просматривал контракты, то обратил внимание, что в одной из функций сначала было деление (descale), а потом умножение (scale). Решил, что это обычная математическая проблема и не проверил, на что она повлияет. В итоге получилось, что я был отчасти прав и это часть уже была указана в одном из предыдущих репортов.

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

1. Пользователи могут избежать комиссии, делая депозит мелких сумм.
2. Оракул возвращает одинаковые значения для разных по сути Flow.

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

Я писал, что понял протокол где-то на 90%. И функция, в которой был найден 2 баг, была как раз в этих 10%. Я тогда (да и сейчас), не особо понял, зачем вообще нужна эта функция. К тому же она не использовалась ни в каких других в протоколе. Грубо говоря, тогда я решил просто "забить" на нее и фокусировал внимание на основной части протокола.

Думаю, стоит вынести пару уроков из этого конкурса:

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

2. Проверяйте лучше свои находки. Если вы нашли какую-то проблему в контракте, то потратьте больше времени на подтверждение своей находки. Не стоит полагаться, что если подобное было раньше, то 100% это засчитают и сейчас. Проверяйте! А лучше напишите тест, если время вам позволяет.

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

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

Всем приятной недели и легкого обучения!

#audit

Разница между вызовом и вызовом по интерфейсу при вызове пустого адреса. Часть 2

И еще пара слов к предыдущему посту.

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

Контракт может проверить, является ли адрес смарт-контрактом, используя EXTCODESIZE, который является опкодом для address.code.length. Если размер равен нулю, это означает, что по данному адресу контракта нет. Однако сам метод вызова не включает эту проверку. Он напрямую выполняет опкод CALL независимо от происходящего.

При использовании интерфейса, проверяется размер кода цели вызова.

Другими словами, в байткоде, сгенерированном для функции callByInterface, по указанному адресу выполняется опкод EXTCODESIZE перед выполнением опкода CALL.

Если размер, возвращаемый EXTCODESIZE, равен нулю, это указывает на отсутствие контракта по этому адресу, и функция возвращается к выполнению опкода CALL. Это объясняет, почему функция callByInterface возвращается, если выполняется вызов с несуществующим адресом контракта, а callByCall - нет.

P.S. Разница между тем, как вызов низкого уровня и вызов высокого уровня взаимодействуют с пустым контрактом, показана на скрине.

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

#highlevel #lowlevel #call

Низкоуровневый вызов и высокоуровневый вызов в Solidity

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

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

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

Почему низкоуровневый вызов (или вызов delegatecall) никогда не возвращается, а вызов через интерфейс контракта может?

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

Когда исключения происходят в подвызове (sub-call), они «всплывают» - «bubble up» - (т. е. исключения отбрасываются) автоматически, если только они не пойманы в операторе try/catch. Исключением из этого правила являются send и низкоуровневые функции call, delegatecalll и staticcall: они возвращают false в качестве первого возвращаемого значения в случае исключения вместо того, чтобы «bubble up».

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

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

pragma solidity ^0.8.0;

contract Caller {

    // first call to ops()
    function callByCall(address _address) public returns (bool success) {
        (success, ) = _address.call(abi.encodeWithSignature("ops()"));
    }

    // second call to ops()
    function callByInterface(address _address) public {
        Called called = Called(_address);
        called.ops();
    }
}
contract Called {

    // ops() always reverts
    function ops() public {
        revert();
    }
}

Несмотря на то, что оба метода используются для вызова одной и той же функции, и оба метода используют опкод CALL, компилятор solidity генерирует байткод для обработки случаев реверта по-разному. Выполнение обеих функций в рамках контракта Caller покажет, что Caller.callByInterface вернется, а Caller.callByCall - нет.

На уровне EVM опкод CALL возвращает булево число, указывающее, был ли вызов успешным или нет, и помещает это возвращение в стек. Сам опкод не вызывает возврата.

Когда вызов выполняется через интерфейс контракта, Solidity обрабатывает это возвращаемое значение за нас. Он явно проверяет, является ли возвращаемое значение ложным, и инициирует возврат, если только вызов не был сделан внутри блока try/catch.

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

contract Caller {

      //...
      function callByCall(address address) public returns (bool success) {
        (success, ) = address.call(abi.encodeWithSignature("ops()"));
        if (!success) {
            revert("Something went wront");
        }
    }
    //...
}

P.S. Разница между высокоуровневым и низкоуровневым вызовом показана на скрине.

#highlevel #lowlevel #call

Поделитесь статьями?

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

Может вы сами читали в последнее время какие-нибудь крутые статьи или разборы, и такие потом: "Вау, классная штука!"?

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

#posts

Что по аудиту? Sablier

На прошлой неделе, в пятницу, закончился мини конкурс протокола Sablier - всего 699 nsloc.

У меня получилось выделить на него всего около 5-6 часов, т.е. в среднем по часу в день.

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

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

До этого момента, я использовал теги в редакторах, по типу:

@audit, @audit-issue, @note, @audit-ok

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

Что для меня хорошо сработало в данный аудит?

1. Залить описательную инфу протокола в переводчик.

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

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

2. Редактор кода, где можно разложить контракт на сниппеты кода также очень помогает.

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

Да и отслеживать function flow так гораздо легче.

3. Рисунок if/else.

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

4. Движение токенов.

Я старался понять движение токенов в контракте: в функциях и до пользователя. Это также помогло отсеять несколько вопросов, которые возникали у меня в процессе аудита.

В целом, я понял протокол, вероятно, на 90% и отправил два репорта.

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

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

Всем легкой и приятной недели!

#audit

Что по аудиту? Введение

Ранее я писал, что планирую "заново научиться проводить аудит", чтобы сформировать для себя подход к более быстрому пониманию кодовой базы протокола. Кратко говоря, сейчас моя цель научиться делать письменные заметки, чтобы быстро запоминать function flow в контракте и понимать его суть на более детальном уровне в короткий промежуток времени. А зачем?

Из-за основной работы, я не могу уделять более 1-2 часов в день на конкурсный аудит, а на выходных я вообще стараюсь не подходить к компьютеру и полностью отдыхать от web3. Любой хороший аудитор понимает, что этого времени абсолютно недостаточно для каких-либо результатов.

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

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

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

Посвящая 6-8 часов в день на разбор кода, можно наконец разобрать в нем и найти максимальное количество багов за весь период конкурса. Но что делать, если находить хочется, а времени нет? Я, по крайней мере, хочу попытаться прокачать навык "быстрого понимания протокола"... А что получится, буду описывать тут в постах.

#audit

Запись стрима "ERC4626: проблемы и решения"

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

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

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

Презентация в Google Docs

Предложение стандарта EIP4626

Контракт от Open Zeppelin


Проблема первого депозитора

Статья - https://mixbytes.io/blog/overview-of-the-inflation-attack
Статья - https://blog.openzeppelin.com/a-novel-defense-against-erc4626-inflation-attacks


"Депозит 1 wei"

Ссылка на отчет с описанием бага - https://code4rena.com/reports/2023-10-ethena#m-04-malicious-users-can-front-run-to-cause-a-denial-of-service-dos-for-stakedusde-due-to-minshares-checks

Ссылка на контракт - https://github.com/code-423n4/2023-10-ethena/blob/main/contracts/StakedUSDe.sol#L191#L194


Проблема с decimals

Статья - https://blog.rivanorth.com/erc-4626-vulnerabilities-and-how-to-avoid-them-in-your-project


Unchecked блоки

Ссылка на отчет - https://code4rena.com/reports/2024-04-panoptic#h-02-overflow-in-collateraltracker-allows-minting-shares-for-free

Ссылка на контракт - https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/CollateralTracker.sol


Проверка на slippage

Ссылка на контракт - https://github.com/code-423n4/2024-03-pooltogether/blob/main/pt-v5-vault/src/PrizeVault.sol#L454-L472


Permit + ERC4626

Ссылка на отчет - https://code4rena.com/reports/2023-07-pooltogether#m-11-vaultmintwithpermit-can-be-dosd-

Ссылка на контракт - https://github.com/GenerationSoftware/pt-v5-vault/blob/b1deb5d494c25f885c34c83f014c8a855c5e2749/src/Vault.sol


Деление перед умножением

Ссылка на отчет - https://code4rena.com/reports/2024-04-gondi#h-02-division-before-multiplication-could-lead-to-users-losing-50-in-withdrawalqueue

Ссылка на контракт - https://github.com/code-423n4/2024-04-gondi/blob/b9863d73c08fcdd2337dc80a8b5e0917e18b036c/src/lib/pools/WithdrawalQueue.sol#L137-L144


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

Ну, и конечно, буду признателен репостам и лайкам!

Всем еще раз спасибо!

#erc4626

Live stream finished (27 minutes)

Live stream started

Стрим!

Начинаем буквально через 10 минут!

#stream