🔴 Какие данные необходимы для независимой экспертизы смарт-контрактов и блокчейн-систем?

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

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

🔴 Раздел 1: Исходный код смарт-контракта — фундамент любой экспертизы

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

🔑 Что такое исходный код и почему он так важен:

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

🔴 Каким должен быть исходный код для экспертизы:

Требование №1: Оригинальные файлы. Не скриншоты, не PDF, не распечатки. А сами файлы с расширением, соответствующим языку программирования. Обычно это текстовые файлы, которые можно открыть в любом редакторе.

Требование №2: Полный комплект. Если смарт-контракт состоит из одного файла — предоставьте один файл. Если из десяти взаимосвязанных файлов (например, контракт, библиотеки, интерфейсы) — предоставьте все. Нельзя предоставить только «главный» файл, остальные «мелкие» не важны. В блокчейне работает объединенный код, и эксперт должен видеть всё.

Требование №3: Версия, которая была развернута. Разработчики могли менять код после развертывания, но в блокчейне осталась старая версия. Эксперту нужна именно та версия, которая была в блокчейне в момент спорных событий. Если вы предоставите не ту версию, эксперт выявит расхождение, но это займет время. Лучше сразу указать: «Это версия от такой-то даты, коммит в репозитории с хешем…».

Требование №4: Комментарии (желательно). Если код содержит комментарии на русском языке, это огромное подспорье. Комментарии объясняют замысел разработчика. Без комментариев эксперт интерпретирует код «как есть», но с ними — глубже понимает, что хотели сделать, и может обнаружить расхождение между замыслом и реализацией.

🔴 Что делать, если исходный код утерян или его не было (например, форкнутый контракт)?

Не отчаивайтесь. Эксперт может:

Восстановить исходный код из байт-кода с помощью дизассемблера и декомпилятора (но это будет не исходный код на высоком уровне, а псевдокод, менее удобный для анализа).

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

Сравнить с открытыми репозиториями, если контракт является клоном известного проекта.

Но помните: отсутствие исходного кода увеличивает стоимость и сроки в 2-3 раза. Поэтому храните исходные коды всех смарт-контрактов, которые вы когда-либо развертывали.

🔴 Раздел 2: Адреса смарт-контрактов в блокчейн-сети — навигатор для эксперта

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

🔑 Что такое адрес смарт-контракта:

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

🔴 Какие адреса и как предоставлять:

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

Требование №2: Указание сети. Один и тот же адрес может существовать в разных блокчейн-сетях (тестовая сеть, основная сеть, боковая сеть). Эксперту нужно точно знать, в какой сети находится контракт. Укажите: «основная сеть», «тестовая сеть с названием», «частная сеть с параметрами».

Требование №3: Адрес прокси-контракта, если есть. Многие современные смарт-контракты используют прокси-схему: пользователи взаимодействуют с одним адресом (прокси), а логика хранится в другом (имплементация). Эксперту нужны оба адреса — и прокси, и имплементации, а также история обновлений (какие версии логики были в разное время).

🔴 Как эксперт использует адреса:

Эксперт вводит адрес в блокчейн-обозреватель и получает:

Полную историю транзакций этого контракта (кто вызывал, какие функции, с какими параметрами).

Баланс контракта в нативной валюте и в токенах.

Код контракта (байт-код, а если контракт верифицирован — то и исходный код).

Информацию о создателе контракта (адрес, который его развернул).

Связи с другими контрактами (например, какие токены разрешены, какой оракул используется).

Без адреса эксперт слеп. Поэтому предоставляйте адреса в виде таблицы с пояснениями: «Адрес контракта голосования», «Адрес контракта токена», «Адрес контракта стейкинга».

🔴 Раздел 3: Логи блокчейн-транзакций (хеши) — хроника событий

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

🔑 Что такое хеш транзакции и зачем он нужен:

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

🔴 Какие транзакции нужно предоставлять:

Требование №1: Все спорные транзакции. Если предмет спора — перевод токенов с адреса А на адрес Б, предоставьте хеш именно этой транзакции.

Требование №2: Транзакции создания контракта. Хеш той транзакции, которая развернула смарт-контракт в блокчейне. По ней эксперт видит, когда контракт появился, кто его создатель.

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

Требование №4: Транзакции, которые могут быть связаны. Даже если вы не уверены, предоставьте все подозрительные транзакции. Эксперт отсеет лишнее, но если вы утаите важное — он может сделать неполный вывод.

🔴 Как правильно фиксировать хеши:

Не скриншотами (они могут быть подделаны), а простым текстовым списком.

Для каждого хеша укажите дату и время (по московскому времени или по универсальному).

Укажите, какая сеть.

Если знаете, какую функцию вызывала транзакция, напишите название функции (это ускорит работу).

Пример правильной подачи:
Хеш: 0x1234…abcd
Время: 15.03.2025 14:32 по московскому времени
Сеть: основная сеть
Функция: перевод токенов (transfer)
Отправитель: адрес 0x111…
Получатель: адрес 0x222…

🔴 Что делать, если хеш утерян, а транзакция была?

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

🔴 Раздел 4: Адреса криптокошельков всех участников — участники событий

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

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

Адрес истца (того, кто обращается за экспертизой или в суд).

Адрес ответчика (противной стороны).

Адреса свидетелей (если есть).

Адреса, которые появились в процессе (например, адрес биржи, куда ушли средства, адрес микс-сервиса).

Адрес, который использовал злоумышленник (если известен).

🔴 Как эксперты проверяют принадлежность адресов:

Эксперт не может просто поверить на слово, что «этот адрес принадлежит Иванову И.И.». Он использует косвенные доказательства:

Транзакции с бирж (если биржа предоставила выписку, что адрес принадлежит конкретному пользователю).

Подписи сообщений (если владелец адреса подписал криптографически сообщение «Я — Иванов»).

Взаимодействия с известными сервисами.

Анализ паттернов поведения.

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

🔴 Раздел 5: Техническая и проектная документация (White Paper, Roadmap, архитектурные схемы)

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

🔑 Какая документация нужна:

Белая книга (White Paper). Это основополагающий документ любого блокчейн-проекта. В нем описываются цели, токеномика, механики. Эксперт сверяет код с белой книгой: если в белой книге написано «максимальная эмиссия 1 000 000 токенов», а в коде нет ограничений — это нарушение.

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

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

Техническое задание. Если разработка велась по ТЗ, предоставьте его. Эксперт проверит, соответствует ли код ТЗ.

Пользовательские сценарии (Use Cases). Описания, как пользователи должны взаимодействовать с системой. Помогают понять бизнес-логику.

🔴 Что делать, если документации нет или она неполная:

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

🔴 Раздел 6: Юридические документы, связанные со смарт-контрактом

Да, смарт-контракт — это программа, но он часто оборачивается в юридическую оболочку. Есть договор, оферта, меморандум, где стороны договариваются, что «условия сделки определяются смарт-контрактом по такому-то адресу». Эксперту нужно видеть эти документы.

🔑 Какие юридические документы предоставить:

Договор на разработку смарт-контракта (между заказчиком и разработчиком).

Публичная оферта (User Agreement) платформы или децентрализованного приложения.

Меморандум о намерениях, если стороны фиксировали его до запуска.

Переписка, в которой обсуждались условия смарт-контракта (например, «Мы договорились, что комиссия составит 1%»).

Любые документы, где упоминается адрес смарт-контракта или хеш транзакции.

🔴 Как эксперт использует юридические документы:

Он не дает правовой оценки — это задача суда. Но он сопоставляет: «В договоре сказано, что функция «вывод средств» доступна только после голосования. В коде эта функция доступна всегда. Факты расходятся». Или: «В оферте обещано, что контракт будет приостановлен при обнаружении уязвимости. В коде такая функция есть, но она никогда не вызывалась до момента инцидента».

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

🔴 Раздел 7: Документы, подтверждающие коммуникацию между сторонами (переписка, чаты, задачи)

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

🔑 Какие коммуникации предоставить:

Переписку по электронной почте (особенно с вложениями).

Чаты в мессенджерах (Telegram, WhatsApp, других) — в виде экспортированных файлов или скриншотов с датами.

Задачи в системах управления проектами (Jira, Trello, других) — скриншоты задач с комментариями, статусами, датами изменений.

Протоколы совещаний (если вели).

Письменные распоряжения (например, «Пожалуйста, добавьте функцию голосования до пятницы»).

🔴 Как эксперт использует коммуникации:

Он ищет ключевые моменты:

Обсуждались ли те или иные функции? Обещал ли разработчик их реализовать?

Указывал ли заказчик на ошибки? Как разработчик реагировал?

Признавал ли разработчик наличие уязвимости?

Был ли согласован план действий при атаке?

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

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

🔴 Раздел 8: Данные из оффчейн-источников (оракулы, API, внешние системы)

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

🔑 Какие оффчейн-данные могут понадобиться:

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

API-логи сервера. Если контракт взаимодействовал с централизованным сервером (например, ваш dApp имеет серверную часть), предоставьте логи этого сервера за период спора.

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

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

🔴 Проблема доверия к оффчейн-данным:

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

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

🔴 Раздел 9: Особые случаи — что нужно для экспертизы приватных (корпоративных) блокчейнов

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

🔑 Что нужно для экспертизы приватного блокчейна:

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

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

Ключи доступа. Если сеть требует авторизации для чтения (разрешенная сеть), предоставьте временные учетные данные.

Конфигурация сети. Описание того, как настроена сеть: алгоритм консенсуса, количество узлов, кто валидаторы, какие ограничения.

🔴 Почему приватные сети сложнее и дороже:

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

🔴 Раздел 10: Пошаговая инструкция по сбору материалов — чек-лист для адвоката или компании

Чтобы ничего не забыть, используйте этот чек-лист. Распечатайте и отмечайте галочками.

🔴 Этап 1: Данные о смарт-контракте:

Исходный код (все файлы) версии, развернутой в блокчейне.

Адрес смарт-контракта (основной, прокси, имплементации).

Хеш транзакции создания контракта.

Информация о том, верифицирован ли код в обозревателе.

Ссылка на репозиторий (если код публичен), с указанием коммита.

🔴 Этап 2: Данные о транзакциях:

Список всех спорных транзакций с хешами, датами, суммами.

Список транзакций вызова ключевых функций (пауза, снятие, голосование).

Логи событий (если эксперт просит их выгрузить отдельно).

🔴 Этап 3: Данные об участниках:

Адреса кошельков всех сторон (истец, ответчик, третьи лица).

Доказательства принадлежности адресов (выписки с бирж, подписанные сообщения).

Любые идентификаторы, связывающие адрес с человеком или компанией.

🔴 Этап 4: Документация проекта:

Белая книга (White Paper) на русском языке.

Дорожная карта (Roadmap).

Архитектурные схемы.

Техническое задание.

Пользовательские сценарии.

🔴 Этап 5: Юридические документы:

Договор на разработку.

Публичная оферта (User Agreement).

Меморандумы, соглашения.

Переписка, где обсуждались условия.

🔴 Этап 6: Коммуникации:

Электронная переписка (экспорт или скриншоты).

Чаты мессенджеров (экспорт).

Скриншоты задач из Jira, Trello, других систем.

🔴 Этап 7: Внешние данные:

Логи оракулов (если использовались).

API-логи сервера.

Скриншоты интерфейса (с датой и временем).

Данные от облачных провайдеров.

🔴 Этап 8: Процессуальные документы (если экспертиза судебная):

Определение суда о назначении экспертизы.

Вопросы, поставленные судом.

Копии других доказательств по делу, которые могут быть релевантны.

🔴 Раздел 11: Реальные кейсы — как недостаток материалов затянул экспертизу или привел к неполным выводам

🔴 Кейс №1: Отсутствие исходного кода. Адвокат предоставил только байт-код, сказав, «разработчики сбежали, кода нет». Эксперту пришлось дизассемблировать байт-код, что заняло 10 дней вместо 3. Стоимость выросла с 300 000 до 600 000 рублей. В итоге эксперт смог установить только часть функций, а некоторые детали остались неясными. Суд назначил дополнительную экспертизу. Если бы исходный код сохранили, можно было бы сэкономить время и деньги.

🔴 Кейс №2: Неверный адрес контракта. Заказчик ошибся в одном символе адреса, и эксперт две недели анализировал чужой контракт, не имеющий отношения к делу. Когда ошибка обнаружилась, заказчик начал спорить, кто виноват. В итоге экспертиза была переделана, сроки сдвинуты на месяц. Урок: всегда перепроверяйте адреса, копируйте их из обозревателя, не вводите вручную.

🔴 Кейс №3: Отсутствие переписки. В споре о том, была ли санкционирована транзакция, истец утверждал, что он дал указание, ответчик — что не давал. В переписке, которую истец не предоставил (потому что «это личное, не для суда»), было прямое указание: «Переведи токены по адресу такой-то». Когда через месяц переписку всё же нашли и передали, эксперт включил ее в дополнение, но основное заключение уже было дано без нее. Суд посчитал, что эксперт был неполон. Урок: предоставляйте всё, даже то, что кажется неважным.

🔴 Кейс №4: Успешный сбор всех материалов. Адвокат крупной компании заранее получил все возможные данные: код, хеши, адреса, переписку, документацию. Эксперт подготовил заключение за 12 дней (из 15 запланированных). Суд приобщил его без замечаний. Компания выиграла спор. Экономия на юристах, которые грамотно собрали материалы, составила более 1 миллиона рублей на ускорении процесса.

🔴 Раздел 12: Частые вопросы о предоставлении исходных данных

Вопрос 1: Могу ли я предоставить данные анонимно?
Ответ: Да, для досудебной экспертизы мы можем заключить договор о неразглашении и получить материалы без раскрытия вашего имени (например, от представителя по доверенности). Но для судебной экспертизы суд будет знать, кто заказчик.

Вопрос 2: Нужно ли переводить на русский язык код?
Ответ: Нет, код пишется на языке программирования, его английские ключевые слова (if, for, function) не считаются иностранным текстом, это технические термины. А вот комментарии на английском желательно перевести на русский, если есть возможность.

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

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

Вопрос 5: Есть ли срок давности для данных блокчейн-транзакций?
Ответ: В публичных блокчейнах данные хранятся вечно, если только сеть не прекратила существование. Но лучше не тянуть: чем раньше вы зафиксируете хеши и адреса, тем меньше риск, что вы что-то перепутаете.

🔴 Заключение: хорошая подготовка материалов — половина успеха

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

Если вы адвокат или представитель компании, готовьтесь к экспертизе заранее. Используйте наш чек-лист. И обращайтесь к нам — мы проведем экспертизу качественно и в срок.

Ссылка на наш сайт: fedexpertiza.ru