التوازن والتنازلات في قابلية توسيع البلوكتشين: مثال على Polkadot
في عصر تسعى فيه تقنية البلوكتشين لتحقيق كفاءة أعلى، بدأت تظهر مشكلة رئيسية: كيف يمكن تحسين الأداء بالتوازي مع الحفاظ على الأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهياكل. بالنسبة لنظام Web3، إذا كان النظام الأسرع يعتمد على التضحية بالثقة والأمان، فعادة ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
بصفتها محركًا مهمًا لتوسيع Web3، هل قدمت Polkadot بعض التضحيات أيضًا تحت هدف ارتفاع الإنتاجية وانخفاض الكمون؟ هل قدم نموذجها للـ rollup تنازلات في اللامركزية أو الأمان أو التشغيل المتداخل للشبكة؟ ستتناول هذه المقالة هذه الأسئلة، وتقوم بتحليل عميق للتوازنات والاختيارات التي قامت بها Polkadot في تصميم التوسع، وتقارنها بحلول سلاسل الكتل الرئيسية الأخرى، مستكشفةً اختلافات اختيارها في الأداء والأمان واللامركزية.
تحديات تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المُحققين وسلسلة الترحيل، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على ميزاتها اللامركزية؟
تعتمد عملية Rollup على مُرتب سلسلة الكتل المتصلة بسلسلة النقل، حيث تستخدم اتصالاتها آلية تُعرف باسم بروتوكول collator. هذا البروتوكول لا يحتاج إلى إذن أو ثقة، يمكن لأي شخص لديه اتصال بالشبكة استخدامه، وربط عدد قليل من عقد سلسلة النقل، وتقديم طلبات تحويل حالة rollup. سيتم التحقق من هذه الطلبات من قبل أحد النوى في سلسلة النقل، بشرط واحد: يجب أن تكون تحويلات الحالة صالحة، وإلا لن يتم تقدم حالة الـ rollup.
توازن التوسع العمودي
يمكن لـ Rollup تحقيق التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة معينة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الوسيطة هو بلا إذن وبدون ثقة، يمكن لأي شخص تقديم الكتل إلى أي core تم تخصيصه للـ rollup للتحقق. قد يستغل المهاجمون هذه النقطة، من خلال تقديم الكتل الشرعية التي تم التحقق منها سابقًا مرارًا وتكرارًا إلى core مختلفة، مما يستهلك الموارد بشكل خبيث، وبالتالي يقلل من إجمالي قدرة الـ rollup وكفاءته.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة النقل دون التأثير على الخصائص الأساسية للنظام.
هل يمكن الوثوق بـ Sequencer؟
طريقة بسيطة للحل هي تعيين البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو الثقة بشكل افتراضي في المنظمين الذين لا يتصرفون بشكل ضار، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة حول sequencer، لأنه يجب الحفاظ على خصائص النظام "بدون ثقة" و"بدون إذن". يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
Polkadot: حل غير متسامح
الخيار النهائي لـ Polkadot هو: ترك المشكلة تُحل تمامًا بواسطة دالة تحويل حالة rollup (Runtime). Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذا يجب توضيح في المخرجات أين يجب تنفيذ التحقق على نواة Polkadot.
هذا التصميم يحقق ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوافر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة تخصيص core.
قبل كتابة أي كتلة rollup على طبقة توفر البيانات الخاصة بـ Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين أولاً بالتحقق من صحتها. يتلقون الإيصالات المرشحة وأدلة الصلاحية التي يقدمها الفرز، والتي تتضمن كتلة rollup وإثبات التخزين المقابل. ستتم معالجة هذه المعلومات بواسطة دالة تحقق السلاسل المتوازية، ليقوم المدققون على سلسلة النقل بإعادة تنفيذها.
تتضمن نتيجة التحقق محدد core، لتحديد أي core يجب التحقق من الكتلة عليه. سيقارن المدقق هذا الفهرس مع core الذي هو مسؤول عنه؛ إذا لم يتطابق، سيتمdiscard الكتلة.
تضمن هذه الآلية أن يظل النظام دائمًا خاليًا من الثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، مما يضمن أنه حتى عند استخدام رول أب لعدة نوى، يمكن الحفاظ على المرونة.
الأمان
في سعيها لتحقيق القابلية للتوسع، لم تقم 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 المختلفة، بينما لن تؤثر التوسعة المرنة على قدرة نقل الرسائل.
التواصل بين الرسائل عبر rollup يتم تحقيقه من خلال طبقة النقل الأساسية، حيث تكون مساحة الكتل التواصلية لكل rollup ثابتة، ولا تتعلق بعدد النواة المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، حيث ستعمل سلسلة التتابع كواجهة تحكم، بدلاً من واجهة البيانات. ستعزز هذه الترقية قدرة الاتصال بين الـrollups مع زيادة المرونة، مما يعزز قدرة النظام على التوسع الرأسي.
ما التنازلات التي قدمتها البروتوكولات الأخرى؟
من المعروف أن تحسين الأداء غالبا ما يأتي على حساب اللامركزية والأمان. ولكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لPolkadot منخفضة، فإن أدائها لا يزال غير مرضٍ.
سولانا
لا تعتمد سولانا على بنية الشظايا الخاصة بـ بولكادوت أو إيثريوم، بل تحقق التوسع من خلال بنية أحادية عالية الإنتاجية، وتعتمد على إثبات التاريخ، والمعالجة المتوازية لوحدة المعالجة المركزية، وآلية إجماع قائمة على القيادة، ويمكن أن تصل نظرية TPS إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل epoch (حوالي يومين أو 432,000 slot) ، يتم تخصيص slots بناءً على كمية الرهان؛
كلما زاد الرهان، زادت التوزيعات. على سبيل المثال، سيحصل المدقق الذي يراهن 1% على حوالي 1% من فرص إنشاء الكتل؛
جميع مُصدري الكتل يُعلنون مسبقًا، مما يزيد من خطر تعرض الشبكة لهجمات DDoS موجهة أو انقطاع الخدمة بشكل متكرر.
التاريخ يثبت أن المعالجة المتوازية تتطلب متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت حصة العقد، زادت فرصة إنتاج الكتل، والعقد الصغيرة ليس لديها تقريبًا أي slots، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجمات.
سولانا sacrificed اللامركزية ومقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.
طن
تدعي TON أن TPS يمكن أن تصل إلى 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: تقليل عبء الشارد الفردي لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة بحرية في الشبكات الفرعية، ويمكن تعيين متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشترك جميع rollup في ضمان أمان موحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، ستحتاج إلى تقديم تنازلات في الأداء، ومن الصعب توفير التزام أمان محدد.
إيثريوم
استراتيجية التوسع في الإيثيريوم تعتمد على الرهانات على قابلية التوسع في طبقة الــrollup، بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، فإن معظم عمليات التحجيم المتفائلة (Optimistic rollup) مركزية (بعضها تحتوي حتى على sequencer واحد فقط)، مما يؤدي إلى مشكلات تتعلق بعدم كفاية الأمان، والعزلة عن بعضها البعض، وارتفاع التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي تستغرق عادةً عدة أيام).
زك رول أب
تواجه عملية تنفيذ ZK rollup قيودًا على كمية البيانات التي يمكن معالجتها في معاملة واحدة. الطلب على حسابات إثبات المعرفة الصفرية مرتفع للغاية، وآلية "الفائز يأخذ كل شيء" قد تؤدي إلى مركزية النظام. لضمان TPS، غالبًا ما يحدد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى الازدحام في الشبكة وزيادة الغاز، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القادر على تيرلنغ تبلغ حوالي 2x10^6 ضعف تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي في بولكادوت.
بالإضافة إلى ذلك، ستزيد مشكلة توفر البيانات في ZK rollup من عيوبها. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين توفير بيانات المعاملات الكاملة. وهذا يعتمد غالبًا على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع، يجب أن لا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم يتبع Polkadot طريق المركزية مقابل الأداء، أو الثقة المسبقة مقابل الكفاءة، بل حقق توازنًا متعدد الأبعاد بين الأمان، واللامركزية، والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، طبقات أمان موحدة، وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا في الوقت الحاضر، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور طويل الأجل للويب 3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
توسيع بولكادوت المرن: السعي لتحقيق التوازن بين الأداء واللامركزية
التوازن والتنازلات في قابلية توسيع البلوكتشين: مثال على Polkadot
في عصر تسعى فيه تقنية البلوكتشين لتحقيق كفاءة أعلى، بدأت تظهر مشكلة رئيسية: كيف يمكن تحسين الأداء بالتوازي مع الحفاظ على الأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهياكل. بالنسبة لنظام Web3، إذا كان النظام الأسرع يعتمد على التضحية بالثقة والأمان، فعادة ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
بصفتها محركًا مهمًا لتوسيع Web3، هل قدمت Polkadot بعض التضحيات أيضًا تحت هدف ارتفاع الإنتاجية وانخفاض الكمون؟ هل قدم نموذجها للـ rollup تنازلات في اللامركزية أو الأمان أو التشغيل المتداخل للشبكة؟ ستتناول هذه المقالة هذه الأسئلة، وتقوم بتحليل عميق للتوازنات والاختيارات التي قامت بها Polkadot في تصميم التوسع، وتقارنها بحلول سلاسل الكتل الرئيسية الأخرى، مستكشفةً اختلافات اختيارها في الأداء والأمان واللامركزية.
تحديات تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المُحققين وسلسلة الترحيل، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على ميزاتها اللامركزية؟
تعتمد عملية Rollup على مُرتب سلسلة الكتل المتصلة بسلسلة النقل، حيث تستخدم اتصالاتها آلية تُعرف باسم بروتوكول collator. هذا البروتوكول لا يحتاج إلى إذن أو ثقة، يمكن لأي شخص لديه اتصال بالشبكة استخدامه، وربط عدد قليل من عقد سلسلة النقل، وتقديم طلبات تحويل حالة rollup. سيتم التحقق من هذه الطلبات من قبل أحد النوى في سلسلة النقل، بشرط واحد: يجب أن تكون تحويلات الحالة صالحة، وإلا لن يتم تقدم حالة الـ rollup.
توازن التوسع العمودي
يمكن لـ Rollup تحقيق التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة معينة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الوسيطة هو بلا إذن وبدون ثقة، يمكن لأي شخص تقديم الكتل إلى أي core تم تخصيصه للـ rollup للتحقق. قد يستغل المهاجمون هذه النقطة، من خلال تقديم الكتل الشرعية التي تم التحقق منها سابقًا مرارًا وتكرارًا إلى core مختلفة، مما يستهلك الموارد بشكل خبيث، وبالتالي يقلل من إجمالي قدرة الـ rollup وكفاءته.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة النقل دون التأثير على الخصائص الأساسية للنظام.
هل يمكن الوثوق بـ Sequencer؟
طريقة بسيطة للحل هي تعيين البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو الثقة بشكل افتراضي في المنظمين الذين لا يتصرفون بشكل ضار، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة حول sequencer، لأنه يجب الحفاظ على خصائص النظام "بدون ثقة" و"بدون إذن". يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
Polkadot: حل غير متسامح
الخيار النهائي لـ Polkadot هو: ترك المشكلة تُحل تمامًا بواسطة دالة تحويل حالة rollup (Runtime). Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذا يجب توضيح في المخرجات أين يجب تنفيذ التحقق على نواة Polkadot.
هذا التصميم يحقق ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوافر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة تخصيص core.
قبل كتابة أي كتلة rollup على طبقة توفر البيانات الخاصة بـ Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين أولاً بالتحقق من صحتها. يتلقون الإيصالات المرشحة وأدلة الصلاحية التي يقدمها الفرز، والتي تتضمن كتلة rollup وإثبات التخزين المقابل. ستتم معالجة هذه المعلومات بواسطة دالة تحقق السلاسل المتوازية، ليقوم المدققون على سلسلة النقل بإعادة تنفيذها.
تتضمن نتيجة التحقق محدد core، لتحديد أي core يجب التحقق من الكتلة عليه. سيقارن المدقق هذا الفهرس مع core الذي هو مسؤول عنه؛ إذا لم يتطابق، سيتمdiscard الكتلة.
تضمن هذه الآلية أن يظل النظام دائمًا خاليًا من الثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، مما يضمن أنه حتى عند استخدام رول أب لعدة نوى، يمكن الحفاظ على المرونة.
الأمان
في سعيها لتحقيق القابلية للتوسع، لم تقم 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 المختلفة، بينما لن تؤثر التوسعة المرنة على قدرة نقل الرسائل.
التواصل بين الرسائل عبر rollup يتم تحقيقه من خلال طبقة النقل الأساسية، حيث تكون مساحة الكتل التواصلية لكل rollup ثابتة، ولا تتعلق بعدد النواة المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، حيث ستعمل سلسلة التتابع كواجهة تحكم، بدلاً من واجهة البيانات. ستعزز هذه الترقية قدرة الاتصال بين الـrollups مع زيادة المرونة، مما يعزز قدرة النظام على التوسع الرأسي.
ما التنازلات التي قدمتها البروتوكولات الأخرى؟
من المعروف أن تحسين الأداء غالبا ما يأتي على حساب اللامركزية والأمان. ولكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لPolkadot منخفضة، فإن أدائها لا يزال غير مرضٍ.
سولانا
لا تعتمد سولانا على بنية الشظايا الخاصة بـ بولكادوت أو إيثريوم، بل تحقق التوسع من خلال بنية أحادية عالية الإنتاجية، وتعتمد على إثبات التاريخ، والمعالجة المتوازية لوحدة المعالجة المركزية، وآلية إجماع قائمة على القيادة، ويمكن أن تصل نظرية TPS إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل epoch (حوالي يومين أو 432,000 slot) ، يتم تخصيص slots بناءً على كمية الرهان؛
كلما زاد الرهان، زادت التوزيعات. على سبيل المثال، سيحصل المدقق الذي يراهن 1% على حوالي 1% من فرص إنشاء الكتل؛
جميع مُصدري الكتل يُعلنون مسبقًا، مما يزيد من خطر تعرض الشبكة لهجمات DDoS موجهة أو انقطاع الخدمة بشكل متكرر.
التاريخ يثبت أن المعالجة المتوازية تتطلب متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت حصة العقد، زادت فرصة إنتاج الكتل، والعقد الصغيرة ليس لديها تقريبًا أي slots، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجمات.
سولانا sacrificed اللامركزية ومقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.
طن
تدعي TON أن TPS يمكن أن تصل إلى 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: تقليل عبء الشارد الفردي لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة بحرية في الشبكات الفرعية، ويمكن تعيين متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشترك جميع rollup في ضمان أمان موحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، ستحتاج إلى تقديم تنازلات في الأداء، ومن الصعب توفير التزام أمان محدد.
إيثريوم
استراتيجية التوسع في الإيثيريوم تعتمد على الرهانات على قابلية التوسع في طبقة الــrollup، بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، فإن معظم عمليات التحجيم المتفائلة (Optimistic rollup) مركزية (بعضها تحتوي حتى على sequencer واحد فقط)، مما يؤدي إلى مشكلات تتعلق بعدم كفاية الأمان، والعزلة عن بعضها البعض، وارتفاع التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي تستغرق عادةً عدة أيام).
زك رول أب
تواجه عملية تنفيذ ZK rollup قيودًا على كمية البيانات التي يمكن معالجتها في معاملة واحدة. الطلب على حسابات إثبات المعرفة الصفرية مرتفع للغاية، وآلية "الفائز يأخذ كل شيء" قد تؤدي إلى مركزية النظام. لضمان TPS، غالبًا ما يحدد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى الازدحام في الشبكة وزيادة الغاز، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القادر على تيرلنغ تبلغ حوالي 2x10^6 ضعف تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي في بولكادوت.
بالإضافة إلى ذلك، ستزيد مشكلة توفر البيانات في ZK rollup من عيوبها. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين توفير بيانات المعاملات الكاملة. وهذا يعتمد غالبًا على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع، يجب أن لا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم يتبع Polkadot طريق المركزية مقابل الأداء، أو الثقة المسبقة مقابل الكفاءة، بل حقق توازنًا متعدد الأبعاد بين الأمان، واللامركزية، والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، طبقات أمان موحدة، وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا في الوقت الحاضر، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور طويل الأجل للويب 3.