خلال الأشهر القليلة الماضية، تحوّل القلق المستمر بشأن «مقاومة بيتكوين للحوسبة الكمّية» من فضول أكاديمي إلى إدارة عملية للمخاطر. قام كريستوفر وود من شركة Jefferies بإزالة بيتكوين من محفظته النموذجية طويلة الأجل بسبب مخاطر الكم.
أعلنت Coinbase عن إنشاء «مجلس استشاري مستقل للحوسبة الكمّية وتقنية البلوكتشين». داخل المجتمع التقني، تم دمج مقترح BIP 360 (نوع مخرجات مقاوم للكم) كمسودة في المستودع الرسمي لمقترحات BIP، وبثّت Blockstream أول معاملات موقّعة بتواقيع ما بعد الكم على سلسلة جانبية إنتاجية.
منذ ذلك الحين، تسارعت وتيرة ضغط الجدول الزمني. في 25 مارس 2026، أعلنت Google أن جميع أنظمتها يجب أن تنتقل إلى التشفير ما بعد الكم بحلول عام 2029. ثلاث أوراق بحثية نُشرت بين مايو 2025 ومارس 2026 خفّضت التكلفة التقديرية لعدد الكيوبِتات اللازمة لكسر التشفير بالمفاتيح العامة بنحو ثلاثة أوامر حجم، من حوالي 20 مليون كيوبِت فيزيائي إلى أقل من 100 ألف محتملًا.
قدّرت ورقة لبرنامج Google Quantum AI في مارس 2026 أن التشفير القائم على المنحنيات الإهليلجية يمكن كسره بأقل من 500 ألف كيوبِت فيزيائي في غضون دقائق؛ حجبت Google دوائر الهجوم ونشرت فقط إثبات معرفة صفرية للنتيجة. فريق من Caltech/Oratomic اقترح أن نحو 26 ألف كيوبِت ذرّي قابل لإعادة التشكيل يمكنه كسر ECC-256 في حوالي عشرة أيام. الفجوة بين «فضول مختبري» و«تهديد تشفيري» تُغلق من الاتجاهين معًا، من خلال ضغط الخوارزميات وتوسّع العتاد في الوقت نفسه.
لفهم التهديد، من المفيد النظر إلى ما يمكن وما لا يمكن لأجهزة الكمبيوتر الكمّية أن تفعله. هي لا «تجرّب جميع المفاتيح بالتوازي». خوارزمية Shor تمنح تسريعًا أُسيًا في مسائل اللوغاريتم المتقطّع والتحليل إلى عوامل أولية، وهي المسائل التي يعتمد عليها تشفير المنحنيات الإهليلجية وRSA، بينما تعاني الخوارزميات المتماثلة ودوال التجزئة فقط من تسريع بجذر تربيعي عبر خوارزمية Grover، وهو ما يمكن التعويض عنه بمعاملات أكبر.
عبارة «الكمّ يكسر التشفير» صحيحة ومضللة في آن واحد: فهو يستهدف البنى الأولية التي تُختزل أمنها إلى مسائل بنى المجموعات، وليس معجزة brute-force عشوائية. التشفير ما بعد الكم موجود بالفعل وقابل للنشر اليوم؛ حيث أنهت NIST وضع معايير (ML-KEM وML-DSA وSLH-DSA) صُممت صراحةً لدعم الانتقال بعيدًا عن ECC/RSA.
في بيتكوين تحديدًا، تكمن الخطورة في التواقيع: إذا استطاع مهاجم رؤية مفتاحك العام، يمكن لخوارزمية Shor استرجاع المفتاح الخاص. في العناوين القائمة على تجزئة المفتاح العام (P2PKH/P2WPKH)، لا يُكشَف المفتاح العام إلا عند الإنفاق؛ الخطر الرئيسي هو إعادة استخدام العنوان. أما مخرجات Taproot (P2TR) والمخرجات القديمة المدفوعة مباشرة للمفتاح العام فتكشف المفتاح العام عند إنشاء المخرج، من دون الحاجة للإنفاق. يعالج BIP 360 هذا مباشرة عبر Pay-to-Merkle-Root (P2MR): نوع مخرجات شبيه بـ Taproot لا يضع المفتاح العام أبدًا على السلسلة.
الأولوية ليست في إتقان قصة بيتكوين ما بعد الكم نظريًا؛ بل في بدء هجرة المستخدمين الآن. يجب السماح للمستخدمين بإرفاق مسار إنفاق ما بعد كمّي إلى جانب المسار القائم على المنحنى الإهليلجي الموجود لديهم. في «زمن السلم» يستمرون في استخدام Schnorr/ECDSA؛ بينما يبقى المفتاح ما بعد الكم غير مستخدم. إذا ظهر «خطر واضح وحاضر»، يمكن للشبكة إهمال التواقيع القائمة على المنحنيات الإهليلجية من دون انتظار سنوات لهجرة جماعية. لا يلزم أن يكون هذا المخطط النهائي—اختر شيئًا متحفظًا الآن، وتحسينه لاحقًا. ساعة الهجرة تُقاس بالتبنّي، لا بصعوبة الهندسة.
وجهة نظري أن على بيتكوين اختيار التواقيع القائمة على الهاش لهذا المسار الطارئ. ليس لأن الشِبكات (مثل ML-DSA) سيئة، بل لأن التواقيع القائمة على الهاش هي أقرب ما يملك علم التشفير إلى «آمنة قدر الإمكان»: أقل قدر من البنية، وأقل قدر من «السحر»، وأقل مساحة للأبواب الخلفية. كما أنها مدهشة السهولة في التدقيق والفهم، بما ينسجم مع روح بيتكوين.
يُعد SPHINCS+ (المسمى قياسيًا SLH-DSA) الخيار القياسي، لكنه ينتج تواقيع كبيرة نوعًا ما، حوالي 8 كيلوبايت لتحقيق خاصية «انعدام الحالة». بيتكوين لا يحتاج حقًا إلى هذه الخاصية. نموذج UTXO قائم جوهريًا على الاستخدام ثم الإلغاء؛ لم يكن الاستخدام المنهجي المتكرر للعناوين جزءًا من التصميم، والبنية التحتية تستوعب ذلك جيدًا. المخططات ذات الحالة مثل XMSS تنتج تواقيع أصغر بكثير (حوالي 2.5 كيلوبايت) ونموذج الإنفاق في بيتكوين يتوافق طبيعيًا مع هذا القيد.
يمنحك بناء SHRINCS من Blockstream Research كلا الأمرين: وضعًا أوليًا ذا حالة مع رجوع احتياطي عديم الحالة باستخدام SLH-DSA إذا فقدت الحالة. امتداد Jonas Nick المسمى SHRIMPS يحل مسألة التوقيع من عدة أجهزة. كلاهما قائم بالكامل على الهاش، وكلاهما يعمل بالفعل على شبكة Liquid.
إذا تم تجاوز عتبة موثوقة من نوع «ظهور Shor فعليًا»، فإن أول مهمة هي إيقاف السرقة غير القابلة للعكس، لا إنقاذ كل مخرج قديم. الإعداد الافتراضي الأكثر أمانًا هو مفتاح قتل: جعل التواقيع القائمة على المنحنى الإهليلجي غير قابلة للإنفاق على مستوى الإجماع. القفل المؤقت قابل للعكس؛ أما السرقة الكمّية فليست كذلك. بالنسبة للمخرجات التي لم يُكشَف فيها المفتاح العام أبدًا، يمكن لإثبات معرفة صفرية (مثل STARK) أن يتيح للمالك الشرعي إثبات معرفة شاهد الفتح من دون كشف المفتاح. أما المفاتيح التي كُشفت بالفعل، فإن الإنقاذ المعقول الوحيد يعتمد على سر إضافي مثل بذرة محفظة HD. العملات التي لا تمتلك أيًا من المسارين—العملات الراكدة، العملات المبكرة، عملات ساتوشي—ستبقى مقفلة. من الأفضل أن تبقى «مفقودة» على أن تصبح «مسروقة الآن».
تُظهر ورقة من StarkWare في أبريل 2026 أن معاملات بيتكوين الآمنة ضد الكم ممكنة اليوم ضمن قواعد الإجماع القائمة. إنها حيلة ذكية فعلًا لكن رد الفعل حولها للأسف يكشف مشكلة حقيقية في مجتمع بيتكوين. هذه الخدعة غير عملية على نطاق واسع وليست بديلًا عن تحديث طفيف (softfork)، لكن مع ذلك فإن المعارضة المتجذرة لفعل أي شيء جعلتها تُستشهد بالفعل كسبب لعدم استخدام «مفتاح إصلاح كل شيء بسهولة».
أعطوا الجميع سترة نجاة. لا تفرطوا في التفكير. الجزء الصعب ليس التشفير؛ بل جعل ملايين المستخدمين وكل محافظهم وأمنائهم وبورصاتهم وأجهزتهم الموقّعة تهاجر. هذا هو النهج الذي يتبعه Tezos: التعامل مع الاستعداد لما بعد الكم كمسارين (هجرة مفاتيح المستخدم مقابل تشفير البروتوكول)، والسماح للمستخدمين بإرفاق مفتاح احتياطي ما بعد كمّي الآن، ثم إهمال التواقيع القائمة على المنحنى الإهليلجي لاحقًا إن تبلور التهديد. ابدأوا الهجرة الاجتماعية بينما لا توجد حالة طوارئ، لأن الطوارئ هي الوقت الذي ترتكب فيه النظم البيئية الأخطاء. ضعوا سترات النجاة أولًا؛ ناقشوا تصميم القارب لاحقًا.