Введение: почему экспертиза в блокчейне требует особых материалов

Когда адвокат или руководитель компании сталкивается со спором, связанным с цифровыми активами или самоисполняемыми соглашениями, первым вопросом становится: «Какие документы нужны эксперту?». Традиционные экспертизы (почерковедческие, строительные, автотехнические) оперируют привычными бумагами и физическими объектами. Но экспертиза смарт-контрактов и блокчейн-систем работает с программным кодом, распределенными реестрами и цифровыми следами. Ошибка в предоставлении данных может привести к неполному или неверному заключению, а это — проигранное дело или необоснованные обвинения. В этом материале мы подробно разберем, какие именно исходные данные и материалы необходимо собрать адвокату или компании, чтобы независимая экспертиза прошла максимально эффективно, а ее результаты были приняты судом. Полную информацию об услугах нашей организации вы найдете на официальном сайте: fedexpertiza.ru

Почему набор данных для блокчейн-экспертизы отличается от традиционной

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

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

Главное правило для заказчика: Не думайте, что эксперт «сам все найдет в интернете». Да, многие блокчейны публичны, но без точных идентификаторов (адресов, хэшей, временных меток) эксперт потратит дни или недели на поиск отправной точки. Предоставьте максимум информации — и вы сэкономите деньги и время.

Категория 1: исходный код смарт-контракта

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

Что именно нужно предоставить:

• Исходные файлы кода с расширениями, соответствующими языку программирования (например,.sol для популярной платформы Эфириум).
• Все версии кода, если в процессе его жизненного цикла были изменения. Часто бывает так: сначала был развернут один контракт, потом его заменили другим, а спор возник по первому. Без старой версии эксперт не сможет восстановить картину.
• Комментарии к коду (если они есть). Разработчики часто оставляют пояснения прямо в коде — это ценный источник информации о замысле.
• Указание на используемые библиотеки и зависимости. Смарт-контракты редко пишутся с нуля; они используют стандартные библиотеки. Эксперту нужно знать, какие именно библиотеки применялись и каких версий.

📌 Пример из практики: В одном споре ответчик утверждал, что смарт-контракт содержал «ошибку», из-за которой средства ушли не туда. При предоставлении исходного кода эксперт обнаружил, что ошибка была не случайной, а преднамеренной — в коде была функция, позволявшая владельцу контракта изменять адрес получателя. Без исходного кода (только по байт-коду из блокчейна) доказать это было бы крайне сложно.

Категория 2: адрес (адреса) смарт-контракта в блокчейне

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

Что нужно знать заказчику:

• Адрес смарт-контракта выглядит как длинная строка из букв и цифр (например, 0x…). Он уникален для каждой сети. Один и тот же контракт, развернутый в тестовой сети и в основной сети, будет иметь разные адреса.
• Обязательно укажите, в какой именно блокчейн-сети находится контракт (например, «основная сеть Эфириум», «тестовая сеть Сеполя», «сеть Бинанс» и так далее). Эксперт должен подключиться к правильной сети.
• Если контракт был развернут несколько раз (разные версии), предоставьте адреса всех версий.

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

Категория 3: полные логи блокчейн-транзакций

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

Что нужно предоставить:

• Хэши всех транзакций, связанных со спорными операциями. Хэш — это уникальный идентификатор транзакции, также длинная строка символов. По хэшу эксперт может найти полную информацию о транзакции в любом блокчейн-обозревателе.
• Адреса отправителей и получателей по каждой транзакции.
• Точные даты и время каждой транзакции (желательно с указанием часового пояса). Чем точнее, тем лучше.
• Суммы переведенных активов и тип актива (например, «10 единиц токена USDT», «0,5 единицы эфира»).
• Комиссии за транзакции (так называемый «газ»), если это имеет значение для спора (например, при оспаривании нехватки средств).

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

Категория 4: адреса криптокошельков всех участников

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

Какие адреса нужны:

• Адрес кошелька истца (потерпевшего).
• Адрес кошелька ответчика (предполагаемого нарушителя).
• Адреса посредников (если средства проходили через промежуточные кошельки).
• Адреса смарт-контрактов, с которыми взаимодействовали участники (если это не тот же контракт, который является предметом спора).

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

Категория 5: техническая и проектная документация

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

Что особенно важно:

• Описание проекта — обычно это файл в формате PDF, где изложены цели, механика работы, экономическая модель. Эксперт сверяет код с этим описанием. Если в коде есть то, чего нет в описании, или наоборот — это повод для выводов.
• Техническое задание на разработку — если оно сохранилось. Иногда в техническом задании описаны функции, которые потом не реализовали, или реализовали иначе.
• Архитектурные схемы — схемы взаимодействия компонентов (как смарт-контракт общается с внешними системами, как пользователи взаимодействуют с контрактом).
• Пользовательские сценарии — описание того, как, по замыслу разработчиков, пользователь должен был совершать действия (например, «шаг 1: пользователь подключает кошелек, шаг 2: нажимает кнопку «инвестировать»»).

Категория 6: юридические документы

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

Примеры:

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

Зачем это эксперту: Иногда код смарт-контракта написан так, что допускает неоднозначное толкование. Юридические документы помогают понять, что именно стороны имели в виду. Эксперт в выводах может указать: «Согласно пункту 3 договора, стороны договорились о X, однако код реализует Y — это является несоответствием».

Категория 7: документы, подтверждающие коммуникацию между сторонами

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

Что может быть полезно:

• Переписка в мессенджерах (Telegram, WhatsApp, электронная почта), где обсуждалась работа смарт-контракта.
• Протоколы встреч (например, в формате Word или PDF), где зафиксированы решения о добавлении или удалении функций.
• Скриншоты обсуждений в системах управления задачами (если они есть).
• Голосовые сообщения и записи звонков (при их допустимости в суде).

Важно: Предоставляйте переписку в хронологическом порядке и в читаемом виде (скриншоты или экспортированные файлы). Эксперт не должен тратить время на расшифровку неразборчивых изображений.

Категория 8: информация из внешних источников (оффчейн-данные)

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

Какие внешние системы бывают:

• Поставщики внешних данных — сервисы, которые передают смарт-контракту информацию о курсах, погоде, результатах спортивных событий и так далее. Нужны логи запросов и ответов.
• Веб-сайты и приложения — через которые пользователи взаимодействовали со смарт-контрактом. Нужны логи действий пользователя (что он нажимал, какие данные вводил).
• Централизованные серверы — если проект использует гибридную архитектуру (часть данных на блокчейне, часть на обычном сервере). Нужны логи сервера за спорный период.

📌 Пример из практики: В споре о ставках через смарт-контракт на спортивное событие одна сторона утверждала, что поставщик внешних данных (так называемый «оракул») передал неверный результат. Эксперту потребовались логи запросов к этому поставщику. Без них было невозможно определить, ошибся ли поставщик или смарт-контракт неверно обработал данные.

Реальные кейсы: какие данные помогли, а какие — нет

Кейс №1. Спор между разработчиком и заказчиком смарт-контракта.

Ситуация: Заказчик утверждал, что разработанный смарт-контракт не соответствует техническому заданию: вместо того чтобы замораживать средства инвесторов на год, контракт позволял владельцу вывести их через месяц. Разработчик настаивал, что «так было задумано».
Предоставленные данные: Исходный код, техническое задание (в формате Word), переписка в мессенджере, где разработчик подтверждал, что функция вывода будет отключена на год.
Результат экспертизы: Эксперт сравнил код с техническим заданием и нашел явное расхождение. Также в переписке были фразы разработчика «Да, я помню про блокировку на год, сделаем». Вывод: контракт не соответствует согласованному техническому заданию. Суд встал на сторону заказчика. Разработчик вернул аванс 1,2 миллиона рублей.

Кейс №2. Инвестор против создателей «пирамиды» на смарт-контракте.

Ситуация: Группа лиц создала смарт-контракт, который принимал средства под обещание высокого дохода. Когда набралось около 50 миллионов рублей, создатели вывели все средства. Пострадавшие инвесторы обратились за экспертизой.
Предоставленные данные: Только адрес смарт-контракта и хэши нескольких транзакций потерпевших. Исходного кода не было (он не был опубликован).
Результат экспертизы: Эксперт извлек байт-код из блокчейна и восстановил примерную логику. Было обнаружено, что контракт содержит функцию, позволяющую «владельцу» в любой момент забрать все средства. Однако без исходного кода и комментариев эксперт не смог определить, кто именно был заложен как «владелец» (конкретный адрес или условие). Тем не менее, заключение помогло возбудить уголовное дело по статье о мошенничестве. Если бы пострадавшие заранее сохранили исходный код (например, с сайта проекта, который потом закрылся), выводы были бы более точными.

Кейс №3. Адвокат, который не предоставил логи транзакций.

Ситуация: Адвокат заказал экспертизу по делу о неисполнении смарт-контракта, но предоставил только устные пояснения своего доверителя и распечатку экрана с балансом кошелька. Эксперт трижды запрашивал хэши транзакций, но адвокат не смог их получить от доверителя (доверитель «забыл» адрес кошелька и не сохранил хэши).
Результат: Экспертиза была проведена в ограниченном объеме (только анализ исходного кода контракта, без привязки к конкретным операциям). Эксперт сделал оговорку: «В связи с отсутствием данных о конкретных транзакциях, выводы носят общий характер». Суд не принял заключение как надлежащее доказательство. Дело было проиграно. Адвокат получил претензию от доверителя за ненадлежащее оказание услуг.

Урок: Без полных данных (особенно хэшей транзакций) экспертиза теряет доказательственную силу. Адвокат должен требовать от доверителя все технические детали, даже если доверитель считает их «скучными».

Как правильно собрать и оформить материалы: советы адвокатам и компаниям

Совет №1. Создайте отдельную папку с материалами в хронологическом порядке.
Разложите документы по подпапкам: «01_Исходный_код», «02_Адреса_контрактов», «03_Хэши_транзакций», «04_Переписка», «05_Документация». Это значительно ускорит работу эксперта и снизит стоимость, потому что эксперт не будет тратить время на систематизацию хаоса.

Совет №2. Не ограничивайтесь скриншотами, предоставляйте данные в машиночитаемых форматах.
Хэши транзакций предоставляйте в текстовом файле (например, в блокноте), а не только на скриншотах. Эксперт должен иметь возможность скопировать хэш и вставить его в инструмент анализа. То же касается адресов кошельков.

Совет №3. Указывайте временные метки с часовым поясом.
Если вы пишете «транзакция произошла 10 мая в 15:30», уточните, по какому часовому поясу (московскому, гринвичскому, местному). Блокчейн использует единое время (координированное всемирное время), и эксперт будет пересчитывать.

Совет №4. Не редактируйте и не обрезайте переписку.
Предоставляйте переписку целиком. Вырезание фрагментов может быть замечено противоположной стороной, и эксперт сделает вывод о неполноте материалов. Если в переписке есть лишнее, эксперт сам отсеет не относящееся к делу.

Совет №5. Если каких-то данных нет — честно скажите об этом.
Не скрывайте отсутствие информации. Эксперт сделает оговорку «в связи с отсутствием данных X выводы о Y не могут быть сделаны». Это лучше, чем если эксперт обнаружит, что вы что-то утаили, и это подорвет доверие ко всем выводам.

Часто задаваемые вопросы о предоставлении данных

Вопрос: Обязательно ли предоставлять исходный код, если контракт уже развернут и его код есть в блокчейне?
Ответ: В блокчейне хранится скомпилированный код (байт-код), который очень трудно читать человеку. Исходный код — это то, что писал разработчик, с комментариями, названиями переменных, структурами. Без исходного кода эксперт может упустить важные детали. Мы настоятельно рекомендуем предоставлять исходный код. Если его нет — мы работаем с байт-кодом, но это дольше, дороже и менее точно.

Вопрос: Что делать, если контракт был развернут через прокси (с возможностью обновления), и логика изменилась после развертывания?
Ответ: Нужно предоставить адреса и версии всех имплементаций (реализаций), а также логи вызовов функции обновления. Эксперт должен знать, какой код когда был активен.

Вопрос: Могу ли я предоставить данные анонимно, чтобы не раскрывать коммерческую тайну?
Ответ: Да,мы подписываем соглашение о неразглашении (конфиденциальности). Вы также можете скрыть названия проектов и заменить их на «Проект А», «Проект Б», но технические детали (код, хэши, адреса) должны быть настоящими. Анонимизация названий не влияет на качество экспертизы.

Вопрос: Сколько времени уходит на сбор всех материалов?
Ответ: Зависит от сложности. Для простого спора по одному смарт-контракту можно собрать все за 1-2 часа (скопировать хэши, скачать код, сохранить переписку). Для сложного дела с десятками транзакций и несколькими контрактами — от 1 до 5 рабочих дней.

Вопрос: Что будет, если я предоставлю неполные или неверные данные?
Ответ: Эксперт укажет в заключении, что анализ проведен на основании предоставленных материалов, и перечислит недостающие данные. Если недостающие данные критичны, эксперт может отказаться от дачи заключения или сделать выводы с большой долей вероятности, что снизит их доказательственную ценность. В худшем случае суд может не принять такое заключение.

Перечень материалов в виде краткого списка (памятка)

Для удобства адвокатов и компаний мы свели все необходимое в один чек-лист. Скопируйте его и используйте при подготовке к экспертизе.

📋 Обязательные материалы:

• Исходный код смарт-контракта (все версии, с комментариями).
• Адрес (адреса) смарт-контракта в блокчейне с указанием сети.
• Хэши всех транзакций, связанных со спором.
• Адреса кошельков всех участников (истец, ответчик, третьи лица).
• Даты и время всех событий с указанием часового пояса.
• Суммы и типы активов по каждой транзакции.

📋 Рекомендуемые материалы (значительно повышают качество экспертизы):

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

Итоговый вывод

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

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

Официальный сайт

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