Плачевное состояние аудита Web3 и что можно с этим сделать

Balancer, старый и хорошо проверенный протокол, недавно был "взломан". Аналогично хорошо проверенный Yearn Finance тоже. Несколько лет назад Euler Finance был "взломан" через функцию, введенную в ответ на более ранний аудит. USPD был проверен перед развертыванием, а затем сам непроверенный процесс развертывания был взломан, что привело к полному списанию примерно через 3 месяца после запуска. Никто из тех, кто обращает внимание, не верит, что аудиты являются гарантией безопасности. Многие сомневаются, стоят ли они вообще чего-либо.

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

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

Наша точка зрения не в том, что аудиторы делают что-то неправильно. Аудиторы делают то, о чем их просят проекты, которые их привлекают. Область аудита определяется проектом. В качестве одного экстремального примера: если бы До Квон привлек аудиторов для своей схемы стейблкоина, они бы отметили, что она потенциально нестабильна. Проблема была бы помечена как "признанная", и ничего не было бы сделано или изменено.

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

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

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

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

Jovay

Jovay - это L2, связанный с Ant Financial или Alibaba, или чем-то в этой общей области. Но на самом деле не важно, что делает Jovay. Это вещь, построенная из программного обеспечения крупной и хорошо финансируемой организацией. В этом аудите перечислены восемь проблем:

1. Законная ошибка программирования, которая впоследствии была исправлена.
2. То, что протокол не является бездоверительным. Это проблема отчасти, но это также основная часть дизайна.
3. Атака "поддельной подзарядки", которая применима к широкому спектру экосистемы и не является специфичной для проекта.
4. RPC-серверы используют HTTP вместо HTTPS. Эти интерфейсы не обрабатывают секретную информацию. Это относится к миллиардам совершенно безопасных веб-сайтов только для чтения.
5. Квантовые вычисления представляют риск для Ethereum. Хорошо. Очень по теме.
6. Смарт-контракты EVM могут быть уязвимы. Нет, серьезно. В нем говорится: "Смарт-контракты Evm восприимчивы к различным векторам атак из-за неизменного развертывания кода и сложных взаимодействий, потенциально приводящих к краже средств,.." Хорошо. Снова действительно уважается узкий фокус этого аудита.
7. Дизайн секвенсора подвержен MEV. Как и вся остальная экосистема Ethereum. Также слишком темно ночью.
8. Качество кода можно улучшить. В отличие от большинства другого кода, написанного с зарождения компьютинга.

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

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

Hyperliquid

Hyperliquid опубликовал несколько отчетов об аудите. В первом отчете об аудите было обнаружено шесть проблем, а второй отчет подтвердил, что они решены. Но область аудита исключала:

1. Другие смарт-контракты, являющиеся частью системы Hyperliquid
2. Внецепочечные компоненты, такие как валидаторы
3. Фронтенд-компоненты
4. Инфраструктура, относящаяся к проекту
5. Хранение ключей

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

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

Ondo

Этот аудит подчеркивает "РИСК ЦЕНТРАЛИЗАЦИИ ДЛЯ ДОВЕРЕННЫХ ЛИЦ И РОЛЕЙ", что команда признала. Он написан заглавными буквами в отчете. Верно.

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

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

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

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

Вы можете увидеть эту эволюцию в аудитах этого одного проекта.

Mutuum Finance

Теперь у нас есть reductio ad absurdum аудитов. Этот выявляет одну проблему:

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

Затем идут многочисленные детали мультиподписи. И, наконец, ответ аудитора:

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

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

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

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

Улучшения

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

Но есть несколько реальных улучшений, которые мы можем предложить. Ethena проложила путь, объяснив некоторые из многих режимов отказа своего продукта заранее. Команда была последовательна в посыле, что USDe не был безрисковым. И они обрисовали способы, которыми он мог столкнуться с проблемами. Продукт выжил, с несколькими неровностями, и сегодня довольно велик. Это дает нам точку действия для инвесторов: настаивать на том, чтобы проекты были честны в отношении любых "финансовых атак", которые могут существовать.

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

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

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

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

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

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

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

➢ Оставайтесь впереди. Присоединяйтесь к Blockhead в Telegram сегодня, чтобы получать все последние новости о криптовалютах.

+ Следите за Blockhead в Google News