نجح برهان الدفعة، فكم رمزاً دخل المخزون فعلاً؟

الخلاصة

• يحدد الإصدار 08 مسارين مختلفين: دفعة VOPRF ببرهان واحد يغطي عناصر عدة، ودفعة عامة يمكن أن تكون الاستجابة في كل موضع فيها موجودة أو فارغة.
• يستعمل كل رمز nonce جديداً، لكن HTTP 200 أو 206 أو البرهان الصحيح لا يثبت عدد الرموز التي اكتمل بناؤها وحُفظت وبقيت قابلة للاستخدام.
• يحتاج المشغل إلى إيصال يطابق الأعداد في كل مرحلة من دون أن يتحول معرّف الدفعة إلى أداة تربط الإصدار بالاسترداد اللاحق.

تبدأ المشكلة عندما يقول النظام: «طلبنا خمسين رمزاً، وجاءت الاستجابة ناجحة، إذن لدينا خمسون رمزاً». هذه قفزة محاسبية وليست نتيجة بروتوكولية.

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

يحمل draft-ietf-privacypass-batched-tokens-08 تاريخ 4 مايو 2026، وقد رفعه فريق Privacy Pass إلى IESG بقصد Standards Track. لكن حالته عند قطع الأدلة هي AD Evaluation::Revised I-D Needed، وليس RFC. كما أن سجل IANA العام لا يعرض بعد القيمة المقترحة 0x0005 لنوع VOPRF(ristretto255, SHA-512).

ليست كل الدفعات متشابهة

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

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

إذا نُفذ بعض الطلبات فقط، يجب أن يكون الرد 206 Partial Content. وإذا لم يُنفذ أي طلب يكون الرد 400. لذلك فإن عبارة «نجحت الدفعة» تمحو فرقاً صممه النص عمداً: برهان جمعي في مسار، ونجاح جزئي ظاهر لكل موضع في المسار الآخر.

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

الـnonce الجديد لا ينشئ دفتر مخزون

ينشئ العميل nonce عشوائياً جديداً بطول 32 بايت لكل رمز في المسار الموزع الكلفة. يدخل معه نوع الرمز، وخلاصة التحدي، ومعرف مفتاح المُصدر في قيمة الرمز قبل التعمية. وهكذا تبقى المدخلات منفصلة رغم جمعها في طلب واحد.

لكن على التنفيذ أن يحافظ على المطابقة: العنصر المقيم رقم i يعود إلى nonce رقم i وإلى الجزء المناسب من ناتج المصادقة. التبديل أو القطع أو خطأ الفهرسة قد يفسد هذه الصلة من دون أن يظهر في عبارة مختصرة مثل «تم التحقق من البرهان».

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

يجب الاحتفاظ بخريطة المواضع بقدر الحاجة إلى الإتمام والتثبيت، ثم تقليصها. ربط batch ID دائم بكل رمز وبسجل الاسترداد اللاحق يعيد بناء علاقة تتعارض مع هدف التعمية.

الكلفة الخطية لم تختف

يقول النص صراحة إن BlindEvaluateBatch خطي في Nr. لا يزال المُصدر يقيّم كل عنصر. التوفير يأتي من توليد برهان واحد؛ ومع كبر الدفعة يمكن أن تقترب الكلفة العملية من نصف كلفة Nr عمليات منفصلة.

لا يشمل ذلك كل شيء. التحليل، والإدخال، والشبكة، وسياسة القبول، والإتمام، والحفظ ما زالت تكبر مع العدد. كما أن المسار العام يحمل كلفة خطية بطبيعته.

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

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

الرد 206 إيصال واضح للنقص

في المسار العام، لا يعني 206 فشلاً مطلقاً. يعني أن بعض الرموز صدر وبعضها لم يصدر. ويجب قراءة المتجه موضعاً موضعاً.

لا يجوز للعميل أن يرمي الجسم لأن الحالة ليست 200، ولا أن يحسب كل الطلبات لأن 206 ضمن 2xx. يتجاهل الموضع الفارغ، ويتمم المواضع الموجودة وفق نوعها، ثم يزيد الرصيد بما ثُبت فعلياً فقط.

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

المعادلة التشغيلية هي:

المطلوب ≠ الموجود ≠ المكتمل ≠ المثبت ≠ المتاح ≠ المصروف.

كلمة «صدر» غامضة ما لم تحدد المراقب. قد يكون المُصدر أرسل بايتات لم تصل، أو وصل الرد ولم يتممه العميل، أو اكتمل الرمز ولم يُحفظ.

إعادة المحاولة تحتاج إلى قاعدة دستورية

بعد 206، هل تُعاد المواضع الفارغة فقط أم الدفعة كلها؟ بعد انقطاع الشبكة، هل كان المُصدر قد نفذ العمل؟ بعد تعطل المخزن، هل تعاد عملية الإصدار أم تُصلح المعاملة المحلية؟

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

ينبغي تعريف وحدة الإعادة والحالات المسموحة والمسؤول عن النتيجة الغامضة. يمكن لإيصال مؤقت لكل موضع أن يحفظ خلاصة طلب غير حساسة، والنوع، وعصر المفتاح، ووجود الرد، ونتيجة الإتمام، وحالة commit. ولا ينبغي أن يصاحب هذا الإيصال الرمز إلى Origin.

الـtimeout دليل على فقدان المراقبة، لا على عدم التنفيذ.

حد الدفعة سياسة توزيع مكتوبة في الكود

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

الحد الكبير يسمح بالتخزين المسبق والعمل عند الانقطاع، لكنه يركز قيمة bearer ويرفع أثر التسريب. الحد الصغير يقلل المخزون ويجعل المُصدر أقرب إلى كل استعمال. وخلال تدوير المفتاح قد تظهر إجابات جزئية مفاجئة.

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

رقم IANA لا يثبت التشغيل

يطلب الإصدار 08 القيمة 0x0005 وأربعة أنواع وسائط. لا يظهر الرقم في سجل IANA المجمد لهذه الدراسة. وفي 20 سبتمبر طلبت Security AD توضيحات حول المراجع والتخصيص ومراجعة مبكرة من HTTP Directorate.

وصفت الرسالة هذه المسائل بأنها سهلة المعالجة. ليست رفضاً ولا حكماً بوجود ثغرة. لكنها تؤكد أن النص ما زال عملاً جارياً.

التخصيص المستقبلي يثبت تنسيق رقم، لا وجود تنفيذ. تقرير التنفيذ لا يثبت التشغيل البيني. التشغيل البيني لا يثبت صحة الرصيد. ويذكر shepherd توافقاً قوياً في فريق صغير وتقارير عن تنفيذ، لا مسحاً كاملاً.

قد يصبح التدقيق أداة ربط

يفصل RFC 9576 سياقات attestation وissuance وredemption لأن الخصوصية تعتمد على إمكان جمع المشاهدات. تضيف الدفعة وقتاً وحجماً ومُصدراً وعصر مفتاح إلى البيانات الوصفية.

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

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

الإيصال المفقود له ثلاث طبقات

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

طبقة الموضع تحفظ مؤقتاً خلاصة الطلب، ووجود الرد، وفك التسلسل، والإتمام، وcommit. تحفظ الترتيب بقدر الحاجة فقط.

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

وللاسترداد إيصال آخر: ملاءمة التحدي، والتقديم، وحالة replay، وترخيص Origin، وأثر التطبيق. لا يحق لإيصال الإصدار أن يقرر هذه النتيجة.

السلسلة الصحيحة هي:

إعداد -> attestation -> طلب -> قبول -> رد -> إتمام -> تثبيت -> اختيار -> استرداد -> ترخيص -> ملاحظة.

تقلل الدفعة كلفة بعض الحلقات، ولا تلغي حدودها.