الخطوة الأولى تستهدف عملية إدراج المعاملات في الكتل. ففي إيثريوم، يقرر منشئو الكتل (block builders) والمقترحون (proposers) في النهاية أي المعاملات تدخل الكتلة. هذا يمنحهم نظرياً القدرة على تأخير أو تجاهل معاملات معينة — خصوصاً تلك المتعلقة بالخصوصية.

الحل المقترح يجمع بين Account Abstraction وآلية Fork‑Choice Enforced Inclusion Lists (FOCIL). تسمح هذه الآلية للجان من المدققين بفرض إدراج المعاملات الصالحة الموجودة في الـmempool خلال عدد محدود من الفتحات الزمنية (slots)، بدلاً من ترك القرار بالكامل لمقترح كتلة واحد.

ومن المتوقع أن تكون FOCIL من أبرز ميزات ترقية الشبكة المعروفة باسم Hegota، المخطط إطلاقها في النصف الثاني من عام 2026. الهدف هو ضمان أن المعاملات التي تلتزم بقواعد البروتوكول لا يمكن استبعادها بسهولة من قبل البنّائين أو الوسطاء أو المدققين.

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

2. نظام Keyed Nonces (EIP‑8250) للمعاملات المتوازية

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

اقتراح EIP‑8250 يقدم نموذجاً جديداً يسمى Keyed Nonces. في هذا النظام تحتوي كل معاملة على حقلين:

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

المعاملات التي تستخدم مفاتيح مختلفة يمكن أن تعمل بشكل مستقل ومتوازٍ. وهذا يعني أن تعطل معاملة واحدة لن يمنع تنفيذ معاملات أخرى غير مرتبطة بها.

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

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

3. خصوصية طبقة الوصول: المحافظ وKohaku والقراءات الخاصة

المشكلة الثالثة أقل وضوحاً لكنها مهمة: تسرب البيانات من خلال المحافظ وموفري RPC.

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

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

يهدف Kohaku إلى جعل ميزات الخصوصية جزءاً طبيعياً من المحافظ القياسية، بدلاً من إجبار المستخدمين على الاعتماد على تطبيقات خصوصية منفصلة. بعض التصميمات تدمج أيضاً تقنيات العميل الخفيف (Light Client) بحيث تستطيع المحافظ التحقق من بيانات البلوكشين بنفسها بدلاً من الاعتماد الكامل على خدمات RPC المركزية.

بهذه الطريقة يمكن تقليل كمية البيانات التي يراها مزودو البنية التحتية عن نشاط المستخدمين.

كيف تنسجم هذه الخطة مع استراتيجية الخصوصية الأوسع لإيثريوم

تعكس هذه الخريطة تحولاً في طريقة تعامل إيثريوم مع الخصوصية. بدلاً من انتظار بروتوكول شامل واحد يحل كل شيء، يتجه النظام البيئي إلى تحسينات تدريجية عبر عدة طبقات من البنية التقنية.

هذه الترقيات تستهدف نقطتين ضعيفتين في معظم شبكات البلوكشين اليوم:

• رقابة المعاملات: حيث يمكن للمدققين أو البنّائين منع معاملات معينة.
• تسرب البيانات الوصفية: حيث تكشف استعلامات المحافظ أو البنية التحتية سلوك المستخدمين.

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

والهدف النهائي هو شبكة يستطيع فيها الأفراد والشركات التفاعل على إيثريوم دون كشف كل نشاطهم علناً، مع الحفاظ في الوقت نفسه على الشفافية وقابلية التحقق التي تجعل البلوكشين العام يعمل.

الخطوة الأولى تستهدف عملية إدراج المعاملات في الكتل. ففي إيثريوم، يقرر منشئو الكتل (block builders) والمقترحون (proposers) في النهاية أي المعاملات تدخل الكتلة. هذا يمنحهم نظرياً القدرة على تأخير أو تجاهل معاملات معينة — خصوصاً تلك المتعلقة بالخصوصية.

الحل المقترح يجمع بين Account Abstraction وآلية Fork‑Choice Enforced Inclusion Lists (FOCIL). تسمح هذه الآلية للجان من المدققين بفرض إدراج المعاملات الصالحة الموجودة في الـmempool خلال عدد محدود من الفتحات الزمنية (slots)، بدلاً من ترك القرار بالكامل لمقترح كتلة واحد.

ومن المتوقع أن تكون FOCIL من أبرز ميزات ترقية الشبكة المعروفة باسم Hegota، المخطط إطلاقها في النصف الثاني من عام 2026. الهدف هو ضمان أن المعاملات التي تلتزم بقواعد البروتوكول لا يمكن استبعادها بسهولة من قبل البنّائين أو الوسطاء أو المدققين.

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

2. نظام Keyed Nonces (EIP‑8250) للمعاملات المتوازية

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

اقتراح EIP‑8250 يقدم نموذجاً جديداً يسمى Keyed Nonces. في هذا النظام تحتوي كل معاملة على حقلين:

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

المعاملات التي تستخدم مفاتيح مختلفة يمكن أن تعمل بشكل مستقل ومتوازٍ. وهذا يعني أن تعطل معاملة واحدة لن يمنع تنفيذ معاملات أخرى غير مرتبطة بها.

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

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

3. خصوصية طبقة الوصول: المحافظ وKohaku والقراءات الخاصة

المشكلة الثالثة أقل وضوحاً لكنها مهمة: تسرب البيانات من خلال المحافظ وموفري RPC.

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

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

يهدف Kohaku إلى جعل ميزات الخصوصية جزءاً طبيعياً من المحافظ القياسية، بدلاً من إجبار المستخدمين على الاعتماد على تطبيقات خصوصية منفصلة. بعض التصميمات تدمج أيضاً تقنيات العميل الخفيف (Light Client) بحيث تستطيع المحافظ التحقق من بيانات البلوكشين بنفسها بدلاً من الاعتماد الكامل على خدمات RPC المركزية.

بهذه الطريقة يمكن تقليل كمية البيانات التي يراها مزودو البنية التحتية عن نشاط المستخدمين.

كيف تنسجم هذه الخطة مع استراتيجية الخصوصية الأوسع لإيثريوم

تعكس هذه الخريطة تحولاً في طريقة تعامل إيثريوم مع الخصوصية. بدلاً من انتظار بروتوكول شامل واحد يحل كل شيء، يتجه النظام البيئي إلى تحسينات تدريجية عبر عدة طبقات من البنية التقنية.

هذه الترقيات تستهدف نقطتين ضعيفتين في معظم شبكات البلوكشين اليوم:

• رقابة المعاملات: حيث يمكن للمدققين أو البنّائين منع معاملات معينة.
• تسرب البيانات الوصفية: حيث تكشف استعلامات المحافظ أو البنية التحتية سلوك المستخدمين.

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

والهدف النهائي هو شبكة يستطيع فيها الأفراد والشركات التفاعل على إيثريوم دون كشف كل نشاطهم علناً، مع الحفاظ في الوقت نفسه على الشفافية وقابلية التحقق التي تجعل البلوكشين العام يعمل.