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

الفكرة الأساسية هي نقل بعض معاملات إيثريوم من طابور nonce واحد لكل مرسل إلى عدة مسارات مستقلة. في النموذج المقترح لمعاملات EIP-8141 الإطارية، لا يعود هناك رقم تسلسلي واحد للمرسل، بل زوج من القيم: nonce_key وnonce_seq. المفتاح

nonce_key == 0

[1]

ما هو النونس أصلاً؟

في إيثريوم، الـ nonce هو عدّاد يستخدم لمنع إعادة تشغيل المعاملة نفسها أكثر من مرة. تخيله كرقم دور في طابور: إذا تعطل رقم في الوسط، قد تتأخر الأرقام التي بعده.

في السياق الذي يستهدفه EIP-8250، تستهلك معاملة الإطار حالياً نونساً خطياً واحداً من المرسل ^[1]. المقترح يبدل ذلك بهذين الحقلين:

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

بحسب نقاش Ethereum Magicians حول المقترح، تحفظ المفاتيح غير الصفرية في عقد نظام يسمى NONCE_MANAGER، وتكون المعاملات على مفاتيح غير صفرية مختلفة مستقلة من ناحية منع إعادة التشغيل ^[1]. بعبارة أبسط: بدلاً من مسار واحد مزدحم لكل حساب، يصبح بالإمكان وجود عدة مسارات ذات مفاتيح.

هذا لا يعني أن كل معاملات إيثريوم ستصبح غير مرتبة أو متوازية فجأة. نطاق EIP-8250 محدد بمعاملات EIP-8141 الإطارية، مع إبقاء المفتاح صفر على سلوك النونس التقليدي للحساب ^[1].

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

تظهر المشكلة بوضوح عندما يمر عدد كبير من المستخدمين المستقلين عبر عنوان مرسل واحد. يصف ETH Daily المقترح بأنه مفيد خصوصاً لبروتوكولات الخصوصية التي توجه معاملات مستخدمين متعددين من خلال عنوان مشترك ^[12].

في نموذج النونس الواحد، إذا تأخرت معاملة إطار من ذلك العنوان، فقد تعطل المعاملات اللاحقة من المرسل نفسه ^[1][12]. هذا يشبه أن يقف الجميع في طابور واحد أمام نافذة واحدة: توقف شخص واحد يعني انتظار من خلفه، حتى لو لم تكن معاملاتهم مرتبطة به.

النونس بالمفاتيح يقسم هذا الطابور إلى نطاقات مستقلة. يمكن لبروتوكول خصوصية أن يضع التدفقات غير المرتبطة على مفاتيح مختلفة، بحيث لا تتنافس كلها على الرقم التسلسلي نفسه للمرسل ^[1]. لذلك فالقيمة الأولى للمقترح ليست أنه يخفي البيانات، بل أنه يحسن طريقة منع الإعادة وتنظيم التدفق.

أين تدخل nullifiers في القصة؟

النونس بالمفاتيح لا يخفي الرصيد، ولا المستلم، ولا مبلغ التحويل بمفرده. هناك مقترحات خصوصية أخرى أكثر مباشرة، مثل EIP-8182، تصف تحويلات خاصة لـ ETH ورموز ERC-20 عبر عقد نظام، وآلية تحقق من البراهين، وملاحظات، وإيداعات، وتحويلات خاصة، وسحوبات ^[9].

صلة EIP-8250 بالخصوصية أضيق لكنها مهمة. التقارير حول المقترح تستخدم nullifiers كمثال أساسي على بيانات الخصوصية التي تكبر بمرور الوقت ولا يمكن حذفها بعد دخولها النظام ^[3][4]. في أنظمة الخصوصية، تُستخدم سجلات من نمط nullifier لمنع إعادة استخدام حالة خاصة سبق إنفاقها؛ ولأنها يجب أن تبقى قابلة للفحص لاحقاً، فقد تصبح عبئاً طويل الأمد على حالة الشبكة ^[3][4].

من هنا، لا ينبغي فهم EIP-8250 على أنه بروتوكول خصوصية قائم على براهين صفرية. هو أقرب إلى آلية أصلية في البروتوكول لإدارة تسلسلات مستقلة كثيرة، ولهذا يربطه المعلقون بفكرة تخزين nullifiers في بنية مخصصة وبنماذج حالة متخصصة أخرى ^[1][4][10].

من تعديل صغير إلى نقاش حالة إيثريوم

تصف تقارير عن فيتاليك بوتيرين الفكرة بوصفها خطوة محتملة نحو حالة متخصصة: بدلاً من وضع كل أنواع البيانات في حالة إيثريوم الديناميكية العامة، يمكن لبعض الاستخدامات الضيقة وكثيفة الحجم أن تحصل على تخزين مصمم وفق نمط وصولها ^[4][5][10].

المثال الضاغط هنا هو nullifiers الخاصة بمعاملات الخصوصية. تكرر عدة تقارير مثالاً يقول إن استمرار 2,000 معاملة خصوصية على السلسلة في الثانية لمدة ثماني سنوات قد ينتج نحو 500 مليار nullifier ^[2][5][7]. يجب قراءة هذا الرقم كصورة لحجم المشكلة، لا كدليل على خطة مفعلة بالفعل؛ فآليات EIP-8250 نفسها معروضة في نقاش على Ethereum Magicians مرتبط بطلب سحب إلى مستودع مقترحات EIP ^[1].

وتصف بعض التقارير مخزناً مخصصاً للـ nullifiers، ربما باستخدام التجزئة إلى شظايا ومرشحات بلوم، كطريقة قد تجعل هذا النوع من البيانات الضخمة أسهل على العقد من وضعه كله في الحالة الديناميكية العامة ^[2][14]. الفكرة الأوسع هي أن التخزين المتخصص قد يناسب الأعمال الضيقة والمتوقعة أكثر، مع محاولة الحفاظ على اللامركزية ^[5][10].

ما الذي قد يحسنه EIP-8250؟

• تقليل اختناق العنوان المشترك: عندما تمرر بروتوكولات الخصوصية مستخدمين متعددين عبر مرسل واحد، قد تقلل المفاتيح المستقلة انتظار تدفقات غير مرتبطة على النونس نفسه ^[1][12].
• عزل أفضل لمنع الإعادة: ينص المقترح على أن المعاملات على مفاتيح غير صفرية مختلفة تكون مستقلة من ناحية replay protection ^[1].
• دعم أوضح للخصوصية على مستوى البروتوكول: تصف تقارير النونس بالمفاتيح كتعزيز لدعم حلول الخصوصية على السلسلة، بدلاً من ترك كل أنماط منع الإعادة أو nullifiers لعقود التطبيقات وحدها ^[4][5].
• طريق نحو حالة متخصصة: النقاش الأكبر هو أن إيثريوم قد تستخدم بنى تخزين موجهة لأحمال عمل محددة، بدلاً من التعامل مع كل البيانات كدلو عام واحد ^[4][10].

ما الذي لا يفعله المقترح؟

• لا يستبدل كل أنواع النونس في إيثريوم. نطاقه هو معاملات EIP-8141 الإطارية، مع ربط

  nonce_key == 0

  بسلوك نونس الحساب التقليدي ^[1].
• لا يجعل المعاملة خاصة بذاته. التحويلات الخاصة تحتاج آليات إضافية مثل الملاحظات، والتحقق من البراهين، وقواعد الإيداع والتحويل والسحب، كما يوضح EIP-8182 ^[9].
• لا يعني أن إيثريوم ستخزن حتماً 500 مليار سجل. رقم 500 مليار يأتي من مثال افتراضي مبني على 2,000 معاملة في الثانية لمدة ثماني سنوات لشرح تحدي توسع nullifiers ^[2][5][7].
• ليس سلوكاً مفعلاً في البروتوكول حالياً. التفاصيل منشورة في نقاش مرتبط بطلب سحب لمقترح EIP، لذلك قد تتغير الآليات والتوقيت قبل أي اعتماد فعلي ^[1].

الخلاصة

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