समाधान अवलोकन

तीन स्तर, निर्भरता की एक दिशा

A-REX उस चीज़ को, जिसे मानकीकृत होना चाहिए, उस चीज़ से अलग करता है जिसे केवल काम करना चाहिए:

मानक की चार परतें

flowchart TB
    L3["परत 3 · IARexAttest<br/>attest · revokeAttestation · isAttested · प्रत्येक विषय के लिए विश्वसनीय जारीकर्ता"]
    L2["परत 2 · IARexHook + IARexHookManager<br/>hookFlags · check → bytes32 · onExecuted · getHooks"]
    L1["परत 1 · IARexBatch<br/>createBatch · batchOf · setBatchStatus · setBatchMetadata · transform · parentsOf"]
    L0["परत 0 · ERC-1155 + ERC-165 + IERC7943MultiToken<br/>freeze · forcedTransfer · canSend · canReceive · canTransfer"]
    L3 --- L2 --- L1 --- L0
    classDef l3 fill:#edf5ff,stroke:#0f62fe,color:#161616
    classDef l2 fill:#d0e2ff,stroke:#0f62fe,color:#161616
    classDef l1 fill:#a6c8ff,stroke:#0f62fe,color:#161616
    classDef l0 fill:#78a9ff,stroke:#0043ce,color:#161616
    class L3 l3
    class L2 l2
    class L1 l1
    class L0 l0

रिपॉज़िटरी के दो स्तर और निर्भरता की दिशा

flowchart LR
    STD["<b>मानक</b><br/>standard/ · contracts/standard/<br/>नॉर्मेटिव · CC0"]
    REF["<b>संदर्भ कार्यान्वयन</b><br/>ARexToken · ARexAttestations<br/>MIT"]
    DEMO["<b>प्रदर्शन</b><br/>7 हुक · 3 एक्सटेंशन<br/>MIT · नॉर्मेटिव नहीं"]
    STD -->|इसके द्वारा कार्यान्वित| REF -->|इसके द्वारा प्रदर्शित| DEMO
    DEMO -.->|केवल इंटरफ़ेस पर निर्भर| STD

मानक कभी संदर्भ पर निर्भर नहीं होता; टोकन कभी हुक पर निर्भर नहीं होता। प्रत्येक हुक और प्रत्येक एक्सटेंशन हटा दें, फिर भी एक अनुरूप टोकन बना रहता है। यही वह गुण है जो किसी तृतीय पक्ष को इस रिपॉज़िटरी से छह इंटरफ़ेस फ़ाइलों के अलावा कुछ भी अपनाए बिना A-REX को लागू करने देता है।

बैच क्या है

बैच एक ERC-1155 टोकन आईडी है जिसके साथ एक रिकॉर्ड जुड़ा होता है:

struct Batch {
    address issuer;        // who created it (or performed the transformation)
    uint64  createdAt;
    uint8   status;        // 0 ACTIVE · 255 RETIRED (terminal) · 1..254 issuer-defined
    bytes32 commodity;     // keccak256("HS:100199"), keccak256("FAO:0111"), keccak256("GTIN:0779…")
    bytes32 unit;          // UN/CEFACT Rec. 20: "KGM", "TNE", "LTR", "BX"
    uint64  producedAt;    // 0 = not yet produced (pre-harvest)
    uint64  expiresAt;     // 0 = none
    bytes32 originRef;     // hash / reference to origin evidence — never coordinates
    bytes32 metadataHash;  // keccak256 of the off-chain document
    string  uri;           // where the document is
}

इससे अधिक समृद्ध सब कुछ — ग्रेड, नमी, प्रोटीन, पैकेजिंग, GS1 आइडेंटिफ़ायर, ट्रेसेबिलिटी लॉट कोड, EUDR घोषणा संदर्भ, प्रयोगशाला रिपोर्ट, जारीकर्ता की स्टेटस तालिका — उस मेटाडेटा दस्तावेज़ में रहता है जिसका हैश ऑन-चेन कमिट किया जाता है। यह दस्तावेज़ EPCIS 2.0 और FSMA 204 के प्रमुख डेटा तत्वों से संरेखित एक प्रकाशित JSON Schema का पालन करता है।

ट्रांसफ़र पाइपलाइन

प्रत्येक बैलेंस परिवर्तन — मिंट, ट्रांसफ़र, बर्न, बलपूर्वक ट्रांसफ़र, ट्रांसफ़ॉर्मेशन — संदर्भ टोकन में एक ही चोक पॉइंट से होकर गुज़रता है। क्रम निश्चित और ऑडिट-योग्य है:

flowchart TD
    A[safeTransferFrom / createBatch / burn / forcedTransfer / transform] --> B["रीएंट्रेंसी लॉक"]
    B --> C{"पॉज़ है?"}
    C -- हाँ, बलपूर्वक नहीं --> X1[EnforcedPause]
    C -- नहीं --> D{"from पर canSend / to पर canReceive<br/>सभी ELIGIBILITY हुक का संयोजन (AND)"}
    D -- false --> X2[ERC7943CannotSend / CannotReceive]
    D -- true --> E{"प्रत्येक id के लिए: मौजूद है? रिटायर नहीं है?<br/>amount ≤ balance − frozen?"}
    E -- विफल --> X3[ARexBatchNotFound / ARexBatchRetired /<br/>ERC7943InsufficientUnfrozenBalance]
    E -- ठीक --> F{"प्रत्येक id, प्रत्येक CHECK हुक के लिए क्रम से:<br/>check → code"}
    F -- code ≠ 0 --> X4["ARexHookRejected(hook, code)"]
    F -- सभी 0 --> G["बैलेंस अपडेट · कुल आपूर्ति दर्ज"]
    G --> H["प्रत्येक id, प्रत्येक EXECUTED हुक के लिए: onExecuted"]
    H --> I["अनलॉक"]

दो व्यू फ़ंक्शन वही तर्क बिना स्थिति बदले दोहराते हैं: canTransfer (बूलियन, जैसा ERC-7943 में अपेक्षित है) और transferCheck (पहला अस्वीकृति कोड, ताकि कोई इंटरफ़ेस उपयोगकर्ता को बता सके कि क्यों)।

बलपूर्वक ट्रांसफ़र पॉज़ और पात्रता जाँचों को छोड़ देते हैं — प्रवर्तन का तब भी काम करना अनिवार्य है जब बाकी सब कुछ फ़्रीज़ हो — परंतु हुक को फिर भी OP_FORCED_TRANSFER के साथ चलाते हैं, ताकि कोई हुक, उदाहरण के लिए, ट्रांसफ़र डेटा में न्यायालय-आदेश का संदर्भ अनिवार्य कर सके।

वंशावली

transform विभाजन, मर्ज और प्रसंस्करण के लिए एकमात्र ऑपरेशन है:

graph LR
    W1["गेहूँ #1<br/>250 t · किसान"] -- "transform (री-बैच)" --> W2["गेहूँ #2<br/>100 t · क्रेता A"]
    W1 -- "transform (री-बैच)" --> W3["गेहूँ #3<br/>150 t · क्रेता B"]
    W2 -- "transform (प्रसंस्करण, TRANSFORMER_ROLE)" --> F4["आटा #4<br/>75 t · मिल"]

• री-बैचिंग (समान कमोडिटी, समान इकाई, संरक्षित मात्रा) किसी भी धारक या अनुमोदित ऑपरेटर के लिए खुली है: सदस्यों के बीच साइलो लॉट को बाँटने वाली सहकारी संस्था, डिलीवरी को मर्ज करने वाला निर्यातक।
• प्रसंस्करण (इसके अलावा कुछ भी) के लिए अतिरिक्त रूप से TRANSFORMER_ROLE आवश्यक है।
• parentsOf(4) == [2], parentsOf(2) == [1]; प्रति ऑपरेशन एक BatchTransformed इवेंट, जो निर्माण से ही एक EPCIS TransformationEvent है।

प्रवर्तन

ENFORCER_ROLE किसी भी खाते के लिए कोई भी राशि फ़्रीज़ कर सकती है (setFrozenTokens, बैलेंस से अधिक हो सकती है, जैसा ERC-7943 निर्दिष्ट करता है) और धारक की सहमति के बिना टोकन ट्रांसफ़र कर सकती है (forcedTransfer)। यही बैच टोकन को डेमो से बाहर उपयोग-योग्य बनाता है: वारंट निष्पादित करने वाला ऋणदाता, भंडारित अनाज की ज़ब्ती का आदेश देने वाला न्यायालय, ग्राहक द्वारा कुंजियाँ खो देने के बाद लॉट वापस पाने वाला वेयरहाउस। प्रत्येक प्रवर्तन कार्रवाई एक इवेंट है।

हुक

हुक पाँच फ़ंक्शन और एक स्थिर फ़्लैग बिटमैप वाला कॉन्ट्रैक्ट है। टोकन पंजीकरण के समय फ़्लैग कैश कर लेता है, इसलिए एक ट्रांसफ़र में प्रत्येक इच्छुक हुक के लिए एक बाह्य कॉल लगती है, प्रति मॉड्यूल प्रति क्षमता एक इंटरफ़ेस प्रोब नहीं। हुक को msg.sender से पता चलता है कि कौन-सा टोकन कॉल कर रहा है; एक डिप्लॉयमेंट अनेक टोकन को सेवा दे सकता है।

संदर्भ हुक तीन क्षमताओं का प्रदर्शन करते हैं:

सहायक एक्सटेंशन (हुक नहीं): CommodityPriceOracle, CarbonImmobilizationWrapper, ParametricInsurance।

एटेस्टेशन

एक सहायक कॉन्ट्रैक्ट (batch, topic) → (issuer, reference, validity) दर्ज करता है। केवल किसी विषय के लिए विश्वसनीय जारीकर्ता ही एटेस्ट कर सकते हैं; निरस्तीकरण, समाप्ति और विश्वास की हानि, तीनों isAttested को false कर देते हैं। विषय bytes32 हैं, इसलिए ERC-735 दावा विषय, Ethereum Attestation Service स्कीमा आईडी और प्रमाणन नामों के हैश, सभी मानक में किसी तालिका के बिना काम करते हैं।

कर्ता और भूमिकाएँ

मानक में कुछ भी इन भूमिकाओं को निर्धारित नहीं करता; ये वह तरीका हैं जिससे संदर्भ कार्यान्वयन अनिवार्य आवश्यकताओं ("किसी अधिकृत भूमिका तक सीमित") को लागू करता है।

डिप्लॉयमेंट के रूप

• सार्वजनिक L2 (Polygon, Arbitrum, Base, Optimism): सबसे सस्ता, सबसे अधिक संयोजनीय; कमोडिटी व्यापार और वित्तपोषण के लिए उपयुक्त जहाँ प्रतिपक्ष व्यवसाय हैं।
• अनुमति-आधारित EVM चेन: जहाँ डेटा-संरक्षण प्राधिकरण या एंकर संस्था इसे अपेक्षित करती है; EDPB स्पष्ट रूप से अनुमति-आधारित डिज़ाइनों को प्रोत्साहित करता है। मानक चेन-अज्ञेयवादी है।
• हाइब्रिड: बैच सार्वजनिक चेन पर, निर्बंधित डेटा (प्लॉट पॉलीगन, उत्पादक की पहचान) एक्सेस-नियंत्रित स्टोरेज के पीछे, जिसे मेटाडेटा से संदर्भित किया जाता है।

संदर्भ स्टैक एक Ignition मॉड्यूल या एक स्क्रिप्ट से डिप्लॉय होता है: टोकन प्रॉक्सी, एटेस्टेशन रजिस्ट्री, पात्रता और समाप्ति हुक।

डिज़ाइन निर्णय और वे विकल्प जिनकी वे जगह लेते हैं