الالتزام ثلاثي الأطراف: كيف تربط حزمتنا نية الدفع وسجل التنفيذ والتسوية في إيصال واحد قابل للتحقق

النقاط الرئيسية

• الالتزام ثلاثي الأطراف يجزئ نية الدفع وملخص سجل التنفيذ وtxid التسوية في إيصال واحد — يتحقق المدقق من كل عنصر بشكل مستقل ثم يؤكد أن التجزئة المجمعة تغطي الثلاثة — الالتزام يغطي جميع الخطوات أو لا يغطي أيًا منها؛ لا توجد تغطية جزئية (IETF draft-hopley-x402-retention-chain-06, 2026).
• يتم اكتشاف إعادة التشغيل بين الجلسات من خلال عدم تطابق التجزئة، وليس منعها بالسياسة — لأن binding_ref يجزئ payment_hash وaction_ref معًا، فإن استبدال دفع من الجلسة A بتنفيذ من الجلسة B ينتج تجزئة مجمعة مختلفة؛ يعيد المحقق الحساب ويحصل على عدم تطابق (x402 GitHub issue #2332, 2026).
• تنتج وحدات MCP سجل التنفيذ بشكل أصلي — يتم تسجيل كل استدعاء أداة (فحص الامتثال للموردين، البحث عن الموردين، صياغة عرض سعر) مع الوسائط والنتائج والطوابع الزمنية؛ ملخص السجل هو action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))، يمكن إعادة حسابه من قبل أي طرف يمتلك الحقول الأربعة (IETF draft-etcheverry-action-ref-02, 2026).
• تسوية x402 على Base تنتج payment_hash في ~200ms — يمكن التحقق من تجزئة المعاملة على السلسلة بشكل مستقل عن طريق الاستعلام عن سلسلة كتل Base؛ لا يلزم الثقة في المشغل أو الوسيط (Chainalysis, 2026).
• جميع الإنشاءات تستخدم SHA-256 وJCS (RFC 8785) — نفس معيار التسوية الذي يستخدمه مسار التدقيق في Hermes Agent (GitHub issue #487)، لذلك يتم إنتاج ملخص سجل التنفيذ بشكل أصلي من قبل نظام التدقيق الخاص بالوكيل نفسه، وليس مضافًا لاحقًا.

المشكلة: تدقيق كل خطوة على حدة ضروري ولكنه غير كافٍ

حزمة ستة بروتوكولات لتجارة الوكلاء (UCP, A2A, MCP, ACP, AP2, x402) تغطي الاكتشاف والاتصال والأدوات والدفع والتفويض والتسوية. كل بروتوكول ينتج دليله الخاص: x402 ينتج تجزئة الدفع، MCP ينتج سجل استدعاء الأداة، AP2 ينتج تفويضًا. تدقيق كل خطوة على حدة ضروري — تحتاج إلى التحقق من أن الدفع تمت تسويته وأن التنفيذ حدث وأن التفويض كان صالحًا.

لكن مسارات التدقيق المنفصلة غير كافية. بدون ربط، يمكن للمهاجم مزج دفع حقيقي من الجلسة A مع تنفيذ حقيقي من الجلسة B. كلاهما قطع أصلية. لم يتم تزوير أي منهما. لكنهما لم يحدثا في نفس الجلسة. إيصال الدفع يثبت أن دفعًا حدث. سجل التنفيذ يثبت أن فحصًا تم تشغيله. بدون ربط يربطهما تشفيريًا، لا يوجد دليل على أنهما نفس المعاملة.

هذا هو هجوم إعادة التشغيل بين الجلسات: خذ payment_hash حقيقي من معاملة مكتملة واقرنه مع action_ref حقيقي من معاملة مختلفة. إذا كان نظام التدقيق يثق في الاقتران لأن كلا القطعتين صالحة بشكل فردي، فإنه يقبل مركبًا ملفقًا. يظهر مسار التدقيق دفعًا تمت تسويته وفحصًا تم تنفيذه — لكنهما من معاملات مختلفة.

خطوة الربط هي المكان الذي يتم فيه اكتشاف هذا الهجوم — أو عدم اكتشافه.

البنية: كيف تنتج حزمتنا كل مكون

يوضح الرسم البياني أدناه تدفق الالتزام ثلاثي الأطراف الكامل — أي نظام ينتج أي قطعة، كيف تقوم طبقة الربط بتكوينها، وكيف يتحقق المدقق منها:

كيف يتم إنتاج كل مكون في حزمتنا

نية الدفع: عرض x402 الموقع

عندما يستدعي الوكيل واجهة برمجة تطبيقات مدفوعة لفحص الامتثال للمورد، يعيد الخادم HTTP 402 مع عرض موقع. إضافة offer-receipt (المدمجة في بروتوكول x402) تلزم الخادم بشروط دفع محددة: amount, asset, payTo address, المورد الدقيق الذي يتم تلبيته، ونافذة الصلاحية. يتم توقيع العرض باستخدام EIP-712 (مستند إلى محفظة Ethereum) أو JWS (أي مفتاح غير متماثل، بما في ذلك Solana Ed25519).

العرض هو نية الدفع — ما سيقوم الوكيل بدفعه. يقوم المدقق بتجزئته بشكل مستقل:

offer_hash = SHA-256(JCS(signed offer terms))

يعيد المدقق حساب هذا من شروط العرض الموقعة ويتحقق من توقيع الخادم. لا يلزم الاتصال بـ payment backend — العرض قطعة موقعة محمولة.

سجل التنفيذ: سجل استدعاء أداة MCP

تقوم وحدات MCP بتوصيل الوكيل بواجهات فحص الامتثال للموردين وكتالوجات الموردين وقنوات الدفع. يتم تسجيل كل استدعاء أداة MCP: أي وحدة تم استدعاؤها، ما الوسائط التي تم تمريرها، ما النتيجة التي تم إرجاعها، في أي طابع زمني، تحت أي إصدار سياسة. هذا هو سجل التنفيذ.

ينفذ مسار تدقيق Hermes Agent (GitHub issue #487) تسجيل الإجراءات بسلسلة تجزئة SHA-256 وتسوية RFC 8785 (JCS) — نفس المعيار الذي تستخدمه action_ref وbinding_ref. يتم إنتاج ملخص سجل التنفيذ بشكل أصلي من قبل نظام التدقيق الخاص بالوكيل نفسه:

action_ref = SHA-256(JCS({
  agent_id: "procurement-agent-001",
  action_type: "compliance.screen",
  scope: "vendor:acme-corp screening-type:sanctions",
  timestamp: "2026-07-31T19:45:23.482Z"
}))

يعيد المدقق حساب action_ref من هذه الحقول الأربعة preimage. لا يلزم الاتصال بالوكيل أو مشغله. التسوية محددة بواسطة RFC 8785، وليس بواسطة المسلسل — لذلك فإن التجزئة حتمية عبر التطبيقات.

يربط policy_bound_ref إصدار السياسة الذي كان ساريًا عند تنفيذ الإجراء. إذا تم تحديث قائمة العقوبات بين يونيو ويوليو 2026، تتغير تجزئة السياسة، ويمكن للمدقق اكتشاف أي إصدار كان نشطًا. يربط gate_ref حكم ALLOW/DENY من فحص الامتثال بمرجع السياسة، لذلك فإن النتيجة مرتبطة بشكل مثبت بإصدار القاعدة الذي أنتجها.

التسوية: txid على السلسلة على Base

يتحقق وسيط x402 من تفويض الدفع الموقع من قبل الوكيل، ينشئ المعاملة على السلسلة، ويبثها على Base. تكتمل التسوية في حوالي 200ms. يعيد الوسيط تجزئة المعاملة (payment_hash) إلى الخادم، الذي يمررها إلى الوكيل في header PAYMENT-RESPONSE.

يتحقق المدقق من payment_hash بالاستعلام عن سلسلة كتل Base — txid سجل عام غير قابل للتغيير. لا يلزم الثقة في الوسيط أو payment backend. يؤكد المدقق:

• المعاملة موجودة على Base
• amount يطابق شروط العرض
• payTo address يطابق العرض
• المعاملة مؤكدة (غير معلقة)

الربط: كيف يقوم binding_ref بتكوين الثلاثة

يقوم binding_ref (IETF draft-hopley-x402-retention-chain-06) بتكوين التجزئات الثلاث في التزام واحد:

binding_ref = SHA-256(JCS({
  offer_hash,      // ما تم التعهد به (نية الدفع)
  action_ref,      // ما تم تنفيذه (ملخص سجل MCP)
  payment_hash     // ما تمت تسويته (txid على السلسلة)
}))

هذا التزام ثلاثي الأطراف. يتحقق المدقق من كل مكون بشكل مستقل:

1. offer_hash — إعادة الحساب من شروط العرض الموقعة، التحقق من توقيع الخادم
2. action_ref — إعادة حساب SHA-256 من حقول preimage الأربعة، دون الاتصال بالوكيل
3. payment_hash — الاستعلام عن سلسلة كتل Base، تأكيد أن txid موجود ومسوى

ثم يعيد المدقق حساب binding_ref من الثلاثة ويؤكد أنه يطابق. إذا تم استبدال أي مكون — دفع من الجلسة A مقترن مع تنفيذ من الجلسة B — فإن التجزئة المجمعة لن تتطابق. الالتزام يغطي الخطوات الثلاث جميعها أو لا يغطي أيًا منها. لا توجد تغطية جزئية.

كيف يتم اكتشاف إعادة التشغيل بين الجلسات

يعمل هجوم إعادة التشغيل بين الجلسات كالتالي: يأخذ المهاجم payment_hash حقيقي من معاملة مكتملة في الجلسة A ويقرنه مع action_ref حقيقي من معاملة مختلفة في الجلسة B. كلتا القطعتين حقيقيتان. لم يتم تزوير أي منهما. لكنهما لم تحدثا في نفس الجلسة.

بدون ربط، يتحقق نظام التدقيق من payment_hash وaction_ref بشكل منفصل، يجد كليهما صالحًا، ويقبل المركب. يظهر مسار التدقيق دفعًا تمت تسويته وفحصًا تم تنفيذه — لكنهما من معاملات مختلفة.

مع binding_ref، يعيد المدقق حساب التجزئة المجمعة من payment_hash وaction_ref الفعليين في الإيصال. إذا استبدل المهاجم واحدًا من جلسة مختلفة، فإن التجزئات من سياقات preimage مختلفة، وbinding_ref المجمع لن يطابق القيمة في الإيصال. يكتشف المحقق عدم التطابق. الالتزام لا يغطي جميع الخطوات، لذلك يتم رفضه.

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

ما يعنيه هذا للبناء

وكيل مشتريات يفحص 85 موردًا أسبوعيًا للامتثال يحتاج إلى الالتزام ثلاثي الأطراف في مسار تدقيقه. التنفيذ في حزمتنا:

• وحدات MCP تنتج سجل التنفيذ. يتم تسجيل كل استدعاء أداة مع الوسائط والنتائج والطوابع الزمنية وإصدار السياسة. ملخص السجل هو action_ref، محسوب بشكل أصلي بواسطة نظام تدقيق Hermes Agent باستخدام تسوية JCS.
• x402 يعالج التسوية. الوسيط يسوّي على Base ويعيد payment_hash. إضافة offer-receipt توقع نية الدفع عند استجابة 402.
• طبقة التدقيق (ليست الوكيل، وليست payment backend) تحسب binding_ref من offer_hash وaction_ref وpayment_hash. تحسب أيضًا policy_bound_ref وgate_ref لربط إصدار السياسة وحكم الامتثال.
• نقطة فحص الإنسان في الحلقة عند تفويض الدفع ترى الإيصال المركب: شروط العرض، نتيجة التنفيذ، تأكيد التسوية، إصدار السياسة، والحكم — جميعها مرتبطة بـ binding_ref.
• مدقق خارجي (منظم، طرف مقابل، امتثال داخلي) يتحقق من الإيصال المركب بإعادة حساب كل تجزئة بشكل مستقل. لا يلزم الاتصال بالوكيل أو payment backend أو مشغل طبقة التدقيق.

يستغرق التحقق ثوانٍ: الاستعلام عن Base للحصول على txid، إعادة حساب action_ref من أربعة حقول، إعادة حساب offer_hash من الشروط الموقعة، إعادة حساب binding_ref من الثلاثة. الالتزام يغطي جميع الخطوات أو لا يغطيها. هذا هو البدائي الذي يجعل تجارة الوكلاء قابلة للتدقيق من البداية إلى النهاية.

قراءات ذات صلة

• التسوية بدون دليل تنفيذ هي صندوق أسود مدفوع: إغلاق حلقة تدقيق مدفوعات الوكيل — حلقة التدقيق ذات الخطوات الخمس ومسودات IETF التي تعرف binding_ref وpolicy_bound_ref وgate_ref
• عندما يضع الوكيل الطلب: كيف تغلق مدفوعات الوكلاء حلقة المشتريات B2B — دورة المشتريات إلى الدفع مع بروتوكولات الدفع للوكلاء (Mastercard Agent Pay, x402, Stripe agentic tokens)
• Kill-Switch by Design: معمارية حوكمة الوكيل — طبقة الحوكمة التي تقرر متى يمكن للوكيل التصرف ومتى يجب أن يتوقف
• قائمة مرجعية لتشديد أمان MCP: 1,467 خادم مكشوف وعناصر التحكم التي تغلقها — OWASP MCP08 (Lack of Audit and Telemetry) وعناصر التحكم التي تغلقها

---

موزع متوسط الحجم يدير وكيلًا يفحص 85 موردًا أسبوعيًا للامتثال يحتاج إلى أكثر من مسارات تدقيق منفصلة. يحتاج إلى التزام ثلاثي الأطراف يربط ما تم التعهد به (العرض الموقع) وما تم تنفيذه (سجل MCP) وما تمت تسويته (txid على السلسلة) في إيصال واحد. يعيد المدقق حساب كل تجزئة بشكل مستقل، ثم يؤكد أن الربط يغطي الثلاثة. يتم اكتشاف إعادة التشغيل بين الجلسات من خلال عدم تطابق التجزئة، وليس منعها بالسياسة. هذه هي المعمارية التي نبنيها: وحدات MCP تنتج السجل، x402 ينتج التسوية، طبقة التدقيق تكوّن الربط، والمحقق يتحقق من كل شيء دون الثقة بأي طرف في السلسلة.

اطلب بناءً محددًا. اكتشاف لمدة أسبوع. تحصل على جرد النظام وخريطة سير العمل ونطاق ثابت — سواء كنت تبني معنا أم لا.