Аудит проектов на блокчейне NEAR с нуля

5 min read
To Share and +4 nLEARNs

Приветствую вас, дорогие читатели!

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

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

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

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

By the way, there are some vacant slots now so if your project needs an audit — feel free to write to us, visit our public reports page here.

l — Что такое NEAR?

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

Важно помнить, что NEAR — это масштабируемый сегментированный блокчейн, а это означает, что развернутые смарт-контракты компилируются в WebAssembly (WASM) и могут быть написаны на следующих языках:

  • Rust
  • AssemblyScript (a TypeScript-like language for WebAssembly)
  • Solidity (via Aurora EVM)
  • Javascript (via JS-VM)

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

При всем при этом, с нашей точки зрения, экосистема NEAR в основном основана на Rust!

https://github.com/rust-in-blockchain/awesome-blockchain-rust

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

Платформа основана на нескольких ключевых функциях:

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

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

https://docs.near.org/

II — Процедура проверки проекта NEAR от команды Pessimistic.io:

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

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

Автоматический анализ:

  • Составляем договоры; 
  • Прогоняем предоставленные тесты и проверяем код; 
  • Мы запускаем инструменты анализа и вручную проверяем (отклоняем или подтверждаем) все заявленные проблемы (см. ниже);

Ручной аудит:

  • Мы вручную просматриваем код и оцениваем его качество; 
  • Проверяем код на наличие известных уязвимостей; 
  • Проверяем соответствие логики кода предоставленной документации; 
  • Мы предлагаем возможную оптимизацию газа и хранения;

Проблемы:

Мы активно ищем:

  • Проблемы с контролем доступа (неверная идентификация/авторизация администратора или пользователей); 
  • Проблемы с утерянными/украденными активами (активы застревают в контракте или отправляются в никуда или на неправильный счет); 
  • DoS из-за логических проблем (взаимная блокировка, ошибка конечного автомата и т. д.); 
  • DoS из-за технических проблем (ошибка Out-of-Gas, другие ограничения); 
  • Проблемы взаимодействия с контрактами (повторный вход, небезопасные вызовы, предположения вызывающего абонента); 
  • Проблемы с арифметикой (переполнение, недополнение, проблемы с округлением); 
  • Неправильное использование Near SDK
  • Другие проблемы.

Газ:

Проверяем, качественно ли выполняются газоемкие операции:

  • Коллекции – коллекции из std::collections читаются все вместе, что увеличивает расход газа. Вы должны использовать near_sdk::collections или Near_sdk::store;
  • Коллекции привязаны к хранилищу, и вы можете случайно забыть их синхронизировать;
  • Карты: LookupMap/UnorderedMap/TreeMap — выбирать нужно по требуемому функционалу (первая — самая дешевая, последняя — самая мощная);
  • LazyOption — для редко используемых «больших данных» (можно использовать только в конструкторе);
  • Borsh/JSON для сериализации сообщений (параметров/возвращаемых значений) — влияет на расход газа;
  • Внимательно изучите атаку «миллион дешевых добавлений данных», чтобы избежать подобных проблем.

Инструменты:

 

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

  • Valgrind — можно использовать, если в коде есть небезопасные блоки с опасным выделением памяти. Тем не менее, такая практика поднимает красный флаг для аудита. В общем, запускать valgrind особого смысла нет!
  • Cargo Geiger — это инструмент, отображающий статистику использования небезопасного кода Rust в крейте Rust и всех его зависимостях. Его способность фокусироваться на возможных проблемах является полезной чертой. Существование опасного кода уже является проблемой в таких проектах, и любые такие записи должны быть перепроверены.
  • Cargo Audit – проверяет файлы на наличие ящиков, содержащих уязвимости в системе безопасности. То есть он отображает устаревшие библиотеки, которыми все еще пользуются. Тем не менее, вы должны использовать его для целей аудита.
  • Статический анализатор Clippy — это отличный линтер кода, который выявляет распространенные ошибки и улучшает ваш код на Rust.
  • Cargo Tarpaulin — для покрытия тестами — очень удобный инструмент, который показывает количество строк кода, не охваченных тестами..

III — Аудит общедоступных отчетов

Публичные отчеты аудита наших собственных проектов экосистемы NEAR структурированы в соответствии с представленной выше схемой потока аудита, поэтому мы рекомендуем вам сравнить эти отчеты, в частности их результаты, с ней:

Надеемся, что эта статья была информативной и полезной для вас! Спасибо за чтение! Какие инструменты мы должны рассмотреть? О чем вам было бы интересно прочитать в нашем блоге?

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

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

8

Оставьте комментарий


To leave a comment you should to:


Пролистать наверх