कोर मानक

डिज़ाइन लक्ष्य: सबसे छोटा इंटरफ़ेस जिसे कोई तृतीय पक्ष लागू करेगा

किसी मानक को तब अपनाया जाता है जब उसे लागू करने की लागत अंतरसंचालनीय न होने की लागत से कम हो। A-REX Core के प्रत्येक फ़ील्ड, फ़ंक्शन और नियम को एक परीक्षा पास करनी थी: क्या अर्जेंटीना में ग्रेन एलिवेटर प्लेटफ़ॉर्म या कोलंबिया में कॉफ़ी निर्यातक की प्रणाली बनाने वाली कोई स्वतंत्र टीम अंतरसंचालनीयता के बदले यह बाध्यता स्वीकार करेगी? फ़सलों के एन्यूमरेशन, अमेरिकी ग्रेड नाम, अनिवार्य फ़ार्म रजिस्ट्री, निर्धारित पहचान स्टैक और मूल्यांकन सूत्र, सभी इस परीक्षा में विफल रहे। बैच पहचान, वंशावली, प्रवर्तन और एक एक्सटेंशन बिंदु उसमें उत्तीर्ण हुए।

फ़ील्ड-दर-फ़ील्ड बैच रिकॉर्ड

जो जान-बूझकर अनुपस्थित है: अक्षांश और देशांतर, फ़ार्म आइडेंटिफ़ायर, ग्रेड एन्यूम, नमी और प्रोटीन, सत्यापन फ़्लैग और सत्यापनकर्ता का पता, quantity फ़ील्ड (ERC-1155 सप्लाई ट्रैकिंग प्रामाणिक है), और मूल्य की कोई भी धारणा।

वंशावली एक ऑपरेशन के रूप में

PROCESSED स्थिति वाला जीवनचक्र, पर प्रसंस्कृत वस्तु बनाने का कोई तरीका नहीं — यह एक आम भूल है। ट्रेसेबिलिटी व्यवस्थाएँ स्पष्ट हैं कि ट्रांसफ़ॉर्मेशन एक इवेंट है जो इनपुट को आउटपुट से जोड़ता है: FSMA 204 का ट्रांसफ़ॉर्मेशन क्रिटिकल ट्रैकिंग इवेंट, inputQuantityList और outputQuantityList के साथ EPCIS 2.0 का TransformationEvent। किसी प्रशासक द्वारा लिखी गई पैरेंट की मैपिंग न मात्राएँ वहन करती और न एटॉमिकता।

transform(from, to, inputIds, inputAmounts, outputs, outputAmounts, processRef) एक ही ट्रांज़ैक्शन में बर्न और मिंट करता है, प्रत्येक आउटपुट पर पैरेंट दर्ज करता है, सभी मात्राओं और एक प्रक्रिया संदर्भ के साथ एक इवेंट इमिट करता है, और प्रत्येक लेग पर हुक पाइपलाइन चलाता है। विभाजन (1→n), मर्ज (n→1) और प्रसंस्करण (n→m) एक ही फ़ंक्शन हैं। संदर्भ कार्यान्वयन किसी भी धारक को अपने ही खाते में री-बैच करने देता है (समान कमोडिटी और इकाई, संरक्षित मात्रा), परंतु वस्तुओं की प्रकृति या मात्रा बदलने के लिए, या आउटपुट किसी अन्य खाते को देने के लिए, TRANSFORMER_ROLE की आवश्यकता रखता है — मिल गेहूँ को आटे में बदल सकती है, किसान गेहूँ को सोने में नहीं बदल सकता। transform के दोनों लेग हुक को OP_TRANSFORM के रूप में चलाते हैं, इसलिए जो किसान किसी लॉट का एक हिस्सा बेचता है, वह पहले उसे उसी खाते में री-लॉट करता है और फिर ट्रांसफ़र करता है; बिक्री हर ट्रांसफ़र नियम से गुज़रती है।

transform टोकनों की सीमा पार नहीं कर सकता। जब किसी क्रेता का टोकन किसी आपूर्तिकर्ता के टोकन से माल लेता है, तो नया बैच अपने मेटाडेटा में आपूर्तिकर्ता के बैच का नाम देता है: स्कीमा 1.2.0 की upstream सूची चेन आईडी, कॉन्ट्रैक्ट, टोकन आईडी और यह बताती है कि माल उससे बिना बदलाव के प्राप्त हुआ (received_from) या उससे प्रसंस्कृत हुआ (processed_from)। अपस्ट्रीम संदर्भ डाउनस्ट्रीम जारीकर्ता का दावा है, ऑन-चेन तथ्य नहीं; इसलिए इंडेक्सर, ऑडिटर और रिकॉल टूल से अपेक्षा है कि वे उसे अपस्ट्रीम टोकन से मिलाएँ और जिन संदर्भों की जाँच नहीं हो सकी उन्हें असत्यापित दिखाएँ। टोकनों के आर-पार आगे की दिशा में रिकॉल इन्हीं सूचियों को पढ़ता है, क्योंकि अपस्ट्रीम टोकन इनका कोई रिकॉर्ड नहीं रखता।

प्रवर्तन ERC-7943 से, नए सिरे से नहीं गढ़ा गया

कृषि लॉट पर नियमित रूप से ग्रहणाधिकार, वारंट, एम्बार्गो, दिवाला कार्यवाहियाँ और रिकॉल लागू होते हैं। जो टोकन किसी अधिकृत पक्ष द्वारा धारक की इच्छा के विरुद्ध फ़्रीज़ या ट्रांसफ़र नहीं किया जा सकता, वह ऐसे लॉट का निरूपण बैंक, न्यायालय या नियामक के सामने नहीं कर सकता। ERC-3643 ने 2021 में प्रतिभूतियों के लिए इसे हल किया; ERC-7943 ने इसे किसी भी वास्तविक-जगत परिसंपत्ति के लिए सामान्यीकृत किया और मई 2026 में ERC-1155 संस्करण के साथ Final स्थिति तक पहुँचा। A-REX उस इंटरफ़ेस को अपना स्वयं का परिभाषित करने के बजाय शब्दशः अपनाता है, ताकि ERC-7943-जागरूक अनुपालन इंजन (Chainlink ACE, ERC-3643 टूलिंग) बिना अनुकूलन के A-REX टोकन को पहचान लें।

मल्टी-टोकन संस्करण ERC-1155 में स्वाभाविक रूप से बैठता है: फ़्रीज़ करना प्रति खाता और प्रति बैच आईडी होता है, बलपूर्वक ट्रांसफ़र बैच का नाम बताते हैं, पात्रता प्रति खाता होती है।

एक हुक, क्रमबद्ध, कोड के साथ

पाँच क्षमता इंटरफ़ेस पर बना मॉड्यूल सिस्टम, जिनमें से प्रत्येक की प्रत्येक ट्रांसफ़र पर supportsInterface से जाँच की जाती है, स्केल नहीं करता; आठ मॉड्यूल और बैच ट्रांसफ़र में पाँच आईडी के साथ किसी भी नियम के चलने से पहले अस्सी स्थिर कॉल हो जाती थीं। अस्वीकृतियाँ मुक्त-रूप स्ट्रिंग थीं जिन्हें कोई इंडेक्सर समझ नहीं सकता था और कोई टेस्ट विश्वसनीय रूप से तुलना नहीं कर सकता था।

A-REX Core एक हुक इंटरफ़ेस परिभाषित करता है, जिसमें पंजीकरण के समय कैश किया गया स्थिर फ़्लैग बिटमैप होता है। टोकन हुक का निश्चित क्रम में मूल्यांकन करता है और पहले गैर-शून्य bytes32 कोड पर रुक जाता है, ARexHookRejected(hook, code) के साथ रिवर्ट करते हुए। क्रम ऑडिट-योग्य है (getHooks), हटाने पर वह बना रहता है, और हुक को msg.sender से कॉल करने वाले टोकन का पता चलता है, इसलिए एक डिप्लॉयमेंट अनेक टोकन की सेवा करता है। पात्रता (canSend/canReceive) को उसी इंटरफ़ेस में समाहित किया गया है ताकि टोकन के ERC-7943 व्यू उसके हुक का संयोजन हों।

हुक से कस्टम एरर के बजाय कोड क्यों? क्योंकि check एक व्यू है जिसका संयोज्य होना अनिवार्य है: टोकन को प्रत्येक हुक से पूछना, उत्तरों की तुलना करना, और रिवर्ट किए बिना transferCheck के माध्यम से पहला उत्तर उपलब्ध कराना होता है। कोड सस्ते, इंडेक्स-योग्य, अनुवाद-योग्य और नेमस्पेस-युक्त हैं (keccak256("AREX:BATCH_EXPIRED"), keccak256("MYHOOK:QUOTA"))।

प्रति बैच एटेस्टेशन, प्रति विषय जारीकर्ता

किसी उत्पादक को प्रमाणित करना एक पहचान समस्या है जिसके परिपक्व समाधान हैं (ONCHAINID, Ethereum Attestation Service, वेरिफ़ायबल क्रेडेंशियल, राष्ट्रीय e-ID)। किसी लॉट को प्रमाणित करना वही है जो क्रेता, सीमा शुल्क अधिकारी और नियामक सत्यापित करते हैं, और उसका कोई मानक रूप नहीं था। IARexAttest (batch, topic) → (issuer, reference, validity) दर्ज करता है और प्रशासक को यह तय करने देता है कि कौन-सा जारीकर्ता किस विषय पर एटेस्ट कर सकता है, जो ERC-3643 की विश्वसनीय-जारीकर्ता रजिस्ट्री को प्रतिबिंबित करता है, बिना किसी पहचान प्रदाता को निर्धारित किए। विषय खुले bytes32 हैं, इसलिए ERC-735 दावा विषय, EAS स्कीमा आईडी और प्रमाणन नामों के हैश साथ-साथ मौजूद रह सकते हैं।

isAttested वह एकमात्र प्रश्न है जो कोई हुक पूछता है: यह false है यदि एटेस्टेशन अनुपस्थित, निरस्त या समाप्त है, या उसके जारीकर्ता ने विश्वास खो दिया है। इससे हुक छह पंक्तियों में "कॉफ़ी बैच को बेचे जाने से पहले EUDR ड्यू-डिलिजेंस संदर्भ चाहिए" लागू कर सकता है।

किसी एटेस्टेशन का जारीकर्ता उसे हमेशा निरस्त कर सकता है, और जारीकर्ता द्वारा प्रत्यायोजित कोई निरस्तकर्ता भी कर सकता है, जैसा W3C क्रेडेंशियल स्टेटस सूचियों और ERC-3643 दावा जारीकर्ताओं में होता है। ADR-019 (प्रस्तावित) के साथ रखे गए मसौदे में टोकन या एटेस्टेशन कॉन्ट्रैक्ट का कोई प्रशासक 2.x में ऐसा एटेस्टेशन निरस्त करने में सक्षम नहीं होना चाहिए जिसे उसने जारी नहीं किया, और संस्करण 3.0 से यह वर्जित है; जो 2.x कार्यान्वयन यह अधिकार बनाए रखता है, वह जारीकर्ताओं और एटेस्टेशन पर निर्भर पक्षों के लिए इसे प्रलेखित करता है। जो ऑपरेटर किसी प्रमाणपत्र को गलत मानता है, वह उसे निरस्त नहीं करता: वह उसे ऑफ़-चेन विवादित चिह्नित करता है और जारीकर्ता को सूचित करता है; जो टोकन अब किसी जारीकर्ता पर निर्भर नहीं रहता, वह उसे विषय से हटा देता है, जिससे उस टोकन के लिए उसके एटेस्टेशन false हो जाते हैं।

मानक क्या नहीं कहता

• यह नहीं कहता कि बैच कौन बना सकता है, स्टेटस कौन बदल सकता है या प्रवर्तन कौन कर सकता है — केवल इतना कि ये भूमिकाएँ हैं, कभी बैलेंस नहीं।
• यह नहीं कहता कि स्टेटस 1..254 का क्या अर्थ है; जारीकर्ता मेटाडेटा में तालिका प्रकाशित करता है।
• यह नहीं कहता कि बैच का मूल्यांकन कैसे हो, वह कैसे क्षय हो, सीज़नल रूप से उसका व्यापार कब हो सकता है, उसकी डिलीवरी या बीमा कैसे हो: ये सब हुक या सहायक कॉन्ट्रैक्ट हैं।
• यह नहीं कहता कि कौन-सी चेन, कौन-सा पहचान प्रदाता, कौन-सा ऑरेकल, कौन-सी रजिस्ट्री।
• यह नहीं कहता कि टोकन प्रतिभूति है या कमोडिटी।
• यह नहीं कहता कि किसी क्षमता का उपयोग कौन कर सकता है, वह चालू है या नहीं, या कौन-सी सूचियाँ और प्राधिकरण लागू होते हैं: प्रवर्तन भूमिका किसके पास है, पॉज़ कौन कर सकता है, कौन-सी प्रतिबंध सूचियाँ मान्य हैं। ADR-019 (प्रस्तावित) इसे प्रति क्षेत्राधिकार और संगठन एक संस्करणित नीति प्रोफ़ाइल में रखता है, ताकि कानून में बदलाव प्रोफ़ाइल का अपडेट हो, कोई नया कॉन्ट्रैक्ट या मानक का नया संस्करण नहीं।

वे सबक जिन्होंने डिज़ाइन को आकार दिया

पश्चगामी संगतता

A-REX Core टोकन पूर्ण ERC-1155 और ERC-7943 टोकन हैं। ERC-1155 को जानने वाले वॉलेट, मार्केटप्लेस और इंडेक्सर बिना बदलाव के काम करते हैं; ERC-7943-जागरूक अनुपालन टूलिंग प्रवर्तन सतह को पहचानती है। अन्य टोकनों के लिए लिखे गए नियम इंजन IARexHook एडेप्टर के माध्यम से जुड़ते हैं, बशर्ते उनके निर्णय केवल कॉल पैरामीटर और बैच रिकॉर्ड पर निर्भर करते हों।