المؤلف: فيتاليك، مؤسس الإيثريوم؛ بالإضافة إلى المخاوف بشأن أمان الشبكة، فإن الانتقاد الأكثر شيوعًا لرفع حد الغاز L1 هو أنه سيجعل من الصعب تشغيل عقدة كاملة. وخاصة في سياق خريطة الطريق التي تركز على "إلغاء ربط العقد الكاملة"، فإن حل هذه المشكلة يتطلب أولاً فهم أهمية العقد الكاملة.
الرأي التقليدي هو أن العقد الكاملة تُستخدم للتحقق من البيانات الموجودة على السلسلة. إذا كانت هذه هي المشكلة الوحيدة، فإن ZK-EVM سوف يفتح المجال لتوسيع نطاق L1: والحد الوحيد هو الحفاظ على تكاليف بناء الكتلة وإثباتها منخفضة بما يكفي بحيث يحافظ كلاهما على مقاومة الرقابة 1 من n مع السماح بسوق تنافسية.
ولكن في الواقع هذا ليس الاعتبار الوحيد. هناك عامل مهم آخر وهو أن تشغيل عقدة كاملة يمنحك خادم RPC محلي يسمح لك بقراءة البيانات الموجودة على السلسلة بطريقة لا تعتمد على الثقة ومقاومة للرقابة وتحافظ على الخصوصية. ستتناول هذه المقالة كيفية تعديل خريطة طريق توسيع L1 الحالية لتحقيق هذا الهدف.
1. لماذا أنت غير راضٍ عن اللامركزية والخصوصية التي حققها ZK-EVM+PIR؟
تدعو خريطة الطريق الخاصة بالخصوصية التي أصدرتها الشهر الماضي إلى: اعتماد حل TEEs+ORAM على المدى القصير والتحول إلى تقنية PIR على المدى الطويل. من خلال الجمع بين التحقق من Helios وZK-EVM، يمكن للمستخدمين أن يكونوا واثقين تمامًا عند الاتصال بـ RPCs الخارجية من أن: (i) بيانات السلسلة التي تم الحصول عليها صحيحة، و(ii) خصوصية البيانات محمية. وهذا يثير السؤال: لماذا لا نتوقف عند هذا الحد؟ هل تؤدي هذه المخططات التشفيرية المتقدمة إلى جعل العقد المستضافة ذاتيًا قديمة؟
لدي بعض الردود على هذا:
--الأنظمة التشفيرية التي لا تعتمد على الثقة تمامًا (مثل PIR لخادم واحد) مكلفة. إن التكاليف الحالية مرتفعة بشكل غير واقعي ومن المرجح أن تظل مرتفعة حتى بعد تحسين الكفاءة بشكل متكرر.
--مشاكل خصوصية البيانات الوصفية. ستكشف البيانات الوصفية مثل وقت الطلب ونمط الطلب لعنوان IP نفسه عن الكثير من معلومات المستخدم.
--ثغرة الرقابة: سيواجه هيكل السوق الذي يهيمن عليه عدد صغير من مزودي RPC ضغوطًا قوية لحظر المستخدمين أو فرض الرقابة. لقد بدأ العديد من موفري RPC بحظر بعض البلدان بالكامل.
لذلك، لا يزال من المهم الاستمرار في ضمان راحة تشغيل العقدة الشخصية.
2. الأولويات قصيرة المدى
إعطاء الأولوية للنشر الكامل لـ EIP-4444، وفي النهاية تحقيق أن كل عقدة تخزن حوالي 36 يومًا فقط من البيانات. سيؤدي هذا إلى تقليل متطلبات مساحة القرص الصلب بشكل كبير - وهي الحاجز الأول الذي يمنع الأشخاص حاليًا من تشغيل العقدة. بعد ذلك، ستتضمن متطلبات تخزين العقدة فقط: (أ) بيانات الحالة، (ب) فرع Merkle الخاص بالحالة، و(ج) 36 يومًا من البيانات التاريخية.
إنشاء حل تخزين تاريخي موزع بحيث يخزن كل عقدة كمية صغيرة من البيانات التاريخية المتأخرة. تعزيز الموثوقية من خلال تقنية الترميز المسحي. ويضمن هذا ميزة "الحفاظ الدائم على blockchain" دون الاعتماد على الموردين المركزيين أو وضع عبء ثقيل على مشغلي العقد.
تعديل استراتيجية تسعير الغاز، وزيادة تكاليف التخزين، وخفض تكاليف التنفيذ. ركز على زيادة تكلفة الغاز للعمليات التالية: (i) تنفيذ SSTORE لفتحة تخزين جديدة، (ii) إنشاء رمز العقد، و(iii) نقل ETH إلى حساب رصيد صفر/nonce صفر.
3. الهدف المتوسط المدى: التحقق من عدم وجود حالة
بعد تنفيذ التحقق من عدم وجود حالة، لن تحتاج العقد قيد التشغيل التي تدعم RPC (أي العقد التي تخزن الحالة) إلى حفظ فرع ميركل للحالة. يمكن أن يؤدي هذا إلى تقليل متطلبات التخزين بنحو 50% أخرى. 4. نوع جديد من العقد: عقدة عديمة الجنسية جزئيًا
سيكون هذا المفهوم المبتكر هو المفتاح لإبقاء العقد الشخصية قيد التشغيل بعد زيادة حد الغاز L1 بمقدار 10-100 مرة. لقد أضفنا نوع عقدة جديد: التحقق من الكتل بطريقة بدون جنسية، والتحقق من السلسلة بأكملها من خلال التحقق بدون جنسية أو ZK-EVM، ولكن الحفاظ فقط على جزء من بيانات الحالة. طالما أن البيانات المطلوبة بواسطة طلب RPC موجودة ضمن هذه المجموعة الفرعية من الحالة، فستكون العقدة قادرة على الاستجابة؛ ستفشل الطلبات الأخرى (أو ستحتاج إلى الرجوع إلى حل تشفير مستضاف خارجيًا - ويمكن للمستخدم تحديد ما إذا كان يجب الرجوع أم لا).

تعتمد الحالات التي يتم صيانتها على وجه التحديد على تكوين المستخدم، على سبيل المثال:
-- استبعاد جميع الحالات باستثناء العقود غير المرغوب فيها المعروفة.
--الحالة المتعلقة بجميع حسابات EOA وSCW ورموز ERC20/ERC721 والتطبيقات المستخدمة بشكل شائع.
--حالة حساب EOA/SCW النشط في العامين الماضيين + حالة بعض رموز ERC20 المستخدمة بشكل شائع + حالة تطبيقات المبادلة/DeFi/الخصوصية المحددة. يمكن إدارة التكوين من خلال العقود على السلسلة: يستخدم المستخدمون المعلمة "--save_state_by_config 0x12345...67890" عند تشغيل عقدة. سيحدد هذا العنوان قائمة العناوين أو فتحة التخزين أو قواعد تصفية الحالة التي تحتاج العقدة إلى حفظها وتحديثها في الوقت الفعلي بلغة معينة. لاحظ أن المستخدمين لا يحتاجون إلى حفظ فرع Merkle، بل القيمة الأصلية فقط. توفر هذه العقد ميزة الوصول المباشر المحلي إلى الحالات الحرجة مع ضمان خصوصية الوصول الكاملة. ص>