أفادت The Defiant في 25 مايو، أن مبادرة Kohaku التابعة لمؤسسة Ethereum Foundation أصدرت SDK يتيح للمطورين دمج بروتوكولات صناديق الإخفاء مثل RAILGUN وTornado Cash وPrivacy Pools بسلاسة داخل واجهة محافظ Ethereum، دون الحاجة إلى الاعتماد على وسطاء. وتؤكد أحدث نسخة أن هذه الوظيفة تعمل ضمن ذاكرة التخزين المؤقتة (mempool) الخاصة بـ ERC-4337 كنقطة ترحيل يتم تشغيلها بالذاكرة.
الأهمية التقنية لترحيل mempool في 4337: التخلص من الاعتماد على مرحّلين مركزيين
يتيح معيار ERC-4337 (معيار تجريد الحساب) إرسال عمليات المستخدم (UserOperations) عبر مجموعة ذاكرة تخزين مؤقتة بديلة (Alternative Mempool)، دون الحاجة إلى تعديل طبقة بروتوكول Ethereum. في السابق، كانت بروتوكولات الخصوصية مثل RAILGUN تتطلب عادةً الاعتماد على مرحّلين مركزيين يعملون من طرف ثالث لبث معاملات الخصوصية. وقد أدّى هذا الاعتماد إلى تقليل قابلية المعاملات لمقاومة الرقابة وخلق مخاطر تتمثل في حجب بروتوكولات الخصوصية بشكل انتقائي.
تحقق ترحيلة ذاكرة التخزين المؤقتة 4337 التي نفذتها Kohaku تغييرات تقنية مؤكدة، وهي: يتم توجيه معاملات الخصوصية عبر مسارات mempool القياسية لـ ERC-4337، باستخدام البنية التحتية نفسها التي تُستخدم لعمليات UserOperations العادية؛ لم يعد المستخدم بحاجة إلى الثقة بمشغّل مرحّل بعينه؛ ويُصبح مسار بث المعاملات أكثر سمات لا مركزية، متوافقًا مع فلسفة Ethereum لمقاومة الرقابة. وصفت Kohaku هذا التحول بأنه «مساهمة كبيرة في تمكين المستخدمين من التحكم في خصوصيتهم، دون الحاجة إلى الاعتماد على مرحّلات مركزية».
وظائف SDK المؤكدة، وتقدم عمليات الدمج، وخريطة الطريق المستقبلية
جارٍ التشغيل بالفعل: دمج RAILGUN (v0.0.1-alpha.21)، وترحيل mempool لـ ERC-4337؛ عرض توضيحي عبر CLI لمحفظة (تم إتاحته لإظهار الوظائف الحقيقية للـ SDK)؛ وفتح كود SDK بالكامل كمصدر مفتوح (GitHub).
عمليات دمج جارية: دمج Tornado Cash (قيد التطوير)؛ دمج Privacy Pools (قيد التطوير)؛ دمج محفظة Ambire (مستعد تحضيريًا بشكل مؤكد)؛ إضافة متصفح (محفظة) تجريبية (قيد التطوير بالتعاون مع breadcoop).
مُدرج ضمن خطط التطوير لكنه غير مكتمل بعد: بنية تحتية لحسابات ما بعد الكمية؛ دعم التوقيعات المتعددة؛ دعم المحافظ العتادية (hardware)؛ عميل خفيف لمتصفح؛ آلية استعادة هوية باستخدام الإثباتات ZK؛ اتصال نظير-لنظير يركز على الخصوصية.
تخطط Kohaku لعرض أحدث التطورات خلال أسبوع بلوكتشين في برلين.
الأسئلة الشائعة
كيف يحمي دمج RAILGUN داخل Kohaku SDK خصوصية المستخدم، وما هي التقنية الأساسية؟
RAILGUN هو نظام عقود ذكية يتم نشره على سلاسل عامة مثل Ethereum، ويستخدم تقنية إثباتات المعرفة الصفرية (zk-SNARKs) ما يسمح للمستخدم بإزالة معلومات عنوان المحفظة من سجلات المعاملات عند تنفيذ تحويل أو معاملة أو استخدام DApp، لتحقيق إخفاء الهوية على السلسلة. وتتمثل الآلية المحددة في أن المستخدم يودع الرموز في RAILGUN ضمن حوض الإخفاء (Shielded Pool). بعد ذلك، لا يتم نشر هوية المستخدم بشكل علني ومباشر على السلسلة ضمن ما يجري داخل الحوض. وعند الخروج، يتم إتمام التسوية عبر إثبات ZK. تقوم Kohaku SDK بإدخال وظائف RAILGUN هذه كمستودع عمل (work library) مباشرة ضمن أدوات Ethereum، بحيث يستطيع مطورو المحافظ تقديم هذه القدرة للمستخدمين دون الحاجة إلى إعادة بناء منطق الخصوصية الأساسي.
هل يوجد خطر امتثال تنظيمي لدمج Kohaku Initiative Tornado Cash؟
Tornado Cash هو بروتوكول خلط عملات على سلسلة Ethereum، وقد أدرجت وزارة الخزانة الأمريكية في 2022 مطوريه ضمن قائمة عقوبات OFAC، الأمر الذي أدى إلى جدل قانوني حول استخدام الأكواد في الولايات القضائية مثل الولايات المتحدة. وما تزال Kohaku Initiative تدرج دمج Tornado Cash ضمن خطط التطوير، وهو ما يعكس تمسك مؤسسة Ethereum Foundation بحياد البروتوكول — مع جعل حيادية الكود نفسه هي المعيار الأساسي بدلًا من اعتبار قوائم عقوبات حكومة بعينها معيارًا للدمج. وبالنسبة للمستخدمين النهائيين، تختلف مخاطر الامتثال عند استخدام Tornado Cash بحسب الولاية القضائية التي يقيم فيها المستخدم؛ وينبغي للمستخدمين فهم اللوائح المحلية قبل الاستخدام.
كيف يعكس إصدار SDK هذه المرة التوجه التقني لـ Vitalik Buterin «تقليل الوسطاء» كما طرحه في مقال طويل أُعيدت فيه هيكلة EF؟
ضمن مقال EF لإعادة الهيكلة بتاريخ 24 مايو 2026، أدرج Vitalik «تقليل الوسطاء (Minimizing Intermediaries)» كواحد من ثلاثة تفضيلات تقنية كبرى لمرحلة Ethereum التالية. وقد أشار صراحةً إلى FOCIL وEIP-8141 وEIP-7701 و إطار عمل محفظة Kohaku بوصفها مكونات عمل محددة. تعد وظيفة ترحيل mempool ضمن 4337 في Kohaku SDK التطبيق التقني الأكثر مباشرةً لهذا التوجه: إذ تُمكّن المستخدمين من تنفيذ معاملات الخصوصية عبر ذاكرة تخزين مؤقتة لا مركزية مُعيارية (بدل الاعتماد على خدمة ترحيل مركزية)؛ وهو ما يتوافق مع هدف تصميم Vitalik الذي يتمثل في أن «يستطيع المستخدم والبروتوكول إرسال المعاملات مباشرة إلى سلسلة الكتل دون الحاجة إلى مسار توجيه عبر طرف ثالث».
