في ظل السعي المستمر نحو كفاءة أعلى في تكنولوجيا البلوكتشين اليوم، تظهر مسألة رئيسية تدريجياً: كيف يمكن تحسين الأداء دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام Web3، إذا كان النظام الأسرع يعتمد على التضحية بالثقة والأمان، فإنه غالباً ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
ستتناول هذه المقالة بالتفصيل التنازلات والموازنة في تصميم قابلية التوسع في Polkadot، وستقارن الحلول مع سلاسل الكتل العامة الرئيسية الأخرى، وتحلل الاختيارات المختلفة في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المدققين وسلسلة الترحيل (Relay Chain). تعتمد تشغيل Rollup على المُرتب (sequencer) المتصل بسلسلة الترحيل، حيث تستخدم اتصالاتها آلية بروتوكول collator. لا يتطلب هذا البروتوكول أي إذن أو ثقة، يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، وربط عدد قليل من عقد سلسلة الترحيل، وتقديم طلبات تحويل حالة rollup. سيتم التحقق من هذه الطلبات عبر أحد نوى سلسلة الترحيل، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة rollup.
التوازن في التوسع العمودي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن" (Elastic Scaling). خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتلة Rollup لا يتم تنفيذها بشكل ثابت على نواة واحدة، فقد يؤثر ذلك على مرونتها.
نظرًا لأن البروتوكول الخاص بتقديم الكتل إلى سلسلة الوسيطة هو غير مرخص وموثوق به، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق. قد يستغل المهاجمون ذلك من خلال تقديم كتل شرعية تم التحقق منها مسبقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي معدل الإنتاجية والكفاءة لـ rollup.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة الترحيل دون التأثير على الخصائص الأساسية للنظام.
مشكلة الثقة في Sequencer
طريقة بسيطة للحل هي تعيين البروتوكول على أنه "مرخص": على سبيل المثال، استخدام آلية القائمة البيضاء، أو افتراض أن المنظمين الموثوقين لن يقوموا بسلوك ضار، مما يضمن نشاط الـ rollup. ومع ذلك، في تصميم Polkadot، لا يمكننا القيام بأي افتراضات ثقة حول المنظم، لأننا بحاجة إلى الحفاظ على ميزات "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة الـ rollup.
بولكادوت: حل غير متنازل
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل إلى دالة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة من Polkadot يجب تنفيذ التحقق عليها.
تصميم كهذا يحقق ضمانات مزدوجة من المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويلات حالة rollup في عملية التوفر، وتضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة أي كتلة rollup في طبقة توفر البيانات (DA) الخاصة بـ Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين أولاً بالتحقق من شرعيتها. يتلقون الإيصالات المرشحة (candidate receipt) وأدلة الصلاحية (PoV) المقدمة من المنظم، والتي تحتوي على كتلة rollup وإثبات التخزين المناسب. ستتم معالجة هذه المعلومات بواسطة دالة التحقق في السلاسل المتوازية، وسيقوم المدققون على سلسلة الترحيل بإعادة تنفيذها.
نتيجة التحقق تحتوي على محدد core، يُستخدم لتحديد أي core يجب أن يتم التحقق من الكتلة عليه. سيقوم المدقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يتطابق، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية بقاء النظام دائمًا بدون حاجة للثقة وبدون حاجة للإذن، وتتجنب تصرفات الجهات الخبيثة مثل المعالجين في التلاعب بمواقع التحقق، مما يضمن الحفاظ على المرونة حتى عند استخدام عدة نوى في عملية التجميع.
الأمان
في سعيها نحو التوسع، لم تتنازل Polkadot عن الأمان. يتم ضمان أمان rollup من قبل سلسلة الوسيط، حيث يكفي وجود مرتب صادق للحفاظ على البقاء.
بمساعدة بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot توسعًا حقيقيًا دون التضحية بالأمان.
عمومية
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات Turing-complete في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في غضون ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ كل 6 ثوان، ولكن نوع الحسابات لا يتأثر.
تعقيد
إن زيادة معدل نقل البيانات وانخفاض الكمون لا مفر منهما في إدخال تعقيد، وهو التوازن الوحيد المقبول في تصميم الأنظمة.
يمكن لـ Rollup ضبط الموارد ديناميكياً من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليهم تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات استخدام مختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد في rollup، والتي قد تعتمد على متغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة حمولات المعاملات المحددة في ميمبول العقد.
استراتيجيات الأتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمة coretime مسبقًا لتكوين الموارد.
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التفاعل بين الأنظمة
تدعم Polkadot التفاعل بين rollups المختلفة، ولن تؤثر التوسع المرن على قدرة نقل الرسائل.
تتم الاتصالات الرسائل عبر الrollup بواسطة طبقة النقل الأساسية، حيث أن مساحة كتلة الاتصال لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة لها.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة (off-chain messaging)، حيث تكون سلسلة النقل هي واجهة التحكم بدلاً من واجهة البيانات. سيسمح هذا التحديث بتحسين قدرة الاتصال بين rollups مع التوسع المرن، مما يعزز القدرة العمودية للنظام.
الموازنة بين البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالباً ما يأتي على حساب اللامركزية والأمان. ولكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائهم لا يزال غير مرضٍ.
سولانا
سولانا لا تستخدم هيكل تقطيع بولكادوت أو إيثريوم، بل تعتمد على هيكل عالي الإنتاجية من طبقة واحدة لتحقيق القابلية للتوسع، بالاعتماد على إثبات التاريخ (PoH) ومعالجة المعالج المركزي المتوازية وآلية الإجماع القائمة على القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي يتم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل عصر (حوالي يومين أو 432,000 فتحة)، يتم توزيع الفتحات حسب كمية الرهان؛
كلما زادت نسبة الرهن، زادت نسبة التوزيع. على سبيل المثال، فإن رهن 1% من المدققين سيحصل على حوالي 1% من فرص إنشاء الكتل؛
يتم الإعلان عن جميع مُنتجي الكتل مسبقًا، مما يزيد من خطر تعرض الشبكة لهجمات DDoS موجهة، وانقطاع الخدمة بشكل متكرر.
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت كمية الرهان، زادت فرص عقد التحقق في إنتاج الكتل، بينما تكاد تكون الفرص ضئيلة لعقد التحقق الصغيرة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
سولانا sacrifices اللامركزية والقدرة على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.
تون
تدعي 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 بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
Rollup متفائل
في الوقت الحالي، فإن معظم عمليات التمرير المتفائلة مركزية (بعضها يحتوي حتى على منظم واحد فقط)، مما يؤدي إلى قلة الأمان، والعزلة عن بعضها البعض، وتأخير عالٍ (يجب الانتظار لفترة إثبات الاحتيال، والتي عادة ما تكون عدة أيام).
ZK رول أب
تتأثر تنفيذ ZK rollup بحدود كمية البيانات القابلة للمعالجة لكل معاملة واحدة. تتطلب حسابات توليد الإثباتات الصفرية معرفة عالية، كما أن آلية "الفائز يأخذ كل شيء" قد تؤدي إلى مركزية النظام. لضمان TPS، غالبًا ما تحد ZK rollup من حجم المعاملات لكل دفعة، مما قد يؤدي إلى ازدحام الشبكة وارتفاع تكاليف الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقابل، تكاليف ZK rollup القابلة للتوجيه تساوي تقريبًا 2x10^6 مرة من بروتوكول أمان الاقتصاد المشفر الأساسي في Polkadot.
علاوة على ذلك، ستؤدي مشكلة توفر بيانات ZK rollup إلى تفاقم عيوبها. لضمان قدرة أي شخص على التحقق من المعاملات، يجب توفير بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع، يجب أن لا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تسلك Polkadot طريق التنازل عن اللامركزية من أجل الأداء أو الثقة المسبقة من أجل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، وطبقة أمان موحدة، وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات واسعة النطاق اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور الطويل الأمد لـ Web3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 9
أعجبني
9
6
مشاركة
تعليق
0/400
GateUser-a5fa8bd0
· منذ 1 س
يجب أن تتعلم dot جيدًا! المهنة القديمة لم تعد موثوقة.
شاهد النسخة الأصليةرد0
AirdropworkerZhang
· 08-01 00:33
هذه الكفاءة عالية جداً وتكلفتها منخفضة جداً، سأذهب للتعدين يا رئيس.
شاهد النسخة الأصليةرد0
MEVHunter
· 07-31 10:51
meh... سلسلة النقل الخاصة بـ dot لا تزال تعاني من نقص تحت ضغط كبير من mempool بصراحة. رأيت ارتفاعات سلبية في التدفق الأسبوع الماضي
شاهد النسخة الأصليةرد0
Lonely_Validator
· 07-31 10:51
لقد كنت لاعباً قديمًا في الشبكة العامة، وDot كانت محبوبة طوال الوقت.
توسع بولكادوت المرن: توازن الأداء والأمان في Web3 دون تنازلات
توازن قابلية توسع البلوكتشين: مثال على Polkadot
في ظل السعي المستمر نحو كفاءة أعلى في تكنولوجيا البلوكتشين اليوم، تظهر مسألة رئيسية تدريجياً: كيف يمكن تحسين الأداء دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام Web3، إذا كان النظام الأسرع يعتمد على التضحية بالثقة والأمان، فإنه غالباً ما يكون من الصعب دعم الابتكار المستدام الحقيقي.
ستتناول هذه المقالة بالتفصيل التنازلات والموازنة في تصميم قابلية التوسع في Polkadot، وستقارن الحلول مع سلاسل الكتل العامة الرئيسية الأخرى، وتحلل الاختيارات المختلفة في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المدققين وسلسلة الترحيل (Relay Chain). تعتمد تشغيل Rollup على المُرتب (sequencer) المتصل بسلسلة الترحيل، حيث تستخدم اتصالاتها آلية بروتوكول collator. لا يتطلب هذا البروتوكول أي إذن أو ثقة، يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، وربط عدد قليل من عقد سلسلة الترحيل، وتقديم طلبات تحويل حالة rollup. سيتم التحقق من هذه الطلبات عبر أحد نوى سلسلة الترحيل، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة rollup.
التوازن في التوسع العمودي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن" (Elastic Scaling). خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتلة Rollup لا يتم تنفيذها بشكل ثابت على نواة واحدة، فقد يؤثر ذلك على مرونتها.
نظرًا لأن البروتوكول الخاص بتقديم الكتل إلى سلسلة الوسيطة هو غير مرخص وموثوق به، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق. قد يستغل المهاجمون ذلك من خلال تقديم كتل شرعية تم التحقق منها مسبقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي معدل الإنتاجية والكفاءة لـ rollup.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة الترحيل دون التأثير على الخصائص الأساسية للنظام.
مشكلة الثقة في Sequencer
طريقة بسيطة للحل هي تعيين البروتوكول على أنه "مرخص": على سبيل المثال، استخدام آلية القائمة البيضاء، أو افتراض أن المنظمين الموثوقين لن يقوموا بسلوك ضار، مما يضمن نشاط الـ rollup. ومع ذلك، في تصميم Polkadot، لا يمكننا القيام بأي افتراضات ثقة حول المنظم، لأننا بحاجة إلى الحفاظ على ميزات "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة الـ rollup.
بولكادوت: حل غير متنازل
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل إلى دالة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة من Polkadot يجب تنفيذ التحقق عليها.
تصميم كهذا يحقق ضمانات مزدوجة من المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويلات حالة rollup في عملية التوفر، وتضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة أي كتلة rollup في طبقة توفر البيانات (DA) الخاصة بـ Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين أولاً بالتحقق من شرعيتها. يتلقون الإيصالات المرشحة (candidate receipt) وأدلة الصلاحية (PoV) المقدمة من المنظم، والتي تحتوي على كتلة rollup وإثبات التخزين المناسب. ستتم معالجة هذه المعلومات بواسطة دالة التحقق في السلاسل المتوازية، وسيقوم المدققون على سلسلة الترحيل بإعادة تنفيذها.
نتيجة التحقق تحتوي على محدد core، يُستخدم لتحديد أي core يجب أن يتم التحقق من الكتلة عليه. سيقوم المدقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يتطابق، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية بقاء النظام دائمًا بدون حاجة للثقة وبدون حاجة للإذن، وتتجنب تصرفات الجهات الخبيثة مثل المعالجين في التلاعب بمواقع التحقق، مما يضمن الحفاظ على المرونة حتى عند استخدام عدة نوى في عملية التجميع.
الأمان
في سعيها نحو التوسع، لم تتنازل Polkadot عن الأمان. يتم ضمان أمان rollup من قبل سلسلة الوسيط، حيث يكفي وجود مرتب صادق للحفاظ على البقاء.
بمساعدة بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot توسعًا حقيقيًا دون التضحية بالأمان.
عمومية
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات Turing-complete في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في غضون ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ كل 6 ثوان، ولكن نوع الحسابات لا يتأثر.
تعقيد
إن زيادة معدل نقل البيانات وانخفاض الكمون لا مفر منهما في إدخال تعقيد، وهو التوازن الوحيد المقبول في تصميم الأنظمة.
يمكن لـ Rollup ضبط الموارد ديناميكياً من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليهم تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات استخدام مختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد في rollup، والتي قد تعتمد على متغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التفاعل بين الأنظمة
تدعم Polkadot التفاعل بين rollups المختلفة، ولن تؤثر التوسع المرن على قدرة نقل الرسائل.
تتم الاتصالات الرسائل عبر الrollup بواسطة طبقة النقل الأساسية، حيث أن مساحة كتلة الاتصال لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة لها.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة (off-chain messaging)، حيث تكون سلسلة النقل هي واجهة التحكم بدلاً من واجهة البيانات. سيسمح هذا التحديث بتحسين قدرة الاتصال بين rollups مع التوسع المرن، مما يعزز القدرة العمودية للنظام.
الموازنة بين البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالباً ما يأتي على حساب اللامركزية والأمان. ولكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائهم لا يزال غير مرضٍ.
سولانا
سولانا لا تستخدم هيكل تقطيع بولكادوت أو إيثريوم، بل تعتمد على هيكل عالي الإنتاجية من طبقة واحدة لتحقيق القابلية للتوسع، بالاعتماد على إثبات التاريخ (PoH) ومعالجة المعالج المركزي المتوازية وآلية الإجماع القائمة على القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي يتم الكشف عنها مسبقًا ويمكن التحقق منها:
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت كمية الرهان، زادت فرص عقد التحقق في إنتاج الكتل، بينما تكاد تكون الفرص ضئيلة لعقد التحقق الصغيرة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
سولانا sacrifices اللامركزية والقدرة على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.
تون
تدعي 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 بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
Rollup متفائل
في الوقت الحالي، فإن معظم عمليات التمرير المتفائلة مركزية (بعضها يحتوي حتى على منظم واحد فقط)، مما يؤدي إلى قلة الأمان، والعزلة عن بعضها البعض، وتأخير عالٍ (يجب الانتظار لفترة إثبات الاحتيال، والتي عادة ما تكون عدة أيام).
ZK رول أب
تتأثر تنفيذ ZK rollup بحدود كمية البيانات القابلة للمعالجة لكل معاملة واحدة. تتطلب حسابات توليد الإثباتات الصفرية معرفة عالية، كما أن آلية "الفائز يأخذ كل شيء" قد تؤدي إلى مركزية النظام. لضمان TPS، غالبًا ما تحد ZK rollup من حجم المعاملات لكل دفعة، مما قد يؤدي إلى ازدحام الشبكة وارتفاع تكاليف الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقابل، تكاليف ZK rollup القابلة للتوجيه تساوي تقريبًا 2x10^6 مرة من بروتوكول أمان الاقتصاد المشفر الأساسي في Polkadot.
علاوة على ذلك، ستؤدي مشكلة توفر بيانات ZK rollup إلى تفاقم عيوبها. لضمان قدرة أي شخص على التحقق من المعاملات، يجب توفير بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع، يجب أن لا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تسلك Polkadot طريق التنازل عن اللامركزية من أجل الأداء أو الثقة المسبقة من أجل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، وطبقة أمان موحدة، وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات واسعة النطاق اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور الطويل الأمد لـ Web3.