श्वेतपत्र · 04
समाधान अवलोकन
A-REX Core की आर्किटेक्चर: निर्भरता की एक दिशा वाले तीन स्तर, ट्रांसफ़र पाइपलाइन, कर्ता, और घटकों को कैसे डिप्लॉय किया जाता है।
तीन स्तर, निर्भरता की एक दिशा
A-REX उस चीज़ को, जिसे मानकीकृत होना चाहिए, उस चीज़ से अलग करता है जिसे केवल काम करना चाहिए:
मानक की चार परतें
flowchart TB
L3["परत 3 · IARexAttest<br/>बैच और विषय के अनुसार साक्ष्य"]
L2["परत 2 · IARexHook + IARexHookManager<br/>नियमों की एक क्रमबद्ध पाइपलाइन"]
L1["परत 1 · IARexBatch<br/>पहचान, स्थिति, मेटाडेटा प्रतिबद्धता और वंश"]
L0["परत 0 · ERC-1155 + ERC-165 + IERC7943MultiToken<br/>शेष और प्रवर्तन सतह"]
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मानक कभी संदर्भ पर निर्भर नहीं होता; टोकन कभी हुक पर निर्भर नहीं होता। प्रत्येक हुक और प्रत्येक एक्सटेंशन हटा दें, फिर भी एक अनुरूप टोकन बना रहता है। कोई तृतीय पक्ष नॉर्मेटिव पाठ शीघ्र पहुँच से प्राप्त करता है, इस सार्वजनिक अध्याय से नहीं।
बैच क्या है
बैच एक ERC-1155 टोकन आईडी है। फ़ील्ड का अभिन्यास नॉर्मेटिव पाठ में रहता है।
इससे अधिक समृद्ध सब कुछ — ग्रेड, नमी, प्रोटीन, पैकेजिंग, 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इवेंट, जो निर्माण से ही एक EPCISTransformationEventहै।
प्रवर्तन
ENFORCER_ROLE किसी भी खाते के लिए कोई भी राशि फ़्रीज़ कर सकती है (setFrozenTokens, बैलेंस से अधिक हो सकती है, जैसा ERC-7943 निर्दिष्ट करता है) और धारक की सहमति के बिना टोकन ट्रांसफ़र कर सकती है (forcedTransfer)। यही बैच टोकन को डेमो से बाहर उपयोग-योग्य बनाता है: वारंट निष्पादित करने वाला ऋणदाता, भंडारित अनाज की ज़ब्ती का आदेश देने वाला न्यायालय, ग्राहक द्वारा कुंजियाँ खो देने के बाद लॉट वापस पाने वाला वेयरहाउस। प्रत्येक प्रवर्तन कार्रवाई एक इवेंट है।
हुक
हुक पाँच फ़ंक्शन और एक स्थिर फ़्लैग बिटमैप वाला कॉन्ट्रैक्ट है। टोकन पंजीकरण के समय फ़्लैग कैश कर लेता है, इसलिए एक ट्रांसफ़र में प्रत्येक इच्छुक हुक के लिए एक बाह्य कॉल लगती है, प्रति मॉड्यूल प्रति क्षमता एक इंटरफ़ेस प्रोब नहीं। हुक को msg.sender से पता चलता है कि कौन-सा टोकन कॉल कर रहा है; एक डिप्लॉयमेंट अनेक टोकन को सेवा दे सकता है।
संदर्भ हुक तीन क्षमताओं का प्रदर्शन करते हैं:
| हुक | क्षमता | यह क्या सिद्ध करता है |
|---|---|---|
EligibilityHook | CHECK + ELIGIBILITY | अनुमति/ब्लॉक सूचियाँ और प्रतिबंध फ़ीड canSend / canReceive को संचालित करते हैं और सटीक कोड उत्पन्न करते हैं |
ExpiryHook | CHECK | नाशवानता और कटाई-पूर्व गेटिंग, जो पूरी तरह बैच रिकॉर्ड से व्युत्पन्न है |
AttestationHook | CHECK | "कॉफ़ी को बेचे जाने से पहले एटेस्ट की गई EUDR घोषणा चाहिए" |
PerishabilityHook | CHECK | क्षय मॉडल और मूल्य व्यू; समाप्त या मूल्यहीन लॉट आगे नहीं बढ़ते |
SeasonalHook | CHECK | प्रति कमोडिटी कटाई और व्यापार विंडो |
DeliveryHook | CHECK + EXECUTED | डिलीवरी के दौरान अभिरक्षा लॉक; निपटान स्वयं ट्रांसफ़र है, जिसकी पहचान data से होती है |
TraceabilityHook | EXECUTED | प्रत्येक ऑपरेशन का EPCIS-आकार का इवेंट लॉग तथा मैन्युअल क्रिटिकल ट्रैकिंग इवेंट |
सहायक एक्सटेंशन (हुक नहीं): CommodityPriceOracle, CarbonImmobilizationWrapper, ParametricInsurance।
एटेस्टेशन
एक सहायक कॉन्ट्रैक्ट (batch, topic) → (issuer, reference, validity) दर्ज करता है। केवल किसी विषय के लिए विश्वसनीय जारीकर्ता ही एटेस्ट कर सकते हैं; निरस्तीकरण, समाप्ति और विश्वास की हानि, तीनों isAttested को false कर देते हैं। विषय bytes32 हैं, इसलिए ERC-735 दावा विषय, Ethereum Attestation Service स्कीमा आईडी और प्रमाणन नामों के हैश, सभी मानक में किसी तालिका के बिना काम करते हैं।
कर्ता और भूमिकाएँ
| कर्ता | संदर्भ टोकन में विशिष्ट भूमिका | विशिष्ट कार्रवाई |
|---|---|---|
| ओरिजिनेटर प्लेटफ़ॉर्म, सहकारी संस्था, ग्रेन एलिवेटर | ISSUER_ROLE | createBatch |
| किसान / धारक | कोई नहीं | ट्रांसफ़र, री-बैच, बर्न |
| मिल, पैकर, प्रोसेसर | TRANSFORMER_ROLE | प्रसंस्करण transform |
| वेयरहाउस, निरीक्षक, प्लेटफ़ॉर्म | STATUS_ROLE | setBatchStatus, setBatchMetadata |
| प्रमाणक, प्रयोगशाला, प्राधिकरण | किसी विषय के लिए विश्वसनीय जारीकर्ता | attest |
| ऋणदाता, न्यायालय-नियुक्त अभिरक्षक, अनुपालन | ENFORCER_ROLE | setFrozenTokens, forcedTransfer |
| गवर्नेंस (मल्टीसिग, टाइमलॉक) | DEFAULT_ADMIN_ROLE, HOOK_ADMIN_ROLE, UPGRADER_ROLE, PAUSER_ROLE | भूमिकाएँ, हुक, अपग्रेड, पॉज़ |
मानक में कुछ भी इन भूमिकाओं को निर्धारित नहीं करता; ये वह तरीका हैं जिससे संदर्भ कार्यान्वयन अनिवार्य आवश्यकताओं ("किसी अधिकृत भूमिका तक सीमित") को लागू करता है।
डिप्लॉयमेंट के रूप
- सार्वजनिक L2 (Polygon, Arbitrum, Base, Optimism): सबसे सस्ता, सबसे अधिक संयोजनीय; कमोडिटी व्यापार और वित्तपोषण के लिए उपयुक्त जहाँ प्रतिपक्ष व्यवसाय हैं।
- अनुमति-आधारित EVM चेन: जहाँ डेटा-संरक्षण प्राधिकरण या एंकर संस्था इसे अपेक्षित करती है; EDPB स्पष्ट रूप से अनुमति-आधारित डिज़ाइनों को प्रोत्साहित करता है। मानक चेन-अज्ञेयवादी है।
- हाइब्रिड: बैच सार्वजनिक चेन पर, निर्बंधित डेटा (प्लॉट पॉलीगन, उत्पादक की पहचान) एक्सेस-नियंत्रित स्टोरेज के पीछे, जिसे मेटाडेटा से संदर्भित किया जाता है।
संदर्भ स्टैक एक Ignition मॉड्यूल या एक स्क्रिप्ट से डिप्लॉय होता है: टोकन प्रॉक्सी, एटेस्टेशन रजिस्ट्री, पात्रता और समाप्ति हुक।
डिज़ाइन निर्णय और वे विकल्प जिनकी वे जगह लेते हैं
| विचार किया गया विकल्प | A-REX Core | कारण |
|---|---|---|
| कमोडिटी, ग्रेड, स्थिति के लिए एन्यूम वाला चौड़ा कोर इंटरफ़ेस | खुले कोड वाला 8-फ़ंक्शन IARexBatch | नई फ़सल, योजना या जीवनचक्र के लिए कुछ भी रीडिप्लॉय नहीं करना पड़ता |
| प्रत्येक ट्रांसफ़र पर प्रोब किए जाने वाले क्षमता इंटरफ़ेस | एक हुक इंटरफ़ेस, फ़्लैग कैश किए गए | गैस हुक के अनुपात में रैखिक है, id × मॉड्यूल × प्रोब के अनुपात में नहीं |
| स्ट्रिंग कारण | bytes32 कोड और टाइप्ड एरर | मशीन-पठनीय, इंडेक्स-योग्य |
| जीवनचक्र स्थिति को कोई भी धारक बदल सके | केवल भूमिका; RETIRED अंतिम | सुरक्षा |
| कटाई की तिथि अतीत में अनिवार्य | producedAt == 0 की अनुमति | कटाई-पूर्व वित्तपोषण |
| कोई विभाजन / मर्ज / प्रसंस्करण नहीं | transform + parentsOf | ट्रेसेबिलिटी, रिकॉल, EPCIS |
| कोई फ़्रीज़ या बलपूर्वक ट्रांसफ़र नहीं | ERC-7943 | प्रवर्तन-योग्यता |
| निर्देशांक ऑन-चेन संग्रहीत | केवल उद्गम संदर्भ | GDPR / EDPB 02/2025 |
| रजिस्ट्री और पहचान कॉन्ट्रैक्ट आवश्यक | कुछ भी आवश्यक नहीं | कोई थोपा गया पहचान स्टैक नहीं |