بلوكستريم تنشر SHRINCS: مخطط توقيع ما بعد الكم مخصص لبيتكوين
خطت شركة بلوكستريم خطوة كبيرة نحو أمان ما بعد الكم في بيتكوين بنشرها مقترح تحسين بيتكوين (BIP) لمخطط التوقيع التجريبي ما بعد الكم المسمى SHRINCS. يعمل SHRINCS بشكل ملموس في الإنتاج على شبكة Liquid الجانبية، مما يجعله أول اقتراح ملموس مصمم صراحةً لنموذج التوقيع والمعاملات الفريدة لبيتكوين.
يختلف SHRINCS عن غيره من مخططات ما بعد الكم بشكل كبير بسبب حجم توقيعه الصغير ونهجه المتأصل في بيتكوين. يصفه الخبراء بأنه “أكثر تصميم توقيع ما بعد الكم أصالةً لبيتكوين تم إنتاجه على الإطلاق”، مما يعكس تركيز بلوكستريم على دمج مقاومة الكم دون تعطيل جذري لهندسة بيتكوين الحالية.
حجم توقيع ما بعد الكم: SHRINCS يوازن بين الصغر والتعقيد
معظم مخططات التوقيع ما بعد الكم المعتمدة من NIST أكبر بكثير من توقيعات ECDSA وSchnorr الحالية في بيتكوين. تظهر بيانات الصناعة أن هذه المخططات قد تكون بين 38 إلى 123 ضعف حجم توقيع بيتكوين، مما يفرض تكاليف كبيرة على بيئات البلوكشين ذات الموارد المحدودة.
يقلل SHRINCS هذا العبء إلى حد كبير: يبدأ حجم التوقيع الأدنى منه عند 548 بايت بالإضافة إلى مفتاح عام بحجم 48 بايت، بينما تصل الحدود العليا إلى نحو 4,619 بايت. وعلى الرغم من أن هذا لا يزال أكبر تقريبًا بتسع مرات من توقيعات Schnorr في بيتكوين التي تبلغ 64 بايت، لكنه يعد صغيرًا نسبيًا في مشهد ما بعد الكم.
| مخطط التوقيع | الحد الأدنى لحجم التوقيع | الحجم النسبي مقارنة بـ Schnorr (64 بايت) | ملاحظات |
|---|---|---|---|
| Bitcoin Schnorr | 64 بايت | 1x | مخطط التوقيع الحالي والمتطور لبيتكوين |
| مخططات ما بعد الكم لـ NIST | ~2,432 إلى ~7,872 بايت* | 38x إلى 123x | توقيعات مبنية على الهاش والشبكات |
| Blockstream SHRINCS | 548 إلى 4,619 بايت | ~9x | مخطط أصلي للبلوكتشين، حالة، أصغر من معظم مخططات PQS |
*منتصف تقريبي محسوب من 38–123 مرة حجم Schnorr.
يخفف Segregated Witness (SegWit) ضمن بيتكوين من تكلفة حجم الكتل للبروتوكولات الأكبر مثل SHRINCS، حيث يقلل SegWit من وزن بيانات التوقيع في حساب وزن الكتلة. وهذا يعني أن التوقيعات الأكبر لا تترجم بشكل خطي إلى كتل أكبر، مما يحافظ على أداء بيتكوين بشكل أكثر كفاءة مما كان مفترضًا أوليًا.
التصميم الحالتِ (stateful): مقايضات التعقيد في SHRINCS لكفاءة المساحة
يحقق SHRINCS ميزة الحجم من خلال اعتماد تصميم توقيع حالتِ. بدلاً من الاعتماد على آليات خالية من الحالة المعقدة، يخزن المفاتيح المستخدمة محليًا على جهاز التوقيع لضمان عدم إعادة استخدام المفتاح، موفرًا مساحة التوقيع بشكل كبير.
هذا يقدم تعقيدات تشغيلية غير موجودة في توقيعات بيتكوين التقليدية الخالية من الحالة. على سبيل المثال:
- كل توقيع يزيد في حجمه نحو 16 بايت في كل مرة يتم استخدامه.
- إذا فقد جهاز التوقيع، فإنه يتطلب معاملة “تراجع خالية من الحالة” كبيرة بحجم نحو 5,777 بايت للاسترداد.
هذا التوازن يمكن أن يخلق تحديات للمستخدم والمطور، خاصة لأجهزة المحافظ المادية أو بيئات الأجهزة المتعددة.
// توضيح مفاهيمي في Solidity لمخاطر إعادة الدخول التناظرية:
contract StatefulSignature {
mapping(address => uint256) public usageCount;
// تحديث حالة مبسط عند استخدام التوقيع
function useSignature(address signer) external {
require(usageCount[signer] < 1000, "Max usage reached");
usageCount[signer] += 1;
// منطق إضافي لمعالجة التوقيع ومنع إعادة الاستخدام...
}
}
ما سبق هو توضيح مفاهيمي: إدارة الحالة بعناية أمر حيوي لتجنب الثغرات مثل إعادة الدخول أو زيادات غير صحيحة في الحالة، التي يمكن تمثيلها بشكل مشابه للحاجة إلى تتبع الحالة في SHRINCS لمنع إعادة استخدام المفاتيح.
تعالج بلوكستريم تحدي الحالة الجوهرية من خلال تقديم SHRIMPS، مخطط مصاحب صدر في وقت سابق من 2026، يسمح لأجهزة النسخ الاحتياطي المتعددة التي تم تهيئتها من نفس البذرة بالتوقيع بشكل تعاوني، مما يخفف مخاطر نقطة الفشل الفردية.
اختبار فعلي على شبكة Liquid الرئيسية يثبت الجدوى ولكن الإثبات الأمني ما زال قيد الانتظار
SHRINCS ليس مجرد فرضية نظرية — فقد تم اختباره في الإنتاج على سلسلة Liquid الجانبية منذ مارس 2026 وأظهر فعالية تشغيله على محافظ الأجهزة الشائعة، مما يؤكد جدواه العملية.
مع ذلك، ينص مقترح التحسين صراحةً على أن “إثبات الأمان لا زال قيد التنفيذ”، مما يبرز أن SHRINCS لا يزال في المرحلة التجريبية من الناحية التشفيرية. لم يتم الانتهاء من التحقق الرسمي لأمانه، وهو أمر حاسم لنشره بثقة في بيئة الشبكة الرئيسية لبيتكوين.
إلى جانب الصرامة التشفيرية، يتطلب استخدام SHRINCS إدارة توافق صارمة: يحذر المقترح من أن المفاتيح التي تم إنشاؤها باستخدام تحسين معين (تقليم الشجرة الفائقة) غير متوافقة مع التطبيقات التي لا تدعم ذلك، مما يعرض الأموال لخطر الفقدان عند الاستيراد بين الإصدارات.
// مثال على استدعاء خارجي آمن لتوضيح الحماية من إعادة الدخول,
// وهو ثغرة نموذجية للأنظمة الحالتية:
contract ReentrancyGuard {
bool internal locked;
modifier noReentrant() {
require(!locked, "ReentrancyGuard: reentrant call");
locked = true;
_;
locked = false;
}
function sensitiveOperation() external noReentrant {
// المنطق الحرج هنا
}
}
على الرغم من أن حالة SHRINCS ليست ثغرة في العقود الذكية بحد ذاتها، إلا أن إدارة الحالة بأمان وضمان الذرية في التحديثات يعادل مفاهيميًا حماية عقود Solidity ضد إعادة الدخول أو فساد الحالة، مما يؤكد أهمية التصميم المنضبط في تكاملات التشفير الجديدة.
الحوكمة، وليس التشفير، هي العائق الأساسي لترقية بيتكوين الموجهة للكم
بينما تعالج مخططات التوقيع ما بعد الكم مثل SHRINCS الجبهة التشفيرية لأمان الكم، فإن العائق الحاسم داخل نظام بيتكوين البيئي هو الحوكمة.
تؤكد تحليلات الخبراء أن “العائق الملزم في هجرت بيتكوين إلى الكم ليس التشفير بل الحوكمة.” إذ تتطلب قرارات ترقيات البروتوكول اتفاقًا بين أصحاب مصلحة متنوعين، وإدارة مخاطر حذرة، وتنسيقًا تدريجيًا.
ينبغي أن يتناغم دمج SHRINCS أو أي توقيع ما بعد الكم مع مبادئ مركزية بيتكوين وضمانات استقرارها على المدى الطويل، وليس فقط الاستعداد التكنولوجي للمخطط.
الملخص والتداعيات الأمنية
يمثل SHRINCS علامة فارقة في تشفير البلوكشين من خلال اقتراح مخطط توقيع ما بعد كم صغير نسبيًا ومتأصل في بيتكوين، وقد تم نشره فعليًا على شبكة Liquid منذ أوائل 2026. يقلل تصميمه الحالتِ من حجم التوقيع مقارنة بالمخططات المنافسة لكنه يقدم تعقيدًا تشغيليًا يجب إدارته بحذر.
تدعو هذه المقايضات إلى تعاون مستمر بين علماء التشفير، مطوري المحافظ، وأصحاب الحوكمة في بيتكوين. مقاومة الكم ضرورية، ولكن الانتقال لا يجب أن يضحي بمبادئ الأمان أو يُدخل أوضاع فشل جديدة.
| الميزة | توقيعات بيتكوين التقليدية | مخطط SHRINCS ما بعد الكم |
|---|---|---|
| نوع التوقيع | خالي من الحالة، ECDSA / Schnorr | حالتِ، مبني على الهاش |
| حجم التوقيع | 64 بايت | 548 إلى 4619 بايت |
| تعقيد التشغيل | بسيط | ينمو مع كل استخدام؛ تكلفة الاسترداد عالية |
| النضج التشفيري | ناضج بالكامل وموثق | إثبات الأمان قيد الانتظار |
| النشر الإنتاجي | شبكة بيتكوين الرئيسية | تم اختباره على شبكة Liquid |
| مخاطر التوافق | منخفضة | عالية بسبب تقليم الشجرة الفائقة |
رؤية أمنية من Soken:
من تجربتنا في تدقيق أنظمة التشفير المعقدة، فإن الحالة في مخططات التوقيع تفرض بطبيعة الحال أعباء تشغيلية إضافية وأساحات للهجوم. يجب أن ترافق المقايضات التي يقدمها SHRINCS في اقتصاد الحجم بروتوكولات صارمة للتعامل مع الأجهزة والبرمجيات. علاوة على ذلك، فإن الحفاظ على التشغيل البيني وتجنب التناقضات الخفية أمران حاسمان لمنع خسائر كارثية في الأموال مع تقدم النظام البيئي نحو توقيعات مقاومة للكم.
يقدم دمج SHRINCS في هندسة بيتكوين مكاسب واعدة في مقاومة الكم، لكنه يكشف أيضًا تعقيدًا دقيقًا في إدارة التوقيعات وسيناريوهات الاسترداد. يمكن للأحجام الأقل للتوقيعات مقارنة بنهج ما بعد الكم المماثل أن تخفف من قلق مساحة البلوكشين، خاصة مع احتساب كفاءة SegWit. ومع ذلك، يتطلب التصميم الحالِ مطوري المحافظ المادية وشركات تصنيعها تطبيق تتبع قوي لاستخدام المفاتيح وآليات تراجع فعالة.
تظل معوقات الحوكمة كبيرة، مذكرًة إياهم بأن الابتكار التشفيري وحده لا يدفع الاعتماد. يتطلب الانتقال إلى خوارزميات التوقيع الجديدة في بيتكوين مشاركة شاملة من المجتمع وتنسيق متعدد المستويات لملاءمة الأهداف الأمنية مع النشر القائم على الإجماع.
بالنسبة لمطوري العقود الذكية وفرق البلوكشين الذين يستكشفون ترقيات التوقيع المرتبطة أو تكامل أدوات التشفير، فإن فهم هذه المقايضات وتبعات الحالة أمر لا يقدر بثمن. يمكن لخبرة Soken في تدقيقات شاملة وتطوير استراتيجيات الأمان أن تسهم في تصميم مسارات اعتماد تشفيرية مرنة تتماشى مع روح بيتكوين.
مدعومًا بهذه التطورات، يجب على الفرق التي تسعى للتحضير للانتقال الكمومي أن تعطي الأولوية لدمج الابتكارات ما بعد الكم مثل SHRINCS بحذر، مدافعة عن إثباتات أمان شاملة وبروتوكولات توافق. يمكن للتنفيذات أن تستفيد من دروس نماذج أمان العقود الذكية الكلاسيكية - خصوصًا حول إدارة الحالة وحمايات إعادة الدخول - لتجنب المزالق التناظرية في الحالة التشفيرية. يتيح الاعتماد على أطر تدقيق مفصلة، مثل تلك التي تقدمها Soken ضمن Services - IT، ضمان التوافق مع المعايير الصارمة التي يتطلبها نظام بيتكوين البيئي.
يُمثّل هذا الإعلان موقع مقترح SHRINCS لـ Blockstream كمعلم تأسيسي في رحلة بيتكوين الطويلة نحو مقاومة الكم، في حين يؤكد أن المسار الأمامي يجمع بين الابتكار التشفيري والحوكمة والتشغيل البيني وتحديات هندسة الأمان. سيكون البحث المتقدم في البروتوكولات والمشاركة الشاملة عبر المطورين ومزودي الأجهزة وأجهزة الحوكمة ضروريًا لتحقيق هجرة ناجحة لما بعد الكم.