ترجمة | صحيفة أودايلي كوكب اليومية ( @OdailyChina )
المترجم | إيثان（@ethanzhang_web3）
بالإضافة إلى القلق بشأن أمان الشبكة، فإن النقد الأكثر شيوعًا لزيادة حد غاز L1 هو أنه سيزيد من صعوبة تشغيل العقد الكاملة. خاصة في سياق خارطة الطريق التي تركز على تقسيم العقد الكاملة، يجب أن نفهم دور العقد الكاملة لمعالجة هذه المشكلة.
من الناحية التاريخية، كان يُعتقد دائمًا أن العقد الكاملة تُستخدم للتحقق من بيانات السلسلة؛ يرجى الرجوع إلى هنا لمعرفة توضيحي حول ما يمكن أن يحدث إذا لم يتمكن المستخدمون العاديون من التحقق. إذا كانت هذه هي المشكلة الوحيدة، فإن ZK-EVM يمكن أن يفتح توسيع L1: الحد الوحيد هو الحفاظ على تكلفة بناء الكتل وإثباتها عند مستوى منخفض بما يكفي بحيث يمكن أن يحتفظ كلاهما بمقاومة الرقابة من نوع 1-of-n والتنافس في السوق.
لكن في الواقع، هذه ليست المشكلة الوحيدة. مشكلة رئيسية أخرى هي أن امتلاك عقدة كاملة أمر ذو قيمة كبيرة، حيث يمكنك الحصول على خادم RPC محلي، لقراءة السلسلة بطريقة غير موثوقة، مقاومة للرقابة وودية للخصوصية. ستناقش هذه الوثيقة التعديلات التي أجريت على خارطة الطريق الحالية للتوسع من المستوى 1 لتحقيق هذا الهدف.
لماذا يجب الاستمرار في تحقيق الثقة والخصوصية من خلال ZK-EVM + PIR؟
في خارطة الطريق للخصوصية التي نشرتها في الشهر الماضي، قمت بتحديد TEE + ORAM كحل مؤقت، بالإضافة إلى PIR كحل طويل الأمد. بهذه الطريقة، ومع Helios و ZK-EVM للتحقق، يمكن لأي مستخدم الاتصال بـ RPC خارجي، والتأكد تمامًا من: (i) أن السلسلة التي يحصلون عليها صحيحة؛ (ii) أن خصوصية بياناتهم محمية. لذلك، لا يسعنا إلا أن نتساءل: لماذا لا نتوقف عند هذا الحد؟ ألا ستجعل هذه الحلول التشفيرية المتقدمة العقد الذاتية الاستضافة شيئًا من الماضي؟
فيما يلي يمكنني تقديم عدة ردود:
الحلول المشفرة التي لا تتطلب الثقة على الإطلاق (أي 1-server PIR) ستكون باهظة الثمن جداً. النفقات الحالية مرتفعة لدرجة أنها غير عملية، وحتى مع تحسينات الكفاءة المتعددة، من المحتمل أن تبقى باهظة.
خصوصية البيانات الوصفية. أي عنوان IP أرسل الطلب في أي وقت، وكذلك نمط الطلب، هذه البيانات في حد ذاتها كافية لكشف الكثير من المعلومات عن المستخدم.
مراجعة الثغرات: سيواجه الهيكل السوقي الذي تهيمن عليه عدد قليل من مزودي RPC ضغوطًا قوية لإلغاء المنصة أو مراجعة المستخدمين. لقد استبعد العديد من مزودي RPC دولًا بأكملها.
لأسباب عديدة، من المفيد الاستمرار في ضمان تشغيل العقد الشخصية بشكل أكثر سهولة.
أولويات قصيرة المدى
زيادة أولوية الترويج الشامل لـ EIP-4444 حتى يتم تخزين البيانات النهائية لكل عقدة لمدة حوالي 36 يومًا فقط. سيؤدي ذلك إلى تقليل احتياجات مساحة القرص بشكل كبير، حيث تعتبر احتياجات مساحة القرص هي المشكلة الرئيسية التي تعيق المزيد من الأشخاص عن تشغيل العقد. بعد ذلك، ستكون احتياجات مساحة القرص للعقد كما يلي: (i) حجم الحالة؛ (ii) فرع Merkle للحالة؛ (iii) سجل تاريخي لمدة 36 يومًا.
بناء حلول تخزين تاريخية موزعة، حيث يمكن لكل عقدة تخزين جزء صغير من البيانات التاريخية التي هي أقدم من تاريخ الاستحقاق. استخدام الترميز التصحيحي لتعظيم المتانة. يمكن أن يضمن ذلك خاصية "البلوكشين هو أبدي" دون الحاجة للاعتماد على مزودي خدمات مركزيين أو تحميل مشغلي العقد عبئاً ثقيلاً.
تعديل تسعير الغاز لزيادة تكلفة التخزين وتقليل تكلفة التنفيذ. الأولوية الخاصة هي زيادة تكلفة الغاز لإنشاء حالة جديدة: (i) SSTORE لبئر التخزين الجديد، (ii) إنشاء كود العقد، (iii) إرسال ETH إلى حسابات ليس لديها رصيد أو nonce.
أولويات المرحلة المتوسطة: التحقق غير الحاوي
بمجرد تفعيلنا للتحقق غير ذي الحالة، يصبح من الممكن تشغيل عقدة ذات وظائف RPC (أي عقدة تخزن الحالة) دون الحاجة لتخزين فرع ميركل للحالة. سيؤدي ذلك إلى تقليل متطلبات التخزين بمقدار حوالي الضعف.
نوع جديد من العقد: عقد بدون حالة جزئية
هذه فكرة جديدة، وهي أيضًا المفتاح للسماح بتشغيل العقد الفردية في ظل زيادة قيود الغاز L1 من 10 إلى 100 مرة.
لقد أضفنا نوعًا جديدًا من العقد يمكنه التحقق من الكتل بدون حالة، والتحقق من السلسلة بالكامل (من خلال التحقق بدون حالة أو ZK-EVM)، والحفاظ على حالة الجزء الأحدث. طالما أن البيانات المطلوبة ضمن مجموعة الحالة هذه، يمكن للعقدة الاستجابة لطلبات RPC؛ ستفشل الطلبات الأخرى (أو يجب أن تعود إلى حل تشفير مستضاف خارجي؛ ينبغي أن يختار المستخدم ما إذا كان سيفعل ذلك).
يعتمد الجزء المحدد من الحالة التي يجب الحفاظ عليها على التكوين الذي يختاره المستخدم. أمثلة أدناه
جميع الحالات ما عدا المعروفة كعقود القمامة
الحالة المرتبطة بجميع EOA و SCW وجميع الرموز والتطبيقات الشائعة ERC 20 و ERC 721
حالة تتعلق بجميع EOA و SCW التي تم زيارتها في العامين الماضيين وبعض رموز ERC 20 الشائعة، بالإضافة إلى مجموعة محدودة من تطبيقات التبادل وdefi والخصوصية
يمكن إدارة الإعدادات من خلال العقود الذكية: يمكن للمستخدمين تشغيل عقدهم باستخدام --save_state_by_config 0x 12345...67890، حيث سيتم تحديد العنوان الذي سيحفظ ويحتفظ بحالة العقد المحدثة بلغة معينة، بالإضافة إلى قائمة مناطق التخزين أو الفلاتر الأخرى. يرجى ملاحظة أن المستخدمين ليسوا بحاجة إلى حفظ فروع Merkle؛ ما عليهم سوى حفظ القيم الأصلية.
يمكن أن تتيح هذه النوعية من العقد للمستخدمين الوصول مباشرة إلى الحالة التي يحتاجون إلى مراقبتها محليًا، مع أقصى حماية لخصوصية الوصول إلى تلك الحالة.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
فيتاليك: حل جديد لمشكلة قابلية التوسع في إثيريوم L1
هذه المقالة من: المؤسس المشارك لإثيريوم فيتالك
ترجمة | صحيفة أودايلي كوكب اليومية ( @OdailyChina )
المترجم | إيثان（@ethanzhang_web3）
بالإضافة إلى القلق بشأن أمان الشبكة، فإن النقد الأكثر شيوعًا لزيادة حد غاز L1 هو أنه سيزيد من صعوبة تشغيل العقد الكاملة. خاصة في سياق خارطة الطريق التي تركز على تقسيم العقد الكاملة، يجب أن نفهم دور العقد الكاملة لمعالجة هذه المشكلة.
من الناحية التاريخية، كان يُعتقد دائمًا أن العقد الكاملة تُستخدم للتحقق من بيانات السلسلة؛ يرجى الرجوع إلى هنا لمعرفة توضيحي حول ما يمكن أن يحدث إذا لم يتمكن المستخدمون العاديون من التحقق. إذا كانت هذه هي المشكلة الوحيدة، فإن ZK-EVM يمكن أن يفتح توسيع L1: الحد الوحيد هو الحفاظ على تكلفة بناء الكتل وإثباتها عند مستوى منخفض بما يكفي بحيث يمكن أن يحتفظ كلاهما بمقاومة الرقابة من نوع 1-of-n والتنافس في السوق.
لكن في الواقع، هذه ليست المشكلة الوحيدة. مشكلة رئيسية أخرى هي أن امتلاك عقدة كاملة أمر ذو قيمة كبيرة، حيث يمكنك الحصول على خادم RPC محلي، لقراءة السلسلة بطريقة غير موثوقة، مقاومة للرقابة وودية للخصوصية. ستناقش هذه الوثيقة التعديلات التي أجريت على خارطة الطريق الحالية للتوسع من المستوى 1 لتحقيق هذا الهدف.
لماذا يجب الاستمرار في تحقيق الثقة والخصوصية من خلال ZK-EVM + PIR؟
في خارطة الطريق للخصوصية التي نشرتها في الشهر الماضي، قمت بتحديد TEE + ORAM كحل مؤقت، بالإضافة إلى PIR كحل طويل الأمد. بهذه الطريقة، ومع Helios و ZK-EVM للتحقق، يمكن لأي مستخدم الاتصال بـ RPC خارجي، والتأكد تمامًا من: (i) أن السلسلة التي يحصلون عليها صحيحة؛ (ii) أن خصوصية بياناتهم محمية. لذلك، لا يسعنا إلا أن نتساءل: لماذا لا نتوقف عند هذا الحد؟ ألا ستجعل هذه الحلول التشفيرية المتقدمة العقد الذاتية الاستضافة شيئًا من الماضي؟
فيما يلي يمكنني تقديم عدة ردود:
لأسباب عديدة، من المفيد الاستمرار في ضمان تشغيل العقد الشخصية بشكل أكثر سهولة.
أولويات قصيرة المدى
أولويات المرحلة المتوسطة: التحقق غير الحاوي
بمجرد تفعيلنا للتحقق غير ذي الحالة، يصبح من الممكن تشغيل عقدة ذات وظائف RPC (أي عقدة تخزن الحالة) دون الحاجة لتخزين فرع ميركل للحالة. سيؤدي ذلك إلى تقليل متطلبات التخزين بمقدار حوالي الضعف.
نوع جديد من العقد: عقد بدون حالة جزئية
هذه فكرة جديدة، وهي أيضًا المفتاح للسماح بتشغيل العقد الفردية في ظل زيادة قيود الغاز L1 من 10 إلى 100 مرة.
لقد أضفنا نوعًا جديدًا من العقد يمكنه التحقق من الكتل بدون حالة، والتحقق من السلسلة بالكامل (من خلال التحقق بدون حالة أو ZK-EVM)، والحفاظ على حالة الجزء الأحدث. طالما أن البيانات المطلوبة ضمن مجموعة الحالة هذه، يمكن للعقدة الاستجابة لطلبات RPC؛ ستفشل الطلبات الأخرى (أو يجب أن تعود إلى حل تشفير مستضاف خارجي؛ ينبغي أن يختار المستخدم ما إذا كان سيفعل ذلك).
يعتمد الجزء المحدد من الحالة التي يجب الحفاظ عليها على التكوين الذي يختاره المستخدم. أمثلة أدناه
يمكن إدارة الإعدادات من خلال العقود الذكية: يمكن للمستخدمين تشغيل عقدهم باستخدام --save_state_by_config 0x 12345...67890، حيث سيتم تحديد العنوان الذي سيحفظ ويحتفظ بحالة العقد المحدثة بلغة معينة، بالإضافة إلى قائمة مناطق التخزين أو الفلاتر الأخرى. يرجى ملاحظة أن المستخدمين ليسوا بحاجة إلى حفظ فروع Merkle؛ ما عليهم سوى حفظ القيم الأصلية.
يمكن أن تتيح هذه النوعية من العقد للمستخدمين الوصول مباشرة إلى الحالة التي يحتاجون إلى مراقبتها محليًا، مع أقصى حماية لخصوصية الوصول إلى تلك الحالة.