تضمنت خريطة طريق إثيريوم في البداية استراتيجيتين لتوسيع النطاق: التجزئة وبروتوكولات Layer2. يسمح التجزئة لكل عقدة بالتحقق من وتخزين جزء صغير فقط من المعاملات، بينما يبني Layer2 شبكة فوق إثيريوم، مستفيداً من أمانها مع الاحتفاظ بمعظم البيانات والحسابات خارج السلسلة الرئيسية. في النهاية، اندمجت هاتان الطريقتان لتشكيل خريطة طريق تركز على Rollup، التي لا تزال الاستراتيجية الرئيسية لتوسيع إثيريوم حتى اليوم.
تركز خريطة الطريق التي تدور حول Rollup على تقسيم واضح للمهام: يركز إثيريوم L1 على أن يكون طبقة أساسية قوية ولا مركزية، بينما يتحمل L2 مهمة مساعدة النظام البيئي على التوسع. يعتبر هذا النموذج شائعًا في المجتمع، مشابهًا لنظام المحاكم (L1) الذي يوجد لحماية العقود وحقوق الملكية، بينما يقوم رواد الأعمال (L2) بالابتكار على هذا الأساس.
هذا العام، حقق هذا المخطط تقدمًا مهمًا: إطلاق كتل EIP-4844 زاد بشكل كبير من عرض البيانات في شبكة إيثريوم L1، وقد دخلت عدة حلول EVM Rollup المرحلة الأولى. كل L2 موجود ك"شريحة" لها قواعدها ومنطقها الخاص، وأصبحت تنوع طرق تنفيذ الشرائح واقعًا اليوم. لكن هذا الطريق يواجه أيضًا بعض التحديات الفريدة. مهمتنا الآن هي إكمال المخطط الذي يركز على Rollup، وحل هذه المشكلات، مع الحفاظ على صلابة ولامركزية إيثريوم L1.
يمكن أن تصل إثيريوم إلى أكثر من 100000 TPS من خلال L2 في المستقبل;
الحفاظ على اللامركزية والصلابة في L1;
على الأقل بعض L2 يرث تمامًا الخصائص الأساسية لإثيريوم ( للثقة، والانفتاح، ومكافحة الرقابة );
إثيريوم يجب أن يشعر وكأنه نظام بيئي موحد، وليس 34 سلسلة كتل مختلفة.
محتوى هذا الفصل
مثلث التناقض في قابلية التوسع
تقدم إضافي في عينة توفر البيانات
ضغط البيانات
بلازما معممة
نظام إثبات L2 الناضج
تحسين التداخل بين L2
توسيع التنفيذ على L1
تناقض مثلث القابلية للتوسع
تعتقد نظرية مثلث القابلية للتوسع أن هناك تعارضًا بين اللامركزية والقابلية للتوسع والأمان في سلسلة الكتل. إنها ليست نظرية، بل تشير إلى أن كسر مثلث التناقض أمر صعب، ويتطلب الخروج عن إطار التفكير المحدد. تدعي بعض السلاسل عالية الأداء أنها قد حلت مثلث التناقض، ولكن غالبًا ما يكون ذلك مضللًا، لأن تشغيل العقد على هذه السلاسل أكثر صعوبة من تشغيلها على إثيريوم.
ومع ذلك ، فإن دمج عينة توفر البيانات مع SNARKs يحل فعلاً مفارقة المثلث: حيث يسمح للعملاء بتحميل كمية صغيرة فقط من البيانات وأداء القليل جداً من الحسابات للتحقق من توفر كميات كبيرة من البيانات وصحة خطوات الحساب. SNARKs هي غير موثوق بها ، بينما تحتوي عينة توفر البيانات على نموذج ثقة دقيق من نوع few-of-N ، لكنها تحتفظ بالخصائص الأساسية لسلسلة غير قابلة للتوسع.
تعتبر بنية بلازما حلاً آخر، حيث تُعهد مسؤولية مراقبة توفر البيانات إلى المستخدمين بطريقة تحفيزية. مع انتشار SNARKs، أصبحت بلازما قابلة للتطبيق على نطاق أوسع من سيناريوهات الاستخدام.
مزيد من التقدم في أخذ عينات توفر البيانات
ما هي المشكلة التي نحلها؟
حاليًا، يحتوي كل شريحة من إثيريوم كل 12 ثانية على 3 كتل بحجم حوالي 125 كيلوبايت، وعرض النطاق الترددي المتاح للبيانات هو حوالي 375 كيلوبايت. إذا تم نشر بيانات المعاملات مباشرة على الشبكة، فإن تحويلات ERC20 تبلغ حوالي 180 بايت، وبالتالي فإن الحد الأقصى لمعدل TPS في Rollup على إثيريوم هو 173.6. بالإضافة إلى ذلك، يمكن أن يصل calldata إلى 607 TPS. باستخدام PeerDAS، قد يزيد عدد الكتل إلى 8-16، مما يوفر 463-926 TPS لـ calldata.
هذا تحسين كبير، لكنه لا يكفي بعد. هدفنا المتوسط هو 16 ميغابايت لكل فتحة، مع تحسين ضغط بيانات Rollup، مما سيؤدي إلى ~58000 TPS.
ما هو؟ كيف يعمل؟
PeerDAS هو تنفيذ بسيط لـ "1D sampling". في إثيريوم، كل blob هو متعدد حدود من الدرجة 4096 في حقل الأعداد الأولية من 253. نحن نقوم ببث حصص متعددة الحدود، كل حصة تحتوي على 16 قيمة تقييم على 16 نقطة متجاورة من 8192 نقطة. يمكن استعادة أي 4096 قيمة تقييم للblob.
يتيح PeerDAS لكل عميل الاستماع إلى عدد قليل من الشبكات الفرعية، حيث تقوم الشبكة الفرعية i ببث العينة i من أي blob، ويقوم العميل بطلب blobs من الشبكات الفرعية الأخرى من خلال الاستفسار عن نظرائه في شبكة p2p العالمية. يستخدم SubnetDAS آلية الشبكة الفرعية فقط، دون استفسارات إضافية عن طبقة النظير. الاقتراح الحالي يسمح لعقد إثبات الحصة بالمشاركة في استخدام SubnetDAS، بينما تستخدم العقد الأخرى PeerDAS.
من الناحية النظرية، يمكننا توسيع نطاق "عينة 1D" إلى حد كبير: إذا قمنا بزيادة الحد الأقصى لعدد blob إلى 256، يمكننا الوصول إلى هدف 16MB، حيث يحتاج كل عقدة إلى معالجة 1MB من البيانات في كل slot. هذا ممكن بصعوبة، ولكنه يعني أن العملاء الذين يواجهون قيودًا في عرض النطاق الترددي لا يمكنهم أخذ العينات. يمكننا تحسين ذلك عن طريق تقليل عدد blob وزيادة حجم blob، لكن هذا سيؤدي إلى زيادة تكلفة إعادة البناء.
لذلك، نريد في النهاية إجراء أخذ عينات ثنائية الأبعاد، ليس فقط داخل الكتلة، ولكن أيضًا أخذ عينات عشوائية بين الكتل. باستخدام الخصائص الخطية لالتزام KZG، يمكننا توسيع مجموعة الكتل داخل كتلة من خلال مجموعة جديدة من الكتل الافتراضية، والتي تشفر المعلومات نفسها بشكل زائد.
عينة 2D صديقة لبناء الكتل الموزعة، حيث يحتاج العقد التي تقوم فعليًا ببناء الكتل فقط إلى امتلاك التزام blob KZG، ويمكنها الاعتماد على عينة توفر البيانات للتحقق من توفر كتل البيانات. 1D DAS في الأساس أيضًا صديقة لبناء الكتل الموزعة.
ماذا يجب أن نفعل أيضًا؟ ما هي الموازنات الموجودة؟
بعد ذلك، سيتم تنفيذ وإطلاق PeerDAS. بعد ذلك، سيزداد عدد blobs على PeerDAS باستمرار، مع مراقبة الشبكة بعناية وتحسين البرمجيات لضمان الأمان. نحتاج أيضًا إلى مزيد من الأعمال الأكاديمية لت规范 PeerDAS وتفاعله مع مسائل الأمان مثل قواعد اختيار الفروع.
في المستقبل، نحتاج إلى تحديد النسخة المثالية من DAS ثنائي الأبعاد، وإثبات خصائصه الأمنية. كما نرغب في الانتقال من KZG إلى بدائل آمنة من الناحية الكمية ولا تحتاج إلى إعداد موثوق، ولكن لا يزال من غير الواضح ما هي الخيارات المتاحة التي تتوافق مع بناء الكتل الموزعة.
أعتقد أن المسار الواقعي طويل الأمد هو:
تنفيذ DAS ثنائي الأبعاد المثالي؛
الاستمرار في استخدام 1D DAS، التضحية بكفاءة عرض النطاق الترددي لأغراض بسيطة وقبول حد بيانات أقل للمتانة؛
التخلي عن DA، وقبول بلازما كهيكل Layer2 الرئيسي.
حتى لو قررنا توسيع التنفيذ مباشرةً على طبقة L1، فإن هذا الخيار موجود. إذا كان على L1 معالجة عدد كبير من TPS، ستصبح كتل L1 كبيرة جداً، وسيحتاج العملاء إلى التحقق من صحتها بكفاءة، وبالتالي سيتعين علينا استخدام نفس التقنيات على طبقة L1 كما هو الحال مع Rollup.
كيف تتفاعل مع أجزاء أخرى من خارطة الطريق؟
إذا تم تحقيق ضغط البيانات، فإن الطلب على 2D DAS سيقل أو يتأخر، وإذا تم استخدام Plasma على نطاق واسع، فإن الطلب سيقل أكثر. كما أن DAS يمثل تحديات لبروتوكولات وآليات بناء الكتل الموزعة: على الرغم من أن DAS نظريًا صديق لإعادة البناء الموزعة، إلا أن هذا يتطلب عمليًا الجمع مع اقتراح قائمة تضمين الحزم وآلية اختيار الفروع المحيطة بها.
تستخدم كل معاملة في Rollup مساحة كبيرة من بيانات السلسلة: تتطلب معاملات ERC20 حوالي 180 بايت. حتى مع وجود عينات مثالية من توافر البيانات، فإن هذا يحد من قابلية توسيع بروتوكولات Layer. كل slot 16 ميغابايت، نحصل على:
16000000 / 12 / 180 = 7407 TPS
ماذا سيحدث إذا استطعنا حل مشكلة البسط، بالإضافة إلى حل مشكلة المقام، مما يجعل كل عملية في Rollup تشغل عددًا أقل من البايتات على السلسلة؟
ما هو، وكيف يعمل؟
في ضغط بايت الصفر، يتم استبدال كل تسلسل طويل من بايتات الصفر ببايتين، للدلالة على عدد بايتات الصفر. بالإضافة إلى ذلك، استفدنا من خصائص معينة للصفقات:
تجميع التوقيعات: الانتقال من توقيع ECDSA إلى توقيع BLS، يمكن دمج توقيع BLS في توقيع واحد، مما يثبت صلاحية جميع التوقيعات الأصلية. في L1، نظرًا لارتفاع تكلفة حساب التحقق، لا يتم النظر في استخدام توقيع BLS. ولكن في L2، حيث تكون البيانات نادرة، يكون استخدام توقيع BLS منطقيًا. توفر خاصية التجميع في ERC-4337 وسيلة لتحقيق هذه الوظيفة.
استخدم المؤشرات لاستبدال العناوين: إذا كنت قد استخدمت عنوانًا معينًا من قبل، فيمكننا استبدال العنوان المكون من 20 بايت بمؤشر مكون من 4 بايت يشير إلى موقع معين في السجل التاريخي.
تسلسل التخصيص لقيمة الصفقة: عدد الأرقام لمعظم قيم الصفقات قليل، على سبيل المثال 0.25 ايثر يتم تمثيله كـ 250,000,000,000,000,000 wei. الرسوم الأساسية القصوى ورسوم الأولوية مشابهة أيضًا. لذلك، يمكننا استخدام تنسيق النقاط العشرية المخصص لتمثيل معظم قيم العملات.
ماذا يجب أن نفعل بعد ذلك، وما هي الموازين المتاحة؟
الخطوة التالية هي تنفيذ الخطة المذكورة أعلاه. تشمل الموازنة الرئيسية:
التبديل إلى توقيع BLS يتطلب جهدًا كبيرًا، وسيقلل من التوافق مع شرائح الأجهزة الموثوقة. يمكن استخدام تغليف ZK-SNARK لخطط التوقيع الأخرى كبديل.
ضغط ديناميكي ( إذا تم استبدال العناوين بالمؤشرات ) سيجعل كود العميل أكثر تعقيدًا.
نشر اختلافات الحالة على السلسلة بدلاً من المعاملات سيقلل من إمكانية التدقيق، مما يجعل الكثير من البرمجيات ( مثل متصفح الكتل ) غير قابلة للعمل.
كيف تتفاعل مع أجزاء أخرى من خارطة الطريق؟
من خلال اعتماد ERC-4337، وإدراج بعض محتوياته في L2 EVM في النهاية، يمكن تسريع نشر تقنية التجميع بشكل كبير. وضع بعض محتويات ERC-4337 على L1 يمكن أن يسرع من نشره على L2.
بلازما عمومية
ما هي المشكلة التي نحلها؟
حتى مع استخدام 16 ميغابايت من البيانات المضغوطة، فإن 58,000 معاملة في الثانية قد لا تكون كافية لتلبية احتياجات الدفع الاستهلاكي، أو وسائل التواصل الاجتماعي اللامركزية، أو أي مجالات ذات عرض نطاق ترددي مرتفع، خاصة عندما نأخذ في الاعتبار عوامل الخصوصية، مما قد يؤدي إلى تقليص القدرة على التوسع بمعدل 3-8 مرات. بالنسبة لسيناريوهات التطبيقات ذات حجم المعاملات العالي والقيمة المنخفضة، أحد الخيارات المتاحة حالياً هو استخدام Validium، الذي يحتفظ بالبيانات خارج السلسلة، وقد اعتمد نموذج أمان مثير للاهتمام: لا يمكن للمشغلين سرقة أموال المستخدمين، ولكنهم قد يقومون بتجميد أموال جميع المستخدمين مؤقتاً أو دائماً. لكن يمكننا أن نفعل أفضل من ذلك.
ما هو، كيف يعمل؟
Plasma هو حل توسيع يتضمن مشغلين ينشرون الكتل خارج السلسلة، ويضعون الجذر ميركل لهذه الكتل على السلسلة. بالنسبة لكل كتلة، يرسل المشغلون فرع ميركل إلى كل مستخدم لإثبات التغيرات أو عدم التغير في أصول هذا المستخدم. يمكن للمستخدمين استرداد الأصول من خلال تقديم فرع ميركل. من المهم أن هذا الفرع لا يجب أن يكون بجذر الحالة الأخيرة. لذلك، حتى في حالة حدوث مشكلات في توفر البيانات، لا يزال بإمكان المستخدمين استرداد الأصول من خلال استرداد الحالة الأخيرة المتاحة. إذا قام المستخدم بتقديم فرع غير صالح، يمكن تحديد ملكية الأصول من خلال آلية التحدي على السلسلة.
الإصدارات المبكرة من Plasma كانت قادرة فقط على معالجة حالات الدفع، ولم يكن من الممكن تعزيزها بشكل فعال. ومع ذلك، إذا كان من المطلوب التحقق من كل جذر باستخدام SNARK، فإن Plasma ستصبح أقوى بكثير. يمكن تبسيط كل لعبة تحدي بشكل كبير، لأننا استبعدنا معظم مسارات الغش المحتملة من المشغلين. في الوقت نفسه، تم فتح مسارات جديدة، مما يسمح لتقنية Plasma بالتوسع إلى فئات أصول أوسع. أخيرًا، في حالة عدم غش المشغلين، يمكن للمستخدمين سحب الأموال على الفور، دون الحاجة إلى انتظار فترة تحدي مدتها أسبوع.
طريقة لإنشاء سلسلة EVM Plasma ( ليست الطريقة الوحيدة ): استخدام ZK-SNARK لبناء شجرة UTXO المتوازية، تعكس التغييرات في الرصيد التي أجرتها EVM، وتعريف "رمز فريد" في نقاط زمنية مختلفة من التاريخ. ثم يمكن بناء هيكل Plasma عليها.
رؤية رئيسية هي أن نظام بلازما لا يحتاج إلى أن يكون مثالياً. حتى إذا كنت تستطيع فقط حماية مجموعة فرعية من الأصول ( مثل فقط في الماضي
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 17
أعجبني
17
6
إعادة النشر
مشاركة
تعليق
0/400
MetaverseVagabond
· 07-16 11:43
المبكرون في عالم العملات الرقمية الحمقى قاموا بتعدين العملات وتداولوا NFT
شاهد النسخة الأصليةرد0
LiquidityOracle
· 07-14 02:19
فقط عبارة فارغة L2 يعمل L1 يستلقي
شاهد النسخة الأصليةرد0
TrustlessMaximalist
· 07-14 02:11
صاعدL2، المحفظة已备好
شاهد النسخة الأصليةرد0
CryptoPhoenix
· 07-14 01:59
احترافي归来！سوق الدببة老حمقى底部心态重建中...
شاهد النسخة الأصليةرد0
Blockwatcher9000
· 07-14 01:58
l2 في النهاية هو مجرد تصحيح، أليس كذلك؟
شاهد النسخة الأصليةرد0
GasFeeCrybaby
· 07-14 01:57
خسارة فادحة في عالم العملات الرقمية، من يفهم الرسوم الغازية التي أدفعها يوميًا بسبب تداولاتي الاندفاعية.
إثيريومThe Surge خريطة الطريق: من Rollup إلى 10万TPS طريق التوسع
إثيريوم المستقبل المحتمل: The Surge
تضمنت خريطة طريق إثيريوم في البداية استراتيجيتين لتوسيع النطاق: التجزئة وبروتوكولات Layer2. يسمح التجزئة لكل عقدة بالتحقق من وتخزين جزء صغير فقط من المعاملات، بينما يبني Layer2 شبكة فوق إثيريوم، مستفيداً من أمانها مع الاحتفاظ بمعظم البيانات والحسابات خارج السلسلة الرئيسية. في النهاية، اندمجت هاتان الطريقتان لتشكيل خريطة طريق تركز على Rollup، التي لا تزال الاستراتيجية الرئيسية لتوسيع إثيريوم حتى اليوم.
تركز خريطة الطريق التي تدور حول Rollup على تقسيم واضح للمهام: يركز إثيريوم L1 على أن يكون طبقة أساسية قوية ولا مركزية، بينما يتحمل L2 مهمة مساعدة النظام البيئي على التوسع. يعتبر هذا النموذج شائعًا في المجتمع، مشابهًا لنظام المحاكم (L1) الذي يوجد لحماية العقود وحقوق الملكية، بينما يقوم رواد الأعمال (L2) بالابتكار على هذا الأساس.
هذا العام، حقق هذا المخطط تقدمًا مهمًا: إطلاق كتل EIP-4844 زاد بشكل كبير من عرض البيانات في شبكة إيثريوم L1، وقد دخلت عدة حلول EVM Rollup المرحلة الأولى. كل L2 موجود ك"شريحة" لها قواعدها ومنطقها الخاص، وأصبحت تنوع طرق تنفيذ الشرائح واقعًا اليوم. لكن هذا الطريق يواجه أيضًا بعض التحديات الفريدة. مهمتنا الآن هي إكمال المخطط الذي يركز على Rollup، وحل هذه المشكلات، مع الحفاظ على صلابة ولامركزية إيثريوم L1.
! أخبار فيتاليك: مستقبل Ethereum المحتمل ، الطفرة
الارتفاع: الأهداف الرئيسية
محتوى هذا الفصل
تناقض مثلث القابلية للتوسع
تعتقد نظرية مثلث القابلية للتوسع أن هناك تعارضًا بين اللامركزية والقابلية للتوسع والأمان في سلسلة الكتل. إنها ليست نظرية، بل تشير إلى أن كسر مثلث التناقض أمر صعب، ويتطلب الخروج عن إطار التفكير المحدد. تدعي بعض السلاسل عالية الأداء أنها قد حلت مثلث التناقض، ولكن غالبًا ما يكون ذلك مضللًا، لأن تشغيل العقد على هذه السلاسل أكثر صعوبة من تشغيلها على إثيريوم.
ومع ذلك ، فإن دمج عينة توفر البيانات مع SNARKs يحل فعلاً مفارقة المثلث: حيث يسمح للعملاء بتحميل كمية صغيرة فقط من البيانات وأداء القليل جداً من الحسابات للتحقق من توفر كميات كبيرة من البيانات وصحة خطوات الحساب. SNARKs هي غير موثوق بها ، بينما تحتوي عينة توفر البيانات على نموذج ثقة دقيق من نوع few-of-N ، لكنها تحتفظ بالخصائص الأساسية لسلسلة غير قابلة للتوسع.
تعتبر بنية بلازما حلاً آخر، حيث تُعهد مسؤولية مراقبة توفر البيانات إلى المستخدمين بطريقة تحفيزية. مع انتشار SNARKs، أصبحت بلازما قابلة للتطبيق على نطاق أوسع من سيناريوهات الاستخدام.
مزيد من التقدم في أخذ عينات توفر البيانات
ما هي المشكلة التي نحلها؟
حاليًا، يحتوي كل شريحة من إثيريوم كل 12 ثانية على 3 كتل بحجم حوالي 125 كيلوبايت، وعرض النطاق الترددي المتاح للبيانات هو حوالي 375 كيلوبايت. إذا تم نشر بيانات المعاملات مباشرة على الشبكة، فإن تحويلات ERC20 تبلغ حوالي 180 بايت، وبالتالي فإن الحد الأقصى لمعدل TPS في Rollup على إثيريوم هو 173.6. بالإضافة إلى ذلك، يمكن أن يصل calldata إلى 607 TPS. باستخدام PeerDAS، قد يزيد عدد الكتل إلى 8-16، مما يوفر 463-926 TPS لـ calldata.
هذا تحسين كبير، لكنه لا يكفي بعد. هدفنا المتوسط هو 16 ميغابايت لكل فتحة، مع تحسين ضغط بيانات Rollup، مما سيؤدي إلى ~58000 TPS.
ما هو؟ كيف يعمل؟
PeerDAS هو تنفيذ بسيط لـ "1D sampling". في إثيريوم، كل blob هو متعدد حدود من الدرجة 4096 في حقل الأعداد الأولية من 253. نحن نقوم ببث حصص متعددة الحدود، كل حصة تحتوي على 16 قيمة تقييم على 16 نقطة متجاورة من 8192 نقطة. يمكن استعادة أي 4096 قيمة تقييم للblob.
يتيح PeerDAS لكل عميل الاستماع إلى عدد قليل من الشبكات الفرعية، حيث تقوم الشبكة الفرعية i ببث العينة i من أي blob، ويقوم العميل بطلب blobs من الشبكات الفرعية الأخرى من خلال الاستفسار عن نظرائه في شبكة p2p العالمية. يستخدم SubnetDAS آلية الشبكة الفرعية فقط، دون استفسارات إضافية عن طبقة النظير. الاقتراح الحالي يسمح لعقد إثبات الحصة بالمشاركة في استخدام SubnetDAS، بينما تستخدم العقد الأخرى PeerDAS.
من الناحية النظرية، يمكننا توسيع نطاق "عينة 1D" إلى حد كبير: إذا قمنا بزيادة الحد الأقصى لعدد blob إلى 256، يمكننا الوصول إلى هدف 16MB، حيث يحتاج كل عقدة إلى معالجة 1MB من البيانات في كل slot. هذا ممكن بصعوبة، ولكنه يعني أن العملاء الذين يواجهون قيودًا في عرض النطاق الترددي لا يمكنهم أخذ العينات. يمكننا تحسين ذلك عن طريق تقليل عدد blob وزيادة حجم blob، لكن هذا سيؤدي إلى زيادة تكلفة إعادة البناء.
لذلك، نريد في النهاية إجراء أخذ عينات ثنائية الأبعاد، ليس فقط داخل الكتلة، ولكن أيضًا أخذ عينات عشوائية بين الكتل. باستخدام الخصائص الخطية لالتزام KZG، يمكننا توسيع مجموعة الكتل داخل كتلة من خلال مجموعة جديدة من الكتل الافتراضية، والتي تشفر المعلومات نفسها بشكل زائد.
عينة 2D صديقة لبناء الكتل الموزعة، حيث يحتاج العقد التي تقوم فعليًا ببناء الكتل فقط إلى امتلاك التزام blob KZG، ويمكنها الاعتماد على عينة توفر البيانات للتحقق من توفر كتل البيانات. 1D DAS في الأساس أيضًا صديقة لبناء الكتل الموزعة.
ماذا يجب أن نفعل أيضًا؟ ما هي الموازنات الموجودة؟
بعد ذلك، سيتم تنفيذ وإطلاق PeerDAS. بعد ذلك، سيزداد عدد blobs على PeerDAS باستمرار، مع مراقبة الشبكة بعناية وتحسين البرمجيات لضمان الأمان. نحتاج أيضًا إلى مزيد من الأعمال الأكاديمية لت规范 PeerDAS وتفاعله مع مسائل الأمان مثل قواعد اختيار الفروع.
في المستقبل، نحتاج إلى تحديد النسخة المثالية من DAS ثنائي الأبعاد، وإثبات خصائصه الأمنية. كما نرغب في الانتقال من KZG إلى بدائل آمنة من الناحية الكمية ولا تحتاج إلى إعداد موثوق، ولكن لا يزال من غير الواضح ما هي الخيارات المتاحة التي تتوافق مع بناء الكتل الموزعة.
أعتقد أن المسار الواقعي طويل الأمد هو:
حتى لو قررنا توسيع التنفيذ مباشرةً على طبقة L1، فإن هذا الخيار موجود. إذا كان على L1 معالجة عدد كبير من TPS، ستصبح كتل L1 كبيرة جداً، وسيحتاج العملاء إلى التحقق من صحتها بكفاءة، وبالتالي سيتعين علينا استخدام نفس التقنيات على طبقة L1 كما هو الحال مع Rollup.
كيف تتفاعل مع أجزاء أخرى من خارطة الطريق؟
إذا تم تحقيق ضغط البيانات، فإن الطلب على 2D DAS سيقل أو يتأخر، وإذا تم استخدام Plasma على نطاق واسع، فإن الطلب سيقل أكثر. كما أن DAS يمثل تحديات لبروتوكولات وآليات بناء الكتل الموزعة: على الرغم من أن DAS نظريًا صديق لإعادة البناء الموزعة، إلا أن هذا يتطلب عمليًا الجمع مع اقتراح قائمة تضمين الحزم وآلية اختيار الفروع المحيطة بها.
! مقال فيتاليك الجديد: مستقبل Ethereum المحتمل ، الطفرة
ضغط البيانات
ما هي المشكلة التي نحلها؟
تستخدم كل معاملة في Rollup مساحة كبيرة من بيانات السلسلة: تتطلب معاملات ERC20 حوالي 180 بايت. حتى مع وجود عينات مثالية من توافر البيانات، فإن هذا يحد من قابلية توسيع بروتوكولات Layer. كل slot 16 ميغابايت، نحصل على:
16000000 / 12 / 180 = 7407 TPS
ماذا سيحدث إذا استطعنا حل مشكلة البسط، بالإضافة إلى حل مشكلة المقام، مما يجعل كل عملية في Rollup تشغل عددًا أقل من البايتات على السلسلة؟
ما هو، وكيف يعمل؟
في ضغط بايت الصفر، يتم استبدال كل تسلسل طويل من بايتات الصفر ببايتين، للدلالة على عدد بايتات الصفر. بالإضافة إلى ذلك، استفدنا من خصائص معينة للصفقات:
تجميع التوقيعات: الانتقال من توقيع ECDSA إلى توقيع BLS، يمكن دمج توقيع BLS في توقيع واحد، مما يثبت صلاحية جميع التوقيعات الأصلية. في L1، نظرًا لارتفاع تكلفة حساب التحقق، لا يتم النظر في استخدام توقيع BLS. ولكن في L2، حيث تكون البيانات نادرة، يكون استخدام توقيع BLS منطقيًا. توفر خاصية التجميع في ERC-4337 وسيلة لتحقيق هذه الوظيفة.
استخدم المؤشرات لاستبدال العناوين: إذا كنت قد استخدمت عنوانًا معينًا من قبل، فيمكننا استبدال العنوان المكون من 20 بايت بمؤشر مكون من 4 بايت يشير إلى موقع معين في السجل التاريخي.
تسلسل التخصيص لقيمة الصفقة: عدد الأرقام لمعظم قيم الصفقات قليل، على سبيل المثال 0.25 ايثر يتم تمثيله كـ 250,000,000,000,000,000 wei. الرسوم الأساسية القصوى ورسوم الأولوية مشابهة أيضًا. لذلك، يمكننا استخدام تنسيق النقاط العشرية المخصص لتمثيل معظم قيم العملات.
ماذا يجب أن نفعل بعد ذلك، وما هي الموازين المتاحة؟
الخطوة التالية هي تنفيذ الخطة المذكورة أعلاه. تشمل الموازنة الرئيسية:
التبديل إلى توقيع BLS يتطلب جهدًا كبيرًا، وسيقلل من التوافق مع شرائح الأجهزة الموثوقة. يمكن استخدام تغليف ZK-SNARK لخطط التوقيع الأخرى كبديل.
ضغط ديناميكي ( إذا تم استبدال العناوين بالمؤشرات ) سيجعل كود العميل أكثر تعقيدًا.
نشر اختلافات الحالة على السلسلة بدلاً من المعاملات سيقلل من إمكانية التدقيق، مما يجعل الكثير من البرمجيات ( مثل متصفح الكتل ) غير قابلة للعمل.
كيف تتفاعل مع أجزاء أخرى من خارطة الطريق؟
من خلال اعتماد ERC-4337، وإدراج بعض محتوياته في L2 EVM في النهاية، يمكن تسريع نشر تقنية التجميع بشكل كبير. وضع بعض محتويات ERC-4337 على L1 يمكن أن يسرع من نشره على L2.
بلازما عمومية
ما هي المشكلة التي نحلها؟
حتى مع استخدام 16 ميغابايت من البيانات المضغوطة، فإن 58,000 معاملة في الثانية قد لا تكون كافية لتلبية احتياجات الدفع الاستهلاكي، أو وسائل التواصل الاجتماعي اللامركزية، أو أي مجالات ذات عرض نطاق ترددي مرتفع، خاصة عندما نأخذ في الاعتبار عوامل الخصوصية، مما قد يؤدي إلى تقليص القدرة على التوسع بمعدل 3-8 مرات. بالنسبة لسيناريوهات التطبيقات ذات حجم المعاملات العالي والقيمة المنخفضة، أحد الخيارات المتاحة حالياً هو استخدام Validium، الذي يحتفظ بالبيانات خارج السلسلة، وقد اعتمد نموذج أمان مثير للاهتمام: لا يمكن للمشغلين سرقة أموال المستخدمين، ولكنهم قد يقومون بتجميد أموال جميع المستخدمين مؤقتاً أو دائماً. لكن يمكننا أن نفعل أفضل من ذلك.
ما هو، كيف يعمل؟
Plasma هو حل توسيع يتضمن مشغلين ينشرون الكتل خارج السلسلة، ويضعون الجذر ميركل لهذه الكتل على السلسلة. بالنسبة لكل كتلة، يرسل المشغلون فرع ميركل إلى كل مستخدم لإثبات التغيرات أو عدم التغير في أصول هذا المستخدم. يمكن للمستخدمين استرداد الأصول من خلال تقديم فرع ميركل. من المهم أن هذا الفرع لا يجب أن يكون بجذر الحالة الأخيرة. لذلك، حتى في حالة حدوث مشكلات في توفر البيانات، لا يزال بإمكان المستخدمين استرداد الأصول من خلال استرداد الحالة الأخيرة المتاحة. إذا قام المستخدم بتقديم فرع غير صالح، يمكن تحديد ملكية الأصول من خلال آلية التحدي على السلسلة.
الإصدارات المبكرة من Plasma كانت قادرة فقط على معالجة حالات الدفع، ولم يكن من الممكن تعزيزها بشكل فعال. ومع ذلك، إذا كان من المطلوب التحقق من كل جذر باستخدام SNARK، فإن Plasma ستصبح أقوى بكثير. يمكن تبسيط كل لعبة تحدي بشكل كبير، لأننا استبعدنا معظم مسارات الغش المحتملة من المشغلين. في الوقت نفسه، تم فتح مسارات جديدة، مما يسمح لتقنية Plasma بالتوسع إلى فئات أصول أوسع. أخيرًا، في حالة عدم غش المشغلين، يمكن للمستخدمين سحب الأموال على الفور، دون الحاجة إلى انتظار فترة تحدي مدتها أسبوع.
طريقة لإنشاء سلسلة EVM Plasma ( ليست الطريقة الوحيدة ): استخدام ZK-SNARK لبناء شجرة UTXO المتوازية، تعكس التغييرات في الرصيد التي أجرتها EVM، وتعريف "رمز فريد" في نقاط زمنية مختلفة من التاريخ. ثم يمكن بناء هيكل Plasma عليها.
رؤية رئيسية هي أن نظام بلازما لا يحتاج إلى أن يكون مثالياً. حتى إذا كنت تستطيع فقط حماية مجموعة فرعية من الأصول ( مثل فقط في الماضي