تشغيل عقدة كاملة يمكنك من امتلاك خادم RPC محلي، مما يتيح لك قراءة البيانات داخل السلسلة بطريقة لا تتطلب الثقة، ومقاومة للرقابة وتحمي الخصوصية.
كتبه: فيتاليك، مؤسس إيثيريوم
** المترجم: التمويل الذهبي xiaozhou **
أكثر الانتقادات شيوعًا لزيادة حد غاز 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 يومًا من البيانات لكل عقدة فقط. سيؤدي ذلك إلى تقليل كبير في متطلبات مساحة القرص - وهو العائق الرئيسي الذي يمنع الناس من تشغيل العقد. بعد ذلك، ستشمل متطلبات تخزين العقد فقط: بيانات الحالة (i)، فرع ميركل لحالة (ii)، وبيانات تاريخية لمدة 36 يومًا (iii).
بناء خطة تخزين تاريخي موزعة، بحيث تخزن كل عقدة كمية صغيرة من البيانات التاريخية التي تجاوزت الفترة. من خلال تقنية الترميز المحوّل، يتم تحقيق أقصى موثوقية. بهذه الطريقة، يمكن ضمان خاصية "الاحتفاظ الدائم بسلسلة الكتل" دون الاعتماد على مزودي خدمة مركزيين أو تحميل مشغلي العقدة عبئاً ثقيلاً.
تعديل استراتيجية تسعير الغاز، وزيادة تكاليف التخزين، وتقليل تكاليف التنفيذ. التركيز على زيادة تكاليف الغاز للعمليات التالية: (i) تنفيذ SSTORE لفتحة التخزين الجديدة، (ii) إنشاء رمز العقد، (iii) تحويل ETH إلى حساب ذو رصيد صفر / nonce صفر.
3، الهدف الوسيط: التحقق بدون حالة
بعد تنفيذ التحقق من الحالة بدون حالة، لن يحتاج تشغيل عقدة تدعم RPC (أي العقدة التي تخزن الحالة) إلى حفظ فرع ميركل للحالة. هذا يمكن أن يقلل من متطلبات التخزين بمعدل حوالي 50٪.
4، عقدة جديدة: بعض العقدة غير الحالة
ستصبح هذه الفكرة الابتكارية هي المفتاح للحفاظ على تشغيل العقدة الشخصية بعد زيادة الحد الأقصى للغاز من L1 بنسبة 10-100 مرة.
لقد أضفنا نوعًا جديدًا من العقد: تحقق من الكتل بطريقة بلا حالة، من خلال التحقق بلا حالة أو ZK-EVM للتحقق من السلسلة بأكملها، ولكنها تحتفظ فقط بجزء من بيانات الحالة. طالما أن البيانات المطلوبة من طلب RPC تقع ضمن مجموعة الحالة هذه، يمكن للعقدة الاستجابة؛ ستفشل الطلبات الأخرى (أو تحتاج إلى التراجع إلى حل تشفير مستضاف خارجيًا - يجب أن يختار المستخدم ما إذا كان سيتراجع).
!
يعتمد الحفاظ على الحالات المحددة على إعدادات المستخدم، على سبيل المثال:
استبعاد جميع الحالات باستثناء العقود المشبوهة المعروفة.
الحالة المتعلقة بجميع حسابات EOA، SCW والرموز والتطبيقات الشائعة ERC20/ERC721.
حالة الحسابات النشطة EOA/SCW خلال العامين الماضيين + حالة بعض رموز ERC20 الشائعة + حالة تطبيقات swap/DeFi/الخصوصية المختارة.
يمكن إدارة الإعدادات من خلال العقدة داخل السلسلة: يستخدم المستخدمون عند تشغيل العقدة معلمة «--save_state_by_config 0x12345...67890»، وسيتم تعريف القائمة العناوين التي تحتاج العقدة إلى حفظها وتحديثها في الوقت الفعلي، وفتحات التخزين أو قواعد تصفية الحالة بلغة معينة. لاحظ أن المستخدمين ليسوا مطالبين بحفظ فرع ميركل، فقط يجب حفظ القيم الأصلية.
تتمتع هذه العقدة بميزة الوصول المباشر المحلي إلى الحالة الرئيسية، وفي نفس الوقت تضمن الخصوصية الكاملة للوصول.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
فيتاليك: خطة تحسين خريطة الطريق للتوسع تركز على العقدة المحلية
كتبه: فيتاليك، مؤسس إيثيريوم
** المترجم: التمويل الذهبي xiaozhou **
أكثر الانتقادات شيوعًا لزيادة حد غاز L1، بخلاف مخاوف الأمان الشبكي، هو أن ذلك سيجعل تشغيل العقدة الكاملة أكثر صعوبة. خاصة في سياق خريطة الطريق التي تركز على "فك ارتباط العقدة الكاملة"، من الضروري فهم معنى وجود العقدة الكاملة قبل معالجة هذه القضية.
تعتبر وجهة النظر التقليدية أن العقدة الكاملة تستخدم للتحقق من البيانات داخل السلسلة. إذا كانت هذه هي المشكلة الوحيدة، فإن ZK-EVM يمكن أن تفتح مجال التوسع L1: القيد الوحيد هو الحفاظ على تكلفة بناء الكتل وإثباتها منخفضة بما يكفي، بحيث يمكن أن تحافظ كلاهما على مقاومة الرقابة 1 من n، وتشكيل سوق تنافسية.
لكن في الواقع، ليس هذا هو الاعتبار الوحيد. هناك عامل مهم آخر وهو: تشغيل عقدة كاملة يمكن أن يمنحك خادم RPC محلي، مما يتيح لك قراءة البيانات داخل السلسلة بطريقة لا تحتاج إلى الثقة، ومضادة للرقابة وتحمي الخصوصية. ستناقش هذه المقالة كيفية تعديل خارطة طريق توسيع L1 الحالية لتحقيق هذا الهدف.
1، لماذا لا نكون راضين عن تحقيق عدم الثقة والخصوصية باستخدام ZK-EVM+PIR؟
تدعو خارطة طريق الخصوصية التي أصدرتها الشهر الماضي إلى اعتماد TEEs + ORAM على المدى القصير والتحول إلى تقنية PIR على المدى الطويل. إلى جانب التحقق من صحة Helios و ZK-EVM ، يمكن للمستخدمين الاتصال ب RPCs الخارجية بثقة تامة في أن (i) تحصل على بيانات السلسلة الصحيحة وحماية خصوصية البيانات (ii). هذا يطرح السؤال: لماذا لا تتوقف عند هذا الحد؟ هل تجعل مخططات التشفير المتقدمة هذه العقد المستضافة ذاتيا قديمة؟
لدي بعض الردود على ذلك:
لذلك، لا يزال من المجدي ضمان سهولة تشغيل العقدة الشخصية.
2، أولويات قصيرة الأجل
تُعطى الأولوية للنشر الشامل لـ EIP-4444، لتحقيق تخزين حوالي 36 يومًا من البيانات لكل عقدة فقط. سيؤدي ذلك إلى تقليل كبير في متطلبات مساحة القرص - وهو العائق الرئيسي الذي يمنع الناس من تشغيل العقد. بعد ذلك، ستشمل متطلبات تخزين العقد فقط: بيانات الحالة (i)، فرع ميركل لحالة (ii)، وبيانات تاريخية لمدة 36 يومًا (iii).
بناء خطة تخزين تاريخي موزعة، بحيث تخزن كل عقدة كمية صغيرة من البيانات التاريخية التي تجاوزت الفترة. من خلال تقنية الترميز المحوّل، يتم تحقيق أقصى موثوقية. بهذه الطريقة، يمكن ضمان خاصية "الاحتفاظ الدائم بسلسلة الكتل" دون الاعتماد على مزودي خدمة مركزيين أو تحميل مشغلي العقدة عبئاً ثقيلاً.
تعديل استراتيجية تسعير الغاز، وزيادة تكاليف التخزين، وتقليل تكاليف التنفيذ. التركيز على زيادة تكاليف الغاز للعمليات التالية: (i) تنفيذ SSTORE لفتحة التخزين الجديدة، (ii) إنشاء رمز العقد، (iii) تحويل ETH إلى حساب ذو رصيد صفر / nonce صفر.
3، الهدف الوسيط: التحقق بدون حالة
بعد تنفيذ التحقق من الحالة بدون حالة، لن يحتاج تشغيل عقدة تدعم RPC (أي العقدة التي تخزن الحالة) إلى حفظ فرع ميركل للحالة. هذا يمكن أن يقلل من متطلبات التخزين بمعدل حوالي 50٪.
4، عقدة جديدة: بعض العقدة غير الحالة
ستصبح هذه الفكرة الابتكارية هي المفتاح للحفاظ على تشغيل العقدة الشخصية بعد زيادة الحد الأقصى للغاز من L1 بنسبة 10-100 مرة.
لقد أضفنا نوعًا جديدًا من العقد: تحقق من الكتل بطريقة بلا حالة، من خلال التحقق بلا حالة أو ZK-EVM للتحقق من السلسلة بأكملها، ولكنها تحتفظ فقط بجزء من بيانات الحالة. طالما أن البيانات المطلوبة من طلب RPC تقع ضمن مجموعة الحالة هذه، يمكن للعقدة الاستجابة؛ ستفشل الطلبات الأخرى (أو تحتاج إلى التراجع إلى حل تشفير مستضاف خارجيًا - يجب أن يختار المستخدم ما إذا كان سيتراجع).
!
يعتمد الحفاظ على الحالات المحددة على إعدادات المستخدم، على سبيل المثال:
يمكن إدارة الإعدادات من خلال العقدة داخل السلسلة: يستخدم المستخدمون عند تشغيل العقدة معلمة «--save_state_by_config 0x12345...67890»، وسيتم تعريف القائمة العناوين التي تحتاج العقدة إلى حفظها وتحديثها في الوقت الفعلي، وفتحات التخزين أو قواعد تصفية الحالة بلغة معينة. لاحظ أن المستخدمين ليسوا مطالبين بحفظ فرع ميركل، فقط يجب حفظ القيم الأصلية.
تتمتع هذه العقدة بميزة الوصول المباشر المحلي إلى الحالة الرئيسية، وفي نفس الوقت تضمن الخصوصية الكاملة للوصول.