قال فيتاليك بوتيرين إن “المفاتيح غير القابلة للتكرار” (Keyed Nonces) قد تصبح أكثر من مجرد تحسين للخصوصية على شبكة إيثريوم. في منشور له على منصة إكس، وصفها بأنها خطوة أولى محتملة نحو استراتيجية جديدة لتوسيع نطاق الحالة (State Scaling) تعتمد على تخزين متخصص.
تركز الفكرة على نقل بعض حالات الاستخدام بعيدًا عن الحالة الديناميكية الكاملة لإيثريوم. وفي الوقت نفسه، تظل معاملات الخصوصية مثالًا رئيسيًا، حيث أن أدوات الإبطال (Nullifiers) تستمر في النمو بمرور الوقت ولا يمكن حذفها بعد دخولها إلى النظام.
بوتيرين يشرح فكرة المفاتيح غير القابلة للتكرار
قال بوتيرين إن المفاتيح غير القابلة للتكرار تضيف دعمًا أقوى على مستوى البروتوكول لحلول الخصوصية. لكنه قدمها أيضًا كجزء من خطة أوسع لإنشاء أنواع تخزين محسّنة لفئات محددة من النشاط على إيثريوم.
يقترح هذا التصميم استبدال المفتاح الواحد للمرسل (Sender Nonce) بهيكل جديد يستخدم مفتاحًا غير قابل للتكرار (Nonce Key) وتسلسلًا غير قابل للتكرار (Nonce Sequence). هذا النموذج يمنح الحسابات مرونة أكبر في ترتيب المعاملات، مع دعم حالات الاستخدام التي تحتاج إلى مسارات منفصلة للمفاتيح غير القابلة للتكرار.
من الجدير بالذكر أن بوتيرين ربط هذه الفكرة بأدوات الإبطال داخل البروتوكول. تستخدم أنظمة الخصوصية أدوات الإبطال لمنع إنفاق نفس العملة أو الرمز مرتين، وكل معاملة تضيف قيمة جديدة إلى مجموعة تستمر في التوسع.
أعطى بوتيرين مثالًا واسع النطاق بـ 2,000 معاملة خاصة في الثانية لمدة ثماني سنوات. هذا السيناريو سيخلق حوالي 500 مليار أداة إبطال على السلسلة، مما يترك إيثريوم أمام تحدي تخزين كبير.
تخزين أدوات الإبطال يصبح قضية رئيسية
قال بوتيرين إن إيثريوم ستبقى أكثر لامركزية إذا تم وضع تلك الـ 500 مليار أداة إبطال في مخزن مخصص لها. وأوضح أن هذه النتيجة ستكون أفضل من وضعها في الحالة العامة الحالية.
السبب يعود إلى كيفية استخدام أدوات الإبطال. فهي تحتاج فقط إلى فحوصات الصلاحية، ويمكن للمعاملات أن توفر معرف أداة الإبطال بشكل صريح، لذلك لا تحتاج العقد إلى نفس المستوى من الوصول الديناميكي المطلوب من تطبيقات التمويل اللامركزي (DeFi).
وفقًا للملاحظة الفنية، فإن دعم الخصوصية الافتراضي قد يتطلب تخزين 32 بايت لكل معاملة في VOPS. بمعدل 1,000 معاملة خاصة في الثانية لمدة ثماني سنوات، سينتج عن ذلك مجموعة أدوات إبطال بحجم 8 تيرابايت.
يقدم مرشح بلوم (Bloom Filter) مسارًا آخر. قالت الملاحظة إن المرشح يمكن أن يقلل المتطلبات إلى حوالي بايت واحد لكل أداة إبطال، أو حوالي 277 جيجابايت بعد ثماني سنوات على نطاق واسع، مع معدل خطأ إيجابي كاذب منخفض.
مرشحات بلوم والتقسيم (Sharding) تدخلان الخطة
استشهد بوتيرين أيضًا بالتقسيم (Sharding) كخيار محتمل لتخزين أدوات الإبطال. في ظل هذا الهيكل، يمكن لكل عقدة الاحتفاظ بنسبة صغيرة فقط من أدوات الإبطال والحفاظ على روابط مع عقد موثوقة عبر أقسام أخرى.
ومع ذلك، فإن مقترح مرشح بلوم يسلك طريقًا مختلفًا. كل عقدة ستحتفظ بمرشح خاص بها، وتتحقق مما إذا كانت أداة الإبطال قد تم إنفاقها، وتقبل أن بعض المعاملات الصالحة قد تواجه رفضًا عشوائيًا.
قدرت الملاحظة أن الرفض الخاطئ يبلغ حوالي 3% للمعاملات التي تستخدم أداة إبطال واحدة، وحوالي 9% للمعاملات التي تنفق ثلاث أدوات إبطال. وأشارت إلى أن التكرار في FOCIL ومجمعات الذاكرة (Mempools) يمكنه استيعاب هذا المقايضة.
قال بوتيرين إن الحالة الديناميكية الكاملة تصبح أصعب بكثير في الإدارة عند عشرات أو مئات التيرابايتات. الحالة المتخصصة يمكن أن تبقي الغاز أرخص لحالات الاستخدام المحدودة، مع الحفاظ على التخزين الديناميكي لتطبيقات DeFi والتطبيقات الأخرى التي تحتاج إلى مرونة كاملة.
الأسئلة الشائعة (FAQs)
- س: ما هي المفاتيح غير القابلة للتكرار (Keyed Nonces) بالضبط؟
ج: هي تحديث لطريقة ترتيب المعاملات على إيثريوم. بدلاً من استخدام مفتاح واحد لكل حساب، تقترح الفكرة استخدام مفتاح وتسلسل جديدين. هذا يسمح بترتيب أكثر مرونة للمعاملات ويدعم تطبيقات الخصوصية بشكل أفضل. - س: لماذا يعتبر تخزين أدوات الإبطال (Nullifiers) مشكلة كبيرة؟
ج: أدوات الإبطال تُستخدم لمنع إنفاق العملات مرتين في معاملات الخصوصية. مع زيادة عدد المعاملات، يزداد عدد هذه الأدوات بشكل هائل (قد يصل إلى مئات المليارات). هذا يخلق مشكلة تخزين ضخمة على الشبكة، مما يؤثر على الأداء واللامركزية. - س: ما هو الحل الذي يقترحه فيتاليك بوتيرين لمشكلة التخزين؟
ج: يقترح بوتيرين عدة حلول، منها: 1) إنشاء مخزن مخصص لأدوات الإبطال بدلاً من وضعها مع البيانات العامة. 2) استخدام مرشحات بلوم (Bloom Filters) لتقليل حجم التخزين المطلوب بشكل كبير. 3) استخدام تقنية التقسيم (Sharding) لتوزيع التخزين على عقد متعددة.
