توازن قابلية التوسع والأمان: تصميم بنية Web3 في Polkadot
في عصر تسعى فيه تقنية 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: حل لا يتنازل
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل لوظيفة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذا يجب أن يتم الإعلان بوضوح في المخرجات عن أي نواة من نوى Polkadot يجب تنفيذ التحقق عليها.
هذا التصميم يضمن حماية مزدوجة من المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويلات حالة rollup في عملية التوافر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة البيانات إلى طبقة قابلية الاستخدام في Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 مصدقين بالتحقق من صحتها أولاً. يتلقون الإيصالات المرشحة وأدلة الصلاحية التي يقدمها المنظم، والتي تحتوي على كتلة rollup والأدلة التخزينية المقابلة. سيتم تسليم هذه المعلومات لمعالجة دالة التحقق في السلسلة المتوازية، حيث يقوم المصدقون على سلسلة الإرسال بتنفيذها مرة أخرى.
تتضمن نتائج التحقق محدد core، والذي يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. يقوم المُحقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يكن متطابقًا، فسيتم التخلص من تلك الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الإذن، وتجنب تصرفات الجهات الخبيثة مثل مرتبي الصفوف من التلاعب بمواقع التحقق، مما يضمن المرونة حتى عند استخدام rollup لعدة cores.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل بولكادوت عن الأمان. يتم تأمين أمان الـ rollup بواسطة سلسلة الإرسال، حيث يكفي وجود مُرتب صادق للحفاظ على البقاء.
بفضل بروتوكول ELVES، يقوم Polkadot بتوسيع أمانه بشكل كامل إلى جميع rollups، ويقوم بالتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات بشأن عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot توسيعاً حقيقياً دون التضحية بالأمان.
قابلية استخدام
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في غضون 2 ثانية. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، ولكن نوع الحسابات لا يتأثر.
التعقيد
تؤدي القدرة العالية على المعالجة وانخفاض التأخير بشكل لا مفر منه إلى إدخال التعقيد، وهي الطريقة الوحيدة المقبولة للتوازن في تصميم الأنظمة.
يمكن لـ Rollup ضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات استخدام مختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد الخاصة بالـ rollup، والتي قد تعتمد على المتغيرات الموجودة على السلسلة أو خارجها. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا كمية ثابتة من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة الوزن: مراقبة أحمال المعاملات المحددة في ميمبول العقد.
استراتيجيات الأتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمة coretime مسبقًا لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار قد ارتفعت بشكل ملحوظ.
التداخل
تدعم بولكادوت التفاعل بين مختلف rollups ، بينما لا تؤثر التوسيع المرن على سعة نقل الرسائل.
تتم عملية الاتصال بين الرسائل عبر rollup بواسطة طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا ترتبط بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضاً نقل الرسائل خارج السلسلة، حيث ستكون سلسلة الترحيل هي واجهة التحكم بدلاً من واجهة البيانات. ستعمل هذه الترقية على تحسين قدرات الاتصال بين الـ rollups مع تحسين قابلية التوسع المرنة، مما يعزز قدرة النظام على التوسع العمودي بشكل أكبر.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت بعض منافسي بولكادوت أقل في مستوى اللامركزية، فإن أدائها ليس مرضيًا.
سولانا
لا تعتمد سولانا على هيكل تقسيم بولكادوت أو إيثريوم، بل تحقق التوسع من خلال هيكل أحادي الطبقة عالي الإنتاجية، معتمدة على إثبات التاريخ، المعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق مبنية على القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل عصر (حوالي يومين أو 432,000 موضع) يتم توزيع المواضع وفقًا لمقدار الرهان؛
كلما زادت نسبة التوكيلات، زادت كمية التوزيع. على سبيل المثال، سيحصل المندوب الذي يوكّل 1% على فرصة كتلة تقدر بحوالي 1%.
جميع مُصدري الكتل أعلنوا مسبقاً، مما زاد من خطر تعرض الشبكة لهجمات DDoS مستهدفة، وتكرار الأعطال.
تثبت التاريخ أن المعالجة المتوازية تتطلب متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زادت الرهانات، زادت فرص العقد في إنتاج الكتل، بينما لا تملك العقد الصغيرة تقريبًا أي فرصة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
تضحي سولانا باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS ، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط ، وهو أقل بكثير من 172 الخاص بـ Polkadot.
تون
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تحقق في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف مثالية من الشبكة والعتاد. بينما حققت Polkadot 128K TPS على شبكة عامة لامركزية.
آلية توافق TON تحتوي على مخاطر أمان: هوية عقد تحقق الشظايا سيتم الكشف عنها مسبقًا. كما أشار البيان الأبيض لـ TON بوضوح إلى أن هذا قد يحسن عرض النطاق الترددي، لكنه قد يُستغل من قبل جهات خبيثة. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا تمامًا من السيطرة على شظية معينة، أو من خلال هجمات DDoS لقطع الوصول عن المدققين الأمناء، وبالتالي تعديل الحالة.
بالمقارنة، يتم تعيين مدققي Polkadot بشكل عشوائي وكشفهم بتأخير، ولا يمكن للمهاجمين معرفة هوية المدققين مسبقًا، ويجب عليهم المجازفة بالتحكم بالكامل لتحقيق النجاح، طالما أن هناك مدققًا واحدًا نزيهًا يبدأ نزاعًا، ستفشل الهجمة وتؤدي إلى خسارة المهاجم للرهانات.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، و P-Chain (إدارة المُصادقين والشبكات الفرعية).
يمكن أن يصل TPS النظري لكل شبكة فرعية إلى حوالي 5000، على غرار فكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن ضبط الشبكة الفرعية لتلبية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تتشارك جميع rollup في ضمان أمان موحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في تعزيز الأمان، فسيتعين عليك التنازل عن الأداء، ومن الصعب تقديم التزام أمان حاسم.
إيثيريوم
استراتيجية توسيع إيثريوم تعتمد على الرهان على قابلية التوسع في طبقة رول أب بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
الطبقة التفاؤلية
في الوقت الحالي، تعتبر معظم تقنيات Optimistic Rollup مركزية، مما يؤدي إلى مشاكل مثل ضعف الأمان، والعزلة بين بعضها البعض، وارتفاع التأخير (حيث يتعين انتظار فترة إثبات الاحتيال، والتي تستغرق عادةً عدة أيام).
زك رول اب
تواجه تنفيذات ZK rollup قيودًا على كمية البيانات التي يمكن معالجتها في معاملة واحدة. المتطلبات الحسابية لإنشاء إثبات المعرفة الصفرية مرتفعة للغاية، وآلية "الفائز يحصل على كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما يقتصر ZK rollup على كمية المعاملات لكل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup الكامل لتورينغ تبلغ حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي لـ Polkadot.
بالإضافة إلى ذلك، ستؤدي مشكلات توفر البيانات في ZK rollup إلى تفاقم عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، يجب توفير بيانات المعاملات الكاملة. يعتمد ذلك عادةً على حلول توفر البيانات الإضافية، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع بولكادوت طريق المركزية مقابل الأداء، أو الثقة المسبقة مقابل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان، واللامركزية، والأداء العالي من خلال التوسع المرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر نطاقًا اليوم، قد تكون "الامتداد غير الموثوق" الذي تتمسك به بولكادوت هو الحل الحقيقي الذي يمكن أن يدعم التطور على المدى الطويل لـ Web3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 19
أعجبني
19
5
مشاركة
تعليق
0/400
NFT_Therapy
· 07-16 00:58
مرة أخرى أرى صديقي القديم dot!
شاهد النسخة الأصليةرد0
LayerZeroHero
· 07-14 19:38
من المؤكد أن هناك تنازلات، ولا يزال يتعين إجراء اختبارات قياسية للتحقق من ذلك...
بنية Web3 الخاصة بـ Polkadot: التوازن المثالي بين القابلية للتوسع والأمان
توازن قابلية التوسع والأمان: تصميم بنية Web3 في Polkadot
في عصر تسعى فيه تقنية 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: حل لا يتنازل
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل لوظيفة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذا يجب أن يتم الإعلان بوضوح في المخرجات عن أي نواة من نوى Polkadot يجب تنفيذ التحقق عليها.
هذا التصميم يضمن حماية مزدوجة من المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويلات حالة rollup في عملية التوافر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة البيانات إلى طبقة قابلية الاستخدام في Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 مصدقين بالتحقق من صحتها أولاً. يتلقون الإيصالات المرشحة وأدلة الصلاحية التي يقدمها المنظم، والتي تحتوي على كتلة rollup والأدلة التخزينية المقابلة. سيتم تسليم هذه المعلومات لمعالجة دالة التحقق في السلسلة المتوازية، حيث يقوم المصدقون على سلسلة الإرسال بتنفيذها مرة أخرى.
تتضمن نتائج التحقق محدد core، والذي يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. يقوم المُحقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يكن متطابقًا، فسيتم التخلص من تلك الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الإذن، وتجنب تصرفات الجهات الخبيثة مثل مرتبي الصفوف من التلاعب بمواقع التحقق، مما يضمن المرونة حتى عند استخدام rollup لعدة cores.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل بولكادوت عن الأمان. يتم تأمين أمان الـ rollup بواسطة سلسلة الإرسال، حيث يكفي وجود مُرتب صادق للحفاظ على البقاء.
بفضل بروتوكول ELVES، يقوم Polkadot بتوسيع أمانه بشكل كامل إلى جميع rollups، ويقوم بالتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات بشأن عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot توسيعاً حقيقياً دون التضحية بالأمان.
قابلية استخدام
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في غضون 2 ثانية. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، ولكن نوع الحسابات لا يتأثر.
التعقيد
تؤدي القدرة العالية على المعالجة وانخفاض التأخير بشكل لا مفر منه إلى إدخال التعقيد، وهي الطريقة الوحيدة المقبولة للتوازن في تصميم الأنظمة.
يمكن لـ Rollup ضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات استخدام مختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد الخاصة بالـ rollup، والتي قد تعتمد على المتغيرات الموجودة على السلسلة أو خارجها. على سبيل المثال:
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار قد ارتفعت بشكل ملحوظ.
التداخل
تدعم بولكادوت التفاعل بين مختلف rollups ، بينما لا تؤثر التوسيع المرن على سعة نقل الرسائل.
تتم عملية الاتصال بين الرسائل عبر rollup بواسطة طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا ترتبط بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضاً نقل الرسائل خارج السلسلة، حيث ستكون سلسلة الترحيل هي واجهة التحكم بدلاً من واجهة البيانات. ستعمل هذه الترقية على تحسين قدرات الاتصال بين الـ rollups مع تحسين قابلية التوسع المرنة، مما يعزز قدرة النظام على التوسع العمودي بشكل أكبر.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت بعض منافسي بولكادوت أقل في مستوى اللامركزية، فإن أدائها ليس مرضيًا.
سولانا
لا تعتمد سولانا على هيكل تقسيم بولكادوت أو إيثريوم، بل تحقق التوسع من خلال هيكل أحادي الطبقة عالي الإنتاجية، معتمدة على إثبات التاريخ، المعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق مبنية على القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
تثبت التاريخ أن المعالجة المتوازية تتطلب متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زادت الرهانات، زادت فرص العقد في إنتاج الكتل، بينما لا تملك العقد الصغيرة تقريبًا أي فرصة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
تضحي سولانا باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS ، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط ، وهو أقل بكثير من 172 الخاص بـ Polkadot.
تون
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تحقق في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف مثالية من الشبكة والعتاد. بينما حققت Polkadot 128K TPS على شبكة عامة لامركزية.
آلية توافق TON تحتوي على مخاطر أمان: هوية عقد تحقق الشظايا سيتم الكشف عنها مسبقًا. كما أشار البيان الأبيض لـ TON بوضوح إلى أن هذا قد يحسن عرض النطاق الترددي، لكنه قد يُستغل من قبل جهات خبيثة. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا تمامًا من السيطرة على شظية معينة، أو من خلال هجمات DDoS لقطع الوصول عن المدققين الأمناء، وبالتالي تعديل الحالة.
بالمقارنة، يتم تعيين مدققي Polkadot بشكل عشوائي وكشفهم بتأخير، ولا يمكن للمهاجمين معرفة هوية المدققين مسبقًا، ويجب عليهم المجازفة بالتحكم بالكامل لتحقيق النجاح، طالما أن هناك مدققًا واحدًا نزيهًا يبدأ نزاعًا، ستفشل الهجمة وتؤدي إلى خسارة المهاجم للرهانات.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، و P-Chain (إدارة المُصادقين والشبكات الفرعية).
يمكن أن يصل TPS النظري لكل شبكة فرعية إلى حوالي 5000، على غرار فكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن ضبط الشبكة الفرعية لتلبية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.
في Polkadot، تتشارك جميع rollup في ضمان أمان موحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في تعزيز الأمان، فسيتعين عليك التنازل عن الأداء، ومن الصعب تقديم التزام أمان حاسم.
إيثيريوم
استراتيجية توسيع إيثريوم تعتمد على الرهان على قابلية التوسع في طبقة رول أب بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
الطبقة التفاؤلية
في الوقت الحالي، تعتبر معظم تقنيات Optimistic Rollup مركزية، مما يؤدي إلى مشاكل مثل ضعف الأمان، والعزلة بين بعضها البعض، وارتفاع التأخير (حيث يتعين انتظار فترة إثبات الاحتيال، والتي تستغرق عادةً عدة أيام).
زك رول اب
تواجه تنفيذات ZK rollup قيودًا على كمية البيانات التي يمكن معالجتها في معاملة واحدة. المتطلبات الحسابية لإنشاء إثبات المعرفة الصفرية مرتفعة للغاية، وآلية "الفائز يحصل على كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما يقتصر ZK rollup على كمية المعاملات لكل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup الكامل لتورينغ تبلغ حوالي 2x10^6 مرة تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي لـ Polkadot.
بالإضافة إلى ذلك، ستؤدي مشكلات توفر البيانات في ZK rollup إلى تفاقم عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، يجب توفير بيانات المعاملات الكاملة. يعتمد ذلك عادةً على حلول توفر البيانات الإضافية، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تتبع بولكادوت طريق المركزية مقابل الأداء، أو الثقة المسبقة مقابل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان، واللامركزية، والأداء العالي من خلال التوسع المرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر نطاقًا اليوم، قد تكون "الامتداد غير الموثوق" الذي تتمسك به بولكادوت هو الحل الحقيقي الذي يمكن أن يدعم التطور على المدى الطويل لـ Web3.