Мой личный затык с аудитами

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

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

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

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

С одной стороны, когда и документация в порядке, и комментарии к коду написаны, и описание контрактов есть - то все просто: не понимаешь - читай заново. А когда комментов нет, но есть доки и то "битые"? Вот как делать аудит тогда?

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

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

Пока что из 12 конкурсных аудитов, что я брал на code4rena и sherlock, 5 я пропустил. 2 из них были слишком сложные для меня пока что - Optimism и какой-то финансовый, а 2 - с ужасными доками и комментами, еще 1 - пробить не смог...

Запомните сами и передайте другим разработчикам: ДЕЛАЙТЕ КОММЕНТАРИИ! Я бы даже сказал: хреновые доки - хреновый аудит.

Фух, выговорился)

А так, принимаю советы и рекомендации из вашего опыта.

#audit