كل مخططات التوقيع بعد الكم الثلاثة لدى NIST - معياران نهائيان وواحد ما زال قيد المسودة (FN-DSA) - تتحقق الآن داخل zkVM وتتم فحصها على السلسلة (on-chain) على شبكة Kaspa testnet، مع وجود آلية تحكم ضد العبث لكل مخطط. لا توجد أي عمليات اقتران (pairings) في أي مكان.
نفس خط الأنابيب (pipeline) للمخططات الثلاثة: نتحقق من التوقيع داخل RISC Zero zkVM → نضغطه إلى إثبات مقتضب (succinct) STARK (FRI/Poseidon2) → يقوم عقد (node) في Kaspa بالتحقق من STARK على السلسلة عبر تعليمة KIP-16 ZK. لا يوجد Groth16.
• FIPS-204 - ML-DSA-44 / Dilithium (شبكات شعرية/لattice).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 - SLH-DSA / SPHINCS+ (قائم على التجزئة/hash-based).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (مسودة) — FN-DSA / Falcon-512 (شبكات شعرية/NTRU)، تنفيذ Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
وخُطوة إضافية بعد التحقق من التواقيع: UTXO محمي بتقنيات ما بعد الكم (PQ) - عملة لا تتحرك إلا بتوقيع ML-DSA صالح على عملية الإنفاق (spend) المحددة تلك. يُعاد بناء الرسالة الموقعة ضمن العهد (covenant) من المعاملة نفسها (استبطان/introspection)، لذلك لا يمكن تحويل الأموال، ويرتبط الإثبات بالمعاملة التمويلية (funding) المحددة التي تم توقيعها.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
أعدنا تشغيل (replay) هذا الإثبات ضد عملة ثانية عند القفل (lock) نفسه؛ فرفضها العقد، وما زالت تلك العملة الثانية غير مُنفقَة عند القفل - أي أن إثبات السلسلة الذي لم يتمكن الـ replay من تحريكه:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
تمتد كلفة zkVM بحوالي ~15×: Falcon ~1.8 دقيقة، ML-DSA ~8، SLH-DSA ~27 (SLH-DSA قائم على التجزئة → آلاف ضغطات SHA-256). لكل مخطط تحكم سلبي - إثبات تم العبث به أو إعادة تشغيله (replayed proof) وجرى رفضه على السلسلة، لذا لا يكون “لا عملية” (no-op).
بوضوح: هذه طبقة التوقيع فقط، وليس “Kaspa جاهز للكم” - تعدين الكم وإلزام/التزام (commitment) MuHash لـ UTXO مشكلتان منفصلتان وأكثر صعوبة ولا يمسّهما هذا العمل.
Testnet-10 PoC؛ المعاملات ما زالت secp256k1.
مكمّل لعمل @Max143672 حول XMSS - فطرقه مختلفة، وهذا هو المسار الأصلي (native route) له.
(لقد كان المتدربون لدينا مشغولين)
نفس خط الأنابيب (pipeline) للمخططات الثلاثة: نتحقق من التوقيع داخل RISC Zero zkVM → نضغطه إلى إثبات مقتضب (succinct) STARK (FRI/Poseidon2) → يقوم عقد (node) في Kaspa بالتحقق من STARK على السلسلة عبر تعليمة KIP-16 ZK. لا يوجد Groth16.
• FIPS-204 - ML-DSA-44 / Dilithium (شبكات شعرية/لattice).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 - SLH-DSA / SPHINCS+ (قائم على التجزئة/hash-based).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (مسودة) — FN-DSA / Falcon-512 (شبكات شعرية/NTRU)، تنفيذ Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
وخُطوة إضافية بعد التحقق من التواقيع: UTXO محمي بتقنيات ما بعد الكم (PQ) - عملة لا تتحرك إلا بتوقيع ML-DSA صالح على عملية الإنفاق (spend) المحددة تلك. يُعاد بناء الرسالة الموقعة ضمن العهد (covenant) من المعاملة نفسها (استبطان/introspection)، لذلك لا يمكن تحويل الأموال، ويرتبط الإثبات بالمعاملة التمويلية (funding) المحددة التي تم توقيعها.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
أعدنا تشغيل (replay) هذا الإثبات ضد عملة ثانية عند القفل (lock) نفسه؛ فرفضها العقد، وما زالت تلك العملة الثانية غير مُنفقَة عند القفل - أي أن إثبات السلسلة الذي لم يتمكن الـ replay من تحريكه:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
تمتد كلفة zkVM بحوالي ~15×: Falcon ~1.8 دقيقة، ML-DSA ~8، SLH-DSA ~27 (SLH-DSA قائم على التجزئة → آلاف ضغطات SHA-256). لكل مخطط تحكم سلبي - إثبات تم العبث به أو إعادة تشغيله (replayed proof) وجرى رفضه على السلسلة، لذا لا يكون “لا عملية” (no-op).
بوضوح: هذه طبقة التوقيع فقط، وليس “Kaspa جاهز للكم” - تعدين الكم وإلزام/التزام (commitment) MuHash لـ UTXO مشكلتان منفصلتان وأكثر صعوبة ولا يمسّهما هذا العمل.
Testnet-10 PoC؛ المعاملات ما زالت secp256k1.
مكمّل لعمل @Max143672 حول XMSS - فطرقه مختلفة، وهذا هو المسار الأصلي (native route) له.
(لقد كان المتدربون لدينا مشغولين)
