हुक और संदर्भ मॉड्यूल

मॉड्यूल प्रदर्शन हैं, मानक नहीं

A-REX Core और उसके मॉड्यूल के बीच वही संबंध है जो ERC-3643 और T-REX के अनुपालन मॉड्यूल के बीच है: जिस इंटरफ़ेस से मॉड्यूल जुड़ते हैं वह मानकीकृत है; मॉड्यूल नहीं। शून्य हुक वाला अनुरूप टोकन एक वैध A-REX टोकन है। किसी के भी द्वारा लिखा गया हुक प्रत्येक अनुरूप टोकन के साथ संगत है। यही इकोसिस्टम को मानक बदले बिना बढ़ने देता है।

graph LR
    T[ARexToken<br/>अनुरूप टोकन] -->|"check / onExecuted / canSend / canReceive"| H1[EligibilityHook]
    T --> H2[ExpiryHook]
    T --> H3[AttestationHook]
    T --> H4["आपका हुक"]
    H3 --> A[ARexAttestations]

हुक कॉन्ट्रैक्ट

op इनमें से एक है: OP_MINT (1), OP_TRANSFER (2), OP_BURN (3), OP_FORCED_TRANSFER (4), OP_TRANSFORM (5)। ट्रांसफ़ॉर्मेशन में इनपुट to == 0 के साथ और आउटपुट from == 0 के साथ आते हैं। data ERC-1155 ट्रांसफ़र डेटा है; ट्रांसफ़ॉर्म के लिए abi.encode(processRef), बलपूर्वक ट्रांसफ़र के लिए खाली।

कॉल करने वाला टोकन msg.sender है। जिस हुक को बैच की आवश्यकता हो वह IARexBatch(msg.sender).batchOf(id) पढ़ता है। तैनाती के समय एक ही टोकन से बंधा हुक (ADR-025, प्रस्तावित) उसे token() के रूप में बताता है और किसी अन्य पते से आई कॉल अस्वीकार करता है।

जब एक से अधिक नियम data पढ़ते हैं, तो ADR-023 (प्रस्तावित) उसे एक टैग किया हुआ लिफ़ाफ़ा बनाता है: अधिकतम 8 (bytes32 key, bytes32 value) प्रविष्टियाँ, जिनकी कुंजियाँ कोड की तरह नेमस्पेस में होती हैं (keccak256("AREX:DELIVERY_ID"), keccak256("AREX:DOCUMENT_REF")), और प्रत्येक नियम केवल अपनी कुंजी पढ़ता है। 32 बाइट का data हर नियम के लिए वही एकमात्र अर्थ रखता है जो उसका पहले था; इसके अलावा कुछ भी हो तो कोई मान नहीं है, और पढ़ना कभी रिवर्ट नहीं होता। लिफ़ाफ़े से पहले लिखा गया नियम उसे "कोई मान नहीं" के रूप में पढ़ता है, इसलिए प्रेषक लिफ़ाफ़ा तभी बनाता है जब टोकन के data पढ़ने वाले सभी नियम लिफ़ाफ़े पढ़ते हों। संदर्भ DeliveryHook और TraceabilityHook रिलीज़ 2.0.0-alpha.7 से ऐसा करते हैं।

संदर्भ हुक

EligibilityHook — अनुमति, ब्लॉक, प्रतिबंध

HOOK_ELIGIBILITY का प्रदर्शन करता है। एक वैकल्पिक अनुमति सूची, एक ब्लॉक सूची और एक प्रतिबंध सूची रखता है; canSend/canReceive उनका संयोजन लौटाते हैं; check SANCTIONED, SENDER_INELIGIBLE या RECEIVER_INELIGIBLE लौटाता है ताकि इंटरफ़ेस इनकार का कारण समझा सकें। बलपूर्वक ट्रांसफ़र की हमेशा अनुमति है: किसी प्रतिबंधित खाते से माल ज़ब्त करना ही प्रवर्तन का उद्देश्य है। प्रोडक्शन में सूचियाँ किसी पहचान रजिस्ट्री (ONCHAINID, EAS, वेरिफ़ायबल क्रेडेंशियल) या प्रतिबंध ऑरेकल से भरी जाती हैं; हुक को इससे फ़र्क नहीं पड़ता कि कौन-सा।

ExpiryHook — मॉड्यूल के बिना नाशवानता

स्टेटलेस। बैच से expiresAt और producedAt पढ़ता है। समाप्त हो चुके बैच के मिंट और ट्रांसफ़र को ब्लॉक करता है (BATCH_EXPIRED), पर बर्न (बट्टे खाते) या बलपूर्वक ट्रांसफ़र (प्रवर्तन) को नहीं। वैकल्पिक रूप से उन बैच के ट्रांसफ़र ब्लॉक करता है जो अभी उत्पादित नहीं हुए (BATCH_NOT_PRODUCED) — कटाई-पूर्व वित्तपोषण करने वाला प्लेटफ़ॉर्म उन्हें अनुमति देने के लिए फ़्लैग सेट करता है; स्पॉट मार्केटप्लेस उन्हें ब्लॉक करने के लिए। यह एक हुक नाशवानता का ब्लॉक करने वाला भाग कवर करता है; क्षय वक्र एक व्यू हेल्पर या ऑफ़-चेन मूल्यांकन बन जाते हैं।

AttestationHook — प्रति कमोडिटी विनियामक गेटिंग

कमोडिटी कोड को आवश्यक एटेस्टेशन विषय से मैप करता है। ट्रांसफ़र से पहले बैच पढ़ता है, आवश्यकता खोजता है, एटेस्टेशन रजिस्ट्री से isAttested पूछता है और अन्यथा ATTESTATION_MISSING लौटाता है। "कॉफ़ी को EUDR ड्यू-डिलिजेंस संदर्भ चाहिए", "जैविक-लेबल वाले बैच को वैध जैविक प्रमाणपत्र चाहिए", "मवेशी को स्वास्थ्य प्रमाणपत्र चाहिए" में से प्रत्येक setRequirement की एक कॉल है। संदर्भ रिलीज़ 2.0.0-alpha.7 से इसका स्वामी checksTransform चालू कर सकता है (डिफ़ॉल्ट रूप से बंद): तब किसी transform के इनपुट बैचों को भी अपना प्रमाणपत्र चाहिए, इसलिए TRANSFORMER_ROLE वाला धारक किसी अप्रमाणित बैच को नए बैच के रूप में किसी अन्य खाते को नहीं सौंप सकता। आउटपुट नए बैच होते हैं और उनकी जाँच नहीं होती।

PerishabilityHook — क्षय मॉडल

प्रति कमोडिटी कोड क्षय कॉन्फ़िगरेशन, प्रति बैच ओवरराइड के साथ; मॉडल NONE, LINEAR (समाप्ति पर एक न्यूनतम स्तर तक), EXPONENTIAL (अर्ध-आयु) और STEP (प्रत्येक अंतराल पर गिरावट)। व्यू valueBps, secondsRemaining, isExpired। समाप्त बैच के मिंट और ट्रांसफ़र (BATCH_EXPIRED) तथा उन बैच के ट्रांसफ़र को ब्लॉक करता है जिनका शेष मूल्य शून्य है (PERISH:NO_VALUE); बर्न या प्रवर्तन को कभी ब्लॉक नहीं करता।

SeasonalHook — कटाई और व्यापार विंडो

प्रति कमोडिटी और ऑपरेशन निरपेक्ष [start, end] विंडो (प्रति कुंजी अधिकतम 16)। बिना विंडो वाली कमोडिटी/ऑपरेशन निर्बंध-रहित है। सामान्य उपयोग: OP_MINT कटाई विंडो तक सीमित, OP_TRANSFER व्यापार विंडो तक; अन्यथा SEASON_CLOSED। संदर्भ रिलीज़ 2.0.0-alpha.7 से कोई मैनेजर किसी विंडो को उसकी सीमाओं से हटाता है (removeWindow), कभी उसकी स्थिति से नहीं, और समाप्त हो चुकी विंडो जगह खाली करती हैं: जब कोई कुंजी भरी हो, तो नई विंडो जोड़ने से पहले उसकी समाप्त विंडो हटा दी जाती हैं। हर हटाव WindowRemoved इमिट करता है, ताकि इंडेक्सर इवेंट से विंडो फिर से बना सके।

DeliveryHook — अभिरक्षा और निपटान

प्रेषक किसी वाहक के माध्यम से किसी प्राप्तकर्ता को amount इकाइयों की डिलीवरी शेड्यूल करता है; इकाइयाँ लॉक हो जाती हैं (एक O(1) काउंटर, इसलिए check इतिहास पर कभी इटरेट नहीं करता)। वाहक और सेंसर पिकअप, ट्रांज़िट और तापमान रीडिंग (उल्लंघन फ़्लैग) दर्ज करते हैं; प्राप्तकर्ता डिलीवरी की पुष्टि करता है; विवाद मध्यस्थ के पास जाते हैं। निपटान स्वयं ERC-1155 ट्रांसफ़र है: प्रेषक → प्राप्तकर्ता, सटीक मात्रा, data में डिलीवरी की संख्या (32 बाइट, abi.encode(deliveryId), या रिलीज़ 2.0.0-alpha.7 से किसी लिफ़ाफ़े की AREX:DELIVERY_ID प्रविष्टि) के साथ; check इसे केवल तब अनुमति देता है जब डिलीवरी DELIVERED हो और onExecuted उसे SETTLED चिह्नित करके अनलॉक कर देता है। मुक्त (अनलॉक्ड) इकाइयाँ चलती रहती हैं। लॉक की गई इकाइयों को ट्रांसफ़र, बर्न या किसी transform के इनपुट के रूप में उपयोग नहीं किया जा सकता: check ऐसे किसी भी ऑपरेशन के लिए IN_TRANSIT लौटाता है जो धारक के बैलेंस को लॉक की गई मात्रा से नीचे ले जाए, सिवाय निपटान ट्रांसफ़र, मिंट और फ़ोर्स्ड ट्रांसफ़र के। किसी फ़ोर्स्ड ट्रांसफ़र द्वारा लॉक की गई इकाइयाँ ज़ब्त कर लिए जाने के बाद भी check रिवर्ट होने के बजाय एक कोड लौटाता है। संदर्भ रिलीज़ 2.0.0-alpha.7 से टोकन द्वारा फ़्रीज़ की गई इकाइयाँ (ERC-7943 getFrozenTokens) डिलीवरी शेड्यूल करने के लिए मुक्त नहीं हैं (freeUnits बताता है कि कितनी मुक्त हैं); जिस डिलीवरी की इकाइयाँ किसी फ़ोर्स्ड ट्रांसफ़र ने ले लीं, उसे डिलीवर के रूप में पुष्ट या स्वीकार नहीं किया जा सकता (LockedUnitsMoved), क्योंकि उसका निपटान कभी नहीं हो सकता, पर उस पर अब भी विवाद उठाया और उसे लौटाया जा सकता है; और ऐसी तापमान सीमा अस्वीकार की जाती है जिसका न्यूनतम उसके अधिकतम से कम न हो (InvalidRange)।

TraceabilityHook — EPCIS-आकार का इवेंट लॉग

प्रत्येक टोकन ऑपरेशन का अवलोकन करता है और उसे CBV बिज़नेस स्टेप (commissioning, shipping, destroying, transforming) तथा डिस्पोज़िशन (active, in_transit, destroyed, seized) से वर्गीकृत करता है; RECORDER_ROLE टोकन से असंबद्ध क्रिटिकल ट्रैकिंग इवेंट (कूलिंग, पैकिंग, प्राप्ति) readPoint और bizLocation के साथ दर्ज करती है। दो मोड: केवल-इमिट (प्रति ट्रांसफ़र लगभग +17 k गैस; इंडेक्सर लॉग फिर से बनाता है) या पर्सिस्ट (लगभग +184 k; getEvents ऑन-चेन उत्तर देता है, पेज-वार)। हुक का संस्करण 2, संदर्भ रिलीज़ 2.0.0-alpha.7 में, डिप्लॉयमेंट के समय एक ही टोकन से बँधा होता है: केवल वही टोकन ऑपरेशन की सूचना देता है, और recordEvent केवल उन्हीं बैचों को स्वीकार करता है जो उस पर मौजूद हैं, इसलिए कोई भी टोकन के नाम पर प्रविष्टियाँ नहीं लिख सकता। इसका EPCISEvent किसी प्रविष्टि के सभी फ़ील्ड रखता है (ऑपरेशन, रीड पॉइंट, स्थान और दर्ज करने वाला), इसलिए केवल-इमिट मोड में कुछ नहीं खोता। किसी आवाजाही के दस्तावेज़ का संदर्भ 32 बाइट के data से या किसी लिफ़ाफ़े की AREX:DOCUMENT_REF प्रविष्टि से आता है, कभी किसी अन्य नियम की प्रविष्टि से नहीं। हुक को अपग्रेड नहीं किया जा सकता: संस्करण 1 के इंस्टेंस और उनके इवेंट जैसे थे वैसे रहते हैं, और संस्करण 2 एक नया डिप्लॉयमेंट है।

CompanyFactsHook — किसी कंपनी के अपने रिकॉर्ड

केवल HOOK_EXECUTED का प्रदर्शन करता है: यह कभी कोई ऑपरेशन अस्वीकार नहीं करता, इसका onExecuted कभी revert नहीं होता, और यह एक ही टोकन से बंधा है। यह कंपनी के अपने रिकॉर्ड उसी तरह दर्ज करता है जैसे मानक का शब्दावली डिस्क्रिप्टर उनका वर्णन करता है (interop/VOCABULARY.md, "Records on the ledger"): किसी लॉट, किसी साइट या कंपनी के बारे में तथ्य (एक recordHash और अधिकतम 8 सार्वजनिक मान), चरण चिह्न (बिट इंडेक्स 0–255 पर नमक लगे चरण संदर्भ, प्रति लेनदेन एक या अधिकतम 50), किसी दूसरी कंपनी के टोकन से प्राप्त चरण, दैनिक एंकर (एक Merkle रूट और एक गिनती) और रद्दीकरण। हर लेखन में एक approvalHash होता है, यानी कंपनी के उस रिकॉर्ड का हैश जो बताता है कि इसे किसने स्वीकृत किया। कंपनी का Safe परिभाषाएँ और चरण पंजीकृत करता है; एक रिकॉर्डर कुंजी, जिसे सौंपा जा सकता है, रिकॉर्ड लिखती है। transform पर यह हर मूल लॉट द्वारा पार किए गए चरण आउटपुट तक ले जाता है। किसी प्रक्रिया प्रकार का चरण यह केवल उसी ब्लॉक में प्रतिबद्ध processRef (commitRun) के लिए जोड़ता है, और हर प्रतिबद्धता केवल एक बार मानी जाती है। इसी तरह यह कस्टडी मॉडल (cocModel, मूल लॉटों में सबसे निम्न) और EUDR कवरेज (eudrCovered, मूल लॉटों का AND) आगे ले जाता है। इवेंट: FactRecorded, StageRecorded, ReceivedStageRecorded, Anchored, FactVoided, RunCommitted, StagesCarried, CustodyDeclared। संदर्भ रिलीज़ 2.0.0-alpha.9।

RequireStageHook — आवश्यक चरणों के बिना कोई डिलीवरी नहीं

CompanyFactsHook के ऊपर HOOK_CHECK का प्रदर्शन करता है। अधिकतम 16 आवश्यकताएँ, हर एक में वे ऑपरेशन जिन पर वह लागू होती है (डिलीवरी और, वैकल्पिक रूप से, किसी transform के इनपुट), कमोडिटी और वे चरण जिनसे लॉट को गुज़रना ज़रूरी है। जिस लॉट में कोई चरण नहीं है उसे REQUIRE_STAGE:MISSING के साथ अस्वीकार किया जाता है; जिस लॉट या चरण मॉड्यूल को यह पढ़ नहीं सकता उसे REQUIRE_STAGE:UNREADABLE के साथ, कभी revert से नहीं। मिंट, बर्न और कानूनी आदेश से होने वाले स्थानांतरण कभी अस्वीकार नहीं होते। हर आवश्यकता का अपना appliesFrom होता है: उससे पहले बने लॉट जाँचे नहीं जाते। कंपनी का Safe configure से आवश्यकताएँ तय करता है, इसलिए आवश्यकताएँ बदली जाने पर शुरुआती बिंदु बदल सकता है; हर बदलाव Configured उत्सर्जित करता है। संदर्भ रिलीज़ 2.0.0-alpha.9।

सहायक एक्सटेंशन

तीन चिंताओं को कभी ट्रांसफ़र नियम होने की आवश्यकता नहीं थी; वे सामान्य कॉन्ट्रैक्ट हैं जो एटेस्टेशन पढ़ते या लिखते हैं:

पुराने लॉट और नए लॉट

किसी ऐसे टोकन के लिए चालू किया गया नियम, जिसमें पहले से लॉट हैं, या तो हर लॉट पर लागू होता है या केवल किसी निश्चित समय-बिंदु से बनाए गए लॉट पर। संदर्भ ExpiryHook, AttestationHook, SeasonalHook और PerishabilityHook यह बिंदु (appliesFrom, हर लॉट के लिए 0) डिप्लॉयमेंट के समय लेते हैं। इसे बाद में बदला नहीं जा सकता, इसलिए कोई भी बाद में और लॉट को छूट नहीं दे सकता; कोई अलग चुनाव नियम का नया डिप्लॉयमेंट होता है। RequireStageHook इसका अपवाद है: उसकी हर आवश्यकता का अपना appliesFrom होता है, और कंपनी का Safe configure से आवश्यकताएँ बदल सकता है।

नियम का उपयोग करने वाली प्रणालियों के लिए उसका विवरण

कोई नियम या ऐड-ऑन अपने कोड के साथ एक arex.module/1 डिस्क्रिप्टर प्रकाशित कर सकता है। यह एक संस्करणित JSON दस्तावेज़ है जो कॉन्ट्रैक्ट के पैरामीटर और सेटिंग, उसके द्वारा पढ़े जाने वाले बैच फ़ील्ड, उसकी अपेक्षित प्रमाणपत्र-श्रेणियाँ, उसके इवेंट और अस्वीकृति कोड, तथा यह बताता है कि उसकी स्टेट नए संस्करण में कैसे आगे जाती है। कोई प्लेटफ़ॉर्म, वॉलेट, इंडेक्सर या ऑडिटर इसे पढ़कर उस नियम के लिए अलग से कोड लिखे बिना नियम को दिखा सकता है, कॉन्फ़िगर कर सकता है और किसी इनकार का कारण समझा सकता है। संशोधन 1.1 से डिस्क्रिप्टर उन ऑपरेशनों की सूची भी दे सकता है जिन्हें नियम नियंत्रित करता है (ops: mint, transfer, burn, forced_transfer, transform)। यह फ़ील्ड केवल सूचनात्मक है: इसके न होने पर ऑपरेशन अज्ञात माने जाते हैं, और कोई भी उपभोक्ता प्रवर्तन के लिए इस पर निर्भर नहीं कर सकता, क्योंकि निर्णय हुक की अपनी जाँचें करती हैं। संशोधन 1.2 दो बातें जोड़ता है। कोई सेटिंग किसी स्थान का नाम ले सकती है (ref:site): वह उस originRef के रूप में रखी जाती है जो वहाँ बने बैच साथ रखते हैं, या उस ऑफ़-चेन उत्पत्ति-साक्ष्य के संदर्भ के रूप में जो वे उसके बदले रखते हैं (उदाहरण के लिए EUDR ड्यू-डिलिजेंस विवरण), कभी पते या निर्देशांक के रूप में नहीं। और check तथा onExecuted की घोषित गैस सेटिंग भरी होने पर मापी जाती है: मापने से पहले कोई सत्यापक हर उस ऑपरेशन को, जो कोई मान सेट करता या जोड़ता है, परीक्षण मानों के साथ प्रति कुंजी setup बार बुलाता है (डिस्क्रिप्टर कुछ और न कहे तो 8, अधिकतम 32), ताकि किसी कॉन्फ़िगर की जा सकने वाली सूची पर चलने वाला नियम वह लागत घोषित करे जो सूची भरी होने पर आती है। संशोधन 1.3 वह लिखित रूप में दर्ज करता है जो डिस्क्रिप्टर का पहला उपभोक्ता पहले से इस्तेमाल करता है, ताकि उसके डिस्क्रिप्टर प्रकाशित स्कीमा की जाँच में खरे उतरें: वे कार्रवाइयाँ जिन्हें लोग एक स्वीकृति के ज़रिए दर्ज करते हैं (किसी ऐड-ऑन के रिकॉर्ड, हर एक उस भूमिका के साथ जो उसे बुला सकती है), अनुबंध की अपनी त्रुटियाँ शब्दों में, उसके रिकॉर्ड पर माप, प्रति डिलीवरी का वह डेटा जिसे कोई नियम पढ़ता है, उसकी घटनाओं का पूरा रूप उनके फ़ील्ड और शब्दों के साथ, और अधिक मान-प्रकार (एक लॉट, मॉड्यूल का एक रिकॉर्ड, छोटा पाठ, केवल अपने फ़िंगरप्रिंट से रखा गया पाठ)। इसका जोड़ा हर फ़ील्ड वैकल्पिक है, इसलिए हर पिछला डिस्क्रिप्टर मान्य बना रहता है। संशोधन 1.4 हर मान का वर्णन इतना करता है कि उससे एक फ़ॉर्म बनाया जा सके: नए मान-प्रकार (अपनी मुद्रा के साथ राशि, तारीख और समय, केवल फ़िंगरप्रिंट से रखा गया दस्तावेज़, GTIN जैसा प्रारूप वाला कोड, देश या क्षेत्र, इकाई, निर्देशिका का कोई व्यक्ति या पक्ष), खाता-बही तक क्या पहुँचता है (मान, केवल उसका फ़िंगरप्रिंट, या कुछ नहीं; व्यक्तिगत डेटा कभी नहीं), हर फ़ील्ड का शीर्षक, सहायता, उदाहरण, खंड और शर्तें, एक बंद सूची से फ़ील्डों के बीच की जाँचें, गणना किए गए मान, खाता-बही से बाहर रखे गए विवरण, लॉट के पास दिखाए जाने वाले केवल-पढ़ने वाले दृश्य, और रिकॉर्ड कैसे दिखाया जाए: हमेशा उसे दर्ज करने वाले संगठन की घोषणा के रूप में, कभी सत्यापित के रूप में नहीं। संशोधन 1.5 हर फ़िंगरप्रिंट में सॉल्ट जोड़ता है: जो डिस्क्रिप्टर fingerprint: { "scheme": "salted-jcs/1" } घोषित करता है, वह हर मान का हैश उसके अपने 32-बाइट सॉल्ट के साथ दर्ज करता है, ताकि छोटे पाठ, संख्याएँ या खेतों की रूपरेखा अनुमान लगाकर न खोजी जा सकें। संशोधन 1.6 ऐसे माप जोड़ता है जो योग नहीं हैं: count और sum के अलावा, कोई माप रिकॉर्ड के किसी संख्या फ़ील्ड का औसत, न्यूनतम या अधिकतम मान (avg, min, max) हो सकता है। इन्हें उस संख्या फ़ील्ड की ज़रूरत होती है और इन्हें समूहों या कंपनियों के बीच कभी जोड़ा नहीं जाता: दो कंपनियों का औसत उनके रिकॉर्ड का माध्य है, उनके औसतों का माध्य नहीं। माप को लॉट बनाने वाले पक्ष (party) और उसकी साइट (site) के अनुसार भी समूहित किया जा सकता है। संदर्भ रिलीज़ 2.0.0-alpha.10 का नमी ऐड-ऑन टेम्पलेट ऐसा एक माप घोषित करता है: उत्पाद और साइट के अनुसार प्राप्ति पर औसत नमी। बेसिस पॉइंट में दर्ज किसी मान पर बना माप unit: "bp" घोषित करता है, और उपभोक्ता उसे 100 से भाग देकर प्रतिशत के रूप में दिखाता है। संशोधन 1.7 किसी फ़ील्ड के visibleWhen को उसी फ़ॉर्म के अन्य फ़ील्ड पर शब्दावली डिस्क्रिप्टर का शर्त-वृक्ष लेने देता है: { field, op, value } पत्तियाँ, जो all, any और not से जुड़ती हैं, अधिकतम 3 स्तर और 12 पत्तियाँ, कभी कोई अभिव्यक्ति नहीं और कभी रिकॉर्ड का संदर्भ नहीं। संशोधन 1.4 की एकल शर्त मान्य रहती है, अप्रचलित है, और समतुल्य पत्ती के रूप में पढ़ी जाती है।

डिस्क्रिप्टर सूचनात्मक और प्रस्तावित है: इसका प्रस्ताव A-REX Platform ने रखा है, जो इसका पहला उपभोक्ता है, और यह तब अनुशंसित प्रारूप बनता है जब कोई दूसरा, स्वतंत्र कार्यान्वयनकर्ता इसका उपयोग करे। कोई नियम बैच के मेटाडेटा दस्तावेज़ में जो फ़ील्ड जोड़ता है, वे extensions.<key> के अंतर्गत रहेंगे और डिस्क्रिप्टर के स्कीमा अंश से मान्य किए जाएँगे (ADR-017, प्रस्तावित, मेटाडेटा स्कीमा 1.3.0 के लिए)।

कोई संगठन अपनी शब्दावली को arex.vocab/1 परिभाषाओं के रूप में भी प्रकाशित कर सकता है: खेत के काम के प्रकार (छंटाई, मिट्टी का नमूना), प्रक्रिया के प्रकार (72 घंटे का किण्वन, छलनी आकार के अनुसार छँटाई) और प्रत्येक उत्पाद के लिए चरणों की सूचियाँ (कटाई, सुखाना, छिलका उतारना, ग्रेडिंग, निर्यात)। ये डेटा हैं, कोड नहीं। प्रत्येक परिभाषा डिस्क्रिप्टर के फ़ील्ड ऑब्जेक्ट का उपयोग करती है, अपना संस्करण बताती है, और एक संदर्भ चरण वर्ग तथा एक GS1 CBV व्यावसायिक चरण से जुड़ी होती है, ताकि संगठन को न जानने वाला पाठक भी उसे समझ सके। प्रक्रिया का प्रकार एक प्रकार वाला transform है, कभी कोई नया ऑपरेशन नहीं: इसका processRef प्रकार का 4-बाइट टैग और उस प्रक्रिया के मानों का फ़िंगरप्रिंट रखता है, इसलिए कोई नियम प्रकार के आधार पर काम कर सकता है और कोई भी प्रक्रिया की जाँच कर सकता है। रिकॉर्ड एक-एक करके या दैनिक Merkle रूट के रूप में लेजर तक पहुँचते हैं, हर मान अपने अलग सॉल्ट के साथ प्रतिबद्ध होता है, ताकि संगठन कुछ फ़ील्ड प्रकट कर सके और अन्य अपने पास रख सके। मेल खाता फ़िंगरप्रिंट दिखाता है कि रिकॉर्ड दर्ज होने के बाद से नहीं बदला, यह कभी नहीं कि काम घोषित तरीके से हुआ। यह प्रारूप सूचनात्मक और प्रस्तावित है (शब्दावली डिस्क्रिप्टर संशोधन 1.5)। संशोधन 1.1 एक वैकल्पिक form जोड़ता है, जो फ़ील्ड को खंडों और चौड़ाइयों में रखता है और तय करता है कि हर फ़ील्ड कैसे व्यवहार करे (शर्तें, डिफ़ॉल्ट मान, केवल-पढ़ने योग्य और परिकलित मान, मास्क और पैटर्न); यह केवल उसे सीमित करता है जो फ़ील्ड स्वीकार करते हैं, इसलिए इसे अनदेखा करने वाला पाठक हर रिकॉर्ड पहले की तरह पढ़ता है। संशोधन 1.2 शर्तों को एक छोटी भाषा देता है, जो नियम डिस्क्रिप्टर के साथ साझा है: not, अधिकतम 3 स्तर और 12 पत्तियाँ, और ऐसी पत्तियाँ जो प्लेटफ़ॉर्म रिकॉर्ड के बारे में जो जानता है उसे ऐसे कोड में पढ़ती हैं जो हर भाषा में एक जैसे पढ़े जाते हैं (फ़सल EPPO कोड के रूप में, रोपण के बाद के दिन, साइट का प्रकार, देश, लॉट के उत्पाद का HS शीर्षक, उसका नवीनतम चरण)। अज्ञात संदर्भ खाली पढ़ा जाता है, और संशोधन 1.1 की हर शर्त जैसी लिखी है वैसी ही मान्य रहती है। संशोधन 1.3 किसी चरण सूची को अपना क्रम (order) बताने देता है: strict में, जो डिफ़ॉल्ट है, किसी लॉट को किसी चरण पर तब तक दर्ज नहीं किया जाता जब तक उसके लिए कोई आवश्यक पिछला चरण दर्ज न हो, उस बिंदु से गिनते हुए जहाँ लॉट सूची में आया; flexible में चरण किसी भी क्रम में दर्ज होते हैं और कमियाँ रिपोर्टों पर छोड़ी जाती हैं। लॉट के अपने इतिहास से निकलने वाला चरण (उसका पंजीकरण, कोई रूपांतरण, कोई प्राप्ति) कभी अस्वीकार नहीं होता, और हर पिछली सूची strict के रूप में पढ़ी जाती है। संशोधन 1.4 किसी प्रक्रिया प्रकार को यह बताने देता है कि उसके आउटपुट कौन-सी कॉफ़ी प्रसंस्करण विधि रखते हैं (washed, natural, honey और उसके पीले, लाल और काले रूप, pulped_natural, wet_hulled, anaerobic, other), जो रन के किसी फ़ील्ड से ली जाती है या प्रकार द्वारा तय होती है, और किसी लॉट का process मेटाडेटा विधि (method) रख सकता है (mixed केवल लॉट के लिए)। यह संगठन की घोषणा है, प्रमाणन नहीं, और यह लॉट के साथ चलती है, वहाँ भी जहाँ चरणों के मान निजी रहते हैं। संशोधन 1.5 व्यापक वर्गों separating, conditioning, sorting_grading या heat_treating में से किसी से मैपिंग को हर वर्ग की एक बंद सूची से subclass जोड़ने देता है (जैसे hulling, curing, screen, roasting), और पाठक किसी अन्य संगठन के व्यापक वर्ग वाले चरण का मिलान केवल उसके उपवर्ग से या प्रति प्रेषक एक स्पष्ट मैपिंग से करता है। संशोधन 1.6 transporting का उपवर्ग to_processor जोड़ता है: माल किसी प्रसंस्करणकर्ता को भेजा जाता है जो उसे उसके मालिक के लिए संसाधित करता है (टोल प्रसंस्करण), इसलिए कब्ज़ा बदलता है पर स्वामित्व नहीं।

अपना हुक लिखना

उदाहरण contracts/examples/SeasonHook.sol रिपॉज़िटरी में रहता है। test/standard/ImplementationGuide.test.js उसे पहुँच वाले पाठकों के लिए चलाता है। SeasonalHook प्रति कमोडिटी और प्रति ऑपरेशन कई विंडो का संदर्भ मॉड्यूल है।

व्यावहारिक नियम:

1. प्रतीक OK और OP_FORCED_TRANSFER नॉर्मेटिव पाठ में परिभाषित हैं।
2. बर्न का व्यवहार नॉर्मेटिव पाठ में परिभाषित है।
3. कॉलबैक check नॉर्मेटिव पाठ में परिभाषित है।
4. ARexCodes.code("MYNS", "NAME") जैसे कोड नाम नॉर्मेटिव पाठ में परिभाषित हैं।
5. फ़्लैग मान नॉर्मेटिव पाठ में परिभाषित हैं।
6. कॉलबैक onExecuted और check नॉर्मेटिव पाठ में परिभाषित हैं।

पंजीकरण और क्रम

सस्ते, उच्च-अस्वीकृति वाले नियम पहले रखें। HOOK_ADMIN_ROLE को मल्टीसिग या टाइमलॉक के पीछे होना चाहिए: जो पाइपलाइन को नियंत्रित करता है वही यह नियंत्रित करता है कि कौन-से ट्रांसफ़र संभव हैं।

परीक्षण

test/standard/helpers.js संदर्भ स्टैक डिप्लॉय करता है। RecordingHook प्रत्येक कॉलबैक दर्ज करता है और उसे किसी भी कोड के साथ अस्वीकार करने को कहा जा सकता है; ReentrantHook onExecuted से टोकन में पुनः प्रवेश का प्रयास करता है और लॉक को सिद्ध करता है। DomainHooks.test.js और Extensions.test.js पोर्ट किए गए हुक और सहायक कॉन्ट्रैक्ट कवर करते हैं; Invariants.test.js ऑपरेशनों का एक सीडेड यादृच्छिक अनुक्रम चलाता है और सप्लाई संरक्षण, अंतिम स्टेटस, तथा यह जाँचता है कि canTransfer प्रत्येक परिणाम की भविष्यवाणी करता है। संदर्भ रिलीज़ 2.0.0-alpha.8 से संदर्भ कार्यान्वयन एक हुक किट (conformance/hooks/) भी देता है, यानी Foundry सुइट जिन्हें हर नियम को पास करना होता है, और एक मॉड्यूल टेम्पलेट (templates/module/)। रिलीज़ 2.0.0-alpha.9 एक ऐड-ऑन किट (conformance/addons/) और उस पर जाँचे गए तीन ऐड-ऑन टेम्पलेट जोड़ता है: प्राप्ति पर नमी (GrainMoisture), कंपनी के घोषित तथ्य के रूप में दर्ज फ़ेयर-ट्रेड प्रमाणपत्र (FairTradeCertificate), और किसी उत्पादक को दिया गया प्रीमियम, जिसकी राशि और प्राप्तकर्ता केवल सॉल्टेड फ़िंगरप्रिंट के रूप में दर्ज होते हैं (PremiumPayments)।

ERC-3643 अनुपालन के साथ अंतरसंचालन

एक ERC-3643 अनुपालन मॉड्यूल moduleCheck(from, to, value, compliance) उपलब्ध कराता है। जो हुक OP_TRANSFER के लिए इसे कॉल करता है और false को किसी कोड में मैप करता है, वह प्रतिभूति टोकन के लिए लिखे गए देश-स्तरीय निर्बंध, बैलेंस सीमाएँ और टाइम लॉक को बैच टोकन पर पुनः उपयोग-योग्य बनाता है। इसका उलटा — किसी A-REX हुक को ERC-3643 टोकन के सामने उपलब्ध कराना — उतना ही यांत्रिक है। Chainlink का Automated Compliance Engine उसी पैटर्न से एकीकृत होता है: उसका पॉलिसी इंजन एक हुक बन जाता है। ये दोनों दिशाएँ केवल डिज़ाइन हैं, कार्यान्वित नहीं। जो संदर्भ एडेप्टर मौजूद है वह उलटी दिशा में जाता है और केवल पढ़ता है: वह ERC-3643 वॉलेट और अनुपालन टूल को एक केवल सूचना पाने वाले हुक के माध्यम से हर बैच को ERC-3643 टोकन के रूप में देखने देता है, जो किसी ट्रांसफ़र की अनुमति या इनकार नहीं कर सकता (ADR-020, प्रस्तावित)।