Покупатель запросил декларацию смарт-контракта по статье 36. Что оно должно охватывать?
Подключите запрос смарт-контракта Закона о данных ЕС к соглашению, средству развертывания, механизму прекращения действия, архивным доказательствам и декларации вместо того, чтобы рассматривать аудит кода как полный ответ.
Сигналы для наблюдения
- Проект по обмену данными называет статью 36 и спрашивает, кто будет выдавать декларацию соответствия ЕС.
- Развернутый смарт-контракт выполняет часть соглашения, но его расторжение, прерывание или архивные доказательства не имеют владельца.
- Покупатель запрашивает аудит кода, в то время как контроль доступа и управление остаются за пределами заявленного объема.
На запрос статьи 36 не дается ответ путем приложения общего аудита блокчейна. Согласно Закону ЕС о данных, первыми вопросами являются какое соглашение выполняет смарт-контракт, кто продает или профессионально развертывает его для другой стороны и где подтверждены четыре основные области требований. Ответственная сторона также должна провести оценку соответствия и выдать декларацию соответствия ЕС.
Это различие имеет значение для директора по продажам поставщика услуг по обеспечению смарт-контрактов или совместного использования данных, наблюдающего за авторизованными группами промышленного пространства данных, разработки блокчейнов и закупок Telegram. «Перед пилотным проектом необходим сертификат по статье 36», возможно, стоит пересмотреть, но он еще не идентифицирует приложение, соглашение, развертывание или отсутствие контроля. Однодневная задержка все равно может привести к потере проверки дизайна, при которой покупатель назначает этих владельцев.
Определение: Статья 36 связана с исполнением соглашения.
Регламент (ЕС) 2023/2854 называет статью 36 «Основными требованиями к смарт-контрактам для выполнения соглашений о совместном использовании данных». Он адресован поставщику приложения, использующего смарт-контракты, или лицу, чья торговля, бизнес или профессия предполагает развертывание смарт-контрактов для других в контексте выполнения соглашения или его части.
Таким образом, юридический крючок заключается не в наличии метки блокчейна. Контракт токена, внутренний прототип или несвязанное децентрализованное приложение не могут быть помещены в статью 36 только потому, что их код неизменяем. Рецензенту необходимо соглашение, функция, которую код выполняет внутри него, и сторона, выступающая в качестве поставщика или профессионального развертывателя.
Именно поэтому фраза «это написал разработчик» не является достаточным ответом на право собственности. Автор разработки, поставщик приложения, системный интегратор и сторона, выполняющая развертывание для другой организации, могут быть разными лицами.
Объедините четыре записи, прежде чем определить объем работы
Используйте одно примечание о применимости с четырьмя связанными записями:
- Запись соглашения: стороны, цель обмена данными, выполняемый пункт или рабочий процесс, определяющая версия и дата производства.
- Запись о развертывании: Поставщик приложений, профессиональный разработчик, оператор, репозиторий кода и развернутый адрес или другой уникальный идентификатор экземпляра.
- Контрольная запись: доказательства надежности, контроля доступа, прекращения или прерывания, архивирования и непрерывности.
- Запись декларации: Владелец оценки соответствия, оцененная версия, используемые стандарты или спецификации, декларация соответствия ЕС и история изменений.
Примечание является оригинальным вкладом этой статьи. Это превращает неопределенную фразу о соответствии в объединение, которое можно проверить, не притворяясь, что обсуждение Telegram представляет собой полное юридическое описание. TOP Prospect может помочь выявить фрагменты, составляющие эту заметку; он не может завершить или утвердить его. Если запись соглашения невозможно присоединить к развернутой версии, в уточненном отчете аудита может описываться другой код.
Четыре области требований связаны, но не взаимозаменяемы.
Статья 36 определяет четыре основные области.
Надежность и контроль доступа. Смарт-контракт должен предлагать механизмы контроля доступа и очень высокую степень надежности, чтобы избежать функциональных ошибок и противостоять манипуляциям со стороны третьих лиц. Доказательства могут включать модель угроз, результаты тестирования, определения ролей и развернутую конфигурацию. Отчет о безопасности полезен только в том случае, если его версия соответствует приложению и экземпляру в записи развертывания.
Безопасное завершение и прерывание. Должен существовать механизм прекращения продолжающегося выполнения транзакций. Смарт-контракт должен включать внутренние функции, способные сбросить его или дать указание остановить или прервать операции, особенно во избежание случайного выполнения в будущем. Важный вопрос продаж не в том, «Есть ли у него кнопка паузы?» Это то, кто может вызвать какое действие, при каких условиях, с каким зарегистрированным одобрением и влиянием на ожидающие транзакции.
Архивирование и непрерывность данных. Если смарт-контракт должен быть расторгнут или деактивирован, его конструкция должна позволять архивировать данные транзакций, их логику и код, чтобы прошлые операции с данными оставались проверяемыми. Только в моментальном снимке репозитория могут отсутствовать развернутые параметры, созданные события или версия соглашения.
Контроль доступа на более чем одном уровне. Статья 36 также призывает к строгим механизмам контроля доступа на уровнях управления и смарт-контрактов. Проверка роли на функциональном уровне не дает ответа на вопрос, кто утверждает назначение ролей, экстренные действия или обновление производства.
Пример: аудит охватывает код, но не присоединение к соглашению.
Представьте себе, что эти неполные сообщения приходят перед проверкой проекта; они носят иллюстративный характер, а не свидетельство клиента:
“Пилотный порт данных будет запущен в следующем месяце. Отдел закупок требует декларации по статье 36”.
“Аудит выполнен на версии 1.8. Роль паузы, я думаю, принадлежит интегратору. Приложение к соглашению все еще обновляется”.
Сообщения содержат дату пилотного проекта, версию кода, возможного держателя роли паузы и незавершенное приложение к соглашению. Они не идентифицируют производственный экземпляр, условие выполнения, поставщика или профессионального развертывателя, одобрение руководства, маршрут архивирования, владельца оценки или декларацию.
В примечании о применимости будут показаны три соединения красного цвета:
- в аудите указано v1.8, но производственная версия и адрес неизвестны;
- роль паузы может принадлежать интегратору, но полномочия и доказательства одобрения неизвестны; и
- приложение к соглашению меняется, поэтому функция, которую выполняет смарт-контракт, еще не стабильна.
Это заслуживающая доверия дискуссия о гарантиях. Это не является доказательством того, что система соответствует требованиям, и не является обещанием, что еще один тест на проникновение завершит декларацию.
Для объявления нужен ограниченный объект
Статья 36 требует, чтобы ответственный поставщик или разработчик провел оценку соответствия и выдал декларацию соответствия ЕС. Официальный текст также предусматривает презумпцию соответствия при соблюдении соответствующих гармонизированных стандартов или их частей.
Для провайдера гарантий коммерческая граница должна называть оцениваемый объект: приложение, версию смарт-контракта, развернутую конфигурацию, функцию соглашения и набор элементов управления. Он также должен определять, что происходит после изменения кода, роли, конечной точки или соглашения. Без этой границы фраза «Статья 36 готова» не является воспроизводимым утверждением.
Декларация не является чем-то, что инструмент мониторинга может создать в результате общественного обсуждения. Внешний аудит также не передает автоматически ответственность ответственной стороне по определению объема и выдаче декларации.
Обнаружение может обнаружить недостающее соединение, а не определить соответствие
Продукт может фильтровать и объединять фрагменты из групп Telegram, которые пользователь намеренно подключает и имеет к ним доступ. Он может сохранять исходные сообщения, источники и время; сгруппировать именованное соглашение, развернутую версию, механизм остановки и запрос объявления; удалить очевидные дубликаты; и ранжируйте результат для проверки человеком.
Он не может проверять частные репозитории, тестировать смарт-контракт, решать, применима ли статья 36, контролировать прекращение действия, выполнять оценку соответствия, выдавать декларации или связываться с членами группы. Цены и варианты доступа охватывает только уровень обнаружения.
Правила доступа к соседним подключенным продуктам см. в документе Руководство по доказательствам по статьям 4 и 5. Для обсуждения переключения облачных сервисов используйте отдельный Статья о сигнале переключения Data Act.
Ключевые факты
- Статья 36 содержится в Регламенте (ЕС) 2023/2854, Законе ЕС о данных.
- Его предметом являются смарт-контракты, используемые для выполнения соглашения об обмене данными или его части, а не каждый контракт, имеющий метку блокчейна.
- Адресуемый субъект — это поставщик приложений, использующий смарт-контракты, или профессиональный разработчик, действующий от имени других в соответствующем контексте.
- Четырьмя областями доказательств являются надежность и контроль доступа, безопасное завершение и прерывание, архивирование и непрерывность данных, а также строгий контроль доступа на уровнях управления и смарт-контрактов.
- Архивные доказательства могут включать в себя данные транзакций, логику смарт-контрактов и код, необходимый для сохранения возможности аудита прошлых операций.
- Ответственная сторона должна провести оценку соответствия и выдать декларацию соответствия ЕС.
- Аудит кода может подтвердить запись, но сам по себе не устанавливает применимость или соответствие.
FAQ
Применяется ли статья 36 к каждому токену блокчейна или смарт-контракту?
Нет. Статья 36 касается поставщика приложения, использующего смарт-контракты, или лица, использующего смарт-контракты для других в профессиональном качестве, в контексте выполнения соглашения или его части. До определения объема необходимо определить соглашение и роль развертывания.
Является ли тест на проникновение или аудит кода тем же, что и соответствие статье 36?
Нет. Технические испытания могут подтверждать доказательства, но статья 36 также охватывает контроль доступа, безопасное завершение и прерывание, архивирование и непрерывность данных, а также оценку соответствия декларации соответствия ЕС.
Что следует архивировать, если смарт-контракт расторгнут?
Статья 36 предусматривает возможность архивирования транзакционных данных, логики смарт-контракта и кода, чтобы записи прошлых операций с данными оставались доступными для проверки.
Кто принимает окончательное юридическое решение и решение о соответствии?
Ответственный поставщик или профессиональный разработчик и его консультанты должны определить применимость, выполнить необходимую работу по обеспечению соответствия и выдать декларацию. Платформа обнаружения может только выявить и систематизировать доказательства запроса.
Прежде чем устанавливать цену на аудит, убедитесь, что соглашение, развернутый объект, контрольные доказательства и декларация относятся к одной и той же реализации.
Часто задаваемые вопросы
Применяется ли статья 36 к каждому токену блокчейна или смарт-контракту?
Нет. Статья 36 касается поставщика приложения, использующего смарт-контракты, или лица, использующего смарт-контракты для других в профессиональном качестве, в контексте выполнения соглашения или его части. До определения объема необходимо определить соглашение и роль развертывания.
Является ли тест на проникновение или аудит кода тем же, что и соответствие статье 36?
Нет. Технические испытания могут подтверждать доказательства, но статья 36 также охватывает контроль доступа, безопасное завершение и прерывание, архивирование и непрерывность данных, а также оценку соответствия декларации соответствия ЕС.
Что следует архивировать, если смарт-контракт расторгнут?
Статья 36 предусматривает возможность архивирования транзакционных данных, логики смарт-контракта и кода, чтобы записи прошлых операций с данными оставались доступными для проверки.
Кто принимает окончательное юридическое решение и решение о соответствии?
Ответственный поставщик или профессиональный разработчик и его консультанты должны определить применимость, выполнить необходимую работу по обеспечению соответствия и выдать декларацию. Платформа обнаружения может только выявить и систематизировать доказательства запроса.
Источники и дополнительное чтение
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
