مشكلة قابلية التوسع في البلوكتشين: الحل من Polkadot
في عصر السعي نحو كفاءة أعلى في مجال البلوكتشين، بدأت مشكلة رئيسية تظهر تدريجياً: كيف يمكن تحقيق الأداء العالي دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى الفني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لبيئة Web3، فإن نظاماً أسرع إذا تم بناءه على أساس التضحية بالثقة والأمان، غالباً ما يكون من الصعب دعمه كابتكار مستدام حقاً.
ستقوم هذه المقالة بتحليل عميق للتنازلات والتوازنات في تصميم قابلية التوسع في Polkadot، ومقارنتها مع حلول سلاسل الكتل الرئيسية الأخرى، واستكشاف الاختيارات المختلفة بينها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
التوازن بين المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المدققين وسلسلة الإعادة. يعتمد تشغيل Rollup على مرتّب متصل بسلسلة الإعادة، حيث تستخدم الاتصالات آلية بروتوكول collator. هذا البروتوكول لا يتطلب إذنًا، ولا يحتاج إلى ثقة، أي شخص لديه اتصال بالشبكة يمكنه استخدامه، وتوصيل عدد قليل من عقد سلسلة الإعادة، وتقديم طلبات تحويل الحالة لـ rollup. ستتم معالجة هذه الطلبات من خلال أحد النوى في سلسلة الإعادة، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة الـ rollup.
التوازن في التوسع الرأسي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من هيكل Polkadot متعدد النوى. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن تحقق كتلة rollup لا يتم تنفيذه على نواة معينة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الوسيط هو بروتوكول غير مرخص وغير موثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق منها. قد يستغل المهاجمون هذه النقطة، حيث يقومون بتقديم كتل شرعية تم التحقق منها سابقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي قدرة rollup وكفاءته.
تهدف Polkadot إلى الحفاظ على مرونة rollup واستخدام موارد سلسلة الترحيل بشكل فعال دون التأثير على الخصائص الأساسية للنظام.
مشكلة الثقة في Sequencer
طريقة بسيطة للحل هي ضبط البروتوكول على "مصرح به": مثل استخدام آلية القائمة البيضاء، أو الثقة الافتراضية في أن ترتيبات الثقة لن تتصرف بشكل خبيث، وبالتالي ضمان نشاط rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة بشأن sequencer، لأننا بحاجة إلى الحفاظ على خصائص "بدون ثقة" و"بدون إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل غير متنازل
الخيار النهائي لبولكادوت هو: تسليم المشكلة بالكامل إلى دالة تحويل الحالة للـ rollup (Runtime). الـ Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة من بولكادوت يجب تنفيذ التحقق عليها.
هذا التصميم يحقق ضماناً مزدوجاً للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل الحالة للـ rollup في عملية القابلية للاستخدام، وتضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع الـ core.
قبل كتابة البيانات إلى طبقة توفر البيانات الخاصة بـ Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 موثوقين بالتحقق أولاً من مشروعيتها. إنهم يستقبلون الإيصالات المرشحة وأدلة الصلاحية المقدمة من المنظم، والتي تحتوي على كتلة rollup والأدلة التخزينية المناسبة. سيتم معالجة هذه المعلومات بواسطة دالة التحقق من سلسلة متوازية، وسيتم إعادة تنفيذها بواسطة الموثوقين على سلسلة الترحيل.
تتضمن نتيجة التحقق محدد core لتحديد أي core يجب التحقق من الكتلة عليه. سيقوم المدقق بمقارنة هذا الفهرس مع core الذي يكون مسؤولًا عنه؛ إذا كان غير متطابق، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية أن يظل النظام دائمًا بدون ثقة وبدون إذن، مما يمنع الجهات الفاعلة الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core يمكن الحفاظ على المرونة.
الأمان
في سعيها نحو التوسع، لم تتنازل Polkadot عن الأمان. يتم ضمان أمان rollup من خلال سلسلة الترحيل، حيث يكفي وجود مُرتب صادق للحفاظ على البقاء.
بفضل بروتوكول ELVES، يقوم Polkadot بتوسيع أمانه بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على core، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن لـ Polkadot أن تحقق توسعًا حقيقيًا من خلال rollup دون التضحية بالأمان.
قابلية العموم
لن يحد التوسع المرن من قابلية برمجة الـ rollup. يدعم نموذج الـ rollup الخاص بـ Polkadot تنفيذ حسابات كاملة التوجه في بيئة WebAssembly، طالما أن التنفيذ الفردي يتم في أقل من 2 ثانية. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
تؤدي زيادة السعة الإنتاجية وتقليل الكمون بشكل لا مفر منه إلى إدخال التعقيد، وهو الطريقة الوحيدة المقبولة في تصميم الأنظمة.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد الخاصة بالـ rollup، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في ميمبول العقد.
استراتيجيات مؤتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمة coretime مسبقًا لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التشغيل المتداخل
يدعم Polkadot التداخل بين مختلف rollups، ولن تؤثر التوسعة المرنة على قدرة نقل الرسائل.
تتم اتصالات الرسائل عبر rollup بواسطة طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة لها.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، حيث ستعمل سلسلة الإرسال كواجهة تحكم، وليس كواجهة بيانات. ستعمل هذه الترقيات على تحسين قدرة الاتصال بين rollups جنبًا إلى جنب مع التوسع المرن، مما يعزز بشكل أكبر القدرة العمودية للنظام.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. لكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لPolkadot أقل، فإن أدائها لا يزال غير مرضٍ.
سولانا
لا تعتمد سولانا على هيكل تقسيم بولكادوت أو إيثريوم، بل تحقق القابلية للتوسع من خلال هيكل أحادي الطبقة عالي الإنتاجية، اعتماداً على إثبات التاريخ، المعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق قائمة على القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل فترة زمنية (حوالي يومين أو 432,000 فتحة)، يتم تخصيص الفتحات بناءً على كمية الرهانات؛
كلما زادت نسبة الرهان، زادت التوزيعات. على سبيل المثال، سيحصل المدقق الذي يراهن بنسبة 1% على حوالي 1% من فرص إنشاء الكتل؛
جميع مُخرجي الكتل يُعلن عنهم مسبقًا، مما يزيد من خطر تعرض الشبكة لهجمات DDoS موجهة، وانقطاع الخدمة المتكرر.
أثبت التاريخ أن المعالجة المتوازية تتطلب متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية العقد التحقق. كلما زاد عدد العقد المراهنة، زادت فرصها في إنتاج الكتل، بينما تكاد تكون الفرص المتاحة للعقد الصغيرة معدومة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
تضحي سولانا باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ بولكادوت.
طن
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظل ظروف شبكة ومعدات مثالية. بينما وصلت Polkadot إلى 128K TPS على شبكة عامة غير مركزية.
توجد مخاطر أمان في آلية توافق TON: سوف يتم الكشف عن هوية عقد التحقق المُجزأ مسبقًا. كما يشير المستند الأبيض لـ TON بوضوح إلى أن هذا قد يحسن عرض النطاق الترددي، ولكنه قد يُستغل بشكل ضار. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة تمامًا على كتلة معينة، أو قطع الاتصال بالتحقق الأمين من خلال هجمات DDoS، وبالتالي تعديل الحالة.
بالمقارنة، يتم تخصيص الموثقين في Polkadot عشوائياً، مع الكشف المتأخر، مما يعني أن المهاجمين لا يمكنهم معرفة هوية الموثقين مسبقاً. يتطلب الهجوم السيطرة الكاملة على الموثقين للفوز، وإذا قام موثق واحد نزيه ببدء نزاع، فسيفشل الهجوم مما يؤدي إلى خسارة المهاجم لرأس المال المرهون.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكات الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، و P-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمتحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن أن تضع الشبكة الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تتشارك جميع rollup ضمان الأمان الموحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا بالكامل. إذا كنت ترغب في تعزيز الأمان، فلا بد من تقديم تنازلات في الأداء، ومن الصعب تقديم التزام أمان حاسم.
إيثيريوم
استراتيجية التوسع في الإيثيريوم تعتمد على المراهنة على قابلية التوسع في طبقة الـ rollup، بدلاً من حل المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، فإن معظم التفاف الأمل (Optimistic rollup) مركزي (بعضها يحتوي حتى على sequencer واحد فقط)، مما يؤدي إلى مشاكل تتعلق بعدم كفاية الأمان، والعزلة عن بعضها البعض، وزيادة التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي غالبًا ما تستغرق عدة أيام).
ZK رولاب
إن تنفيذ ZK rollup مقيد بحدود كمية البيانات التي يمكن معالجتها في معاملة واحدة. إن متطلبات حساب إثبات المعرفة الصفرية مرتفعة للغاية، وآلية "الفائز يأخذ كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما يقتصر ZK rollup على حجم المعاملات في كل دفعة، مما قد يتسبب في ازدحام الشبكة وزيادة الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقارنة، تكلفة ZK rollup المجهزة بـ Turing الكاملة حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي لـ Polkadot.
بالإضافة إلى ذلك، ستؤدي مشكلة توفر بيانات ZK rollup إلى تفاقم عيوبه. لضمان قدرة أي شخص على التحقق من المعاملات، لا يزال يتعين تقديم بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع Polkadot الطريق الذي يتم فيه تبادل المركزية بالأداء أو الثقة المسبقة بالكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال توسيع مرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا في الوقت الحاضر، فإن "التوسع بدون ثقة" الذي تتمسك به Polkadot، قد يكون حقًا هو الحل الذي يدعم التطوير طويل الأمد للويب 3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 24
أعجبني
24
7
مشاركة
تعليق
0/400
OneBlockAtATime
· 07-21 14:44
مرة أخرى يتم رسم BTC، من يتبادل DOT؟
شاهد النسخة الأصليةرد0
RunWhenCut
· 07-21 10:51
من يهتم بالأمان بعد الآن، فقط اذهب وانتهى الأمر.
شاهد النسخة الأصليةرد0
ImpermanentSage
· 07-18 23:56
غنت لفترة طويلة، لكن بولكادوت لم يحقق نجاحًا كبيرًا.
شاهد النسخة الأصليةرد0
RektCoaster
· 07-18 23:51
لا أستطيع الكلام، TPS الخاص بـ dot منخفض جداً، دائماً أرى من يتفاخر.
شاهد النسخة الأصليةرد0
SoliditySlayer
· 07-18 23:44
dot هو الطريق الصحيح
شاهد النسخة الأصليةرد0
SelfCustodyIssues
· 07-18 23:34
أخيراً أدركت أن dot لا يمكن أن تتفوق على sol
شاهد النسخة الأصليةرد0
Web3ProductManager
· 07-18 23:32
بالنظر إلى أرقام DAU الخاصة بـ Dot... لا أرى تلك الزيادة الحادة التي نحتاجها بصراحة
اختراق قابلية التوسع في بولكادوت: أداء وأمان دون تنازلات
مشكلة قابلية التوسع في البلوكتشين: الحل من Polkadot
في عصر السعي نحو كفاءة أعلى في مجال البلوكتشين، بدأت مشكلة رئيسية تظهر تدريجياً: كيف يمكن تحقيق الأداء العالي دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى الفني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لبيئة Web3، فإن نظاماً أسرع إذا تم بناءه على أساس التضحية بالثقة والأمان، غالباً ما يكون من الصعب دعمه كابتكار مستدام حقاً.
ستقوم هذه المقالة بتحليل عميق للتنازلات والتوازنات في تصميم قابلية التوسع في Polkadot، ومقارنتها مع حلول سلاسل الكتل الرئيسية الأخرى، واستكشاف الاختيارات المختلفة بينها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
التوازن بين المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المدققين وسلسلة الإعادة. يعتمد تشغيل Rollup على مرتّب متصل بسلسلة الإعادة، حيث تستخدم الاتصالات آلية بروتوكول collator. هذا البروتوكول لا يتطلب إذنًا، ولا يحتاج إلى ثقة، أي شخص لديه اتصال بالشبكة يمكنه استخدامه، وتوصيل عدد قليل من عقد سلسلة الإعادة، وتقديم طلبات تحويل الحالة لـ rollup. ستتم معالجة هذه الطلبات من خلال أحد النوى في سلسلة الإعادة، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة الـ rollup.
التوازن في التوسع الرأسي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من هيكل Polkadot متعدد النوى. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن تحقق كتلة rollup لا يتم تنفيذه على نواة معينة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الوسيط هو بروتوكول غير مرخص وغير موثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق منها. قد يستغل المهاجمون هذه النقطة، حيث يقومون بتقديم كتل شرعية تم التحقق منها سابقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي قدرة rollup وكفاءته.
تهدف Polkadot إلى الحفاظ على مرونة rollup واستخدام موارد سلسلة الترحيل بشكل فعال دون التأثير على الخصائص الأساسية للنظام.
مشكلة الثقة في Sequencer
طريقة بسيطة للحل هي ضبط البروتوكول على "مصرح به": مثل استخدام آلية القائمة البيضاء، أو الثقة الافتراضية في أن ترتيبات الثقة لن تتصرف بشكل خبيث، وبالتالي ضمان نشاط rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة بشأن sequencer، لأننا بحاجة إلى الحفاظ على خصائص "بدون ثقة" و"بدون إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل غير متنازل
الخيار النهائي لبولكادوت هو: تسليم المشكلة بالكامل إلى دالة تحويل الحالة للـ rollup (Runtime). الـ Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة من بولكادوت يجب تنفيذ التحقق عليها.
هذا التصميم يحقق ضماناً مزدوجاً للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل الحالة للـ rollup في عملية القابلية للاستخدام، وتضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع الـ core.
قبل كتابة البيانات إلى طبقة توفر البيانات الخاصة بـ Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 موثوقين بالتحقق أولاً من مشروعيتها. إنهم يستقبلون الإيصالات المرشحة وأدلة الصلاحية المقدمة من المنظم، والتي تحتوي على كتلة rollup والأدلة التخزينية المناسبة. سيتم معالجة هذه المعلومات بواسطة دالة التحقق من سلسلة متوازية، وسيتم إعادة تنفيذها بواسطة الموثوقين على سلسلة الترحيل.
تتضمن نتيجة التحقق محدد core لتحديد أي core يجب التحقق من الكتلة عليه. سيقوم المدقق بمقارنة هذا الفهرس مع core الذي يكون مسؤولًا عنه؛ إذا كان غير متطابق، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية أن يظل النظام دائمًا بدون ثقة وبدون إذن، مما يمنع الجهات الفاعلة الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core يمكن الحفاظ على المرونة.
الأمان
في سعيها نحو التوسع، لم تتنازل Polkadot عن الأمان. يتم ضمان أمان rollup من خلال سلسلة الترحيل، حيث يكفي وجود مُرتب صادق للحفاظ على البقاء.
بفضل بروتوكول ELVES، يقوم Polkadot بتوسيع أمانه بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على core، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن لـ Polkadot أن تحقق توسعًا حقيقيًا من خلال rollup دون التضحية بالأمان.
قابلية العموم
لن يحد التوسع المرن من قابلية برمجة الـ rollup. يدعم نموذج الـ rollup الخاص بـ Polkadot تنفيذ حسابات كاملة التوجه في بيئة WebAssembly، طالما أن التنفيذ الفردي يتم في أقل من 2 ثانية. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
تؤدي زيادة السعة الإنتاجية وتقليل الكمون بشكل لا مفر منه إلى إدخال التعقيد، وهو الطريقة الوحيدة المقبولة في تصميم الأنظمة.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد الخاصة بالـ rollup، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التشغيل المتداخل
يدعم Polkadot التداخل بين مختلف rollups، ولن تؤثر التوسعة المرنة على قدرة نقل الرسائل.
تتم اتصالات الرسائل عبر rollup بواسطة طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة لها.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، حيث ستعمل سلسلة الإرسال كواجهة تحكم، وليس كواجهة بيانات. ستعمل هذه الترقيات على تحسين قدرة الاتصال بين rollups جنبًا إلى جنب مع التوسع المرن، مما يعزز بشكل أكبر القدرة العمودية للنظام.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. لكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لPolkadot أقل، فإن أدائها لا يزال غير مرضٍ.
سولانا
لا تعتمد سولانا على هيكل تقسيم بولكادوت أو إيثريوم، بل تحقق القابلية للتوسع من خلال هيكل أحادي الطبقة عالي الإنتاجية، اعتماداً على إثبات التاريخ، المعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق قائمة على القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
أثبت التاريخ أن المعالجة المتوازية تتطلب متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية العقد التحقق. كلما زاد عدد العقد المراهنة، زادت فرصها في إنتاج الكتل، بينما تكاد تكون الفرص المتاحة للعقد الصغيرة معدومة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
تضحي سولانا باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ بولكادوت.
طن
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظل ظروف شبكة ومعدات مثالية. بينما وصلت Polkadot إلى 128K TPS على شبكة عامة غير مركزية.
توجد مخاطر أمان في آلية توافق TON: سوف يتم الكشف عن هوية عقد التحقق المُجزأ مسبقًا. كما يشير المستند الأبيض لـ TON بوضوح إلى أن هذا قد يحسن عرض النطاق الترددي، ولكنه قد يُستغل بشكل ضار. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة تمامًا على كتلة معينة، أو قطع الاتصال بالتحقق الأمين من خلال هجمات DDoS، وبالتالي تعديل الحالة.
بالمقارنة، يتم تخصيص الموثقين في Polkadot عشوائياً، مع الكشف المتأخر، مما يعني أن المهاجمين لا يمكنهم معرفة هوية الموثقين مسبقاً. يتطلب الهجوم السيطرة الكاملة على الموثقين للفوز، وإذا قام موثق واحد نزيه ببدء نزاع، فسيفشل الهجوم مما يؤدي إلى خسارة المهاجم لرأس المال المرهون.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكات الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، و P-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمتحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن أن تضع الشبكة الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تتشارك جميع rollup ضمان الأمان الموحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا بالكامل. إذا كنت ترغب في تعزيز الأمان، فلا بد من تقديم تنازلات في الأداء، ومن الصعب تقديم التزام أمان حاسم.
إيثيريوم
استراتيجية التوسع في الإيثيريوم تعتمد على المراهنة على قابلية التوسع في طبقة الـ rollup، بدلاً من حل المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، فإن معظم التفاف الأمل (Optimistic rollup) مركزي (بعضها يحتوي حتى على sequencer واحد فقط)، مما يؤدي إلى مشاكل تتعلق بعدم كفاية الأمان، والعزلة عن بعضها البعض، وزيادة التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي غالبًا ما تستغرق عدة أيام).
ZK رولاب
إن تنفيذ ZK rollup مقيد بحدود كمية البيانات التي يمكن معالجتها في معاملة واحدة. إن متطلبات حساب إثبات المعرفة الصفرية مرتفعة للغاية، وآلية "الفائز يأخذ كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما يقتصر ZK rollup على حجم المعاملات في كل دفعة، مما قد يتسبب في ازدحام الشبكة وزيادة الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقارنة، تكلفة ZK rollup المجهزة بـ Turing الكاملة حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي لـ Polkadot.
بالإضافة إلى ذلك، ستؤدي مشكلة توفر بيانات ZK rollup إلى تفاقم عيوبه. لضمان قدرة أي شخص على التحقق من المعاملات، لا يزال يتعين تقديم بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع Polkadot الطريق الذي يتم فيه تبادل المركزية بالأداء أو الثقة المسبقة بالكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال توسيع مرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا في الوقت الحاضر، فإن "التوسع بدون ثقة" الذي تتمسك به Polkadot، قد يكون حقًا هو الحل الذي يدعم التطوير طويل الأمد للويب 3.