القابلية للتوسع والمقايضات: كيف تسعى Polkadot لتحقيق التوازن في نظام Web3 البيئي
في عصر تسعى فيه تقنية البلوكشين لتحقيق كفاءة أعلى، بدأت مشكلة رئيسية بالظهور: كيف يمكن تحسين أداء النظام دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام Web3، فإن النظام الأسرع إذا تم بناؤه على أساس التضحية بالثقة والأمان، غالبًا ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
هل ضحت Polkadot كدافع رئيسي لتوسيع Web3 ببعض الأمور في سعيها لتحقيق أهداف عالية الإنتاجية ومنخفضة الكمون؟ هل قدم نموذج rollup تنازلات في اللامركزية أو الأمان أو التوافق الشبكي؟ سيتناول هذا المقال هذه الأسئلة، ويحلل بعمق التنازلات والموازنة التي قامت بها Polkadot في تصميم التوسيع، ويقارنها بحلول سلاسل الكتل الرئيسية الأخرى، مستكشفاً الخيارات المختلفة التي اتخذتها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن بين المرونة واللامركزية
تعتمد بنية بولكادوت على شبكة من المدققين وسلسلة إعادة مركزية، هل من الممكن أن يؤدي ذلك إلى تقديم مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على ميزاتها اللامركزية؟
تعتمد عملية تشغيل Rollup على مُرتب مُتصل بسلسلة الوسيط، حيث تستخدم الاتصالات آلية تُسمى بروتوكول الجمع. لا يتطلب هذا البروتوكول أي إذن أو ثقة، ويمكن لأي شخص لديه اتصال بالشبكة استخدامه، لربط عدد قليل من عقد سلسلة الوسيط وتقديم طلبات تحويل حالة Rollup. ستتم معالجة هذه الطلبات من خلال أحد نواة سلسلة الوسيط، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة Rollup.
التوازن في التوسع العمودي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم ، اكتشفنا أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة معينة ، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة التتابع غير مصرح به وموثوق به، يمكن لأي شخص تقديم الكتل إلى أي نواة مخصصة للـrollup للتحقق. قد يستغل المهاجمون هذه النقطة، من خلال تقديم كتل شرعية تم التحقق منها مسبقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي إنتاجية وكفاءة الـrollup.
يهدف Polkadot إلى الحفاظ على مرونة rollup واستخدام موارد سلسلة الترحيل بشكل فعال دون التأثير على الخصائص الأساسية للنظام.
هل Sequencer موثوق به؟
طريقة بسيطة لحل المشكلة هي تعيين البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو الثقة بشكل افتراضي في المنظمين بحيث لا يتصرفون بسوء، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة بشأن sequencer، لأننا بحاجة إلى الحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يتمكن أي شخص من استخدام بروتوكول collator لتقديم طلبات التحويل الحالة للrollup.
Polkadot: حل لا يتنازل
الخيار النهائي الذي اختارته Polkadot هو: ترك المشكلة بالكامل لحلها بواسطة دالة تحويل الحالة للـ rollup (Runtime). تعتبر Runtime المصدر الوحيد الموثوق لجميع معلومات التوافق، لذلك يجب أن يتم الإعلان بوضوح في المخرجات عن أي نواة Polkadot يجب أن يتم تنفيذ التحقق عليها.
هذا التصميم يحقق ضمانات مزدوجة من المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل الحالة للـ rollup في عملية الاستخدام، وتضمن بروتوكول الاقتصاد التشفيري ELVES صحة توزيع core.
قبل كتابة أي بيانات على طبقة توفر البيانات (DA) الخاصة بـ Polkadot في كتل rollup، ستقوم مجموعة مكونة من حوالي 5 مدققين بالتحقق من صحتها أولاً. يتلقون الإيصالات المرشحة والأدلة على الصحة المقدمة من مُرتب، والتي تحتوي على كتل rollup والأدلة التخزينية المقابلة. ستتم معالجة هذه المعلومات بواسطة دالة التحقق في السلاسل المتوازية، والتي سيعيد تنفيذها المدققون على سلسلة الترحيل.
تتضمن نتيجة التحقق محدد core، لتحديد أي core يجب التحقق من الكتلة عليه. سيتحقق المصدق من ما إذا كان هذا الفهرس متطابقًا مع core الذي يتحمل مسؤوليته؛ إذا لم يكن متطابقًا، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الإذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core، يبقى النظام مرنًا.
الأمان
في سعيها لتحقيق القابلية للتوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين أمان الـ rollup بواسطة سلسلة التتابع، حيث يكفي وجود منظم أمين للحفاظ على البقاء.
بفضل بروتوكول ELVES، تقوم Polkadot بتوسيع أمانها بشكل كامل إلى جميع rollups، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن لـ rollup الخاص بـ Polkadot تحقيق توسع حقيقي دون التضحية بالأمان.
قابلية الاستخدام
لن يقيّد التوسع المرن قابلية برمجة rollup. يدعم نموذج rollup الخاص بـ Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يكتمل في غضون ثانيتين. بفضل التوسع المرن، تم تعزيز إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوان، ولكن نوع الحسابات لا يتأثر.
تعقيد
من المؤكد أن زيادة السعة وتقليل التأخير يجلبان تعقيدًا، وهذه هي الطريقة الوحيدة المقبولة في تصميم الأنظمة.
يمكن أن يقوم Rollup بضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليهم تلبية بعض متطلبات RFC103 للتكيف مع سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجية إدارة الموارد للـ rollup، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عددًا ثابتًا من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في mempool العقدة؛
استراتيجيات الأتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمات coretime مسبقًا لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار زادت بشكل ملحوظ.
التفاعل بين الأنظمة
تدعم بولكادوت التوافق بين rollups المختلفة، ولن تؤثر التوسع المرن على قدرة نقل الرسائل.
تتم اتصالات الرسائل عبر rollup بواسطة طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصالات لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، حيث سيكون سلسلة الترحيل هي واجهة التحكم بدلاً من واجهة البيانات. ستعمل هذه الترقية على تحسين قدرة الاتصال بين rollups مع توسيع مرونة، مما يعزز القدرة الرأسية للنظام.
ما هي التنازلات التي قدمتها البروتوكولات الأخرى؟
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لبولكادوت منخفضة، فإن أدائهم لا يزال غير مرضٍ.
سولانا
لا تستخدم سولانا هيكل تقسيم بولكادوت أو إيثريوم، بل تعتمد على هيكل أحادي الطبقة عالي الإنتاجية لتحقيق قابلية التوسع، بالاعتماد على إثبات التاريخ (PoH) ومعالجة مركزية متوازية وآلية توافق قائمة على القيادة، ويصل TPS النظري إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل فترة (حوالي يومين أو 432,000 فتحة) ، يتم تخصيص الفتحات بناءً على كمية الرهانات؛
كلما زادت الحصة، زادت التوزيعات. على سبيل المثال، سيحصل المدقق الذي يراهن بنسبة 1% على حوالي 1% من فرصة إنشاء الكتل؛
جميع المُعدّنين يُعلن عنهم مسبقًا، مما يزيد من خطر تعرض الشبكة لهجمات DDoS موجهة، والانقطاع المتكرر.
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زاد عدد العقد المرهونة، زادت فرصها في إنتاج الكتل، بينما تكاد تكون الفرص المتاحة للعقد الصغيرة معدومة، مما يزيد من حدة المركزية ويزيد من خطر تعطل النظام بعد التعرض للهجوم.
تضحي سولانا باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.
طن
يزعم مشروع blockchain معين أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، لكن هذا الرقم تحقق في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف شبكة وأجهزة مثالية. بينما وصلت Polkadot إلى 128K TPS على شبكة عامة لامركزية.
آلية إجماع هذا المشروع تحتوي على ثغرات أمنية: هوية عقد التحقق من الشظايا قد تُكشف مسبقًا. كما أوضح الورقة البيضاء أن هذا قد يحسن عرض النطاق الترددي، لكنه قد يُستغل بشكل ضار. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة تمامًا على شظية معينة، أو منع المدققين المخلصين من خلال هجمات DDoS، مما يتيح لهم تعديل الحالة.
بالمقارنة، يتم توزيع المدققين في Polkadot بشكل عشوائي وكشفهم بعد تأخير، مما يجعل المهاجمين غير قادرين على معرفة هوية المدققين مسبقًا، ويجب عليهم المراهنة على السيطرة الكاملة للنجاح. طالما أن هناك مدققًا صادقًا واحدًا يثير النزاع، ستفشل الهجمة وستؤدي إلى خسارة المهاجم لمبلغ الرهانات.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS) وC-Chain (العقود الذكية، ~100-200 TPS) وP-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكات الفرعية بحرية، ويمكن أن تضع الشبكات الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشترك جميع rollups في ضمان أمان موحد؛ بينما لا توفر الشبكات الفرعية في Avalanche ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا بالكامل. إذا كنت ترغب في تعزيز الأمان، فلا بد من التنازل عن الأداء، ومن الصعب تقديم التزامات أمان محددة.
إيثريوم
استراتيجية التوسع في الإيثيريوم تعتمد على الرهان على قابلية التوسع في طبقة rollup، بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، فإن معظم عمليات التكديس التفاؤلية (Optimistic rollup) مركزية (بعضها يحتوي حتى على sequencer واحد فقط)، مما يؤدي إلى مشاكل مثل نقص الأمان، والعزلة عن بعضها البعض، وزيادة التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادة ما تستغرق عدة أيام).
زك رول اب
تواجه تطبيقات ZK rollup قيودًا بسبب كمية البيانات التي يمكن معالجتها في كل معاملة. تتطلب عملية توليد إثباتات المعرفة الصفرية موارد حسابية عالية جدًا، وآلية "الفائز يأخذ كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup عدد المعاملات في كل دفعة، مما قد يتسبب في ازدحام الشبكة وزيادة رسوم الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القابلة للتطوير Turing هي حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد الرقمي الأساسي لـ Polkadot.
بالإضافة إلى ذلك، فإن مشكلة توفر بيانات ZK rollup ستزيد من عيوبها. لضمان أن يتمكن أي شخص من التحقق من المعاملات، لا يزال يتعين تقديم بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع بولكادوت الطريق الذي يستبدل فيه المركزية بالأداء، أو الثقة المسبقة بالكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التصميم المرن للتوسع، والبروتوكولات غير المصرح بها، وطبقة الأمان الموحدة، وآلية إدارة الموارد المرنة.
في سعيها لتحقيق تطبيقات على نطاق أوسع اليوم، فإن "الامتداد غير الموثوق" الذي تتمسك به Polkadot قد يكون هو الحل الحقيقي الذي يدعم التطور طويل الأمد لـ Web3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
8
مشاركة
تعليق
0/400
MysteryBoxOpener
· 07-22 22:03
دوت بالفعل تتفوق على سلاسل الكتل الأخرى
شاهد النسخة الأصليةرد0
NotFinancialAdviser
· 07-22 21:00
لا تبالغ، dot ليست بتلك الأهمية.
شاهد النسخة الأصليةرد0
LuckyBearDrawer
· 07-22 00:01
هذه الموجة من DOT ستنطلق للقمر
شاهد النسخة الأصليةرد0
P2ENotWorking
· 07-19 22:40
ما فائدة السرعة إذا؟ دعنا نعيش أولاً ثم نتحدث.
شاهد النسخة الأصليةرد0
BrokenDAO
· 07-19 22:39
مرة أخرى في رسم توازن مثالي... هل نذكر تلك الأزمة البيئية في عام 2021؟
شاهد النسخة الأصليةرد0
ser_we_are_early
· 07-19 22:39
رائع! أنا مهتم بنقطة واحدة فقط في هذا النوع من المقالات التقنية، ارتفع أم لا؟
شاهد النسخة الأصليةرد0
DevChive
· 07-19 22:32
dot هو المستقبل، من يعارض ذلك؟
شاهد النسخة الأصليةرد0
MagicBean
· 07-19 22:31
انتظر نتائج المتسابقين في بولكادوت، ولا أستطيع أن أقول إنهم بالتأكيد سيذهبون للقمر
طرق التوازن في Polkadot: قابلية التوسع بلا تنازلات في بيئة Web3
القابلية للتوسع والمقايضات: كيف تسعى Polkadot لتحقيق التوازن في نظام Web3 البيئي
في عصر تسعى فيه تقنية البلوكشين لتحقيق كفاءة أعلى، بدأت مشكلة رئيسية بالظهور: كيف يمكن تحسين أداء النظام دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام Web3، فإن النظام الأسرع إذا تم بناؤه على أساس التضحية بالثقة والأمان، غالبًا ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
هل ضحت Polkadot كدافع رئيسي لتوسيع Web3 ببعض الأمور في سعيها لتحقيق أهداف عالية الإنتاجية ومنخفضة الكمون؟ هل قدم نموذج rollup تنازلات في اللامركزية أو الأمان أو التوافق الشبكي؟ سيتناول هذا المقال هذه الأسئلة، ويحلل بعمق التنازلات والموازنة التي قامت بها Polkadot في تصميم التوسيع، ويقارنها بحلول سلاسل الكتل الرئيسية الأخرى، مستكشفاً الخيارات المختلفة التي اتخذتها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن بين المرونة واللامركزية
تعتمد بنية بولكادوت على شبكة من المدققين وسلسلة إعادة مركزية، هل من الممكن أن يؤدي ذلك إلى تقديم مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على ميزاتها اللامركزية؟
تعتمد عملية تشغيل Rollup على مُرتب مُتصل بسلسلة الوسيط، حيث تستخدم الاتصالات آلية تُسمى بروتوكول الجمع. لا يتطلب هذا البروتوكول أي إذن أو ثقة، ويمكن لأي شخص لديه اتصال بالشبكة استخدامه، لربط عدد قليل من عقد سلسلة الوسيط وتقديم طلبات تحويل حالة Rollup. ستتم معالجة هذه الطلبات من خلال أحد نواة سلسلة الوسيط، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة Rollup.
التوازن في التوسع العمودي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم ، اكتشفنا أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة معينة ، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة التتابع غير مصرح به وموثوق به، يمكن لأي شخص تقديم الكتل إلى أي نواة مخصصة للـrollup للتحقق. قد يستغل المهاجمون هذه النقطة، من خلال تقديم كتل شرعية تم التحقق منها مسبقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي إنتاجية وكفاءة الـrollup.
يهدف Polkadot إلى الحفاظ على مرونة rollup واستخدام موارد سلسلة الترحيل بشكل فعال دون التأثير على الخصائص الأساسية للنظام.
هل Sequencer موثوق به؟
طريقة بسيطة لحل المشكلة هي تعيين البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو الثقة بشكل افتراضي في المنظمين بحيث لا يتصرفون بسوء، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة بشأن sequencer، لأننا بحاجة إلى الحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يتمكن أي شخص من استخدام بروتوكول collator لتقديم طلبات التحويل الحالة للrollup.
Polkadot: حل لا يتنازل
الخيار النهائي الذي اختارته Polkadot هو: ترك المشكلة بالكامل لحلها بواسطة دالة تحويل الحالة للـ rollup (Runtime). تعتبر Runtime المصدر الوحيد الموثوق لجميع معلومات التوافق، لذلك يجب أن يتم الإعلان بوضوح في المخرجات عن أي نواة Polkadot يجب أن يتم تنفيذ التحقق عليها.
هذا التصميم يحقق ضمانات مزدوجة من المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل الحالة للـ rollup في عملية الاستخدام، وتضمن بروتوكول الاقتصاد التشفيري ELVES صحة توزيع core.
قبل كتابة أي بيانات على طبقة توفر البيانات (DA) الخاصة بـ Polkadot في كتل rollup، ستقوم مجموعة مكونة من حوالي 5 مدققين بالتحقق من صحتها أولاً. يتلقون الإيصالات المرشحة والأدلة على الصحة المقدمة من مُرتب، والتي تحتوي على كتل rollup والأدلة التخزينية المقابلة. ستتم معالجة هذه المعلومات بواسطة دالة التحقق في السلاسل المتوازية، والتي سيعيد تنفيذها المدققون على سلسلة الترحيل.
تتضمن نتيجة التحقق محدد core، لتحديد أي core يجب التحقق من الكتلة عليه. سيتحقق المصدق من ما إذا كان هذا الفهرس متطابقًا مع core الذي يتحمل مسؤوليته؛ إذا لم يكن متطابقًا، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الإذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core، يبقى النظام مرنًا.
الأمان
في سعيها لتحقيق القابلية للتوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين أمان الـ rollup بواسطة سلسلة التتابع، حيث يكفي وجود منظم أمين للحفاظ على البقاء.
بفضل بروتوكول ELVES، تقوم Polkadot بتوسيع أمانها بشكل كامل إلى جميع rollups، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن لـ rollup الخاص بـ Polkadot تحقيق توسع حقيقي دون التضحية بالأمان.
قابلية الاستخدام
لن يقيّد التوسع المرن قابلية برمجة rollup. يدعم نموذج rollup الخاص بـ Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يكتمل في غضون ثانيتين. بفضل التوسع المرن، تم تعزيز إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوان، ولكن نوع الحسابات لا يتأثر.
تعقيد
من المؤكد أن زيادة السعة وتقليل التأخير يجلبان تعقيدًا، وهذه هي الطريقة الوحيدة المقبولة في تصميم الأنظمة.
يمكن أن يقوم Rollup بضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليهم تلبية بعض متطلبات RFC103 للتكيف مع سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجية إدارة الموارد للـ rollup، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عددًا ثابتًا من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في mempool العقدة؛
استراتيجيات الأتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمات coretime مسبقًا لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار زادت بشكل ملحوظ.
التفاعل بين الأنظمة
تدعم بولكادوت التوافق بين rollups المختلفة، ولن تؤثر التوسع المرن على قدرة نقل الرسائل.
تتم اتصالات الرسائل عبر rollup بواسطة طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصالات لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، حيث سيكون سلسلة الترحيل هي واجهة التحكم بدلاً من واجهة البيانات. ستعمل هذه الترقية على تحسين قدرة الاتصال بين rollups مع توسيع مرونة، مما يعزز القدرة الرأسية للنظام.
ما هي التنازلات التي قدمتها البروتوكولات الأخرى؟
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لبولكادوت منخفضة، فإن أدائهم لا يزال غير مرضٍ.
سولانا
لا تستخدم سولانا هيكل تقسيم بولكادوت أو إيثريوم، بل تعتمد على هيكل أحادي الطبقة عالي الإنتاجية لتحقيق قابلية التوسع، بالاعتماد على إثبات التاريخ (PoH) ومعالجة مركزية متوازية وآلية توافق قائمة على القيادة، ويصل TPS النظري إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل فترة (حوالي يومين أو 432,000 فتحة) ، يتم تخصيص الفتحات بناءً على كمية الرهانات؛
كلما زادت الحصة، زادت التوزيعات. على سبيل المثال، سيحصل المدقق الذي يراهن بنسبة 1% على حوالي 1% من فرصة إنشاء الكتل؛
جميع المُعدّنين يُعلن عنهم مسبقًا، مما يزيد من خطر تعرض الشبكة لهجمات DDoS موجهة، والانقطاع المتكرر.
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زاد عدد العقد المرهونة، زادت فرصها في إنتاج الكتل، بينما تكاد تكون الفرص المتاحة للعقد الصغيرة معدومة، مما يزيد من حدة المركزية ويزيد من خطر تعطل النظام بعد التعرض للهجوم.
تضحي سولانا باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.
طن
يزعم مشروع blockchain معين أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، لكن هذا الرقم تحقق في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف شبكة وأجهزة مثالية. بينما وصلت Polkadot إلى 128K TPS على شبكة عامة لامركزية.
آلية إجماع هذا المشروع تحتوي على ثغرات أمنية: هوية عقد التحقق من الشظايا قد تُكشف مسبقًا. كما أوضح الورقة البيضاء أن هذا قد يحسن عرض النطاق الترددي، لكنه قد يُستغل بشكل ضار. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة تمامًا على شظية معينة، أو منع المدققين المخلصين من خلال هجمات DDoS، مما يتيح لهم تعديل الحالة.
بالمقارنة، يتم توزيع المدققين في Polkadot بشكل عشوائي وكشفهم بعد تأخير، مما يجعل المهاجمين غير قادرين على معرفة هوية المدققين مسبقًا، ويجب عليهم المراهنة على السيطرة الكاملة للنجاح. طالما أن هناك مدققًا صادقًا واحدًا يثير النزاع، ستفشل الهجمة وستؤدي إلى خسارة المهاجم لمبلغ الرهانات.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS) وC-Chain (العقود الذكية، ~100-200 TPS) وP-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكات الفرعية بحرية، ويمكن أن تضع الشبكات الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشترك جميع rollups في ضمان أمان موحد؛ بينما لا توفر الشبكات الفرعية في Avalanche ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا بالكامل. إذا كنت ترغب في تعزيز الأمان، فلا بد من التنازل عن الأداء، ومن الصعب تقديم التزامات أمان محددة.
إيثريوم
استراتيجية التوسع في الإيثيريوم تعتمد على الرهان على قابلية التوسع في طبقة rollup، بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، فإن معظم عمليات التكديس التفاؤلية (Optimistic rollup) مركزية (بعضها يحتوي حتى على sequencer واحد فقط)، مما يؤدي إلى مشاكل مثل نقص الأمان، والعزلة عن بعضها البعض، وزيادة التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادة ما تستغرق عدة أيام).
زك رول اب
تواجه تطبيقات ZK rollup قيودًا بسبب كمية البيانات التي يمكن معالجتها في كل معاملة. تتطلب عملية توليد إثباتات المعرفة الصفرية موارد حسابية عالية جدًا، وآلية "الفائز يأخذ كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup عدد المعاملات في كل دفعة، مما قد يتسبب في ازدحام الشبكة وزيادة رسوم الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القابلة للتطوير Turing هي حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد الرقمي الأساسي لـ Polkadot.
بالإضافة إلى ذلك، فإن مشكلة توفر بيانات ZK rollup ستزيد من عيوبها. لضمان أن يتمكن أي شخص من التحقق من المعاملات، لا يزال يتعين تقديم بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع بولكادوت الطريق الذي يستبدل فيه المركزية بالأداء، أو الثقة المسبقة بالكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التصميم المرن للتوسع، والبروتوكولات غير المصرح بها، وطبقة الأمان الموحدة، وآلية إدارة الموارد المرنة.
في سعيها لتحقيق تطبيقات على نطاق أوسع اليوم، فإن "الامتداد غير الموثوق" الذي تتمسك به Polkadot قد يكون هو الحل الحقيقي الذي يدعم التطور طويل الأمد لـ Web3.