МЕТОДЫ ВЕРИФИКАЦИИ СМАРТ-КОНТРАКТОВ Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.021

Перепечин А.А. студент магистратуры

2 курс

Поволжский государственный университет телекоммуникаций и информатики

Россия, г. Самара

МЕТОДЫ ВЕРИФИКАЦИИ СМАРТ-КОНТРАКТОВ

Аннотация: В статье рассматриваются различные методы верификации, которые применяются к смарт-контрактам. Описаны их недостатки и в качестве альтернативы предложен метод автоматической верификации путем проверки достижимости или не достижимости состояний системы.

Ключевые слова: смарт-контракт, блокчейн, верификация, статистические анализаторы, SMT-решатель.

Perepechin A.A. master's degree student second year Povolzhskiy State University of Telecommunications and Informatics

Samara, Russia

SMART CONTRACT VERIFICATION METHODS

Аnnotation: The article discusses various verification methods that apply to smart contracts. Their shortcomings are described and, as an alternative, a method of automatic verification is proposed by checking the reachability or not reachability of system states.

Key words: smart contract, blockchain, verification, statistical analyzers, SMT-solver.

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

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

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

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

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

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

• Переменные контракта, которые участвуют в алгоритме, включая внутренние переменные метода.

• Логические выражения изменения каждой из этих переменных. Берем во внимание от каких переменных зависит, при каких условиях изменяется и как.

• Условие перехода. Условием перехода является выполнение логических выражений всех переменных в правильной последовательности.

• Начальное состояние системы - набор значений для всех переменных контракта после его инициализации.

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

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

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

Использованные источники:

1. Э. Кларк, О. Грамберг, Д. Пелед. Верификация моделей программ: Model Checking. М.: МЦНМО, 2002

2. Вельдер С. Э., Лукин М. А., Шалыто А. А., Яминов Б. Р. Верификация автоматных программ. СПбГУ ИТМО, 2011.

3. А. С. Камкин. Введение в формальные методы верификации программ: учебное пособие - Москва: МАКС Пресс, 2018.