Тестирование и формальная проверка безопасности смарт-контрактов Web3

Время Читать: 9 минут

Представьте, что вы прыгаете с парашютом. Прежде чем спрыгнуть с самолета, ты сто раз проверишь свой парашют, да? Проверка и тестирование являются неотъемлемой частью безопасности; подумайте о любой вещи, связанной с безопасностью. Вероятно, после этого будет механизм тестирования, будь то установка видеонаблюдения или проверка чернил в ручке перед письменным экзаменом в школе, мы все соблюдаем меры безопасности. Чем выше связанный с этим риск, тем больше мы тестируем вещи. И когда мы говорим о смарт-контрактах, риск ОГРОМНЫЙ. Вы не можете быть небрежными, когда речь идет о безопасности смарт-контрактов.

1. Безопасность нужна всегда.

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

Мир Web3 ничем не отличается. Не существует безопасного способа спасти себя, но наличие опытных аудиторов из QuillAudits может значительно увеличить шансы на то, что ваш протокол будет защищен, и обеспечит вашу безопасность на современном уровне. В web3 есть два важных механизма, которые помогут вам понять, насколько вы защищены, выполнив некоторые тесты вашего протокола:

1. Тестирование смарт-контрактов
2. Формальная проверка смарт-контрактов

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

2. Тестирование смарт-контрактов

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

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

2.1 Автоматизированный

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

2.1.1. Функциональное тестирование

Предположим, вы пишете программу, которая берет два числа, a и b, а затем возвращает результат сложения обоих чисел. Таким образом, чтобы проверить эту программу, вы даете 2 и 8 и подаете ожидаемый результат 10. Теперь, когда программа запускается, она также должна возвращать 10. Если это так, то она работает нормально, и наш код правильный, но если он нет, то в нашем коде есть какая-то ошибка. 

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

1. Модульное тестирование:- Это касается проверки отдельных компонентов смарт-контракта на правильность. Он является напористым или требует утверждений о переменных.

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

3. Система Текстынг: - Это самый высокий уровень в иерархии. При этом мы тестируем весь контракт как одну полностью интегрированную систему, чтобы увидеть, соответствует ли она нашим потребностям. Это делается с точки зрения пользователя, и лучший способ сделать это — развернуть его в тестовых сетях.

2.1.2. Статический анализ

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

2.1.3. Динамический анализ

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

2.2 Руководство

Как следует из названия, этот метод тестирования смарт-контрактов предполагает регулярное взаимодействие с разработчиком-человеком. Аудит кода, когда разработчики просматривают строки кода, относится к ручному режиму тестирования смарт-контрактов.

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

2.2.1 Аудит кода: 

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

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

2.2.2 Награда за обнаружение ошибок: -

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

3. Формальная проверка смарт-контрактов

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

3.1 Что такое формальная спецификация?

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

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

Это может помочь нам определить, соответствует ли смарт-контракт спецификациям или имеет неожиданное поведение. Формальная проверка состоит из трех компонентов: спецификации, модели и механизма проверки.

3.1.1 Спецификация

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

// Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
// Implementation details are not relevant to the specification
// …
}

Модель 3.1.2

Модель формально представляет смарт-контракт, который можно использовать для объяснения его поведения. Одной из популярных моделей смарт-контрактов является язык программирования Solidity. Вот пример модели для описанной выше функции добавления:

// Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public view returns (uint) {
return a + b;
}

3.1.3 Механизм проверки

Механизм проверки — это инструмент, который может анализировать модель и проверять ее правильность относительно заданной спецификации. Для смарт-контрактов доступно несколько механизмов проверки, в том числе:

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

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

Сертора прувер: коммерческий инструмент, который может проверять правильность смарт-контрактов с помощью автоматизированных математических рассуждений. Вот пример того, как можно использовать формальную проверку для проверки правильности смарт-контракта с помощью Certora Prover:

pragma solidity 0.7.6; // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint)
function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Model: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function add(uint a, uint b) public pure returns (uint) {
return a + b;
} // Specification: Adds two numbers
// Inputs: a, b (uint)
// Outputs: the sum of a and b (uint) function test_add(uint a, uint b) public pure returns (bool) {
uint expected = a + b;
uint actual = add(a, b);
return expected == actual;
} // Verification: Verify the correctness of the add function contract TestAdd {
function test_add(uint a, uint b) public view returns (bool) {
return CertoraProver.verify(test_add, a, b);
}
}

В приведенном выше примере мы определяем смарт-контракт Solidity, который включает в себя модель функции добавления, спецификацию функции и механизм проверки (Certora Prover), который может проверить правильность функции. Мы также определяем тестовую функцию (test_add), которую можно использовать для проверки правильности функции.

3.2 Тестирование VS Формальная проверка

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

3.3 Методы формальной верификации

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

3.3.1 Проверка модели

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

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

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

3.3.2 Доказательство теоремы

Доказательство теорем связано с математическими рассуждениями о правильности программ. Он имеет дело с созданием логического впечатления о системе и спецификации контракта и проверкой «логической эквивалентности» между утверждениями. Логическая эквивалентность — это математическое отношение, согласно которому утверждение А истинно тогда и только тогда, когда истинно утверждение Б.

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

4. Заключение

Тестирование и формальная проверка являются неотъемлемыми частями разработки смарт-контрактов. Эти методы используются для обеспечения безопасности смарт-контрактов и помогают подготовить контракты к развертыванию. Но, как известно, безопасности никогда не бывает достаточно. Многие смарт-контракты взламывались только потому, что не было надлежащего тестирования. Сейчас больше, чем когда-либо, сообществу web3 нужны более безопасные протоколы. 

Мы в QuillAudits стремимся защитить ваши протоколы. С нашей умелой и опытной командой мы гарантируем, что ни одна уязвимость не останется незамеченной. Посетите наш веб-сайт и защитите свой проект Web3!

28 Просмотры

• SEO-контент и PR-распределение. Получите усиление сегодня.
• Платоблокчейн. Интеллект метавселенной Web3. Расширение знаний. Доступ здесь.
• Источник: https://blog.quillhash.com/2023/02/16/testing-and-formal-verification/