العنوان الأصلي: العقود المستقبلية المحتملة لبروتوكول Ethereum، الجزء 2: The Surge
المؤلف: فيتاليك، مؤسس Ethereum، المترجم: Deng Tong، Golden Finance
شكر خاص لجوستين دريك، وفرانشيسكو، وهسياو-وي وانغ، وantonttc، وجورجيوس كونستانتوبولوس
في البداية، الأثير هناك استراتيجيتان للتوسع في خريطة طريق فانغ. إحداها هي "التقسيم": بدلاً من التحقق من صحة جميع المعاملات في السلسلة وتخزينها، تحتاج كل عقدة فقط إلى التحقق من صحة وتخزين مجموعة فرعية صغيرة من المعاملات. هذه أيضًا هي الطريقة التي تعمل بها أي شبكة نظير إلى نظير أخرى (مثل BitTorrent)، لذلك يمكننا بالتأكيد جعل blockchains تعمل بنفس الطريقة. الآخر عبارة عن بروتوكول الطبقة الثانية: ستوضع الشبكة فوق Ethereum، مما يسمح لها بالتشغيل الكامل الاستفادة من أمانها مع إبقاء معظم البيانات والحسابات بعيدًا عن السلسلة الرئيسية. تشير "بروتوكولات الطبقة الثانية" إلى القنوات الحكومية في عام 2015، والبلازما في عام 2017، والمجموعات المجمعة في عام 2019. تعتبر المجموعات المجمعة أقوى من القنوات الحكومية أو البلازما، ولكنها تتطلب نطاقًا تردديًا كبيرًا للبيانات على السلسلة. ولحسن الحظ، بحلول عام 2019، نجحت أبحاث التقاسم في حل مشكلة التحقق من صحة "توافر البيانات" على نطاق واسع. ونتيجة لذلك، تم دمج المسارين وحصلنا على خارطة طريق تتمحور حول القيمة المجمعة، والتي لا تزال تمثل استراتيجية التوسع في Ethereum اليوم.
الطفرة، إصدار خارطة الطريق 2023.
تقترح خريطة الطريق المرتكزة على التجميع تقسيمًا بسيطًا للعمل: تركز Ethereum L1 على أن تصبح طبقة أساسية قوية ولامركزية، بينما تتولى L2 مسؤولية مساعدة النظام البيئي على التوسع. وهذا نمط متكرر في جميع أنحاء المجتمع: نظام المحاكم (L1) ليس موجودًا ليكون فائق السرعة والكفاءة، ولكن لحماية العقود وحقوق الملكية، ويحتاج رواد الأعمال (L2) إلى بناء طبقة أساسية صلبة فوقه وأخذ البشرية إلى المريخ (مجازيًا وحرفيًا).
هذا العام، حققت خارطة الطريق المرتكزة على التجميع نجاحات مهمة: زاد عرض النطاق الترددي لبيانات Ethereum L1 بشكل ملحوظ مع EIP-4844 blob، وأصبحت العديد من مجموعات EVM الآن في المرحلة الأولى. أصبحت الآن تطبيقات التجزئة غير المتجانسة والمتنوعة للغاية، حيث يعمل كل L2 بمثابة "جزء" بقواعده الداخلية ومنطقه الخاص، حقيقة واقعة. ولكن كما رأينا، فإن السير في هذا الطريق يأتي مصحوبًا ببعض التحديات الفريدة في حد ذاته. لذلكنحن الآن مكلفون بإكمال خارطة الطريق المرتكزة على مجموعة التحديثات وحل هذه المشكلات مع الاحتفاظ بما يجعل Ethereum L1 فريدًا من حيث المتانة واللامركزية.
الزيادة: الأهداف الرئيسية
100,000+ TPS على L1+L2
الحفاظ على لامركزية وقوة L1
على الأقل بعض L2 ترث السمات الأساسية للإيثريوم (غير موثوق بها، ومفتوحة، ومقاومة للرقابة)
< p>الحد الأقصى لإمكانية التشغيل التفاعلي بين L2. يجب أن يبدو الإيثيريوم وكأنه نظام بيئي واحد، وليس 34 سلسلة بلوكتشين مختلفة.
معضلة قابلية التوسع
معضلة قابلية التوسع هي فكرة مقترحة في عام 2017، والتي تأخذ في الاعتبار ثلاثة جوانب من blockchain. هناك توتر بين عدة خصائص: اللامركزية (بشكل أكثر تحديدًا: انخفاض تكلفة تشغيل العقدة)، وقابلية التوسع (بشكل أكثر تحديدًا: معالجة كميات كبيرة من المعاملات)، والأمان (بشكل أكثر تحديدًا: الحاجة إلى مهاجم للتوصل إلى حل وسط، فهو يتطلب أغلبية العقد في الشبكة بأكملها لعقدة واحدة) فشل الصفقة).
من الجدير بالذكر أن المعضلة الثلاثية ليست نظرية، والمقالة التي تقدم المعضلة الثلاثية لا تأتي مع دليل رياضي. إنه يعطي حجة رياضية إرشادية: إذا كانت العقدة الصديقة للامركزية (على سبيل المثال، كمبيوتر محمول للمستهلك) يمكنها التحقق من معاملات N في الثانية، وكان لديك سلسلة تعالج معاملات k*N في الثانية، فعندئذ (1) سيتم رؤية كل معاملة فقط بواسطة عقدة 1/k، مما يعني أن المهاجم يحتاج فقط إلى اختراق عدد قليل من العقد لدفع المعاملات السيئة، أو (2) ستصبح العقد الخاصة بك قوية ولن تكون سلسلتك لا مركزية. لم يكن الغرض من هذه المقالة أبدًا إظهار أن كسر المعضلة الثلاثية أمر مستحيل؛ بل كان إظهار أن كسر المعضلة الثلاثية أمر صعب - فهو يتطلب بطريقة ما التفكير خارج الصندوق الذي تشير إليه الحجة.
على مر السنين، ادعت بعض السلاسل عالية الأداء في كثير من الأحيان أنها حلت المعضلة الثلاثية دون اتخاذ أي تدابير ذكية على مستوى البنية التحتية، وعادة ما يكون ذلك عن طريق استخدام حيل هندسة البرمجيات لتحسين العقد. هذا دائمًا ما يكون مضللًا، وسيكون تشغيل عقدة في مثل هذه السلسلة دائمًا أكثر صعوبة مما هو عليه في Ethereum. تستكشف هذه المقالة العديد من التفاصيل الدقيقة لسبب حدوث ذلك (ولماذا لا تستطيع هندسة برمجيات العميل L1 وحدها توسيع نطاق Ethereum نفسها).
ومع ذلك، فإن الجمع بين عينات توفر البيانات وSNARKs يحل المعضلة الثلاثية: فهو يسمح للعميل بالتحقق من توفر قدر معين من البيانات ومن تنفيذ عدد معين من الخطوات الحسابية بشكل صحيح، في حين أن فقط تنزيل هذا الجزء الأصغر من البيانات وتشغيل كمية أقل بكثير من العمليات الحسابية. SNARKs ليست جديرة بالثقة. يحتوي أخذ عينات توفر البيانات على نموذج ثقة أقلية-N دقيق، لكنه يحتفظ بالخاصية الأساسية للسلاسل غير القابلة للتطوير، وهي أنه حتى هجوم بنسبة 51% لا يمكنه إجبار الشبكة على قبول الكتل السيئة.
الحل الآخر لهذه المعضلة الثلاثية هو بنية البلازما، التي تستخدم تقنيات ذكية لتحويل مسؤولية مراقبة توفر البيانات إلى المستخدم بطريقة متوافقة مع الحوافز. في الفترة 2017-2019، عندما كان كل ما نحتاجه لتوسيع نطاق الحوسبة هو إثباتات الاحتيال، كانت قدرات Plasma الأمنية محدودة للغاية، ولكن تعميم SNARKs جعل بنية Plasma أكثر ملاءمة لمجموعة واسعة من حالات الاستخدام من ذي قبل.
مزيد من التقدم في أخذ عينات مدى توفر البيانات
ما هي المشكلة التي نحاول حلها؟
اعتبارًا من 13 مارس 2024، عندما يتم إطلاق ترقية Dencun، تحتوي شبكة Ethereum blockchain على 3 "نقط" تبلغ حوالي 125 كيلو بايت لكل فترة 12 ثانية، أو ما يقرب من 375 كيلو بايت من البيانات لكل فترة من النطاق الترددي المتاح. بافتراض أن بيانات المعاملة يتم نشرها مباشرة على السلسلة، فإن إرسال ERC20 يبلغ حوالي 180 بايت، وبالتالي فإن الحد الأقصى لعدد TPS من عمليات التجميع على Ethereum هو:
375000 / 12 / 180 = 173.6 TPS
إذا أضفنا بيانات استدعاء Ethereum (الحد الأقصى النظري: 30 مليون غاز لكل فتحة / 16 غاز لكل بايت = 1,875,000 بايت لكل فتحة) ويصبح هذا 607 TPS. بالنسبة لـ PeerDAS، تتمثل الخطة في زيادة هدف عدد البيانات الثنائية الكبيرة إلى 8-16، مما سيوفر لنا 463-926 TPS من بيانات الاتصال.
يعد هذا تحسنًا كبيرًا مقارنة بـ Ethereum L1، لكنه ليس كافيًا. نريد المزيد من قابلية التوسع. هدفنا على المدى المتوسط هو 16 ميجابايت لكل مقبس، والذي عند دمجه مع التحسينات في ضغط البيانات المجمعة سيمنحنا حوالي 58000 TPS.
ما هو وكيف يعمل؟
يعد PeerDAS تطبيقًا بسيطًا نسبيًا لـ "أخذ العينات أحادية البعد". كل نقطة في Ethereum هي متعددة الحدود من الدرجة 4096 في حقل مكون من 253 بت من الأعداد الأولية. نقوم ببث "مشاركات" كثيرة الحدود، حيث تتكون كل مشاركة من 16 تقييمًا عند 16 إحداثيات مجاورة مأخوذة من إجمالي 8192 مجموعة إحداثيات. يمكن استرداد النقطة في أي 4096 من أصل 8192 تقييمًا (باستخدام المعلمات الموصى بها حاليًا: أي 64 من أصل 128 عينة محتملة).
يعمل PeerDAS من خلال جعل كل عميل يستمع إلى عدد صغير من الشبكات الفرعية، حيث تبث الشبكة الفرعية ith العينة ith لأي كائن ثنائي كبير الحجم، بالإضافة إلى اسأل أقرانهم في p2p العالمي الشبكة لطلب النقط المطلوبة على شبكات فرعية أخرى (والتي ستستمع إلى شبكات فرعية مختلفة). يستخدم الإصدار الأكثر تحفظًا، SubnetDAS، آلية الشبكة الفرعية فقط ولا توجد طبقة نظير إضافية للطلب. التوصية الحالية هي أن العقد المشاركة في إثبات الملكية تستخدم SubnetDAS والعقد الأخرى (أي "العملاء") تستخدم PeerDAS.
من الناحية النظرية، يمكننا توسيع نطاق أخذ العينات أحادية الأبعاد إلى حد كبير: إذا قمنا بزيادة الحد الأقصى لعدد البيانات الثنائية الكبيرة إلى 256 (وبالتالي، فإن الهدف هو 128)، فسنصل إلى هدف 16 ميجا بايت ، في حين أن أخذ عينات توفر البيانات لا يكلف سوى 16 عينة لكل عقدة * 128 نقطة * 512 بايت لكل عينة لكل نقطة = 1 ميجابايت من عرض النطاق الترددي للبيانات لكل فتحة. يقع هذا ضمن نطاق التسامح الخاص بنا فقط: إنه أمر ممكن التنفيذ، ولكنه يعني أن العملاء ذوي النطاق الترددي المحدود لا يمكنهم أخذ عينات. يمكننا تحسين ذلك عن طريق تقليل عدد النقط وزيادة حجم النقط، ولكن هذا سيجعل إعادة البناء أكثر تكلفة.
لذا، نريد في النهاية أن نخطو خطوة إلى الأمام ونقوم بأخذ عينات ثنائية الأبعاد، وهو ما يفعل ذلك عن طريق أخذ عينات عشوائيًا ليس فقط داخل النقطة، ولكن أيضًا بين النقط. تُستخدم الخصائص الخطية لالتزامات KZG "لتوسيع" مجموعة النقط في الكتلة بقائمة من "النقط الافتراضية" الجديدة التي تقوم بتشفير نفس المعلومات بشكل متكرر.
أخذ عينات ثنائية الأبعاد. المصدر: a16z
بشكل حاسم، ليست هناك حاجة إلى نقاط كبيرة لحساب التوسيع الموعود، لذلك هذا المخطط صديق بشكل أساسي لبناء الكتل الموزعة. تحتاج العقدة التي تقوم ببناء الكتلة فعليًا فقط إلى التزام Blob KZG ويمكنها الاعتماد على DAS نفسها للتحقق من توفر Blob. يعد 1D DAS أيضًا صديقًا بطبيعته لبناء الكتل الموزعة.
ما هي الارتباطات بالأبحاث الحالية؟
المقالة الأصلية التي توضح توفر البيانات (2018): https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
< p style="text-align: left;">ورقة المتابعة:
https://arxiv.org/abs/1809.09044منشور توضيحي لـ DAS، النموذج: https:// www.paradigm.xyz/2022/08/das
التوفر ثنائي الأبعاد الذي وعدت به KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
< p style="text-align: left;">PeerDAS على ethresear.ch:
https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 والورق:
https://eprint.iacr.org/2024/1362 EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
< p style="text-align: left;">SubnetDAS على ethresear.ch:
https: // ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169اختلافات دقيقة في إمكانية الاسترداد في أخذ العينات ثنائية الأبعاد: https://ethresear.ch/t/nuances-of-data-recoverability-in- data-availability-sampling/16256
ما الذي يجب القيام به أيضًا، وما هي المقايضات التي يجب القيام بها؟
الخطوة التالية هي استكمال تنفيذ وطرح PeerDAS. منذ ذلك الحين، كان هناك جهد متزايد لزيادة عدد البيانات الثنائية الكبيرة بشكل مستمر في PeerDAS، مع مراقبة الشبكة بعناية وتحسين البرنامج لضمان الأمان. في غضون ذلك، نأمل في إجراء المزيد من العمل الأكاديمي على PeerDAS والإصدارات الأخرى من إضفاء الطابع الرسمي على DAS وتفاعلها مع قضايا مثل سلامة قاعدة اختيار الشوكة.
من الآن فصاعدا، نحن بحاجة إلى بذل المزيد من العمل لمعرفة الإصدار المثالي من DAS ثنائي الأبعاد وإثبات ذلك خاصية آمنة. نأمل أيضًا أن ننتقل في النهاية من KZG إلى البدائل المقاومة للكم ولا تتطلب إعدادًا موثوقًا به. في الوقت الحالي، لا نعرف أي المرشحين يفضلون بناء الكتل الموزعة. حتى تقنية "القوة الغاشمة" الباهظة الثمن المتمثلة في استخدام STARKs العودية لإنشاء أدلة صحة لإعادة بناء الصفوف والأعمدة ليست كافية لأن حجم تجزئة STARK من الناحية الفنية هو O(log(n) * log(log(n)) (مع STIR) )، في الواقع فإن STARK كبير تقريبًا مثل النقطة بأكملها
على المدى الطويل، أعتقد أن المسار الواقعي هو:
أداة DAS مثالية ثنائية الأبعاد؛
التزم باستخدام DAS أحادي الأبعاد، وضحي من أجل البساطة والمتانة عينة من كفاءة عرض النطاق الترددي وقبول الحد الأقصى للبيانات
(المحور الثابت) التخلي عن DA واحتضان البلازما بالكامل باعتبارها بنية الطبقة الثانية الأساسية التي نركز عليها
ul>يمكننا النظر إلى هذه الأمور من خلال تقييم النطاق:
لاحظ أن هذا الخيار لا يزال موجودًا حتى لو قررنا توسيع نطاق التنفيذ مباشرةً على L1. وذلك لأنه إذا كان L1 سيتعامل مع عدد كبير من TPS، فستصبح كتلة L1 كبيرة جدًا كبيرة، سيحتاج العملاء إلى طريقة فعالة للتحقق من صحتها، لذلك يجب علينا استخدام نفس التقنية التي تدعم التجميع (ZK-EVM وDAS) وL1
كيف تتلاءم مع خريطة الطريق التفاعلات الجزئية الأخرى؟
هل سيتم تقليل الحاجة إلى DAS ثنائي الأبعاد، أو على الأقل تأخيرها، إذا تم تنفيذ ضغط البيانات (انظر أدناه)، وستنخفض بشكل أكبر إذا أصبح استخدام البلازما أيضًا يشكل تحديات بروتوكولات وآليات إنشاء الكتل الموزعة: على الرغم من أن DAS ملائم من الناحية النظرية لإعادة البناء الموزع، إلا أنه من الناحية العملية يجب دمجه مع مقترح قائمة التضمين وآلية اختيار الشوكة المحيطة به. < /span>
ضغط البيانات
ما هي المشكلة التي نحاول حلها
كل معاملة في مجموعة التحديثات تشغل مساحة كبيرة من البيانات على السلسلة: تستغرق عمليات نقل ERC20 حوالي 180 بايت، مما يحد من قابلية التوسع لبروتوكول الطبقة الثانية عند 16 ميجابايت لكل فتحة p>
16000000 / 12 / 180 = 7407 TPS
ماذا لو، بالإضافة إلى. بحل البسط، يمكننا أيضًا حل المقام وجعل كل معاملة في المجموعة تستهلك عددًا أقل من البايتات على السلسلة، ماذا تفعل؟
ما هو وكيف يعمل؟
أعتقد أن أفضل تفسير هو هذه الصورة منذ عامين:
أبسط ربح هو ضغط صفر بايت: استبدال كل تسلسل طويل من صفر بايت ببايتين يمثلان عدد البايتات الصفرية. وللمضي قدمًا خطوة أخرى، نستغل الخصائص الخاصة بالمعاملات:
التوقيع التجميع< - نتحول من توقيعات ECDSA إلى توقيعات BLS التي لها خاصية دمج العديد من التوقيعات معًا في توقيع واحد يثبت صحة جميع التوقيعات الأصلية. لا تأخذ اللغة L1 ذلك في الاعتبار لأن التكلفة الحسابية للتحقق (حتى مع التجميع) أعلى، ولكن في بيئة شحيحة البيانات مثل البيئة L2 يمكن القول إنها منطقية. توفر وظيفة التجميع لـ ERC-4337 طريقة واحدة لتحقيق ذلك.
استبدال العنوان بالمؤشر - إذا تم استخدام العنوان من قبل، فيمكننا استبدال العنوان المكون من 20 بايت بمؤشر مكون من 4 بايت إلى الموقع التاريخي. يعد ذلك ضروريًا لتحقيق أقصى قدر من الفوائد، على الرغم من أن الأمر سيتطلب جهدًا لتحقيقه لأنه يتطلب (على الأقل جزءًا من) تاريخ blockchain لتصبح جزءًا من الأمة بشكل فعال.
تسلسل مخصص لقيم المعاملات - تحتوي معظم قيم المعاملات على أرقام قليلة جدًا، على سبيل المثال. يتم تمثيل 0.25 ETH بـ 250,000,000,000,000,000 وي. تعمل الرسوم الأساسية القصوى للغاز ورسوم الأولوية بالمثل. ولذلك، يمكننا تمثيل معظم القيم النقدية بشكل مضغوط للغاية باستخدام تنسيق النقطة العائمة العشرية المخصصة أو حتى قاموس القيم المشتركة بشكل خاص.
ما هي الروابط مع الأبحاث الموجودة؟
الاستكشاف من التسلسل.xyz: https://sequence xyz /blog/compressing-calldata
عقد تحسين بيانات المكالمات للمستوى الثاني، من ScopeLift: https://github.com/ScopeLift/l2-optimizooors
استراتيجية أخرى - تعتمد على الفعالية مجموعات المجموعات المثبتة (المعروفة أيضًا باسم مجموعات ZK) تنشر اختلافات الحالة بدلاً من المعاملات: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint- -l2-dataبصمة على -l1/9975
محفظة BLS - تجميع BLS عبر ERC-4337: https://github.com/getwax/bls-wallet
ما الذي يجب القيام به أيضًا وما هي المقايضات التي يجب إجراؤها؟
العمل الرئيسي المتبقي هو تنفيذ الخطة المذكورة أعلاه. المفاضلات الرئيسية هي:
يتطلب التبديل إلى توقيعات BLS جهدًا كبيرًا، و انخفاض التوافق مع شرائح الأجهزة الموثوقة التي تعمل على تحسين الأمان. يمكن استخدام أغلفة ZK-SNARK لأنظمة التوقيع الأخرى بدلاً من ذلك.
يؤدي الضغط الديناميكي (مثل استبدال العناوين بالمؤشرات) إلى تعقيد تعليمات العميل البرمجية.
يؤدي نشر اختلافات الحالة إلى السلسلة بدلاً من المعاملات إلى تقليل إمكانية التدقيق ويمنع العديد من البرامج (مثل مستكشفات المجموعات) من العمل.
كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
يمكن أن يؤدي اعتماد ERC-4337، ودمج أجزاء منه في نهاية المطاف في L2 EVM، إلى تسريع نشر التقنيات المتقاربة بشكل كبير. قد يؤدي دمج أجزاء من ERC-4337 في L1 إلى تسريع نشره على L2.
البلازما المعممة
ما المشكلة التي نريد حلها؟
حتى مع وجود 16 ميجابايت من النقاط الكبيرة وضغط البيانات، فإن 58000 TPS لا تكفي بالضرورة لتولي مدفوعات المستهلك بالكامل أو المجالات الاجتماعية اللامركزية أو غيرها من المجالات ذات النطاق الترددي العالي. وهذا صحيح بشكل خاص إذا بدأنا في التفكير في الخصوصية. قد يقلل من قابلية التوسع بمقدار 3-8x. بالنسبة للتطبيقات كبيرة الحجم ومنخفضة القيمة، أحد الخيارات اليوم هو Validium، الذي يبقي البيانات خارج السلسلة ولديه نموذج أمان مثير للاهتمام حيث لا يستطيع المشغلون سرقة أموال المستخدمين، ولكن يمكنهم الاختفاء وتجميد جميع أموال المستخدم بشكل مؤقت أو دائم. ولكن يمكننا أن نفعل ما هو أفضل.
ما هو وكيف يعمل؟
البلازما هي حل توسيع يتضمن قيام المشغلين بنشر الكتل خارج السلسلة ووضع جذور Merkle لتلك الكتل على السلسلة (على عكس Rollups، الذي يضع الكتلة بأكملها على السلسلة في السلسلة). بالنسبة لكل كتلة، يرسل المشغل لكل مستخدم فرع Merkle لإثبات ما حدث أو لم يحدث لأصول ذلك المستخدم. يمكن للمستخدمين سحب الأصول من خلال توفير شوكة Merkle. والأهم من ذلك، ليس من الضروري أن يتم تجذير الفرع عند أحدث حالة - لذا، حتى في حالة فشل توفر البيانات، لا يزال بإمكان المستخدمين استرداد أصولهم عن طريق الرجوع إلى أحدث حالة متاحة. إذا ارتكب المستخدم فرعًا غير صالح (على سبيل المثال، سحب أصل أرسله إلى شخص آخر، أو قام المشغل نفسه بإنشاء الأصل من لا شيء)، فيمكن لآلية التحدي على السلسلة أن تفصل فيمن ينتمي الأصل بشكل صحيح.
مخطط سلسلة النقدية بالبلازما. يتم وضع المعاملة التي تنفق العملة i في الموضع i في الشجرة. في هذا المثال، بافتراض أن جميع الأشجار السابقة صالحة، نعلم أن حواء تمتلك حاليًا العملة رقم 1، وديفيد يمتلك العملة رقم 4، وجورج يمتلك العملة رقم 6.
يمكن للإصدارات السابقة من Plasma التعامل مع حالات استخدام الدفع فقط ولا يمكن الترويج لها بشكل فعال بشكل أكبر. ومع ذلك، تصبح البلازما أكثر قوة إذا طلبنا التحقق من كل جذر باستخدام SNARKs. يمكن تبسيط كل لعبة تحدي إلى حد كبير لأننا نزيل معظم المسارات الممكنة للعملاء للغش. يتم أيضًا فتح مسارات جديدة، مما يسمح لتكنولوجيا البلازما بالتوسع في نطاق أوسع من فئات الأصول. أخيرًا، طالما أن المشغل لا يغش، يمكن للمستخدمين سحب الأموال على الفور دون انتظار فترة تحدي مدتها أسبوع.
طريقة عمل سلسلة بلازما EVM (وليست طريقة واحدة فقط): استخدم ZK-SNARK لإنشاء شجرة UTXO متوازية تعكس تغييرات التوازن التي أجراها EVM وتحدد التعيين الفريد لـ "نفس العملة" لنقاط مختلفة في التاريخ. ويمكن بعد ذلك بناء هياكل البلازما على هذا الأساس.
من الأفكار المهمة أن أنظمة البلازما لا تحتاج إلى أن تكون مثالية. حتى لو كان بإمكانك فقط حماية جزء من أصولك (على سبيل المثال، حتى الرموز المميزة التي لم يتم نقلها في الأسبوع الماضي)، فقد قمت بتحسين الوضع الراهن لأجهزة EVM القابلة للتطوير بشكل كبير، وهو ما يعد بمثابة التحقق من الصحة.
هناك نوع آخر من البنية وهو بنية بلازما/مجموعات هجينة، مثل Intmax. تضع هذه الهياكل كمية صغيرة جدًا من البيانات لكل مستخدم على السلسلة (على سبيل المثال 5 بايت)، ومن خلال القيام بذلك يمكنك الحصول على خصائص بين البلازما والتجميع: في حالة Intmax، يمكنك الحصول على مستوى عالٍ جدًا من قابلية التوسع والخصوصية، حتى في عالم 16 ميجابايت، يبلغ الحد النظري للسعة حوالي 16,000,000 / 12 / 5 = 266,667 TPS.
ما هي الروابط مع الأبحاث الحالية؟
ورق البلازما الأصلي: https://plasma.io/plasma -deprecated.pdf
البلازما النقدية: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
التدفق النقدي للبلازما: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#-Exit
Intmax (2023): https://eprint.iacr.org/2023/1082
ما الذي يجب فعله أيضًا وما هي المقايضات ؟
المهمة الرئيسية المتبقية هي إدخال نظام البلازما إلى مرحلة الإنتاج. كما ذكرنا أعلاه، فإن "البلازما مقابل فالديوم" ليس معارضة ثنائية: يمكن لأي فالديوم أن يحسن الأداء الأمني على الأقل قليلاً عن طريق إضافة وظيفة البلازما إلى آلية الخروج. ويهدف البحث جزئيًا إلى الحصول على أفضل خصائص EVM (من حيث متطلبات الثقة، وتكلفة الغاز L1 في أسوأ الحالات، وضعف DoS) بالإضافة إلى الهياكل البديلة الخاصة بالتطبيقات. بالإضافة إلى ذلك، تتمتع البلازما بتعقيد مفاهيمي أكبر مقارنة بالمجموعات التي تحتاج إلى معالجة مباشرة من خلال البحث وبناء أطر عامة أفضل.
العيب الرئيسي لاستخدام تصميمات البلازما هو أنها تعتمد بشكل أكبر على المشغل ويصعب "البناء عليها"، على الرغم من أن تصميمات البلازما/التراكمية الهجينة غالبًا ما تتجنب هذا الضعف.
كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
كلما كان حل البلازما أكثر فعالية، قل الضغط على L1 للحصول على إمكانات توفر بيانات عالية الأداء. يؤدي نقل الأنشطة إلى L2 أيضًا إلى تقليل ضغط MEV على L1.
نظام إثبات اللغة الثانية الناضج
ما هي المشكلات التي نريد حلها؟
اليوم، أغلب التجمعات ليست في واقع الأمر عديمة الثقة؛ فهناك مجلس أمني يتمتع بالقدرة على تجاوز البراهين (المتفائلة أو الصادقة) على سلوك النظام. وفي بعض الحالات، لا يكون نظام التصديق موجودًا، أو إذا كان موجودًا، فإنه يكون له وظيفة "استشارية" فقط. أبرزها (1) بعض عمليات التجميع الخاصة بالتطبيقات، مثل Fuel، التي لا يمكن الثقة بها، و(2) اعتبارًا من كتابة هذه السطور، Optimism وArbitrum، وهما مجموعتان كاملتان من أدوات EVM تنفذان بالفعل انعدام الثقة الجزئي. يُطلق على المعلم الرئيسي اسم "المرحلة 1" ". يرجع السبب وراء عدم تطوير Rollups بشكل أكبر إلى المخاوف بشأن الأخطاء الموجودة في التعليمات البرمجية. نحن بحاجة إلى تجميع غير موثوق به، لذلك نحتاج إلى معالجة هذه المشكلة بشكل مباشر.
ما هو وكيف يعمل؟
أولاً، دعونا نراجع نظام "المرحلة" الذي تم تقديمه في البداية في هذه المقالة. هناك متطلبات أكثر تفصيلاً، ولكن الملخص هو كما يلي:
رقم 0 المرحلة: يجب أن يكون المستخدم قادرًا على تشغيل العقدة ومزامنة السلسلة. سيكون من المناسب أن يكون التحقق موثوقًا/مركزيًا بالكامل.
المرحلة الأولى: يجب أن يكون هناك نظام إثبات (غير موثوق به) لضمان قبول المعاملات الصحيحة فقط. يُسمح بتشكيل لجنة سلامة يمكنها تجاوز نظام التصديق، ولكن بحد تصويت يبلغ 75% فقط. بالإضافة إلى ذلك، يجب أن يكون الجزء الذي يحجب النصاب القانوني للمجلس (أي أكثر من 26%) من خارج الشركات الكبرى التي تقوم ببناء المجمع. يُسمح بآليات الترقية الأقل قوة (مثل DAOs)، ولكن يجب أن يكون هناك تأخير طويل بما فيه الكفاية بحيث إذا تمت الموافقة على ترقية ضارة، يمكن للمستخدمين سحب أموالهم قبل بدء الترقية.
المرحلة الثانية: يجب أن يكون هناك نظام إثبات (غير موثوق به) لضمان قبول المعاملات الصحيحة فقط. ولا يُسمح لمجلس الأمن بالتدخل إلا إذا كانت هناك أخطاء واضحة في القانون، على سبيل المثال. إذا كان هناك نظامان للإثبات الزائد غير متناسقين مع بعضهما البعض، أو إذا كان أحد أنظمة الإثبات يقبل جذرين مختلفين لحالة ما بعد لنفس الكتلة (أو لا يقبل أي شيء لفترة طويلة بما فيه الكفاية من الوقت، مثل أسبوع). يُسمح بآليات الترقية، ولكن مع تأخيرات طويلة فقط.
هدفنا الوصول للمرحلة الثانية . ويتمثل التحدي الرئيسي في الوصول إلى المرحلة الثانية في اكتساب القدر الكافي من الثقة لإثبات أن النظام في الواقع جدير بالثقة بدرجة كافية. هناك طريقتان رئيسيتان للقيام بذلك:
التحقق الرسمي :< /strong>يمكننا استخدام التقنيات الرياضية والحسابية الحديثة لإثبات (بشكل متفائل أو بكفاءة) أن النظام يقبل فقط الكتل التي تتجاوز مواصفات EVM. كانت هذه التقنيات موجودة منذ عقود، لكن التطورات الأخيرة (مثل Lean 4) جعلتها أكثر عملية، وقد يؤدي التقدم في التدقيق بمساعدة الذكاء الاصطناعي إلى تسريع هذا الاتجاه.
المصدقون المتعددون: أنشئ أنظمة تصديق متعددة واستثمر الأموال في أنظمة التصديق هذه واللجان الأمنية (و/أو المجموعات الصغيرة الأخرى التي لديها افتراضات ثقة) 2 -من 3 (أو أكبر) multisig بين أدوات مثل TEE). وإذا ثبت موافقة النظام فلا سلطة للمجلس. وإذا اختلفوا، فلا يمكن للمجلس إلا أن يختار واحدا منهم ولا يمكنه أن يفرض إجابته من جانب واحد.
>
مخطط منمق لمثبتين متعددين، يجمع بين نظام إثبات متفائل ونظام إثبات صحة ولجنة آمنة.
ما هي الروابط مع الأبحاث الحالية؟
EVM K Semantics (عمل التحقق الرسمي منذ 2017): https : //github.com/runtimeverification/evm-semantics
عرض توضيحي حول فكرة المثبتات المتعددة (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
تخطط Taiko لاستخدام البراهين المتعددة: https://docs.taiko.xyz/core- المفاهيم/multi -proofs/
ما الذي يجب فعله أيضًا وما الذي يجب وزنه؟
للتحقق الرسمي، هناك الكثير. نحتاج إلى إنشاء نسخة تم التحقق منها رسميًا من مُثبت SNARK بأكمله لـ EVM. وهذا مشروع معقد للغاية، على الرغم من أننا بدأناه بالفعل. هناك خدعة تعمل على تبسيط المهمة إلى حد كبير: يمكننا على سبيل المثال إنشاء إثبات SNARK تم التحقق منه رسميًا لجهاز افتراضي بسيط. RISC-V أو القاهرة، ثم اكتب تنفيذًا لـ EVM في هذا الحد الأدنى من VM (وأثبت رسميًا مكافئته لبعض مواصفات EVM الأخرى).
هناك جزأين رئيسيين متبقيين لمثبتين متعددين. أولاً، نحتاج إلى الثقة الكافية في نظامين إثبات مختلفين على الأقل، وأن كل منهما آمن إلى حد معقول، وأنه في حالة تعطلهما، فسوف يتعطلان لأسباب مختلفة وغير ذات صلة (بحيث لا يتعطلان في نفس الوقت). . ثانيًا، نحتاج إلى مستوى عالٍ جدًا من الضمانات في المنطق الأساسي لنظام إثبات الدمج. هذه قطعة صغيرة من التعليمات البرمجية. هناك طرق لجعلها صغيرة جدًا - ما عليك سوى تخزين الأموال في عقد آمن متعدد التوقيع يكون موقعوه عبارة عن عقود تمثل نظام التصديق الشخصي - ولكن هذا يأتي على حساب تكاليف الغاز المرتفعة على السلسلة. ويجب إيجاد بعض التوازن بين الكفاءة والأمن.
كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
يؤدي نقل الأنشطة إلى L2 إلى تقليل ضغط MEV على L1.
تحسينات قابلية التشغيل التفاعلي عبر L2
ما المشكلة التي نحاول حلها؟
أحد التحديات التي تواجه النظام البيئي للغة الثانية اليوم هو أنه يصعب على المستخدمين التنقل. بالإضافة إلى ذلك، غالبًا ما تعيد أبسط الأساليب تقديم افتراضات الثقة: الجسور المركزية، وعملاء RPC، وما إلى ذلك. إذا كنا جادين بشأن فكرة كون L2 جزءًا من Ethereum، فنحن بحاجة إلى جعل استخدام نظام L2 البيئي يشبه استخدام نظام Ethereum البيئي الموحد.
مثال سيئ للغاية (حتى خطير: لقد خسرت شخصيًا 100 دولار بسبب اختيار السلسلة الخاطئ هنا) عبر L2 UX - على الرغم من أن هذا ليس خطأ Polymarket، ولكن يجب أن تكون إمكانية التشغيل البيني عبر L2 مسؤولية المحافظ ومجتمع معايير Ethereum (ERC). في نظام إيثريوم البيئي الذي يعمل بشكل جيد، يجب أن يكون إرسال الرموز المميزة من L1 إلى L2 أو من L2 إلى آخر مثل إرسال الرموز المميزة داخل نفس L1.
ما هو وكيف يعمل؟
هناك العديد من فئات تحسينات قابلية التشغيل التفاعلي عبر L2. بشكل عام، طريقة طرح هذه الأسئلة هي ملاحظة أنه من الناحية النظرية، فإن Ethereum المتمركز حول التجميع هو نفس أداء L1 للتجزئة، ثم اسأل كيف تفشل نسخة L2 الحالية من Ethereum في تحقيق المثالية في الممارسة العملية. فيما يلي بعض منها:
عنوان محدد للسلسلة: يجب أن تكون السلسلة (L1، التفاؤل، التحكيم...) جزءًا من العنوان. بمجرد تنفيذها، يمكن تحقيق عملية الإرسال عبر L2 ببساطة عن طريق وضع العنوان في حقل "الإرسال"، وعند هذه النقطة يمكن للمحفظة معرفة كيفية الإرسال في الخلفية (بما في ذلك استخدام بروتوكول التجسير).
طلبات الدفع الخاصة بالسلسلة: يجب أن يكون إنشاء رسالة بالنموذج "أرسل لي الرموز المميزة X من النوع Y على السلسلة Z" أمرًا بسيطًا وموحدًا . هناك حالتان رئيسيتان للاستخدام لهذا: (1) المدفوعات، سواء كانت خدمات من شخص إلى شخص أو من شخص إلى تاجر، و(2) التطبيقات اللامركزية التي تطلب الأموال، على سبيل المثال. مثال Polymarket أعلاه.
التبادل عبر السلسلة ودفع الغاز: يجب أن يكون هناك بروتوكول مفتوح موحد للتعبير عن العمليات عبر السلسلة، مثل "أرسل 1 ETH على التفاؤل "إلى الشخص الذي أرسل 0.9999 ETH على Arbitrum"، و"لقد أرسلت 0.0001 ETH على التفاؤل إلى أي شخص قام بتضمين هذه المعاملة على Arbitrum" ERC-7683 هي محاولة للأول، بينما RIP-7755 هي محاولة لـ الأخير، على الرغم من أن كلاهما أكثر عمومية من حالات الاستخدام المحددة هذه
العملاء الخفيفون: يجب أن يكون المستخدمون قادرين على التحقق فعليًا من السلسلة التي يتفاعلون معها. ، ليس فقط الثقة بمزود RPC. فالعملة المشفرة A16z تفعل ذلك لـ Ethereum نفسها، ولكننا نحتاج إلى توسيع نطاق انعدام الثقة هذا إلى L2 /li>
p>
كيف يقوم العميل الخفيف بتحديث طريقة عرضه لسلسلة رأس Ethereum بمجرد حصولك على سلسلة الرأس، يمكنك استخدام إثباتات Merkle للتحقق من أي حالة بمجرد حصولك على كائن حالة L1 الصحيح، يمكنك استخدام إثباتات Merkle (وربما التوقيعات إذا كنت تريد التحقق من التأكيد المسبق) للتحقق من قيام أي كائن حالة على L2 < يمثل التوسيع إلى الأخير تحديًا توحيديًا
رسم تخطيطي لكيفية عمل محفظة Keystore.
فكرة أكثر تطرفًا لـ "جسر الرمز المميز المشترك" :تخيل عالمًا حيث كل L2 عبارة عن مجموعة من إثباتات الصلاحية، مع كل فتحة مخصصة لـ Ethereum. وحتى في هذا العالم، فإن نقل الأصول "محلياً" من L2 إلى آخر يتطلب عمليات سحب وإيداع، وهو ما يتطلب دفع الكثير من الغاز L1. تتمثل إحدى طرق حل هذه المشكلة في إنشاء الحد الأدنى من القيمة المجمعة المشتركة التي تتمثل وظيفتها الوحيدة في الحفاظ على الأرصدة التي يمتلك فيها L2 عدد أنواع الرموز المميزة، والسماح بتحديث هذه الأرصدة بشكل جماعي من خلال سلسلة من عمليات الانتقال. عملية إرسال L2 بدأت بواسطة أي L2. سيسمح ذلك بإجراء التحويلات عبر L2 دون دفع غاز L1 لكل عملية تحويل ودون الحاجة إلى تقنية تعتمد على مزود السيولة (مثل ERC-7683).
قابلية التركيب المتزامن: تسمح بإجراء مكالمات متزامنة بين L2 وL1 محددين، أو بين L2s متعددة. قد يساعد هذا في تحسين الكفاءة المالية لبروتوكولات التحدي. يمكن تحقيق الأول دون أي تنسيق عبر L2؛ ويتطلب الأخير تسلسلًا مشتركًا. تعتبر الأتمتة القائمة على التجميع صديقة لجميع هذه التقنيات.
ما هي الروابط مع الأبحاث الموجودة؟
العنوان الخاص بالسلسلة: ERC-3770: https: / /eips.ethereum.org/EIPS/eip-3770
ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
RIP-7755: . < a href="https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md">https://github.com/wilsoncusack/RIPs/blob/ cross -l2-call-standard/RIPS/rip-7755.md
تصميم محفظة تخزين المفاتيح المتداول: https://hackmd.io/@haichen/keystore
هيليوس: https://github.com/a16z/helios
ERC- 3668 (تسمى أحيانًا CCIP-read): https://eips.ethereum.org/EIPS/eip-3668< /p>
اقتراح جاستن دريك "(المشترك) القائم على التأكيد المسبق": https://ethresear.ch/t/based-preconfirmations/17353
L1SLOAD (RIP-7728): "https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388">https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388< /a>< /p>
المكالمات عن بعد في حالة تفاؤل: https:/ /github.com/ethereum-optimism/ecosystem-contributions/issues/76
AggLayer، والذي يتضمن أفكار جسر الرمز المميز المشترك: https://github.com/AggLayer
ما الذي يجب فعله أيضًا، وما هي المقايضات التي يجب إجراؤها؟
تواجه العديد من الأمثلة المذكورة أعلاه معضلة المعايير المتعلقة بوقت توحيد المعايير وأي الطبقات يجب توحيدها. إذا قمت بالتوحيد في وقت مبكر جدًا، فإنك تخاطر بالتوصل إلى حل رديء. إذا قمت بالتوحيد بعد فوات الأوان، فإنك تخاطر بالتسبب في تجزئة غير ضرورية. في بعض الحالات، هناك حلول قصيرة المدى أقل أداءً ولكن أسهل في التنفيذ، وحلول طويلة المدى "صحيحة في النهاية" ولكنها تستغرق وقتًا طويلاً للتنفيذ.
الأمر الفريد في هذا القسم هو أن هذه المهام ليست مجرد مشكلات فنية: فهي أيضًا (وربما في الغالب!) مشكلات اجتماعية. إنهم بحاجة إلى L2 والمحفظة للتعاون مع L1. إن قدرتنا على التعامل بنجاح مع هذه المشكلة هي اختبار لقدرتنا على العمل معًا كمجتمع.
كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
معظم هذه الاقتراحات هي بنيات "مستوى أعلى"، وبالتالي ليس لها تأثير كبير على اعتبارات اللغة الأولى. الاستثناء الوحيد هو الطلب المشترك، والذي له تأثير كبير على MEV.
تمديد التنفيذ على L1
ما المشكلة التي نحاول حلها؟
إذا أصبح L2 قابلاً للتطوير وناجحًا للغاية، لكن L1 لا يزال قادرًا فقط على التعامل مع عدد صغير جدًا من المعاملات، فقد يكون هناك عدد من المخاطر التي تواجه Ethereum:
أصبح الوضع الاقتصادي لأصول ETH أكثر خطورة، مما يؤثر بدوره على أمان الشبكة على المدى الطويل.
تستفيد العديد من لغات المستوى الثاني من الروابط الوثيقة مع النظام البيئي المالي المتطور للغاية في اللغة الأولى، وإذا تم إضعاف هذا النظام البيئي بشكل كبير، فإن الحافز لتصبح لغة ثانية (بدلاً من لغة واحدة مستقلة) سوف يضعف.
سيستغرق الأمر وقتًا طويلاً حتى يتمتع L2 بنفس الضمانات الأمنية تمامًا مثل L1.
إذا فشل L2 (على سبيل المثال، بسبب إجراءات ضارة أو عامل اختفاء)، سيظل المستخدمون بحاجة إلى المرور عبر L1 لاستعادة أصولهم. لذلك، يجب أن يكون L1 قويًا بما يكفي ليكون قادرًا على التعامل فعليًا مع نهاية L2 شديدة التعقيد والفوضى على الأقل في بعض الأحيان.
لهذه الأسباب، من المهم الاستمرار في توسيع المستوى الأول نفسه والتأكد من إمكانية الاستمرار في تكييفه مع عدد متزايد من الاستخدامات.
ما هو وكيف يعمل؟
أسهل طريقة للتوسع هي ببساطة زيادة حد الغاز. ومع ذلك، فإن هذا يخاطر بمركزية L1، وبالتالي تقويض سمة مهمة أخرى تجعل Ethereum L1 قوية جدًا: مصداقيتها كطبقة أساسية قوية. هناك جدل مستمر حول مدى استدامة الزيادة في حد الغاز البسيط، وسيتغير هذا أيضًا بناءً على تنفيذ تقنيات أخرى لتسهيل التحقق من الكتل الأكبر (على سبيل المثال، انتهاء التاريخ، عديم الجنسية، إثبات فعالية L1 EVM) . الشيء المهم الآخر الذي يحتاج إلى تحسين مستمر هو كفاءة برنامج عميل Ethereum، والذي تم تحسينه اليوم أكثر مما كان عليه قبل خمس سنوات. ستتضمن الإستراتيجية الفعالة لزيادة حد غاز L1 تسريع تقنيات التحقق هذه.
تتضمن إستراتيجية التوسع الأخرى تحديد وظائف محددة وأنواع الحوسبة التي يمكن جعلها ميسورة التكلفة دون المساس بلامركزية الشبكة أو خصائصها الأمنية. تتضمن الأمثلة على ذلك:
EOF - 1 أ تنسيق رمز بايت EVM جديد أكثر ملاءمة للتحليل الثابت ويمكّن من التنفيذ بشكل أسرع. مع أخذ هذه الكفاءات في الاعتبار، يمكن إعطاء رمز بايت EOF تكلفة غاز أقل.
تسعير الغاز متعدد الأبعاد - يمكن أن يؤدي إنشاء رسوم أساسية وحدود منفصلة للحوسبة والبيانات والتخزين إلى زيادة متوسط سعة Ethereum L1 دون زيادة سعة Ethereum L1. القدرة القصوى (وبالتالي خلق مخاطر أمنية جديدة).
تقليل تكاليف الغاز لأكواد تشغيل محددة وعمليات تجميع مسبقة - تاريخيًا، قمنا بالعديد من عمليات زيادة تكلفة الغاز المستديرة لتجنب هجمات رفض الخدمة. ما قمنا به أقل ولكن يمكننا القيام به أكثر هو تقليل تكلفة الغاز لعملياتنا المبالغ فيها. على سبيل المثال، تعتبر عملية الجمع أرخص بكثير من عملية الضرب، إلا أن تكلفة أكواد التشغيل ADD وMUL هي نفسها حاليًا. يمكننا أن نجعل ADD أرخص، وحتى أكواد التشغيل الأبسط مثل PUSH أرخص. هناك بشكل عام المزيد من EOFs.
EVM-MAX وSIMD: EVM-MAX ("الامتدادات الحسابية المعيارية") هو اقتراح يسمح بإجراء عمليات حسابية محلية أكثر كفاءة على نطاق واسع الرياضيات المعيارية كوحدة منفصلة لـ EVM. لا يمكن الوصول إلى القيم المحسوبة بواسطة حسابات EVM-MAX إلا عن طريق أكواد تشغيل EVM-MAX الأخرى ما لم يتم تصديرها عمدًا؛ وهذا يتيح مساحة أكبر لتخزين هذه القيم بتنسيق محسّن. SIMD ("تعليمات فردية وبيانات متعددة") هو اقتراح يسمح بالتنفيذ الفعال لنفس التعليمات على مجموعة من القيم. يمكن استخدام الاثنين معًا مع EVM لإنشاء معالج مساعد قوي يمكن استخدامه لتنفيذ عمليات التشفير بشكل أكثر كفاءة. يعد هذا مفيدًا بشكل خاص لبروتوكولات الخصوصية وأنظمة إثبات المستوى الثاني، لذا فهو سيساعد في قياس المستوى الأول والمستوى الثاني.
ستتم مناقشة هذه التحسينات بمزيد من التفصيل في مقال مستقبلي عن Splurge.
أخيرًا، الإستراتيجية الثالثة هي التجميع الأصلي (أو "التجميع المدمج"): بشكل أساسي، إنشاء العديد من نسخ EVM التي تعمل بالتوازي، وبالتالي تشكيل نموذج مكافئ لما يمكن أن يوفره التجميع، ولكن أكثر متكاملة أصلا في البروتوكول.
ما هي الروابط مع الأبحاث الحالية؟
خريطة طريق توسيع Ethereum L1 لبولينيا: https: //polynya .mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
تسعير الغاز متعدد الأبعاد: https://vitalik.eth.limo/general/2024/05/09/multidim.html
EIP-7706:https://eips.ethereum.org/EIPS/eip-7706< /a>
EOF: https://evmobjectformat.org/< /p>
EVM-MAX:https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
SIMD : https://eips.ethereum.org/EIPS/eip-616
< p style= "text-align: left;">الملخص الأصلي:https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgog k 6io1GEمقابلة مع ماكس ريسنيك حول قيمة تمديد L1: https : //x.com/BanklessHQ/status/1831319419739361321
جوستين دريك يتحدث عن التوسع باستخدام SNARKs والتجميع الأصلي: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
ما الذي يجب فعله أيضًا وما الذي يجب وزنه؟
هناك ثلاث إستراتيجيات لقياس المستوى الأول، والتي يمكن تنفيذها بشكل فردي أو بالتوازي:
-
قم بتحسين التكنولوجيا (على سبيل المثال، رمز العميل، والعميل عديم الجنسية، وانتهاء صلاحية السجل) لتسهيل التحقق من L1، ثم قم بزيادة حد الغاز
تقليل تكلفة عمليات محددة، في زيادة متوسط السعة دون زيادة مخاطر أسوأ الحالات
التراكمي الأصلي (أي "إنشاء N نسخ متوازية من EVM"، على الرغم من أنه قد يكون مفيدًا للمطورين يوفر نشر النسخ قدرًا كبيرًا من المرونة من حيث المعلمات)
من الجدير أن نفهم أن هذه تقنيات مختلفة مع مقايضات مختلفة. على سبيل المثال، تحتوي المجموعات المجمعة الأصلية على العديد من نقاط الضعف نفسها في قابلية التركيب مثل المجموعات العادية: لا يمكنك إرسال معاملة واحدة لتنفيذ العمليات بشكل متزامن عبر معاملات متعددة، تمامًا كما هو الحال مع العقود على نفس المستوى 1 (أو المستوى 2). سيؤدي رفع حد الغاز إلى إزالة الفوائد الأخرى التي يمكن تحقيقها من خلال تسهيل التحقق من L1، مثل زيادة نسبة المستخدمين الذين يقومون بتشغيل عقد التحقق وزيادة أصحاب المصلحة الفرديين. إن جعل عمليات محددة في EVM أرخص (اعتمادًا على كيفية تنفيذها) قد يزيد من التعقيد الإجمالي لـ EVM.
السؤال الكبير الذي يجب أن تجيب عليه أي خريطة طريق للتوسع في المستوى الأول هو: ما هي الرؤية النهائية للمستوى الأول والمستوى الثاني؟ من الواضح أن حدوث كل شيء على L1 أمر مثير للسخرية: حالات الاستخدام المحتملة تحتوي على مئات الآلاف من المعاملات في الثانية، مما يجعل L1 غير قابل للتحقق تمامًا (ما لم نذهب إلى مسار التجميع الأصلي). لكننا نحتاج إلى بعض الإرشادات حتى نتمكن من التأكد من أننا لا نخلق موقفًا نزيد فيه حد الغاز بمقدار 10x، ونلحق ضررًا كبيرًا باللامركزية في Ethereum L1، ونجد أننا دخلنا للتو عالمًا بدلاً من 99٪ من العالم. يكون النشاط على L2، و90% من النشاط يكون على L2، لذا تبدو النتائج متماثلة تقريبًا، باستثناء الخسارة التي لا رجعة فيها في الغالب لخصوصية L1 الخاصة بـ Ethereum.
عرض مقترح حول "تقسيم العمل" بين اللغتين L1 وL2
كيف يتناسب مع خارطة الطريق أجزاء أخرى من التفاعل؟
إن جذب المزيد من المستخدمين إلى اللغة الأولى لا يعني تحسين النطاق فحسب، بل يعني أيضًا تحسين الجوانب الأخرى من اللغة الأولى. وهذا يعني أن المزيد من المركبات الكهربائية المتوسطة ستبقى على المستوى الأول (بدلاً من كونها مجرد مشكلة في المستوى الثاني)، لذلك هناك حاجة ملحة أكبر للتعامل معها بشكل صريح. إنه يزيد بشكل كبير من قيمة أوقات الفتحات السريعة على L1. كما أنه يعتمد بشكل كبير على التحقق من صحة L1 ("The Verge") بسلاسة. ص>