Гайд по изучению Uniswap. Часть 2

В Uniswap v3 было сделано большое обновление протокола, поэтому для понимания принципов его работы может уйти некоторое время.

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

Там мы увидим, что проект, в своей сути, разделен на два репозитория:

Uniswap v3 Core
и
Uniswap v3 Periphery

Core, как мы может догадаться, исполняет основную логику протокола - создание пулов (пар). Periphery используется как посредник между фронтендом, их сайтом, где проходят все манипуляции, и core контрактами. Более того, мы можем подключать функции и делать свапы в своих контрактах, используя именно периферийные контракты.

Для изучения работы протокола можно обращаться к его официальной документации или стороннему проекту, где описана вся его логика с примерами - Uniswap V3 Development Book.

Есть три видео, в которых авторы проходятся построчно в таких контрактах, как Position, Factory и делают общий обзор.

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

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

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

Вообще, tick - это некий диапазон цен, в котором находится токен для покупки или продажи. И пул, например, WETH/DAI, может иметь множество таких ticks.

Вот здесь можно почитать подробнее про оба этих принципа.

Статья 1, статья 2.

Ну, еще мне понравилась эта картинка для демонстрации.

Также, в процессе изучения ticks вы встретитесь с такими "монстрами", как tickSpacing и tick bitmap. В первом случае, это некий параметр для более эффективной итерации по тикам, во втором - специальная техника для индексации данных в компактном виде. Почитать подробнее можно в этих постах:

Про tickSpacing, иллюстрация tickSpacing, про tick bitmap.

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

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

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

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

Также буду раз, если поделитесь своими ссылками, которые проливают свет на работу Uniswap v3.

#uniswap

Немного о комментариях к коду

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

В Solidity вы можете использовать специальные теги для пометки своего кода, вот их обозначения:

@noscript - заголовок
@author - автор кода
@notice -заметка о коде
@dev - пометка от разработчика
@param - описание параметров функции
@return - описание возвращаемой переменной

Как их использовать?

Например у нас есть простая функция:

functions example(uint256 amount, address receiver) external returs (uint128) {}

Ее описание может быть таким:

/*
*
* @noscript - кто написал эту функцию (разработчик);
* @noscript - что она должна делать?
* @notice - более детальное описание функции (можно на нескольких строках);
* @dev - пометка для других разработчиков;
* @param - amount отвечает за это...
* @param - receiver отвечает за это...
* @return - uint128 должна вернуть это...
*
*/

Такое описание должно быть практически для каждой функции в контракте. Для импортов и наследований достаточно оставлять @notice.

Для проведения аудита крайне рекомендую скачать приложение для VS Code - Inline Bookmarks от tintinweb, которое позволяет делать теговые заметки:

/*
*
* @audit - общие заметки по аудиту;
* @audit-info - дополнительная информация;
* @audit-issue - найденная уязвимость или проблема;
* @audit-ok - проверено и все ок;
*
*/

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

Ставьте комментарии и теги.

#natspec #comments

Читаем отчеты вместе. 14

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

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

Читаем отчет вместе!

#report #audit

Большой задачник данного канала

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

Сохраните этот пост к себе в Избранное и проходите их в своем темпе.


Задачи канала


Задача 1 — Задача 2 — Задача 3

Задача 4 — Задача 5

Задача 6 — Задача 7 — Задача 8

Задача 9 — Задача 10

Задача 11 — Задача 12 — Задача 13 — Задача 14 — Задача 15

Задача 16 — Задача 17 — Задача 18 — Задача 19 — Задача 20

Задача 21 — Задача 22 — Задача 23 — Задача 24 — Задача 25

Задача 26 — Задача 27

Задача28 — Задача 29 — Задача 30 -- Задача 31 — Задача 32

P.S. Для некоторых задач решение находится сразу за скрином следующим постом.


Популярные и не только CTF


Capture the Ether — The Ethernaut — CryptoZombies — Damn Vulnerable DeFi

DeFiHack — CryptoHack — EtherHack — Cipher Shastra

Speedrun Ethereum — CTF Blockchain Challenges — Mr Steal Yo Crypto

CTF Protocol — QuillCTF


CTF для практики Foundry


Damn Vulnerable DeFi — Fifty years Capture the Ether — Ethernaut CTF

DeFiHackLabs -- DeFiVulnLabs

Подборка уязвимостей


Hight risk — Medium Risk — All the rest


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

Приятного обучения!

#ctf #task

Ретроспектива материалов на канале

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

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

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


Безопасность


Уязвимости с прокси контрактами

Кратко о Beacon Proxy

Проблемы контракта USDT

Защита от атак Signature Replay

Новые уязвимости? (5 постов)

Double Entry Point

Signature Malleability (2 поста)

Read-only-reentrancy

Манипуляции  с block.timestamp

Опасность с approve токена


Foundry


Изучаем Foundry

Чуть больше о Foundry

Тесты с Foundry (6 постов)

Прочитать mapping в Foundry

Про внешние контракты в Foundry

Минт токенов в Foundry

Новые уроки по Foundry


Скамы


Возможные скамы с NFT (5 постов)

Возможные скамы с токенами ERC20

Новый скам в NFT


Остальное


Как создать адрес в сети Эфир на js

Как создать подписанное сообщение?

Проблемный create2

Не принятый create3

Разбор байткода, opcodes, деплой

Пример работы Frontrun ботов

Интересный нюанс с call вызовом

Хэширование в EIP712

Как стать web3 разработчиком? (4 поста)

Чуть больше о Yul (assembly)

Как читать calldata?

Правило 1/64

Solidity полон сюрпризов

Особенность try/catch

Собрание подсказок по газу

Gatekeeper Three от Ethernaut

ABI Smuggling от Damn Vulnerable DeFi

Немного о Zero Knowledge

Немного о комментариях к коду

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

Приятного изучения!

#all

Привет всем новым участникам

За последние два дня на канал пришло какое-то невероятное количество новеньких, примерно +100 человек! Большое спасибо @arsln_galimov и @MaxWayld за упоминание и репост на своих каналах!

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

При этом хочу обозначить некоторые моменты про данный канал:

1) Тут не учат играть на биржах и не постят новости о крипте;
2) Тут не научат делать ботов и фронтранить мемпул;
3) Тут не учат фронтенду и ethers.js;

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

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

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

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

Добро пожаловать и приятного обучения!

#intro

Задача 33

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

Ну, а пока, достаточно сложная задача с двумя уязвимостями. Сможете найти их?

Решение

Во-первых, из-за работы функции с memory, само состояние маппинга не будет обновлено, более того при работе с callback вызовом, в данном случае, возможна DoS атака. 

#task

Задача 34

Эта задача была помечена как Med Risk на code4rena.

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

Решение

Все дело в transfer() и ее лимите на использование газа. Если в контракте принимающего будет fallback функция с дополнительными действиями при приеме эфира, то withdrawPayments() будет откатываться. В общем, лучше использовать call вызов.

#task

Задача 35

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

Решение

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

#task

Задача 36

Задача от Immunefi. Как всегда они идут в ногу со временем. Уже несколько раз натыкался на эту проблему в других контрактах. Вроде, даже была подобная на канале ранее. Узнали?

Решение

Проблема кроется в переводе uint256 amount в uint160, из-за чего транзакция может откатиться. В этом случае лучше использовать сторонние библиотеки, типа safeCast.

#task

Задача 37

И последняя на сегодня, снова же от Immunefi. Как подсказка: внимание на комментарий в коде!

Решение

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

#task

Чтение слотов памяти в контрактах

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

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

Проект Query Storage Slot.

Смотрим и применяем!

#storage #slot

Немного о EIP-1967

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

Итак, EIP-1967 стандартизирует как Прокси контракты хранят информацию о контракте Исполнения и другие необходимые данные, такие как адреса beacon контрактов и админский функционал.

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

bytes32(uint256(keccak256("eip1967.proxy.admin")))

то в EIP1967 она такая:

bytes32(uint256(keccak256("eip1967.proxy.admin")) -1 )

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

Preimage атака заключатся в том, чтобы найти изначальное "сообщение", которое было зашифровано одним из криптографических  способов (например, keccak или sha).

Больше о EIP-1967 можно почитать в обсуждениях на GitHub.

Я буду добавлять информацию об этом стандарте по мере работы с ним. Все будет также доступно по тегу #eip1967.

#eip1967

Шаблон для аудиторского отчета

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

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

Сохраните себе для работы в будущем.

P.S. Можно сделать перевод для своей страны и использовать для местных аудитов.

#audit #template

The File Pattern

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

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

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

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

#hint #event #file

Сводный пост про биржи

На прошлой неделе я хотел разобраться, как работают современные биржи, и сделал пару постов про Uniswap (V1, V2, V3), что дало мне достаточно много базовой информации.

Дальше, все выходные, понедельник и вторник, я смотрел статьи и видео о работе других бирж: Compound, Aave, Curve, Tornado Cash, dYdX, Balancer и пары других. И знаете что? Не смотря на некоторые различия и тонкости реализации кода, идеи и смысл практических всех один и тот же. Хотя, чего я ожидал...

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

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

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

Итак, что же стоит освоить в первую очередь:

1) Формирование цены в пулах;
2) Добавление ликвидности, расчет ее пропорций при добавлении;
3) Вывод ликвидности: условия и ограничения;
4) Что такое collateral;
5) Что такое over collateralized и under collateralized;
6) Что такое flashloan;
7) Что такое loan;
8) Что такое flash swap;
9) Как работают callbacks в swap / mint / borrow;
10) Как работает возврат займов;
11) Что такое ликвидация займа;
12) Что такое аукцион ликвидации займа;
13) Как работают collateral токены;
14) Как работают DAO токены;
15) Процент DAO токенов для проведения голосования;
16) Как работают reward токены?
17) Как работает средняя цена и оракулы?
18) Как работают функции collect fees;

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

Больше всего мне помог поиск в Youtube по запросу: "Как работает биржа..." (How compound works), а также следующие плейлисты:

Плейлист 1, плейлист 2.

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

Далее приведу ссылки на GitHub репо некоторых бирж:

Compound v2, compound v3, curve (vyper), aave core, Tornado cash, Balancer

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

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

#compound #curve #aave #balancer #tornado

Storage Structs

Еще одна потрясающая статья от автора The File Pattern, в которой он разбирает вопрос использования структур для хранения данных при использовании прокси контрактов.

Статья мне приглянулась еще тем, что я сам участвовал в конкурсных аудитах Astaria и Drips. Тогда я хоть и понял, что данные берутся из определённого слота, но не понимал зачем это сделано.

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

Этот паттерн предлагает создавать структуру данных (struct) и помещать ее в слот "далеко" в памяти при помощи формулы EIP-1967, о которой писалось выше.

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

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

#storage #eip1967 #struct

Проверка покрытия тестами

Только для пользователей Linux, как я понял, есть новый инструмент для проверки покрытия тестами какого-либо контракта с использованием команды forge coverage.

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

В этой статье можно почитать про настройку и проведение тестов.

#linux #coverage #forge #foundry

Подборка проектов с новостями

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

Secureum

Blockchain Threat Intelligence

Week in Ethereum News

NotOnlyOwner

Vulnerability Research by Samczsun

Noxx

Faith's Blog

Cygaar’s Substack

Rekt

DeFiHackLabs’s Substack

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

#email #security #news

Необычный тест для участников

Недавно в Дискорде нашел интересные тесты, которые проводятся один-два раза в год хорошо известной всем компанией. Посмотрев последний из них, я решил пройти их все.

Предлагаю и вам пройти их вместе со мной. Если узнали, откуда они, то не рассказывайте никому. В этот раз попробуем сами.

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

Ответы я напишу в конце дня также в комментариях.

Для просмотра контракта вам потребуется скачать файл выше.

1. В данном контракте:
а) Не стандартное значение decimals;
б) Не стандартные decreaseAllowance и increaseAllowance;
в) Не стандартный transfer;
г) Ничего из перечисленного;

2. В данном контракте:
а) decimals() могут быть pure вместо view;
б) _burn() может быть external вместо internal;
в) _mint() должен быть internal вместо external;
г) Ничего из перечисленного;

3. В функции transferFrom():
а) Есть вероятность integer underflow;
б) Не правильная проверка allowance;
в) Есть вероятность неограниченных approvals;
г) Ничего из перечисленного;

4. В данном контракте:
а) В increaseAllowance есть вероятность integer overflow;
б) В decreaseAllowance есть вероятность integer overflow;
в) В decreaseAllowance не возможно нулевой allowance;
г) decreaseAllowance может быть оптимизирован с unchecked{};

5. В функции _transfer():
а) Отсутствует проверка на нулевой адрес;
б) Есть вероятность integer overflow;
в) Есть вероятность integer overflow;
г) Ничего из перечисленного;

6. В функции _mint():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;

7. В функции _burn():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное порождение события;
в) Не правильное обновление баланса аккаунта;
г) Ничего из перечисленного;

8. В функции _approve():
а) Отсутствует проверка на нулевой адрес;
б) Не правильное сообщение об ошибке;
в) Не правильное обновление allowance аккаунта;
г) Ничего из перечисленного;

Первый тест довольно простой и больше на внимательность. Дальше будет интереснее.

#test