تُشير مفارقة مثلث القابلية للتوسع إلى وجود تناقض بين الخصائص الثلاث للبلوكشين، وهي اللامركزية والقابلية للتوسع والأمان. إنها ليست نظرية صارمة، بل تُقدم حجة رياضية استدلالية: إذا كان لدى عقدة صديقة للامركزية القدرة على التحقق من N معاملة في الثانية، وكان لديك سلسلة قادرة على معالجة k*N معاملة في الثانية، فإن إما أن كل معاملة يمكن أن تُرى فقط بواسطة 1/k من العقد، مما يعني أن المهاجم يحتاج فقط إلى تدمير عدد قليل من العقد لتنفيذ معاملة ضارة؛ أو ستصبح عقدتك قوية، ولن تكون سلسلتك لامركزية.
على مدار السنوات، ادعت بعض السلاسل عالية الأداء أنها حلت التناقض الثلاثي دون تغيير الهيكل الأساسي، عادةً من خلال استخدام تقنيات هندسة البرمجيات لتحسين العقد. وهذا غالبًا ما يكون مضللًا، إذ أن تشغيل العقد على هذه السلاسل أصعب بكثير من تشغيل العقد على إثيريوم.
ومع ذلك، فإن دمج عينة توفر البيانات مع SNARKs يحل فعلاً معضلة المثلث: حيث يسمح للعملاء بالتحقق من توفر كمية معينة من البيانات وعدد معين من خطوات الحساب بشكل صحيح دون الحاجة إلى تحميل كمية كبيرة من البيانات أو إجراء الكثير من العمليات الحسابية. SNARKs لا تتطلب الثقة. عينة توفر البيانات لها نموذج ثقة دقيق من نوع few-of-N، لكنها تحتفظ بالخصائص الأساسية للسلاسل غير القابلة للتوسع، أي أنه حتى هجوم بنسبة 51% لا يمكنه إجبار الكتل السيئة على القبول من قبل الشبكة.
طريقة أخرى لحل معضلة الثلاثة هي بنية Plasma، التي تستخدم تقنيات بارعة لتحفيز المستخدمين على تحمل مسؤولية مراقبة توفر البيانات. مع انتشار SNARKs، أصبحت بنية Plasma أكثر قابلية للتطبيق على مجموعة واسعة من السيناريوهات مقارنةً بالماضي.
تقدم إضافي في عينة توفر البيانات
ماذا نحن نحل من مشكلة؟
في 13 مارس 2024، عندما يتم إطلاق ترقية Dencun، سيكون هناك 3 كتل بحجم حوالي 125 كيلوبايت لكل شريحة في سلسلة الكتل إيثريوم كل 12 ثانية، أو عرض نطاق البيانات المتاح لكل شريحة حوالي 375 كيلوبايت. إذا تم نشر بيانات المعاملات مباشرة على السلسلة، فإن تحويلات ERC20 ستكون حوالي 180 بايت، وبالتالي فإن الحد الأقصى لمعدل المعاملات في إيثريوم Rollup هو: 375000 / 12 / 180 = 173.6 TPS
إذا أضفنا calldata لإثيريوم، فإن ذلك يصبح 607 TPS. باستخدام PeerDAS، قد يزيد عدد الـ blob إلى 8-16، مما سيقدم 463-926 TPS لـ calldata.
هذا تحسين كبير لـ إثيريوم L1، لكنه ليس كافيًا. نريد المزيد من القابلية للتوسع. هدفنا المتوسط هو 16 ميغابايت لكل شريحة، وإذا تم دمجه مع تحسينات ضغط بيانات Rollup، سيؤدي ذلك إلى ~58000 TPS.
ماذا هو؟ كيف يعمل؟
PeerDAS هو تنفيذ بسيط نسبيًا لـ "1D sampling". في إثيريوم، كل blob هو كثير حدود من الدرجة 4096 في حقل الأعداد الأولية المكون من 253 بت. نقوم ببث حصص الكثيرة، حيث تحتوي كل حصة على 16 قيمة تقييم من 16 نقطة متجاورة من أصل 8192 نقطة. من بين هذه الـ 8192 قيمة تقييم، يمكن استعادة أي 4096 blob.
تعمل PeerDAS على جعل كل عميل يستمع إلى عدد قليل من الشبكات الفرعية، حيث تقوم الشبكة الفرعية i ببث العينة i لأي blob، وتطلب من الأقران في الشبكة العالمية p2p للحصول على blobs الأخرى التي تحتاجها من الشبكات الفرعية. النسخة الأكثر تحفظًا SubnetDAS تستخدم فقط آلية الشبكات الفرعية، دون الاستفسار الإضافي عن طبقة الأقران. الاقتراح الحالي هو السماح للعقد المشاركة في إثبات الحصة باستخدام SubnetDAS، بينما تستخدم العقد الأخرى PeerDAS.
من الناحية النظرية، يمكننا توسيع نطاق "1D sampling" بشكل كبير: إذا قمنا بزيادة العدد الأقصى من blobs إلى 256، فإننا سنصل إلى الهدف البالغ 16 ميغابايت، حيث أن كل عقدة في عينة توفر البيانات تحتوي على 16 عينة * 128 blob * 512 بايت لكل blob لكل عينة = 1 ميغابايت من عرض النطاق الترددي لكل وحدة زمنية. هذا بالكاد يقع ضمن نطاق تحمّلنا: إنه ممكن، لكن هذا يعني أن العملاء ذوي النطاق الترددي المحدود لا يمكنهم أخذ عينات. يمكننا تحسين ذلك إلى حد ما من خلال تقليل عدد blobs وزيادة حجم blobs، لكن هذا سيجعل تكلفة إعادة البناء أعلى.
لذلك، نريد في النهاية أن نخطو خطوة أخرى، ونقوم بأخذ عينات ثنائية الأبعاد، هذه الطريقة لا تقوم فقط بأخذ عينات عشوائية داخل الكتلة، بل أيضًا بين الكتل. من خلال استخدام خاصية الالتزام KZG الخطية، نقوم بتوسيع مجموعة الكتل في كتلة واحدة من خلال مجموعة جديدة من الكتل الافتراضية، التي تشفر بشكل زائد نفس المعلومات.
من المهم جدًا أن توسيع الالتزام لا يتطلب وجود blob، وبالتالي فإن هذه الخطة تعتبر في الأساس صديقة لبناء الكتل الموزعة. nodes التي تقوم ببناء الكتل فعلياً تحتاج فقط لامتلاك التزام blob KZG، ويمكنها الاعتماد على أخذ عينات توافر البيانات للتحقق من توافر كتل البيانات. أخذ عينات توافر البيانات أحادية البعد تعتبر أيضًا صديقة لبناء الكتل الموزعة.
ماذا يجب أن نفعل بعد؟ وما هي الموازنات الموجودة؟
الخطوة التالية هي إكمال تنفيذ وإطلاق PeerDAS. بعد ذلك، سنقوم بزيادة عدد البلوبيات على PeerDAS باستمرار، مع مراقبة الشبكة بدقة وتحسين البرمجيات لضمان الأمان، وهي عملية تدريجية. في الوقت نفسه، نأمل أن يكون هناك المزيد من الأعمال الأكاديمية لتنظيم PeerDAS والإصدارات الأخرى من DAS وتفاعلاتها مع مسائل الأمان المتعلقة بقواعد اختيار الانقسام.
في مراحل أبعد في المستقبل، نحتاج إلى القيام بمزيد من العمل لتحديد النسخة المثالية من 2D DAS، وإثبات خصائصها الأمنية. نأمل أيضًا في النهاية أن نتمكن من الانتقال من KZG إلى بديل آمن كمي ولا يتطلب إعداد موثوق. في الوقت الحالي، لا نعرف بعد ما هي الخيارات المرشحة التي تكون ودية لبناء الكتل الموزعة. حتى مع استخدام تقنية "القوة الغاشمة" المكلفة، أي استخدام STARK المتكرر لتوليد إثباتات الصلاحية لإعادة بناء الصفوف والأعمدة، لا يكفي لتلبية الطلب، لأنه على الرغم من أنه من الناحية التقنية، فإن حجم STARK هو O(log(n) * log(log(n)) قيمة هاش، إلا أن STARK في الواقع يكاد يكون بحجم كامل blob.
أعتقد أن المسار الواقعي على المدى الطويل هو:
تنفيذ DAS ثنائي الأبعاد المثالي;
الاستمرار في استخدام 1D DAS، التضحية بكفاءة عرض النطاق الترددي للعينة، من أجل البساطة والموثوقية قبول حد أدنى من البيانات.
التخلي عن DA، وقبول Plasma بالكامل كهيكل Layer2 الرئيسي الذي نركز عليه.
يرجى ملاحظة أنه حتى إذا قررنا التوسع مباشرة في طبقة L1، فإن هذا الخيار موجود. وذلك لأنه إذا كانت طبقة L1 ستتعامل مع عدد كبير من TPS، ستصبح كتل L1 كبيرة جداً، وسيرغب العملاء في وجود طريقة فعالة للتحقق من صحتها، وبالتالي سيتعين علينا استخدام نفس التقنية المستخدمة في Rollup في طبقة L1.
كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟
إذا تم تحقيق ضغط البيانات، فإن الطلب على 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 ETH كـ 250,000,000,000,000,000 wei. كما أن الحد الأقصى للرسوم الأساسية ورسوم الأولوية مشابهة. لذلك، يمكننا استخدام تنسيق عائم عشري مخصص لتمثيل معظم قيم العملات.
ماذا يجب أن نفعل بعد؟ وما هي الموازنات الموجودة؟
الشيء الرئيسي الذي يجب القيام به بعد ذلك هو تنفيذ الاقتراح المذكور أعلاه. تشمل الموازنة الرئيسية:
1، يتطلب التبديل إلى توقيع BLS جهدًا كبيرًا، وسيقلل من التوافق مع شرائح الأجهزة الموثوقة التي يمكن أن تعزز الأمان. يمكن استخدام تغليف ZK-SNARK لخطط التوقيع الأخرى كبديل لذلك.
2، ضغط ديناميكي ( على سبيل المثال، استبدال العناوين بـ pointers ) سيجعل كود العميل أكثر تعقيدًا.
3، نشر الفروق في الحالة على السلسلة بدلاً من المعاملات، سيقلل من إمكانية التدقيق، مما يجعل العديد من البرمجيات ( مثل متصفح الكتل ) غير قابلة للعمل.
كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
اعتماد ERC-4337 وإدراج بعض محتوياته في L2 EVM يمكن أن يسرع بشكل كبير من نشر تقنية التجميع. وضع بعض محتويات ERC-4337 على L1 يمكن أن يسرع من نشره على L2.
بلازما عامة
ماذا نقوم بحلّه؟
حتى مع استخدام 16 ميغابايت من blob وضغط البيانات، فإن 58,000 TPS قد لا تكون كافية تمامًا لتلبية احتياجات المدفوعات الاستهلاكية أو الشبكات الاجتماعية اللامركزية أو غيرها من المجالات ذات النطاق الترددي العالي، خاصة عندما نبدأ في النظر في عوامل الخصوصية، مما قد يؤدي إلى تقليل قابلية التوسع بمقدار 3-8 مرات. بالنسبة لسيناريوهات التطبيقات ذات الحجم العالي والمعاملات ذات القيمة المنخفضة، فإن أحد الخيارات الحالية هو استخدام Validium، الذي يحتفظ بالبيانات خارج السلسلة، ويتبنى نموذج أمان مثيرًا للاهتمام: لا يمكن للمشغلين سرقة أموال المستخدمين، ولكن قد يتمكنون من تجميد أموال جميع المستخدمين بشكل مؤقت أو دائم. ولكن يمكننا أن نفعل ما هو أفضل.
ما هو ، كيف يعمل؟
Plasma هو حل للتوسع، يتعلق بوجود مشغل يقوم بنشر الكتل خارج السلسلة، ووضع جذر Merkle لهذه الكتل على السلسلة. بالنسبة لكل كتلة، سيرسل المشغل فرع Merkle لكل مستخدم لإثبات ما حدث من تغييرات على أصول المستخدم أو عدم حدوث أي تغييرات. يمكن للمستخدمين استرداد أصولهم من خلال تقديم فرع Merkle. من المهم أن هذا الفرع لا يجب أن يكون له جذر بأحدث حالة. لذلك، حتى في حالة وجود مشاكل في توفر البيانات، لا يزال بإمكان المستخدمين استرداد أصولهم من خلال استرداد أحدث حالة متاحة. إذا قدم المستخدم فرعًا غير صالح، يمكن تحديد الملكية القانونية للأصول من خلال آلية التحدي على السلسلة.
إصدارات بلازما المبكرة كانت قادرة فقط على معالجة حالات الدفع، ولم تكن قادرة على التوسع بفعالية. ومع ذلك، إذا طلبنا التحقق من كل جذر باستخدام SNARK، فإن بلازما ستصبح أقوى بكثير. يمكن تبسيط كل لعبة تحدي بشكل كبير،
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 6
أعجبني
6
6
إعادة النشر
مشاركة
تعليق
0/400
AltcoinMarathoner
· 08-13 13:35
كنت في العملات المشفرة منذ 2016... التوسع ليس سباقا سريعا، إنه ماراثون فائق. إيث لا تزال متصدرة المجموعة fr
شاهد النسخة الأصليةرد0
BoredApeResistance
· 08-13 07:25
متى ستصبح الطبقة الثانية حقيقة؟ آي.
شاهد النسخة الأصليةرد0
NeverVoteOnDAO
· 08-10 19:10
مرة أخرى يقولون هذه الكلمات الفارغة عقدة لا تعمل
شاهد النسخة الأصليةرد0
FancyResearchLab
· 08-10 18:58
القيمة الأكاديمية في أقصى ارتفاع، ذهبت لتجربة صغيرة على الحساب
شاهد النسخة الأصليةرد0
BlockchainThinkTank
· 08-10 18:51
بغض النظر عن مدى البذخ في الكلام، فإن البيانات لا تكذب أبداً، يُنصح الحمقى بمراقبة التغيرات بهدوء
Ethereum: الطفرة: دفع حدود قابلية التوسع
إثيريوم المستقبل: The Surge
تناقض مثلث القابلية للتوسع
تُشير مفارقة مثلث القابلية للتوسع إلى وجود تناقض بين الخصائص الثلاث للبلوكشين، وهي اللامركزية والقابلية للتوسع والأمان. إنها ليست نظرية صارمة، بل تُقدم حجة رياضية استدلالية: إذا كان لدى عقدة صديقة للامركزية القدرة على التحقق من N معاملة في الثانية، وكان لديك سلسلة قادرة على معالجة k*N معاملة في الثانية، فإن إما أن كل معاملة يمكن أن تُرى فقط بواسطة 1/k من العقد، مما يعني أن المهاجم يحتاج فقط إلى تدمير عدد قليل من العقد لتنفيذ معاملة ضارة؛ أو ستصبح عقدتك قوية، ولن تكون سلسلتك لامركزية.
على مدار السنوات، ادعت بعض السلاسل عالية الأداء أنها حلت التناقض الثلاثي دون تغيير الهيكل الأساسي، عادةً من خلال استخدام تقنيات هندسة البرمجيات لتحسين العقد. وهذا غالبًا ما يكون مضللًا، إذ أن تشغيل العقد على هذه السلاسل أصعب بكثير من تشغيل العقد على إثيريوم.
ومع ذلك، فإن دمج عينة توفر البيانات مع SNARKs يحل فعلاً معضلة المثلث: حيث يسمح للعملاء بالتحقق من توفر كمية معينة من البيانات وعدد معين من خطوات الحساب بشكل صحيح دون الحاجة إلى تحميل كمية كبيرة من البيانات أو إجراء الكثير من العمليات الحسابية. SNARKs لا تتطلب الثقة. عينة توفر البيانات لها نموذج ثقة دقيق من نوع few-of-N، لكنها تحتفظ بالخصائص الأساسية للسلاسل غير القابلة للتوسع، أي أنه حتى هجوم بنسبة 51% لا يمكنه إجبار الكتل السيئة على القبول من قبل الشبكة.
طريقة أخرى لحل معضلة الثلاثة هي بنية Plasma، التي تستخدم تقنيات بارعة لتحفيز المستخدمين على تحمل مسؤولية مراقبة توفر البيانات. مع انتشار SNARKs، أصبحت بنية Plasma أكثر قابلية للتطبيق على مجموعة واسعة من السيناريوهات مقارنةً بالماضي.
تقدم إضافي في عينة توفر البيانات
ماذا نحن نحل من مشكلة؟
في 13 مارس 2024، عندما يتم إطلاق ترقية Dencun، سيكون هناك 3 كتل بحجم حوالي 125 كيلوبايت لكل شريحة في سلسلة الكتل إيثريوم كل 12 ثانية، أو عرض نطاق البيانات المتاح لكل شريحة حوالي 375 كيلوبايت. إذا تم نشر بيانات المعاملات مباشرة على السلسلة، فإن تحويلات ERC20 ستكون حوالي 180 بايت، وبالتالي فإن الحد الأقصى لمعدل المعاملات في إيثريوم Rollup هو: 375000 / 12 / 180 = 173.6 TPS
إذا أضفنا calldata لإثيريوم، فإن ذلك يصبح 607 TPS. باستخدام PeerDAS، قد يزيد عدد الـ blob إلى 8-16، مما سيقدم 463-926 TPS لـ calldata.
هذا تحسين كبير لـ إثيريوم L1، لكنه ليس كافيًا. نريد المزيد من القابلية للتوسع. هدفنا المتوسط هو 16 ميغابايت لكل شريحة، وإذا تم دمجه مع تحسينات ضغط بيانات Rollup، سيؤدي ذلك إلى ~58000 TPS.
ماذا هو؟ كيف يعمل؟
PeerDAS هو تنفيذ بسيط نسبيًا لـ "1D sampling". في إثيريوم، كل blob هو كثير حدود من الدرجة 4096 في حقل الأعداد الأولية المكون من 253 بت. نقوم ببث حصص الكثيرة، حيث تحتوي كل حصة على 16 قيمة تقييم من 16 نقطة متجاورة من أصل 8192 نقطة. من بين هذه الـ 8192 قيمة تقييم، يمكن استعادة أي 4096 blob.
تعمل PeerDAS على جعل كل عميل يستمع إلى عدد قليل من الشبكات الفرعية، حيث تقوم الشبكة الفرعية i ببث العينة i لأي blob، وتطلب من الأقران في الشبكة العالمية p2p للحصول على blobs الأخرى التي تحتاجها من الشبكات الفرعية. النسخة الأكثر تحفظًا SubnetDAS تستخدم فقط آلية الشبكات الفرعية، دون الاستفسار الإضافي عن طبقة الأقران. الاقتراح الحالي هو السماح للعقد المشاركة في إثبات الحصة باستخدام SubnetDAS، بينما تستخدم العقد الأخرى PeerDAS.
من الناحية النظرية، يمكننا توسيع نطاق "1D sampling" بشكل كبير: إذا قمنا بزيادة العدد الأقصى من blobs إلى 256، فإننا سنصل إلى الهدف البالغ 16 ميغابايت، حيث أن كل عقدة في عينة توفر البيانات تحتوي على 16 عينة * 128 blob * 512 بايت لكل blob لكل عينة = 1 ميغابايت من عرض النطاق الترددي لكل وحدة زمنية. هذا بالكاد يقع ضمن نطاق تحمّلنا: إنه ممكن، لكن هذا يعني أن العملاء ذوي النطاق الترددي المحدود لا يمكنهم أخذ عينات. يمكننا تحسين ذلك إلى حد ما من خلال تقليل عدد blobs وزيادة حجم blobs، لكن هذا سيجعل تكلفة إعادة البناء أعلى.
لذلك، نريد في النهاية أن نخطو خطوة أخرى، ونقوم بأخذ عينات ثنائية الأبعاد، هذه الطريقة لا تقوم فقط بأخذ عينات عشوائية داخل الكتلة، بل أيضًا بين الكتل. من خلال استخدام خاصية الالتزام KZG الخطية، نقوم بتوسيع مجموعة الكتل في كتلة واحدة من خلال مجموعة جديدة من الكتل الافتراضية، التي تشفر بشكل زائد نفس المعلومات.
من المهم جدًا أن توسيع الالتزام لا يتطلب وجود blob، وبالتالي فإن هذه الخطة تعتبر في الأساس صديقة لبناء الكتل الموزعة. nodes التي تقوم ببناء الكتل فعلياً تحتاج فقط لامتلاك التزام blob KZG، ويمكنها الاعتماد على أخذ عينات توافر البيانات للتحقق من توافر كتل البيانات. أخذ عينات توافر البيانات أحادية البعد تعتبر أيضًا صديقة لبناء الكتل الموزعة.
ماذا يجب أن نفعل بعد؟ وما هي الموازنات الموجودة؟
الخطوة التالية هي إكمال تنفيذ وإطلاق PeerDAS. بعد ذلك، سنقوم بزيادة عدد البلوبيات على PeerDAS باستمرار، مع مراقبة الشبكة بدقة وتحسين البرمجيات لضمان الأمان، وهي عملية تدريجية. في الوقت نفسه، نأمل أن يكون هناك المزيد من الأعمال الأكاديمية لتنظيم PeerDAS والإصدارات الأخرى من DAS وتفاعلاتها مع مسائل الأمان المتعلقة بقواعد اختيار الانقسام.
في مراحل أبعد في المستقبل، نحتاج إلى القيام بمزيد من العمل لتحديد النسخة المثالية من 2D DAS، وإثبات خصائصها الأمنية. نأمل أيضًا في النهاية أن نتمكن من الانتقال من KZG إلى بديل آمن كمي ولا يتطلب إعداد موثوق. في الوقت الحالي، لا نعرف بعد ما هي الخيارات المرشحة التي تكون ودية لبناء الكتل الموزعة. حتى مع استخدام تقنية "القوة الغاشمة" المكلفة، أي استخدام STARK المتكرر لتوليد إثباتات الصلاحية لإعادة بناء الصفوف والأعمدة، لا يكفي لتلبية الطلب، لأنه على الرغم من أنه من الناحية التقنية، فإن حجم STARK هو O(log(n) * log(log(n)) قيمة هاش، إلا أن STARK في الواقع يكاد يكون بحجم كامل blob.
أعتقد أن المسار الواقعي على المدى الطويل هو:
يرجى ملاحظة أنه حتى إذا قررنا التوسع مباشرة في طبقة L1، فإن هذا الخيار موجود. وذلك لأنه إذا كانت طبقة L1 ستتعامل مع عدد كبير من TPS، ستصبح كتل L1 كبيرة جداً، وسيرغب العملاء في وجود طريقة فعالة للتحقق من صحتها، وبالتالي سيتعين علينا استخدام نفس التقنية المستخدمة في Rollup في طبقة L1.
كيف تتفاعل مع أجزاء أخرى من خريطة الطريق؟
إذا تم تحقيق ضغط البيانات، فإن الطلب على 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 ETH كـ 250,000,000,000,000,000 wei. كما أن الحد الأقصى للرسوم الأساسية ورسوم الأولوية مشابهة. لذلك، يمكننا استخدام تنسيق عائم عشري مخصص لتمثيل معظم قيم العملات.
ماذا يجب أن نفعل بعد؟ وما هي الموازنات الموجودة؟
الشيء الرئيسي الذي يجب القيام به بعد ذلك هو تنفيذ الاقتراح المذكور أعلاه. تشمل الموازنة الرئيسية:
1، يتطلب التبديل إلى توقيع BLS جهدًا كبيرًا، وسيقلل من التوافق مع شرائح الأجهزة الموثوقة التي يمكن أن تعزز الأمان. يمكن استخدام تغليف ZK-SNARK لخطط التوقيع الأخرى كبديل لذلك.
2، ضغط ديناميكي ( على سبيل المثال، استبدال العناوين بـ pointers ) سيجعل كود العميل أكثر تعقيدًا.
3، نشر الفروق في الحالة على السلسلة بدلاً من المعاملات، سيقلل من إمكانية التدقيق، مما يجعل العديد من البرمجيات ( مثل متصفح الكتل ) غير قابلة للعمل.
كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟
اعتماد ERC-4337 وإدراج بعض محتوياته في L2 EVM يمكن أن يسرع بشكل كبير من نشر تقنية التجميع. وضع بعض محتويات ERC-4337 على L1 يمكن أن يسرع من نشره على L2.
بلازما عامة
ماذا نقوم بحلّه؟
حتى مع استخدام 16 ميغابايت من blob وضغط البيانات، فإن 58,000 TPS قد لا تكون كافية تمامًا لتلبية احتياجات المدفوعات الاستهلاكية أو الشبكات الاجتماعية اللامركزية أو غيرها من المجالات ذات النطاق الترددي العالي، خاصة عندما نبدأ في النظر في عوامل الخصوصية، مما قد يؤدي إلى تقليل قابلية التوسع بمقدار 3-8 مرات. بالنسبة لسيناريوهات التطبيقات ذات الحجم العالي والمعاملات ذات القيمة المنخفضة، فإن أحد الخيارات الحالية هو استخدام Validium، الذي يحتفظ بالبيانات خارج السلسلة، ويتبنى نموذج أمان مثيرًا للاهتمام: لا يمكن للمشغلين سرقة أموال المستخدمين، ولكن قد يتمكنون من تجميد أموال جميع المستخدمين بشكل مؤقت أو دائم. ولكن يمكننا أن نفعل ما هو أفضل.
ما هو ، كيف يعمل؟
Plasma هو حل للتوسع، يتعلق بوجود مشغل يقوم بنشر الكتل خارج السلسلة، ووضع جذر Merkle لهذه الكتل على السلسلة. بالنسبة لكل كتلة، سيرسل المشغل فرع Merkle لكل مستخدم لإثبات ما حدث من تغييرات على أصول المستخدم أو عدم حدوث أي تغييرات. يمكن للمستخدمين استرداد أصولهم من خلال تقديم فرع Merkle. من المهم أن هذا الفرع لا يجب أن يكون له جذر بأحدث حالة. لذلك، حتى في حالة وجود مشاكل في توفر البيانات، لا يزال بإمكان المستخدمين استرداد أصولهم من خلال استرداد أحدث حالة متاحة. إذا قدم المستخدم فرعًا غير صالح، يمكن تحديد الملكية القانونية للأصول من خلال آلية التحدي على السلسلة.
إصدارات بلازما المبكرة كانت قادرة فقط على معالجة حالات الدفع، ولم تكن قادرة على التوسع بفعالية. ومع ذلك، إذا طلبنا التحقق من كل جذر باستخدام SNARK، فإن بلازما ستصبح أقوى بكثير. يمكن تبسيط كل لعبة تحدي بشكل كبير،