Livre blanc · 14
Évolutions futures
La feuille de route depuis une interface alpha figée jusqu'à un standard de fait, puis officiel, et le travail technique qui l'accompagne. Les dates sont des objectifs, non des promesses.
Principe
Ce sont les interfaces qui sont standardisées ; tout le reste peut évoluer. La feuille de route comporte donc deux volets : la standardisation (rendre les interfaces dignes de confiance et adoptées) et l'implémentation (améliorer la référence et les modules sans toucher aux interfaces).
Volet de standardisation
| Phase | Objectif | Critères de sortie |
|---|---|---|
| 0 · Gel alpha (actuellement) | interfaces v2.0.0-alpha publiées ; implémentation de référence avec tous les hooks métier et toutes les extensions ; CI ; spécification au format ERC ; document de conception du système, enregistrements de décision et dossier d'audit | aucune modification d'interface sans version majeure |
| 1 · Ancrage en production (6–12 mois) | un déploiement réel (coopérative, silo collecteur ou exportateur) avec des lots réels sur un L2 ou une chaîne à accès restreint | six mois d'exploitation ; indicateurs publics : lots, transformations, transferts forcés exécutés, délai de réponse à une demande de traçabilité ; audit par un tiers publié |
| 2 · Communauté (en parallèle) | fil de discussion Ethereum Magicians ; coalition d'implémenteurs de hooks indépendants ; adaptateur de conformité ERC-3643 bidirectionnel | trois implémentations indépendantes d'IARexHook en dehors de ce dépôt ; deux jetons conformes indépendants |
| 3 · Soumission | ERC en brouillon (Draft) dans ethereum/ERCs contenant uniquement standard/AREX-CORE.md (couches 1–3 ; ERC-7943 référencé, non copié) | acceptation par les éditeurs ; Last Call sans objection bloquante |
| 4 · Gouvernance neutre (année 2) | groupe de travail ou association indépendant des auteurs d'origine ; liaison avec l'ISO TC 307 (l'initiative espagnole sur ERC-3643) et GS1 | documents de gouvernance adoptés ; spécification maintenue en dehors d'une seule entreprise |
Pourquoi ne pas soumettre dès maintenant : ERC-3643 était en production depuis trois ans avant son EIP ; ERC-7943 a atteint le statut Final en huit mois parce que sa coalition l'utilisait déjà. Un ERC fige ce qu'il standardise, et les interfaces méritent un cycle de production avant d'être figées pour tout le monde.
Volet d'implémentation
Modules métier : portés (septembre 2026)
| Module | Maintenant | Statut |
|---|---|---|
| Périssabilité | PerishabilityHook (linéaire, exponentiel, par paliers ; configuration par denrée et par lot) + ExpiryHook | terminé |
| Saisonnalité | SeasonalHook | terminé |
| Livraison | DeliveryHook (machine à états, chaîne du froid, litiges, verrou d'unités en O(1), règlement via les données de transfert) | terminé |
| Traçabilité | TraceabilityHook (vocabulaire EPCIS ; émission seule ou persistant) | terminé |
| Sanctions, conformité | EligibilityHook (sanctions avec source et TTL) | terminé |
| Limites de transfert / quotas | non fourni ; le guide Développement de hooks présente un modèle de hook de quota borné | ouvert (communauté) |
| Oracle | CommodityPriceOracle (tours numérotés, quorum, médiane) | terminé |
| Carbone | CarbonImmobilizationWrapper (crédits immobilisés par un registre ; attestation ; aucune émission) | terminé |
| Assurance | ParametricInsurance (déclenchée par attestation) | terminé |
Le travail d'implémentation restant sur ces composants relève de l'optimisation et du durcissement pour la production, non de la conception.
Primitives de règlement et de financement
- Blocages et séquestre (livraison contre paiement) : un hook plus un compagnon mettant en œuvre une libération conditionnelle ; alignement sur ERC-7573 lorsqu'un volet de paiement est on-chain.
- Flux de travail de nantissement : un petit contrat qui pilote
setFrozenTokens/forcedTransferà partir du hash d'un contrat de nantissement, afin que les prêteurs exercent le rôle de mise en application par une procédure auditable plutôt que par des appels bruts.
Vie privée
- Divulgation sélective des données de qualité : des preuves à divulgation nulle de connaissance attestant qu'une mesure du document de métadonnées respecte une limite (humidité, aflatoxine, résidus) sans révéler la valeur ; la preuve devient une attestation.
- Contrôle d'accès aux données restreintes : implémentation de référence du pointeur
restrictedavec des jetons de capacité pour les acheteurs, les certificateurs et les régulateurs.
Identité et attestations
- Implémentation d'
IARexAttestadossée à EAS. - Hook d'éligibilité adossé aux attestations ONCHAINID et à des justificatifs vérifiables (portefeuilles eIDAS 2.0).
Inter-chaînes
- Référence de wrapper ERC-7802 / CCIP ; la filiation reste sur la chaîne d'origine.
Outillage
- Outil d'export EPCIS 2.0 au-dessus du journal d'événements.
- Validateur JSON Schema et canonicalisateur RFC 8785 pour les métadonnées.
- Modèles de subgraph / d'indexeur pour les lots, la filiation, les attestations et la mise en application.
- Vérification formelle des invariants du pipeline de transfert (conservation de l'offre, statut terminal, absence de réentrance) ; un test d'invariants aléatoire à graine fixée les exerce déjà (
test/standard/Invariants.test.js).
Questions de recherche
- Déterminer si les transitions de
statusdevraient pouvoir s'exprimer sous forme de table on-chain (automate défini par l'émetteur) sans alourdir le standard. - Déterminer si une interface standard d'éligibilité des comptes distincte des hooks faciliterait l'intégration avec les moteurs de conformité, ou si la conjonction des hooks suffit.
- Règles de bilan massique pour le traitement (bornes de rendement par couple de denrées) sous forme de hooks, et leur interaction avec les pertes légitimes.
- Réconciliation entre la filiation on-chain et le mélange physique dans les silos, où « quel kilogramme » est juridiquement un droit fongible.
Ce qui ne changera pas
- Les quatre interfaces, en l'absence d'une version majeure accompagnée d'une note de migration.
- La règle selon laquelle les modules sont des démonstrations, non du standard.
- La règle selon laquelle les données personnelles restent off-chain.
- La règle selon laquelle l'autorité provient des rôles, non des soldes.