المؤلف: فيتاليك، مؤسس إثيريوم؛ الترجمة: 金色财经xiaozhou
أكثر الانتقادات شيوعًا لزيادة الحد الأقصى لغاز L1، بالإضافة إلى مخاوف الأمان الشبكي، هو أن ذلك سيجعل تشغيل العقد الكاملة أكثر صعوبة. خاصة في سياق خريطة الطريق التي تركز على "فك ارتباط العقد الكاملة"، لحل هذه المشكلة يجب أولاً فهم معنى وجود العقد الكاملة.
تعتقد وجهة النظر التقليدية أن العقد الكامل تُستخدم للتحقق من بيانات السلسلة. إذا كانت هذه هي المشكلة الوحيدة، فإن ZK-EVM يمكن أن يفتح سعة L1: القيد الوحيد هو الحفاظ على تكلفة بناء الكتل وإثباتها منخفضة بما يكفي، بحيث يمكن لكليهما الحفاظ على مقاومة الرقابة من نوع 1 من n، وأيضًا تشكيل سوق تنافسية.
لكن في الواقع، هذه ليست الاعتبارات الوحيدة. عامل مهم آخر هو: تشغيل عقدة كاملة يسمح لك بامتلاك خادم RPC محلي، مما يتيح لك قراءة بيانات السلسلة بطريقة لا تحتاج إلى ثقة، ومقاومة للرقابة وتحمي الخصوصية. ستناقش هذه المقالة كيفية تعديل خريطة الطريق الحالية للتوسع L1 لتحقيق هذا الهدف.
1، لماذا لا نكون راضين عن اللامركزية والخصوصية التي تحققها ZK-EVM + PIR؟
خطة الخصوصية التي نشرتها الشهر الماضي تدعو إلى: اعتماد حلول TEE + ORAM على المدى القصير، والانتقال إلى تقنية PIR على المدى الطويل. من خلال دمج Helios والتحقق من ZK-EVM، يمكن للمستخدمين أن يكونوا واثقين تمامًا عند الاتصال بـ RPC خارجي: أن بيانات السلسلة المستخرجة صحيحة، وأن خصوصية البيانات محمية. وهذا يطرح سؤالاً: لماذا لا نتوقف عند هذا الحد؟ هل تجعل هذه الحلول التشفيرية المتقدمة عقد الإدارة الذاتية شيئًا عتيقًا؟
لدي بعض الردود على ذلك:
--التكاليف العالية للحلول التشفيرية التي لا تتطلب الثقة (مثل PIR أحادي الخادم). التكاليف الحالية مرتفعة للغاية وغير عملية، حتى مع العديد من تحسينات الكفاءة، قد تظل الأسعار مرتفعة.
--قضايا خصوصية البيانات الوصفية. ستكشف بيانات وصفية مثل وقت طلب عنوان IP ونمط الطلب عن كمية كبيرة من معلومات المستخدم.
--**مراجعة الضعف: ** ستواجه هيكل السوق الذي تهيمن عليه عدد قليل من مزودي RPC ضغطًا قويًا من حظر المستخدمين أو المراجعة. لقد بدأ العديد من مزودي RPC في حجب بعض الدول تمامًا.
لذلك، لا يزال من المجدي ضمان سهولة تشغيل العقد الشخصية.
( 2، الأولويات القصيرة الأجل
الأولوية لنشر EIP-4444 بشكل شامل، لتحقيق تخزين حوالي 36 يوم من البيانات لكل عقدة. سيساعد هذا بشكل كبير في تقليل متطلبات مساحة القرص - وهو الحاجز الرئيسي الذي يعيق الناس عن تشغيل العقد. بعد ذلك، ستتضمن متطلبات تخزين العقد ما يلي: )i( بيانات الحالة، )ii### فرع ميركل لحالة البيانات، (iii) بيانات تاريخية لمدة 36 يوم.
بناء حل تخزين تاريخي موزع، بحيث يقوم كل عقدة بتخزين كمية صغيرة من البيانات التاريخية المنتهية. من خلال تقنية تشفير البيانات، يتم تعظيم الموثوقية. هذا يضمن خصائص "حفظ البيانات على البلوكشين بشكل دائم" دون الاعتماد على مزودين مركزيين أو تحميل مشغلي العقد عبءًا ثقيلًا.
تعديل استراتيجية تسعير الغاز، وزيادة تكلفة التخزين، وتقليل تكلفة التنفيذ. التركيز على زيادة تكلفة الغاز للعمليات التالية: (i) تنفيذ SSTORE لفتحة التخزين الجديدة (storage slot)، (ii) إنشاء كود العقد، (iii) تحويل ETH إلى حساب برصيد صفر/nonce صفر.
( 3، الهدف المتوسط: التحقق بدون حالة
بعد تحقيق التحقق بدون حالة، لن تحتاج العقد التي تدعم RPC (أي العقد التي تخزن الحالة) إلى حفظ فرع ميركل للحالة. وهذا يمكن أن يقلل من متطلبات التخزين بحوالي 50٪.
4، عقد جديدة: بعض العقد بدون حالة
ستكون هذه الفكرة الابتكارية هي المفتاح للحفاظ على تشغيل العقد الفردية بعد زيادة الحد الأقصى للغاز L1 من 10 إلى 100 مرة.
لقد أضفنا نوعا جديدا من العقدة: التحقق من صحة الكتل بطريقة عديمة الحالة، والتحقق من السلسلة بأكملها عبر التحقق عديم الحالة أو ZK-EVM، مع الاحتفاظ بجزء فقط من بيانات الحالة. طالما أن البيانات المطلوبة لطلب RPC موجودة في تلك المجموعة الفرعية من الحالة ، يمكن للعقدة الاستجابة. ستفشل الطلبات الأخرى (أو ستحتاج إلى العودة إلى حل تشفير مستضاف خارجيا - يجب أن يختار المستخدم الاحتياطي).
--حالة حسابات EOA/SCW النشطة في العامين الماضيين + حالة بعض رموز ERC20 الشائعة + حالات مختارة من تطبيقات swap/DeFi/الخصوصية.
يمكن إدارة التكوين من خلال عقود على السلسلة: عندما يقوم المستخدم بتشغيل العقدة، يستخدم معلمة “--save_state_by_config 0x12345...67890”، حيث سيتم تعريف قائمة العناوين التي يجب أن تحفظها العقدة وتحدثها في الوقت الحقيقي، وكذلك خانات التخزين (storage slot) أو قواعد تصفية الحالة بلغة معينة. يجب ملاحظة أن المستخدم ليس مطالبًا بحفظ فرع ميركل، بل يكفي حفظ القيم الأصلية.
تقدم هذه الأنواع من العقد مزايا الوصول المباشر المحلي إلى الحالة الرئيسية، بالإضافة إلى ضمان الخصوصية الكاملة للوصول.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
فيتالك: خطة تحسين تركز على توسيع العقدة المحلية
المؤلف: فيتاليك، مؤسس إثيريوم؛ الترجمة: 金色财经xiaozhou
أكثر الانتقادات شيوعًا لزيادة الحد الأقصى لغاز L1، بالإضافة إلى مخاوف الأمان الشبكي، هو أن ذلك سيجعل تشغيل العقد الكاملة أكثر صعوبة. خاصة في سياق خريطة الطريق التي تركز على "فك ارتباط العقد الكاملة"، لحل هذه المشكلة يجب أولاً فهم معنى وجود العقد الكاملة.
تعتقد وجهة النظر التقليدية أن العقد الكامل تُستخدم للتحقق من بيانات السلسلة. إذا كانت هذه هي المشكلة الوحيدة، فإن ZK-EVM يمكن أن يفتح سعة L1: القيد الوحيد هو الحفاظ على تكلفة بناء الكتل وإثباتها منخفضة بما يكفي، بحيث يمكن لكليهما الحفاظ على مقاومة الرقابة من نوع 1 من n، وأيضًا تشكيل سوق تنافسية.
لكن في الواقع، هذه ليست الاعتبارات الوحيدة. عامل مهم آخر هو: تشغيل عقدة كاملة يسمح لك بامتلاك خادم RPC محلي، مما يتيح لك قراءة بيانات السلسلة بطريقة لا تحتاج إلى ثقة، ومقاومة للرقابة وتحمي الخصوصية. ستناقش هذه المقالة كيفية تعديل خريطة الطريق الحالية للتوسع L1 لتحقيق هذا الهدف.
1، لماذا لا نكون راضين عن اللامركزية والخصوصية التي تحققها ZK-EVM + PIR؟
خطة الخصوصية التي نشرتها الشهر الماضي تدعو إلى: اعتماد حلول TEE + ORAM على المدى القصير، والانتقال إلى تقنية PIR على المدى الطويل. من خلال دمج Helios والتحقق من ZK-EVM، يمكن للمستخدمين أن يكونوا واثقين تمامًا عند الاتصال بـ RPC خارجي: أن بيانات السلسلة المستخرجة صحيحة، وأن خصوصية البيانات محمية. وهذا يطرح سؤالاً: لماذا لا نتوقف عند هذا الحد؟ هل تجعل هذه الحلول التشفيرية المتقدمة عقد الإدارة الذاتية شيئًا عتيقًا؟
لدي بعض الردود على ذلك:
--التكاليف العالية للحلول التشفيرية التي لا تتطلب الثقة (مثل PIR أحادي الخادم). التكاليف الحالية مرتفعة للغاية وغير عملية، حتى مع العديد من تحسينات الكفاءة، قد تظل الأسعار مرتفعة.
--قضايا خصوصية البيانات الوصفية. ستكشف بيانات وصفية مثل وقت طلب عنوان IP ونمط الطلب عن كمية كبيرة من معلومات المستخدم.
--**مراجعة الضعف: ** ستواجه هيكل السوق الذي تهيمن عليه عدد قليل من مزودي RPC ضغطًا قويًا من حظر المستخدمين أو المراجعة. لقد بدأ العديد من مزودي RPC في حجب بعض الدول تمامًا.
لذلك، لا يزال من المجدي ضمان سهولة تشغيل العقد الشخصية.
( 2، الأولويات القصيرة الأجل
الأولوية لنشر EIP-4444 بشكل شامل، لتحقيق تخزين حوالي 36 يوم من البيانات لكل عقدة. سيساعد هذا بشكل كبير في تقليل متطلبات مساحة القرص - وهو الحاجز الرئيسي الذي يعيق الناس عن تشغيل العقد. بعد ذلك، ستتضمن متطلبات تخزين العقد ما يلي: )i( بيانات الحالة، )ii### فرع ميركل لحالة البيانات، (iii) بيانات تاريخية لمدة 36 يوم.
بناء حل تخزين تاريخي موزع، بحيث يقوم كل عقدة بتخزين كمية صغيرة من البيانات التاريخية المنتهية. من خلال تقنية تشفير البيانات، يتم تعظيم الموثوقية. هذا يضمن خصائص "حفظ البيانات على البلوكشين بشكل دائم" دون الاعتماد على مزودين مركزيين أو تحميل مشغلي العقد عبءًا ثقيلًا.
تعديل استراتيجية تسعير الغاز، وزيادة تكلفة التخزين، وتقليل تكلفة التنفيذ. التركيز على زيادة تكلفة الغاز للعمليات التالية: (i) تنفيذ SSTORE لفتحة التخزين الجديدة (storage slot)، (ii) إنشاء كود العقد، (iii) تحويل ETH إلى حساب برصيد صفر/nonce صفر.
( 3، الهدف المتوسط: التحقق بدون حالة
بعد تحقيق التحقق بدون حالة، لن تحتاج العقد التي تدعم RPC (أي العقد التي تخزن الحالة) إلى حفظ فرع ميركل للحالة. وهذا يمكن أن يقلل من متطلبات التخزين بحوالي 50٪.
4، عقد جديدة: بعض العقد بدون حالة
ستكون هذه الفكرة الابتكارية هي المفتاح للحفاظ على تشغيل العقد الفردية بعد زيادة الحد الأقصى للغاز L1 من 10 إلى 100 مرة.
لقد أضفنا نوعا جديدا من العقدة: التحقق من صحة الكتل بطريقة عديمة الحالة، والتحقق من السلسلة بأكملها عبر التحقق عديم الحالة أو ZK-EVM، مع الاحتفاظ بجزء فقط من بيانات الحالة. طالما أن البيانات المطلوبة لطلب RPC موجودة في تلك المجموعة الفرعية من الحالة ، يمكن للعقدة الاستجابة. ستفشل الطلبات الأخرى (أو ستحتاج إلى العودة إلى حل تشفير مستضاف خارجيا - يجب أن يختار المستخدم الاحتياطي).
! [qWmAn09ZE4jt0rEyydlCshCydJI7aVcg5fEeT5qk.png])https://img.gateio.im/social/moments-03f98897bcef682e26eb0c90558d1df9 "7370273"(
يعتمد الحفاظ على الحالات المحددة على إعدادات المستخدم، على سبيل المثال:
--استبعاد جميع الحالات باستثناء العقود المعروفة على أنها غير مرغوب فيها.
--حالة مرتبطة بجميع حسابات EOA و SCW والرموز والتطبيقات الشائعة ERC20 / ERC721.
--حالة حسابات EOA/SCW النشطة في العامين الماضيين + حالة بعض رموز ERC20 الشائعة + حالات مختارة من تطبيقات swap/DeFi/الخصوصية.
يمكن إدارة التكوين من خلال عقود على السلسلة: عندما يقوم المستخدم بتشغيل العقدة، يستخدم معلمة “--save_state_by_config 0x12345...67890”، حيث سيتم تعريف قائمة العناوين التي يجب أن تحفظها العقدة وتحدثها في الوقت الحقيقي، وكذلك خانات التخزين (storage slot) أو قواعد تصفية الحالة بلغة معينة. يجب ملاحظة أن المستخدم ليس مطالبًا بحفظ فرع ميركل، بل يكفي حفظ القيم الأصلية.
تقدم هذه الأنواع من العقد مزايا الوصول المباشر المحلي إلى الحالة الرئيسية، بالإضافة إلى ضمان الخصوصية الكاملة للوصول.