في عالم تسعى فيه تقنية blockchain باستمرار لتحقيق كفاءة أعلى، تبرز مسألة حاسمة: كيف يمكن تحسين الأداء مع الحفاظ على الأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لبيئة Web3، فإن النظام الأسرع إذا تم بناؤه على أساس التضحية بالثقة والأمان، غالبًا ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
باعتبارها واحدة من المحفزات الرئيسية لقابلية التوسع في Web3، هل ضحت Polkadot ببعض الأمور في سعيها لتحقيق أهداف عالية من خلال القدرة على المعالجة المنخفضة والتأخير؟ هل قدم نموذجها للـ rollup تنازلات في اللامركزية أو الأمان أو التشغيل البيني للشبكات؟
ستتناول هذه المقالة هذه القضايا، وتحلل بعمق المساومات والتوازنات التي اتخذها Polkadot في تصميم القابلية للتوسع، وتقارنها مع حلول سلاسل الكتل الرئيسية الأخرى، مستكشفة الاختيارات المختلفة بينها من حيث الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
التوازن بين المرونة واللامركزية
يعتمد هيكل بولكادوت على شبكة من المدققين وسلسلة مركزية، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقطة فشل واحدة أو تحكم، مما يؤثر على خصائصه اللامركزية؟
تعتمد تشغيل Rollup على المُرتب للربط مع سلسلة الترحيل، حيث يتم استخدام آلية بروتوكول collator للتواصل. هذا البروتوكول لا يحتاج إلى إذن أو ثقة، أي شخص لديه اتصال بالشبكة يمكنه استخدامه، والاتصال بعدد قليل من عقد سلسلة الترحيل، وتقديم طلبات تحويل حالة Rollup. سيتم التحقق من هذه الطلبات من خلال أحد النواة في سلسلة الترحيل، بشرط واحد فقط: يجب أن تكون تحويل الحالة صالحًا، وإلا فلن يتم دفع حالة Rollup.
التوازن في التوسع العمودي
يمكن لـ Rollup تحقيق التوسع العمودي من خلال الاستفادة من البنية متعددة النوى في Polkadot. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتل rollup لا يتم تنفيذه بشكل ثابت على نواة واحدة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الارتباط هو بروتوكول غير مرخص وغير موثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق. قد يستغل المهاجمون هذه النقطة من خلال تقديم كتل قانونية تم التحقق منها مسبقًا بشكل متكرر إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل خبيث، وبالتالي تقليل إنتاجية وكفاءة rollup الكلية.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة الترحيل دون التأثير على الخصائص الأساسية للنظام.
مشكلة الثقة في Sequencer
طريقة بسيطة للحل هي تعيين البروتوكول إلى "مرخص": على سبيل المثال، اعتماد آلية القائمة البيضاء، أو الثقة الافتراضية بأن المنظمين لن يقوموا بسلوكيات ضارة، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا القيام بأي افتراضات ثقة بشأن sequencer، لأننا بحاجة للحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل الحالة للrollup.
بولكادوت: حل غير متنازل
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل إلى وظيفة تحويل حالة rollup (Runtime). Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذلك يجب أن يتم الإشارة بوضوح في المخرجات إلى أي نواة من Polkadot يجب تنفيذ التحقق عليها.
هذا التصميم يضمن ثنائية المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويلات حالة rollup في عملية التوفر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة البيانات إلى طبقة توفر البيانات الخاصة بـ Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 مصادقين بالتحقق من صحتها أولاً. إنهم يتلقون الإيصالات المرشحة وإثباتات الصلاحية التي يقدمها المترتب، والتي تحتوي على كتلة rollup وإثباتات التخزين المناسبة. سيتم تمرير هذه المعلومات إلى دالة التحقق من السلسلة المتوازية، حيث سيقوم المصادقون على السلسلة الوسيطة بإعادة تنفيذها.
تحتوي نتيجة التحقق على محدد أساسي، يُستخدم لتحديد أي نواة يجب أن يتحقق منها الكتلة. سيقوم المدقق بمقارنة هذا الفهرس مع النواة التي هو مسؤول عنها؛ إذا لم تكن متطابقة، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الحاجة إلى إذن، مما يمنع الجهات الفاعلة الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام رول أب لعدة نوى، يمكن الحفاظ على المرونة.
الأمان
خلال سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين أمان rollup بواسطة سلسلة الترحيل، ويكفي وجود مُرتب صادق للحفاظ على الاستمرارية.
من خلال بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بشكل كامل ليشمل جميع الـrollup، والتحقق من جميع الحسابات على الـcore، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot التوسع الحقيقي دون التضحية بالأمان.
عمومية
لن يقيّد التوسع المرن قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة الدقة في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في أقل من 2 ثانية. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات التي يمكن تنفيذها في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
التعقيد
تؤدي زيادة الإنتاجية وانخفاض التأخير حتمًا إلى إدخال التعقيد، وهي الطريقة الوحيدة المقبولة للتوازن في تصميم النظام.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان موحد. كما يجب عليها تلبية بعض متطلبات RFC103 لتناسب سيناريوهات استخدام مختلفة.
تعتمد التعقيدات المحددة على استراتيجية إدارة الموارد في rollup، والتي قد تعتمد على متغيرات على السلسلة أو خارجها. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة;
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في mempool العقد.
استراتيجيات تلقائية: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمة coretime مسبقًا لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكلفة التنفيذ والاختبار قد زادت بشكل ملحوظ.
التفاعلية
تدعم Polkadot التشغيل البيني بين rollups المختلفة، ولن تؤثر القدرة على التوسع المرن على سعة نقل الرسائل.
تتم عملية التواصل بين rollups عبر طبقة النقل الأساسية، حيث تكون مساحة كتلة التواصل لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، سيدعم Polkadot أيضًا رسائل خارج السلسلة، حيث ستكون سلسلة الترحيل هي واجهة التحكم بدلاً من واجهة البيانات. ستعمل هذه الترقية على تحسين قدرة الاتصال بين عمليات الرفع بالتوازي مع التوسع المرن، مما يعزز بشكل أكبر القدرة على التوسع العمودي للنظام.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائها ليس مرضيًا.
سولانا
لا تعتمد سولانا على هيكل تقسيم بولكادوت أو إيثيريوم، بل تحقق القابلية للتوسع من خلال بنية عالية الإنتاجية ذات طبقة واحدة، وتعتمد على إثبات التاريخ (PoH)، والمعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق قائمة على القيادة، ويمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي يتم الكشف عنها مسبقًا ويمكن التحقق منها:
كل إبوك ( يستمر حوالي يومين أو 432,000 فتحة ) في البداية، يتم توزيع الفتحات حسب كمية الرهان؛
كلما زادت نسبة الرهن، زادت نسبة التوزيع. على سبيل المثال، فإن رهن 1% من المصدقين سيحصل على حوالي 1% من فرصة إنشاء الكتل؛
تم الإعلان عن جميع مُصدري الكتل مسبقًا، مما زاد من خطر تعرض الشبكة لهجمات DDoS موجهة، والتوقف المتكرر.
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت كمية الرهان، زادت فرصة العقد في إنتاج الكتل، بينما تكاد تكون الفرص متاحة للعقد الصغيرة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
سولانا sacrificed اللامركزية وقدرة مقاومة الهجمات في سعيها نحو TPS، حيث أن معامل ناكاموتو لديها لا يتجاوز 20، وهو أقل بكثير من 172 الخاص بـ بولكادوت.
طن
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف شبكة وأجهزة مثالية. بينما حققت Polkadot بالفعل 128 ألف معاملة في الثانية على شبكة عامة لامركزية.
آلية إجماع TON تحتوي على مخاطر أمنية: هوية عقد التحقق من الشظايا قد تتعرض للكشف مسبقًا. كما أوضح المستند الأبيض لـ TON، رغم أن هذا يمكن أن يحسن النطاق الترددي، إلا أنه قد يُستغل بشكل خبيث. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتم السيطرة بالكامل على شظية معينة، أو من خلال هجمات DDoS عرقلة المدققين الشرفاء، وبالتالي التلاعب بالحالة.
بالمقارنة، يتم تعيين المدققين في Polkadot بشكل عشوائي، ويتم الكشف عنهم بعد فترة، مما يجعل المهاجمين غير قادرين على معرفة هوية المدققين مسبقًا. يجب على المهاجم أن يراهن على السيطرة الكاملة للنجاح، طالما أن هناك مدققًا نزيهًا واحدًا يقوم ببدء النزاع، ستفشل الهجمة وتؤدي إلى خسارة المهاجم لرهانه.
أفالانش
تستخدم Avalanche هيكل شبكة رئيسية + شبكات فرعية للتوسع، حيث تتكون الشبكة الرئيسية من تحويلات X-Chain( بمعدل ~4,500 TPS)، وعقود ذكية على C-Chain( بمعدل ~100-200 TPS)، وإدارة المدققين والشبكات الفرعية بواسطة P-Chain(.
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة بولكادوت: تقليل الحمل على shard واحد لتحقيق التوسع. لكن أفالانش يسمح للمتحققين باختيار المشاركة بحرية في الشبكات الفرعية، ويمكن أن يتم تعيين متطلبات إضافية جغرافية وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشترك جميع rollups في ضمان أمن موحد؛ بينما لا تتمتع الشبكات الفرعية في Avalanche بضمان أمني افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، فسيتعين عليك التضحية بالأداء، ومن الصعب تقديم التزام أمني حتمي.
) إيثيريوم
استراتيجية توسيع إيثيريوم تعتمد على المراهنة على قابلية التوسع في طبقة الرول أب، بدلاً من معالجة المشكلات مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا في المكدس.
التجميع المتفائل
حالياً، معظم حلول الأوبتيمستيك رول أب مركزية ### وبعضها يحتوي على مسجل واحد فقط (، مما يسبب نقصاً في الأمان، وعزلة بين الأنظمة، وزيادة في التأخير ) حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادةً ما تستغرق بضعة أيام (.
)# زك رول أب
تُعَاني تنفيذات ZK rollup من قيود كمية البيانات القابلة للمعالجة في كل معاملة. متطلبات حساب إثبات المعرفة الصفرية مرتفعة للغاية، ومن السهل أن تؤدي آلية "الفائز يأخذ كل شيء" إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة gas في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القابلة للتوسع Turing الكامل تبلغ حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي لـ Polkadot.
علاوة على ذلك، فإن مشكلة توفر بيانات ZK rollup ستزيد من عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا بد من توفير بيانات المعاملات الكاملة. وهذا غالبًا ما يعتمد على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع، يجب ألا تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع Polkadot طريق المركزية مقابل الأداء، أو الثقة المسبقة مقابل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم البروتوكولات غير المصرح بها، وطبقة الأمان الموحدة، وآلية إدارة الموارد المرنة.
في سعيها لتحقيق تطبيقات أكبر نطاقًا اليوم، فإن "التوسع بدون ثقة" الذي تتمسك به بولكادوت قد يكون هو الحل الحقيقي الذي يمكن أن يدعم التطور الطويل الأمد للويب 3.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
اختيار Polkadot لتوسيع Web3: الأمان واللامركزية دون أي تنازل
خيارات التوسع: صفقات Polkadot و Web3
في عالم تسعى فيه تقنية blockchain باستمرار لتحقيق كفاءة أعلى، تبرز مسألة حاسمة: كيف يمكن تحسين الأداء مع الحفاظ على الأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لبيئة Web3، فإن النظام الأسرع إذا تم بناؤه على أساس التضحية بالثقة والأمان، غالبًا ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
باعتبارها واحدة من المحفزات الرئيسية لقابلية التوسع في Web3، هل ضحت Polkadot ببعض الأمور في سعيها لتحقيق أهداف عالية من خلال القدرة على المعالجة المنخفضة والتأخير؟ هل قدم نموذجها للـ rollup تنازلات في اللامركزية أو الأمان أو التشغيل البيني للشبكات؟
ستتناول هذه المقالة هذه القضايا، وتحلل بعمق المساومات والتوازنات التي اتخذها Polkadot في تصميم القابلية للتوسع، وتقارنها مع حلول سلاسل الكتل الرئيسية الأخرى، مستكشفة الاختيارات المختلفة بينها من حيث الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
التوازن بين المرونة واللامركزية
يعتمد هيكل بولكادوت على شبكة من المدققين وسلسلة مركزية، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقطة فشل واحدة أو تحكم، مما يؤثر على خصائصه اللامركزية؟
تعتمد تشغيل Rollup على المُرتب للربط مع سلسلة الترحيل، حيث يتم استخدام آلية بروتوكول collator للتواصل. هذا البروتوكول لا يحتاج إلى إذن أو ثقة، أي شخص لديه اتصال بالشبكة يمكنه استخدامه، والاتصال بعدد قليل من عقد سلسلة الترحيل، وتقديم طلبات تحويل حالة Rollup. سيتم التحقق من هذه الطلبات من خلال أحد النواة في سلسلة الترحيل، بشرط واحد فقط: يجب أن تكون تحويل الحالة صالحًا، وإلا فلن يتم دفع حالة Rollup.
التوازن في التوسع العمودي
يمكن لـ Rollup تحقيق التوسع العمودي من خلال الاستفادة من البنية متعددة النوى في Polkadot. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتل rollup لا يتم تنفيذه بشكل ثابت على نواة واحدة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الارتباط هو بروتوكول غير مرخص وغير موثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق. قد يستغل المهاجمون هذه النقطة من خلال تقديم كتل قانونية تم التحقق منها مسبقًا بشكل متكرر إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل خبيث، وبالتالي تقليل إنتاجية وكفاءة rollup الكلية.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة الترحيل دون التأثير على الخصائص الأساسية للنظام.
مشكلة الثقة في Sequencer
طريقة بسيطة للحل هي تعيين البروتوكول إلى "مرخص": على سبيل المثال، اعتماد آلية القائمة البيضاء، أو الثقة الافتراضية بأن المنظمين لن يقوموا بسلوكيات ضارة، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا القيام بأي افتراضات ثقة بشأن sequencer، لأننا بحاجة للحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل الحالة للrollup.
بولكادوت: حل غير متنازل
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل إلى وظيفة تحويل حالة rollup (Runtime). Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذلك يجب أن يتم الإشارة بوضوح في المخرجات إلى أي نواة من Polkadot يجب تنفيذ التحقق عليها.
هذا التصميم يضمن ثنائية المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويلات حالة rollup في عملية التوفر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة البيانات إلى طبقة توفر البيانات الخاصة بـ Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 مصادقين بالتحقق من صحتها أولاً. إنهم يتلقون الإيصالات المرشحة وإثباتات الصلاحية التي يقدمها المترتب، والتي تحتوي على كتلة rollup وإثباتات التخزين المناسبة. سيتم تمرير هذه المعلومات إلى دالة التحقق من السلسلة المتوازية، حيث سيقوم المصادقون على السلسلة الوسيطة بإعادة تنفيذها.
تحتوي نتيجة التحقق على محدد أساسي، يُستخدم لتحديد أي نواة يجب أن يتحقق منها الكتلة. سيقوم المدقق بمقارنة هذا الفهرس مع النواة التي هو مسؤول عنها؛ إذا لم تكن متطابقة، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الحاجة إلى إذن، مما يمنع الجهات الفاعلة الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام رول أب لعدة نوى، يمكن الحفاظ على المرونة.
الأمان
خلال سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين أمان rollup بواسطة سلسلة الترحيل، ويكفي وجود مُرتب صادق للحفاظ على الاستمرارية.
من خلال بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بشكل كامل ليشمل جميع الـrollup، والتحقق من جميع الحسابات على الـcore، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot التوسع الحقيقي دون التضحية بالأمان.
عمومية
لن يقيّد التوسع المرن قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة الدقة في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في أقل من 2 ثانية. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات التي يمكن تنفيذها في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
التعقيد
تؤدي زيادة الإنتاجية وانخفاض التأخير حتمًا إلى إدخال التعقيد، وهي الطريقة الوحيدة المقبولة للتوازن في تصميم النظام.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان موحد. كما يجب عليها تلبية بعض متطلبات RFC103 لتناسب سيناريوهات استخدام مختلفة.
تعتمد التعقيدات المحددة على استراتيجية إدارة الموارد في rollup، والتي قد تعتمد على متغيرات على السلسلة أو خارجها. على سبيل المثال:
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكلفة التنفيذ والاختبار قد زادت بشكل ملحوظ.
التفاعلية
تدعم Polkadot التشغيل البيني بين rollups المختلفة، ولن تؤثر القدرة على التوسع المرن على سعة نقل الرسائل.
تتم عملية التواصل بين rollups عبر طبقة النقل الأساسية، حيث تكون مساحة كتلة التواصل لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، سيدعم Polkadot أيضًا رسائل خارج السلسلة، حيث ستكون سلسلة الترحيل هي واجهة التحكم بدلاً من واجهة البيانات. ستعمل هذه الترقية على تحسين قدرة الاتصال بين عمليات الرفع بالتوازي مع التوسع المرن، مما يعزز بشكل أكبر القدرة على التوسع العمودي للنظام.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائها ليس مرضيًا.
سولانا
لا تعتمد سولانا على هيكل تقسيم بولكادوت أو إيثيريوم، بل تحقق القابلية للتوسع من خلال بنية عالية الإنتاجية ذات طبقة واحدة، وتعتمد على إثبات التاريخ (PoH)، والمعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق قائمة على القيادة، ويمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي يتم الكشف عنها مسبقًا ويمكن التحقق منها:
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت كمية الرهان، زادت فرصة العقد في إنتاج الكتل، بينما تكاد تكون الفرص متاحة للعقد الصغيرة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
سولانا sacrificed اللامركزية وقدرة مقاومة الهجمات في سعيها نحو TPS، حيث أن معامل ناكاموتو لديها لا يتجاوز 20، وهو أقل بكثير من 172 الخاص بـ بولكادوت.
طن
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف شبكة وأجهزة مثالية. بينما حققت Polkadot بالفعل 128 ألف معاملة في الثانية على شبكة عامة لامركزية.
آلية إجماع TON تحتوي على مخاطر أمنية: هوية عقد التحقق من الشظايا قد تتعرض للكشف مسبقًا. كما أوضح المستند الأبيض لـ TON، رغم أن هذا يمكن أن يحسن النطاق الترددي، إلا أنه قد يُستغل بشكل خبيث. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتم السيطرة بالكامل على شظية معينة، أو من خلال هجمات DDoS عرقلة المدققين الشرفاء، وبالتالي التلاعب بالحالة.
بالمقارنة، يتم تعيين المدققين في Polkadot بشكل عشوائي، ويتم الكشف عنهم بعد فترة، مما يجعل المهاجمين غير قادرين على معرفة هوية المدققين مسبقًا. يجب على المهاجم أن يراهن على السيطرة الكاملة للنجاح، طالما أن هناك مدققًا نزيهًا واحدًا يقوم ببدء النزاع، ستفشل الهجمة وتؤدي إلى خسارة المهاجم لرهانه.
أفالانش
تستخدم Avalanche هيكل شبكة رئيسية + شبكات فرعية للتوسع، حيث تتكون الشبكة الرئيسية من تحويلات X-Chain( بمعدل ~4,500 TPS)، وعقود ذكية على C-Chain( بمعدل ~100-200 TPS)، وإدارة المدققين والشبكات الفرعية بواسطة P-Chain(.
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة بولكادوت: تقليل الحمل على shard واحد لتحقيق التوسع. لكن أفالانش يسمح للمتحققين باختيار المشاركة بحرية في الشبكات الفرعية، ويمكن أن يتم تعيين متطلبات إضافية جغرافية وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشترك جميع rollups في ضمان أمن موحد؛ بينما لا تتمتع الشبكات الفرعية في Avalanche بضمان أمني افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، فسيتعين عليك التضحية بالأداء، ومن الصعب تقديم التزام أمني حتمي.
) إيثيريوم
استراتيجية توسيع إيثيريوم تعتمد على المراهنة على قابلية التوسع في طبقة الرول أب، بدلاً من معالجة المشكلات مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا في المكدس.
التجميع المتفائل
حالياً، معظم حلول الأوبتيمستيك رول أب مركزية ### وبعضها يحتوي على مسجل واحد فقط (، مما يسبب نقصاً في الأمان، وعزلة بين الأنظمة، وزيادة في التأخير ) حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادةً ما تستغرق بضعة أيام (.
)# زك رول أب
تُعَاني تنفيذات ZK rollup من قيود كمية البيانات القابلة للمعالجة في كل معاملة. متطلبات حساب إثبات المعرفة الصفرية مرتفعة للغاية، ومن السهل أن تؤدي آلية "الفائز يأخذ كل شيء" إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة gas في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القابلة للتوسع Turing الكامل تبلغ حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي لـ Polkadot.
علاوة على ذلك، فإن مشكلة توفر بيانات ZK rollup ستزيد من عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا بد من توفير بيانات المعاملات الكاملة. وهذا غالبًا ما يعتمد على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع، يجب ألا تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع Polkadot طريق المركزية مقابل الأداء، أو الثقة المسبقة مقابل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم البروتوكولات غير المصرح بها، وطبقة الأمان الموحدة، وآلية إدارة الموارد المرنة.
في سعيها لتحقيق تطبيقات أكبر نطاقًا اليوم، فإن "التوسع بدون ثقة" الذي تتمسك به بولكادوت قد يكون هو الحل الحقيقي الذي يمكن أن يدعم التطور الطويل الأمد للويب 3.