Подготовка к аудиту смарт-контракта

оригинал : https://media.consensys.net/preparing-for-a-smart-contract-code-audit-83691200cb9c

Если вы планируете запустить проект на blockchain Ethereum вы, вероятно, знаете о важности стороннего аудита вашего кода. Качественный внешний аудит может гарантировать, что ваши контракты функционируют так, как вы этого ожидаете и устранить уязвимости в коде.

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

Важность подготовки

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

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

1. Придерживайтесь лучших практик.

Мы рекомендуем изучить документ Smart Contract Best Practices на ранней стадии проекта и снова вернуться к нему перед проведением аудита.

2. Предоставьте спецификацию, используя простой английский язык.

Разработку смарт-контрактов часто сравнивают с написанием критически важного кода для NASA, но в действительности проекты редко имеют спецификацию описывающую, что должен делать код контракта.

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

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

Диаграммы чрезвычайно полезны и свидетельствуют о продуманном процессе проектирования. Посмотрите на проекты WeiFund и Golem . Они имеют отличные диаграммы спецификаций, которые можно использовать в качестве примеров.

3. Продумайте все от начала до конца

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

Таким образом, документированность процесса развертывания смарт-контракта имеет важное значение для избежания опасности. Такое руководство должно включать: какую версию компилятора использовать для каких контрактов, в каком порядке производить развертывание контрактов, и какие параметры конструктора использовать для инициализации каждого.

4. Напишите хороший README

В проекте должен быть хороший файл README.md, в котором четко описывается как установить систему локально, и как запустить тестирование. Он также должен четко ссылаться на другие источники, полезные для понимания проекта.

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

5. Почистите репозиторий проекта

Отсутствие беспорядка в коде сделает работу аудитора намного проще. Вы должны удалить любые неиспользуемые или ненужные контракты, файлы или код.

Вы также должны указать:

- какие контракты используются только для целей тестирования и не являются частью окончательной системы;

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

Хороший макет каталога для ваших контрактов может выглядеть примерно так:

В приведенном выше дереве каталогов

./contracts/*.sol:- это будет основной задачей аудита.

./contracts/base/*.sol: здесь будут хорошо проверенные контракты, которые наследуются контрактами верхнего уровня. Они могут, по-прежнему, требовать тщательного изучения, но уже в меньшей степени.

./contracts/test/*.sol — это контракты, которые существуют только для целей тестирования и не предназначены для развертывания в контрактной системе.

6. Управляйте отступами

Используйте линтеры solium или solcheck и следуйте официальному руководству по стилю Solidity . Также, форматируйте и ваши тесты.

7. Комментируйте сложные разделы кода

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

8. Определите степень покрытие тестами

Определение глубины покрытия тестами сможет помочь при идентификации разделов кода, которые не тестируются, или наоборот требуют дополнительного тестирования. Solidity-coverage — отличный инструмент для этого.

Конечно, 100% покрытие тестами не является панацеей, поэтому мы также оцениваем качество и тщательность в написании тестового кода. Написание тестов на Python или использование async/await синтаксиса NodeJS сделает их более читабельными и простыми в использовании.

9. Заморозьте кодовую базу

Цель аудита кода — не чистить ваш код или проверять простые ошибки. Ваша система контракта должна считаться готовой до начала аудита.

Вывод

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