EIP-8250 في إيثريوم: كيف تعمل «النانسات» ذات المفاتيح؟

ما الذي يغيره EIP-8250 فعلياً؟

في النموذج الحالي لمعاملات Frame، تستهلك كل معاملة نانساً خطياً واحداً من المرسل. إذا تأخرت معاملة واحدة، يمكن أن تعطل كل معاملات Frame اللاحقة الصادرة من المرسل نفسه . يقترح EIP-8250 استبدال هذا التسلسل الواحد بحقلين:

• nonce_key: يحدد نطاق الحماية من إعادة الإرسال.
• nonce_seq: يمثل الرقم التسلسلي داخل ذلك النطاق المحدد.

نقطة التصميم المهمة هنا هي التوافق مع السلوك القائم. عندما يكون

nonce_key == 0

بكلمات أبسط: بدلاً من طابور واحد واسع للحساب، يصبح لدى المرسل عدة مسارات مرتبطة بمفاتيح. المعاملات التي تستخدم مفاتيح غير صفرية مختلفة تكون مستقلة من ناحية إعادة الإرسال، لكن الترتيب لا يختفي كلياً؛ فهو يبقى موجوداً داخل كل مفتاح على حدة . لذلك لا ينبغي فهم المقترح كزر لتشغيل التنفيذ المتوازي لكل معاملات إيثريوم، بل كتعديل في حماية إعادة الإرسال لنوع محدد من المعاملات.

لماذا تهتم بروتوكولات الخصوصية بهذا؟

تظهر المشكلة عندما تمر معاملات تخص مستخدمين غير مرتبطين ببعضهم عبر عنوان إرسال واحد. بحسب ETH Daily، هذا هو السبب الذي يجعل EIP-8250 مهماً لبروتوكولات الخصوصية: هذه البروتوكولات قد تستخدم عنواناً مشتركاً لتمرير تدفقات كثيرة ومستقلة . ومع وجود نانس خطي واحد، فإن تأخر معاملة واحدة من ذلك العنوان قد يوقف كل ما بعدها في السلسلة نفسها .

النانسات ذات المفاتيح تخفف هذا النوع من «ازدحام مقدمة الطابور». فبدلاً من وضع كل التدفقات في مسار واحد، يمكن للبروتوكول توزيع التدفقات غير المرتبطة على مفاتيح نانس غير صفرية مختلفة، بحيث لا يؤدي تعطل تدفق واحد بالضرورة إلى تعطيل كل التدفقات الأخرى من العنوان المشترك نفسه . ومع ذلك، تبقى الوظيفة الأمنية الأساسية هي منع إعادة الإرسال، لا إزالة فحوصات الأمان أو تجاوزها .

ما علاقة nullifiers وتوسيع الحالة؟

لا يخفي EIP-8250 الأرصدة أو عناوين المستلمين أو مبالغ التحويل من تلقاء نفسه. فمثلاً، يقترح EIP-8182، وهو مقترح منفصل، نموذجاً لتحويلات ETH وERC-20 خاصة عبر عقد نظام، ومكوّن تحقق من الإثباتات، وملاحظات notes، وإيداعات، وتحويلات خاصة، وسحوبات . هذه هي النوعية الإضافية من البنية المطلوبة إذا كان الهدف هو تحويلات خاصة فعلاً.

صلة EIP-8250 بالخصوصية أقرب إلى مسألة تنظيم الحالة وتوسيعها. التقارير التي تلخص تعليقات بوتيرين تشير إلى أن nullifiers في أنظمة الخصوصية هي حالة الضغط الأساسية: فهي تكبر مع الوقت ولا يمكن تقليمها بعد دخولها النظام . في سياق الخصوصية، تُستخدم هذه السجلات لمنع إعادة استخدام حالة خاصة سبق إنفاقها أو استهلاكها، لذلك يجب أن تبقى قابلة للفحص.

الرقم المتداول في التقارير كبير: إذا استمرت معاملات الخصوصية على السلسلة بمعدل 2,000 معاملة في الثانية لمدة ثماني سنوات، فقد ينتج عنها نحو 500 مليار nullifier . لكن ينبغي قراءة هذا الرقم كمثال ضغط لا كتعهد بأن إيثريوم ستخزن هذا العدد فعلاً، ولا كدليل على أن EIP-8250 أصبح مجدولاً للتفعيل.

لماذا قد يكون التخزين المتخصص مهماً؟

حجة توسيع الحالة هنا بسيطة: ليست كل أنواع البيانات على إيثريوم بحاجة إلى نموذج التخزين العام نفسه. تصف تقارير النانسات ذات المفاتيح كخطوة محتملة نحو أنواع تخزين مخصصة لأعباء عمل محددة، مع اعتبار nullifiers الخاصة بالخصوصية المثال الأبرز .

بعض التقارير تتحدث عن مخزن مخصص لـ nullifiers يستخدم تقنيات مثل التقسيم sharding ومرشحات Bloom لجعل مجموعات بيانات الخصوصية الضخمة أسهل على العقد من إدارتها مقارنة بوضع كل السجلات داخل حالة إيثريوم الديناميكية العامة . جاذبية الفكرة أن nullifiers بيانات ضيقة الغرض وكثيفة الإضافة: يجب التحقق من وجودها أو عدم وجودها، لكنها لا تحتاج المرونة نفسها التي تحتاجها عقود ذكية عشوائية.

لهذا السبب تجاوز الاهتمام بالمقترح تفصيل النانس نفسه. EIP-8250 يتحدث مباشرة عن حماية إعادة الإرسال بمفاتيح في معاملات Frame، لكن الاتجاه المعماري الأوسع هو دعم هياكل يديرها البروتوكول لأعباء عمل كبيرة ومتوقعة .

ما الذي يمكن أن يحسنه EIP-8250؟

• رفع سعة العناوين المشتركة: بروتوكولات الخصوصية التي تمرر مستخدمين كثيرين عبر عنوان واحد قد تتجنب إجبار كل التدفقات على انتظار طابور نانس واحد إذا تعطلت معاملة مبكرة .
• عزل إعادة الإرسال: المفاتيح غير الصفرية المختلفة تعمل كنطاقات مستقلة، ولذلك تكون المعاملات عليها مستقلة من ناحية إعادة الإرسال .
• دعم أقوى على مستوى البروتوكول للخصوصية: تقارير ثانوية تنقل أن بوتيرين عرض النانسات ذات المفاتيح كوسيلة لدعم أنظمة الخصوصية على السلسلة بصورة أقرب إلى البروتوكول نفسه .
• مسار نحو حالة متخصصة: تصف تقارير أخرى الفكرة كجزء من استراتيجية لتوسيع الحالة عبر هياكل تخزين مصممة لاستخدامات محددة .

ما الذي لا يفعله EIP-8250؟

• لا يستبدل كل نانس في إيثريوم. نطاق المقترح هو معاملات EIP-8141 من نوع Frame، كما أن المفتاح 0 يحافظ على مسار النانس التقليدي للحساب .
• لا يجعل المعاملات خاصة وحده. تصميم التحويلات الخاصة يحتاج مكونات أخرى مثل notes، والتحقق من الإثباتات، والإيداعات، وقواعد التحويل والسحب، كما يوضح EIP-8182 .
• لا يثبت أن إيثريوم ستخزن 500 مليار سجل خصوصية. هذا الرقم يأتي من أمثلة منشورة تفترض 2,000 معاملة خصوصية في الثانية على مدى ثماني سنوات .
• ليس سلوكاً مفعّلاً في البروتوكول حالياً. الآلية موضحة في نقاش EIP على Ethereum Magicians مرتبط بطلب سحب، وبالتالي قد تتغير تفاصيل التنفيذ .

الخلاصة

أفضل طريقة لفهم EIP-8250 هي اعتباره مقترحاً لحماية إعادة الإرسال له آثار محتملة على توسيع الخصوصية. التغيير المباشر بسيط: تقسيم ترتيب النانس في معاملات Frame إلى مسارات مرتبطة بمفاتيح. أما الأهمية الأكبر فهي معمارية: إذا استطاعت إيثريوم توفير هياكل يديرها البروتوكول لأعباء عمل ضيقة وعالية الحجم، فقد تتمكن أنظمة الخصوصية من التوسع من دون دفع كل سجل غير قابل للتقليم إلى الحالة العامة بالكامل .