يُصوَّر اختراق Zcash بالحواسيب الكمومية وكأنه سيحدث غدًا، لكن في مقترح Zakura تفصيل يستحق اهتمامًا أكبر: تخصيص مفتاح عرض مستقل لكل عملية مبادلة لـ ZEC. ظاهريًا، هذا إجراء لمقاومة الحوسبة الكمومية، لكن عند التعمق يتضح أنه يعالج ثغرة في الخصوصية موجودة منذ زمن. فالمحفظة تستطيع إنشاء مجموعة من العناوين التي تبدو غير مرتبطة، لكن هذه العناوين غالبًا ما تشترك في مفتاح عرض واحد. وإذا أمكن استنتاج هذا المفتاح، فستنكشف معًا جميع المدفوعات التي تلقاها الحساب ومبالغها وملاحظاتها.
لا تكمن أهمية هذا التغيير في عبارة «مقاومة الحوسبة الكمومية»، بل في خفض نطاق المفتاح من مستوى الحساب إلى مستوى عملية المبادلة الواحدة. فحتى لو اختُرق عنوان الاسترداد في المستقبل، لن يتمكن المهاجم من رؤية سوى المدفوعات المرتبطة بتلك المبادلة وحدها، بينما يظل مفتاح الإنفاق في الحساب الرئيسي للمستخدم. إنها فكرة عملية إلى حد بعيد؛ فالتهديد الكمومي عامل بعيد المدى، لكن ربط العناوين نقطة ضعف يمكن استغلالها الآن. معالجة المشكلات الصغيرة أولًا ثم الاستعداد للأكبر: ترتيب منطقي لم يختل.
ويحل المقترح أيضًا، بالمناسبة، مشكلة عملية مزعجة جدًا: فالمحفظة التي تجري مئات عمليات المبادلة ستجمع مئات المفاتيح، وعند الاستعادة من نسخة احتياطية، سيتعين فحص السلسلة بأكملها باستخدام كل مفتاح على حدة، ما يجعل تجربة الاستخدام كارثية. استخدمت Zakura تقنية استرجاع المعلومات الخاصة لإنشاء قاعدة بيانات تتيح الاستعلام بسرية، بحيث لا تعرف قاعدة البيانات أي عنوان تبحث عنه المحفظة عند الاستعلام عن وجهة الاسترداد. هنا لا تتعارض الخصوصية وسهولة الاستخدام، بل يراعيهما التصميم نفسه في آن واحد.
أما من حيث الجدول الزمني، فيمكن إضافة هذه الميزة إلى المحافظ المبنية على مكتبتها مفتوحة المصدر، بما فيها Vizor، خلال الأسابيع القليلة المقبلة. أما محافظ الأجهزة، فعليها انتظار دعم البرنامج الثابت. وبذلك يسبق التطبيق الموعد المستهدف لمعاملات الدفع المقاومة للحوسبة الكمومية، الذي حدده مطورو Zcash لهذا الشهر في يناير. لطالما استند خطاب الخصوصية لدى $ZEC إلى التفاصيل التقنية، وهذا النوع من الإصلاحات الأساسية أنفع بكثير من الشعارات. لكن تبقى المشكلة: صحيح أن تخصيص مفتاح لكل عملية يجعل التتبع أصعب، لكن على المحفظة إدارة مئات المفاتيح، وفي النهاية تقع كلفة الاستعادة والمزامنة على المستخدم. فهل ينبغي أن يتحمل البروتوكول كلفة الخصوصية، أم أن يتحملها كل مستخدم عادي بنفسه؟
#Zcash #隐私币 #الحوسبة_الكمومية
$NEAR $USDC
لا تكمن أهمية هذا التغيير في عبارة «مقاومة الحوسبة الكمومية»، بل في خفض نطاق المفتاح من مستوى الحساب إلى مستوى عملية المبادلة الواحدة. فحتى لو اختُرق عنوان الاسترداد في المستقبل، لن يتمكن المهاجم من رؤية سوى المدفوعات المرتبطة بتلك المبادلة وحدها، بينما يظل مفتاح الإنفاق في الحساب الرئيسي للمستخدم. إنها فكرة عملية إلى حد بعيد؛ فالتهديد الكمومي عامل بعيد المدى، لكن ربط العناوين نقطة ضعف يمكن استغلالها الآن. معالجة المشكلات الصغيرة أولًا ثم الاستعداد للأكبر: ترتيب منطقي لم يختل.
ويحل المقترح أيضًا، بالمناسبة، مشكلة عملية مزعجة جدًا: فالمحفظة التي تجري مئات عمليات المبادلة ستجمع مئات المفاتيح، وعند الاستعادة من نسخة احتياطية، سيتعين فحص السلسلة بأكملها باستخدام كل مفتاح على حدة، ما يجعل تجربة الاستخدام كارثية. استخدمت Zakura تقنية استرجاع المعلومات الخاصة لإنشاء قاعدة بيانات تتيح الاستعلام بسرية، بحيث لا تعرف قاعدة البيانات أي عنوان تبحث عنه المحفظة عند الاستعلام عن وجهة الاسترداد. هنا لا تتعارض الخصوصية وسهولة الاستخدام، بل يراعيهما التصميم نفسه في آن واحد.
أما من حيث الجدول الزمني، فيمكن إضافة هذه الميزة إلى المحافظ المبنية على مكتبتها مفتوحة المصدر، بما فيها Vizor، خلال الأسابيع القليلة المقبلة. أما محافظ الأجهزة، فعليها انتظار دعم البرنامج الثابت. وبذلك يسبق التطبيق الموعد المستهدف لمعاملات الدفع المقاومة للحوسبة الكمومية، الذي حدده مطورو Zcash لهذا الشهر في يناير. لطالما استند خطاب الخصوصية لدى $ZEC إلى التفاصيل التقنية، وهذا النوع من الإصلاحات الأساسية أنفع بكثير من الشعارات. لكن تبقى المشكلة: صحيح أن تخصيص مفتاح لكل عملية يجعل التتبع أصعب، لكن على المحفظة إدارة مئات المفاتيح، وفي النهاية تقع كلفة الاستعادة والمزامنة على المستخدم. فهل ينبغي أن يتحمل البروتوكول كلفة الخصوصية، أم أن يتحملها كل مستخدم عادي بنفسه؟
#Zcash #隐私币 #الحوسبة_الكمومية
$NEAR $USDC