مستند واحد. ثلاثة قرارات مختلفة.

ملاحظة تصميم بروتوكول · 7 سبتمبر 2026

يسهل كتابة «تم التحقق» على موقع، ويصعب استخدام العبارة بدقة. هل تحققنا من توقيع أم حساب أم إدراج معاملة أم شرط سياسة أم السلطة لاتخاذ الفعل التالي؟

تفصل واجهة المستلم المقترحة في Proof21 هذه الأسئلة عمدًا. نتيجة خضراء واحدة تخفي الفروق أساس سيئ لمسارات مالية مستقلة.

1. التحقق من المستند

تسأل الطبقة الأولى هل المستند سليم ومرتبط صحيحًا تحت افتراضات المفاتيح المقبولة. تفحص البنية والتوقيعات والمُصدر ومراجع العمليات وقواعد الترميز المدعومة.

يثبت ذلك ما وقعه المُصدر، ولا يثبت مستقلًا أن كل بيان موقّع صحيح. تصرح بروتوكولات سجلات مثل PEAC بحدود الأدلة التي يبلّغ بها المُصدر. [1]

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

2. تقييم الادعاء المسمى

تطبق الطبقة التالية سياسة محددة على مجموعة أدلة معرّفة. قد تقارن مستلم دفعة ومبلغها بالتعليمات، أو تعيد اشتقاق DMT من الحقل والقواعد المرجعية.

المخرجات محددة: نجاح أو فشل أو عدم حسم مع أسباب. لا تحول نجاح شرط واحد إلى ادعاء شامل بأمان الوكيل أو أدائه الاستثماري أو اكتمال سجل عملية كاملة.

أنواع الأدلة مهمة: الادعاء الموقّع ومشاهدة RPC وإثبات الإدراج والحالة المتحقق منها مستقلًا غير قابلة للاستبدال. يجب أن يحافظ جمعها في تقرير موحد على اختلافاتها.

3. تطبيق القبول المحلي

يقرر المستلم هل تكفي النتيجة لفعله التالي. قد تختلف متطلبات المصادر والنهائية والموقّعين والحداثة وموافقة البشر بين مهمة مراقبة صغيرة والتزام مالي كبير.

لهذا لا يستبدل P21 جميع ضوابط المحافظ والمنصات. يحتفظ المستلم بالسلطة، والتقرير دليل يُنظر فيه تحت تلك السلطة لا تفويض جديد.

بسيط من الخارج، صريح من الداخل

يمكن أن تبقى تجربة المطور موجزة. يحمل SDK واحد الطلب ويحفظ الأدلة الأصلية ويصدر نتائج ويوفر مدققًا للمستلم. يجب أن تأتي البساطة من اتساق الواجهة لا من حذف عدم اليقين.

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

تقرير الفشل الأصيل دليل مفيد

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

وبالعكس، قد يتضمن تقرير سليم ادعاء نجاح لا يملك المنتج دليلًا عليه. لا يجوز للمقيّم استعارة اليقين من التوقيع. يمثل نموذج بيانات بيانات الاعتماد القابلة للتحقق من W3C مرجعًا أصليًا مفيدًا للفصل بين التحقق من آليات الاعتماد وقرارات الثقة لدى الطرف المعتمد عليه؛ ولا تدّعي Proof21 أن صيغة أثرها المسودة تُعد تلقائيًا بيانات اعتماد وفق W3C. [2]

يحسّن هذا الفصل رسائل الخطأ أيضًا. عبارة «ملف أدلة غير مدعوم» تخبر المستهلك بالحاجة إلى تنفيذ متوافق أو أدلة مختلفة. و«عدم تطابق المستلم» تصف مقارنة مدعومة فشلت. أما «السياسة المحلية لا تقبل الجهة المصدرة» فتتعلق بالسلطة والثقة. دمج الحالات الثلاث في «غير صالح» قد يصعّب المعالجة ويشجع إعادة محاولات غير آمنة.

احسم البايتات قبل التوقيعات

قد يبدو كائنان من JSON متكافئين للقارئ مع اختلاف ترميزهما. يحتاج التوقيع إلى رسالة محددة بدقة، لا لقطة شاشة أو تفسير القارئ. تحدد RFC 8785 قواعد مخطط تقنين JSON، بما فيها قيود البيانات والتسلسل الحتمي. إنها مرجع تصميم ذي صلة، وليست بديلًا عن اختيار ملف التسلسل الدقيق المستخدم في التنفيذ واختباره. [3]

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

ينبغي للمحلل رفض الإصدارات غير المدعومة والحقول المكررة أو المتعارضة وفق قواعده الموثقة. ضع حدودًا لأحجام المدخلات قبل العمل المكلف. استخدم مكتبات تشفير راسخة ومتجهات اختبارها بدل مطالبة نموذج لغوي بابتكار التحقق من التوقيع. توفر RFC 8032 مرجع EdDSA ومتجهات الاختبار؛ واختيار Ed25519 لا يثبت بذاته ملكية المفتاح أو حالة إلغائه أو الإذن بالتصرف. [4]

القبول يخص سياسة مستهلك مسماة

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

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

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

الأسئلة الشائعة

هل يمكن أن ينجح التحقق من التوقيع بينما يفشل فحص الدفعة؟

نعم. يمكن لتقرير صحيح التوقيع أن يصف بصدق شرط دفع فاشلًا. تتعلق السلامة بالأثر الموثَّق، ويتعلق التقييم بالادعاء المسمى والأدلة. يجب أن تعرض الواجهة النتيجتين صراحةً.

هل يخول التقرير المقبول الوكيل إنفاق المال؟

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

هل يمكن اختزال كل أنواع الأدلة إلى درجة ثقة واحدة؟

سيخفي ذلك فروقًا مهمة. فالادعاء الموقّع والرصد عبر RPC والحالة المتحقق منها مستقلًا تدعم ادعاءات مختلفة. ينبغي للغلاف المشترك الاحتفاظ بنوع الدليل الأصلي ومصدره وحدوده والأسئلة غير المحسومة.