Standard
A-REX Core — le standard
Ce que définit le standard, ce que fait un jeton conforme, comment il évolue et comment il devient un ERC. Le texte normatif est partagé via l'accès anticipé.
Statut
Brouillon 2.1.0-alpha.2, avant soumission, avec le schéma de métadonnées de lot 1.2.0. Le texte est rédigé au format d'un Ethereum Request for Comments afin de pouvoir être soumis à ethereum/ERCs une fois que des implémenteurs indépendants auront utilisé les interfaces en production. Il sera publié sous CC0 ; l'implémentation de référence est sous MIT. Tant qu'il n'existe pas deux implémenteurs indépendants, les modifications acceptées sont marquées comme provisoires.
Ce qu'il définit
A-REX Core est une petite extension d'ERC-1155 et d'ERC-7943. Un lot (une partie d'une marchandise physique, ou le droit à un lot futur) est un identifiant de jeton ERC-1155. Le standard lui ajoute quatre couches :
| Couche | Interface | Ce qu'elle couvre | Obligatoire |
|---|---|---|---|
| 0 | ERC-1155, ERC-165, IERC7943MultiToken | soldes et transferts par lot ; gel, transfert forcé, éligibilité des comptes | oui |
| 1 | IARexBatch | la fiche du lot : codes ouverts de produit et d'unité, dates de production et d'expiration, une référence d'origine, un engagement envers un document hors chaîne, un statut de cycle de vie, et la lignée lorsqu'un lot est divisé, fusionné ou transformé | oui |
| 2 | IARexHook, IARexHookManager | un pipeline ordonné unique de contrats de règles externes ; une règle répond par un motif lisible par machine | oui |
| 3 | IARexAttest | certifications, inspections et déclarations par lot et par thème, émises par des émetteurs de confiance pour ce thème | recommandée, dans le jeton ou un contrat compagnon |
Ce que fait un jeton conforme
- Il se comporte comme un jeton ERC-1155 ordinaire : portefeuilles, places de marché et indexeurs fonctionnent sans changement.
- Il expose la surface d'exécution d'ERC-7943 : un lot peut être gelé ou déplacé sur décision de justice, nantissement ou rappel, et chacune de ces actions est visible sur la chaîne.
- Il tient une fiche pour chaque lot et enregistre chaque division, fusion ou étape de transformation, de sorte que les lots d'origine restent toujours traçables.
- Il fait passer chaque transfert par son pipeline de règles et peut dire pourquoi un transfert est refusé.
- Il déclare les interfaces qu'il implémente, pour que les outils puissent le détecter.
Un contrat de règles (un hook) est conforme lorsqu'il implémente IARexHook. Un même contrat de règles peut servir de nombreux jetons.
Comment la conformité est vérifiée
L'implémentation de référence fournit une suite de conformité qui ne dépend pas d'elle : l'implémentation testée n'est atteinte qu'à travers les interfaces du standard et un petit adaptateur écrit par ses auteurs. Chaque test porte la clause qu'il vérifie ; il y a 87 clauses, 74 de niveau MUST et 13 de niveau SHOULD. Une exécution se termine par un verdict, et une déclaration de conformité doit justifier chaque clause qu'elle a ignorée. Les clauses qui ne peuvent pas être observées sur la chaîne, comme la règle selon laquelle la référence d'origine ne contient aucune donnée personnelle, relèvent de la revue.
Proposé et non publié
Ces modifications sont rédigées et ouvertes à l'examen. Aucune n'est acceptée : chacune attend la confirmation de deux implémenteurs indépendants, et celles de niveau MUST suivent la règle des changements majeurs.
| Proposition | Ce qu'elle changerait |
|---|---|
| ADR-019 (Proposé) : les capacités dans le standard, la politique dans les profils | Le standard fixe les rôles, les événements, les formes de données, la sémantique de la pause et de la révocation, et les règles de protection de la vie privée ; qui peut utiliser une capacité, si elle est activée et quelles listes ou autorités s'appliquent passent dans des profils de politique versionnés par juridiction et par organisation. Il apporte deux clarifications : la référence d'origine NE DOIT PAS être dérivée de la localisation (aucun hash ni encodage de coordonnées ou de géométrie de parcelle) ; et l'émetteur d'une attestation, ou un révocateur qu'il a désigné, la révoque, tandis qu'un rôle administratif NE DEVRAIT PAS révoquer en 2.x une attestation qu'il n'a pas émise et NE DOIT PAS le faire à partir de 3.0, afin que les jetons déjà déployés restent conformes ; selon la même règle, attester à nouveau ne remplace jamais l'enregistrement d'un autre émetteur et ne rétablit jamais un enregistrement révoqué. |
ADR-017 (Proposé) : extensions dans les métadonnées | Le schéma de métadonnées 1.3.0 ajouterait un objet extensions facultatif, avec une entrée par règle, validée par le fragment de schéma du descripteur de la règle. |
| ADR-018 (Proposé) : empreinte carbone déclarée | Un lot peut porter une empreinte carbone de produit déclarée par un tiers nommé, recopiée depuis PACT 3.0.3 dans extensions.pact_pcf avec un statut de vérification ; jamais calculée, additionnée ni transmise à d'autres lots. |
| ADR-020, ADR-021, ADR-022 (Proposé) : adaptateurs de référence | Les outils ERC-3643 lisent chaque lot via une vue qui ne peut rien autoriser ni refuser ; des attestations ONCHAINID valides tant qu'A-REX fait confiance à leur signataire ; un miroir EAS des certificats et enregistrements de lot en vigueur. Informatifs : ils n'ajoutent aucune exigence. |
Descripteur de règle arex.module/1 (informatif, Proposé) | Un document JSON qu'une règle ou un module complémentaire publie afin que les consommateurs l'intègrent sans code sur mesure. |
Les correspondances informatives vers GS1 EPCIS 2.0, l'UN Transparency Protocol 0.7.0, PACT 3.0.3, ERC-3643 et l'Ethereum Attestation Service n'ajoutent aucune exigence ; Interopérabilité les résume.
Ce qu'il laisse de côté
Aucune liste de cultures, de qualités ou de certifications : les codes sont ouverts. Aucune donnée personnelle sur la chaîne : ni coordonnées de parcelles, ni noms, ni identifiants de personnes physiques, ni aucune valeur calculée à partir de la localisation d'une parcelle. Aucun fournisseur d'identité, oracle ou registre n'est imposé, ni aucune politique : qui peut mettre en application, mettre en pause ou filtrer, et selon quelles listes, relève de la décision de l'émetteur dans sa juridiction. Courbes de dépréciation, flux de livraison, comptabilité carbone et assurance se construisent comme règles ou contrats compagnons ; l'implémentation de référence en montre certains, et la conformité n'en dépend pas.
Versionnage
Les interfaces sont versionnées avec le standard. Une modification d'une fonction, d'un événement ou d'une exigence est une version majeure et s'accompagne d'une note de migration. Les ajouts facultatifs, comme de nouveaux codes recommandés ou champs de métadonnées, sont une version mineure : le schéma de métadonnées 1.1.0 a ouvert la nomenclature des denrées, et le schéma 1.2.0 a ajouté des références vers des lots d'autres jetons (upstream). Tout document valide selon un schéma antérieur reste valide. Jusqu'à la soumission, les interfaces peuvent encore changer, toujours en version majeure.
Vers un ERC
Le texte est soumis à ethereum/ERCs lorsque quatre conditions sont réunies : un déploiement en production avec de vrais lots fonctionne depuis six mois ; au moins trois contrats de règles indépendants existent ; l'implémentation de référence a un audit tiers publié ; et les interfaces n'ont pas changé pendant un cycle de versions. La feuille de route se trouve dans Évolutions futures.
Ce que ce site réserve
Les clauses normatives, les sources des interfaces et leurs identifiants, les codes de rejet et le schéma de métadonnées du lot restent dans le dépôt du standard tant qu'il est privé. Les entreprises qui veulent implémenter A-REX, émettre des lots avec lui ou l'auditer demandent un accès en lecture sur Demander un accès anticipé. Chaque demande est examinée à la main ; les lecteurs approuvés reçoivent un accès en lecture seule au standard et à l'implémentation de référence. Le contenu reste confidentiel jusqu'à sa publication sous CC0, et l'accès anticipé n'accorde aucune exclusivité.