# توافق دون محو الأدلة. **ملاحظة تصميم بروتوكول · 7 سبتمبر 2026 · أهداف التوافق ليست تكاملات منفذة.** قد ينتج سير عمل فاتورة وعرض خدمة موقعًا وإيصالًا ورصد معاملة وتقييم سياسة. إعطاؤها كلها الغلاف نفسه قد يسهل كتابة البرمجيات. وقد يصعّب فهم الأدلة أيضًا إذا عامل الغلاف كل عنصر بصمت كإثبات مكافئ للنجاح. يجب أن يكون هدف التوافق في Proof21 العكس: واجهة متسقة تحفظ معنى الآثار الأصلية ومصدرها وحدودها. أعد استخدام الصيغ القائمة حيث تلائم الغرض. وأضف فقط الروابط ونتائج التقييم التي يحتاجها العمل حقًا. الاسم الجديد للإيصال ليس سببًا لاستبدال منظومة تعمل. ## سمِّ الادعاء قبل اختيار الغلاف يتعلق امتداد العروض والإيصالات الموقعة في x402 بآثار التفاعل التجاري. وتصف PEAC سجلات تفاعل قابلة للتحقق مع حدود للأدلة التي يبلغ عنها المصدر. يمكن أن تكون مدخلات مفيدة أو أهداف توافق، لكن لا ينبغي توسيع أي تسمية إلى إثبات مستقل بأن كل عملية لاحقة مطلوبة نُفذت بصورة صحيحة. [1][2] ينبغي للمهايئ المقترح أن يحدد الادعاء الدقيق الذي يستهلكه. مثلًا: وقّعت هذه الجهة هذه الشروط التجارية؛ وأبلغت هذه الخدمة عن هذا التفاعل؛ وأعاد هذا المصدر رصد المعاملة هذا؛ وقارن هذا المقيّم هذه الحقول وفق هذا الملف. يستطيع المستهلك جمع التصريحات دون التظاهر بأن افتراضات الثقة فيها متطابقة. ابدأ بإصدار مسمى واحد وشكل أثر مدعوم واحد. ادعاء «التوافق مع كل شيء» أقل فائدة من ملف ضيق مع متجهات اختبار إيجابية وسلبية وحالات غير مدعومة. صف ما إذا كان المهايئ يحلل أثرًا أو يتحقق من آليته أو يقيّم ادعاءً أو يحتفظ به للفحص اللاحق فقط. ## احفظ الأصل قبل التطبيع لنفترض أن مهايئًا يقرأ أثر JSON موقعًا وينتج عرضًا موحدًا ملائمًا. قد يساعد العرض المطور، لكن يجب ألا يتخلص المهايئ من التمثيل الأصلي الموثَّق. إذا أعاد كتابة الأنواع أو حذف الحقول أو غيّر معالجة Unicode أو التسلسل، فقد لا تبقى البايتات الناتجة هي الرسالة التي وقعتها الجهة المصدرة. احتفظ بالأثر الأصلي أو بمرجع استرجاع مأذون به ومربوط بالسلامة. سجّل إصدار التحويل وأي حقول موحدة اشتُقت من أي مدخلات. ميّز الحقل الغائب عن القيمة الفارغة الصريحة عندما تفعل صيغة المصدر ذلك. يجب ألا تختفي الحقول غير المدعومة بصمت إذا أثرت في التحقق من المصدر أو دلالات ادعائه. يمكن للتقنين حل مشكلة تسلسل محددة، لا كل مشكلة تحويل. تمثل RFC 8785 مرجعًا مفيدًا لمخطط تقنين JSON معين. يجب أن يحدد الملف متى ينطبق المخطط ومتى تستخدم الصيغة الأصلية قواعد أخرى. لا تقنّن كائنًا موقعًا اعتباطيًا ثم تفترض أن التوقيع ينبغي أن يتحقق على البايتات الجديدة. [3] ## حافظ على دقة المعرّفات عبر الأنظمة أسماء الشبكات والأصول مصدر شائع للتكافؤ العرضي. قد تعرض شبكتان رمز الأصل نفسه. وقد تتشابه عناوين شبكة اختبار وشبكة إنتاج. وقد لا يعني معرّف حساب محلي شيئًا خارج النظام الذي أصدره. يجب أن يحفظ التقرير الموحد نطاقات التسمية وقواعد الربط. توفر CAIP-2 وCAIP-19 مواصفات أصلية لتعريف السلاسل والأصول. تساعدان على تسمية ما يُناقش، ولا تثبتان وصول سلسلة خارجية إلى الإجماع أو حدوث تحويل معين. يظل المستهلك بحاجة إلى أدلة التنفيذ المعنية وسياسة قبول. [4][5] في اختبار توافق اصطناعي، أبقِ رمز العرض ثابتًا مع تغيير معرّف الأصل الدقيق. ثم غيّر الشبكة مع إبقاء نص المستلم الظاهر مشابهًا. ينبغي للمهايئ إظهار التغييرات بدل دمج السجلات. تستطيع واجهة مفيدة شرح عدم التطابق دون إعادة كتابة المعرّفات الأساسية لجعل سير العمل ينجح. ## افصل نجاح النقل عن النجاح الدلالي تعني استجابة HTTP الناجحة أن الطلب عولج وفق واجهة الخادم؛ ولا تعني تلقائيًا تقييمًا إيجابيًا للادعاء التجاري. قد يحمل أثر أصيل نتيجة سلبية. ويجب أن يبقى الملف غير المدعوم غير مدعوم حتى عندما يُحلل JSON بنجاح. تخص هذه الفروق المخطط وعرض المستهلك معًا. ينبغي لمستهلك P21 المقترح الإبلاغ منفصلًا عن سلامة الأثر ونتيجة كل تقييم مدعوم والقبول المحلي. إذا احتوت صيغة شريك على ادعاء جهة إصدار فقط، فاحفظ فئة الأدلة تلك. لا تُعد تسميتها حالة متحققًا منها مستقلًا لمجرد أنها أصبحت داخل تقرير P21. وبالمثل، لا يثبت حفظ توقيع خارجي قبول المستهلك للجهة المصدرة اليوم. لاكتشاف المفاتيح وتدويرها وإلغائها والتفويض التنظيمي سياسات خاصة. يبرهن اختبار غير متصل على مفتاح مقدم نطاقه المعلن فقط. يجب ألا يوحي مهايئ بين الصيغ باستشارة سجل هوية أو ثقة عندما لم يحدث ذلك. ## ابنِ عقد توافق يمكنه الفشل بصدق للتكامل الأول، وثّق إصدار المدخلات والادعاءات المدعومة والحقول المطلوبة وآلية المصادقة وملف المخرجات والأصول المحفوظة والحالات غير المحسومة. انشر عينات تغطي أثرًا سليمًا وعبثًا ومعرّف عملية خاطئًا وإصدارًا مجهولًا ونتيجة سلبية أصيلة وأدلة مفقودة. شغّل المنتج والمستهلك مستقلين. يمكن لاختبارات الذهاب والإياب التحقق من احتفاظ المهايئ بما وعد بحفظه. ويمكن للاختبارات التفاضلية كشف الخلاف مع تنفيذ أصلي. لا يثبت أي النوعين شراكة أو جاهزية إنتاجية بمفرده. سجّل مراجعة المصدر وتاريخ الاختبار حتى لا يبطل تغيير لاحق تصريح توافق قديمًا بصمت. من نتائج الاختبار المفيدة قدرة مستهلك مستقل على شرح النتيجة والعثور على الأدلة الأصلية دون طلب إعادة بناء القصة من المنتج. تسمي وثائق Proof21 الحالية أهداف التوافق وحدوده. ولا تدعي مهايئات PEAC أو x402 أو MCP أو A2A منشورة، والعرض غير المتصل ليس حزمة مطابقة لتلك البروتوكولات. ## الأسئلة الشائعة ### هل ينبغي لـProof21 استبدال كل صيغة إيصال موجودة؟ لا. إعادة الاستخدام هي الافتراضي عندما تلائم الصيغة الادعاء المطلوب. يجب أن يحفظ المهايئ المقترح الأدلة الأصلية ويضيف روابط أو تقييمات صريحة لسير العمل، لا غلافًا مكررًا لأجل العلامة التجارية فقط. ### هل يجعل وضع استجابة RPC في تقرير موقع منها حالة متحققًا منها مستقلًا؟ لا. يمكن للتوقيع توثيق ما وقّعه مصدر التقرير. وتبقى استجابة RPC رصدًا بمصدره وحدوده ما لم يُنفذ تحقق إضافي ويُوثق بالفعل. ### هل يكفي تحليل صيغة شريك لادعاء التوافق الكامل؟ لا. يجب أن يسمي التوافق إصدارًا ونطاقًا، وأن يغطي الدلالات المطلوبة وتدعمه اختبارات. التحليل والتحقق من التوقيع وتقييم الادعاء والقبول المحلي قدرات مختلفة. ## وصول عبر السلاسل ومدفوعات حسب النظام يبقى NAT الأصلي وUSDC على Base وسيلتين مطلوبتين للإطلاق التجاري الأول. ولـ NAT تمثيلات محددة على Ethereum وSolana وBNB Smart Chain. اعتمد عقد كل تمثيل أو mint وربطه بالجسر قبل قبوله؛ فالتوفر عبر السلاسل لا يلغي افتراضات الثقة الخاصة بالمصدر. يشمل نطاق Binance B402 أصول USDT وUSDC وUSD1 وU على BNB Smart Chain بالطرق المدعومة لكل أصل. تستخدم مسارات PayAI وCoinbase توليفات الشبكات والأصول المختبرة؛ ويحافظ Virtuals ACP على دورة دفع مهام USDC. لا يفرض MCP أو A2A عملة دفع. يبقى اختيار الدفع والتحويل الاختياري للخزينة منفصلين عن التحقق من أدلة Bitcoin/DMT. هذه أهداف تكامل محددة وليست خدمات دفع مفعلة. [Binance assets and methods](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882) ## تحديث · قابلية التشغيل البيني تحتاج حدود تفويض أيضاً تصبح الأدلة المحمولة أكثر فائدة عندما تكون سلطة التنفيذ صريحة. يميز P21 بين evidence-only verification وoptional action-bound authorization، ويمكن تكييف المبدأ نفسه مع TAP threshold signer أو smart account أو MPC/HSM أو API capability proxy من دون الادعاء بأن هذه الأنظمة تشترك في consensus واحد. قرارات المستهلك أيضاً آثار موقعة قابلة للنقل. الرفض لا يكتب فوق settlement أو evaluation المستقلة، ويمكن للقرارات الموقعة المتعارضة أن تصبح equivocation evidence بدلاً من ضغطها في reputation score قابل للتعديل. ## المراجع الأصلية وقراءة تالية - [1: x402 — العروض والإيصالات الموقعة](https://docs.x402.org/extensions/offer-receipt) - [2: PEAC — سجلات التفاعل وحدود الأدلة](https://www.peacprotocol.org/) - [3: RFC 8785 — مخطط تقنين JSON](https://www.rfc-editor.org/rfc/rfc8785.html) - [4: CAIP-2 — مواصفة معرّف سلسلة الكتل](https://standards.chainagnostic.org/CAIPs/caip-2) - [5: CAIP-19 — مواصفة نوع الأصل ومعرّف الأصل](https://standards.chainagnostic.org/CAIPs/caip-19) - [نطاق تكامل المدفوعات في Proof21](https://proof21.xyz/ar/docs/integrations/payments/)