В целом, участие в конкурсных аудитах может сильно продвинуть ваши навыки работы с различными протоколами, архитектурами и их тестами, но если вы решите на 100% уйти в них, то желательно, на мой взгляд, работать с одной-двумя и топить за них, чтобы через некоторое время стать "своим". А дальше, уже уходить в соло или компанию, или на полноценные баг баунти.
#audit
#audit
1👍1
Роудмап: Как стать аудитором смарт контрактов. Часть 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. Изучение и понимание 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:
👍3❤1
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
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
3👍9🔥2
Роудмап: Как стать аудитором смарт контрактов. Часть 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
Как лучше работать с ними, чтобы понять потенциальную проблему?
Далее, после того, как мы изучили базовые контракты и стандарты, лучше всего будет продолжить свой путь с задач 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
Как лучше работать с ними, чтобы понять потенциальную проблему?
🔥6👍1
Есть такой прекрасный сайт - 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
Например, вы вбиваете в поиск "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
🔥13👍1
Роудмап: Как стать аудитором смарт контрактов. Часть 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.
Недостатки:
Ну, и завершаем наш роудмап для начинающего аудитора парой дополнительных пунктов.
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.
Недостатки:
❤4👍1
- Становление лучшим аудитором в CH в настоящее время не имеет никаких преимуществ. Здесь нет пригласительных аудитов, нет ведущего старшего Ватсона или других возможностей для лучших аудиторов.
- Малое количество конкурсов по сравнению с C4 или Шерлоком.
- Cyfrin пытается делать все. Иногда непонятно, что это - образовательная платформа с конкурсами или платформа для конкурсов с образованием.
3. Шерлок: «Хардкорное PvP»
Примечание: Если вы читаете X, то вскоре узнаете, что у Sherlock ужасная репутация, когда речь идет о судействе и эскалации. Хотя они, безусловно, заслужили такую репутацию, важно также признать, что они - единственная платформа, которая полностью прозрачна во всем. У других платформ также есть некоторые из этих проблем, но они держат их в секрете. Поэтому при сравнении платформ не следует рассматривать их как черно-белые, а скорее как светло-серые/темно-серые.
Компания Шерлок предлагает клиентам гибридную модель между частными аудитами и публичными конкурсами. В каждом конкурсе есть ведущий старший Ватсон - эксперт, который получает фиксированный процент от конкурсного пула. Затем LSW соревнуется с каждым участвующим аудитором за оставшуюся часть банка.
Основная ценность «Шерлока» - меритократия. Хотите стать LSW? Тогда победите его и займите его место. Хотите стать ведущим судьей? Тогда победите нынешнего судью и станьте судьей. Все - это соревнование, в котором побеждает тот, кто стоит первым.
Преимущества:
- Если вы любите бесконечные споры и безжалостную конкуренцию, это место для вас.
- Это делают немногие, поэтому количество участников ниже, чем на других платформах.
- Постоянный поток небольших конкурсов с очень коротким циклом обратной связи.
- Если вы сможете стать LSW, вы будете в большом плюсе.
Недостатки:
- Судьи выбираются через соревновательную систему лидерборда, подобную LSW, где они соревнуются в судействе сообщества после каждого конкурса. Лучший участник может стать ведущим судьей конкурса. Однако вознаграждение судьи чрезвычайно мало по сравнению с другими платформами. В результате у тех, кто обладает необходимым опытом для правильного судейства, нет экономического стимула участвовать в конкурсе. Следовательно, зачастую ведущий судья не обладает необходимыми знаниями.
- Отсутствие объяснений, почему результат признан недействительным, и недоверие к ведущему судье приводят к неприличному количеству эскалаций в каждом конкурсе.
- Каждая эскалация быстро превращается в перепалку между участниками, которые экономически стимулированы делать все, чтобы победить. Если вам удастся подтвердить недействительный вывод, судья потеряет деньги. Если вы можете признать недействительным чужой вывод, вы получаете деньги. В сущности, предательство выгодно, а «твоя потеря - моя выгода», так что это становится нормой.
- Эскалация может затянуться на недели.
-Интерпретация правил судейства Шерлока может меняться в разных конкурсах, а также рамки конкурса могут меняться во время или даже после его завершения.
4. Hats: «Скорость - это любовь, скорость - это жизнь»
Уникальная платформа Hats Finance полностью основана на скорости. Каждый конкурс - это гонка, в которой вознаграждается только тот, кто первым представит находку. Заявка подается на цепочке с доказательством концепции, и временная метка решает, получите ли вы все или ничего.
Преимущества:
- Если вы любите адреналин, то вам обязательно понравится Hats.
- Банк не разбавляется дубликатами. Так что если вы попали в банк, то вы попали в него по-крупному.
Многим не нравится давление, поэтому конкуренция намного ниже, чем на других платформах.
Недостатки:
- Высокая дисперсия. Вы можете подать 10 правильных заявок и получить 0 долларов только потому, что опоздали на 1 секунду.
- Психический стресс. Мало того, что вы не знаете, будет ли ваша находка признана достоверной, так еще и дополнительный стресс от того, что вы не знаете, были ли вы первыми.
5. Cantina: «There Be Dragons»
- Малое количество конкурсов по сравнению с C4 или Шерлоком.
- Cyfrin пытается делать все. Иногда непонятно, что это - образовательная платформа с конкурсами или платформа для конкурсов с образованием.
3. Шерлок: «Хардкорное PvP»
Примечание: Если вы читаете X, то вскоре узнаете, что у Sherlock ужасная репутация, когда речь идет о судействе и эскалации. Хотя они, безусловно, заслужили такую репутацию, важно также признать, что они - единственная платформа, которая полностью прозрачна во всем. У других платформ также есть некоторые из этих проблем, но они держат их в секрете. Поэтому при сравнении платформ не следует рассматривать их как черно-белые, а скорее как светло-серые/темно-серые.
Компания Шерлок предлагает клиентам гибридную модель между частными аудитами и публичными конкурсами. В каждом конкурсе есть ведущий старший Ватсон - эксперт, который получает фиксированный процент от конкурсного пула. Затем LSW соревнуется с каждым участвующим аудитором за оставшуюся часть банка.
Основная ценность «Шерлока» - меритократия. Хотите стать LSW? Тогда победите его и займите его место. Хотите стать ведущим судьей? Тогда победите нынешнего судью и станьте судьей. Все - это соревнование, в котором побеждает тот, кто стоит первым.
Преимущества:
- Если вы любите бесконечные споры и безжалостную конкуренцию, это место для вас.
- Это делают немногие, поэтому количество участников ниже, чем на других платформах.
- Постоянный поток небольших конкурсов с очень коротким циклом обратной связи.
- Если вы сможете стать LSW, вы будете в большом плюсе.
Недостатки:
- Судьи выбираются через соревновательную систему лидерборда, подобную LSW, где они соревнуются в судействе сообщества после каждого конкурса. Лучший участник может стать ведущим судьей конкурса. Однако вознаграждение судьи чрезвычайно мало по сравнению с другими платформами. В результате у тех, кто обладает необходимым опытом для правильного судейства, нет экономического стимула участвовать в конкурсе. Следовательно, зачастую ведущий судья не обладает необходимыми знаниями.
- Отсутствие объяснений, почему результат признан недействительным, и недоверие к ведущему судье приводят к неприличному количеству эскалаций в каждом конкурсе.
- Каждая эскалация быстро превращается в перепалку между участниками, которые экономически стимулированы делать все, чтобы победить. Если вам удастся подтвердить недействительный вывод, судья потеряет деньги. Если вы можете признать недействительным чужой вывод, вы получаете деньги. В сущности, предательство выгодно, а «твоя потеря - моя выгода», так что это становится нормой.
- Эскалация может затянуться на недели.
-Интерпретация правил судейства Шерлока может меняться в разных конкурсах, а также рамки конкурса могут меняться во время или даже после его завершения.
4. Hats: «Скорость - это любовь, скорость - это жизнь»
Уникальная платформа Hats Finance полностью основана на скорости. Каждый конкурс - это гонка, в которой вознаграждается только тот, кто первым представит находку. Заявка подается на цепочке с доказательством концепции, и временная метка решает, получите ли вы все или ничего.
Преимущества:
- Если вы любите адреналин, то вам обязательно понравится Hats.
- Банк не разбавляется дубликатами. Так что если вы попали в банк, то вы попали в него по-крупному.
Многим не нравится давление, поэтому конкуренция намного ниже, чем на других платформах.
Недостатки:
- Высокая дисперсия. Вы можете подать 10 правильных заявок и получить 0 долларов только потому, что опоздали на 1 секунду.
- Психический стресс. Мало того, что вы не знаете, будет ли ваша находка признана достоверной, так еще и дополнительный стресс от того, что вы не знаете, были ли вы первыми.
5. Cantina: «There Be Dragons»
❤1👍1
Основанная элитной аудиторской компанией SpearbitDAO, Кантина - это конкурсная платформа, на которой элитные аудиторы соревнуются за код высочайшего качества.
Преимущества:
- Вы можете проверить свои силы в борьбе с легендами индустрии.
- Если у вас есть достоверные результаты, вознаграждение часто в 10 раз превышает вознаграждение на других платформах.
- Элитные исполнители могут получить приглашение на Spearbit.
Недостатки:
- Вы будете раздавлены легендами индустрии.
- Код часто сначала проверяется самим Spearbit, поэтому найти что-то гораздо сложнее.
- Полученные результаты сразу же становятся известны команде протокола, что может привести к нежелательным последствиям в крайних случаях.
- В настоящее время в общий доступ выкладывается очень мало информации о внутренней работе (выводы/суждения/эскалации), их админ заявил, что это работа в процессе.
6. Immunefi: «Охота на китов»
Хотя существует множество конкурсных платформ, для получения вознаграждений есть только одна. Immunefi предлагает сотни миллионов в виде багов за развернутые web3-контракты. С прошлого года они также начали проводить ограниченные по времени конкурсы Boosted и совсем недавно - Attackathons, которые сочетают в себе обширное обучение и конкурс.
Преимущества:
- Каждый месяц на Immunefi зарабатываются миллионеры.
- На аудит кодовой базы вы можете потратить столько времени, сколько захотите. В отличие от конкурсов, здесь нет ограничений по времени.
- С помощью бустов вы можете проводить классические конкурсы по аудиту с гарантированным призовым фондом.
- Атакатоны позволяют глубоко изучить определенный протокол/язык/фреймворк, а затем проверить свои приобретенные навыки в конкурсе.
Недостатки:
- Чрезвычайная вариативность. Крупные выигрыши очень публичны, а месяцев, когда вы получали $0, - не так уж и много. Я знаю людей, которые в один год заработали 100 тысяч долларов, а в другой - 2 тысячи.
- Протоколы часто могут решить не платить за действительную заявку. Посредничество Immunefi делает все возможное, но часто вы оказываетесь во власти протокола.
Как не самый профессиональный аудитор, для себя выбрал code4rena и codehawks. Мне нравится, что там дают развернутую причину не валидности бага, что делает мое обучение намного эффективнее.
Однако вы можете попробовать каждую и решить для себя, где будет работать комфортнее.
Надеюсь, эта серия постов смогла дать вам всю необходимую информацию по старту пути в аудите и безопасности смарт контрактов.
#audit
Преимущества:
- Вы можете проверить свои силы в борьбе с легендами индустрии.
- Если у вас есть достоверные результаты, вознаграждение часто в 10 раз превышает вознаграждение на других платформах.
- Элитные исполнители могут получить приглашение на Spearbit.
Недостатки:
- Вы будете раздавлены легендами индустрии.
- Код часто сначала проверяется самим Spearbit, поэтому найти что-то гораздо сложнее.
- Полученные результаты сразу же становятся известны команде протокола, что может привести к нежелательным последствиям в крайних случаях.
- В настоящее время в общий доступ выкладывается очень мало информации о внутренней работе (выводы/суждения/эскалации), их админ заявил, что это работа в процессе.
6. Immunefi: «Охота на китов»
Хотя существует множество конкурсных платформ, для получения вознаграждений есть только одна. Immunefi предлагает сотни миллионов в виде багов за развернутые web3-контракты. С прошлого года они также начали проводить ограниченные по времени конкурсы Boosted и совсем недавно - Attackathons, которые сочетают в себе обширное обучение и конкурс.
Преимущества:
- Каждый месяц на Immunefi зарабатываются миллионеры.
- На аудит кодовой базы вы можете потратить столько времени, сколько захотите. В отличие от конкурсов, здесь нет ограничений по времени.
- С помощью бустов вы можете проводить классические конкурсы по аудиту с гарантированным призовым фондом.
- Атакатоны позволяют глубоко изучить определенный протокол/язык/фреймворк, а затем проверить свои приобретенные навыки в конкурсе.
Недостатки:
- Чрезвычайная вариативность. Крупные выигрыши очень публичны, а месяцев, когда вы получали $0, - не так уж и много. Я знаю людей, которые в один год заработали 100 тысяч долларов, а в другой - 2 тысячи.
- Протоколы часто могут решить не платить за действительную заявку. Посредничество Immunefi делает все возможное, но часто вы оказываетесь во власти протокола.
Как не самый профессиональный аудитор, для себя выбрал code4rena и codehawks. Мне нравится, что там дают развернутую причину не валидности бага, что делает мое обучение намного эффективнее.
Однако вы можете попробовать каждую и решить для себя, где будет работать комфортнее.
Надеюсь, эта серия постов смогла дать вам всю необходимую информацию по старту пути в аудите и безопасности смарт контрактов.
#audit
🔥7❤4👍1
Конкурсные аудиты с пулом "по условию" - 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
И последний пост про аудиты, так как на следующей неделе, хочу разобрать одну тему, которой еще не было на канале.
В последнее время в сфере конкурсных площадок все чаще проявляется такое сомнительное решение как 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
6👍3😱3
Планы на две недели и отпуск
Тему с аудитами продолжим чуть позже, пока жду результатов с последнего конкурса и хочу поучаствовать еще в двух на с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://news.1rj.ru/str/+CTsJv2XzxacwM2Ji
Это будет абсолютно не спешные переводы и разборы.
А так, все прекрасной первой неделе зимы и легкого обучения!
#offtop
Тему с аудитами продолжим чуть позже, пока жду результатов с последнего конкурса и хочу поучаствовать еще в двух на с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://news.1rj.ru/str/+CTsJv2XzxacwM2Ji
Это будет абсолютно не спешные переводы и разборы.
А так, все прекрасной первой неделе зимы и легкого обучения!
#offtop
2👍3❤2
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
Вчера пришли результаты одного из конкурсов, с площадки 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
2🔥8🎉6👍1
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
Как и говорил ранее, мы разберем новую для канала тему, которая может быть кстати при изучении такого 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
2👍6
Упражнение для начинающих аудиторов
Сейчас проходит небольшой конкурс на платформе 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
Сейчас проходит небольшой конкурс на платформе 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
👍9🔥3
RSA алгоритмы. Часть 2
Алгоритм RSA
Если мы хотим существенно превзойти ECDSA, нам нужно найти другой криптографический алгоритм, позволяющий доказать принадлежность к членству. ECDSA - это фактически новая, более "клевая" версия оригинального алгоритма цифровой подписи RSA. ECDSA опирается на то, что дискретные логарифмы над эллиптическими кривыми являются жесткими (отсюда и название - алгоритм цифровой подписи на эллиптических кривых). RSA (названный по имени его авторов - Ривеста, Шамира и Адлемана) основан на том, что большие целые числа трудно считать. По возрасту RSA был опубликован в 1970-х годах, а ECDSA стал общепринятым в начале 2000-х.
Мы не будем супер подробно разбирать RSA, но некоторые предварительные условия необходимы. Подписывающий выбирает два больших простых числа p и q и перемножает их вместе, чтобы получить n. Этот n - первая часть открытого ключа. Во-вторых, подписывающий выбирает небольшое простое число e (для нашего случая можно зафиксировать 3) и публикует пару (n, e) в качестве открытого ключа. За кулисами подписывающий вычисляет
Число d является закрытым ключом. Если бы кто-то мог разложить n на p и q, то вычисление d было бы простым делом. Но известно, что целочисленная факторизация сложна. Чтобы подписать сообщение, подписывающий хэширует сообщение m, получая h, и возводит h в степень d. То есть,
Подписант публикует (m, s) как сообщение и подпись. Верификатор хэширует m и возводит его в степень e mod n. Помните, что e и n - это открытый ключ. Если и только если
то подпись действительна для открытого ключа (n, e). Обратите внимание, что если n очень велико, то вероятность того, что s == s ^ e % n по случайному стечению обстоятельств исчезающе мала. Если равенство подтверждается, то мы знаем, что подпись действительна для открытого ключа. Чтобы сделать это в Ethereum, мы просто подпишем адрес как
и смарт-контракт будет проверять
Понимаю эти вычисления для нашего канала не свойственны, но в них можно разобраться, только если сами запишите все на бумаге. У меня, при чтении статьи, вообще "мозг вылетел", так как я с математикой не в ладах, поэтому переписать все на листик бумаги будет куда эффективнее.
На следующей неделе поговорим уже с меньшим количеством математики в постах.
#rsa
Алгоритм 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
👍6🤯1
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-байтовые типы данных, поэтому по умолчанию мы не можем выполнить:
К счастью, блокчейн ethereum добавил в EIP-198 прекомпилированный контракт специально для поддержки модульной арифметики.
Для его использования необходимо загрузить в память базу, экспоненту и модуль в кодированном формате abi. Затем вызывается контракт, находящийся по адресу 0x05. Хранение открытого ключа становится некоторой проблемой, если вы используете безопасное количество бит. Если размер ключа составляет 1024 бита, то для хранения потребуется 4 слота. Чтобы посчитать открытый ключ из хранилища, потребуется четыре операции SLOAD, что в общей сложности составит 8 400 газа.
Это само по себе уже менее эффективно, чем решение ECDSA, приведенное выше. Если мы используем неизменяемые переменные, эти затраты в значительной степени устраняются, но это создает слабое место, если мы не можем задним числом удалить кого-то из предварительной продажи аирдропа.
В традиционных ECDSA или деревьях Меркла мы бы просто заменили адрес подписи или корень Меркла. Это невозможно, если мы используем неизменяемую переменную. Однако ключевой идеей является хранение открытого ключа в байткоде, а не в памяти. Чтение байткода внешнего контракта (EXTCODECOPY) стоит 2 600 газа, что гораздо меньше, чем 8 400 газа при чтении каждой части открытого ключа в четырех экземплярах. Чтобы аннулировать открытый ключ, мы могли бы просто создать новый контракт и обновить переменную хранения, чтобы она указывала на новый адрес. Но это добавляет еще 2100 газа. И оказывается, что можно хранить адрес внешнего контракта (в байткоде которого хранится открытый ключ) в неизменяемой переменной, но при этом сделать открытый ключ недействительным, изменив байткод внешнего смарт-контракта.
Сложно, но интересно! Дальше больше!
#rsa
На этой неделе постараюсь уже закончить с 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
1❤2
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
Аннулирование открытого ключа с помощью шаблона метаморфного контракта
Смарт контракт создается путем загрузки байткода в память и возврата 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
2👍2🤔1
Про подготовку к аудиту
Проведение максимально эффективного аудита ложится на плечи не только самого аудитора, но и команды, которая должна сделать все, чтобы дать аудитору максимум полезной информации. Я уже не раз писал об этом, и хочу поднять эту тему еще раз в ключе одного из конкурсов, который проходит в данную минуту.
Пару дней назад начался конкурс для протокола SecondSwap. Это единственный конкурс на моей памяти, который переносился 4 раза! Изначально он должен был запуститься 24 ноября, потом его перенесли на 29, потом на 5 декабря, потом на 9!
Мне были очень интересны причины этого. И после старта они стали понятны. Подготовка к конкурсу просто ужасная. Пошли по порядку:
1. Отсутствие документации. Кроме как описания протокола на два абзаца и быстро сделанной схемы контрактов больше ничего нет. По ссылке на сайте проекта находится простой лендинг, без дополнительных ссылок на документацию или хотя бы на whitepaper протокола.
Да, аудитору, в целом, достаточно кода для хорошей проверки. При этом с подробной документацией он может сравнить "задумку" разработчиков с фактической реализацией, найти несоответствия или подсказать лучшие паттерны. Довольно часто в отчетах я встречал High/Med баги с ссылкой на формулировки в документации протокола.
2. Протокол заказывал аудит в другой компании, но к его началу аудиторам не показали отчет. Многие вышли из конкурса, так как по правилам все находки, даже acknowledged, уже не валидны для данного конкурса. Т.е. аудитор мог подать репорт, не зная, что в отчете уже описан этот баг и его бы не засчитали. Другими словами, это просто потраченное время для аудитора с нулем пользы для протокола.
И только вчера вечером администраторы платформы написали, что отчет вообще не будет показан аудиторам, но схожие баги все таки будут засчитаны. Но это полная хрень, как для аудиторов, так и для протокола.
3. Много рабочих комментариев от разработчиков по проблемам из аудиторского отчета, который не будет показан. Т.е. есть функция, в которой описан потенциальный баг: в одном случае он исправлен, в другом может быть нет, так как acknowledged. Это очень сильно сбивает с процесса.
Комментарии к коду при аудите должны быть чистыми и выверенными, которые помогут аудитору понять смысл function flow. Именно поэтому нужно фиксировать отдельный репо для аудита, а рабочие заметки держать у себя.
4. Связь с командой. В первые дни команда вообще не появлялась в чате. Все вопросы аудиторов игнорировались. И только со вчерашнего вечера пошли первые отчеты. Это тоже в корне не правильный подход.
По идее, команда должна выделять одного-двух человек, которые будут ответственны за коммуникацию и ответы на вопросы. Люди читают "жопой", и многим проще задать вопрос в чате, даже самый банальный, чем пытаться понять документацию.
Протоколу нужно хорошо подготовиться к аудиту: соло, от компании или конкурсу. Это напрямую влияет на ваши расходы сейчас и в будущем, и на безопасность протокола в целом!
Вот есть отличный гайд о подготовке протокола к аудиту:
https://auditprofile.xyz/plan.php
Если хотите нанять аудитора, то убедитесь, что соответствуете требованиям.
#audit
Проведение максимально эффективного аудита ложится на плечи не только самого аудитора, но и команды, которая должна сделать все, чтобы дать аудитору максимум полезной информации. Я уже не раз писал об этом, и хочу поднять эту тему еще раз в ключе одного из конкурсов, который проходит в данную минуту.
Пару дней назад начался конкурс для протокола SecondSwap. Это единственный конкурс на моей памяти, который переносился 4 раза! Изначально он должен был запуститься 24 ноября, потом его перенесли на 29, потом на 5 декабря, потом на 9!
Мне были очень интересны причины этого. И после старта они стали понятны. Подготовка к конкурсу просто ужасная. Пошли по порядку:
1. Отсутствие документации. Кроме как описания протокола на два абзаца и быстро сделанной схемы контрактов больше ничего нет. По ссылке на сайте проекта находится простой лендинг, без дополнительных ссылок на документацию или хотя бы на whitepaper протокола.
Да, аудитору, в целом, достаточно кода для хорошей проверки. При этом с подробной документацией он может сравнить "задумку" разработчиков с фактической реализацией, найти несоответствия или подсказать лучшие паттерны. Довольно часто в отчетах я встречал High/Med баги с ссылкой на формулировки в документации протокола.
2. Протокол заказывал аудит в другой компании, но к его началу аудиторам не показали отчет. Многие вышли из конкурса, так как по правилам все находки, даже acknowledged, уже не валидны для данного конкурса. Т.е. аудитор мог подать репорт, не зная, что в отчете уже описан этот баг и его бы не засчитали. Другими словами, это просто потраченное время для аудитора с нулем пользы для протокола.
И только вчера вечером администраторы платформы написали, что отчет вообще не будет показан аудиторам, но схожие баги все таки будут засчитаны. Но это полная хрень, как для аудиторов, так и для протокола.
3. Много рабочих комментариев от разработчиков по проблемам из аудиторского отчета, который не будет показан. Т.е. есть функция, в которой описан потенциальный баг: в одном случае он исправлен, в другом может быть нет, так как acknowledged. Это очень сильно сбивает с процесса.
Комментарии к коду при аудите должны быть чистыми и выверенными, которые помогут аудитору понять смысл function flow. Именно поэтому нужно фиксировать отдельный репо для аудита, а рабочие заметки держать у себя.
4. Связь с командой. В первые дни команда вообще не появлялась в чате. Все вопросы аудиторов игнорировались. И только со вчерашнего вечера пошли первые отчеты. Это тоже в корне не правильный подход.
По идее, команда должна выделять одного-двух человек, которые будут ответственны за коммуникацию и ответы на вопросы. Люди читают "жопой", и многим проще задать вопрос в чате, даже самый банальный, чем пытаться понять документацию.
Протоколу нужно хорошо подготовиться к аудиту: соло, от компании или конкурсу. Это напрямую влияет на ваши расходы сейчас и в будущем, и на безопасность протокола в целом!
Вот есть отличный гайд о подготовке протокола к аудиту:
https://auditprofile.xyz/plan.php
Если хотите нанять аудитора, то убедитесь, что соответствуете требованиям.
#audit
👍3
Последний пост этого года
Уже около трех лет я в теме web3, solidity, сетей, аудита и хочу сказать, что до сих пор не могу назвать себя не то, что сеньором, а даже твердым мидлом. Каждый раз, когда я читаю статьи от RareSkills или ветки обсуждений каких-то нишевых особенностей сети или языка от зарубежных коллег, я всегда такой: "Вау! Я тоже хочу знать это, на том же уровне!". Это и дает мне заряд мотивации вести канал, делиться интересными постами, делать переводы и много чего еще.
Многие спрашивали, а сколько нужно времени, чтобы научиться всему этому, и я до сих пор не знаю ответа. Научиться создавать свой токен с нуля можно за час, писать смарт контракт - за неделю, осмысленные проекты - за месяц, стать про - бесконечно... В обучение web3 нет временных рамок и ограничений, если встаете на этот путь будьте готовы учиться постоянно.
На следующий год я для себя выделил три ключевых направления для собственного обучения:
1. Аудит и безопасность. Эта тема меня действительно зажигает! Мне нравится читать отчеты, порой участвовать в конкурсах и помогать делать протоколы более безопасными. Я хочу освоить скилл создания видео, где в формате коротких роликов показывал бы баги из репортов и моменты, на которые стоит обращать внимание при разработке смарт контрактов. Это поможет как развитию канала, так и начинающим web3 разработчикам совершать меньше ошибок.
2. Разбор DeFi протоколов. При том, что я понимаю и разбираюсь в общих чертах финансовых протоколов, например, могу рассказать, чем отличаются версии Balancer v1 и v2, у меня все равно пробелы в знаниях о том, как работает все на уровне кода, и, кроме того, в чем особенности экономической модели. В общем, буду подтягивать эту тему.
3. Видео... Долбанный видео формат, который мне никак не удается совместить с демонстрацией кода в вертикальном формате. У меня давно было желание записывать видео по темам Solidity, безопасность и какие-нибудь разборы. Получилось провести даже два стрима (большое спасибо за вашу поддержку еще раз!). Но этот формат все никак не дается мне: то код маленький, то не знаю, как нарисовать схему на экране, то нужно много переключений между вкладками... Поэтому буду учиться этому весь следующий год.
Также весной, по мере желающих, будет перезапуск нашего курса "Начинающий разработчик смарт контрактов". Это уже третий поток учеников! Планирую добавить туда больше видео материала и примеров кода.
Размышляю также провести небольшой практический интенсив по Foundry. Открытие уроки уже выложены на канале, поэтому на интенсиве будет больше практической части: как писать unit / fuzz тесты, как делать форк сетей и интеграции с другими протоколами, как оптимизировать сами тесты и setup функцию, чтобы и вам, и другим разработчикам было удобнее работать с ними.
Это такие - глобальные - задачи на следующий год. А по мелочи, все также будем разбираться в тонкостях Solidity и сетей, делать разборы всяких интересных штук и обучаться дальше!
Спасибо всем, кто был со мной весь этот год! Спасибо всем, кто подписался на канал и комментировал посты! Спасибо всем, кто делился своими находками и материалами!
Встретимся с вами уже в Новом году! А я иду в долгожданный длинный отпуск!
#offtop
Уже около трех лет я в теме web3, solidity, сетей, аудита и хочу сказать, что до сих пор не могу назвать себя не то, что сеньором, а даже твердым мидлом. Каждый раз, когда я читаю статьи от RareSkills или ветки обсуждений каких-то нишевых особенностей сети или языка от зарубежных коллег, я всегда такой: "Вау! Я тоже хочу знать это, на том же уровне!". Это и дает мне заряд мотивации вести канал, делиться интересными постами, делать переводы и много чего еще.
Многие спрашивали, а сколько нужно времени, чтобы научиться всему этому, и я до сих пор не знаю ответа. Научиться создавать свой токен с нуля можно за час, писать смарт контракт - за неделю, осмысленные проекты - за месяц, стать про - бесконечно... В обучение web3 нет временных рамок и ограничений, если встаете на этот путь будьте готовы учиться постоянно.
На следующий год я для себя выделил три ключевых направления для собственного обучения:
1. Аудит и безопасность. Эта тема меня действительно зажигает! Мне нравится читать отчеты, порой участвовать в конкурсах и помогать делать протоколы более безопасными. Я хочу освоить скилл создания видео, где в формате коротких роликов показывал бы баги из репортов и моменты, на которые стоит обращать внимание при разработке смарт контрактов. Это поможет как развитию канала, так и начинающим web3 разработчикам совершать меньше ошибок.
2. Разбор DeFi протоколов. При том, что я понимаю и разбираюсь в общих чертах финансовых протоколов, например, могу рассказать, чем отличаются версии Balancer v1 и v2, у меня все равно пробелы в знаниях о том, как работает все на уровне кода, и, кроме того, в чем особенности экономической модели. В общем, буду подтягивать эту тему.
3. Видео... Долбанный видео формат, который мне никак не удается совместить с демонстрацией кода в вертикальном формате. У меня давно было желание записывать видео по темам Solidity, безопасность и какие-нибудь разборы. Получилось провести даже два стрима (большое спасибо за вашу поддержку еще раз!). Но этот формат все никак не дается мне: то код маленький, то не знаю, как нарисовать схему на экране, то нужно много переключений между вкладками... Поэтому буду учиться этому весь следующий год.
Также весной, по мере желающих, будет перезапуск нашего курса "Начинающий разработчик смарт контрактов". Это уже третий поток учеников! Планирую добавить туда больше видео материала и примеров кода.
Размышляю также провести небольшой практический интенсив по Foundry. Открытие уроки уже выложены на канале, поэтому на интенсиве будет больше практической части: как писать unit / fuzz тесты, как делать форк сетей и интеграции с другими протоколами, как оптимизировать сами тесты и setup функцию, чтобы и вам, и другим разработчикам было удобнее работать с ними.
Это такие - глобальные - задачи на следующий год. А по мелочи, все также будем разбираться в тонкостях Solidity и сетей, делать разборы всяких интересных штук и обучаться дальше!
Спасибо всем, кто был со мной весь этот год! Спасибо всем, кто подписался на канал и комментировал посты! Спасибо всем, кто делился своими находками и материалами!
Встретимся с вами уже в Новом году! А я иду в долгожданный длинный отпуск!
#offtop
1🔥17❤5👍5
С Новым Годом 🎄🎄🎄
Каждый год встречаюсь с дилеммой: а когда же все таки слать поздравления: в канун Нового года, типа как "с наступающим", или уже когда он наступил, т.е. 1 января? И тем не менее...
Дорогие друзья, поздравляю вас всех с Новым годом! Желаю чтобы каждый из вас исполнил свои заветные желания, перестал делать то, что совершенно не хочется, и развивался бы в той сфере, которая приносит удовольствие и мотивацию!
Наш путь в web3 это небольшая жизнь за гранью понимания большинства людей (пока что). Многие просто не понимают, чем мы занимаемся, другие называют криптовалюту скамом, третьи знают, но боятся нового. Мы те, кто меняет представление наших близких и друзей, и делает свой, пусть даже маленький, вклад в развитие сферы. Мы те, кто заряжает других!
Пусть каждый из вас не испугается объёма знаний, их сложности и продолжительности обучения! Пусть найдет то, что мотивирует двигаться дальше и зарабатывать большие деньги!
С Новым годом, друзья! Будьте счастливы в 2025 году!
🎄🎄🎄
Каждый год встречаюсь с дилеммой: а когда же все таки слать поздравления: в канун Нового года, типа как "с наступающим", или уже когда он наступил, т.е. 1 января? И тем не менее...
Дорогие друзья, поздравляю вас всех с Новым годом! Желаю чтобы каждый из вас исполнил свои заветные желания, перестал делать то, что совершенно не хочется, и развивался бы в той сфере, которая приносит удовольствие и мотивацию!
Наш путь в web3 это небольшая жизнь за гранью понимания большинства людей (пока что). Многие просто не понимают, чем мы занимаемся, другие называют криптовалюту скамом, третьи знают, но боятся нового. Мы те, кто меняет представление наших близких и друзей, и делает свой, пусть даже маленький, вклад в развитие сферы. Мы те, кто заряжает других!
Пусть каждый из вас не испугается объёма знаний, их сложности и продолжительности обучения! Пусть найдет то, что мотивирует двигаться дальше и зарабатывать большие деньги!
С Новым годом, друзья! Будьте счастливы в 2025 году!
🎄🎄🎄
3❤23🎉8🔥3
Выходим из отпуска и возвращаемся к работе
Фух, это был самый длинный мой отпуск за последние три года. Целый месяц практически без Solidity, аудитов, блога, сайта и всего другого связанного с web3. Голова немного проветрилась, мысли прояснились и появилась мотивация к новым действиям!
Как я и писал ранее, в этом году у меня будет сделан упор на аудиты, создание видео и погружение в DeFi протоколы. Кстати по поводу конкурсных аудитов: если бы меня попросили дать один лишь совет для начинающих в этой стезе, я бы сказал:
"Отслеживайте движения токенов в протоколе: перемещения с контракта на контракт и между пользователями, балансы токенов, какой токен, за что отвечает".
Только благодаря этому прокаченному скиллу вы сможете добиться значительных результатов к концу года и заработать кучу денег. Практически в каждом протоколе, который выходил на конкурсную площадку был High/Med баг связанный с этим советом.
В буквальном смысле, забейте на поиск остальных багов и учитесь отслеживать токены: рисуйте схемы, делайте записи (очень сильно помогает) и подписывайте код.
Помимо этого, в январе я хочу написать интенсив по Foundry: обновить некоторую информацию из открытого курса и сформировать большое количество практических заданий. Я хочу показать, что Foundry может намного больше, чем все привыкли думать, что он уже давно вышел за рамки простой программы для тестирования и стал полноценным инструментом разработчика смарт контрактов. Рассчитываю в феврале собрать первую группу учеников.
Также на DeFi канале мы закончим с разбором протокола Tornado Cash и его деревьями Меркла и начнем погружаться в тему: что такое perpetuals. Я вижу, что все больше протоколов так или иначе используют эти наработки и хочу сам разобраться в деталях.
Вместе с этим на канале будет выходить много постов про Solidity и разработку в целом. Мы поговорим про: обновляемые контракты, delegatecall, метадату и реорганизацию сетей. А на этой неделе, для легкого старта, поговорим про разные типы DAO систем.
В общем, год будет интересным! Приятного обучения!
#start
Фух, это был самый длинный мой отпуск за последние три года. Целый месяц практически без Solidity, аудитов, блога, сайта и всего другого связанного с web3. Голова немного проветрилась, мысли прояснились и появилась мотивация к новым действиям!
Как я и писал ранее, в этом году у меня будет сделан упор на аудиты, создание видео и погружение в DeFi протоколы. Кстати по поводу конкурсных аудитов: если бы меня попросили дать один лишь совет для начинающих в этой стезе, я бы сказал:
"Отслеживайте движения токенов в протоколе: перемещения с контракта на контракт и между пользователями, балансы токенов, какой токен, за что отвечает".
Только благодаря этому прокаченному скиллу вы сможете добиться значительных результатов к концу года и заработать кучу денег. Практически в каждом протоколе, который выходил на конкурсную площадку был High/Med баг связанный с этим советом.
В буквальном смысле, забейте на поиск остальных багов и учитесь отслеживать токены: рисуйте схемы, делайте записи (очень сильно помогает) и подписывайте код.
Помимо этого, в январе я хочу написать интенсив по Foundry: обновить некоторую информацию из открытого курса и сформировать большое количество практических заданий. Я хочу показать, что Foundry может намного больше, чем все привыкли думать, что он уже давно вышел за рамки простой программы для тестирования и стал полноценным инструментом разработчика смарт контрактов. Рассчитываю в феврале собрать первую группу учеников.
Также на DeFi канале мы закончим с разбором протокола Tornado Cash и его деревьями Меркла и начнем погружаться в тему: что такое perpetuals. Я вижу, что все больше протоколов так или иначе используют эти наработки и хочу сам разобраться в деталях.
Вместе с этим на канале будет выходить много постов про Solidity и разработку в целом. Мы поговорим про: обновляемые контракты, delegatecall, метадату и реорганизацию сетей. А на этой неделе, для легкого старта, поговорим про разные типы DAO систем.
В общем, год будет интересным! Приятного обучения!
#start
1🔥21👍3