मानक
A-REX Core — मानक
मानक क्या परिभाषित करता है, एक अनुरूप टोकन क्या करता है, यह कैसे बदलता है और ERC कैसे बनता है। मानक पाठ जल्दी पहुँच के माध्यम से साझा किया जाता है।
स्थिति
मसौदा 2.1.0-alpha.2, जमा करने से पहले, बैच मेटाडेटा स्कीमा 1.2.0 के साथ। पाठ Ethereum Request for Comments के प्रारूप में लिखा गया है ताकि स्वतंत्र कार्यान्वयनकर्ताओं द्वारा इंटरफ़ेस को उत्पादन में इस्तेमाल करने के बाद इसे ethereum/ERCs में जमा किया जा सके। इसे CC0 के अंतर्गत प्रकाशित किया जाएगा; संदर्भ कार्यान्वयन MIT के अंतर्गत है। जब तक दो स्वतंत्र कार्यान्वयनकर्ता मौजूद नहीं हैं, स्वीकृत बदलाव अस्थायी चिह्नित किए जाते हैं।
संस्करण
मानक और उसके संदर्भ कार्यान्वयन के संस्करण क्रमांक अलग-अलग हैं। "alpha.10" जैसा नाम अकेले संदर्भ कार्यान्वयन का संस्करण है, मानक का नहीं।
| क्या | संस्करण | यह क्या है |
|---|---|---|
| मानक (A-REX Core) | 2.1.0-alpha.2 | विनिर्देश और उसके इंटरफ़ेस। इस संस्करण के बाद प्रस्तावित पाठ को प्रस्तावित के रूप में चिह्नित किया जाता है और वह इसका हिस्सा नहीं है। |
| बैच मेटाडेटा स्कीमा | 1.2.0 जारी, 1.4.0 प्रस्तावित | ऑफ़-चेन बैच दस्तावेज़ जिसके प्रति टोकन प्रतिबद्ध होता है। |
| संदर्भ कार्यान्वयन | 2.0.0-alpha.10 | MIT अनुबंध जो मानक 2.1.0-alpha.2 को लागू करते हैं। |
| अनुरूपता परीक्षण-समूह | 1.1.0 | खंड-दर-खंड परीक्षण जिन्हें हर कार्यान्वयन चलाता है; यह संदर्भ कार्यान्वयन के साथ आता है। |
ये क्रमांक अलग-अलग चीज़ें गिनते हैं: मानक विनिर्देश में बदलाव गिनता है, कार्यान्वयन अपने रिलीज़ गिनता है। दोनों 2.0.0 से शुरू हुए; मानक के 2.1 ने कोई इंटरफ़ेस, इवेंट या आवश्यकता नहीं बदली, इसलिए 2.0 कार्यान्वयन उसे लागू करता है।
यह क्या परिभाषित करता है
A-REX Core, ERC-1155 और ERC-7943 का एक छोटा विस्तार है। एक बैच (किसी भौतिक जिंस का एक लॉट, या भविष्य के लॉट का अधिकार) एक ERC-1155 टोकन id है। मानक इसमें चार परतें जोड़ता है:
| परत | इंटरफ़ेस | क्या शामिल है | अनिवार्य |
|---|---|---|---|
| 0 | ERC-1155, ERC-165, IERC7943MultiToken | शेष राशि और बैच हस्तांतरण; फ़्रीज़, बलपूर्वक हस्तांतरण, खाता पात्रता | हाँ |
| 1 | IARexBatch | बैच रिकॉर्ड: जिंस और इकाई के खुले कोड, उत्पादन और समाप्ति का समय, मूल संदर्भ, चेन के बाहर के दस्तावेज़ के प्रति प्रतिबद्धता, जीवनचक्र स्थिति, और लॉट के विभाजन, विलय या प्रसंस्करण पर वंशावली | हाँ |
| 2 | IARexHook, IARexHookManager | बाहरी नियम अनुबंधों की एक क्रमबद्ध पाइपलाइन; नियम मशीन-पठनीय कारण के साथ उत्तर देता है | हाँ |
| 3 | IARexAttest | बैच और विषय के अनुसार प्रमाणन, निरीक्षण और घोषणाएँ, उस विषय के लिए विश्वसनीय जारीकर्ताओं से | अनुशंसित, टोकन में या सहायक अनुबंध में |
एक अनुरूप टोकन क्या करता है
- यह एक सामान्य ERC-1155 टोकन की तरह व्यवहार करता है, इसलिए वॉलेट, मार्केटप्लेस और इंडेक्सर बिना बदलाव के काम करते हैं।
- यह ERC-7943 की प्रवर्तन सतह उपलब्ध कराता है: अदालत के आदेश, ग्रहणाधिकार या रिकॉल के तहत किसी लॉट को फ़्रीज़ या स्थानांतरित किया जा सकता है, और ऐसी हर कार्रवाई चेन पर दिखाई देती है।
- यह हर बैच का रिकॉर्ड रखता है और हर विभाजन, विलय या प्रसंस्करण चरण दर्ज करता है, ताकि किसी लॉट के मूल लॉट हमेशा खोजे जा सकें।
- यह हर हस्तांतरण को अपनी नियम पाइपलाइन से गुज़ारता है और बता सकता है कि हस्तांतरण क्यों अस्वीकार हुआ।
- यह उन इंटरफ़ेस की घोषणा करता है जिन्हें यह लागू करता है, ताकि टूल इसे पहचान सकें।
एक नियम अनुबंध (हुक) तब अनुरूप है जब वह IARexHook लागू करता है। एक नियम अनुबंध कई टोकनों की सेवा कर सकता है।
अनुरूपता की जाँच कैसे होती है
संदर्भ कार्यान्वयन के साथ एक अनुरूपता सुइट आता है जो उस पर निर्भर नहीं करता: परीक्षणाधीन कार्यान्वयन तक केवल मानक इंटरफ़ेस और एक छोटे एडेप्टर के माध्यम से पहुँचा जाता है, जिसे उसके लेखक लिखते हैं। हर परीक्षण उस क्लॉज़ को दर्शाता है जिसकी वह जाँच करता है; कुल 89 क्लॉज़ हैं, 75 MUST स्तर पर और 14 SHOULD स्तर पर। हर रन एक निर्णय के साथ समाप्त होता है, और अनुरूपता के दावे को हर छोड़े गए क्लॉज़ का कारण बताना होता है। जिन क्लॉज़ को चेन पर देखा नहीं जा सकता, जैसे यह नियम कि मूल संदर्भ में कोई व्यक्तिगत डेटा नहीं होता, वे समीक्षा पर छोड़े जाते हैं।
प्रस्तावित और जारी नहीं
ये बदलाव लिखे जा चुके हैं और समीक्षा के लिए खुले हैं। इनमें से कोई भी स्वीकृत नहीं है: हर एक दो स्वतंत्र कार्यान्वयनकर्ताओं की पुष्टि की प्रतीक्षा में है, और MUST-स्तर वाले बदलाव प्रमुख बदलावों के नियम का पालन करते हैं।
| प्रस्ताव | यह क्या बदलेगा |
|---|---|
| ADR-019 (प्रस्तावित): मानक में क्षमताएँ, प्रोफ़ाइल में नीति | मानक भूमिकाएँ, इवेंट, डेटा के आकार, पॉज़ और निरस्तीकरण का अर्थ, और गोपनीयता नियम तय करता है; किसी क्षमता का उपयोग कौन कर सकता है, वह चालू है या नहीं, और कौन-सी सूचियाँ या प्राधिकरण लागू होते हैं, यह प्रति क्षेत्राधिकार और संगठन संस्करणित नीति प्रोफ़ाइल में जाता है। यह दो स्पष्टीकरण लाता है: मूल संदर्भ स्थान से व्युत्पन्न नहीं होना चाहिए (MUST NOT; निर्देशांक या भूखंड की ज्यामिति का कोई हैश या एन्कोडिंग नहीं); और किसी एटेस्टेशन को उसका जारीकर्ता, या उसके द्वारा प्रत्यायोजित कोई निरस्तकर्ता, निरस्त करता है, जबकि किसी प्रशासनिक भूमिका को 2.x में ऐसा एटेस्टेशन निरस्त नहीं करना चाहिए (SHOULD NOT) जिसे उसने जारी नहीं किया, और 3.0 से नहीं करना चाहिए (MUST NOT), ताकि पहले से तैनात टोकन अनुरूप बने रहें; इसी नियम के तहत, दोबारा एटेस्ट करना कभी किसी दूसरे जारीकर्ता का रिकॉर्ड नहीं बदलता और न ही किसी निरस्त रिकॉर्ड को पुनर्जीवित करता है। |
ADR-017 (प्रस्तावित): मेटाडेटा में extensions | मेटाडेटा स्कीमा 1.3.0 एक वैकल्पिक extensions ऑब्जेक्ट जोड़ेगा, प्रति नियम एक प्रविष्टि, जो नियम के डिस्क्रिप्टर के स्कीमा अंश से मान्य की जाएगी। |
| ADR-024 (प्रस्तावित): स्थान ISO कोड के रूप में | मेटाडेटा स्कीमा 1.3.0 से origin.region एक ISO 3166-2 उपविभाग कोड है, जैसे BR-MG (जहाँ कोई उपविभाग लागू न हो, वहाँ देश का ISO 3166-1 कोड), जिसकी जाँच पैटर्न से होती है; लोगों के लिए नाम वैकल्पिक origin.regionName में जाता है। पुराने संस्करणों के दस्तावेज़ मान्य रहते हैं। |
| ADR-025 (प्रस्तावित): एक ही टोकन से बंधे हुक | कोई हुक तैनाती के समय एक ही टोकन से बाँधा जा सकता है, यदि वह उस टोकन को सार्वजनिक करे और किसी अन्य पते से आई हर कॉल को नामित त्रुटि के साथ अस्वीकार करे; जो हुक बंधे नहीं हैं वे उन्हें कॉल करने वाले किसी भी टोकन की सेवा करते रहते हैं। संदर्भ ट्रेसबिलिटी हुक बंधा हुआ है। |
| ADR-018 (प्रस्तावित): घोषित कार्बन फ़ुटप्रिंट | कोई बैच किसी नामित तृतीय पक्ष द्वारा घोषित उत्पाद कार्बन फ़ुटप्रिंट वहन कर सकता है, जो PACT 3.0.3 से extensions.pact_pcf में सत्यापन स्थिति के साथ कॉपी किया जाता है; उसे कभी परिकलित नहीं किया जाता, न जोड़ा जाता है, न अन्य बैच तक आगे बढ़ाया जाता है। |
| ADR-020, ADR-021, ADR-022 (प्रस्तावित): संदर्भ एडेप्टर | ERC-3643 टूल हर बैच को ऐसे व्यू के माध्यम से पढ़ते हैं जो किसी भी चीज़ की अनुमति या इनकार नहीं कर सकता; ONCHAINID दावे तब तक वैध जब तक A-REX उनके हस्ताक्षरकर्ता पर भरोसा करता है; वैध प्रमाणपत्रों और बैच रिकॉर्ड का EAS मिरर। सूचनात्मक: वे कोई आवश्यकता नहीं जोड़ते। |
| ADR-023 (प्रस्तावित): एक ट्रांसफ़र के डेटा में कई मान | किसी ट्रांसफ़र का data अधिकतम 8 प्रविष्टियों वाला एक टैग किया हुआ लिफ़ाफ़ा हो सकता है, हर प्रविष्टि में एक कुंजी और एक मान, ताकि हर नियम केवल अपनी कुंजी पढ़े; 32 बाइट का डेटा अपना पहले वाला अर्थ बनाए रखता है। यह कोई आवश्यकता नहीं जोड़ता। |
| ADR-026 (प्रस्तावित): नेटवर्क | A-REX Core एक EVM मानक बना रहता है: paris स्तर या उसके बाद का कोई भी EVM नेटवर्क एक अनुरूप टोकन चला सकता है, नेटवर्क CAIP-2 ID से पहचाने जाते हैं और मानक उनकी कोई सूची नहीं रखता; किसी टोकन के आसपास के साक्ष्य किसी भी नेटवर्क पर एंकर किए जा सकते हैं। |
| मेटाडेटा स्कीमा 1.4.0 (प्रस्तावित) | कोई upstream प्रविष्टि उस बैच का CAIP-2 network दे सकती है जिसका वह नाम लेती है; ऐसे नेटवर्क पर मौजूद बैच, जो EVM नहीं है, अपने CAIP-19 एसेट से पहचाना जाता है। |
नियम डिस्क्रिप्टर arex.module/1 (सूचनात्मक, प्रस्तावित) | एक JSON दस्तावेज़ जिसे कोई नियम या ऐड-ऑन प्रकाशित करता है, ताकि उपभोक्ता उसे कस्टम कोड के बिना एकीकृत कर सकें। |
प्रारूप arex.vocab/1, arex.anchor-proof/1 और arex.report-sources/1 (सूचनात्मक, प्रस्तावित) | खेत के काम, प्रक्रियाओं और चरणों के लिए किसी संगठन की अपनी शब्दावली; इस बात के प्रमाण कि कोई रिकॉर्ड बिना बदले मौजूद था, किसी भी नेटवर्क पर एंकर किए गए; किसी रिपोर्ट के आँकड़ों के स्रोत, हर रिकॉर्ड के लिए एक पंक्ति। |
GS1 EPCIS 2.0, UN Transparency Protocol 0.7.0, PACT 3.0.3, ERC-3643 और Ethereum Attestation Service के लिए सूचनात्मक मैपिंग कोई आवश्यकता नहीं जोड़तीं; अंतरसंचालनीयता उनका सारांश देती है।
यह क्या छोड़ देता है
फ़सलों, ग्रेड या प्रमाणनों की कोई सूची नहीं है: कोड खुले हैं। चेन पर कोई व्यक्तिगत डेटा नहीं: न भूखंड के निर्देशांक, न नाम, न प्राकृतिक व्यक्तियों के पहचानकर्ता, और न भूखंड के स्थान से परिकलित कोई मान। कोई पहचान प्रदाता, ओरेकल या रजिस्ट्री अनिवार्य नहीं है, और कोई नीति भी नहीं: कौन प्रवर्तन, पॉज़ या स्क्रीनिंग कर सकता है, और किन सूचियों के आधार पर, यह जारीकर्ता का अपने क्षेत्राधिकार के अंतर्गत निर्णय है। क्षय वक्र, डिलीवरी प्रवाह, कार्बन लेखा और बीमा नियमों या सहायक अनुबंधों के रूप में बनाए जाते हैं; संदर्भ कार्यान्वयन इनमें से कुछ दिखाता है, और अनुरूपता इन पर निर्भर नहीं करती।
संस्करण
इंटरफ़ेस मानक के साथ संस्करणित होते हैं। किसी फ़ंक्शन, इवेंट या आवश्यकता में बदलाव एक प्रमुख संस्करण है और इसके साथ माइग्रेशन नोट आता है। वैकल्पिक जोड़, जैसे नए अनुशंसित कोड या मेटाडेटा फ़ील्ड, एक लघु संस्करण हैं: मेटाडेटा स्कीमा 1.1.0 ने जिंस योजना को खुला किया, और स्कीमा 1.2.0 ने अन्य टोकनों के बैचों के संदर्भ (upstream) जोड़े। मेटाडेटा स्कीमा 1.3.0 और 1.4.0 प्रस्तावित हैं और जारी नहीं हुए हैं। किसी पुराने स्कीमा के अंतर्गत मान्य हर दस्तावेज़ मान्य बना रहता है। जमा करने तक इंटरफ़ेस अभी भी बदल सकते हैं, हमेशा प्रमुख संस्करण के रूप में।
ERC तक का रास्ता
पाठ ethereum/ERCs में तब जाता है जब चार शर्तें पूरी हों: वास्तविक बैचों के साथ एक उत्पादन तैनाती छह महीने चली हो; कम से कम तीन स्वतंत्र नियम अनुबंध मौजूद हों; संदर्भ कार्यान्वयन का प्रकाशित तृतीय-पक्ष ऑडिट हो; और इंटरफ़ेस एक रिलीज़ चक्र तक न बदले हों। रोडमैप भावी विकास में है।
यह साइट क्या रोककर रखती है
जब तक मानक रिपॉज़िटरी निजी है, मानक खंड, इंटरफ़ेस स्रोत और उनके पहचानकर्ता, अस्वीकृति कोड और बैच मेटाडेटा स्कीमा उसी में रहते हैं। जो कंपनियाँ A-REX लागू करना, इसके साथ बैच जारी करना या इसका ऑडिट करना चाहती हैं, वे जल्दी पहुँच का अनुरोध करें पर पढ़ने की पहुँच का अनुरोध करती हैं। हर अनुरोध की समीक्षा हाथ से की जाती है; स्वीकृत पाठकों को मानक और संदर्भ कार्यान्वयन तक केवल-पढ़ने की पहुँच मिलती है। CC0 के अंतर्गत प्रकाशित होने तक सामग्री गोपनीय रहती है, और जल्दी पहुँच कोई विशिष्टता नहीं देती।