لا توجد حواسيب كمومية قادرة على كسر سلسلة بلوكشين بيتكوين اليوم. ومع ذلك، فإن المطورين يدرسون بالفعل موجة من الترقيات لبناء دفاعات ضد التهديد المحتمل، ومن حقهم فعل ذلك، لأن التهديد لم يعد أمراً افتراضياً.
في هذا الأسبوع، نشرت Google أبحاثاً تقترح أن حاسوباً كمومياً قوياً بما يكفي يمكنه فك تشفير التشفير الأساسي في بيتكوين خلال أقل من تسع دقائق — دقيقة واحدة أسرع من متوسط وقت تسوية بلوك بيتكوين. يعتقد بعض المحللين أن هذا التهديد قد يصبح واقعاً بحلول 2029.
الرهان مرتفع: نحو 6.5 مليون من رموز بيتكوين، بقيمة مئات مليارات الدولارات، موجودة في عناوين يمكن لحاسوب كمومي أن يستهدفها بشكل مباشر. تنتمي بعض هذه العملات إلى منشئ بيتكوين المجهول بالاسم، Satoshi Nakamoto. علاوة على ذلك، فإن احتمال الاختراق سيُتلف المبادئ الأساسية لبيتكوين – “trust the code " و"sound money.”
إليك شكل التهديد، إلى جانب المقترحات التي يجري النظر فيها للتخفيف منه.
لنبدأ بفهم الضعف قبل مناقشة المقترحات.
يُبنى أمن بيتكوين على علاقة رياضية أحادية الاتجاه. عندما تنشئ محفظة، يتم توليد مفتاح خاص ورقم سري، ومنهما يتم اشتقاق مفتاح عام.
يتطلب إنفاق رموز بيتكوين إثبات امتلاك مفتاح خاص، ليس عبر كشفه، بل باستخدامه لتوليد توقيع تشفير يمكن للشبكة التحقق منه.
هذا النظام خالٍ من العيوب لأن الحواسيب الحديثة ستحتاج إلى مليارات السنين لكسر تشفير المنحنيات البيضاوية — وبالتحديد خوارزمية ECDSA (خوارزمية التوقيع الرقمي للمنحنى البيضاوي) — من أجل عكس هندسة المفتاح الخاص من المفتاح العام. لذلك يُقال إن سلسلة البلوكشين من الناحية الحسابية مستحيلة الاختراق.
لكن يمكن للحاسوب الكمومي في المستقبل أن يحوّل هذا الطريق أحادي الاتجاه إلى طريق ثنائي الاتجاه عبر اشتقاق مفتاحك الخاص من المفتاح العام ثم تفريغ عملاتك.
المفتاح العام مكشوف بطريقتين: من عملات خاملة جالسة علىchain (هجوم التعرض الطويل) أو عملات في حركة أو معاملات تنتظر في تجمع الذاكرة (هجوم التعرض القصير).
تُعد عناوين Pay-to-public key (P2PK) (المستخدمة من قِبل Satoshi والعمال الأوائل) وTaproot (P2TR)، تنسيق العناوين الحالي المُفعّل في 2021، عرضة لهجوم التعرض الطويل. لا تحتاج العملات في هذه العناوين إلى التحرك لكشف مفاتيحها العامة؛ لقد حدث التعرض بالفعل وهو قابل للقراءة من أي شخص على وجه الأرض، بما في ذلك مهاجم كمومي مستقبلي. تقريباً 1.7 مليون BTC موجودة في عناوين P2PK قديمة — بما في ذلك عملات Satoshi.
يرتبط التعرض القصير بتجمع الذاكرة — غرفة الانتظار للمعاملات غير المؤكدة. بينما تبقى المعاملات هناك بانتظار إدراجها في بلوك، تكون قيمة مفتاحك العام وتوقيعك مرئية بالكامل للشبكة.
يمكن للحاسوب الكمومي الوصول إلى هذه البيانات، لكنه سيكون أمامه نافذة زمنية قصيرة — قبل تأكيد المعاملة ودفنها تحت بلوكات إضافية — من أجل اشتقاق المفتاح الخاص المقابل والتصرف بناءً عليه.
كما لوحظ سابقاً، فإن كل عنوان بيتكوين جديد يُنشأ باستخدام Taproot اليوم يكشف بشكل دائم مفتاحاً عاماً علىchain، مما يمنح الحاسوب الكمومي المستقبلي هدفاً لن يختفي.
تزيل مقترحات تحسين بيتكوين (BIP) 360 المفتاح العام بشكل دائم المضمن علىchain والمرئي للجميع عبر تقديم نوع إخراج جديد يسمى Pay-to-Merkle-Root (P2MR).
تذكّر أن الحاسوب الكمومي يدرس المفتاح العام، ويُجري عكس هندسة للشكل الدقيق للمفتاح الخاص، ثم يصنع نسخة تعمل. إذا أزلنا المفتاح العام، فلن يكون هناك ما يعمل منه هذا الهجوم. وفي الوقت نفسه، يبقى كل شيء آخر، بما في ذلك مدفوعات Lightning وإعدادات متعدد التوقيع وغيرها من ميزات بيتكوين، كما هو.
ومع ذلك، إذا طُبق، فإن هذا المقترح سيحمي فقط العملات الجديدة القادمة. إن الـ 1.7 مليون BTC التي كانت موجودة بالفعل في عناوين قديمة مكشوفة تمثل مشكلة منفصلة، ويعالجها مقترحات أخرى أدناه.
SPHINCS+ هو مخطط توقيع ما بعد كمومي مبني على دوال التجزئة، ويتجنب مخاطر الكم التي تواجه التشفير القائم على المنحنيات البيضاوية المستخدم في بيتكوين. بينما تهدد خوارزمية Shor ECDSA، لا يُنظر إلى التصاميم المبنية على التجزئة مثل SPHINCS+ على أنها عرضة لنفس المستوى من الضعف.
تم توحيد المخطط بواسطة المعهد الوطني للمعايير والتكنولوجيا (NIST) في أغسطس 2024 كـ FIPS 205 (SLH-DSA) بعد سنوات من المراجعة العامة.
المقايضة من حيث الأمان هي الحجم. بينما تكون توقيعات بيتكوين الحالية 64 بايت، فإن SLH-DSA تبلغ 8 كيلوبايت (KB) أو أكثر من حيث الحجم. وبهذا، فإن اعتماد SLH-DSA سيزيد بشكل حاد من الطلب على مساحة البلوك ويرفع رسوم المعاملات.
ونتيجة لذلك، تم بالفعل تقديم مقترحات مثل SHRIMPS (مخطط توقيع ما بعد كمومي آخر مبني على التجزئة) وSHRINCS لتقليل أحجام التوقيعات دون التضحية بأمان ما بعد الكم. كلاهما يبني على SHPINCS+ بهدف الحفاظ على ضمانات أمانه، لكن في شكل أكثر عملية وكفاءة من ناحية المساحة ومناسب لاستخدامه في البلوكشين.
يهدف هذا المقترح، وهو شوكة برمجية جزئية (soft fork) اقترحها المشارك في إنشاء Lightning Network Tadge Dryja، إلى حماية المعاملات في تجمع الذاكرة من مهاجم كمومي مستقبلي. وهو يفعل ذلك عبر فصل تنفيذ المعاملة إلى مرحلتين: Commit وReveal.
تخيّل إخبار طرف مقابل أنك ستقوم بإرسال بريد إلكتروني إليه، ثم إرسال البريد الإلكتروني فعلياً. المرحلة الأولى هي مرحلة الالتزام (commit)، واللاحقة هي مرحلة الكشف (reveal).
على سلسلة البلوكشين، يعني ذلك أنك تنشر أولاً بصمة مختومة لنيتك — مجرد تجزئة لا تكشف شيئاً عن المعاملة. تقوم سلسلة البلوكشين بإضافة وقت (timestamp) لهذه البصمة بشكل دائم. لاحقاً، عند بث المعاملة الفعلية، يصبح مفتاحك العام مرئياً — ونعم، يمكن لحاسوب كمومي يراقب الشبكة أن يشتق مفتاحك الخاص منه ويُنشئ معاملة منافسة لسرقة أموالك.
لكن المعاملة المُزيفة سيتم رفضها فوراً. تتحقق الشبكة: هل يحتوي هذا الإنفاق على التزام سابق مُسجل علىchain؟ التزامك مسجل. أما التزام المهاجم فلا — لأنه أنشأه قبل لحظات فقط. إن بصمتك المُسجلة مسبقاً هي دليل أنك بريء.
لكن المشكلة هي التكلفة الأعلى بسبب تقسيم المعاملة إلى مرحلتين. لذلك، يُوصف هذا الأمر كجسر مؤقت، عملي للنشر بينما تعمل الجماعة على بناء دفاعات ضد الكم.
قدّمه المطور Hunter Beast، ويستهدف Hourglass V2 الضعف الكمومي المرتبط بحوالي 1.7 مليون BTC محتفظ بها في عناوين أقدم كانت مكشوفة بالفعل.
يقبل المقترح أن هذه العملات قد تُسرق في هجوم كمومي مستقبلي، ويسعى إلى إبطاء النزيف عبر تقييد عمليات البيع بعملة بيتكوين واحدة لكل بلوك، وذلك لتفادي تصفية جماعية كارثية في ليلة واحدة قد تُحطّم السوق.
التشبيه هو هجوم سحب جماعي من بنك (bank run): لا يمكنك إيقاف الناس من سحب أموالهم، لكن يمكنك تحديد وتيرة عمليات السحب لمنع انهيار النظام بين عشية وضحاها. يُعد هذا المقترح مثيراً للجدل لأن حتى هذا التقييد المحدود يُنظر إليه من قِبل بعض في مجتمع بيتكوين باعتباره انتهاكاً لمبدأ أنه لا يمكن لأي طرف خارجي أن يتدخل على الإطلاق في حقك في إنفاق عملاتك.
هذه المقترحات ليست مفعلة بعد، وبما أن حوكمة بيتكوين اللامركزية تمتد عبر المطورين والعمال ومشغلي العقد، فمن المرجح أن تستغرق أي ترقية وقتاً لكي تصبح حقيقة.
ومع ذلك، فإن التدفق المستمر للمقترحات التي سبقت تقرير Google هذا الأسبوع يوحي بأن المشكلة كانت مطروحة منذ زمن على رادار المطورين، ما قد يساعد في تهدئة مخاوف السوق.