شكر خاص لـ Micah Zoltu و Toni Wahrstätter و Justin Traglia و pcaversaccio على المناقشة

أكثر الانتقادات شيوعا لزيادة حد الغاز L1، بالإضافة إلى القلق بشأن سلامة الشبكة، هو أنه يجعل من الأصعب تشغيل العقدة الكاملة.

خصوصا في سياق خريطة طريق تركز علىتقسيم الحزمةالعقد الكامل، ومعالجة هذا يتطلب فهم ما هي العقد الكاملة عليها.

تاريخياً، كان التفكير أن العقد الكاملة هي للتحقق من السلسلة؛ انظرهنالتفسيري الخاص لما يمكن أن يحدث إذا لم يتمكن المستخدمون العاديون من التحقق. إذا كانت هذه هي المشكلة الوحيدة، فإن توسيع L1 مفتوح عن طريق ZK-EVMs: الحد الوحيد هو الاحتفاظ بتكلفة بناء الكتلة وإثباتها منخفضة بما فيه الكفاية بحيث يمكن لكلاهما البقاء1 من nمقاوم للرقابة وسوق تنافسي.

ومع ذلك، في الواقع هذا ليس القلق الوحيد. القلق الآخر الرئيسي هو: أنه من المهم أن يكون لديك عقدة كاملة حتى تتمكن من الحصول على خادم RPC محلي يمكنك استخدامه لقراءة السلسلة بطريقة غير قابلة للثقة ومقاومة للرقابة وودية للخصوصية. ستناقش هذه الوثيقة التعديلات على خريطة الطريق الحالية للتوسيع L1 التي تجعل ذلك يحدث.

لماذا لا تتوقف عند عدم الثقة والخصوصية عبر ZK-EVM + PIR؟

الخارطة الطريق الخاصة التي نشرتها الشهر الماضييركز على TEEs + ORAMكحلاحقة قصيرة الأجل بالإضافة إلىPIRكحلول على المدى الطويل. سيسمح ذلك، جنبا إلى جنب مع التحقق من هيليوس و ZK-EVM، لأي مستخدم بالاتصال بـ RPCs الخارجية وأن يكون على ثقة تامة بأن (i) السلسلة التي يحصلون عليها صحيحة، و (ii) خصوصيتهم محمية. لذلك يستحق السؤال: لماذا لا نتوقف هنا؟ أليست هذه الحلول المتقدمة في التشفير تجعل العقد القديمة التي تستضيفها الذاتية تحفة قديمة؟

هنا يمكنني تقديم بعض الردود:

• سوف تكون الحلول التشفيرية ذات الثقة الكاملة (أي PIR بخادم واحد) مكلفة. حاليًا ، العبء مرتفع بشكل غير عملي ، وحتى بعد العديد من تحسينات الكفاءة ، من المحتمل أن تظل مكلفة.
• الخصوصية الفنية. البيانات التي تظهر عنوان IP الذي يقدم الطلبات في أي وقت، ونمط الطلبات، هي بمفردها كافية لكشف الكثير من المعلومات حول المستخدمين.
• ثغرة الرقابة: هيكل السوق الذي يهيمن عليه عدد قليل من موفري خدمة RPC هو الذي سيواجه ضغوطًا قوية لحجب أو رقابة المستخدمين. فعدد كبير من موفري خدمة RPC يستبعدون بالفعل دولاً بأكملها.

لهذه الأسباب، هناك قيمة في مواصلة ضمان سهولة أكبر في تشغيل العقدة الشخصية.

الأولويات على المدى القصير

• ترتيب أولوية كامل لتطبيق EIP-4444، حتى النهاية النهائية حيث يخزن كل عقد بيانات لمدة 36 يومًا فقط. يقلل هذا بشكل كبير من متطلبات مساحة القرص، التي تعد المشكلة الرئيسية التي تمنع المزيد من الأشخاص من تشغيل العقد. بعد ذلك، ستكون متطلبات مساحة القرص للعقد (i) حجم الحالة، (ii) فروع Merkle الحالة، (iii) 36 يومًا من التاريخ.
• بناء حلاً لتخزين التاريخ الموزع، حيث يمكن لكل عقد تخزين نسبة صغيرة من البيانات التاريخية الأقدم من الحد الزمني. استخدام الترميز المحوي لتعظيم الصلابة. هذا يضمن خاصية "البلوكشين مستمر إلى الأبد" دون الاعتماد على موفري الخدمات المركزية أو وضع أعباء ثقيلة على مشغلي العقد
• ضبط تسعير الغاز لجعل التخزين أكثر تكلفة والتنفيذ أقل تكلفة. أحد أولويات عالية بشكل خاص هو زيادة تكلفة الغاز لإنشاء حالة جديدة: (i) SSTORE لفتحات التخزين الجديدة، (ii) إنشاء رمز العقد، (iii) إرسال ETH إلى الحسابات التي لا تمتلك رصيدًا أو nonce بعد.

الأولوية في المدى المتوسط: التحقق بدون دولة

بمجرد تمكين التحقق من الحالة اللاحدية ، يصبح من الممكن تشغيل عقد RPC قادر على (أي يخزن الحالة) دون تخزين فروع Merkle الحالة. يزيد ذلك بشكل أكبر من متطلبات التخزين بمقدار ~ 2 مرة.

نوع جديد من العقد: العقد جزئي الحالة

هذه هي الفكرة الجديدة، وستكون مفتاحًا للسماح بتشغيل العقد الشخصية حتى في سياق يتزايد فيه حد الغاز L1 بمقدار 10-100 مرة.

نحن نضيف نوع العقد الذي يتحقق من حالة الكتل بشكل لا حالي، ويتحقق من السلسلة بأكملها (سواء من خلال التحقق اللا حالي أو ZK-EVM) ويحافظ على جزء من الحالة يكون محدثًا. يمكن للعقد الاستجابة لطلبات RPC طالما أن البيانات المطلوبة داخل تلك الجزء من الحالة؛ ستفشل الطلبات الأخرى (أو يجب أن تعود إلى حل مشفر مستضاف خارجيًا؛ سواء كان عليها القيام بذلك يعتمد على اختيار المستخدم).

partial_statelessness.drawio776×341 19.9 كيلوبايت

الجزء الدقيق من الحالة الذي سيتم الاحتفاظ به سيعتمد على التكوين الذي اختاره المستخدم. قد تكون بعض الأمثلة هي:

• جميع الدول باستثناء العقود المعروفة بأنها رسائل غير مرغوب فيها
• الحالة المرتبطة بجميع الEOAs و SCWs وجميع الرموز المميزة ERC20 و ERC721 المستخدمة بشكل شائع والتطبيقات
• الحالة المرتبطة بجميع EOAs و SCWs التي تم الوصول إليها خلال السنتين الماضيتين، بالإضافة إلى بعض الرموز المميزة المستخدمة عادةً من ERC20، بالإضافة إلى مجموعة محدودة من تطبيقات الصرف والتمويل اللامركزي والخصوصية

يمكن إدارة التكوين عن طريق عقد على السلسلة: سيقوم المستخدم بتشغيل عقدهم مع —save_state_by_config 0x12345…67890، وسيحدد العنوان بلغة ما قائمة بالعناوين أو فتحات التخزين أو مناطق مرشحة بطريقة ما من الحالة التي سيقوم العقد بحفظها والإبقاء عليها حتى تاريخ محدد. لاحظ أنه لا حاجة للمستخدم لحفظ فروع Merkle؛ فهم بحاجة فقط لحفظ القيم النقية.

هذا النوع من العقدة سيوفر فوائد الوصول المحلي المباشر إلى الحالة التي يحتاجها المستخدم للعناية بها، وكذلك الخصوصية الكاملة القصوى للوصول إلى تلك الحالة.

تنصل:

1. تم نقل هذه المقالة منethresear]. جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [فيتالي بوتيرينإذا كانت هناك اعتراضات على هذا النشر، يرجى الاتصال بالبوابة تعلمالفريق، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم الترجمات للمقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، يُمنع نسخ أو توزيع أو سرقة المقالات المترجمة.