Интероперабельность

С экосистемой Ethereum

Токен A-REX Core является токеном ERC-1155. Кошельки, обозреватели блоков, торговые площадки и индексаторы, понимающие ERC-1155, работают без изменений: балансы, пакетные переводы, uri(id), одобрения, проверки получателя при безопасных переводах. A-REX добавляет события и view-функции; ничего не удаляя.

Токен A-REX Core является мультитокеном ERC-7943. Движки комплаенса и платформы хранения активов, ориентированные на ERC-7943 (Chainlink Automated Compliance Engine продемонстрировал совместимость; платформы выпуска из коалиции ERC-7943 внедряют его), распознают canTransfer, forcedTransfer, setFrozenTokens, canSend и canReceive без адаптации.

Со стандартами данных прослеживаемости

GS1 EPCIS 2.0 / CBV

Стандарт публикует информативное сопоставление, событие за событием:

Схема метаданных намеренно использует имена EPCIS/CBV, чтобы экспортёру приходилось сопоставлять поля, а не понятия.

Показания датчиков не входят в ядро. Хук доставки может записать температуру в блокчейн; остальные измерения (влажность, CO₂ и O₂, удар, наклон, дверь, положение) остаются вне блокчейна в том же sensorElementList, со своим типом CBV и единицей по Rec. 20. Сопоставление описывает шаблон фиксации обязательства по ним: для каждого временного окна — худшее показание температуры со ссылкой, которая является корнем по всем показаниям окна и исходным сообщениям, из которых они получены, чтобы аудитор мог сверить показание с блокчейном. Обязательство доказывает, что было у записавшего на момент этого блока, но не то, что устройство измерило верно. Точки считывания и места деятельности — это идентификаторы площадок, никогда не координаты.

UN Transparency Protocol (UNTP 0.7.0)

Информативное сопоставление превращает партию, её события и аттестации в учётные данные UNTP 0.7.0 с теми же идентификаторами, что и в сопоставлении с EPCIS, чтобы их можно было связать:

Учётные данные соответствуют модели данных W3C Verifiable Credentials 2.0 и подписываются по VC-JOSE-COSE под did:web эмитента; отзыв использует Bitstring Status List. Подписанные учётные данные можно также привязать к партии как аттестацию, ссылкой в которой служит хеш учётных данных: привязка доказывает коммитмент, подпись доказывает содержимое. Учётные данные содержат только то, что хранят токен или его метаданные, а значения, для которых нужна методика (углеродный след, оценка риска), появляются лишь тогда, когда их задекларировала названная сторона. Сопоставление прямо указывает, чего оно не охватывает, и прежде всего это цифровой паспорт продукта ЕС: ESPR не применяется к продуктам питания, кормам, живым растениям и животным, и A-REX не делает в отношении них заявлений о паспорте.

Место производства товара указывается кодами: страна (ISO 3166-1), административная единица первого уровня (ISO 3166-2, например BR-MG) и UN/LOCODE населённого пункта только для деловой площадки, такой как склад или порт, но никогда для фермы. Показания датчиков помещаются в sensorData события MoveEvent доставки; паспорт содержит не более чем сводку. Начиная со схемы метаданных 1.3.0 (ADR-024, Предложено), origin.region всегда является таким кодом.

Задекларированный углеродный след (PACT 3.0.3)

ADR-018 (Предложено) позволяет партии нести углеродный след продукта, рассчитанный третьей стороной, в extensions.pact_pcf документа метаданных. Фрагмент поле за полем следует WBCSD PACT Technical Specifications 3.0.3: кто задекларировал след, задекларированная единица и отчётный период, след с учётом и без учёта биогенного поглощения, а также обязательный статус верификации, в котором указан верификатор, если след верифицирован. След копируется, но никогда не рассчитывается, не суммируется и не передаётся партиям, изготовленным из лота, и он не является углеродным кредитом (ADR-014). Сопоставление — это отдельная производная работа на основе PACT, и оно не копирует ни одного файла PACT.

Коды товаров и единиц измерения

Код товара — это keccak256("<SCHEME>:<CODE>") для любой схемы: Гармонизированной системы (HS), национальных тарифных номенклатур (NCM в Меркосуре, CN и TARIC в ЕС, HTS в США и других), FAO, CPC, GTIN или собственной схемы эмитента. Начиная со схемы метаданных 1.1.0 схема в документе тоже открыта, поэтому метаданные могут повторять ончейн-код. Единицы измерения — это коды Рекомендации UN/CEFACT 20 (KGM, TNE, LTR), то есть перечень, который уже используют EDI, EPCIS и таможня.

FSMA 204

Ключевые элементы данных — это поля метаданных (traceabilityLotCode, GLN, даты, количества) и события; CTE «преобразование» — это BatchTransformed; запрос записей в течение 24 часов — это запрос к индексатору. Полное соответствие приведено в регуляторной главе.

Codex, ISO 22000, GLOBALG.A.P., схемы органической продукции

Все они — темы аттестаций. Стандарт их не перечисляет: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") — соглашения, которые эмитент публикует вместе со своей схемой метаданных.

С реестрами юридических документов

Токены A-REX ссылаются на правовые инструменты; они не заменяют их, пока юрисдикция не признает сам токен:

С системами идентичности

Токен задаёт только вопросы canSend(account) / canReceive(account). За этим вопросом может стоять:

• список разрешённых и заблокированных адресов, который ведёт эмитент (EligibilityHook);
• реестр идентичности ONCHAINID с темами утверждений (модель ERC-3643);
• аттестации Ethereum Attestation Service в отношении аккаунта;
• верифицируемые учётные данные, проверяемые офчейн и отражаемые ончейн ретранслятором;
• национальная схема e-ID (кошелёк eIDAS 2.0 в ЕС) через верификатор учётных данных.

Ничто из этого не входит в стандарт, поэтому эмитент в Бразилии и эмитент в Германии могут использовать разных поставщиков и оставаться интероперабельными.

С движками правил и платформами

Правило или дополнение может опубликовать дескриптор arex.module/1: JSON-документ с его параметрами, настройками, обязательными полями партии, типами сертификатов, событиями, кодами отказа и описанием того, как его состояние переносится в новую версию. Платформа, кошелёк, индексатор или аудитор, читающие дескрипторы, интегрируют новое правило без специального кода. Формат информативен и имеет статус «Предложено»; он станет рекомендуемым, когда его начнёт использовать второй независимый разработчик реализации. Редакция 1.1 добавляет необязательный информационный список ops с операциями, которыми управляет правило; его отсутствие означает, что они неизвестны, и он никогда не используется для принуждения к правилам. Редакция 1.2 добавляет тип места ref:site (originRef, который несут его партии, но никогда не местоположение) и указывает, что заявленный газ измеряется с заполненными настройками (необязательный gas.setup). Ревизия 1.3 документирует поля, которые её первый потребитель уже записывает (действия, собственные ошибки контракта, показатели, данные по поставке и полную форму событий); все они необязательны. Ревизия 1.4 добавляет то, что нужно платформе для построения форм дополнений: новые типы значений, что попадает в реестр (никогда персональные данные), представление и проверки для каждого поля, представления только для чтения и отображение записи в EPCIS и паспорте UNTP (характеристика, заявленная её организацией, никогда не утверждение о соответствии). Редакция 1.5 добавляет соль к каждому отпечатку: дескриптор, объявляющий fingerprint: { "scheme": "salted-jcs/1" }, записывает хеш каждого значения вместе с собственной 32-байтовой солью, поэтому короткие тексты, числа или контуры участков нельзя подобрать перебором. Ревизия 1.6 добавляет показатели, которые не являются суммами (avg, min, max числового поля, никогда не суммируются между группами или компаниями), и две группировки: по стороне, создавшей партию (party), и по её площадке (site); шаблон дополнения влажности в эталонном релизе 2.0.0-alpha.10 использует её для средней влажности при приёмке. Редакция 1.7 позволяет visibleWhen поля использовать дерево условий дескриптора словаря (all, any, not; не более 3 уровней и 12 листьев) над другими полями формы; одиночное условие редакции 1.4 остаётся допустимым, но устаревшим.

Организации могут публиковать собственные виды полевых работ, виды процессов и списки этапов в виде словарных определений arex.vocab/1. Каждое определение сопоставлено с одним из 26 эталонных классов этапов (например, drying или fermenting) и с бизнес-шагом GS1 CBV. Их события EPCIS содержат три уровня: CBV bizStep, который читает любая система EPCIS; эталонный класс (arex:stageClass), позволяющий двум организациям с разными названиями сравнивать свои записи; и собственный тип, названия и опубликованные значения организации. В паспорте UNTP значения являются характеристиками, а не заявлениями. Метаданные переработанной партии могут называть вид процесса и запуск, стоящие за ней, в объекте process, который планируется включить в схему метаданных 1.4.0. Редакция 1.1 добавляет необязательную раскладку формы (разделы, ширина, условия), которая лишь сужает то, что принимают поля. Редакция 1.2 позволяет условиям использовать not, иметь до 3 уровней и до 12 листьев и читать контекст записи в кодах (культура как код EPPO, дни с посадки, вид площадки, страна, позиция HS продукта, последний этап); неизвестный контекст читается как пустой. Редакция 1.3 добавляет порядок списка этапов (order): strict (по умолчанию; обязательный предыдущий этап должен быть записан первым) или flexible (любой порядок, пропуски остаются отчётам). Редакция 1.4 добавляет методы обработки кофе (washed, natural, honey, pulped_natural, wet_hulled, anaerobic и другие), которые тип процесса присваивает своим выходам и которые несут метаданные process партии: заявление организации, а не сертификация. Редакция 1.5 добавляет подклассы широких классов (separating, conditioning, sorting_grading, heat_treating) из закрытого списка, так что читатель сопоставляет этап другой организации из широкого класса только по его подклассу или по явному сопоставлению для каждого отправителя. Ревизия 1.6 добавляет to_processor, подкласс transporting: товар, отправленный переработчику, который обрабатывает его для владельца (давальческая переработка), так что меняется владение, но не право собственности. Метки в реестре, ссылки на этапы и субъекты-площадки снабжены солью, поэтому ни ход процесса, ни хронологию хозяйства нельзя прочитать из реестра, а денежные суммы никогда не записываются в реестр в открытом виде. Этап упаковки или погрузки, записанный с логистической единицей (SSCC, номер контейнера), сопоставляется с AggregationEvent EPCIS. В эталонном релизе 2.0.0-alpha.9 CompanyFactsHook записывает такие записи в реестр, а RequireStageHook отклоняет поставки партий, у которых нет обязательных этапов; ни один из этих модулей не обязателен. Всё это носит информативный характер и имеет статус «Предложено».

Кроссчейн-развёртывание

A-REX Core — стандарт для EVM (ADR-026, Предложено): соответствующий токен работает в любой сети EVM уровня paris или новее, а сам стандарт не ведёт списка сетей; какие сети может использовать организация, определяет её профиль политик. Сети обозначаются идентификаторами CAIP-2, например eip155:8453 или hedera:mainnet. Практические шаблоны:

• Одна домашняя сеть на эмитента (рекомендуется): родословная и принудительное исполнение остаются согласованными; другие сети держат обёрнутые представления через адаптеры в стиле ERC-7802 или CCIP.
• Сеть EVM с разрешительным доступом для эмитентов, которым это требуется по указанию органа по защите данных или якорного учреждения; EDPB прямо отдаёт предпочтение архитектурам с разрешительным доступом. Тот же байткод.
• Зеркала для ликвидности: идентификатор партии в домашней сети, обёртка ERC-20 в другой; обёртка должна соблюдать canTransfer домашнего токена либо ограничиваться допущенными держателями.

Родословная никогда не пересекает границы сетей; ссылки — пересекают. Между токенами в одной сети или в разных сетях партия, изготовленная из партии другого токена, указывает её в списке upstream своих метаданных (схема 1.2.0) по идентификатору сети, контракту и идентификатору токена. Эти ссылки — утверждения эмитента, которые следует сверять с исходным токеном. Начиная со схемы 1.4.0 (Предложено), запись может также указывать сеть CAIP-2 (network), а партия, учтённая в сети без EVM, обозначается своей сетью и своим активом CAIP-19.

Записи, которые может проверить каждый, в любой сети

Доказательства вокруг токена не зависят от сети, в которой он работает. Раз в период эмитент может объединить отпечатки своих записей (журнал аудита, отчёты, документы) в один корень Меркла и опубликовать эти 32 байта в нескольких независимых сетях: в своей сети EVM, в Bitcoin через OpenTimestamps и в Hedera Consensus Service. Каждая запись получает короткое доказательство arex.anchor-proof/1. Любой, у кого есть запись и её доказательство, может без каких-либо сервисов A-REX проверить, что запись существовала в неизменном виде не позднее момента, когда каждая сеть получила корень; контракт EVM может проверить то же доказательство с помощью MerkleProof от OpenZeppelin. Публикуются только хеши, никогда не персональные данные. Формат информативный, статус: Предложено (ADR-026). В каких сетях эмитент выполняет привязку, решает политика, заданная его профилем юрисдикции или организации, а доказательство действительно при любом числе квитанций. Квитанция Hedera указывает идентификатор своей транзакции при отправке корня и получает порядковый номер и время консенсуса сообщения, как только его подтверждает публичный зеркальный узел.

Откуда берутся числа подписанного отчёта

Отчёт, рассчитанный по записям эмитента, например «1 200 кг поставлено одному покупателю в октябре» или список записей, может нести свои источники: по одной строке на каждую прочитанную запись, с указанием того, где реестр хранит эту запись, и значений, которые использовал отчёт. Каждая строка — источник arex.report-sources/1; его лист — keccak256(0x03 ‖ JCS(source)), а отсортированные листья попарно объединяются в один корень источников. Корень и SHA-256 файла источников (<report>.sources.csv) запечатываются вместе с отчётом, в его подписанном манифесте или под подписью PDF, поэтому позже ни одну строку нельзя добавить, удалить или изменить. Отчёт сообщает, сколько его записей проверяется по реестру, сколько — через отпечаток в реестре (дневной якорь или окно показаний) и сколько являются лишь записями эмитента, покрытыми его печатью. Источник никогда не содержит персональное значение в открытом виде. Читатель проверяет всё это без каких-либо сервисов A-REX: verify-sources.mjs, самостоятельная программа проверки (Node.js 20, ничего не нужно устанавливать), которую может поставлять любая реализация, заново вычисляет каждый лист и корень, сравнивает их с отчётом, а затем читает каждую запись реестра с любого узла её сети. Отчёт с несколькими карточками сохраняет один файл источников и один корень; каждая строка называет свою карточку в необязательном поле section (редакция 1.1), поэтому числа каждой карточки складываются отдельно.

node verify-sources.mjs report.csv.sources.csv --manifest report.csv.manifest.json --rpc https://<a node of the network>

Формат информативный, статус: Предложено (редакция 1.1 источников отчётов). Документ стандарта, который предоставляется в рамках раннего доступа, приводит столбцы файла, каждую проверку и пример вектора; схема описывает один источник.

С системами управления фермами и ERP

Точки интеграции те же, что и для любого токена ERC-1155, плюс view-функции партий:

• Путь записи: сервис первичного оформления держит ISSUER_ROLE и вызывает createBatch по событиям ERP (весовая квитанция, выдача расписки); setBatchStatus/setBatchMetadata — по складским событиям; transform — по заказам на переработку.
• Путь чтения: индексатор материализует партии, родословную, аттестации и события принудительного исполнения в таблицах прослеживаемости ERP; экспорт EPCIS для партнёров и регуляторов.
• Предварительная проверка: transferCheck позволяет ERP объяснить оператору отказ до отправки транзакции.
• Идентификаторы: ключи GS1 в метаданных связывают с существующими репозиториями EDI и EPCIS; единицы UN/CEFACT уже есть в ERP.

Матрица совместимости