Interoperabilität

Mit dem Ethereum-Ökosystem

Ein A-REX-Core-Token ist ein ERC-1155-Token. Wallets, Explorer, Marktplätze und Indexer, die ERC-1155 verstehen, funktionieren unverändert: Salden, Sammeltransfers, uri(id), Freigaben, Empfängerprüfungen bei sicheren Transfers. A-REX ergänzt Ereignisse und Views; es entfernt nichts.

Ein A-REX-Core-Token ist ein ERC-7943-Multi-Token. Compliance-Engines und Verwahrungsplattformen, die auf ERC-7943 abzielen (die Automated Compliance Engine von Chainlink hat die Kompatibilität demonstriert; Ausgabeplattformen der ERC-7943-Koalition übernehmen ihn), erkennen canTransfer, forcedTransfer, setFrozenTokens, canSend und canReceive ohne Anpassung.

Mit Datenstandards für die Rückverfolgbarkeit

GS1 EPCIS 2.0 / CBV

Der Standard veröffentlicht eine informative Abbildung, Ereignis für Ereignis:

Das Metadatenschema verwendet absichtlich die Namen aus EPCIS/CBV, damit ein Exporter Felder abbildet und nicht Konzepte.

Sensormesswerte gehören nicht zum Kern. Ein Liefer-Hook kann eine Temperatur on-chain aufzeichnen; andere Messungen (Luftfeuchte, CO₂ und O₂, Stoß, Neigung, Tür, Position) bleiben off-chain in derselben sensorElementList, mit ihrem CBV-Typ und ihrer Einheit nach Rec. 20. Die Abbildung beschreibt ein Muster, um sich auf sie festzulegen: pro Zeitfenster der ungünstigste Temperaturwert mit einer Referenz, die eine Wurzel über jeden Messwert des Fensters und die ursprüngliche Nachricht ist, aus der er stammt, sodass ein Prüfer einen Messwert gegen die Chain prüfen kann. Die Festlegung beweist, was der Aufzeichnende in diesem Block hatte, nicht, dass das Gerät richtig gemessen hat. Lesepunkte und Geschäftsorte sind Standortkennungen, niemals Koordinaten.

UN Transparency Protocol (UNTP 0.7.0)

Eine informative Abbildung überführt eine Charge, ihre Ereignisse und ihre Attestierungen in Credentials nach UNTP 0.7.0, mit denselben Kennungen wie die EPCIS-Abbildung, sodass sich beide verknüpfen lassen:

Credentials folgen dem W3C Verifiable Credentials Data Model 2.0 und werden mit VC-JOSE-COSE unter dem did:web des Ausstellers signiert; der Widerruf nutzt eine Bitstring Status List. Ein signiertes Credential lässt sich zusätzlich als Attestierung an seiner Charge verankern, deren Referenz der Hash des Credentials ist; der Anker beweist die Festlegung, die Signatur den Inhalt. Ein Credential enthält nur, was der Token oder seine Metadaten enthalten, und Werte, die eine Methode erfordern (ein Fußabdruck, eine Risikobewertung), erscheinen nur, wenn eine benannte Partei sie deklariert hat. Die Abbildung nennt, was sie nicht abdeckt, angefangen beim Digitalen Produktpass der EU: Die ESPR gilt nicht für Lebensmittel, Futtermittel oder lebende Pflanzen und Tiere, und A-REX macht für sie keine Aussage zum Produktpass.

Wo die Waren erzeugt wurden, wird als Codes angegeben: das Land (ISO 3166-1), die Untergliederung der ersten Ebene (ISO 3166-2, zum Beispiel BR-MG) und der UN/LOCODE eines Ortes nur für einen Geschäftsstandort wie ein Lager oder einen Hafen, nie für einen Betrieb. Sensormesswerte stehen im sensorData des MoveEvent der Lieferung; ein Pass trägt höchstens eine Zusammenfassung. Ab Metadatenschema 1.3.0 (ADR-024, Vorgeschlagen) ist origin.region immer ein solcher Code.

Deklarierte CO₂-Fußabdrücke (PACT 3.0.3)

ADR-018 (Vorgeschlagen) erlaubt einer Charge, unter extensions.pact_pcf des Metadatendokuments einen Produkt-CO₂-Fußabdruck zu tragen, den ein Dritter berechnet hat. Das Fragment folgt den WBCSD PACT Technical Specifications 3.0.3 Feld für Feld: wer ihn deklariert hat, die deklarierte Einheit und der Bezugszeitraum, der Fußabdruck mit und ohne biogene Aufnahme sowie ein verpflichtender Verifizierungsstatus, der bei einem verifizierten Fußabdruck den Verifizierer nennt. Er wird übernommen, nie berechnet, summiert oder an die aus der Charge hergestellten Chargen weitergegeben, und er ist keine Kohlenstoffgutschrift (ADR-014). Die Abbildung ist ein eigenständiges Derivat von PACT und kopiert keine PACT-Datei.

Rohstoff- und Einheitencodes

Ein Rohstoffcode ist keccak256("<SCHEME>:<CODE>") für jedes Schema: das Harmonisierte System (HS), nationale Zolltarifnomenklaturen (NCM im Mercosur, CN und TARIC in der EU, HTS in den Vereinigten Staaten und weitere), FAO, CPC, GTIN oder ein eigenes Schema des Ausstellers. Seit dem Metadatenschema 1.1.0 ist auch das Schema im Dokument offen, sodass die Metadaten den On-Chain-Code spiegeln können. Einheiten sind Codes der UN/CEFACT-Empfehlung 20 (KGM, TNE, LTR), die Liste, die EDI, EPCIS und Zoll bereits verwenden.

FSMA 204

Schlüsseldatenelemente sind Metadatenfelder (traceabilityLotCode, GLN, Daten, Mengen) und Ereignisse; das Transformations-CTE ist BatchTransformed; die Anforderung, Aufzeichnungen binnen 24 Stunden vorzulegen, ist eine Indexer-Abfrage. Die vollständige Zuordnung steht im Kapitel zur regulatorischen Compliance.

Codex, ISO 22000, GLOBALG.A.P., Bio-Schemata

Alle sind Attestierungsthemen. Der Standard zählt sie nicht auf: keccak256("GLOBALGAP:IFA"), keccak256("AREX:CERT:ORGANIC_EU"), keccak256("CODEX:MRL") sind Konventionen, die der Aussteller mit seinem Metadatenschema veröffentlicht.

Mit Registern für Rechtsdokumente

A-REX-Token referenzieren Rechtsinstrumente; sie ersetzen sie nicht, bis eine Rechtsordnung den Token selbst anerkennt:

Mit Identitätssystemen

Der Token stellt nur die Fragen canSend(account) / canReceive(account). Hinter dieser Frage können stehen:

• eine vom Aussteller geführte Zulassungs-/Sperrliste (EligibilityHook);
• ein ONCHAINID-Identitätsregister mit Claim-Themen (das ERC-3643-Modell);
• Attestierungen des Ethereum Attestation Service zum Konto;
• Verifiable Credentials, die Off-Chain geprüft und von einem Relayer On-Chain abgebildet werden;
• ein nationales eID-System (eIDAS-2.0-Wallet in der EU) über einen Credential-Verifizierer.

Keines davon ist Teil des Standards; deshalb können ein Aussteller in Brasilien und einer in Deutschland unterschiedliche Anbieter nutzen und dennoch interoperabel bleiben.

Mit Regel-Engines und Plattformen

Eine Regel oder ein Add-on kann einen Deskriptor arex.module/1 veröffentlichen: ein JSON-Dokument mit ihren Parametern, Einstellungen, erforderlichen Chargenfeldern, Zertifikatstypen, Ereignissen, Ablehnungscodes und der Angabe, wie ihr Zustand in eine neue Version übergeht. Eine Plattform, eine Wallet, ein Indexer oder ein Auditor, der Deskriptoren liest, bindet eine neue Regel ohne eigens geschriebenen Code ein. Das Format ist informativ und hat den Status Vorgeschlagen; es wird zu einem empfohlenen Format, sobald ein zweiter unabhängiger Implementierer es nutzt. Revision 1.1 ergänzt eine optionale, informative Liste ops der Operationen, die eine Regel steuert; fehlt sie, sind sie unbekannt, und sie wird nie zur Durchsetzung verwendet. Revision 1.2 ergänzt den Ortstyp ref:site (die originRef, die seine Chargen tragen, nie ein Standort) und legt fest, dass das deklarierte Gas mit gefüllten Einstellungen gemessen wird (optional gas.setup). Revision 1.3 dokumentiert die Felder, die ihr erster Nutzer bereits schreibt (Aktionen, eigene Fehler des Vertrags, Kennzahlen, Angaben je Lieferung und eine vollständige Form der Ereignisse), alle optional. Revision 1.4 ergänzt, was eine Plattform braucht, um Formulare für Add-ons zu bauen: weitere Werttypen, was ins Register gelangt (nie personenbezogene Daten), Darstellung und Prüfungen je Feld, schreibgeschützte Ansichten und wie ein Eintrag auf EPCIS und einen UNTP-Pass abgebildet wird (ein von seiner Organisation erklärtes Merkmal, nie eine Aussage über Konformität). Revision 1.5 versieht jeden Fingerabdruck mit Salt: Ein Deskriptor, der fingerprint: { "scheme": "salted-jcs/1" } angibt, speichert den Hash jedes Werts zusammen mit einem eigenen 32-Byte-Salt, sodass kurze Texte, Zahlen oder Flurstücksumrisse nicht durch Ausprobieren gefunden werden können. Revision 1.6 ergänzt Kennzahlen, die keine Summen sind (avg, min, max eines Zahlenfelds, nie über Gruppen oder Unternehmen hinweg addiert), und zwei Gruppierungen, nach der Partei, die die Charge angelegt hat (party), und nach ihrem Standort (site); die Vorlage des Feuchte-Add-ons in Referenz-Release 2.0.0-alpha.10 nutzt sie für die durchschnittliche Feuchte bei der Annahme. Revision 1.7 lässt das visibleWhen eines Felds den Bedingungsbaum des Vokabular-Deskriptors (all, any, not; höchstens 3 Ebenen und 12 Blätter) über die anderen Felder des Formulars verwenden; die einzelne Bedingung aus Revision 1.4 bleibt gültig, ist aber veraltet.

Organisationen können ihre eigenen Arten von Feldarbeit, Prozessarten und Stufenlisten als arex.vocab/1-Vokabulardefinitionen veröffentlichen. Jede ist einer von 26 Referenzstufenklassen (zum Beispiel drying oder fermenting) und einem GS1-CBV-Geschäftsschritt zugeordnet. Ihre EPCIS-Ereignisse tragen drei Ebenen: den CBV-bizStep, den jedes EPCIS-System liest, die Referenzklasse (arex:stageClass), mit der zwei Organisationen mit unterschiedlichen Namen ihre Einträge vergleichen können, und den eigenen Typ, die Namen und die veröffentlichten Werte der Organisation. In einem UNTP-Pass sind die Werte Merkmale, niemals Aussagen. Die Metadaten eines verarbeiteten Loses können die Prozessart und den Durchlauf dahinter in einem process-Objekt nennen, das für das Metadatenschema 1.4.0 vorgesehen ist. Revision 1.1 ergänzt ein optionales Formularlayout (Abschnitte, Breiten, Bedingungen), das nur einschränkt, was die Felder annehmen. Revision 1.2 erlaubt in Bedingungen not, bis zu 3 Ebenen mit bis zu 12 Blättern und das Lesen des Kontexts des Datensatzes in Codes (die Kultur als EPPO-Code, Tage seit der Pflanzung, Art des Standorts, Land, HS-Position des Produkts, letzte Stufe); unbekannter Kontext gilt als leer. Revision 1.3 ergänzt die Reihenfolge einer Stufenliste (order): strict (Vorgabe; eine erforderliche frühere Stufe muss zuerst erfasst sein) oder flexible (beliebige Reihenfolge, Lücken bleiben den Berichten). Revision 1.4 ergänzt Kaffee-Aufbereitungsmethoden (washed, natural, honey, pulped_natural, wet_hulled, anaerobic und weitere), die ein Prozesstyp seinen Ergebnissen gibt und die process-Metadaten einer Charge tragen: eine Erklärung der Organisation, keine Zertifizierung. Revision 1.5 ergänzt Unterklassen der breiten Klassen (separating, conditioning, sorting_grading, heat_treating) aus einer geschlossenen Liste, sodass ein Leser den Schritt einer anderen Organisation in einer breiten Klasse nur über seine Unterklasse oder eine ausdrückliche Zuordnung je Absender zuordnet. Revision 1.6 ergänzt to_processor, eine Unterklasse von transporting: Ware, die an einen Verarbeiter geht, der sie für ihren Eigentümer bearbeitet (Lohnverarbeitung), sodass der Besitz wechselt, das Eigentum aber nicht. Ledger-Tags, Stufenreferenzen und Standort-Subjekte sind gesalzen, sodass sich kein Prozessablauf und keine Zeitleiste eines Betriebs aus dem Ledger lesen lässt, und Geldbeträge stehen nie im Klartext im Ledger. Eine Pack- oder Verladestufe, die mit einer logistischen Einheit (einer SSCC, einer Containernummer) erfasst wird, wird auf ein EPCIS-AggregationEvent abgebildet. In Referenz-Release 2.0.0-alpha.9 schreibt CompanyFactsHook diese Aufzeichnungen in das Ledger, und RequireStageHook lehnt Lieferungen von Chargen ab, denen erforderliche Stufen fehlen; keines der beiden Module ist verpflichtend. Alles ist informativ und Vorgeschlagen.

Cross-Chain-Deployment

A-REX Core ist ein EVM-Standard (ADR-026, Vorgeschlagen): Ein konformer Token läuft auf jedem EVM-Netzwerk ab dem Stand paris, und der Standard führt keine Liste von Netzwerken; welche eine Organisation nutzen darf, legt ihr Richtlinienprofil fest. Netzwerke werden mit CAIP-2-IDs benannt, etwa eip155:8453 oder hedera:mainnet. Praktische Muster:

• Eine Heimat-Chain je Aussteller (empfohlen): Abstammung und Durchsetzung bleiben kohärent; andere Chains halten gekapselte Repräsentationen über Adapter im Stil von ERC-7802 oder über CCIP.
• Zugangsbeschränkte EVM-Chain für Aussteller, deren Datenschutzbehörde oder Ankerinstitution dies verlangt; der EDPB bevorzugt zugangsbeschränkte Designs ausdrücklich. Derselbe Bytecode.
• Spiegelungen für Liquidität: eine Chargen-ID auf der Heimat-Chain, ein ERC-20-Wrapper anderswo; der Wrapper muss canTransfer des Heimat-Tokens beachten oder sich auf berechtigte Inhaber beschränken.

Die Abstammung überschreitet nie Chains; Referenzen schon. Zwischen Token auf derselben oder auf verschiedenen Chains benennt eine Charge, die aus der Charge eines anderen Tokens hergestellt wurde, diese in der Liste upstream ihrer Metadaten (Schema 1.2.0) über Chain-ID, Contract und Token-ID. Diese Referenzen sind Behauptungen des Ausstellers und am vorgelagerten Token zu prüfen. Ab Schema 1.4.0 (Vorgeschlagen) kann ein Eintrag zusätzlich das CAIP-2-Netzwerk (network) angeben, und eine Charge, die auf einem Netzwerk ohne EVM erfasst ist, wird über ihr Netzwerk und ihr CAIP-19-Asset benannt.

Einträge, die jeder prüfen kann, auf jedem Netzwerk

Die Nachweise rund um einen Token hängen nicht vom Netzwerk des Tokens ab. Einmal pro Zeitraum kann ein Aussteller die Fingerabdrücke seiner Einträge (Audit-Log, Berichte, Dokumente) zu einer einzigen Merkle-Wurzel zusammenfassen und diese 32 Bytes auf mehreren unabhängigen Netzwerken veröffentlichen: auf seinem eigenen EVM-Netzwerk, auf Bitcoin über OpenTimestamps und im Hedera Consensus Service. Jeder Eintrag erhält einen kurzen arex.anchor-proof/1-Nachweis. Wer den Eintrag und seinen Nachweis hat, kann ohne einen Dienst von A-REX prüfen, dass der Eintrag spätestens zu dem Zeitpunkt unverändert existierte, zu dem jedes Netzwerk die Wurzel erhalten hat; ein EVM-Contract kann denselben Nachweis mit OpenZeppelin MerkleProof prüfen. Veröffentlicht werden nur Hashes, nie personenbezogene Daten. Das Format ist informativ und Vorgeschlagen (ADR-026). Auf welchen Netzwerken ein Emittent verankert, ist eine Richtlinienfrage, festgelegt durch sein Profil für Rechtsordnung oder Organisation, und ein Nachweis ist mit beliebig vielen Belegen gültig. Ein Hedera-Beleg nennt beim Senden der Wurzel seine Transaktions-ID und erhält die Sequenznummer und die Konsenszeit der Nachricht, sobald ein öffentlicher Mirror-Node sie bestätigt.

Woher die Zahlen eines signierten Berichts stammen

Ein Bericht, der aus den Einträgen eines Ausstellers berechnet wird, etwa „1 200 kg im Oktober an einen Käufer geliefert“ oder eine Liste von Einträgen, kann seine Quellen mitführen: eine Zeile je gelesenem Eintrag, mit der Stelle, an der das Ledger diesen Eintrag hält, und den Werten, die der Bericht verwendet hat. Jede Zeile ist eine arex.report-sources/1-Quelle; ihr Blatt ist keccak256(0x03 ‖ JCS(source)), und die sortierten Blätter werden paarweise zu einer einzigen Quellenwurzel zusammengefasst. Die Wurzel und der SHA-256 der Quellendatei (<report>.sources.csv) werden mit dem Bericht versiegelt, in seinem signierten Manifest oder unter der Signatur eines PDF, sodass später keine Zeile hinzugefügt, entfernt oder geändert werden kann. Der Bericht sagt, wie viele seiner Einträge sich gegen das Ledger prüfen lassen, wie viele über einen Fingerabdruck auf dem Ledger (einen Tagesanker oder ein Messfenster) und wie viele nur Einträge des Ausstellers sind, gedeckt durch sein Siegel. Eine Quelle enthält nie einen personenbezogenen Wert im Klartext. Ein Leser prüft all das ohne einen Dienst von A-REX: verify-sources.mjs, ein eigenständiges Prüfprogramm (Node.js 20, keine Installation), das jede Implementierung mitliefern kann, berechnet jedes Blatt und die Wurzel neu, vergleicht sie mit dem Bericht und liest dann jeden Ledger-Eintrag von einem beliebigen Knoten seines Netzwerks. Ein Bericht mit mehreren Karten behält eine Quelldatei und eine Wurzel; jede Zeile nennt ihre Karte im optionalen Element section (Revision 1.1), sodass sich die Zahlen jeder Karte für sich summieren.

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

Das Format ist informativ und Vorgeschlagen (Revision 1.1 der Berichtsquellen). Das Dokument des Standards, im Rahmen des frühen Zugangs geteilt, nennt die Spalten der Datei, jede Prüfung und einen Beispielvektor; das Schema beschreibt eine Quelle.

Mit Betriebsverwaltungs- und ERP-Systemen

Die Integrationspunkte sind dieselben wie bei jedem ERC-1155-Token, ergänzt um die Chargen-Views:

• Schreibpfad: Ein Originierungsdienst hält ISSUER_ROLE und ruft createBatch aus ERP-Ereignissen auf (Wiegebrücken-Schein, Ausstellung von Lagerscheinen); setBatchStatus/setBatchMetadata aus Lagerereignissen; transform aus Verarbeitungsaufträgen.
• Lesepfad: Ein Indexer materialisiert Chargen, Abstammung, Attestierungen und Durchsetzungsereignisse in den Rückverfolgbarkeitstabellen des ERP; EPCIS-Export für Partner und Aufsichtsbehörden.
• Vorabprüfung: transferCheck ermöglicht es einem ERP, einem Bediener eine Ablehnung zu erklären, bevor eine Transaktion übermittelt wird.
• Kennungen: GS1-Schlüssel in den Metadaten schlagen die Brücke zu bestehenden EDI- und EPCIS-Repositories; UN/CEFACT-Einheiten sind in ERPs bereits vorhanden.

Kompatibilitätsmatrix