श्वेतपत्र · 12

अंतरसंचालनीयता

A-REX टोकन मौजूदा दुनिया में कैसे फ़िट होता है: Ethereum टोकन मानक, अनुपालन इंजन, ट्रेसेबिलिटी और उत्पाद-पासपोर्ट डेटा मानक, कार्बन फ़ुटप्रिंट, विधिक-दस्तावेज़ रजिस्ट्री, पहचान प्रणालियाँ, क्रॉस-चेन इन्फ्रास्ट्रक्चर और मौजूदा फ़ार्म सिस्टम।

Ethereum इकोसिस्टम के साथ

A-REX Core टोकन एक ERC-1155 टोकन है। ERC-1155 को समझने वाले वॉलेट, एक्सप्लोरर, मार्केटप्लेस और इंडेक्सर बिना बदलाव के काम करते हैं: बैलेंस, बैच ट्रांसफ़र, uri(id), अनुमोदन, सेफ़-ट्रांसफ़र रिसीवर जाँच। A-REX इवेंट और व्यू जोड़ता है; कुछ हटाता नहीं।

A-REX Core टोकन एक ERC-7943 मल्टी-टोकन है। ERC-7943 को लक्षित करने वाले अनुपालन इंजन और अभिरक्षा प्लेटफ़ॉर्म (Chainlink के Automated Compliance Engine ने संगतता प्रदर्शित की है; ERC-7943 गठबंधन के जारीकरण प्लेटफ़ॉर्म इसे अपना रहे हैं) canTransfer, forcedTransfer, setFrozenTokens, canSend और canReceive को बिना अनुकूलन के पहचानते हैं।

मानक	संबंध
ERC-1155	आधार; A-REX Core एक एक्सटेंशन है
ERC-165	इंटरफ़ेस खोज; पाँच आईडी प्रकाशित
ERC-7943	अनिवार्य; प्रवर्तन सतह शब्दशः अपनाई गई
ERC-3643	संदर्भ एडेप्टर (ADR-020, प्रस्तावित): हर बैच को एक ERC-3643 टोकन के रूप में पढ़ा जा सकता है (बैलेंस, पात्रता, फ़्रीज़ की गई मात्राएँ, पॉज़, आवाजाही), एक ऐसे व्यू के माध्यम से जो सीधे टोकन से पढ़ता है और एक केवल सूचना पाने वाले हुक के माध्यम से, जो किसी भी चीज़ की अनुमति या इनकार नहीं कर सकता; A-REX टोकन अपरिवर्तित रहता है। T-REX 4.1.6 के विरुद्ध परीक्षित। ERC-3643 अनुपालन मॉड्यूल को `IARexHook` के रूप में रैप करना, और किसी बैच को ERC-3643 प्रतिभूति के रूप में रैप करना, अभी केवल डिज़ाइन हैं, कार्यान्वित नहीं। ERC-3643 के माध्यम से किसी बैच को पढ़ने से वह प्रतिभूति नहीं बन जाता।
ERC-735 / ONCHAINID दावे	दावा विषय सीधे `IARexAttest` विषयों से मैप होते हैं (`bytes32(uint256 topic)`); एक संदर्भ दावा जारीकर्ता (ADR-021, प्रस्तावित) किसी कंपनी की A-REX स्थिति को ONCHAINID दावों के रूप में प्रस्तुत करता है, जो केवल तब तक वैध हैं जब तक A-REX उनके हस्ताक्षरकर्ता पर भरोसा करता है, पढ़े जाने के क्षण में जाँचे जाते हैं, और केवल हस्ताक्षरकर्ता ही उन्हें निरस्त करता है। ONCHAINID 2.2.1 के विरुद्ध परीक्षित।
Ethereum Attestation Service	स्कीमा UID वैध `IARexAttest` विषय हैं; एक संदर्भ मिरर (ADR-022, प्रस्तावित) वैध प्रमाणपत्रों और बैच रिकॉर्ड को EAS पर दो रिज़ॉल्वर-रहित स्कीमा के तहत प्रकाशित करता है, और जब A-REX उन्हें निरस्त करता है, उन पर भरोसा हटाता है या उन्हें बदलता है, तो अपनी प्रतियाँ निरस्त कर देता है। EAS 1.4.0 के विरुद्ध परीक्षित। EAS-समर्थित `IARexAttest` रजिस्ट्री अभी केवल डिज़ाइन है, कार्यान्वित नहीं।
ERC-7201	संदर्भ कार्यान्वयन का स्टोरेज लेआउट
ERC-7573, होल्ड/एस्क्रो पैटर्न	डिलीवरी-बनाम-भुगतान और एस्क्रो हुक या सहायक कॉन्ट्रैक्ट हैं; मानक निपटान निर्धारित नहीं करता
ERC-7802 / Chainlink CCIP	क्रॉस-चेन मिंट/बर्न एडेप्टर टोकन को रैप कर सकते हैं; वंशावली मूल चेन पर रहती है, संदर्भ यात्रा करते हैं

ट्रेसेबिलिटी डेटा मानकों के साथ

GS1 EPCIS 2.0 / CBV

मानक इवेंट-दर-इवेंट एक सूचनात्मक मैपिंग प्रकाशित करता है:

ऑन-चेन	EPCIS 2.0
`BatchCreated`	`ObjectEvent` ADD, `bizStep = creating_class_instance` (लॉट स्तर) या `commissioning` जब इंस्टेंस आईडी निर्धारित की जाती हैं, `quantityList` (इकाई Rec. 20 से), लॉट मास्टर डेटा `ilmd` में
`TransferSingle` / `TransferBatch`	`ObjectEvent` OBSERVE, स्वामी पक्ष स्रोत और गंतव्य के रूप में; केवल स्वामित्व परिवर्तन के लिए कोई `bizStep` नहीं, `shipping`/`receiving` केवल तब जब मेटाडेटा या कोई ट्रेसेबिलिटी हुक बताए कि माल की आवाजाही हुई
`BatchTransformed`	`TransformationEvent` (`inputQuantityList`, `outputQuantityList`, `processRef` से `transformationID`); री-बैच के लिए `bizStep = repackaging`, प्रसंस्करण के लिए `creating_class_instance`
`upstream` संदर्भों के साथ `BatchCreated`	जब माल किसी अन्य टोकन के बैच से प्रसंस्कृत हुआ हो तो `TransformationEvent`, अन्यथा आपूर्तिकर्ता को स्रोत मानकर एक `ObjectEvent`; साझा `epcClass` इसे आपूर्तिकर्ता के अपने इवेंट से जोड़ता है
`ForcedTransfer`	`ObjectEvent` OBSERVE, `holding` जब माल विधिक रोक (लीगल होल्ड) के अंतर्गत रखा जाता है
`BatchStatusChanged`	जारीकर्ता की स्टेटस तालिका से `disposition` के साथ `ObjectEvent`
`Attested` / `AttestationRevoked`	प्रमाणपत्र संदर्भ के साथ `ObjectEvent` (`inspecting`, या प्रयोगशाला के लिए `sampling`)
मेटाडेटा `gs1.*`	GTIN, LGTIN, SSCC, GLN, Digital Link
मेटाडेटा `extensions`	बनाने वाले इवेंट का `ilmd`; घोषित फ़ुटप्रिंट `arex:declaredFootprint` के रूप में

मेटाडेटा स्कीमा जान-बूझकर EPCIS/CBV नामों का उपयोग करती है ताकि निर्यातक अवधारणाओं को नहीं, फ़ील्ड को मैप करे।

UN Transparency Protocol (UNTP 0.7.0)

एक सूचनात्मक मैपिंग किसी बैच, उसके इवेंट और उसके एटेस्टेशन को UNTP 0.7.0 क्रेडेंशियल में बदलती है, EPCIS मैपिंग वाले ही आइडेंटिफ़ायर के साथ, ताकि दोनों को जोड़ा जा सके:

A-REX	UNTP क्रेडेंशियल	कौन जारी करता है
बैच, उसका उद्गम, सुविधा और प्रमाणपत्र	Digital Product Passport (`credentialSubject` एक `Product`, प्रति बैच एक)	बैच जारीकर्ता
मिंट और प्रसंस्करण; ट्रांसफ़र और प्राप्तियाँ; बर्न, स्टेटस परिवर्तन और मेटाडेटा सुधार	Digital Traceability Events: `MakeEvent`; `MoveEvent`; `ModifyEvent`, प्रत्येक अपने ट्रांज़ैक्शन से जुड़ा	बैच जारीकर्ता
किसी प्रमाणक या प्रयोगशाला का एटेस्टेशन	मूल्यांकनकर्ता के Digital Conformity Credential का संदर्भ	मूल्यांकनकर्ता, बैच जारीकर्ता कभी नहीं

क्रेडेंशियल W3C Verifiable Credentials Data Model 2.0 का पालन करते हैं और जारीकर्ता के did:web के अंतर्गत VC-JOSE-COSE से हस्ताक्षरित होते हैं; निरस्तीकरण के लिए Bitstring Status List का उपयोग होता है। हस्ताक्षरित क्रेडेंशियल को उसके बैच से एक एटेस्टेशन के रूप में भी एंकर किया जा सकता है, जिसका संदर्भ क्रेडेंशियल का हैश हो; एंकर कमिटमेंट को सिद्ध करता है, हस्ताक्षर सामग्री को। क्रेडेंशियल में केवल वही होता है जो टोकन या उसके मेटाडेटा में है, और जिन मानों के लिए किसी पद्धति की आवश्यकता होती है (फ़ुटप्रिंट, जोखिम स्कोर) वे केवल तब दिखते हैं जब किसी नामित पक्ष ने उन्हें घोषित किया हो। मैपिंग यह बताती है कि वह क्या कवर नहीं करती, शुरुआत EU Digital Product Passport से: ESPR खाद्य, चारा या जीवित पौधों और पशुओं पर लागू नहीं होता, और A-REX उनके लिए कोई पासपोर्ट दावा नहीं करता।

घोषित कार्बन फ़ुटप्रिंट (PACT 3.0.3)

ADR-018 (प्रस्तावित) किसी बैच को मेटाडेटा दस्तावेज़ के extensions.pact_pcf के अंतर्गत ऐसा उत्पाद कार्बन फ़ुटप्रिंट वहन करने देता है जिसे किसी तृतीय पक्ष ने परिकलित किया हो। यह अंश WBCSD PACT Technical Specifications 3.0.3 का फ़ील्ड-दर-फ़ील्ड पालन करता है: किसने घोषित किया, घोषित इकाई और संदर्भ अवधि, बायोजेनिक अवशोषण सहित और उसके बिना फ़ुटप्रिंट, और एक अनिवार्य सत्यापन स्थिति जो फ़ुटप्रिंट सत्यापित होने पर सत्यापनकर्ता का नाम देती है। इसे कॉपी किया जाता है; कभी परिकलित नहीं किया जाता, न जोड़ा जाता है, न लॉट से बने बैच तक आगे बढ़ाया जाता है, और यह कार्बन क्रेडिट नहीं है (ADR-014)। मैपिंग PACT का एक अलग व्युत्पन्न है और PACT की कोई फ़ाइल कॉपी नहीं करती।

कमोडिटी और इकाई कोड

कमोडिटी कोड किसी भी योजना के लिए keccak256("<SCHEME>:<CODE>") है: Harmonized System (HS), राष्ट्रीय टैरिफ़ नामपद्धतियाँ (Mercosur में NCM, EU में CN और TARIC, संयुक्त राज्य अमेरिका में HTS, और अन्य), FAO, CPC, GTIN, या जारीकर्ता की अपनी योजना। मेटाडेटा स्कीमा 1.1.0 से दस्तावेज़ में भी योजना खुली है, इसलिए मेटाडेटा ऑन-चेन कोड को प्रतिबिंबित कर सकता है। इकाइयाँ UN/CEFACT Recommendation 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 टोकन विधिक लिखतों को संदर्भित करते हैं; जब तक कोई क्षेत्राधिकार स्वयं टोकन को मान्यता नहीं देता, वे उनकी जगह नहीं लेते:

लिखत	कहाँ रहता है	टोकन उसे कैसे संदर्भित करता है
U.S. इलेक्ट्रॉनिक वेयरहाउस रसीद (7 CFR 869)	USDA-अधिकृत EWR प्रदाता	`documents[].registry`, `originRef`
ब्राज़ीली CPR-e, CDA/WA	केंद्रीय बैंक-अधिकृत रजिस्ट्रार	`documents[].registryId`; `producedAt == 0` वाला कटाई-पूर्व बैच
अर्जेंटीनी certificado de depósito / warrant (Law 9.643)	वेयरहाउस	`originRef` हैश
इलेक्ट्रॉनिक बिल ऑफ़ लैडिंग (MLETR क्षेत्राधिकार)	eBL प्लेटफ़ॉर्म	दस्तावेज़ हैश; MLETR क्षेत्राधिकारों में टोकन स्वयं अनन्य नियंत्रण को पूरा कर सकता है
EUDR ड्यू-डिलिजेंस कथन	EU Information System	`origin.eudr.ddsReference`, एटेस्टेशन `EUDR:DDS`

पहचान प्रणालियों के साथ

टोकन केवल canSend(account) / canReceive(account) पूछता है। उस प्रश्न के पीछे हो सकता है:

जारीकर्ता द्वारा संचालित अनुमति/ब्लॉक सूची (EligibilityHook);
दावा विषयों वाली ONCHAINID पहचान रजिस्ट्री (ERC-3643 मॉडल);
खाते पर Ethereum Attestation Service के एटेस्टेशन;
वेरिफ़ायबल क्रेडेंशियल जिन्हें ऑफ़-चेन सत्यापित किया जाता है और रिले करने वाले द्वारा ऑन-चेन प्रतिबिंबित किया जाता है;
क्रेडेंशियल सत्यापनकर्ता के माध्यम से राष्ट्रीय e-ID योजना (EU में eIDAS 2.0 वॉलेट)।

इनमें से कोई भी मानक का हिस्सा नहीं है, यही कारण है कि ब्राज़ील और जर्मनी के जारीकर्ता अलग-अलग प्रदाताओं का उपयोग कर सकते हैं और फिर भी अंतरसंचालनीय बने रह सकते हैं।

नियम इंजन और प्लेटफ़ॉर्म के साथ

कोई नियम या ऐड-ऑन एक arex.module/1 डिस्क्रिप्टर प्रकाशित कर सकता है: एक JSON दस्तावेज़ जिसमें उसके पैरामीटर, सेटिंग, आवश्यक बैच फ़ील्ड, प्रमाणपत्र-श्रेणियाँ, इवेंट, अस्वीकृति कोड और यह विवरण होता है कि उसकी स्टेट नए संस्करण में कैसे आगे जाती है। डिस्क्रिप्टर पढ़ने वाला प्लेटफ़ॉर्म, वॉलेट, इंडेक्सर या ऑडिटर किसी नए नियम को बिना कस्टम कोड के एकीकृत करता है। प्रारूप सूचनात्मक और प्रस्तावित है; जब कोई दूसरा स्वतंत्र कार्यान्वयनकर्ता इसका उपयोग करे, तब यह अनुशंसित प्रारूप बन जाता है। संशोधन 1.1 एक वैकल्पिक, सूचनात्मक ops सूची जोड़ता है जिसमें वे ऑपरेशन होते हैं जिन्हें कोई नियम नियंत्रित करता है; इसका न होना अज्ञात का अर्थ है, और इसका उपयोग कभी प्रवर्तन के लिए नहीं होता।

क्रॉस-चेन डिप्लॉयमेंट

मानक चेन-अज्ञेयवादी है। व्यावहारिक पैटर्न:

प्रति जारीकर्ता एक होम चेन (अनुशंसित): वंशावली और प्रवर्तन सुसंगत रहते हैं; अन्य चेन ERC-7802-शैली एडेप्टर या CCIP के माध्यम से रैप किए गए निरूपण रखती हैं।
अनुमति-आधारित EVM चेन उन जारीकर्ताओं के लिए जिनका डेटा-संरक्षण प्राधिकरण या एंकर संस्था इसे अपेक्षित करती है; EDPB अनुमति-आधारित डिज़ाइनों का स्पष्ट रूप से पक्षधर है। वही बाइटकोड।
तरलता के लिए मिरर: होम चेन पर बैच आईडी, अन्यत्र ERC-20 रैपर; रैपर के लिए होम टोकन के canTransfer का पालन करना या स्वयं को पात्र धारकों तक सीमित रखना अनिवार्य है।

वंशावली कभी चेन पार नहीं करती; संदर्भ करते हैं। एक ही चेन पर या अलग-अलग चेन पर टोकनों के बीच, किसी अन्य टोकन के बैच से बना बैच अपने मेटाडेटा की upstream सूची (स्कीमा 1.2.0) में चेन आईडी, कॉन्ट्रैक्ट और टोकन आईडी द्वारा उसका नाम देता है। ये संदर्भ जारीकर्ता के दावे हैं, जिन्हें अपस्ट्रीम टोकन से मिलाकर जाँचा जाना है।

फ़ार्म प्रबंधन और ERP प्रणालियों के साथ

इंटीग्रेशन बिंदु किसी भी ERC-1155 टोकन जैसे ही हैं, साथ में बैच व्यू:

राइट पाथ: एक ओरिजिनेशन सेवा ISSUER_ROLE रखती है और ERP इवेंट (वेब्रिज टिकट, रसीद जारी करना) से createBatch कॉल करती है; वेयरहाउस इवेंट से setBatchStatus/setBatchMetadata; प्रोसेसिंग ऑर्डर से transform।
रीड पाथ: एक इंडेक्सर बैच, वंशावली, एटेस्टेशन और प्रवर्तन इवेंट को ERP की ट्रेसेबिलिटी तालिकाओं में मटीरियलाइज़ करता है; साझेदारों और नियामकों के लिए EPCIS निर्यात।
प्री-फ़्लाइट: transferCheck ERP को ट्रांज़ैक्शन सबमिट करने से पहले किसी ऑपरेटर को इनकार का कारण समझाने देता है।
आइडेंटिफ़ायर: मेटाडेटा में GS1 कुंजियाँ मौजूदा EDI और EPCIS रिपॉज़िटरी से सेतु बनाती हैं; UN/CEFACT इकाइयाँ ERP में पहले से हैं।

संगतता मैट्रिक्स

क्षमता	स्थिति
ERC-1155 वॉलेट / मार्केटप्लेस	नेटिव
ERC-7943 अनुपालन टूलिंग	नेटिव
बैच पढ़ने वाले ERC-3643 टूल	संदर्भ एडेप्टर (ADR-020, प्रस्तावित)
हुक के रूप में ERC-3643 अनुपालन मॉड्यूल	डिज़ाइन, कार्यान्वित नहीं
A-REX स्थिति से ONCHAINID दावे	संदर्भ दावा जारीकर्ता (ADR-021, प्रस्तावित)
ERC-735 / EAS एटेस्टेशन	विषय मैपिंग; EAS मिरर (ADR-022, प्रस्तावित)
EPCIS 2.0 निर्यात	सूचनात्मक इवेंट मैपिंग; स्कीमा में फ़ील्ड नाम; इंडेक्सर-पक्ष
UNTP 0.7.0 क्रेडेंशियल	सूचनात्मक मैपिंग; जारीकर्ता द्वारा हस्ताक्षरित (`did:web`, VC-JOSE-COSE)
PACT 3.0.3 फ़ुटप्रिंट	`extensions.pact_pcf` (ADR-018, प्रस्तावित)
नियम डिस्क्रिप्टर	`arex.module/1` (सूचनात्मक, प्रस्तावित)
टोकनों के बीच वंशावली	मेटाडेटा `upstream` (स्कीमा 1.2.0)
अनुमति-आधारित EVM	वही बाइटकोड
क्रॉस-चेन	रैपर; वंशावली होम पर रहती है