# معمارية البروتوكول

يجمع P21 نواة حتمية ومهايئات أدلة خاصة بالمصادر وواجهات تسليم خفيفة. يشكل سجل كتل بيتكوين والالتزامات الاختيارية المرجع العام المشترك؛ ويحتفظ كل وكيل بسياسة قبوله الخاصة.

```mermaid
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F7F6F2","primaryTextColor":"#181A18","primaryBorderColor":"#D4D6D1","lineColor":"#666A65","tertiaryColor":"#FFFFFF"}}}%%
flowchart TD
  A[Requester: instruction and policy] --> B[Evidence adapters]
  B --> C[P21 deterministic core]
  C --> D[Findings and evidence bundle]
  D --> E[Consumer verifies]
  E --> F[Local acceptance policy]
  D -. optional .-> G[Asynchronous Bitcoin commitment]
  H[Bitcoin / DMT / TAP] --> B
  I[EVM / signed service artifacts] --> B
```

## المكونات

تسترجع **المحولات** الأدلة الأصلية وتحافظ على نوعها ومنشئها وشبكتها وإصدار مصدرها ووقت رصدها. يجب ألا تحوّل ملاحظة RPC إلى إثبات إجماع.

تتحقق **النواة** من البنية والروابط وتنفذ السياسات المدعومة وتنتج نتائج صريحة. يجوز للنموذج اللغوي تفسير الطلب أو شرح النتيجة؛ لكنه لا يقرر صحة الإثباتات التشفيرية ولا ينفذ تعليمات عشوائية واردة في سجل.

تجمع **واجهات المنتِج** الأدلة والتقارير. وتتحقق **واجهات المستقبِل** منها وتعيد الفحوص وتطبق شروط القبول المحلية. يستخدم الطرفان تفسيراً واحداً محدد الإصدار.

قد تجلب **الوحدات العاملة المستضافة** الأدلة وتدير المهام وترسل إشعارات الاستدعاء. ولا تملك أي سلطة على أموال العملاء في ألفا.

## حدود النطاق

التقرير ليس حفظاً للأصول أو محرك تسوية أو سجل هوية أو ضماناً لجودة الاستثمار أو إثباتاً عاماً لتنفيذ نموذج. اختيار عينة تدقيق محايدة يختلف عن إثبات اكتمال المهام، وكلاهما يختلف عن تقييم العمل المختار تقييماً صحيحاً.

قد تختلف وسيلة نقل المصدر ووسيلة الدفع وسلسلة التنفيذ. تحتفظ كل منها بافتراضات الثقة والنهائية الخاصة بها.

<!-- p21-source-payment-v08 -->

## تفسير عناصر DMT دون سكّ رموز

يستخدم Proof21 إطار DMT بوصفه ملفاً محدد الإصدار لتفسير مصادر البيانات، لا إجماع Bitcoin ولا محركاً للحقيقة المطلقة. تشير عملية DMT إلى تعريف عنصر مقبول، وتحدد كتلة Bitcoin بتجزئتها وارتفاعها، وتقيّم الحقل أو النمط المدعوم، وتضم هذه المدخلات إلى إيصال عملية قابل لإعادة الحساب. لا يلزم رمز DMT أو سكّ أو كتابة على Bitcoin لكل إيصال. وللعمليات التي تستخدم بيانات Bitcoin مباشرة ملف مصدر منفصل وصريح.

عنصر مصدر P21 **سيُعلن لاحقاً**. لا تُنشر هنا حمولة التسجيل أو الحقل والنمط المختاران أو اسم محجوز أو معرّف نقش العنصر. يجوز إعادة استخدام عنصر مسجل صالح؛ ولا يشترط البروتوكول نقشاً جديداً يحمل اسم العلامة.

يوفر مفهرس Trac المستقل `ord-tap` بنية فهرسة قابلة لإعادة الاستخدام. يقبل محلل العناصر في الإصدار المثبّت الحقول 4 و10 و11، ويتحقق من تفعيل القواعد وتوحيد الأسماء وصحة الأنماط، ويرفض الأسماء المكررة وتوقيعات الحقل/النمط المكررة معاً. لا يتيح اسم جديد إعادة تسجيل تعريف حقل كامل سبق تسجيله. لا يتضمن المحلل الذي روجع خطوة موافقة بشرية من الفريق؛ لكن صحة التسجيل تتطلب تقييم القواعد التاريخية، لا مجرد الإدراج في Bitcoin. شروط مزود الاستضافة وصلاحيات الوصول مسألة منفصلة. [1][2][6]


## فصل التفسير والتسجيل والملكية

تميّز الإيصالات بين استخراج بيانات المصدر وتسجيل العنصر والاشتقاق الحتمي وصحة نشر الرموز أو سكّها والملكية أو الرصيد الحالي. التحقق من أحدها لا يثبت البقية. يتطلب إثبات أول تسجيل صالح فهرس التاريخ ذي الصلة وقواعد التفعيل؛ ولا يثبت دليل إدراج نقش واحد عدم وجود عنصر متعارض سابق.

يُثبّت ملخص محتوى النقش وملف المصدر وإصدار التنفيذ الأصلي والشبكة وتجزئة الكتلة وارتفاعها والترميز المعياري والعملية ومعلماتها والتزام المدخلات والنتيجة. يُبيّن نطاق الأدلة وحدودها. نقص المصدر أو نمط غير مدعوم ينتج INDETERMINATE، لا نتيجة صالحة مختلقة. تُفصل ملاحظة المفهرس عن حالة البروتوكول المعاد حسابها مستقلاً. ولا يجوز أن يحل الرجوع إلى حقل Bitcoin خام خفيةً محل فحص تسجيل DMT لم يُجرَ.


[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559

<!-- p21-enforcement-v10 -->

## من الأدلة إلى الإنفاذ الاختياري

يفصل Proof21 بين **وضع الأدلة** و**وضع بوابة التنفيذ** الاختياري. ينتج وضع الأدلة التقارير ويتحقق منها من دون التحكم في المحفظة؛ أما وضع البوابة فيجعل الموقّع أو المحفظة أو صلاحية API المحمية قابلة للوصول فقط عبر بوابة سياسة. مخرجات النموذج ليست سلطة الإنفاق النهائية.

قبل التنفيذ تعيد البوابة حساب `actionDigest` للفعل الفعلي وتتحقق من الطلب والسياسة والشبكة والأصل عند الحاجة وnonce والصلاحية. تفويض الفعل A لا يجيز الفعل B. وقرار `ACCEPT / REJECT / REVIEW` الذي يوقّعه المستقبِل لاحقاً هو أثر مستقل لا يعيد كتابة سلامة الأثر أو التقييم الحتمي أو التسوية المثبتة بشكل مستقل. هذا الإصدار يحدد العقد فقط ولا يطلق موقّع سياسة P21 أو مسار حفظ إنتاجي.