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

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

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

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

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

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

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

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

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

#audit

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

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

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

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

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

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

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

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

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

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

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

#challenge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#audit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#audit

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

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

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

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

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

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

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

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

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

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

#audit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#audit

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

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

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

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

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

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

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

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

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

#highlevel #lowlevel #call

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

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

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

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

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

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

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

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

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

pragma solidity ^0.8.0;

contract Caller {

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

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

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

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

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

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

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

contract Caller {

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

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

#highlevel #lowlevel #call

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

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

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

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

#posts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#audit