يمكن أن يصل إثيريوم في المستقبل إلى أكثر من 100000 TPS من خلال L2؛
الحفاظ على اللامركزية والصلابة لـ L1؛
على الأقل بعض L2 ورثت الخصائص الأساسية لإثيريوم (عدم الثقة، مفتوح، مقاوم للرقابة)؛
إثيريوم يجب أن يشعر كأنه نظام بيئي موحد، وليس 34 سلسلة كتلة مختلفة.
محتوى هذا الفصل
تناقض مثلث القابلية للتوسع
المزيد من التقدم في عينة توفر البيانات
ضغط البيانات
بلازما مُعمَّمَة
نظام إثبات L2 الناضج
تحسين التشغيل المتداخل عبر L2
توسيع التنفيذ على L1
معضلة مثلث القابلية للتوسع
مثلث التوسع هو فكرة تم تقديمها في عام 2017، وتفيد بأن هناك تناقض بين ثلاثة خصائص للبلوك تشين: اللامركزية (بشكل أكثر تحديدًا: انخفاض تكلفة تشغيل العقد)، التوسع (عدد المعاملات المعالجة كبير) والأمان (يحتاج المهاجمون إلى تدمير جزء كبير من العقد في الشبكة لجعل معاملة واحدة تفشل).
من المهم أن نلاحظ أن مفارقة المثلث ليست نظرية، كما أن المنشورات التي تقدم مفارقة المثلث لا تحتوي على إثبات رياضي. لكنها تقدم حجة رياضية استدلالية: إذا كان هناك عقدة صديقة لامركزية (مثل الكمبيوتر المحمول الاستهلاكي) يمكنها التحقق من N معاملة في الثانية، وكان لديك سلسلة يمكنها معالجة k*N معاملة في الثانية، فإن (i) كل معاملة يمكن أن تُرى فقط بواسطة 1/k من العقد، مما يعني أن المهاجم يحتاج فقط إلى تدمير عدد قليل من العقد لإجراء معاملة خبيثة، أو (ii) ستصبح عقدتك قوية بينما لن تكون سلسلتك لامركزية. الغرض من هذه المقالة ليس إثبات أن كسر مفارقة المثلث مستحيل؛ بل يهدف في المقابل إلى إظهار أن كسر المفارقة الثلاثية صعب، ويتطلب الخروج بطريقة ما من إطار التفكير الضمني الذي يتضمنه هذا الجدل.
لسنوات عديدة، ادعت بعض الشبكات عالية الأداء أنها حلت معضلة الثلاثة دون تغيير هيكلها الأساسي، غالبًا من خلال استخدام تقنيات هندسة البرمجيات لتحسين العقد. هذا دائمًا ما يكون مضللًا، حيث أن تشغيل العقد على هذه الشبكات أصعب بكثير من تشغيل العقد على إثيريوم. ستستكشف هذه المقالة لماذا يحدث ذلك، ولماذا لا يمكن توسيع إثيريوم فقط من خلال هندسة البرمجيات الخاصة بعميل L1؟
ومع ذلك، فإن الجمع بين أخذ عينات توفر البيانات و SNARKs يحل بالفعل مفارقة المثلث: حيث يسمح للعميل بالتحقق من توفر كمية معينة من البيانات وصحة عدد معين من خطوات الحساب، مع تنزيل كمية قليلة فقط من البيانات وتنفيذ عدد قليل جدًا من الحسابات. SNARKs لا تتطلب الثقة. إن أخذ عينات توفر البيانات لديه نموذج ثقة دقيق من نوع few-of-N، ولكنه يحتفظ بالخصائص الأساسية للسلسلة غير القابلة للتوسع، حيث حتى هجوم 51% لا يمكنه إجبار الكتل السيئة على قبولها من قبل الشبكة.
طريقة أخرى لحل أزمة الثلاثة هي بنية بلازما، التي تستخدم تقنية ذكية لتحفيز المسؤولية عن مراقبة توفر البيانات على المستخدمين. في الفترة من 2017 إلى 2019، عندما كانت لدينا فقط وسيلة إثبات الاحتيال لتوسيع القدرة الحاسوبية، كانت بلازما محدودة جدًا من حيث التنفيذ الآمن، ولكن مع انتشار SNARKs (إثباتات المعرفة الصفرية القصيرة غير التفاعلية)، أصبحت بنية بلازما أكثر قابلية للتطبيق في مجموعة واسعة من سيناريوهات الاستخدام مقارنةً بالماضي.
التقدم الإضافي في عينة توفر البيانات
ما هي المشكلة التي نعمل على حلها؟
في 13 مارس 2024، عند إطلاق ترقية Dencun، سيكون هناك 3 blobs بحجم حوالي 125 كيلوبايت لكل slot كل 12 ثانية، أو عرض نطاق البيانات المتاحة لكل slot حوالي 375 كيلوبايت. إذا تم نشر بيانات المعاملات مباشرة على السلسلة، فإن تحويل ERC20 سيكون حوالي 180 بايت، لذا فإن الحد الأقصى لعدد المعاملات في الثانية على Rollup هو: 375000 / 12 / 180 = 173.6 TPS
إذا أضفنا calldata (القيمة القصوى النظرية: كل slot 30 مليون Gas / لكل بايت 16 gas = كل slot 1,875,000 بايت)، فإنها ستصبح 607 TPS. باستخدام PeerDAS، قد يزيد عدد blobs إلى 8-16، مما سيوفر 463-926 TPS لـ calldata.
هذا تطوير كبير لـ L1، لكنه ليس كافيًا. نريد المزيد من القابلية للتوسع. هدفنا المتوسط هو 16 ميجابايت لكل فتحة، وإذا تم دمجه مع تحسينات ضغط بيانات Rollup، فسيوفر ~58000 TPS.
ما هو؟ كيف يعمل؟
PeerDAS هو تنفيذ بسيط نسبيًا لـ "1D sampling". في هذا السياق، كل blob هو متعدد حدود (polynomial) من الدرجة 4096 في مجال الأعداد الأولية (prime field) المكون من 253 بت. نحن نبث أجزاء (shares) من المتعدد الحدود، حيث يحتوي كل جزء على 16 قيمة تقييم من 16 نقطة متجاورة من إجمالي 8192 نقطة. من بين هذه الـ 8192 قيمة تقييم، يمكن استعادة أي 4096 منها (وفقًا للمعلمات المقترحة حاليًا: أي 64 من 128 عينة محتملة).
تعمل PeerDAS على جعل كل عميل يستمع إلى عدد قليل من الشبكات الفرعية، حيث تقوم الشبكة الفرعية رقم i ببث العينة رقم i لأي blob، وتطلب blobs الأخرى في الشبكات الفرعية من خلال استعلام نظراء في الشبكة العالمية p2p (الذين سيستمعون إلى الشبكات الفرعية المختلفة). نسخة أكثر تحفظًا هي SubnetDAS التي تستخدم فقط آلية الشبكة الفرعية، دون استعلام إضافي عن طبقة النظراء. الاقتراح الحالي هو أن تستخدم العقد المشاركة في إثبات الحصة SubnetDAS، بينما تستخدم العقد الأخرى (أي العملاء) PeerDAS.
من الناحية النظرية، يمكننا توسيع نطاق "1D sampling" ليكون كبيرًا جدًا: إذا قمنا بزيادة العدد الأقصى من الـ blob إلى 256 (الهدف هو 128)، فسوف نتمكن من الوصول إلى هدف 16 ميجابايت، حيث أن كل عقدة في عينة توفر البيانات تحتوي على 16 عينة * 128 blob * 512 بايت لكل blob لكل عينة = 1 ميجابايت من عرض النطاق الترددي لكل فتحة. هذا بالكاد في نطاق تحملنا: هذا ممكن، لكن هذا يعني أن العملاء ذوي النطاق الترددي المحدود لا يمكنهم أخذ العينات. يمكننا تحسين ذلك إلى حد ما عن طريق تقليل عدد الـ blob وزيادة حجم الـ blob، لكن ذلك سيجعل تكلفة إعادة البناء أعلى.
لذلك، نريد في النهاية أن نخطو خطوة إضافية، وهو إجراء أخذ عينات ثنائية الأبعاد (2D sampling)، وهذه الطريقة لا تقوم فقط بأخذ عينات عشوائية داخل الـ blob، بل تأخذ عينات عشوائية أيضًا بين الـ blobs. باستخدام الخصائص الخطية لالتزام KZG، نقوم بتوسيع مجموعة الـ blobs داخل كتلة من خلال مجموعة جديدة من الـ blobs الافتراضية، هذه الـ blobs الافتراضية ترمز بشكل زائد لنفس المعلومات.
لذلك ، في النهاية نريد أن نذهب خطوة أخرى إلى الأمام ، ونقوم بأخذ عينات ثنائية الأبعاد ، ليس فقط داخل الكتلة ولكن أيضًا لأخذ عينات عشوائية بين الكتل. تُستخدم خصائص الالتزام KZG الخطية لتوسيع مجموعة الكتل داخل كتلة واحدة ، والتي تحتوي على قائمة كتل افتراضية جديدة ترمز بشكل زائد لنفس المعلومات.
من المهم جداً أن توسيع الالتزامات الحسابية لا يتطلب وجود blob، لذلك فإن هذه الخطة تعتبر بشكل أساسي صديقة لبناء الكتل الموزعة. يحتاج العقد التي تبني الكتل فعليًا فقط إلى امتلاك التزام blob KZG، ويمكنها الاعتماد على أخذ عينات توافر البيانات (DAS) للتحقق من توافر كتل البيانات. أخذ عينات توافر البيانات أحادي البعد (1D DAS) هو أيضاً بشكل أساسي صديق لبناء الكتل الموزعة.
ماذا يجب أن نفعل بعد؟ وما هي الموازنات المتاحة؟
بعد ذلك يأتي تنفيذ وإطلاق PeerDAS. بعد ذلك، سيتم زيادة عدد ال blob على PeerDAS باستمرار، مع مراقبة الشبكة بعناية وتحسين البرمجيات لضمان الأمان، وهي عملية تدريجية. في الوقت نفسه، نأمل أن تكون هناك المزيد من الأعمال الأكاديمية لتنظيم PeerDAS والإصدارات الأخرى من DAS والتفاعل بينها وبين مسائل الأمان المتعلقة بقواعد اختيار الانقسام.
في مراحل أبعد في المستقبل، نحتاج إلى القيام بمزيد من العمل لتحديد النسخة المثالية من 2D DAS وإثبات خصائصه الأمنية. نأمل أيضًا في النهاية أن نتمكن من الانتقال من KZG إلى بديل آمن كمي ولا يتطلب إعداد موثوق. في الوقت الحالي، لا نعرف بعد أي من الخيارات المحتملة صديقة لبناء الكتل الموزعة. حتى باستخدام تقنية "القوة الغاشمة" المكلفة، حتى باستخدام STARK التكراري لتوليد إثباتات الصلاحية لإعادة بناء الصفوف والأعمدة، لا يكفي تلبية الطلب، لأنه على الرغم من أنه من الناحية الفنية، فإن حجم STARK هو O(log(n) * log(log(n)) هاش (باستخدام STIR)، إلا أن STARK في الواقع يكاد يكون بحجم blob بأكمله.
أعتقد أن المسار الواقعي على المدى الطويل هو:
تنفيذ DAS ثنائي الأبعاد المثالي؛
الاستمرار في استخدام 1D DAS، التضحية بكفاءة عرض النطاق الترددي للعينة، وقبول حد بيانات أقل من أجل البساطة والموثوقية
التخلي عن DA، وقبول Plasma بالكامل كهيكل Layer2 الرئيسي الذي نهتم به.
يرجى ملاحظة أنه حتى إذا قررنا التوسع في التنفيذ مباشرة على طبقة L1، فإن هذا الخيار موجود. وذلك لأنه إذا كانت طبقة L1 ستتعامل مع عدد كبير من معاملات في الثانية (TPS)، فإن كتل L1 ستصبح كبيرة جداً، وسيرغب العميل في الحصول على طريقة فعالة للتحقق من صحتها، وبالتالي سيتعين علينا استخدام تقنيات مماثلة لتقنيات Rollup (مثل ZK-EVM و DAS) في طبقة L1.
كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
إذا تم تحقيق ضغط البيانات، فسيكون هناك انخفاض في الطلب على DAS ثنائي الأبعاد، أو على الأقل سيتم تأجيله، وإذا تم استخدام Plasma على نطاق واسع، فإن الطلب سيتقلص أكثر. كما أن DAS يمثل تحديًا لبروتوكولات وآليات بناء الكتل الموزعة: على الرغم من أن DAS نظريًا صديق للتوزيع، إلا أن هذا في الممارسة العملية يتطلب دمجه مع اقتراح قائمة تضمين الحزم وآلية اختيار الفروع المحيطة بها.
ضغط البيانات
ماذا نحل من مشكلة؟
تستهلك كل معاملة في Rollup مساحة كبيرة من بيانات السلسلة: يتطلب نقل ERC20 حوالي 180 بايت. حتى مع وجود عينات مثالية من توفر البيانات، فإن هذا يحد من قابلية التوسع في بروتوكولات Layer. كل فتحة 16 ميغابايت، نحصل على:
16000000 / 12 / 180 = 7407 TPS
ماذا لو تمكنا من حل مشكلة البسط وليس فقط مشكلة المقام، مما يجعل كل معاملة في كل Rollup تشغل عددًا أقل من البايتات على السلسلة؟
ما هو، وكيف يعمل؟
في رأيي، أفضل تفسير هو هذه الصورة من قبل عامين:
في ضغط بايتات صفرية، يتم استبدال كل سلسلة طويلة من بايتات صفرية بواسطة بايتين، تمثل عدد بايتات الصفر. علاوة على ذلك، استخدمنا خصائص معينة للمعاملات:
تجميع التوقيعات: نحن نتنقل من توقيع ECDSA إلى توقيع BLS، حيث تتمثل خاصية توقيع BLS في إمكانية دمج عدة توقيعات في توقيع واحد فقط، يمكن أن يثبت صحة جميع التوقيعات الأصلية. في طبقة L1، نظرًا لأن تكلفة حساب التحقق لا تزال مرتفعة حتى عند التجميع، فلا يتم النظر في استخدام توقيع BLS. ولكن في بيئة L2 التي تعاني من ندرة البيانات، فإن استخدام توقيع BLS له معنى. توفر خاصية التجميع في ERC-4337 مسارًا لتحقيق هذه الوظيفة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
إثيريوم The Surge الرؤية:突破10万TPS与生态统一
إثيريوم可能的未来:The Surge
الارتفاع: الأهداف الرئيسية
يمكن أن يصل إثيريوم في المستقبل إلى أكثر من 100000 TPS من خلال L2؛
الحفاظ على اللامركزية والصلابة لـ L1؛
على الأقل بعض L2 ورثت الخصائص الأساسية لإثيريوم (عدم الثقة، مفتوح، مقاوم للرقابة)؛
إثيريوم يجب أن يشعر كأنه نظام بيئي موحد، وليس 34 سلسلة كتلة مختلفة.
محتوى هذا الفصل
معضلة مثلث القابلية للتوسع
مثلث التوسع هو فكرة تم تقديمها في عام 2017، وتفيد بأن هناك تناقض بين ثلاثة خصائص للبلوك تشين: اللامركزية (بشكل أكثر تحديدًا: انخفاض تكلفة تشغيل العقد)، التوسع (عدد المعاملات المعالجة كبير) والأمان (يحتاج المهاجمون إلى تدمير جزء كبير من العقد في الشبكة لجعل معاملة واحدة تفشل).
من المهم أن نلاحظ أن مفارقة المثلث ليست نظرية، كما أن المنشورات التي تقدم مفارقة المثلث لا تحتوي على إثبات رياضي. لكنها تقدم حجة رياضية استدلالية: إذا كان هناك عقدة صديقة لامركزية (مثل الكمبيوتر المحمول الاستهلاكي) يمكنها التحقق من N معاملة في الثانية، وكان لديك سلسلة يمكنها معالجة k*N معاملة في الثانية، فإن (i) كل معاملة يمكن أن تُرى فقط بواسطة 1/k من العقد، مما يعني أن المهاجم يحتاج فقط إلى تدمير عدد قليل من العقد لإجراء معاملة خبيثة، أو (ii) ستصبح عقدتك قوية بينما لن تكون سلسلتك لامركزية. الغرض من هذه المقالة ليس إثبات أن كسر مفارقة المثلث مستحيل؛ بل يهدف في المقابل إلى إظهار أن كسر المفارقة الثلاثية صعب، ويتطلب الخروج بطريقة ما من إطار التفكير الضمني الذي يتضمنه هذا الجدل.
لسنوات عديدة، ادعت بعض الشبكات عالية الأداء أنها حلت معضلة الثلاثة دون تغيير هيكلها الأساسي، غالبًا من خلال استخدام تقنيات هندسة البرمجيات لتحسين العقد. هذا دائمًا ما يكون مضللًا، حيث أن تشغيل العقد على هذه الشبكات أصعب بكثير من تشغيل العقد على إثيريوم. ستستكشف هذه المقالة لماذا يحدث ذلك، ولماذا لا يمكن توسيع إثيريوم فقط من خلال هندسة البرمجيات الخاصة بعميل L1؟
ومع ذلك، فإن الجمع بين أخذ عينات توفر البيانات و SNARKs يحل بالفعل مفارقة المثلث: حيث يسمح للعميل بالتحقق من توفر كمية معينة من البيانات وصحة عدد معين من خطوات الحساب، مع تنزيل كمية قليلة فقط من البيانات وتنفيذ عدد قليل جدًا من الحسابات. SNARKs لا تتطلب الثقة. إن أخذ عينات توفر البيانات لديه نموذج ثقة دقيق من نوع few-of-N، ولكنه يحتفظ بالخصائص الأساسية للسلسلة غير القابلة للتوسع، حيث حتى هجوم 51% لا يمكنه إجبار الكتل السيئة على قبولها من قبل الشبكة.
طريقة أخرى لحل أزمة الثلاثة هي بنية بلازما، التي تستخدم تقنية ذكية لتحفيز المسؤولية عن مراقبة توفر البيانات على المستخدمين. في الفترة من 2017 إلى 2019، عندما كانت لدينا فقط وسيلة إثبات الاحتيال لتوسيع القدرة الحاسوبية، كانت بلازما محدودة جدًا من حيث التنفيذ الآمن، ولكن مع انتشار SNARKs (إثباتات المعرفة الصفرية القصيرة غير التفاعلية)، أصبحت بنية بلازما أكثر قابلية للتطبيق في مجموعة واسعة من سيناريوهات الاستخدام مقارنةً بالماضي.
التقدم الإضافي في عينة توفر البيانات
ما هي المشكلة التي نعمل على حلها؟
في 13 مارس 2024، عند إطلاق ترقية Dencun، سيكون هناك 3 blobs بحجم حوالي 125 كيلوبايت لكل slot كل 12 ثانية، أو عرض نطاق البيانات المتاحة لكل slot حوالي 375 كيلوبايت. إذا تم نشر بيانات المعاملات مباشرة على السلسلة، فإن تحويل ERC20 سيكون حوالي 180 بايت، لذا فإن الحد الأقصى لعدد المعاملات في الثانية على Rollup هو: 375000 / 12 / 180 = 173.6 TPS
إذا أضفنا calldata (القيمة القصوى النظرية: كل slot 30 مليون Gas / لكل بايت 16 gas = كل slot 1,875,000 بايت)، فإنها ستصبح 607 TPS. باستخدام PeerDAS، قد يزيد عدد blobs إلى 8-16، مما سيوفر 463-926 TPS لـ calldata.
هذا تطوير كبير لـ L1، لكنه ليس كافيًا. نريد المزيد من القابلية للتوسع. هدفنا المتوسط هو 16 ميجابايت لكل فتحة، وإذا تم دمجه مع تحسينات ضغط بيانات Rollup، فسيوفر ~58000 TPS.
ما هو؟ كيف يعمل؟
PeerDAS هو تنفيذ بسيط نسبيًا لـ "1D sampling". في هذا السياق، كل blob هو متعدد حدود (polynomial) من الدرجة 4096 في مجال الأعداد الأولية (prime field) المكون من 253 بت. نحن نبث أجزاء (shares) من المتعدد الحدود، حيث يحتوي كل جزء على 16 قيمة تقييم من 16 نقطة متجاورة من إجمالي 8192 نقطة. من بين هذه الـ 8192 قيمة تقييم، يمكن استعادة أي 4096 منها (وفقًا للمعلمات المقترحة حاليًا: أي 64 من 128 عينة محتملة).
تعمل PeerDAS على جعل كل عميل يستمع إلى عدد قليل من الشبكات الفرعية، حيث تقوم الشبكة الفرعية رقم i ببث العينة رقم i لأي blob، وتطلب blobs الأخرى في الشبكات الفرعية من خلال استعلام نظراء في الشبكة العالمية p2p (الذين سيستمعون إلى الشبكات الفرعية المختلفة). نسخة أكثر تحفظًا هي SubnetDAS التي تستخدم فقط آلية الشبكة الفرعية، دون استعلام إضافي عن طبقة النظراء. الاقتراح الحالي هو أن تستخدم العقد المشاركة في إثبات الحصة SubnetDAS، بينما تستخدم العقد الأخرى (أي العملاء) PeerDAS.
من الناحية النظرية، يمكننا توسيع نطاق "1D sampling" ليكون كبيرًا جدًا: إذا قمنا بزيادة العدد الأقصى من الـ blob إلى 256 (الهدف هو 128)، فسوف نتمكن من الوصول إلى هدف 16 ميجابايت، حيث أن كل عقدة في عينة توفر البيانات تحتوي على 16 عينة * 128 blob * 512 بايت لكل blob لكل عينة = 1 ميجابايت من عرض النطاق الترددي لكل فتحة. هذا بالكاد في نطاق تحملنا: هذا ممكن، لكن هذا يعني أن العملاء ذوي النطاق الترددي المحدود لا يمكنهم أخذ العينات. يمكننا تحسين ذلك إلى حد ما عن طريق تقليل عدد الـ blob وزيادة حجم الـ blob، لكن ذلك سيجعل تكلفة إعادة البناء أعلى.
لذلك، نريد في النهاية أن نخطو خطوة إضافية، وهو إجراء أخذ عينات ثنائية الأبعاد (2D sampling)، وهذه الطريقة لا تقوم فقط بأخذ عينات عشوائية داخل الـ blob، بل تأخذ عينات عشوائية أيضًا بين الـ blobs. باستخدام الخصائص الخطية لالتزام KZG، نقوم بتوسيع مجموعة الـ blobs داخل كتلة من خلال مجموعة جديدة من الـ blobs الافتراضية، هذه الـ blobs الافتراضية ترمز بشكل زائد لنفس المعلومات.
لذلك ، في النهاية نريد أن نذهب خطوة أخرى إلى الأمام ، ونقوم بأخذ عينات ثنائية الأبعاد ، ليس فقط داخل الكتلة ولكن أيضًا لأخذ عينات عشوائية بين الكتل. تُستخدم خصائص الالتزام KZG الخطية لتوسيع مجموعة الكتل داخل كتلة واحدة ، والتي تحتوي على قائمة كتل افتراضية جديدة ترمز بشكل زائد لنفس المعلومات.
! مقال فيتاليك الجديد: مستقبل Ethereum المحتمل ، الطفرة
من المهم جداً أن توسيع الالتزامات الحسابية لا يتطلب وجود blob، لذلك فإن هذه الخطة تعتبر بشكل أساسي صديقة لبناء الكتل الموزعة. يحتاج العقد التي تبني الكتل فعليًا فقط إلى امتلاك التزام blob KZG، ويمكنها الاعتماد على أخذ عينات توافر البيانات (DAS) للتحقق من توافر كتل البيانات. أخذ عينات توافر البيانات أحادي البعد (1D DAS) هو أيضاً بشكل أساسي صديق لبناء الكتل الموزعة.
ماذا يجب أن نفعل بعد؟ وما هي الموازنات المتاحة؟
بعد ذلك يأتي تنفيذ وإطلاق PeerDAS. بعد ذلك، سيتم زيادة عدد ال blob على PeerDAS باستمرار، مع مراقبة الشبكة بعناية وتحسين البرمجيات لضمان الأمان، وهي عملية تدريجية. في الوقت نفسه، نأمل أن تكون هناك المزيد من الأعمال الأكاديمية لتنظيم PeerDAS والإصدارات الأخرى من DAS والتفاعل بينها وبين مسائل الأمان المتعلقة بقواعد اختيار الانقسام.
في مراحل أبعد في المستقبل، نحتاج إلى القيام بمزيد من العمل لتحديد النسخة المثالية من 2D DAS وإثبات خصائصه الأمنية. نأمل أيضًا في النهاية أن نتمكن من الانتقال من KZG إلى بديل آمن كمي ولا يتطلب إعداد موثوق. في الوقت الحالي، لا نعرف بعد أي من الخيارات المحتملة صديقة لبناء الكتل الموزعة. حتى باستخدام تقنية "القوة الغاشمة" المكلفة، حتى باستخدام STARK التكراري لتوليد إثباتات الصلاحية لإعادة بناء الصفوف والأعمدة، لا يكفي تلبية الطلب، لأنه على الرغم من أنه من الناحية الفنية، فإن حجم STARK هو O(log(n) * log(log(n)) هاش (باستخدام STIR)، إلا أن STARK في الواقع يكاد يكون بحجم blob بأكمله.
أعتقد أن المسار الواقعي على المدى الطويل هو:
يرجى ملاحظة أنه حتى إذا قررنا التوسع في التنفيذ مباشرة على طبقة L1، فإن هذا الخيار موجود. وذلك لأنه إذا كانت طبقة L1 ستتعامل مع عدد كبير من معاملات في الثانية (TPS)، فإن كتل L1 ستصبح كبيرة جداً، وسيرغب العميل في الحصول على طريقة فعالة للتحقق من صحتها، وبالتالي سيتعين علينا استخدام تقنيات مماثلة لتقنيات Rollup (مثل ZK-EVM و DAS) في طبقة L1.
كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
إذا تم تحقيق ضغط البيانات، فسيكون هناك انخفاض في الطلب على DAS ثنائي الأبعاد، أو على الأقل سيتم تأجيله، وإذا تم استخدام Plasma على نطاق واسع، فإن الطلب سيتقلص أكثر. كما أن DAS يمثل تحديًا لبروتوكولات وآليات بناء الكتل الموزعة: على الرغم من أن DAS نظريًا صديق للتوزيع، إلا أن هذا في الممارسة العملية يتطلب دمجه مع اقتراح قائمة تضمين الحزم وآلية اختيار الفروع المحيطة بها.
ضغط البيانات
ماذا نحل من مشكلة؟
تستهلك كل معاملة في Rollup مساحة كبيرة من بيانات السلسلة: يتطلب نقل ERC20 حوالي 180 بايت. حتى مع وجود عينات مثالية من توفر البيانات، فإن هذا يحد من قابلية التوسع في بروتوكولات Layer. كل فتحة 16 ميغابايت، نحصل على:
16000000 / 12 / 180 = 7407 TPS
ماذا لو تمكنا من حل مشكلة البسط وليس فقط مشكلة المقام، مما يجعل كل معاملة في كل Rollup تشغل عددًا أقل من البايتات على السلسلة؟
ما هو، وكيف يعمل؟
في رأيي، أفضل تفسير هو هذه الصورة من قبل عامين:
في ضغط بايتات صفرية، يتم استبدال كل سلسلة طويلة من بايتات صفرية بواسطة بايتين، تمثل عدد بايتات الصفر. علاوة على ذلك، استخدمنا خصائص معينة للمعاملات:
تجميع التوقيعات: نحن نتنقل من توقيع ECDSA إلى توقيع BLS، حيث تتمثل خاصية توقيع BLS في إمكانية دمج عدة توقيعات في توقيع واحد فقط، يمكن أن يثبت صحة جميع التوقيعات الأصلية. في طبقة L1، نظرًا لأن تكلفة حساب التحقق لا تزال مرتفعة حتى عند التجميع، فلا يتم النظر في استخدام توقيع BLS. ولكن في بيئة L2 التي تعاني من ندرة البيانات، فإن استخدام توقيع BLS له معنى. توفر خاصية التجميع في ERC-4337 مسارًا لتحقيق هذه الوظيفة.