في البداية، كان لدى إثيريوم استراتيجيتان لتوسيع القدرات في خريطة طريقه. واحدة (مثلا، انظر هذه الورقة المبكرةمن أهم الابتكارات (منذ عام 2015) كانت "التجزئة": بدلاً من التحقق وتخزين جميع المعاملات في السلسلة، يحتاج كل عقد فقط للتحقق وتخزين جزء صغير من المعاملات. هذا هو كيفية عمل أي شبكة ند للند أخرى (على سبيل المثال، BitTorrent) أيضًا، لذا بالتأكيد يمكننا جعل البلوكشين يعمل بنفس الطريقة. كانت واحدة أخرى بروتوكولات الطبقة 2: شبكات تجلس على رأس إثيريوم بطريقة تتيح لها الاستفادة بشكل كامل من أمانه، مع الاحتفاظ بمعظم البيانات والحسابات خارج السلسلة الرئيسية. "بروتوكولات الطبقة 2" تعنيقنوات الحالة في عام 2015، بلازمافي عام 2017، ثمرولابسفي عام 2019. تكون اللفات أكثر قوة من القنوات الحالية أو البلازما، ولكنها تتطلب كمية كبيرة من عرض الباندويث في البيانات على السلسلة. لحسن الحظ، بحلول عام 2019، قد حل بحث التشظيمشكلة التحقق من "توفر البيانات" على نطاق واسعنتيجة لذلك تقاربت المسارات الاثنان، وحصلنا على الخارطة طريق متمحورة حول الرول ابالتي تظل استراتيجية توسيع إثيريوم حتى اليوم.

الارتفاع، إصدار خريطة الطريق 2023.

يقترح خريطة العمل المركزة على الRollup تقسيمًا بسيطًا للعمل: يركز Ethereum L1 على كونه طبقة أساسية قوية ولامركزية، بينما تتولى L2s مهمة مساعدة النظام البيئي على التوسع. هذا نمط يتكرر في كل مكان في المجتمع: نظام المحاكم (L1) ليس هنا ليكون سريعًا للغاية وفعالًا، بل هو هنا لحماية العقود وحقوق الملكية، ويتوقف الأمر على رجال الأعمال (L2) لبناء فوق ذلكمتينقاعدةطبقةويأخذ البنية البشرية إلى (مجازي وحرفي) المريخ.

هذا العام، شهدت الخريطة الطريقية المركزة على الRollup نجاحات هامة: تزايد كبير في عرض النطاق الترددي لبيانات Ethereum L1 معالكتل EIP-4844, والعديد من الحلول الأسطوانية للآر إف إم الآن مرحلة 1. A very تنفيذ متنوع وتعددي للتجزئة، حيث يعمل كل L2 ك "شظية" لها قواعدها الداخلية ومنطقها ، أصبح الآن حقيقة واقعة. ولكن كما رأينا ، فإن اتخاذ هذا المسار ينطوي على بعض التحديات الفريدة الخاصة به. ولذا فإن مهمتنا الآن هي الانتهاء من خارطة الطريق التي تركز على التجميع ، وحل هذه المشكلات ، مع الحفاظ على المتانة واللامركزية التي تجعل Ethereum L1 مميزا.

الارتفاع: أهداف رئيسية

• 100,000+ TPS على L1+L2
• الحفاظ على اللامركزية وقوة L1
• على الأقل يرث بعض الطبقات الثانوية خصائص إيثيريوم الأساسية (غير المعتمدة على الثقة، مفتوحة، مقاومة للرقابة)
• أقصى توافق بين L2s. يجب أن يشعر Ethereum وكأنه نظام بيئي واحد، وليس 34 سلسلة كتل مختلفة.

في هذا الفصل

• وبعيدًا: معضلة التوسع الثلاثية
• تقدم إضافي في عينات توافر البيانات
• ضغط البيانات
• البلازما المعممة
• أنظمة الإثبات L2 الناضجة
• التوافق بين L2 المتقاطع وتحسينات تجربة المستخدم
• توسيع التنفيذ على المستوى L1

بصفتي: معضلة التوسعية الثلاثية

كانت مشكلة قابلية التوسع مفهومًاتم إطلاقه في عام 2017, الذي اعتبر أن هناك توتر بين ثلاث خصائص للبلوكشين: اللامركزية (بشكل أكثر تحديدًا: تكلفة منخفضة لتشغيل عقدة)، التوسعة (بشكل أكثر تحديدًا: عدد عالٍ من المعاملات المعالجة)، والأمان (بشكل أكثر تحديدًا: الحاجة إلى أن يفسد المهاجم جزءًا كبيرًا من العقد في الشبكة بأكملها لجعل حتى معاملة واحدة تفشل).

بشكل ملحوظ، الثلاثية ليست نظرية رياضية، ولم يتم إرفاق البريد الإلكتروني الذي يقدم الثلاثية بدليل رياضي. لقد قدم حجة رياضية استنتاجية: إذا كان بإمكان جهاز العميل اللابتوب (على سبيل المثال) التحقق من N معاملات في الثانية، وكان لديك سلسلة تعالج k*N معاملة في الثانية، فإما (i) أن ترى كل معاملة فقط من قبل 1/k من العقد، وهو ما يعني أن المهاجم يحتاج فقط إلى تلفيق عدد قليل من العقد لتمرير معاملة سيئة، أو (ii) سيؤدي ذلك إلى أن تكون عقدك قوية وسلسلتك غير مركزية. الغرض من البريد لم يكن أبدًا لإظهار أن كسر الثلاثية مستحيل؛ بل كان الهدف منه إظهار أن كسر الثلاثية صعب - فإنه يتطلب التفكير بطريقة مبتكرة خارج الصندوق الذي تقترحه الحجة.

لسنوات عديدة، كان من الشائع بالنسبة لبعض السلاسل عالية الأداء أن تدعي أنها تحل معضلة الثلاثية دون القيام بأي شيء ذكي على مستوى الهندسة المعمارية الأساسية، عادةً عن طريق استخدام حيل هندسة البرمجيات لتحسين العقد. هذا مضلل دائمًا، وتشغيل عقد في مثل هذه السلاسل ينتهي دائمًا بصعوبة أكبر بكثير مما هو عليه في إيثيريوم.هذا المنشوريدخل في بعض التفاصيل الدقيقة التي تشير إلى سبب هذا (وبالتالي، لماذا لا يمكن لهندسة برمجيات العميل L1 أن توسع Ethereum بمفردها).

ومع ذلك، فإن الجمع بين أخذ عينات من توافر البيانات و SNARKs لا يحل المعضلة الثلاثية: إذ يسمح للعميل بالتحقق من توافر كمية معينة من البيانات، وتمت إجراء عدد معين من خطوات الحساب بشكل صحيح، بينما يتم تنزيل جزء صغير فقط من تلك البيانات وتشغيل كمية أقل بكثير من الحسابات. SNARKs هي بدون ثقة. تمتلك عينة توافر البيانات تفاصيل دقيقةنموذج الثقة على أساس عدد قليل من N, ولكنه يحافظ على الخاصية الأساسية التي تتمتع بها الشبكات غير القابلة للتوسيع، وهي أنه حتى هجوم بنسبة 51% لا يمكن أن يجبر الكتل السيئة على القبول من قبل الشبكة.

طريقة أخرى لحل المعضلة الثلاثية هي تركيبات البلازما، التي تستخدم تقنيات ذكية لنقل المسؤولية لمراقبة توافر البيانات إلى المستخدم بطريقة متوافقة مع الحوافز. في الفترة بين عامي 2017 و 2019، عندما كان كل ما كان لدينا لتوسيع عمليات الحساب هو إثباتات الاحتيال، كانت البلازما محدودة جدًا فيما يمكنها فعله بأمان، ولكن توسيع استخدام تقنية SNARKs جعل تركيبات البلازماأكثر قابلية للتحقيق بكثيرلمجموعة أوسع من حالات الاستخدام مما كان عليه في السابق.

تقدم further في أخذ عينات من توافر البيانات

ما المشكلة التي نحن حلها؟

اعتبارًا من 13 مارس 2024، عندما ترقية دينكونعندما يتم تشغيله، يحتوي سلسلة تشفير إثيريوم على ثلاث "كتل" بحجم 125 كيلوبايت تقريبًا في كل فتحة زمنية بمعدل 12 ثانية، أو 375 كيلوبايت تقريبًا في كل فتحة زمنية من عرض البيانات المتاحة. بافتراض نشر بيانات المعاملات على السلسلة مباشرة، فإن نقل ERC20 يستهلك حوالي 180 بايتًا، وبالتالي، أقصى عدد للمعاملات في الثانية للتقنيات المتقدمة على سلسلة تشفير إثيريوم هو:

375000 / 12 / 180 = 173.6 TPS

إذا قمنا بإضافة بيانات Ethereum (الحد النظري: 30 مليون وحدة غاز لكل فتحة / 16 وحدة غاز لكل بايت = 1،875،000 بايت لكل فتحة)، سيصبح ذلك 607 TPS. مع PeerDAS، الخطة هي زيادة هدف عدد البلوب إلى 8-16، وهو ما سيمنحنا 463-926 TPS في بيانات Ethereum.

هذه زيادة كبيرة على إثيريوم L1، ولكنها ليست كافية. نريد المزيد من قابلية التوسع. هدفنا في المدى الطويل هو 16 ميجابايت لكل فتحة، وهو ما إذا تم دمجه مع تحسينات في ضغط بيانات الرول أب سيمنحنا حوالي 58،000 TPS.

ما هو وكيف يعمل؟

PeerDAS هو تنفيذ مبسط نسبيًا لعينة "1D". كل كتلة في إثيريوم هي متعددة الحدود من الدرجة 4096 فوق حقل أساسي بحجم 253 بت. نبث "حصصًا" من المتعدد، حيث يتكون كل حصة من 16 تقييمًا في 16 إحداثيًا متجاورًا مأخوذة من مجموعة إجمالية من 8192 إحداثيًا. أي 4096 من التقييمات الإجمالية (بمعلمات مقترحة حاليًا: أي 64 من العينات الممكنة 128) يمكن أن تسترد الكتلة.

يعمل PeerDAS عن طريق الاستماع كل عميل على عدد صغير من الشبكات الفرعية، حيث تبث الشبكة الفرعية الثانية عينة البلوك الثانية من أي بلوب، وتطلب أيضًا بلوبات على شبكات فرعية أخرى يحتاجها من خلال طلب نظرائه في شبكة p2p العالمية (الذين سيكونون يستمعون إلى شبكات فرعية مختلفة). إصدار أكثر تحفظًا، SubnetDAS, يستخدم آلية الشبكة الفرعية فقط، دون الطبقة الإضافية لطلب المساعدة من الأقران. الاقتراح الحالي هو أن تستخدم العقد المشاركة في الحصة النسبية SubnetDAS، وأن تستخدم العقد الأخرى (أي "العملاء") PeerDAS.

نظريًا، يمكننا توسيع عينة 1D إلى حد بعيد: إذا قمنا بزيادة الحد الأقصى لعدد الكتل إلى 256 (بالتالي، الهدف إلى 128)، فإننا سنصل إلى هدفنا من 16 ميجابايت بينما ستكلف عينة توفر البيانات كل عقدة فقط 16 عينة 128 blobs 512 بايت لكل عينة لكل كتلة = 1 ميجابايت من عرض البيانات لكل فتحة. هذا يكاد يكون ضمن نطاق تحملنا: يمكن القيام به، ولكن ذلك سيعني أن العملاء المحددين بعرض النطاق لا يمكنهم العينة. يمكننا تحسين هذا إلى حد ما عن طريق تقليل عدد الكتل وزيادة حجم الكتلة، ولكن هذا سيجعل عملية الإعادة أكثر تكلفة.

وبالتالي نريد في النهاية أن نذهب أبعد من ذلك، ونفعلعينات ثنائية الأبعاد، الذي يعمل عن طريق أخذ عينات عشوائية ليس فقط داخل الكتل، ولكن أيضًا بين الكتل. تُستخدم الخصائص الخطية لالتزامات KZG لـ "توسيع" مجموعة الكتل في كتلة مع قائمة من "الكتل الافتراضية" الجديدة التي تُشفر بشكل متكرر نفس المعلومات.

عينة ثنائية الأبعاد. المصدر: a16z crypto

من الضروري بشكل حاسم حساب تمديد الالتزامات دون الحاجة إلى وجود الكتل، لذلك النظام ودية بشكل أساسي لإنشاء كتل موزعة. العقدة التي تقوم فعليًا ببناء الكتلة ستحتاج فقط إلى وجود الالتزامات KZG للكتلة، ويمكن لها الاعتماد على DAS للتحقق من توفر الكتل. يعمل DAS بشكل طبيعي أيضًا على إنشاء كتل موزعة.

ما هي بعض الروابط للأبحاث الموجودة؟

• المنشور الأصلي الذي يقدم توافر البيانات (2018): https://github.com/إثيريوم/research/wiki/مذكرة-حول-توفر-البيانات-وترميز-المحو
• ورقة متابعة: 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
• PeerDAS على ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541، وورقة: https://eprint.iacr.org/2024/1362
• عرض حول PeerDAS بواسطة فرانشيسكو: https://www.youtube.com/watch?v=WOdpO1tH_Us
• EIP-7594: https://eips.إثيريوم.org/EIPS/eip-7594
• 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 وتفاعلاتها مع قضايا مثل سلامة قاعدة اختيار الفورك.

علاوة على ذلك في المستقبل ، نحتاج إلى مزيد من العمل لمعرفة الإصدار المثالي من 2D DAS وإثبات خصائص السلامة الخاصة به. نريد أيضا الانتقال في النهاية بعيدا عن KZG إلى بديل مقاوم للكم وخالي من الإعداد الموثوق به. حاليا ، لا نعرف مرشحين ودودين لبناء الكتل الموزعة. حتى تقنية "القوة الغاشمة" باهظة الثمن لاستخدام STARKs العودية لإنشاء أدلة على الصلاحية لإعادة بناء الصفوف والأعمدة لا تكفي ، لأنه في حين أن STARK من الناحية الفنية هي O (log (n) * log (log (n)) تجزئت في الحجم (مع STIR), في الواقع، يكاد يكون STARK بحجم كبير تقريبًا مثل كتلة كاملة.

المسارات الواقعية التي أراها على المدى الطويل هي:

• تنفيذ DAS ثنائي الأبعاد المثالي
• تمسك بـ 1D DAS، مضحيًا بكفاءة عرض النطاق الترددي للعينات وقبول سقف بيانات أقل من أجل البساطة والصلابة
• (التحول الصعب) التخلي عن DA، واعتناق Plasma بالكامل كهندسة طبقة 2 الأساسية التي نركز عليها

يمكننا عرض هذه على طول الطيف التضحية:

لاحظ أن هذا الاختيار موجود حتى لو قررنا توسيع التنفيذ على L1 مباشرة. هذا لأنه إذا كان يجب على L1 معالجة العديد من TPS ، فستصبح الكتل L1 كبيرة جدًا ، وسيود العملاء طريقة فعالة للتحقق من صحتها ، لذا سنحتاج إلى استخدام نفس التكنولوجيا التي تدعم ال rollups (ZK-EVM و DAS) في L1.

كيف تتفاعل مع أجزاء أخرى من خارطة الطريق؟

يقلل الحاجة إلى 2D DAS إلى حد ما، أو على الأقل يتم تأخيرها، إذا تم تنفيذ ضغط البيانات (انظر أدناه)، ويقلل أكثر إذا استخدم بلازما على نطاق واسع. كما تشكل DAS تحدياً لبروتوكولات وآليات بناء الكتل الموزعة: بينما نظرياً يعتبر DAS ودي لإعادة البناء الموزعة، إلا أن هذا يحتاج إلى توحيد في الممارسة.قائمة الإدراجالاقتراحات وميكانيكيات اختيار الشوكة المحيطة بها.

ضغط البيانات

ما المشكلة التي نحن نحلها؟

كل عملية في اللف من البيانات تأخذ كمية كبيرة من مساحة البيانات على السلسلة: تأخذ عملية نقل ERC20 حوالي 180 بايت. حتى مع أخذ عينات مثالية لتوافر البيانات، يتم وضع حد لقدرة التوسع لبروتوكولات الطبقة 2. مع 16 ميجابايت لكل فتحة، نحصل على:

16000000 / 12 / 180 = 7407 TPS

ماذا لو كان بالإضافة إلى معالجة البسط ، يمكننا أيضا معالجة المقام ، وجعل كل معاملة في مجموعة التحديثات تأخذ عددا أقل من البايتات على السلسلة؟

ما هو وكيف يعمل؟

أفضل تفسير في رأيي هوهذا الرسم البياني منذ عامين:

أبسط مكاسب هي مجرد ضغط بايت صفري: استبدال كل تسلسل طويل من بايتات الصفر ببايتين يمثلان كم من بايتات صفر هناك. للذهاب أبعد من ذلك، نستفيد من الخصائص الخاصة للمعاملات:

• التجميع التوقيعي - نقوم بالتبديل من توقيعات ECDSA إلى توقيعات BLS، والتي تتمتع بالخاصية التي يمكن دمج العديد من التواقيع معًا في توقيع واحد يشهد على صحة جميع التواقيع الأصلية. لا يعتبر هذا الأمر في L1 بسبب تكاليف التحقق الحسابية، حتى مع التجميع، ولكن في بيئة قليلة البيانات مثل L2s، فإنها تجعل معنى. ميزة التجميع ERC-4337يقدم مسارًا واحدًا لتنفيذ ذلك.
• استبدال العناوين بمؤشرات - إذا تم استخدام عنوان معين من قبل، يمكننا استبدال العنوان المكون من 20 بايت بمؤشر مؤلف من 4 بايت إلى موقع في التاريخ. هذا مطلوب لتحقيق أكبر مكاسب، على الرغم من أنه يتطلب جهدًا للتنفيذ، لأنه يتطلب (على الأقل جزءًا من) تاريخ البلوكشين أن يصبح بشكل فعال جزءًا من الحالة.
• تسلسل مخصص لقيم المعاملات - معظم قيم المعاملات لديها عدد قليل جدًا من الأرقام، على سبيل المثال، 0.25 إيث هو 250،000،000،000،000،000 واي. يعمل الحد الأقصى للغاز ورسوم الأساس والرسوم الأساسية بنفس الطريقة. بالتالي، يمكننا تمثيل معظم قيم العملة بشكل مضغوط جدًا باستخدام تنسيق نقطة عائمة عشرية مخصص، أو حتى قاموس للقيم الشائعة بشكل خاص.

ما هي بعض الروابط إلى الأبحاث الموجودة؟

• استكشاف من sequence.xyz: https://sequence.xyz/blog/compressing-calldata
• عقود محسنة لبيانات الاتصال ل L2s، من ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• استراتيجية بديلة - التراكمات القائمة على إثبات الصلاحية (المعروفة أيضا باسم ZK rollups) اختلافات ما بعد الحالة بدلا من المعاملات: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• محفظة BLS - تنفيذ لتجميع BLS من خلال ERC-4337: https://github.com/getwax/bls-wallet

ما الذي تبقى للقيام به، وما هي التنازلات؟

الشيء الرئيسي المتبقي هو تنفيذ الخطط أعلاه. التضحيات الرئيسية هي:

• الانتقال إلى توقيعات BLS يتطلب جهدًا كبيرًا، ويقلل من التوافق مع رقائق الأجهزة الموثوق بها التي يمكن أن تزيد الأمان. يمكن استخدام غلاف ZK-SNARK حول النظم التوقيعية الأخرى لاستبدال هذا.
• الضغط الديناميكي (على سبيل المثال، استبدال العناوين بالمؤشرات) يعقد كود العميل.
• تقليل نسبة التدقيق عن طريق حالات النشر بدلاً من المعاملات يقلل من إمكانية التدقيق، ويجعل العديد من البرامج (على سبيل المثال، مستكشفي الكتل) لا تعمل.

كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟

اعتماد ERC-4337، وفي نهاية المطاف تأصيل أجزاء منه في L2 EVMs، يمكن أن يسرع بشكل كبير نشر تقنيات التجميع. تأصيل أجزاء من ERC-4337 على L1 يمكن أن يسرع نشرها على L2s.

البلازما المعممة

ما المشكلة التي نحن نحلها؟

حتى مع وجود 16 ميغابايت من النقط وضغط البيانات ، فإن 58,000 TPS ليست بالضرورة كافية للاستيلاء الكامل على مدفوعات المستهلك أو القطاعات الاجتماعية اللامركزية أو غيرها من القطاعات ذات النطاق الترددي العالي ، ويصبح هذا صحيحا بشكل خاص إذا بدأنا في أخذ الخصوصية في الاعتبار ، مما قد يؤدي إلى انخفاض قابلية التوسع بمقدار 3-8x. بالنسبة للتطبيقات ذات الحجم الكبير والقيمة المنخفضة ، فإن أحد الخيارات اليوم هو ملف validium، الذي يحتفظ بالبيانات خارج السلسلة ولديه نموذج أمان مثير للاهتمام حيث لا يمكن للمشغل سرقة أموال المستخدمين، ولكن يمكن أن يختفي مؤقتًا أو دائمًا ويجمد جميع أموال المستخدمين. ولكن يمكننا أن نفعل أفضل.

ما هو وكيف يعمل؟

Plasma هو حلاً لتوسيع الذي يشمل مشغل نشر كتل خارج السلسلة، ووضع جذور Merkle لتلك الكتل على السلسلة (على عكس rollups، حيث يتم وضع الكتلة الكاملة على السلسلة). لكل كتلة، يرسل المشغل إلى كل مستخدم فرع Merkle يثبت ما حدث، أو لم يحدث، لأصول تلك المستخدم. يمكن للمستخدمين سحب أصولهم عن طريق تقديم فرع Merkle. من الأهمية بمكان، هذا الفرع لا يجب أن يكون متأصلاً في آخر حالة - لهذا السبب، حتى إذا فشلت توافر البيانات، يمكن للمستخدم استعادة أصولهم عن طريق سحب أحدث حالة متاحة لديهم. إذا قدم مستخدم فرعًا غير صالح (على سبيل المثال الخروج من أصل قام بإرساله بالفعل إلى شخص آخر، أو المشغل نفسه إنشاء أصل من العدم)، يمكن لآلية تحدي على السلسلة أن تقضي بمن ينتمي بحق إلى الأصل.

رسم بياني لسلسلة بلازما كاش. يتم وضع المعاملات التي تنفق عملة i في الموقع i في الشجرة. في هذا المثال، وبناءً على افتراض صحة جميع الشجيرات السابقة، نعلم أن إيف تمتلك حاليًا عملة 1، ديفيد يمتلك عملة 4، وجورج يمتلك عملة 6.

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

طريقة واحدة (ليست الطريقة الوحيدة) لإنشاء سلسلة بلازما EVM: استخدم ZK-SNARK لبناء شجرة UTXO موازية تعكس تغييرات التوازن التي أجراها EVM ، وتحدد تخطيطا فريدا لما هو "نفس العملة" في نقاط مختلفة من التاريخ. يمكن بعد ذلك بناء بناء البلازما فوق ذلك.

إحدى الرؤى الرئيسية هي أن نظام البلازما لا يحتاج إلى أن يكون مثاليًا. حتى لو كنت تستطيع حماية مجموعة فرعية من الأصول (على سبيل المثال، حتى العملات التي لم تتحرك في الأسبوع الماضي فقط)، فقد قمت بتحسين الوضع الراهن بشكل كبير بالفعل على نظام EVM فائق القابلية للتطوير، وهو نظام فاليديوم صالح.

فئة أخرى من البناء هي الهجين بلازما/رول أب، مثل Intmaxتضع هذه البنى كمية بيانات صغيرة جدًا لكل مستخدم على السلسلة (على سبيل المثال 5 بايت)، وبذلك تحصل على خصائص تقع بين البلازما والرولبس: في حالة Intmax، تحصل على مستوى عالٍ جدًا من التوسيع والخصوصية، على الرغم من أن القدرة في عالم 16 ميجابايت محدودة نظريًا إلى حوالي 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

ما الذي تبقى للقيام به، وما هي التنازلات؟

المهمة الرئيسية المتبقية هي جلب أنظمة البلازما إلى الإنتاج. كما ذُكر أعلاه، فإن "البلازما مقابل الفاليديوم" ليس ثنائيًا: يمكن تحسين خصائص سلامة أي فاليديوم على الأقل قليلًا عن طريق إضافة ميزات البلازما إلى آلية الخروج. الجزء البحثي هو الحصول على خصائص مثلى (من حيث متطلبات الثقة وتكلفة الغاز L1 في أسوأ الحالات، والعرضة للهجوم الضاري) لـ EVM، فضلاً عن البناء البديل لتطبيقات محددة. بالإضافة إلى ذلك، يجب معالجة التعقيد المفهومي الأكبر للبلازما مقارنة بالروبوتات مباشرة، سواء من خلال البحث أو من خلال بناء أطر عامة أفضل بشكل مباشر.

أبرز التضحيات في استخدام تصاميم البلازما هو أنها تعتمد أكثر على المشغلين وأصعب في التنفيذاستنادا اليعلى الرغم من أن التصاميم الهجينة للبلازما/الرول أب غالبًا ما تتجنب هذه الضعف.

كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟

كلما كانت حلول Plasma أكثر فعالية، كلما كانت أقل الضغط على L1 لديه وظيفة توافر بيانات عالية الأداء. نقل النشاط إلى L2 يقلل أيضًا من الضغط MEV على L1.

أنظمة إثبات L2 الناضجة

ما هي المشكلة التي نحن نحلها؟

اليوم، معظم الروابط ليست بعد غير موثوقة بالفعل؛ هناك مجلس أمن يمتلك القدرة على تجاوز سلوك (التفاؤلي أو الصحيح)نظام الإثبات. في بعض الحالات ، لا يكون نظام الإثبات مباشرا على الإطلاق ، أو إذا كان لديه وظيفة "استشارية" فقط. الأبعد إلى الأمام هي (i) عدد قليل من عمليات التجميع الخاصة بالتطبيقات ، مثل Fuel ، والتي لا يمكن ثقتها ، و (ii) اعتبارا من وقت كتابة هذه السطور ، Optimism و Arbitrum ، وهما مجموعتان كاملتان ل EVM حققتا علامة فارقة جزئية في انعدام الثقة تعرف باسم "المرحلة 1". السبب في أن عمليات التجميع لم تذهب إلى أبعد من ذلك هو القلق بشأن الأخطاء في الكود. نحن بحاجة إلى تراكمات غير موثوقة ، ولذا نحتاج إلى معالجة هذه المشكلة وجها لوجه.

ما هو وكيف يعمل؟

أولا ، دعونا نلخص نظام "المرحلة" ، الذي تم تقديمه في الأصل في هذا المنشور. هناك متطلبات أكثر تفصيلا ، ولكن الملخص هو:

• المرحلة 0: يجب أن يكون من الممكن للمستخدم تشغيل عقدة ومزامنة السلسلة. من المقبول إذا كانت عملية التحقق موثوقة / مركزية بالكامل.
• المرحلة 1: يجب أن يكون هناك نظام دليل (غير قابل للثقة) يضمن أن تتم قبول المعاملات الصالحة فقط. يُسمح بوجود مجلس أمان يمكنه تجاوز نظام الدليل، ولكن فقط بتصويت بنسبة 75٪. بالإضافة إلى ذلك، يجب أن يكون جزء من مجلس يعيق النصاب (مثل 26٪ أو أكثر) خارج مبنى الشركة الرئيسي التي تقوم بتطوير الRollup. يُسمح بآلية ترقية تحتوي على ميزات أضعف (مثل DAO)، ولكن يجب أن يكون لديها تأخير كافٍ بحيث إذا وافقت على ترقية خبيثة، يمكن للمستخدمين سحب أموالهم قبل أن تصبح نشطة.
• المرحلة 2: يجب أن يكون هناك نظام دليل (غير قابل للثقة) يضمن أن تتم قبول المعاملات الصالحة فقط. يسمح فقط لمجالس الأمان بالتدخل في حالة وجود علل قابلة للإثبات في الشفرة، على سبيل المثال، إذا اختلف نظاما الدليل المتكرران مع بعضهما البعض أو إذا قبل نظام الدليل واجهتان ما بعدية مختلفتان لنفس الكتلة (أو يقبل شيئًا لفترة زمنية كافية ، على سبيل المثال أسبوع). يُسمح بآلية الترقية، ولكن يجب أن يكون لديها تأخير طويل جدًا.

الهدف هو الوصول إلى المرحلة 2. التحدي الرئيسي في الوصول إلى المرحلة 2 هو الحصول على ثقة كافية بأن نظام الإثبات جدير بالثقة بدرجة كافية. هناك طريقتان رئيسيتان للقيام بذلك:

• التحقق الرسمي: يمكننا استخدام التقنيات الرياضية والحسابية الحديثة لإثبات أن نظام الإثبات (التفاؤلي أو الصحة) يقبل فقط الكتل التي تجتاز مواصفات EVM. هذه التقنيات موجودة منذ عقود، ولكن التطورات الأخيرة مثل لين 4جعلتها أكثر عملية بكثير، ويمكن أن تسرع التقدمات في إثبات المساعدة الذكاء الاصطناعي هذا الاتجاه بشكل كبير.
• المثبتون المتعددون: قم بإنشاء أنظمة إثبات متعددة، وضع الأموال في عقد متعدد التوقيع بنسبة 2 من بين 3 (أو أكبر) بين تلك الأنظمة الإثباتية ومجلس أمن (و/أو جهاز آخر ذو افتراضات ثقة، على سبيل المثال TEEs). إذا اتفقت أنظمة الإثبات، فإن مجلس الأمن ليس لديه سلطة؛ إذا اختلفوا، يمكن لمجلس الأمن فقط اختيار أحدها، لا يمكنه فرض إجابته بمفرده.

مخطط مُزخرف لنظام متعدد الإثبات، يجمع بين نظام إثبات متفائل واحد، ونظام إثبات الصحة ومجلس أمان.

ما هي بعض الروابط إلى الأبحاث الحالية؟

• الجانب العاطفي لـ EVM (عمل التحقق الرسمي من عام 2017): https://github.com/runtimeverification/evm-semantics
• عرض حول فكرة الحوكمة المتعددة (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
• تخطط Taiko لاستخدام البراهين المتعددة: https://docs.taiko.xyz/core-concepts/multi-proofs/

ما الذي تبقى للقيام به ، وما هي المقايضات؟

للتحقق الرسمي ، الكثير. نحتاج إلى إنشاء نسخة تم التحقق منها رسميا من بروفير SNARK كامل ل EVM. هذا مشروع معقد بشكل لا يصدق ، على الرغم من أنه مشروع لقد بدأنا بالفعل. هناك خدعة واحدة تبسط بشكل كبير المهمة: يمكننا أن نصنع منفي SNARK موثق رسميًا لـ VM أدنى، على سبيل المثال. RISC-Vأوالقاهرة، ثم قم بكتابة تنفيذ لـ EVM في تلك الآلة الظاهرية الدنيا (وأثبت بشكل رسمي مكافأته لبعض مواصفات EVM الأخرى).

لدى العديد من المثبتين، هناك قطعتان رئيسيتان متبقيتان. أولاً، نحتاج إلى الحصول على ثقة كافية في ما لا يقل عن نظامي دليل مختلفين، كلاهما آمن بشكل معقول بشكل فردي وأنه إذا تم كسر أحدهما، فإنه سيتم كسره لأسباب مختلفة وغير متصلة (وبالتالي لن يتم كسرها في نفس الوقت). ثانيًا، نحتاج إلى الحصول على مستوى عالٍ جدًا من الثقة في اللوجيك الأساسي الذي يدمج أنظمة الدليل. هذه قطعة صغيرة جدًا من الشيفرة. هناك طرق لجعلها صغيرة للغاية - ما عليك سوى تخزين الأموال في عقد متعدد التوقيع الآمنالذين يوقعون العقود التي تمثل أنظمة البرهان الفردية - ولكن هذا يأتي على حساب تكاليف الغاز العالية في السلسلة. سيحتاج إلى العثور على توازن بين الكفاءة والسلامة.

كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟

نقل النشاط إلى L2 يقلل من ضغط MEV على L1.

تحسينات قابلية التشغيل البيني عبر L2

ما المشكلة التي نحن نحلها؟

تحد كبير واجهه النظام البيئي L2 اليوم هو أنه من الصعب على المستخدمين التنقل. وعلاوة على ذلك، تعيد طرق القيام بذلك كثيرًا فترضي افتراضات الثقة: الجسور المركزية، وعملاء RPC، وهلم جرا. إذا كنا جادين بالفكرة أن L2s هي جزء من إثيريوم، فيجب علينا أن نجعل استخدام بيئة L2 يشعر وكأنه استخدام بيئة إثيريوم موحدة.

مثال على سوء (وحتى خطورة: لقد خسرت شخصيًا 100 دولار بسبب خطأ في اختيار السلسلة هنا) تجربة مستخدم عبر L2 مرضية - على الرغم من أن هذا ليس خطأ Polymarket، ينبغي أن تكون توافقية L2 عبر المسؤولية الخاصة بالمحافظ ومجتمع معايير إيثيريوم (ERC). في نظام بيئي إيثيريوم يعمل بشكل جيد، يجب أن يشعر إرسال العملات من L1 إلى L2، أو من L2 إلى آخر، تمامًا كما لو كنت ترسل العملات داخل نفس L1.

ما هو وكيف يعمل؟

هناك العديد من فئات تحسينات التوافق عبر L2. بشكل عام، الطريقة للتوصل إلى هذه هي أن نلاحظ أنه في نظرية،Ethereum المرتكزة على التراكمي هي نفس الشيء مثل تجزئة تنفيذ L1، ثم اسأل حيث ينقص الكون الفرعي الحالي لإثيريوم من تلك الفكرة في التطبيق العملي. إليك بعض الأمثلة:

• عناوين محددة للسلسلة: يجب أن تكون السلسلة (L1، Optimism، Arbitrum...) جزءًا من العنوان. بمجرد تنفيذ هذا، يمكن تنفيذ تدفقات الإرسال عبر L2 فقط عن طريق وضع العنوان في حقل 'إرسال'، حيث يمكن للمحفظة معرفة كيفية الإرسال (بما في ذلك استخدام بروتوكولات الجسر) في الخلفية.
• طلبات الدفع الخاصة بالسلسلة: يجب أن يكون من السهل والمعياري إرسال رسالة من النموذج "أرسل لي X الرموز المميزة من النوع Y على السلسلة Z". يحتوي هذا على حالتين أساسيتين للاستخدام: (i) المدفوعات ، سواء كانت خدمة من شخص إلى شخص أو من شخص إلى تاجر ، و (ii) dapps التي تطلب الأموال ، على سبيل المثال. مثال بوليماركت أعلاه.
• تبادلات عبر السلاسل ودفع الغاز: يجب أن يكون هناك بروتوكول مفتوح موحد للتعبير عن العمليات عبر السلاسل مثل “أرسل 1 إيثر على الأمل إلى من يرسل لي 0.9999 إيثر على أربيتروم”، و“أرسل 0.0001 إيثر على الأمل إلى من يتضمن هذه العملية على أربيتروم”.ERC-7683 هي محاولة واحدة للأولى، و RIP-7755هو محاولة واحدة في هذا الأخير، على الرغم من أن كلاهما أكثر عمومية من مجرد هذه الحالات الاستخدام المحددة.
• عملاء خفيفون: يجب على المستخدمين أن يكونوا قادرين على التحقق فعليًا من السلاسل التي يتفاعلون معها، وليس فقط الاعتماد على مزودي RPC. A16z crypto’sهيليوسهل يفعل ذلك لإثيريوم نفسه، ولكن نحن بحاجة إلى توسيع هذه الثقة إلى L2s.ERC-3668 (CCIP-read)هي استراتيجية واحدة للقيام بذلك.

كيف يمكن لعميل خفيف تحديث رؤيته لسلسلة رؤوس إيثيريوم. بمجرد الحصول على سلسلة الرؤوس، يمكنك استخدام دلائل Merkle للتحقق من أي كائن حالة. وبمجرد الحصول على كائنات الحالة L1 الصحيحة، يمكنك استخدام دلائل Merkle (وربما التواقيع، إذا كنت ترغب في التحقق من التأكيدات السابقة) للتحقق من أي كائن حالة على L2. يقوم Helios بالفعل بالسابق. توسيع ذلك إلى الأخير هو تحدي توحيد.

• محافظ Keystore: اليوم، إذا أردت تحديث المفاتيح التي تتحكم في محفظة العقد الذكي الخاصة بك، عليك أن تفعل ذلك على جميع سلاسل N التي توجد فيها تلك المحفظة. محافظ Keystore هي تقنية تسمح بوجود المفاتيح في مكان واحد (سواء على L1، أو في وقت لاحق بشكل محتمل على L2)، ثم يتم قراءتها من أي L2 يحتوي على نسخة من المحفظة. هذا يعني أن التحديثات تحدث مرة واحدة فقط. لتكون فعالة، تتطلب محافظ Keystore من L2s أن يكون لديها طريقة موحدة لقراءة L1 دون تكلفة؛ هناك اقتراحان لهذا هماL1SLOAD و REMOTESTATICCALL.

رسم تخطيطي مُزخرف لكيفية عمل محافظ متجر المفاتيح.

• أفكار "جسر الرمز المميز المشترك" الأكثر راديكالية: تخيل عالما تكون فيه جميع L2s عبارة عن مجموعات إثبات الصلاحية ، والتي تلتزم ب Ethereum في كل فتحة. حتى في هذا العالم ، فإن نقل الأصول من L2 إلى L2 آخر "أصلا" يتطلب السحب والإيداع ، الأمر الذي يتطلب دفع كمية كبيرة من غاز L1. تتمثل إحدى طرق حل هذه المشكلة في إنشاء الحد الأدنى من التجميع المشترك ، والذي ستكون وظيفته الوحيدة هي الحفاظ على أرصدة عدد الرموز المميزة من أي نوع مملوكة من قبل L2 ، والسماح بتحديث هذه الأرصدة بشكل جماعي من خلال سلسلة من عمليات الإرسال عبر L2 التي بدأها أي من L2s. سيسمح ذلك بإجراء عمليات النقل عبر L2 دون الحاجة إلى دفع غاز L1 لكل عملية نقل ، ودون الحاجة إلى تقنيات قائمة على مزود السيولة مثل ERC-7683.
• قابلية التركيب المتزامن: تسمح بحدوث المكالمات المتزامنة سواء بين L2 محدد و L1، أو بين عدة L2. يمكن أن يكون هذا مفيدًا في تحسين الكفاءة المالية لبروتوكولات ديفي. يمكن القيام بالأولى دون أي تنسيق بين L2؛ بينما سيتطلب الأخير تسلسل مشترك. التراص القائم علىتكون وديّة تلقائيًا لجميع هذه التقنيات.

ما هي بعض الروابط إلى الأبحاث الحالية؟

• عناوين محددة للسلسلة: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
• ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
• RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
• تصميم محفظة ملف تعريف تخزين التمرير: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• هيليوس: https://github.com/a16z/helios
• ERC-3668 (المعروف أحيانًا باسم CCIP-read): https://eips.ethereum.org/EIPS/eip-3668
• مقترح لـ "التأكيدات المسبقة (المشتركة) بناءً على كلمة Justin Drake:https://ethresear.ch/t/based-preconfirmations/17353
• L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
• REMOTESTATICCALL في التفاؤل: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
• AggLayer، والتي تتضمن أفكار جسر الرمز المشترك: https://github.com/AggLayer

ما الذي تبقى للقيام به، وما هي التنازلات؟

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

طريقة واحدة يتميز بها هذا القسم هو أن هذه المهام ليست مجرد مشاكل تقنية: بل هي أيضًا (ربما حتى في المقام الأول!) مشاكل اجتماعية. إنها تتطلب من L2s والمحافظ و L1 أن يتعاونوا. قدرتنا على التعامل مع هذه المشكلة بنجاح هي اختبار لقدرتنا على البقاء معًا كمجتمع.

كيف يتفاعل مع أجزاء أخرى من خارطة الطريق؟

معظم هذه المقترحات عبارة عن إنشاءات "طبقة أعلى" ، وبالتالي لا تؤثر بشكل كبير على اعتبارات L1. استثناء واحد هو التسلسل المشترك ، والذي له تأثيرات شديدة على MEV.

تحجيم التنفيذ على L1

ما المشكلة التي نحن نحلها؟

إذا أصبحت L2s قابلة للتوسع بشكل كبير وناجحة ولكن L1 لا تزال قادرة على معالجة حجم قليل جدًا من المعاملات، فهناك العديد من المخاطر التي قد تنشأ تجاه إثيريوم:

1. تصبح الوضع الاقتصادي لأصل ETH أكثر خطورة، مما يؤثر بدوره على أمان الشبكة على المدى الطويل.
2. العديد من L2s تستفيد من كونها مرتبطة ارتباطًا وثيقًا بنظام مالي متقدم للغاية على L1، وإذا ضعف هذا النظام المالي بشكل كبير، فإن الحافز لتصبح L2 (بدلاً من أن تكون L1 مستقلة) يضعف
3. سيستغرق وقتًا طويلاً قبل أن تحصل L2s على تأكيدات أمان مطابقة تمامًا ل L1.
4. إذا فشل L2 (على سبيل المثال بسبب مشغل خبيث أو اختفاء) ، فإن المستخدمين سيحتاجون للانتقال إلى L1 لاستعادة أصولهم. وبالتالي ، يجب أن يكون L1 قويًا بما يكفي للتعامل على الأقل أحيانًا فعليًا مع تسوية معقدة للغاية وفوضوية لـ L2.

لهذه الأسباب، فمن القيمة مواصلة توسيع L1 نفسه، والتأكد من أنه يمكنه مواصلة استيعاب عدد متزايد من الاستخدامات.

ما هذا وكيف يعمل؟

أسهل طريقة للتوسع هي ببساطة زيادة حد الغاز. ومع ذلك، يعرض هذا الأمر تمركز L1 للخطر، وبالتالي يضعف الخاصية الهامة الأخرى التي تجعل Ethereum L1 قوية: مصداقيتها كطبقة أساسية قوية. هناك جدل مستمر حول مدى الزيادة البسيطة في حد الغاز التي يمكن أن تكون مستدامة، ويتغير هذا أيضًا استنادًا إلى التقنيات الأخرى المُنفَّذة لجعل الكتل الأكبر أسهل في التحقق (على سبيل المثال، انتهاء الصلاحية التاريخية، عدم الاعتماد على الحالة، إثباتات صحة L1 EVM). شيء آخر مهم للارتقاء به هو ببساطة كفاءة برامج عميل Ethereum، والتي تم تحسينها بشكل أفضل اليوم مما كانت عليه قبل خمس سنوات. ستشمل استراتيجية فعالة لزيادة حد الغاز في L1 تسريع هذه التقنيات التحقق.

استراتيجية توسيع أخرى تتضمن تحديد الميزات وأنواع معينة من الحسابات التي يمكن جعلها أرخص دون التأثير على تمركزية الشبكة أو خصائص أمانها. أمثلة على ذلك تشمل:

• نهاية الملفتنسيق جديد لبيانات البايتكود التنفيذي الخاص بـ EVM يعمل على تسهيل تحليل الثابت، مما يسمح بتنفيذ أسرع. يمكن منح بايتكود EOF تكاليف غاز أقل لمراعاة هذه الكفاءات.
• تسعير الغاز متعدد الأبعاد- تحديد رسوم قاعدية منفصلة وحدود للحسابات والبيانات والتخزين يمكن أن يزيد من القدرة المتوسطة لـ Ethereum L1 دون زيادة القدرة القصوى (وبالتالي خلق مخاطر أمنية جديدة).
• تقليل تكاليف الغاز لشفرات التشغيل والعمليات المسبقة المحددة - تاريخيًا، كان لديناعدة جولاتمنزيادة غاز تكاليفلبعض العمليات التي كانت مُسعرة بشكل غير مناسب من أجل تجنب هجمات إنكار الخدمة. ما كان ينقصنا، ويمكننا أن نفعل المزيد منه، هو تقليل تكاليف الغاز للعمليات التي تكون مُفرطة في السعر. على سبيل المثال، الجمع أرخص بكثير من الضرب، ولكن تكاليف أكواد الإضافة والضرب حاليًا متماثلة. يمكننا جعل الإضافة أرخص، وحتى تكاليف أكواد بسيطة مثل الدفع أرخص أيضًا.
• EVM-MAXوSIMD: EVM-MAX (“تمديدات الحساب الرياضي الوحدة”) هو اقتراح للسماح برياضيات الوحدة الكبيرة الفعالة أكثر كوحدة منفصلة من EVM. القيم التي تم حسابها بواسطة عمليات EVM-MAX ستكون متاحة فقط لعمليات EVM-MAX الأخرى، ما لم يتم تصديرها بشكل متعمد؛ وهذا يتيح مساحة أكبر لتخزين هذه القيم فيتنسيقات محسنة. SIMD (“single instruction multiple data”) هو اقتراح للسماح بتنفيذ نفس التعليمة بكفاءة على مصفوفة من القيم. يمكن للاثنين معًا إنشاء قوة قوية المعالج المساعدبجانب EVM الذي يمكن استخدامه لتنفيذ العمليات التشفيرية بكفاءة أكبر بكثير. سيكون هذا مفيدًا بشكل خاص لبروتوكولات الخصوصية وأنظمة البرهان L2، لذلك سيساعد على تحسين قدرة توسيع L1 و L2.

ستتم مناقشة هذه التحسينات بمزيد من التفصيل في منشور مستقبلي حول التفاخر.

أخيرًا، الاستراتيجية الثالثة هي اللفات الأصلية (أو "اللفات الموضوعة"): وهي في الأساس إنشاء العديد من نسخ EVM التي تعمل بشكل متوازي، مما يؤدي إلى نموذج يكمل ما يمكن أن توفره اللفات، ولكن بشكل متكامل بشكل أكثر في البروتوكول.

ما هي بعض الروابط إلى الأبحاث الحالية؟

• خريطة طريق توسيع Polynya لـ 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
• نهاية الملف: https://evmobjectformat.org/
• EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
• SIMD: https://eips.إثيريوم.org/EIPS/eip-616
• تجميعات اللف الأصلية: https://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
• مقابلة مع ماكس ريسنيك حول قيمة توسيع L1: https://x.com/BanklessHQ/status/1831319419739361321
• جاستن دريك حول استخدام SNARKs والتكديس الأصلي للتوسيع:https://www.reddit.com/r/إثيريوم/comments/1f81ntr/comment/llmfi28/

ما الذي تبقى للقيام به، وما هي التنازلات؟

هناك ثلاث استراتيجيات لتحسين L1، يمكن متابعتها بشكل فردي أو متوازي:

• تحسين التكنولوجيا (مثل رمز العميل ، والعملاء عديمي الجنسية ، وانتهاء صلاحية التاريخ) لتسهيل التحقق من L1 ، ثم رفع حد الغاز
• اجعل العمليات المحددة أرخص، مما يزيد من الطاقة المتوسطة دون زيادة المخاطر في أسوأ الحالات
• لف لفات الأصلية (أي "إنشاء نسخ موازية N من EVM"، على الرغم من أنه قد يمنح المطورين الكثير من المرونة في معلمات النسخ التي ينشرونها)

يجدر بنا أن نفهم أن هذه تقنيات مختلفة لها مقايضات مختلفة. على سبيل المثال ، تحتوي عمليات التجميع الأصلية على العديد من نقاط الضعف نفسها في قابلية التركيب مثل عمليات التجميع العادية: لا يمكنك إرسال معاملة واحدة تقوم بتنفيذ العمليات بشكل متزامن عبر العديد منها ، كما يمكنك مع العقود على نفس L1 (أو L2). يؤدي رفع حد الغاز إلى الابتعاد عن الفوائد الأخرى التي يمكن تحقيقها من خلال تسهيل التحقق من L1 ، مثل زيادة جزء المستخدمين الذين يقومون بتشغيل عقد التحقق ، وزيادة التخزين الفردي. يمكن أن يؤدي جعل عمليات محددة في EVM أرخص ، اعتمادا على كيفية إجرائها ، إلى زيادة تعقيد EVM الكلي.

السؤال الكبير الذي تحتاج أي خارطة طريق لتوسيع نطاق L1 إلى الإجابة عليه هو: ما هي الرؤية النهائية لما ينتمي إلى L1 وما ينتمي إلى L2؟ من الواضح أنه من السخف أن يستمر كل شيء على L1: تدخل حالات الاستخدام المحتملة في مئات الآلاف من المعاملات في الثانية ، وهذا من شأنه أن يجعل L1 غير قابل للتحقق تماما (ما لم نذهب إلى مسار التجميع الأصلي). لكننا نحتاج إلى بعض المبادئ التوجيهية ، حتى نتمكن من التأكد من أننا لا نخلق وضعا نزيد فيه حد الغاز بمقدار 10 أضعاف ، ونلحق أضرارا جسيمة باللامركزية في Ethereum L1 ، ونجد أننا وصلنا فقط إلى عالم حيث بدلا من 99٪ من النشاط على L2 ، 90٪ من النشاط على L2 ، وبالتالي فإن النتيجة تبدو متشابهة تقريبا ، باستثناء خسارة لا رجعة فيها لكثير مما يجعل Ethereum L1 مميزا.

واحدة من الآراء المقترحة حول 'تقسيم العمل' بين L1 و L2s،مصدر.

كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟

جلب المزيد من المستخدمين إلى L1 يعني تحسين ليس فقط الحجم، ولكن أيضًا جوانب أخرى من L1. يعني أن المزيد من MEV سيظل على L1 (بدلاً من أن يصبح مشكلة فقط لـ L2)، وسيكون هناك حاجة أكبر حتى أكثر إلحاحًا للتعامل معه بشكل صريح. إنه يزيد بشكل كبير من قيمة وجود أوقات فتح سريعة على L1. وهو أيضًا يعتمد بشكل كبير على التحقق من L1 (“الحافة”) بشكل جيد.

تنصل المسؤولية:

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