Standard
A-REX Core — der Standard
Was der Standard festlegt, was ein konformer Token tut, wie er sich ändert und wie er zu einem ERC wird. Der normative Text wird über den frühen Zugang geteilt.
Status
Entwurf 2.1.0-alpha.2, vor der Einreichung, mit dem Chargen-Metadatenschema 1.2.0. Der Text ist im Format eines Ethereum Request for Comments verfasst, damit er bei ethereum/ERCs eingereicht werden kann, sobald unabhängige Implementierer die Schnittstellen in Produktion eingesetzt haben. Er wird unter CC0 veröffentlicht; die Referenzimplementierung steht unter MIT. Solange es keine zwei unabhängigen Implementierer gibt, werden angenommene Änderungen als vorläufig gekennzeichnet.
Was er festlegt
A-REX Core ist eine kleine Erweiterung von ERC-1155 und ERC-7943. Eine Charge (eine Partie einer physischen Ware oder das Recht auf eine künftige Partie) ist eine ERC-1155-Token-ID. Der Standard fügt ihr vier Schichten hinzu:
| Schicht | Schnittstelle | Was sie abdeckt | Pflicht |
|---|---|---|---|
| 0 | ERC-1155, ERC-165, IERC7943MultiToken | Salden und Chargenübertragungen; Einfrieren, Zwangsübertragung, Kontoberechtigung | ja |
| 1 | IARexBatch | der Chargendatensatz: offene Waren- und Einheitencodes, Produktions- und Ablaufzeit, eine Herkunftsreferenz, eine Verpflichtung auf ein Off-Chain-Dokument, ein Lebenszyklusstatus und die Abstammung, wenn eine Charge geteilt, zusammengeführt oder verarbeitet wird | ja |
| 2 | IARexHook, IARexHookManager | eine einzige geordnete Pipeline externer Regelverträge; eine Regel antwortet mit einem maschinenlesbaren Grund | ja |
| 3 | IARexAttest | Zertifizierungen, Inspektionen und Erklärungen je Charge und Thema, von für dieses Thema vertrauenswürdigen Ausstellern | empfohlen, im Token oder in einem Begleitvertrag |
Was ein konformer Token tut
- Er verhält sich wie ein gewöhnlicher ERC-1155-Token, sodass Wallets, Marktplätze und Indexer unverändert funktionieren.
- Er bietet die Durchsetzungsschnittstelle von ERC-7943: Eine Charge kann auf gerichtliche Anordnung, wegen eines Pfandrechts oder eines Rückrufs eingefroren oder bewegt werden, und jede solche Maßnahme ist on-chain sichtbar.
- Er führt für jede Charge einen Datensatz und hält jede Teilung, Zusammenführung oder Verarbeitung fest, sodass sich die Ausgangschargen immer zurückverfolgen lassen.
- Er leitet jede Übertragung durch seine Regel-Pipeline und kann sagen, warum eine Übertragung abgelehnt wird.
- Er deklariert die Schnittstellen, die er implementiert, damit Werkzeuge ihn erkennen können.
Ein Regelvertrag (ein Hook) ist konform, wenn er IARexHook implementiert. Ein Regelvertrag kann viele Token bedienen.
Wie die Konformität geprüft wird
Die Referenzimplementierung liefert eine Konformitätssuite mit, die nicht von ihr abhängt: Eine zu prüfende Implementierung wird nur über die Schnittstellen des Standards und einen kleinen Adapter angesprochen, den ihre Autoren schreiben. Jeder Test nennt die Klausel, die er prüft; es gibt 85 Klauseln, 74 auf MUSS-Ebene und 11 auf SOLLTE-Ebene. Ein Lauf endet mit einem Ergebnis, und eine Konformitätsaussage muss jede übersprungene Klausel begründen. Klauseln, die sich on-chain nicht beobachten lassen, etwa die Regel, dass die Herkunftsreferenz keine personenbezogenen Daten enthält, bleiben der Prüfung durch Menschen überlassen.
Vorgeschlagen und nicht veröffentlicht
Diese Änderungen sind ausformuliert und stehen zur Prüfung offen. Keine davon ist angenommen: Jede wartet auf die Bestätigung durch zwei unabhängige Implementierer, und die auf MUSS-Ebene folgen der Regel für Hauptversionen.
| Vorschlag | Was er ändern würde |
|---|---|
| ADR-019 (Vorgeschlagen): Fähigkeiten im Standard, Richtlinien in Profilen | Der Standard legt Rollen, Ereignisse, Datenformen, die Semantik von Pause und Widerruf sowie Datenschutzregeln fest; wer eine Fähigkeit nutzen darf, ob sie eingeschaltet ist und welche Listen oder Behörden gelten, wandert in versionierte Richtlinienprofile je Rechtsordnung und Organisation. Er bringt zwei Klarstellungen: Die Herkunftsreferenz DARF NICHT aus dem Standort abgeleitet sein (kein Hash und keine Kodierung von Koordinaten oder Flächengeometrie); und der Aussteller einer Attestierung oder ein von ihm beauftragter Widerrufsberechtigter widerruft sie, während eine administrative Rolle eine nicht selbst ausgestellte Attestierung in 2.x NICHT widerrufen SOLLTE und ab 3.0 NICHT widerrufen DARF, damit bereits bereitgestellte Tokens konform bleiben. |
ADR-017 (Vorgeschlagen): extensions in den Metadaten | Das Metadatenschema 1.3.0 würde ein optionales Objekt extensions hinzufügen, einen Eintrag je Regel, validiert durch das Schemafragment des Deskriptors der Regel. |
| ADR-018 (Vorgeschlagen): deklarierter CO₂-Fußabdruck | Eine Charge kann einen Produkt-CO₂-Fußabdruck tragen, den ein benannter Dritter deklariert hat, übernommen aus PACT 3.0.3 in extensions.pact_pcf mit einem Verifizierungsstatus; nie berechnet, summiert oder an andere Chargen weitergegeben. |
| ADR-020, ADR-021, ADR-022 (Vorgeschlagen): Referenzadapter | ERC-3643-Werkzeuge lesen jede Charge über eine Sicht, die nichts erlauben oder verweigern kann; ONCHAINID-Claims, gültig, solange A-REX ihrem Unterzeichner vertraut; ein EAS-Spiegel gültiger Zertifikate und Chargendatensätze. Informativ: Sie fügen keine Anforderung hinzu. |
Regeldeskriptor arex.module/1 (informativ, Vorgeschlagen) | Ein JSON-Dokument, das eine Regel oder ein Add-on veröffentlicht, damit nutzende Systeme sie ohne eigenen Code einbinden. |
Die informativen Abbildungen auf GS1 EPCIS 2.0, das UN Transparency Protocol 0.7.0, PACT 3.0.3, ERC-3643 und den Ethereum Attestation Service fügen keine Anforderung hinzu; Interoperabilität fasst sie zusammen.
Was er auslässt
Es gibt keine Liste von Kulturen, Qualitätsstufen oder Zertifizierungen: Die Codes sind offen. Es gibt keine personenbezogenen Daten on-chain: keine Flächenkoordinaten, keine Namen, keine Kennungen natürlicher Personen und kein aus dem Standort einer Fläche berechneter Wert. Kein Identitätsanbieter, Orakel oder Register wird vorgeschrieben, und keine Richtlinie: Wer durchsetzen, pausieren oder ein Screening durchführen darf und anhand welcher Listen, entscheidet der Aussteller nach seiner Rechtsordnung. Verfallskurven, Lieferabläufe, CO₂-Bilanzierung und Versicherung werden als Regeln oder Begleitverträge gebaut; die Referenzimplementierung zeigt einige davon, und die Konformität hängt nicht von ihnen ab.
Versionierung
Die Schnittstellen werden mit dem Standard versioniert. Eine Änderung an einer Funktion, einem Ereignis oder einer Anforderung ist eine Hauptversion und kommt mit einem Migrationshinweis. Optionale Ergänzungen wie neue empfohlene Codes oder Metadatenfelder sind eine Nebenversion: Das Metadatenschema 1.1.0 öffnete das Schema der Warencodes, und das Schema 1.2.0 fügte Referenzen auf Chargen anderer Token hinzu (upstream). Jedes Dokument, das unter einem früheren Schema gültig ist, bleibt gültig. Bis zur Einreichung können sich die Schnittstellen noch ändern, stets als Hauptversion.
Weg zum ERC
Der Text geht an ethereum/ERCs, wenn vier Bedingungen erfüllt sind: Ein Produktionseinsatz mit echten Chargen läuft seit sechs Monaten; es gibt mindestens drei unabhängige Regelverträge; die Referenzimplementierung hat ein veröffentlichtes externes Audit; und die Schnittstellen sind einen Release-Zyklus lang unverändert geblieben. Die Roadmap steht in Zukünftige Entwicklungen.
Was diese Website zurückhält
Die normativen Klauseln, die Quellen der Schnittstellen und ihre Kennungen, die Ablehnungscodes und das Metadatenschema der Charge bleiben im Repository des Standards, solange es privat ist. Unternehmen, die A-REX implementieren, damit Chargen ausgeben oder es prüfen wollen, beantragen Lesezugriff unter Frühen Zugang anfragen. Jede Anfrage wird von Hand geprüft; zugelassene Leser erhalten schreibgeschützten Zugriff auf den Standard und die Referenzimplementierung. Das Material bleibt vertraulich, bis es unter CC0 veröffentlicht wird, und der frühe Zugang gewährt keine Exklusivität.