MSTR Cat

Криптоправо/Уровень V · Создатели и запуск проектов/5.3 Продвижение и ответственность/Урок 5

Аудиты смарт-контрактов и то, что они обещают

Что на самом деле включает в себя аудит кода, почему наличие статуса «прошедший аудит» не является гарантией, кому можно доверять отчету, и как утверждения об аудите создают ответственность для проектов.

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

Экономный путь

Самый дешёвый, с наименьшими налогами, самый простой и самый приватный путь, который допускает закон, — от лучшего к худшему. Для каждого шага указано, на какой норме он основан и при каком условии остаётся законным.

  1. Опубликуйте проверенный исходный код в блок-эксплорере и хеш просмотренного коммита. Это бесплатно, и это позволяет проверить любое утверждение об аудите, но утверждение должно соответствовать развернутому коду, который не был обновлён.
  2. Если вы используете слово «аудитированный», дайте ссылку на полный отчёт и перечислите те замечания, которые остаются открытыми. Пропуск серьёзных нерешённых замечаний может вводить в заблуждение в соответствии с §5 Закона FTC, Правилом 10b-5 или Статьей 7 MiCA.
  3. Небольшой проект может сузить объём проверки только до развёрнутых контрактов и добавить публичную программу вознаграждения за обнаружение уязвимостей (bug bounty). Оговорки в отчёте ограничивают то, что он доказывает, поэтому утверждайте только то, на что он распространяется.
  4. Аудиторская фирма несёт обязанности по обычной небрежности (ordinary negligence) только перед своим клиентом согласно делу Bily (Cal. 1992), поэтому покупатели редко могут взыскать убытки с аудиторов; проекты несут ответственность за свои собственные утверждения.
  5. Utah DAO нуждается в проверке безопасности публичного кода для получения юридического признания. Закладывайте бюджет на проверку только в том случае, если вы выбираете такую правовую конструкцию (wrapper).

МатериалыОпубликованный отчет об оценке безопасности смарт-контракта с разделом с оговорками, например, отчет Trail of Bits от мая 2023 года о FraxGov.Проверенный исходный код и адрес развернутого контракта в блок-эксплоререБилли против Arthur Young & Co., 3 Cal. 4th 370 (1992) — о ответственности аудиторов перед третьими лицами

Любопытство

  1. Если аудированный контракт подвергается хакерской атаке, могут ли покупатели подать в суд на аудитора?
  2. Покрывает ли аудит код, который фактически выполняется в сети?
  3. Может ли проект попасть в юридические неприятности только за то, что говорится о том, что он прошел аудит?

Исследование

  1. Аудит смарт-контракта — это проверка безопасности определенной версии кода проекта, проводимая сторонней компанией за счет средств проекта. В результате составляется отчет, в котором перечисляются находки в зависимости от их серьезности, а также, часто, способы их устранения в рамках проекта. Термин заимствован из финансового аудита, но результаты работы различаются: объем, сроки и методы проведения аудита определяются частным контрактом между проверяющей стороной и проектом. Покупатели обычно видят только публичный отчет. Отчеты о наличии резервов, которые некоторые биржи также называют аудитами, представляют собой отдельную категорию (учебный материал 4.1.6).
  2. Сам отчет указывает на свои ограничения. Например, в обзоре FraxGov, опубликованном Trail of Bits в мае 2023 года, говорится, что работа выполнялась согласно техническому заданию, что оценки проводятся в установленные сроки и основаны на информации от клиента, а также что полученные результаты «не должны рассматриваться как полный список проблем безопасности». Там также отмечается, что у автоматизированных инструментов есть ограничения. Исправления отслеживаются по идентификатору конкретной версии кода — коммиту; например: «Проблема решена в коммите ed4e708». Следовательно, аудит описывает конкретный код в определенное время, а не то, что было развернуто или обновлено позже.
  3. Прошедший аудит код все равно может дать сбой. 13 марта 2023 года протокол кредитования Euler Finance потерял около 197 миллионов долларов. Причиной стало отсутствие проверки состояния (health check) в функции donateToReserves, которая была добавлена как часть исправления более ранней проблемы и сама прошла аудит. Euler заявил, что проходил аудит значительно чаще, чем обычно, и имел программу вознаграждения за баги на сумму 1 миллион долларов. К 3 апреля 2023 года после нескольких недель переговоров атакующий вернул средства на сумму около 240 миллионов долларов. Аудиты снижают риск; они не устраняют его.
  4. Для покупателя, рассматривающего возможность подачи иска против специалиста по проверке кода, законодательство о финансовых аудиторах показывает вероятные препятствия. В деле Bily v. Arthur Young & Co. (1992) Верховный суд Калифорнии постановил, что ответственность аудитора за обычную халатность распространяется только на его клиента. Другие лица могут подать иск о небрежном введении в заблуждение только в том случае, если они были конкретно предусмотренными бенефициарами отчета, известными аудитору, а также за умышленное мошенничество, если это было разумно предвидено. Покупателю токена, читающему публичный отчет, как правило, потребуется больше, чем просто доказательство небрежности со стороны проверяющего.
  5. Слова самого проекта об аудите несут больший риск. Утверждение о том, что проект «прошел аудит» или является «безопасным», при этом скрывая нерешенные критические замечания или используя другой код, может быть вводящим в заблуждение заявлением. Если токен является ценной бумагой, это может служить основанием для претензий по правилу 10b-5 SEC или разделу 12(a)(2) (урок 5.3.2). В противном случае Закон FTC запрещает «несправедливые или вводящие в заблуждение действия или практики» (урок 5.1.7), а статья 7 закона MiCA в ЕС требует, чтобы маркетинг был «честным, ясным и не вводящим в заблуждение». Закон штата Юта о DAO, действующий с 1 января 2024 года, даже требует проведения проверки безопасности кода DAO для юридического признания.
  6. Читайте отчет об аудите как контракт, а не как значок. Уточните, кто оплатил, что входило в объем работ, какие замечания были исправлены, какие «приняты к сведению» и оставлены без решения, а также могут ли контракты быть обновлены или приостановлены с помощью ключа администратора (урок 5.1.5). Практическая проверка: возьмите идентификатор коммита из отчета, откройте развернутый контракт в блок-эксплорере и убедитесь, что проверенный исходный код совпадает с рассмотренной версией и что более позднее обновление не заменило его. Если они не совпадают, отчет говорит мало о коде, который используется.

Ключевые факты

  • Аудит смарт-контракта включает проверку конкретной версии кода в рамках частного контракта между аудитором и проектом.
  • В отчете FraxGov за май 2023 года, опубликованном Trail of Bits, говорится, что его выводы не должны рассматриваться как полный список проблем безопасности.
  • 13 марта 2023 года компания Euler Finance понесла убытки в размере примерно 197 миллионов долларов из-за ошибки в проверенной функции; средства были возвращены к 3 апреля 2023 года.
  • В деле Bily v. Arthur Young & Co. (1992) Верховный суд Калифорнии ограничил ответственность аудиторов за обычную халатность их клиентами.
  • Согласно решению по делу Bily, третьи лица могут подать иск к аудитору за небрежное введение в заблуждение только как конкретно предусмотренные бенефициары, известные аудитору, или за умышленное мошенничество.
  • Закон штата Юта об децентрализованных автономных организациях, вступивший в силу 1 января 2024 года, требует, чтобы код DAO, доступный для публичного просмотра, прошел проверку на безопасность.

Упражнение девять, шесть, три, один

9СобратьПеречислите до 9 утверждений о безопасности, которые вы видели на веб-сайтах токенов или протоколов, таких как «прошло аудит», «безопасно», названия аудиторских фирм или программы вознаграждения за обнаружение ошибок (некоторые списки могут быть короче).
6СгруппироватьРазделите их на 6 групп: утверждения со ссылкой на отчет, утверждения без отчета, отчеты с нерешенными критическими замечаниями, отчеты по более старой версии кода, заявления о программах вознаграждения за баги и размытые формулировки в отношении безопасности.
3Выделить главноеСократите 6 групп до 3: утверждения, которые можно проверить на основе развернутого кода, утверждения, которые можно проверить только частично, и утверждения, которые невозможно проверить вообще.
1КристаллизоватьНапишите одно предложение, объясняющее, что отчет об аудите может и не может сказать вам о коде, который сейчас работает в блокчейне.

Проверка фактов

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

Открыть в интерактивной академии →

EN PT ES ZH JA KO DE FR MS