المقدمة
تعتمد أمان البلوكشين على تفاعل عدة آليات تشفير وبروتوكولات. يقوم المستخدمون بتفويض المعاملات عبر المحفظة، وينفذ الشبكة المعاملات وفقًا للقواعد، وتساعد إثباتات التشفير في التحقق من نتائج الحساب، بينما تحدد آليات الإجماع وتوافر البيانات كيفية قبول حالة الشبكة ونشرها واستعادتها. نظرًا لأن هذه الآليات تتحمل مهام مختلفة، من الضروري عند فهم الخصائص الأمنية لتقنية معينة أن نحدد بوضوح أي طبقة تحميها، وما هي المشكلات التي لم تحلها.
تضيف الحوسبة الكمومية متغيرات تقنية طويلة الأمد إلى هذه المسألة. قد تواجه بعض أنظمة التشفير العامة المستخدمة على نطاق واسع مخاطر هجوم مختلفة في بيئة الحوسبة الكمومية القادرة على تحمل الأخطاء، مقارنةً ببيئة الحوسبة التقليدية. ومع ذلك، لا يزال الجدول الزمني الفعلي للتهديدات الكمومية غير مؤكد، ولا يمكن اعتبار القدرة النظرية على الهجوم معادلة مباشرة للقدرة الفورية على الاختراق في الواقع. بالنسبة للبلوكشين، فإن السؤال الأكثر قابلية للتطبيق هو: أي مكونات تشفير قد تتأثر، وهل يمكن للبروتوكول استبدال هذه المكونات، وهل يمكن للمستخدمين الانتقال بأمان، وهل لدى النظام البيئي الوقت الكافي لإجراء التحديثات.
تقدم تقنية Starknet حالة تحليلية مثيرة للاهتمام، لأنها تستخدم نظام إثبات STARK، ولديها نموذج حسابات قائم على حسابات العقود الذكية. عند البحث، يجب النظر في "خصائص نظام الإثبات" و"خصائص توقيع الحساب" بشكل منفصل، ثم فحص تحديث البروتوكول، ودعم المحفظة، والاعتماد عبر السلاسل. ستبني هذه المقالة إطارًا أساسيًا حول هذه النقاط لمساعدة القراء على فهم المعنى التقني لطرق مقاومة الكم والقيود الواقعية لها.
النقاط الأساسية
-
تُستخدم التوقيعات الرقمية لإثبات تفويض المعاملات، وتُستخدم دوال التجزئة لإنشاء ملخصات البيانات، وتُستخدم إثباتات STARK لدعم التحقق من صحة الحسابات.
-
إن وجود مزايا بحثية معينة لمقاومة الكم في نظام الإثبات لا يعني أن جميع توقيعات الحسابات في الشبكة ومكونات البروتوكول تتمتع بنفس الخصائص.
-
يوفر نموذج الحسابات الذكية في Starknet مساحة تصميم لاستبدال منطق التحقق من التوقيع، لكن الأمان الفعلي يعتمد على التنفيذ المحدد وعملية الانتقال.
-
لا تتطلب التحديثات المقاومة للكم فقط خوارزميات تشفير، بل تشمل أيضًا المحفظة، وعقود الحسابات، وآليات الاعتماد عبر السلاسل، وصلاحيات البروتوكول، وتجربة المستخدم.
-
يمكن أن تؤكد العروض التكنولوجية التجريبية جدوى مسار معين، لكنها لا يمكن أن تحل محل تدقيق بيئة الإنتاج، والنشر الواسع، والتقييم الأمني على المدى الطويل.
-
عند تقييم الادعاءات ذات الصلة، يجب التمييز بين الخصائص الأمنية النظرية، والنتائج التجريبية، والنشر الاختباري، والوظائف التي تم التحقق منها في بيئة الإنتاج.
ثلاث فئات من آليات التشفير في البلوكشين
تتعامل التوقيعات الرقمية مع مشكلة التفويض. عندما يقوم المستخدم بإجراء تحويل أو استدعاء عقد ذكي، يحتاج النظام إلى تحديد ما إذا كانت هذه العملية قد حصلت على تفويض من مالك الحساب. عادةً ما تستخدم المحفظة المفتاح الخاص لإنشاء التوقيع، بينما يتحقق الطرف الآخر من صحة التوقيع بناءً على المفتاح العام أو قواعد الحساب المعنية. لا تثبت التوقيع بحد ذاته أن المعاملة معقولة اقتصاديًا، ولا تضمن عدم وجود ثغرات في العقد؛ بل تجيب بشكل أساسي على سؤال ما إذا كانت هذه العملية تتوافق مع شروط التفويض المعترف بها من قبل النظام.
تتحمل دوال التجزئة نوعًا آخر من العمل. فهي تقوم بربط البيانات المدخلة بملخص ثابت الطول، وغالبًا ما تُستخدم في التحقق من سلامة البيانات، وهياكل الالتزام، وأشجار ميركل، وغيرها من البنى التشفيرية. لا تعادل دوال التجزئة خوارزميات التشفير، ولا تكمل التفويض الحسابي بشكل مباشر. عادةً ما تحتاج أمان دوال التجزئة إلى تحليل من جوانب مقاومة التصادم، ومقاومة الصورة الأصلية، والافتراضات الأمنية المتعلقة بالبنى ذات الصلة. حتى لو كانت دالة تجزئة معينة تتمتع بخصائص أمان جيدة، قد يفشل النظام الفعلي بسبب أخطاء في التنفيذ، أو تصميم بروتوكول غير مناسب، أو مشكلات في إدارة المفاتيح.
تُستخدم إثباتات STARK لإثبات أن حسابًا ما يتبع قواعد محددة، دون الحاجة إلى أن يقوم الطرف المصدق بإعادة تنفيذ جميع الحسابات. من الناحية المفاهيمية، يقدم المُثبت إثباتًا لعملية الحساب، ويتحقق المُصدق مما إذا كان الإثبات يلبي متطلبات البروتوكول. عادةً ما تستخدم تصميمات الأمان لـ STARK دوال التجزئة وغيرها من البنى، وتتميز بإعدادات شفافة، مما يجعلها تحتل مكانة مهمة في أبحاث التشفير المقاومة للكم. لكنها لا تحل محل توقيع الحساب تلقائيًا، ولا يمكنها تحديد ترتيب المعاملات، أو ضمان توافر جميع البيانات، أو القضاء على ثغرات العقود الذكية. لفهم الأمان الكامل لشبكة ما، يجب فحص مكونات التوقيع، والإثبات، والإجماع، ومعالجة البيانات في الوقت نفسه.
توجد علاقة تعاونية بين هذه الفئات الثلاث من الآليات، لكنها لا يمكن أن تحل محل بعضها البعض. يمكن أن تفوض توقيعات المستخدم معاملة، وتعمل بيئة التنفيذ وفقًا للبروتوكول، ويمكن لنظام الإثبات دعم التحقق من نتائج الحساب، بينما تحدد آلية الإجماع الأساسية أو شبكة البلوكشين كيفية تأكيد الحالة. إذا تم التركيز فقط على أحد المكونات، فقد يتم تفويت نقاط الخطر الحقيقية. على سبيل المثال، لا يعني أن إثبات الحسابات ليس به مشكلات أن توقيعات الحسابات الخبيثة لا يمكن قبولها؛ كما أن أمان خوارزمية التوقيع لا يعني أن الجسر عبر السلاسل لن يطلق أصولًا خاطئة بسبب خطأ في منطق التحقق.
ما هي الافتراضات الأمنية التي ستتحدى الحوسبة الكمومية
تستخدم حسابات البلوكشين التقليدية تقنيات التشفير العامة مثل توقيعات المنحنيات البيضاوية. في بيئة الحوسبة التقليدية، تعتمد هذه الحلول على بعض المسائل الرياضية التي يصعب حلها باستخدام موارد الحوسبة الواقعية. إذا تمكنت حواسيب الكم القادرة على تحمل الأخطاء من تشغيل الخوارزميات ذات الصلة، فقد تغير نظريًا صعوبة بعض المسائل، مما يؤثر على بعض أنظمة التشفير العامة الحالية. ستتأثر درجة المخاطر بنوع الخوارزمية، وبنية المفاتيح، وطريقة التنفيذ، والقدرة الحاسوبية المتاحة للمهاجمين، لذا لا يمكن اعتبار جميع أنظمة التشفير متساوية.
تتطلب تأثيرات الحوسبة الكمومية على دوال التجزئة تحليلًا مختلفًا. قد تغير الخوارزميات الكمومية تعقيد مسائل البحث، لكن هذا لا يعني أن جميع دوال التجزئة ستتعرض لنفس نوع الهجمات الهيكلية كما هو الحال مع بعض أنظمة التشفير العامة. بالنسبة لأنظمة مثل STARK، تركز الأبحاث عادةً على اختيار دوال التجزئة، وتحديد المعلمات، وبناء نظام الإثبات، وهامش الأمان. يجب فهم ما يسمى بـ "المزايا التصميمية المقاومة للكم" على أنها أحكام أمنية تستند إلى افتراضات وبنى معينة، وليس كضمان مطلق ضد جميع أساليب الهجوم المستقبلية.
من منظور هندسي، تتطلب عملية الانتقال في التشفير تخطيطًا أكثر شمولاً من مجرد استبدال الخوارزميات. يجب على البروتوكول تحديد كيفية تعايش التوقيعات القديمة والجديدة، وما إذا كان يمكن تحديث الحسابات القديمة، وكيف يمكن للمستخدم إثبات السيطرة على الحساب الأصلي، وكيفية منع المهاجمين من استغلال المنطق المتوافق خلال فترة الانتقال. يجب أيضًا مراعاة عمليات استعادة المحفظة، وأجهزة التوقيع المادية، وكود التحقق من الحسابات الذكية، والرسائل عبر السلاسل، والدعم الفني لمنصات المعاملات. إذا احتفظ أي مكون رئيسي بالاعتماد على القديم لفترة طويلة، فقد لا تحقق التحديثات الشاملة الأهداف الأمنية المتوقعة.
لذا، فإن أبحاث المخاطر الكمومية أكثر ملاءمة لاستخدام نموذج تهديدات متعدد الطبقات. أولاً، يجب تحديد مكونات التشفير المستخدمة في النظام، ثم تحديد المسؤوليات الأمنية لكل مكون وسطح الهجوم المحتمل؛ ثانيًا، تحليل ما إذا كانت الحلول البديلة ناضجة، وما إذا كانت قابلة للنشر، وما هي مشكلات التوافق التي قد تنشأ خلال عملية الانتقال؛ وأخيرًا، فحص ما إذا كان المشروع قد قدم خطة واضحة للاختبار، والتدقيق، والتحديث. هذا الإطار أكثر قدرة على عكس تعقيد النظام الحقيقي من مجرد تصنيف الشبكة على أنها "آمنة ضد الكم" أو "غير آمنة ضد الكم".
نموذج حسابات Starknet وترقية التوقيع
في تصميم الحسابات التقليدية، قد تكون عنوان الحساب وقواعد التحقق من التوقيع مرتبطة ارتباطًا وثيقًا بخطة تشفير معينة. إذا كان من الضروري في المستقبل استبدال خوارزمية التوقيع، فقد يتطلب ذلك تعديلات متزامنة على تنسيق الحساب، وتنفيذ المحفظة، وتوافق البروتوكول. تسمح الحسابات الذكية للمطورين بتعريف منطق التحقق من المعاملات من خلال عقود الحساب، مما يوفر مساحة لآليات تفويض أكثر مرونة. من الناحية النظرية، يمكن أن تدعم الحسابات توقيعات مختلفة، وطرق تحقق مختلفة، أو قواعد انتقال تدريجي، لكن إمكانية التنفيذ تعتمد على تصميم العقد المحدد، وليس على اسم "الحساب الذكي" بحد ذاته.
تستحق نموذج حسابات Starknet الدراسة، حيث يمكن تنفيذ منطق التحقق من الحساب بواسطة العقد. إذا سمح تنفيذ الحساب بتحديث أو دمج طرق التحقق من التوقيع، فستكون هناك فرصة لاستكشاف تكامل مكونات التشفير الجديدة دون الاعتماد الكامل على خطة توقيع ثابتة واحدة. ومع ذلك، يجب تأكيد ما إذا كان يمكن تحديث الحساب، ومن يملك صلاحيات التحديث، وما إذا كانت التحديثات تتطلب إجراءً نشطًا من المستخدم، وما إذا كانت منطق التحقق الجديد قد خضعت لتدقيق كافٍ. قد تتبنى حسابات مختلفة تنفيذات مختلفة، ولا يمكن افتراض أن جميع الحسابات تدعم نفس مسار الانتقال.
من حيث تجربة المستخدم، تحتاج التحديثات المقاومة للكم إلى تقليل مخاطر العمليات خلال فترة الانتقال قدر الإمكان. قد لا يكون المستخدمون على دراية بالاختلافات بين المفاتيح العامة، وتنسيقات التوقيع، وعقود الحسابات، لذا يجب على المحفظة توضيح محتوى التحديث، ونطاق التفويض، والتكاليف المحتملة، وطرق الاستعادة في حالة الفشل. إذا كانت عملية الانتقال تتطلب من المستخدم إجراء معاملات خاصة، يجب على النظام أيضًا منع مواقع التصيد من استغلال الفرصة لإغراء المستخدمين بتوقيع رسائل خبيثة. إن التحديثات الأمنية ليست مجرد عمل لفريق التشفير، بل هي أيضًا جزء من تصميم منتجات المحفظة، وتحذيرات المخاطر، وتعليم المستخدمين.
عند تقييم التقدم الفعلي لـ Starknet، يجب تسجيل حالة الأوراق البحثية، وأدوات المطورين، والحسابات التجريبية، وحالة الشبكة الاختبارية، والنشر في الشبكة الرئيسية بشكل منفصل. إن قدرة خطة توقيع معينة على إتمام المعاملات في بيئة تجريبية هي دليل هندسي ذو قيمة، لكن لا يزال يتعين التأكد مما إذا كانت قد خضعت لتدقيق مستقل، وما إذا كانت مناسبة للمستخدمين العاديين، وما إذا كانت تدعم المحافظ الرئيسية، وما إذا كانت منطق التحقق ذات صلة في بيئة الشبكة الحقيقية. فقط من خلال تمييز هذه المراحل بوضوح، يمكن فهم نطاق ما تثبته العروض التكنولوجية بدقة.
العلاقة التعاونية بين إثباتات STARK وتوقيع الحسابات
في أنظمة البلوكشين، قد تظهر توقيعات الحسابات وإثباتات STARK في نفس عملية معالجة المعاملات، لكن كل منهما يحل مشكلة مختلفة. تُستخدم التوقيعات للتعبير عن تفويض الحساب، بينما يُستخدم نظام الإثبات لدعم التحقق مما إذا كانت عملية الحساب أو تحويل الحالة تتوافق مع القواعد. يمكن لنظام ما استخدام إثباتات STARK للتحقق من عدد كبير من الحسابات، بينما يستخدم نظام تشفير آخر للتحقق من توقيع الحساب. لذلك، لا يمكن الاستنتاج فقط من استخدام الشبكة لإثباتات STARK أن مرحلة تفويض المعاملات قد تحولت بالكامل إلى الحلول المقاومة للكم.
إذا كان النظام يرغب في تعزيز قدرته العامة على مقاومة الكم، فيجب عليه تحليل الاعتماد الأمني من منظور شامل. بالإضافة إلى توقيع الحساب، يجب مراعاة صلاحيات تحديث البروتوكول، وآليات التحقق أو الترتيب، والتوقيع المستخدم في الجسور عبر السلاسل، والرسائل، والخدمات المدارة، والبنية التحتية ذات الصلة. حتى إذا استخدم نظام الإثبات الأساسي بنى تتمتع بمزايا بحثية مقاومة للكم، قد تستخدم المكونات المحيطية أنظمة تشفير أخرى. الهدف من التقييم الأمني ليس العثور على مكون "الأكثر أمانًا"، بل التأكد من عدم وجود ثغرات أمنية واضحة بين العناصر الأساسية للنظام.
جانب آخر يجب الانتباه إليه هو تعقيد التنفيذ. لا تضمن الأمان النظري لخطة التشفير صحة التنفيذ البرمجي تلقائيًا. يمكن أن تؤثر اختيارات المعلمات، وتوليد الأرقام العشوائية، وقواعد التسلسل، وظروف الحدود، وصلاحيات التحديث على الأمان النهائي. قد تزيد أنظمة الإثبات الجديدة أو خطط التوقيع من تكاليف الحساب، ورسوم المعاملات، وتكاليف توافق المحفظة، أو تعقيد التطوير. يجب أن يتوازن تصميم البروتوكول بين الأمان، والكفاءة، وقابلية النشر، وتجربة المستخدم، ويجب التحكم في المخاطر من خلال التدقيق، والاختبار، والصيانة المستمرة.
كيفية تقييم ما إذا كانت طرق مقاومة الكم قد تم تنفيذها بالفعل
أول نقطة فحص هي نطاق التقنية. هل يوضح المشروع بوضوح أي المكونات قد اكتملت ترقيتها، وأيها لا تزال قيد البحث أو التخطيط؟ إذا تم ذكر نظام الإثبات فقط، دون الإشارة إلى توقيع الحساب، والمحفظة، وصلاحيات البروتوكول، والاعتماد عبر السلاسل، فلا يمكن اعتبار هذه المعلومات بيانًا أمنيًا كاملاً على مستوى النظام. يجب أن تكون الوثائق التقنية واضحة قدر الإمكان بشأن الأهداف الأمنية، ونموذج التهديد، والافتراضات المعتمدة، والمخاطر التي لا تقع ضمن النطاق.
النقطة الثانية هي حالة النشر. تقارير البحث، وإثبات المفاهيم، والشبكات الاختبارية، والنشر في الشبكة الرئيسية تنتمي إلى مراحل مختلفة. يجب البحث عن وثائق تقنية قابلة للتحقق، وتغييرات في الشيفرة، ونتائج الاختبار، وتقارير التدقيق، للتأكد من أن الوظائف تعمل بالفعل، ومن يدعمها من الحسابات أو العقود، وما إذا كانت هناك قيود معروفة. بالنسبة للعروض التجريبية، يجب التحقق مما إذا كانت هناك توضيحات واضحة حول نطاقها ومخاطر بيئة الإنتاج، لتجنب سوء فهم نتائج البحث على أنها وظائف ناضجة لجميع المستخدمين.
النقطة الثالثة هي آلية الانتقال. إن إمكانية تنفيذ طرق مقاومة الكم تعتمد في النهاية على ما إذا كان المستخدمون والنظام البيئي قادرين على اعتماد الآليات الجديدة. يجب الانتباه إلى ما إذا كانت ترقية الحسابات تتطلب إجراءً نشطًا من المستخدم، وكيفية معالجة الحسابات القديمة، وما إذا كانت المحفظة تدعم ذلك، وما إذا كانت الأصول يمكن نقلها بأمان، وما إذا كانت هناك مسارات توقيع قديمة متوافقة على المدى الطويل خلال عملية الترقية. إذا لم يكن بالإمكان نشر الحلول التقنية بأمان بين مجموعة المستخدمين الحقيقية، حتى لو كان التصميم النظري معقولًا، سيكون من الصعب تشكيل حماية نظامية كاملة.
النقطة الرابعة هي الصيانة على المدى الطويل. تتطور أبحاث التشفير باستمرار، ويجب أن يحتفظ البروتوكول بالقدرة على إصلاح الثغرات وتحديث المعلمات. في الوقت نفسه، قد تؤدي التحديثات المتكررة أو المفرطة التركيز على الصلاحيات إلى مخاطر في الحوكمة. يجب على المشروع أن يحقق توازنًا مناسبًا بين كفاءة الاستجابة الأمنية، والشفافية، وإجراءات التدقيق، ومشاركة المجتمع. إن القدرة على مقاومة الكم ليست علامة يمكن تحقيقها مرة واحدة إلى الأبد، بل هي خاصية نظامية تحتاج إلى تقييم مستمر مع تقدم أبحاث التشفير.
الأسئلة الشائعة
ما الفرق بين إثباتات STARK والتوقيعات الرقمية؟
تُستخدم التوقيعات الرقمية بشكل أساسي لإثبات أن عملية معينة قد حصلت على تفويض من المفتاح أو قواعد الحساب المعنية؛ بينما تُستخدم إثباتات STARK لدعم التحقق مما إذا كانت عملية الحساب تتوافق مع القواعد المحددة. يمكن أن تتعاون كلاهما في نفس النظام، لكن لا يمكن أن تحل إحداهما محل الأخرى.
هل يعني استخدام إثباتات STARK أن البلوكشين مقاوم تمامًا للكم؟
لا يعني ذلك. تعتمد الأمانة العامة أيضًا على توقيع الحساب، وصلاحيات تحديث البروتوكول، والتحقق عبر السلاسل، والبنية التحتية، والتنفيذ المحدد. عند التقييم، يجب فحص النظام بأكمله، وليس فقط نظام الإثبات.
هل يمكن لحسابات Starknet الذكية استبدال خطة التوقيع؟
توفر منطق التحقق القابل للبرمجة في الحسابات الذكية مساحة تصميم لعدة طرق توقيع، لكن القدرة المحددة تعتمد على تنفيذ عقد الحساب، وصلاحيات التحديث، ودعم المحفظة، وعملية الانتقال. لا يمكن افتراض أن جميع الحسابات يمكن أن تتطور تلقائيًا.
هل يمكن للحوسبة الكمومية اختراق محافظ البلوكشين الشائعة الآن؟
لا يمكن الاستنتاج بذلك. إن التأثير المحتمل للحوسبة الكمومية على أنظمة التشفير الحالية هو موضوع بحث طويل الأمد وإعداد هندسي، لكن يجب التمييز بين التهديدات النظرية، والقدرة على الهجوم المتاحة، وظروف النشر الواقعية.
كيف يمكن التحقق مما إذا كانت ميزات مقاومة الكم قد تم نشرها بالفعل؟
يجب التحقق من الوثائق التقنية الرسمية، وتغييرات الشيفرة، وتقارير التدقيق، ونتائج الاختبار، وحالة الشبكة الفعلية، مع التمييز الواضح بين البحث، والتجريب، والشبكة الاختبارية، والنشر في الشبكة الرئيسية. لا تكفي الأخبار أو الوصف الترويجي لإثبات أن جميع مكونات الأمان قد اكتملت ترقيتها.
