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

Для проведения независимой экспертизы самоисполняемых контрактов (часто называемых «смарт-контрактами») и систем распределенного реестра (блокчейн) адвокату или компании потребуется предоставить максимально полный набор данных, который позволит эксперту всесторонне изучить предмет исследования и дать объективные выводы. 🔎

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

Ключевые отличия от традиционной экспертизы:

📌 Кейс из практики:

Адвокат обратился к нам на fedexpertiza.ru для проведения экспертизы по делу о краже криптоактивов. Первоначально он предоставил только исковое заявление и переписку сторон. Этого было недостаточно. Мы объяснили, что нужны хеши транзакций и адреса кошельков. После того как адвокат получил эти данные от доверителя, экспертиза была проведена за 12 рабочих дней. Заключение помогло выиграть дело. Если бы адвокат предоставил полный пакет с самого начала, срок сократился бы на 5 дней.

🧩 Раздел 2. Исходный код самоисполняемого контракта (смарт-контракта)

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

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

✅ Исходный код (файлы с расширениями, характерными для языка, например, «солидити» для платформы «Эфириум»).

✅ Все версии кода, если в процессе жизненного цикла контракта были изменения (например, версия 1.0, 1.1, 2.0).

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

✅ Комментарии к коду (если есть) — они помогают понять замысел разработчика.

✅ Файлы зависимостей (библиотеки, которые импортируются в контракт).

Что проверяет эксперт в коде:

📌 Кейс из практики:

К нам на fedexpertiza.ru обратился держатель токенов. Он подозревал, что разработчики оставили в коде скрытую функцию для выпуска дополнительных токенов в свою пользу. Мы запросили исходный код контракта (около 600 строк). В ходе анализа эксперт обнаружил функцию, которая позволяла создателю контраста (владельцу) увеличивать общее количество токенов без ограничений, даже после завершения первичного размещения. Эта функция не была описана в белой книге. Экспертное заключение подтвердило наличие скрытой возможности. Держатель токенов использовал заключение для обращения в правоохранительные органы.

🌐 Раздел 3. Адрес (адреса) самоисполняемого контракта в распределенном реестре

Адрес самоисполняемого контракта — это уникальный идентификатор в сети распределенного реестра (например, сеть «Эфириум» или «Бинанс Смарт Чейн»). 🔎 Он необходим для того, чтобы эксперт мог получить доступ к публичной записи о контракте и к истории всех его взаимодействий.

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

📍 Основной адрес контракта (строка из 40 шестнадцатеричных символов, начинающаяся с «0х»).

📍 Сеть, в которой развернут контракт (основная сеть, тестовая сеть, побочная сеть).

📍 Адреса прокси-контрактов (если контракт обновляется через прокси).

📍 Блок, в котором контракт был создан (если известно).

Что может сделать эксперт, зная адрес контракта:

✅ Проверить байт-код (скомпилированную версию) и сравнить его с предоставленным исходным кодом.

✅ Получить историю всех транзакций — кто, когда и с какими параметрами вызывал контракт.

✅ Узнать баланс контракта (сколько токенов или монет хранится на его счете).

✅ Посмотреть, был ли контракт удален или самоуничтожен.

📌 Кейс из практики:

В судебном споре о неисполнении условий токенизации одна сторона утверждала, что самоисполняемый контракт был развернут по адресу «А», а другая — что по адресу «Б». Мы на fedexpertiza.ru запросили у сторон оба адреса. Эксперт проанализировал оба контракта. Оказалось, что по адресу «А» находится «контракт-обертка», который просто перенаправляет вызовы на адрес «Б». Но владелец адреса «Б» изменил логику за день до спорной транзакции. Без знания обоих адресов эксперт не смог бы восстановить полную картину. Дело было разрешено в пользу стороны, предоставившей оба адреса.

📜 Раздел 4. Полные логи записей распределенного реестра, связанных с самоисполняемым контрактом и спорными операциями

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

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

🔗 Хеши (идентификаторы) всех спорных транзакций — уникальные строки, по которым можно найти каждую операцию в распределенном реестре.

📍 Адреса участников (отправителя, получателя, самого контракта).

⏱️ Точные метки времени (дата и час, когда транзакция была включена в блок).

🧾 Суммы переданных активов (в единицах криптоактивов и/или в рублях на момент операции).

⛽ Размер комиссии (газа) и использованный лимит.

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

✅ Восстанавливает хронологию событий (что произошло раньше, что позже).

✅ Выявляет аномалии (например, несколько одинаковых вызовов за короткое время — признак атаки).

✅ Проверяет, были ли выполнены условия самоисполняемого контракта.

✅ Отслеживает движение средств между кошельками.

📌 Кейс из практики (важность логов):

*По делу о мошенничестве с децентрализованным кредитованием потерпевший предоставил нам на fedexpertiza.ru только одно утверждение: «Мои токены исчезли». Мы запросили хеши транзакций. Он сказал, что не сохранил их. Без хешей экспертиза была невозможна. К счастью, потерпевший нашел историю операций в своем интернет-обозревателе. Мы получили 6 хешей. Анализ показал, что токены были не украдены, а переведены в другой пул ликвидности по собственной подписи пользователя (он случайно нажал «одобрить» в фишинговом приложении). Экспертиза помогла это установить.*

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

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

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

📍 Адрес кошелька истца (потерпевшего) — откуда ушли средства.

📍 Адрес кошелька ответчика (подозреваемого) — куда предположительно ушли средства (если известен).

📍 Промежуточные адреса — если средства проходили через несколько кошельков.

📍 Адреса, на которых средства были «заморожены» или находятся в настоящее время.

Что дает эксперту знание адресов кошельков:

✅ Возможность построить карту потоков (граф перемещений активов).

✅ Найти связанные адреса (принадлежащие тому же лицу через кластерный анализ).

✅ Проверить, не поступали ли средства на централизованные биржи (для последующей деанонимизации через судебный запрос).

✅ Установить, не использовались ли миксеры или сервисы смешивания.

📌 Кейс из практики (кластерный анализ адресов):

*В деле о хищении криптоактивов злоумышленник использовал 15 разных адресов-посредников. Потерпевший знал только свой адрес и начальный адрес, на который ушли средства. На fedexpertiza.ru мы запросили оба адреса и, используя кластерный анализ, выявили еще 13 адресов, которые с высокой вероятностью принадлежали тому же злоумышленнику (были общие входы и паттерны перевода). Это позволило в пять раз увеличить количество «следов» для правоохранительных органов.*

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

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

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

📘 Белая книга — документ, в котором изложены цели проекта, механика работы, токеномика.

🗺️ Дорожная карта — план развития проекта с указанием ключевых этапов.

📐 Архитектурные схемы — рисунки, показывающие, как контракты взаимодействуют друг с другом и с внешними системами.

📝 Техническое задание — документ, где описано, что именно должен делать контракт.

🧪 Результаты предварительных тестов (если проводились).

Что проверяет эксперт с помощью документации:

✅ Соответствует ли реальный код тому, что обещано в белой книге.

✅ Есть ли функции, не описанные в документации (подозрительно).

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

✅ Не вводили ли инвесторов в заблуждение (расхождения между обещаниями и реальностью).

📌 Кейс из практики (расхождение с белой книгой):

Инвесторы обвинили разработчиков в том, что те изменили механику распределения наград без уведомления. Разработчики утверждали, что «все по документации». Мы на fedexpertiza.ru запросили актуальную белую книгу и исходный код контракта. Оказалось, что в белой книге было написано: «награда распределяется пропорционально доле в пуле каждые 7 дней». В коде же награда распределялась каждые 30 дней с преимуществом для крупных вкладчиков. Экспертиза подтвердила расхождение. Суд обязал разработчиков доплатить инвесторам разницу.

⚖️ Раздел 7. Юридические документы (договоры, соглашения, меморандумы)

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

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

📄 Договор на разработку самоисполняемого контракта (если есть).

📄 Договор между сторонами, который контракт должен был исполнить.

📄 Меморандум о взаимопонимании (если стороны обменивались намерениями).

📄 Пользовательское соглашение платформы, на которой работает контракт.

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

✅ Понимает, какие именно обязательства должны были быть исполнены автоматически.

✅ Определяет, были ли условия о применимом праве и порядке разрешения споров.

✅ Сопоставляет юридические формулировки («сторона А обязуется передать токены») с технической реализацией.

✅ Выявляет несоответствия между текстом договора и кодом контракта.

📌 Кейс из практики:

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

💬 Раздел 8. Документы, подтверждающие коммуникацию между сторонами

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

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

📧 Электронную переписку между разработчиками, заказчиками, пользователями.

💬 Логи чатов в мессенджерах (Telegram, иные мессенджеры), если они относятся к делу.

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

🧩 Снимки экранов из систем управления задачами (например, в системах типа «Джира» или «Трелло»).

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

✅ Устанавливает, обсуждалась ли спорная функция до инцидента.

✅ Выявляет, было ли предупреждение о уязвимости или ошибке.

✅ Понимает, кто из участников давал указания на изменение кода.

✅ Фиксирует временные метки (что обсуждалось до и после спорной операции).

📌 Кейс из практики (переписка спасла от обвинения):

Разработчика обвиняли в том, что он намеренно внес уязвимость в код самоисполняемого контракта. На fedexpertiza.ru он предоставил переписку в мессенджере, где заказчик собственноручно написал: «Убери проверку на повторный вход, она замедляет работу, нам нужно быстро». Эксперт проанализировал код и переписку. Вывод: изменение было сделано по указанию заказчика, а не по злому умыслу разработчика. Дело против разработчика было прекращено.

🔌 Раздел 9. Информация из внешних источников (оффчейн-данные) и оракулов

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

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

📡 Логи оракулов — записи того, какие данные (цены, курсы, температура и т.д.) передавались в контракт и в какое время.

🌐 Логи вызовов внешних прикладных интерфейсов — если контракт запрашивал данные из внешних баз.

📊 Скриншоты внешних панелей управления (дашбордов).

Почему это важно:

Многие атаки происходят через манипуляцию оракулами (например, временное искажение цены).

Без логов оракула эксперт не сможет определить, по вине контракта или по вине оракула произошел сбой.

📌 Кейс из практики (оракул как источник проблемы):

*Самоисполняемый контракт децентрализованной биржи полагался на оракул, который передавал цену токена. В какой-то момент цена резко упала, и контракт принудительно ликвидировал позиции пользователей. Пользователи обвинили контракт в ошибке. Мы на fedexpertiza.ru запросили логи оракула. Оказалось, что оракул на 2 секунды передал цену, которая была в 100 раз ниже рыночной, потому что узел оракула был атакован. Контракт сработал корректно согласно полученным данным. Вина лежала на операторе оракула.*

📋 Раздел 10. Полный чек-лист документов для заказчика (шпаргалка)

Для удобства адвокатов и компаний мы на fedexpertiza.ru подготовили сводный список. ✅ Отметьте галочками то, что у вас есть, и направляйте нам.

Обязательный минимум (без этого экспертиза невозможна):

🔘 Исходный код самоисполняемого контракта (все версии).

🔘 Адрес (адреса) контракта в сети распределенного реестра.

🔘 Хеши хотя бы одной спорной транзакции.

🔘 Адрес кошелька заказчика (потерпевшего).

🔘 Краткое описание ситуации (что произошло, когда, на какую сумму).

Желательно (повышает качество и снижает сроки):

🔘 Белая книга и дорожная карта проекта.

🔘 Переписка сторон (электронная почта, чаты).

🔘 Логи оракулов или внешних прикладных интерфейсов.

🔘 Договоры и пользовательские соглашения.

🔘 Архитектурные схемы и техническое задание.

Если есть — дополнительно:

🔘 Результаты предыдущих аудитов (если проводились).

🔘 Данные о личностях разработчиков (если известны).

🔘 Снимки экранов интерфейса дэппа (децентрализованного приложения) до и после инцидента.

🧭 Раздел 11. Пошаговая инструкция: как собрать материалы и передать экспертам

Чтобы процесс сбора данных не превратился в хаос, следуйте этой простой схеме. 🕒

Шаг 1. Зафиксируйте инцидент (сразу после обнаружения проблемы)

Сделайте снимки экрана кошелька, контракта, интерфейса.

Запишите хеши транзакций (скопируйте в текстовый файл).

Не удаляйте историю браузера и кэш.

Шаг 2. Определите, кто владеет недостающими данными

Исходный код — у разработчика или в открытом репозитории.

Логи оракулов — у оператора оракула.

Переписка — у сторон спора.

Шаг 3. Сформулируйте вопросы к эксперту (письменно)

Вместо «разберитесь, что произошло» лучше: «Был ли вызван метод “вывести средства” с адреса истца без его подписи?».

Четкие вопросы ускоряют работу.

Шаг 4. Направьте пакет нам на fedexpertiza.ru через форму на сайте или по электронной почте

Мы подписываем договор о конфиденциальности (если требуется).

В течение 1-3 рабочих дней даем предварительную оценку и стоимость.

Шаг 5. При необходимости — дополнительный сбор

Если данных недостаточно, эксперт укажет, что именно нужно добрать.

По судебным делам — запросите данные через суд (если сторона отказывается предоставлять добровольно).

⚠️ Раздел 12. Распространенные ошибки при сборе исходных данных

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

📌 Кейс из практики (ошибка с тестовой сетью):

Адвокат предоставил нам на fedexpertiza.ru адрес контракта, утверждая, что это основная сеть. Эксперт начал анализ и не мог найти историю транзакций за указанный период. Оказалось, что контракт развернут в тестовой сети (сеть с «игрушечными» деньгами). Судебное дело касалось реальных убытков в основной сети. Адвокат перепутал. Экспертиза задержалась на 4 дня, пока адвокат не нашел правильный адрес в основной сети.

🎯 Резюме и итоговые выводы

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

🔎 Чем полнее пакет предоставленных данных, тем точнее, быстрее и дешевле будет экспертиза. Неполные данные — это риск неоднозначных выводов или отказа от дачи заключения.

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

📌 Формулируйте вопросы к эксперту письменно и конкретно. Это дисциплинирует процесс и ускоряет работу.

🏆 На fedexpertiza.ru мы помогаем заказчику определить, какие именно материалы нужны в его конкретном случае. Если чего-то не хватает — мы подскажем, где и как это можно получить.

🤝 Мы готовы помочь вам собрать правильный пакет данных и провести экспертизу

Не тратьте время на догадки — обратитесь к профессионалам. Мы на fedexpertiza.ru проведем бесплатную предварительную консультацию, поможем сформулировать вопросы и подскажем, какие документы необходимо предоставить для вашего конкретного дела.

🌐 Переходите на наш официальный сайт, чтобы оставить заявку или задать вопрос: fedexpertiza.ru