سلاسل التجزئة لمسارات تدقيق مقاومة للعبث

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

الوصفة

لكل فاتورة، احسب:

hash_n = SHA256(prev_hash || canonicalize(payload_n))

// حيث تنتج canonicalize() تسلسلاً ثابتاً من البايتات
// (مفاتيح مرتبة، بلا مسافات بيضاء، تنسيق أرقام مستقر).

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

لماذا التنميط (canonicalization) هو كل شيء

تسلسلان مختلفان بايتياً لنفس الكائن المنطقي ينتجان تجزئتين مختلفتين. RFC 8785 (JCS — JSON Canonicalization Scheme) هو المنهج المعتمد: ترتيب المفاتيح أبجدياً، بلا مسافات غير دالة، أرقام بأقصر تمثيل فريد، سلاسل نصية مهربة وفق RFC 8259.

سلاسل لكل عميل، لا سلسلة عالمية

اعتمد سلسلة منفصلة لكل عميل بدلاً من سلسلة عالمية واحدة. سببان: (1) يمكنك تجزئة التخزين والحوسبة لكل عميل دون تنسيق الكتابة، و(2) فساد سلسلة عميل واحد لا يُسمم مسار تدقيق الجميع.

التحقق بأثر رجعي

يستطيع المدقق (أو أنت دفاعاً) إعادة تشغيل السلسلة من بدايتها: احسب تجزئة حمولة الفاتورة الأولى دون prev_hash، تحقق من مطابقتها للتجزئة المخزنة، ثم تابع. أي انحراف يُحدد السجل المعبوث. وتقدّم Web Crypto عبر subtle.digest خوارزمية SHA-256 في أي بيئة تشغيل حديثة — Node أو Deno أو المتصفح.

يكتب إنفويسي تجزئة متسلسلة على كل فاتورة وعلى كل سجل ComplianceLog. السلسلتان مستقلتان: الأولى للفواتير لإثبات بأسلوب زاتكا، والثانية للسجلات للتدقيق التشغيلي.