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

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

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

🔬 1. Исходный код смарт-контракта (самый важный элемент)

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

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

✅ Полный текст исходного кода всех смарт-контрактов, задействованных в спорной ситуации (не только главного контракта, но и всех вспомогательных, библиотек, наследуемых контрактов).
✅ Все версии кода, если в процессе жизненного цикла контракта (до или после инцидента) в него вносились изменения. Указание версий и дат изменений критически важно для определения того, какой именно код исполнялся в момент спорных событий.
✅ Ссылку на систему контроля версий (например, на открытые репозитории), если код хранился публично, с указанием конкретного коммита (фиксированного набора изменений), который соответствует развернутому в блокчейне контракту.
✅ Файлы конфигурации компилятора (например, файлы сборки), чтобы эксперт мог воспроизвести процесс компиляции и убедиться, что байт-код в блокчейне соответствует предоставленному исходному коду.
✅ Комментарии разработчиков в коде (если они есть) — они помогают понять замысел, особенно в сложных участках логики.

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

🔍 2. Адрес (адреса) смарт-контракта в блокчейн-сети

Каждый развернутый смарт-контракт в публичном блокчейне (подобно Эфириуму, Бинанс Смарт Чейн, Полигону и другим) имеет уникальный идентификатор — адрес контракта. Это строка букв и цифр (например, 0x…), по которой любой участник сети может найти контракт, посмотреть его байт-код, баланс, количество транзакций и взаимодействий.

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

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

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

📜 3. Полные записи (логи) блокчейн-транзакций, связанных со смарт-контрактом и спорными операциями

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

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

✅ Список хэшей (идентификаторов) всех транзакций, имеющих отношение к спору: начиная с развертывания смарт-контракта, заканчивая каждой спорной операцией.
✅ Для каждой транзакции: временная метка (время включения в блок, желательно в скоординированном всемирном времени), адрес отправителя, адрес получателя, сумма перевода (если это перевод активов), объем использованного газа (комиссии), статус выполнения (успех или ошибка).
✅ Логи событий (ивенты), сгенерированные смарт-контрактом в ходе исполнения — они содержат структурированную информацию о том, что именно произошло (например, «токен А переведен с адреса Х на адрес У в количестве Z»).
✅ Если транзакций много (сотни или тысячи) — экспортируйте их в структурированном формате (например, электронная таблица или файл с разделителями) из обозревателя блокчейна (блокчейн-эксплорера) или через программный интерфейс (АПИ).

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

👛 4. Адреса криптокошельков всех участников спорных операций

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

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

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

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

📚 5. Техническая и проектная документация («белая книга», архитектурные схемы, техническое задание)

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

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

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

Почему это важно: Документация позволяет выявить расхождения между заявленными намерениями и фактической реализацией. Если в белой книге написано «комиссия составляет 1 процент от суммы перевода», а в коде найдено, что фактически удерживается 5 процентов — это основание для признания действий разработчиков недобросовестными.

⚖️ 6. Юридические документы, связанные с использованием смарт-контракта

Хотя эксперт не является юристом и не дает правовой квалификации, он использует юридические документы для понимания контекста и сопоставления «кода как закона» с традиционным правовым полем.

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

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

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

💬 7. Материалы коммуникации между сторонами (переписка, протоколы совещаний, задачи)

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

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

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

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

🌐 8. Информация из внешних источников (оффчейн-данные), если смарт-контракт полагался на оракулов или сторонние АПИ

Многие современные смарт-контракты не существуют изолированно — они получают данные из внешнего мира через оракулов (сервисы-поставщики данных) или напрямую через программные интерфейсы приложений (АПИ) централизованных сервисов.

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

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

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

💻 9. Данные об узлах сети (при необходимости технической экспертизы инфраструктуры)

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

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

✅ Конфигурационные файлы нод (узлов), участвовавших в обработке спорных транзакций.
✅ Логи работы нод (особенно если они не публичные, а внутренние логи компании).
✅ Сведения о том, кто управлял нодами, какой у них был доступ к ключам.
✅ Для частных блокчейнов (разрешенных сетей) — списки участников, правила консенсуса, протоколы связи.

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

📌 10. Дополнительные материалы: скриншоты, видеозаписи, показания свидетелей

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

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

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

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

📊 РАЗДЕЛ С КЕЙСАМИ

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

Кейс № 2. Полный набор данных позволил доказать атаку через оракул. Компания-заказчик подозревала, что крупные потери в протоколе ДеФи связаны с манипуляцией ценой через оракул. Мы запросили и получили: исходный код смарт-контракта, хеши всех подозрительных транзакций, адреса кошельков атакующего (частично известные), а также логи обращений к оракулу от оператора оракула. Эксперты восстановили последовательность из 25 транзакций и показали, что атакующий за 3 секунды до основной атаки подал оракулу специально сформированный запрос, занизивший цену актива в 50 раз, после чего смарт-контракт выдал кредит под залог по заниженной цене. Адреса атакующего были связаны с конкретным лицом через данные верификации на бирже. Суд удовлетворил иск, средства частично возвращены.

Кейс № 3. Расхождение между белой книгой и кодом как основание для признания сделки недействительной. Инвесторы приобрели токены проекта, в белой книге которого было заявлено, что комиссия за вывод средств составляет 0,1 процента, а также что владелец контракта не имеет права замораживать средства пользователей. Наша экспертиза, проведенная по заказу юристов инвесторов, выявила: в коде комиссия была установлена на уровне 3 процентов, а также имелась функция, позволяющая владельцу (администратору) полностью заблокировать вывод средств с любого адреса по своему усмотрению — информация, отсутствовавшая в белой книге. Экспертное заключение с указанием конкретных строк кода и сравнением с документацией было приобщено к иску. Суд признал действия разработчиков недобросовестными, сделки купли-продажи токенов были частично признаны недействительными, инвесторы получили компенсацию.

Кейс № 4. Переписка в мессенджере помогла установить момент, когда разработчики узнали об уязвимости. По делу о хищении из смарт-контракта ответчик (разработчик) утверждал, что не знал об уязвимости и не мог ее исправить до взлома. Адвокат истца предоставил в материалы экспертизы экспортированные логи чата в одном из мессенджеров где за 2 месяца до инцидента разработчик обсуждал с коллегой «странное поведение функции» и говорил «надо бы пофиксить, но пока нет времени». Наши эксперты сопоставили временные метки из чата с датой исправления в системе контроля версий (оказалось, исправление было внесено только через 2 месяца после взлома). Также эксперты показали, что исправление в коде было тривиальным (одна строка). Суд сделал вывод о том, что разработчик знал об уязвимости, но сознательно не исправлял ее, что отягчило ответственность. Размер компенсации увеличен на 40 процентов.

Кейс № 5. Отсутствие логов оракула не позволило доказать вину одной из сторон. В споре между двумя компаниями о сбое поставки данных через оракул, истец утверждал, что оракул дал неверные данные по вине ответчика (оператора оракула). Однако оператор оракула не вел детальных логов входных запросов, хранил только итоговые данные, переданные в блокчейн. Наша экспертиза показала, что по имеющимся в блокчейне данным (хешам транзакций и значениям) невозможно определить, была ли ошибка на стороне источника данных, в канале связи или в самом оракуле. Заключение содержало вывод: «установить причину неверного значения не представляется возможным ввиду отсутствия необходимых логов». Суд отказал в иске из-за недоказанности вины ответчика. Дело — пример того, как недостаточность исходных данных (логов) рушит перспективу дела.

📌 Рекомендации адвокатам и компаниям по сбору данных

🔹 Начинайте сбор данных как можно раньше, желательно в момент обнаружения проблемы или сразу после подозрительной операции. Некоторые данные (например, временные ключи доступа к нодам, сессионные логи) могут быть перезаписаны или удалены в течение нескольких дней.
🔹 Фиксируйте все в письменном виде — кто, когда, у кого запросил данные, какие данные были получены, а какие нет. Это поможет в суде обосновать, что запрашивались все возможные материалы.
🔹 Используйте общедоступные обозреватели блокчейна (блокчейн-эксплореры) для самостоятельного экспорта хешей транзакций и адресов — это бесплатно и позволяет проверить базовую информацию до обращения к эксперту.
🔹 Сохраняйте скриншоты интерфейсов децентрализованных приложений (ДАпп), особенно тех страниц, где показаны комиссии, сроки, условия — впоследствии веб-сайт может быть изменен.
🔹 Привлекайте эксперта на этапе формулирования запроса о предоставлении данных противоположной стороной или третьими лицами, чтобы перечень запрашиваемых материалов был полным и юридически корректным.
🔹 Обеспечьте сохранность цифровых доказательств — используйте хеширование (вычисление контрольных сумм) файлов и логов, фиксируйте дату и время получения материалов засвидетельствованным способом (нотариус, протокол осмотра). Это предотвратит утверждения о фальсификации.

🏁 Заключение: полнота данных — залог успеха

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

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

👉 Больше экспертных материалов и информация об услугах — на нашем сайте: fedexpertiza.ru