قابلية التشغيل البيني

مع منظومة Ethereum

رمز A-REX Core هو رمز ERC-1155. وتعمل المحافظ والمستكشفات والأسواق والمفهرسات التي تفهم ERC-1155 دون تغيير: الأرصدة، والتحويلات المجمّعة، وuri(id)، والتفويضات، وفحوص مستقبِل التحويل الآمن. وتضيف A-REX أحداثًا ودوال عرض؛ ولا تحذف شيئًا.

رمز A-REX Core هو رمز متعدد الرموز وفق ERC-7943. وتتعرف محركات الامتثال ومنصات الحفظ التي تستهدف ERC-7943 (أظهر Automated Compliance Engine من Chainlink توافقًا؛ وتتبنّاه منصات الإصدار في تحالف ERC-7943) على canTransfer وforcedTransfer وsetFrozenTokens وcanSend وcanReceive دون تكييف.

مع معايير بيانات التتبع

GS1 EPCIS 2.0 / CBV

ينشر المعيار مقابلة إرشادية، حدثًا حدثًا:

يستخدم مخطط البيانات الوصفية أسماء EPCIS/CBV عن قصد حتى تطابق أداة التصدير بين الحقول لا بين المفاهيم.

قراءات أجهزة الاستشعار ليست جزءًا من النواة. يمكن لخطّاف التسليم أن يسجّل درجة الحرارة على السلسلة، وتبقى القياسات الأخرى (الرطوبة، وCO₂ وO₂، والصدمات، والميل، والباب، والموقع) خارج السلسلة في sensorElementList نفسها، بنوعها في CBV ووحدتها في Rec. 20. وتصف المقابلة نمطًا للالتزام بها: لكل نافذة زمنية، أسوأ قراءة لدرجة الحرارة مع مرجع هو جذر يغطي كل قراءة في النافذة والرسالة الأصلية التي جاءت منها، كي يتحقق المدقق من قراءة ما مقابل السلسلة. يثبت الالتزام ما كان لدى المسجِّل عند تلك الكتلة، لا أن الجهاز قاس بدقة. ونقاط القراءة ومواقع العمل معرّفات مواقع، وليست إحداثيات أبدًا.

UN Transparency Protocol (UNTP 0.7.0)

تحوّل مقابلة إرشادية الدفعةَ وأحداثها وإفاداتها إلى بيانات اعتماد وفق UNTP 0.7.0، بالمعرّفات نفسها المستخدمة في مقابلة EPCIS حتى يمكن الربط بينهما:

تتبع بيانات الاعتماد نموذج بيانات W3C Verifiable Credentials Data Model 2.0 وتُوقَّع بـ VC-JOSE-COSE تحت did:web الخاص بجهة الإصدار؛ ويستخدم الإبطال Bitstring Status List. ويمكن أيضًا تثبيت بيانات اعتماد موقّعة على دفعتها بوصفها إفادة مرجعها تجزئة بيانات الاعتماد؛ فالتثبيت يُثبت الالتزام، والتوقيع يُثبت المحتوى. ولا تحمل بيانات الاعتماد إلا ما يحمله الرمز أو بياناته الوصفية، ولا تظهر القيم التي تحتاج إلى منهجية (كالبصمة أو درجة المخاطر) إلا حين يكون طرف مسمّى قد صرّح بها. وتذكر المقابلة ما لا تغطيه، بدءًا بجواز المنتج الرقمي في الاتحاد الأوروبي: فلا تنطبق ESPR على الأغذية والأعلاف والنباتات والحيوانات الحية، ولا تقدّم A-REX أي ادعاء بشأن جواز لها.

يُذكر مكان إنتاج البضائع برموز: البلد (ISO 3166-1)، والتقسيم الإداري من المستوى الأول (ISO 3166-2، مثل BR-MG)، ورمز UN/LOCODE للبلدة فقط لموقع تجاري كالمستودع أو الميناء، ولا يُذكر أبدًا لمزرعة. وتوضع قراءات أجهزة الاستشعار في sensorData الخاص بحدث MoveEvent للتسليم؛ ولا يحمل جواز المنتج أكثر من ملخص. ابتداءً من مخطط البيانات الوصفية 1.3.0 (ADR-024، مقترح)، يكون origin.region دائمًا رمزًا من هذا النوع.

البصمات الكربونية المصرَّح بها (PACT 3.0.3)

يتيح ADR-018 (مقترح) للدفعة أن تحمل بصمة كربونية للمنتج حسبها طرف ثالث، تحت extensions.pact_pcf في مستند البيانات الوصفية. ويتبع هذا الجزء المواصفات التقنية لـ PACT 3.0.3 الصادرة عن WBCSD حقلًا حقلًا: من صرّح بها، والوحدة المصرَّح بها والفترة المرجعية، والبصمة مع الامتصاص الحيوي وبدونه، وحالة تحقق مطلوبة تسمّي جهة التحقق حين يكون قد جرى التحقق من البصمة. وهي تُنسخ، ولا تُحسب ولا تُجمع ولا تُمرَّر أبدًا إلى الدفعات المصنوعة من الدفعة، وليست رصيد كربون (ADR-014). والمقابلة عمل مشتق مستقل عن PACT ولا تنسخ أي ملف من ملفات PACT.

أكواد السلع ووحدات القياس

كود السلعة هو keccak256("<SCHEME>:<CODE>") لأي نظام: النظام المنسّق (HS)، والتعريفات الجمركية الوطنية (NCM في ميركوسور، وCN وTARIC في الاتحاد الأوروبي، وHTS في الولايات المتحدة، وغيرها)، وFAO، وCPC، وGTIN، أو نظام جهة الإصدار نفسها. ومنذ مخطط البيانات الوصفية 1.1.0 صار النظام مفتوحًا في المستند أيضًا، فيمكن للبيانات الوصفية أن تعكس الكود الموجود على السلسلة. ووحدات القياس أكواد التوصية 20 الصادرة عن UN/CEFACT (KGM وTNE وLTR)، وهي القائمة التي تستخدمها أصلًا أنظمة EDI وEPCIS والجمارك.

FSMA 204

عناصر البيانات الرئيسية هي حقول بيانات وصفية (traceabilityLotCode، وGLN، والتواريخ، والكميات) وأحداث؛ وحدث التتبع الحرج للتحويل التصنيعي هو BatchTransformed؛ وطلب السجلات خلال 24 ساعة هو استعلام في المفهرس. انظر الفصل التنظيمي لمعرفة المقابلة الكاملة.

Codex وISO 22000 وGLOBALG.A.P. وأنظمة الزراعة العضوية

جميعها مواضيع إفادات. ولا يحصرها المعيار: فالصيغ keccak256("GLOBALGAP:IFA") وkeccak256("AREX:CERT:ORGANIC_EU") وkeccak256("CODEX:MRL") أعراف تنشرها جهة الإصدار مع مخطط بياناتها الوصفية.

مع سجلات المستندات القانونية

تشير رموز A-REX إلى الأدوات القانونية ولا تحلّ محلها إلى أن تعترف ولاية قضائية بالرمز نفسه:

مع أنظمة الهوية

لا يسأل الرمز إلا canSend(account) / canReceive(account). ويمكن أن يقف خلف هذا السؤال:

• قائمة سماح/حظر تحتفظ بها جهة الإصدار (EligibilityHook)؛
• سجل هوية ONCHAINID مع مواضيع ادعاءات (نموذج ERC-3643)؛
• إفادات Ethereum Attestation Service على الحساب؛
• بيانات اعتماد قابلة للتحقق يجري التحقق منها خارج السلسلة وتنعكس على السلسلة بواسطة جهة مُرحِّلة (relayer)؛
• نظام هوية إلكترونية وطني (محفظة eIDAS 2.0 في الاتحاد الأوروبي) عبر جهة تحقق من بيانات الاعتماد.

لا شيء من ذلك جزء من المعيار، ولهذا يمكن لجهة إصدار في البرازيل وأخرى في ألمانيا أن تستخدما مزودين مختلفين وتبقيا قابلتين للتشغيل البيني.

مع محركات القواعد والمنصات

يمكن للقاعدة أو للإضافة أن تنشر واصف arex.module/1: مستند JSON يتضمن معاملاتها وإعداداتها، وحقول الدفعة المطلوبة، وأنواع الشهادات، والأحداث، وأكواد الرفض، وكيف تنتقل حالتها إلى إصدار جديد. والمنصة أو المحفظة أو المفهرس أو المدقق الذي يقرأ الواصفات يدمج قاعدة جديدة دون شيفرة مخصصة. والصيغة إرشادية ومقترحة؛ وتصبح صيغة موصى بها متى استخدمها منفّذ ثانٍ مستقل. وتضيف المراجعة 1.1 قائمة اختيارية إعلامية ops بالعمليات التي تحكمها القاعدة؛ وغيابها يعني أنها غير معروفة، ولا تُستخدم أبدًا في الإنفاذ. وتضيف المراجعة 1.2 نوع المكان ref:site (وهو originRef الذي تحمله دفعاته، لا موقعًا أبدًا) وتنص على أن الغاز المعلن يُقاس والإعدادات ممتلئة (gas.setup اختياري). وتوثّق المراجعة 1.3 الحقول التي يكتبها أول مستهلك لها فعلًا (الإجراءات، وأخطاء العقد الخاصة، والمقاييس، وبيانات كل تسليم، وصيغة كاملة للأحداث)، وكلها اختيارية. وتضيف المراجعة 1.4 ما تحتاجه المنصة لبناء نماذج الإضافات: أنواع قيم أكثر، وما يصل إلى السجل (لا بيانات شخصية أبدًا)، والعرض والتحققات لكل حقل، وعروضًا للقراءة فقط، وكيفية ربط السجل بـ EPCIS وبجواز UNTP (خاصية تصرّح بها منظمتها، لا ادعاء أبدًا). تضيف المراجعة 1.5 ملحًا إلى كل بصمة: الواصف الذي يصرّح بـ fingerprint: { "scheme": "salted-jcs/1" } يسجّل تجزئة كل قيمة مع ملح خاص بها من 32 بايت، فلا يمكن العثور على النصوص القصيرة أو الأرقام أو حدود القطع بتجربة الاحتمالات. وتضيف المراجعة 1.6 مقاييس ليست مجاميع (avg وmin وmax لحقل رقمي، لا تُجمع أبدًا عبر المجموعات أو الشركات) وطريقتين لتجميعها، حسب الطرف الذي أنشأ الدفعة (party) وحسب موقعها (site)؛ ويستخدمها قالب الإضافة الخاصة بالرطوبة في الإصدار المرجعي 2.0.0-alpha.10 لمتوسط الرطوبة عند الاستلام. وتتيح المراجعة 1.7 أن يأخذ visibleWhen الخاص بالحقل شجرةَ الشروط في واصف المفردات (all وany وnot؛ بـ 3 مستويات و12 ورقة على الأكثر) على حقول النموذج الأخرى؛ ويبقى الشرط الواحد في المراجعة 1.4 صالحًا، لكنه مهمل.

يمكن للمنظمات أن تنشر أنواع أعمالها الحقلية وأنواع عملياتها وقوائم مراحلها كتعريفات مفردات arex.vocab/1. يُربط كل تعريف بإحدى 26 فئة مرحلة مرجعية (مثل drying أو fermenting) وبخطوة عمل من GS1 CBV. تحمل أحداث EPCIS الخاصة بها ثلاث طبقات: bizStep من CBV الذي يقرؤه أي نظام EPCIS، والفئة المرجعية (arex:stageClass) التي تتيح لمنظمتين بأسماء مختلفة مقارنة سجلاتهما، والنوع والأسماء والقيم المنشورة الخاصة بالمنظمة نفسها. في جواز UNTP تكون القيم خصائص، وليست ادعاءات أبدًا. يمكن للبيانات الوصفية لدفعة مُصنّعة أن تسمّي نوع العملية والتشغيل الكامنين وراءها في كائن process، المخطط لإدراجه في مخطط البيانات الوصفية 1.4.0. وتضيف المراجعة 1.1 تخطيطًا اختياريًا للنموذج (أقسام وعروض وشروط) لا يفعل سوى تضييق ما تقبله الحقول. وتتيح المراجعة 1.2 للشروط استخدام not، والتعمق حتى 3 مستويات بما يصل إلى 12 ورقة، وقراءة سياق السجل برموز (المحصول برمز EPPO، والأيام منذ الزراعة، ونوع الموقع، والبلد، وبند HS للمنتج، وآخر مرحلة)؛ ويُقرأ السياق غير المعروف على أنه فارغ. وتضيف المراجعة 1.3 ترتيب قائمة المراحل (order): strict (الافتراضي؛ يجب تسجيل المرحلة المطلوبة السابقة أولًا) أو flexible (أي ترتيب، وتُترك الفجوات للتقارير). وتضيف المراجعة 1.4 طرق معالجة البن (washed وnatural وhoney وpulped_natural وwet_hulled وanaerobic وغيرها) التي يمنحها نوع المعالجة لمخرجاته وتحملها بيانات process الوصفية للدفعة: تصريح من المنظمة، لا شهادة. وتضيف المراجعة 1.5 فئات فرعية للفئات العامة (separating وconditioning وsorting_grading وheat_treating) من قائمة مغلقة، فلا يطابق القارئ خطوةً من فئة عامة لدى منظمة أخرى إلا بفئتها الفرعية أو بربط صريح لكل مُرسِل. وتضيف المراجعة 1.6 الفئة الفرعية to_processor للفئة transporting: بضائع تُرسَل إلى جهة معالجة تعالجها لصالح مالكها (التصنيع لحساب الغير)، فتنتقل الحيازة دون الملكية. وتُملَّح وسوم السجل الموزع ومراجع المراحل وموضوعات المواقع، فلا يمكن قراءة أي مسار عملية أو تسلسل زمني لمزرعة من السجل الموزع، ولا تُكتب المبالغ المالية أبدًا بنص صريح في السجل الموزع. وتقابل مرحلةُ التعبئة أو التحميل المسجلة مع وحدة لوجستية (رمز SSCC أو رقم حاوية) حدثَ AggregationEvent في EPCIS. وفي الإصدار المرجعي 2.0.0-alpha.9 يكتب CompanyFactsHook هذه السجلات في السجل الموزع، ويرفض RequireStageHook تسليم الدفعات التي تنقصها المراحل المطلوبة؛ ولا تُعد أي من الوحدتين إلزامية. كل ذلك إرشادي ومقترح.

النشر عبر السلاسل

A-REX Core معيار لـ EVM (ADR-026، مقترح): يعمل الرمز المطابق على أي شبكة EVM بمستوى paris أو أحدث، ولا يحتفظ المعيار بأي قائمة للشبكات؛ إذ يحدد ملف السياسات الخاص بالمنظمة الشبكاتِ التي يجوز لها استخدامها. وتُسمّى الشبكات بمعرّفات CAIP-2، مثل eip155:8453 أو hedera:mainnet. والأنماط العملية:

• سلسلة أصلية واحدة لكل جهة إصدار (موصى بها): يبقى النسب والإنفاذ متسقين؛ وتحتفظ السلاسل الأخرى بتمثيلات مغلَّفة عبر مهايئات على نمط ERC-7802 أو CCIP.
• سلسلة EVM مقيّدة بتصاريح لجهات الإصدار التي تشترطها سلطة حماية البيانات لديها أو المؤسسة المحورية؛ ويفضّل EDPB صراحةً التصاميم المقيّدة بتصاريح. البايتكود نفسه.
• مرايا لأغراض السيولة: معرّف دفعة على السلسلة الأصلية، وغلاف ERC-20 في مكان آخر؛ ويجب على الغلاف أن يحترم canTransfer في الرمز الأصلي أو أن يقصر نفسه على الحاملين المؤهلين.

لا يعبر النسب السلاسل أبدًا؛ أما المراجع فتعبرها. وبين الرموز على السلسلة نفسها أو على سلاسل مختلفة، تسمّي الدفعةُ المصنوعة من دفعة رمز آخر تلك الدفعةَ في قائمة upstream في بياناتها الوصفية (المخطط 1.2.0) بمعرّف السلسلة والعقد ومعرّف الرمز. وهذه المراجع ادعاءات من جهة الإصدار، ينبغي التحقق منها مقابل رمز المنبع. وابتداءً من المخطط 1.4.0 (مقترح)، يجوز للمدخل أن يذكر أيضًا شبكة CAIP-2 (network)، وتُسمّى الدفعة المسجّلة على شبكة ليست EVM بشبكتها وبأصلها وفق CAIP-19.

سجلات يمكن لأي أحد التحقق منها، على أي شبكة

لا تعتمد الأدلة المحيطة بالرمز على شبكة الرمز. فمرة في كل فترة، يمكن لجهة الإصدار أن تجمع بصمات سجلاتها (سجل التدقيق والتقارير والمستندات) في جذر Merkle واحد وأن تنشر هذه الـ 32 بايت على عدة شبكات مستقلة: شبكة EVM الخاصة بها، وBitcoin عبر OpenTimestamps، وHedera Consensus Service. ويحصل كل سجل على إثبات arex.anchor-proof/1 قصير. ويستطيع كل من يملك السجل وإثباته أن يتحقق، دون أي خدمة من A-REX، من أن السجل كان موجودًا دون تغيير في موعد أقصاه الوقت الذي تلقّت فيه كل شبكة الجذر؛ ويمكن لعقد على EVM أن يتحقق من الإثبات نفسه باستخدام MerkleProof من OpenZeppelin. ولا يُنشر سوى قيم التجزئة، ولا تُنشر البيانات الشخصية أبدًا. والصيغة إرشادية، وحالتها: مقترح (ADR-026). أما الشبكات التي تثبّت عليها جهة الإصدار فمسألة سياسات يحددها ملفها الخاص بالولاية القضائية أو بالمؤسسة، ويكون الإثبات صالحًا مع أي عدد من الإيصالات. ويذكر إيصال Hedera معرّف معاملته عند إرسال الجذر، ثم يكتسب رقم تسلسل الرسالة ووقت الإجماع الخاص بها بمجرد أن تؤكدها عقدة مرآة عامة.

من أين تأتي أرقام التقرير الموقّع

يمكن للتقرير المحسوب من سجلات جهة الإصدار، مثل "1 200 كغ سُلّمت إلى مشترٍ واحد في أكتوبر" أو قائمة سجلات، أن يحمل مصادره: سطر واحد لكل سجل قرأه، يذكر أين يحفظ السجل الموزع ذلك السجل والقيم التي استخدمها التقرير. كل سطر هو مصدر arex.report-sources/1؛ وورقته هي keccak256(0x03 ‖ JCS(source))، وتُقرن الأوراق المرتّبة زوجًا زوجًا حتى جذر مصادر واحد. ويُختم الجذر وقيمة SHA-256 لملف المصادر (<report>.sources.csv) مع التقرير، في بيانه الموقّع أو تحت توقيع ملف PDF، فلا يمكن لاحقًا إضافة أي سطر أو حذفه أو تغييره. ويذكر التقرير عدد سجلاته التي تُطابَق مع السجل الموزع، وعدد ما يُطابَق عبر بصمة على السجل الموزع (مرساة يومية أو نافذة قراءات)، وعدد ما ليس إلا سجلات جهة الإصدار، يغطيها ختمها. ولا يحمل المصدر أبدًا قيمة شخصية بنص صريح. ويتحقق القارئ من ذلك كله دون أي خدمة من A-REX: فالأداة verify-sources.mjs، وهي أداة تحقق مستقلة (Node.js 20، دون أي تثبيت) يمكن لأي تنفيذ أن يوفّرها، تعيد حساب كل ورقة والجذر، وتقارنهما بالتقرير، ثم تقرأ كل سجل على السجل الموزع من أي عقدة في شبكته. يحتفظ التقرير ذو البطاقات المتعددة بملف مصادر واحد وجذر واحد؛ ويذكر كل سطر بطاقته في العضو الاختياري section (المراجعة 1.1)، فتُجمع أرقام كل بطاقة على حدة.

node verify-sources.mjs report.csv.sources.csv --manifest report.csv.manifest.json --rpc https://<a node of the network>

والصيغة إرشادية، وحالتها: مقترح (المراجعة 1.1 لمصادر التقارير). ويعرض مستند المعيار، المتاح عبر الوصول المبكر، أعمدة الملف وكل خطوة تحقق ومتجه مثال؛ ويصف المخطط مصدرًا واحدًا.

مع أنظمة إدارة المزارع وتخطيط موارد المؤسسات

نقاط التكامل هي نفسها لأي رمز ERC-1155 مضافًا إليها دوال عرض الدفعة:

• مسار الكتابة: تحتفظ خدمة الإنشاء بـ ISSUER_ROLE وتستدعي createBatch من أحداث ERP (تذكرة ميزان الشاحنات، وإصدار الإيصال)؛ وتستدعي setBatchStatus/setBatchMetadata من أحداث المستودع؛ وtransform من أوامر المعالجة.
• مسار القراءة: يُدرج المفهرس الدفعات والنسب والإفادات وأحداث الإنفاذ في جداول التتبع الخاصة بنظام ERP؛ وتصدير EPCIS للشركاء والجهات التنظيمية.
• الفحص المسبق: تتيح transferCheck لنظام ERP أن يشرح الرفض لأحد المشغّلين قبل إرسال معاملة.
• المعرّفات: تربط مفاتيح GS1 في البيانات الوصفية مستودعات EDI وEPCIS القائمة؛ ووحدات قياس UN/CEFACT موجودة أصلًا في أنظمة ERP.

مصفوفة التوافق