Приветствую вас, дорогие читатели!
Сег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, поэтому настоятельно рекомендуем вам посетить их базу знаний и изучить документацию проекта для лучшего понимания:
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 структурированы в соответствии с представленной выше схемой потока аудита, поэтому мы рекомендуем вам сравнить эти отчеты, в частности их результаты, с ней:
Надеемся, что эта статья была информативной и полезной для вас! Спасибо за чтение! Какие инструменты мы должны рассмотреть? О чем вам было бы интересно прочитать в нашем блоге?
Если у вас остались вопросы, пожалуйста, не стесняйтесь спрашивать! Мы будем рады ответить на каждый ваш вопрос! Лучшие ответы и вопросы могут быть включены в следующую запись в блоге!
Кстати, сейчас есть несколько вакантных мест, поэтому, если вашему проекту нужен аудит — не стесняйтесь писать нам, посетите нашу страницу публичных отчетов здесь.
