في عصر تسعى فيه تقنية البلوك تشين لتحقيق كفاءة أعلى، بدأت تظهر مشكلة رئيسية: كيف يمكن تحسين الأداء القابل للتوسع دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام ويب 3، فإن إنشاء نظام أسرع إذا تم على حساب الثقة والأمان غالباً ما يكون من الصعب دعم الابتكار المستدام حقًا.
هل قامت Polkadot، باعتبارها أحد الداعمين الرئيسيين لتوسيع Web3، بالتضحية ببعض الأشياء لتحقيق أهداف عالية في قدرة المعالجة وانخفاض زمن الاستجابة؟ هل قدم نموذج الـ rollup الخاص بها تنازلات في اللامركزية أو الأمان أو التفاعل الشبكي؟
ستتناول هذه المقالة هذه القضايا، وتقوم بتحليل عميق للتوازنات والتنازلات التي تقدمها Polkadot في تصميم التوسع، ومقارنتها مع حلول السلاسل العامة الرئيسية الأخرى، واستكشاف الاختيارات المختلفة بينها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن المرونة واللامركزية
يعتمد هيكل Polkadot على شبكة من المدققين وسلسلة Relay، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن يتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على خصائصه اللامركزية؟
تعتمد عملية Rollup على مرتبة الاتصال بسلسلة الترحيل، حيث تستخدم الاتصالات آلية بروتوكول collator. هذا البروتوكول لا يتطلب إذنًا، ولا يحتاج إلى ثقة، يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، للاتصال بعدد قليل من عقد سلسلة الترحيل، وتقديم طلبات تحويل حالة rollup. ستتم معالجة هذه الطلبات من خلال أحد نوى سلسلة الترحيل، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة rollup.
موازنة التوسع العمودي
يمكن لـ Rollup تحقيق التوسع العمودي من خلال الاستفادة من بنية متعددة النوى في Polkadot. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتل rollup لا يتم تنفيذها بشكل ثابت على نواة معينة، فقد يؤثر ذلك على مرونتها.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة التتابع غير مرخص وموثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لعملية التحقق من التكديس. قد يستغل المهاجمون هذه النقطة من خلال تقديم كتل شرعية تم التحقق منها مسبقًا عدة مرات إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي القدرة الإنتاجية وكفاءة التكديس.
الهدف من Polkadot هو الحفاظ على مرونة الــrollup والاستخدام الفعال لموارد سلسلة النقل دون التأثير على الخصائص الرئيسية للنظام.
هل يمكن الوثوق بـ Sequencer؟
إحدى الحلول البسيطة هي تعيين البروتوكول إلى "مرخص": على سبيل المثال، من خلال اعتماد آلية القائمة البيضاء، أو الثقة الافتراضية في المنظمين لمنع السلوك الضار، مما يضمن نشاط rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا تقديم أي افتراضات ثقة بشأن sequencer، لأننا بحاجة إلى الحفاظ على خصائص "عدم الثقة" و"عدم الإذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل غير مخصص
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل لحل دالة تحويل حالة rollup (Runtime). Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذا يجب أن يتم التصريح بوضوح في المخرجات حول أي نواة من Polkadot يجب أن يتم تنفيذ التحقق عليها.
يحقق هذا التصميم ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية القابلية للاستخدام، وتضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة أي بيانات إلى طبقة قابلية استخدام Polkadot في كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 مدققين بالتحقق من قانونيتها أولاً. يتلقون الإيصالات المرشحة وشهادات الصلاحية المقدمة من المنظم، والتي تحتوي على كتلة rollup وإثباتات التخزين المقابلة. سيتم تقديم هذه المعلومات لمعالجة دالة التحقق على السلاسل المتوازية، حيث سيعيد المدققون في سلسلة الإرسال التنفيذ.
تتضمن نتيجة التحقق محدد core، يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيقوم المدقق بمطابقة هذا الفهرس مع core الذي هو مسؤول عنه؛ إذا لم يتطابق، سيتمdiscardت الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الحاجة إلى الإذن، مما يمنع المتلاعبين مثل المنظمين من التلاعب بمواقع التحقق، ويضمن الحفاظ على المرونة حتى عند استخدام عدة نوى في الـrollup.
الأمان
في سعيها لتحقيق التوسع، لم تقدم Polkadot أي تنازلات بشأن الأمان. يتم تأمين أمان الRollup بواسطة سلسلة الترحيل، وكل ما يتطلبه الأمر هو مرتّب نزيه للحفاظ على البقاء.
بمساعدة بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على core، دون الحاجة إلى أي قيود أو افتراضات بشأن عدد النوى المستخدمة.
لذلك، يمكن لمجموعة Polkadot أن تحقق التوسع الحقيقي دون التضحية بالأمان.
قابلية الاستخدام
لن تؤثر التوسعة المرنة على إمكانية برمجة الـ rollup. يدعم نموذج الـ rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في أقل من 2 ثانية. بفضل التوسعة المرنة، يمكن زيادة إجمالي كمية الحسابات المنفذة في فترة 6 ثوان، لكن نوع الحسابات لا يتأثر.
تعقيد
تؤدي الزيادة في الإنتاجية وتقليل الكمون بشكل غير قابل للتجنب إلى إدخال تعقيد، وهو الطريقة الوحيدة المقبولة للتوازن في تصميم الأنظمة.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليهم تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد لـ rollup ، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في ميمبول العقدة؛
استراتيجيات تلقائية: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمات coretime مسبقًا لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التداخلية
يدعم Polkadot التفاعل بين rollups المختلفة، ولن تؤثر قابلية التوسع المرنة على سعة نقل الرسائل.
تتم اتصالات الرسائل عبر rollup عبر طبقة النقل الأساسية، حيث إن مساحة كتلة الاتصال لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، مع وجود سلسلة الوسيط كواجهة تحكم، وليس كواجهة بيانات. ستعمل هذه الترقية على تحسين قدرة التواصل بين rollups مع تحسين التوسع المرن، مما يعزز قدرة النظام على التوسع العمودي.
ما هي التسويات التي قدمتها بروتوكولات أخرى؟
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض منافسي بولكادوت منخفضة، فإن أدائهم لا يكون مُرضيًا.
سولانا
لا تعتمد سولانا على بنية تقسيم بولكادوت أو إيثيريوم، بل تحقق التوسع من خلال بنية أحادية عالية الإنتاجية، وتعتمد على إثبات التاريخ (PoH) ومعالجة المعالجات المركزية بشكل متوازي وآلية إجماع قائمة على القيادة، ويمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا والتي يمكن التحقق منها:
في بداية كل حقبة (حوالي يومين أو 432,000 فتحة)، يتم توزيع الفتحات بناءً على كمية الرهان؛
كلما زادت المراهنة، زادت التوزيعات. على سبيل المثال، سيحصل المدقق الذي يراهن بنسبة 1% على حوالي 1% من فرص إنشاء الكتل؛
تم الإعلان عن جميع من يقومون بإنشاء الكتل مسبقًا، مما زاد من خطر تعرض الشبكة لهجمات DDoS موجهة، وارتفاع معدل الانقطاع.
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت كمية الرهانات، زادت فرص العقد الكبيرة في إنتاج الكتل، في حين أن العقد الصغيرة تكاد لا تمتلك أي slots، مما يزيد من تفاقم المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
تضحى سولانا باللامركزية والقدرة على مقاومة الهجمات من أجل تحقيق 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 النظرية لكل شبكة فرعية إلى ~5,000، مشابهة لفكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمصادقين باختيار المشاركة في الشبكات الفرعية بحرية، ويمكن إعداد الشبكات الفرعية مع متطلبات إضافية مثل الجغرافيا و KYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشارك جميع الـ rollup ضمان الأمان الموحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، ستحتاج إلى التنازل عن الأداء، ومن الصعب تقديم تعهدات أمان مؤكدة.
إيثيريوم
استراتيجية توسيع إيثيريوم تعتمد على التوسع في طبقة الرول أب بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة بل نقلتها إلى الطبقة العليا من المكدس.
التحسين المتفائل
في الوقت الحالي، فإن معظم حلول Optimistic rollup مركزية (بعضها يحتوي على sequencer واحد فقط)، مما يؤدي إلى مشكلات مثل نقص الأمان، والعزلة، وارتفاع التأخير (يجب الانتظار لفترة إثبات الاحتيال، والتي عادةً ما تستغرق بضعة أيام).
زك رول أب
تتأثر تنفيذات ZK rollup بحدود كمية البيانات التي يمكن معالجتها في كل معاملة. متطلبات الحساب لإنتاج الإثباتات الصفرية المعرفة عالية للغاية، و"آلية الفائز يأخذ كل شيء" قد تؤدي إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup حجم المعاملات لكل دفعة، مما قد يؤدي في أوقات الطلب المرتفع إلى ازدحام الشبكة وزيادة الغاز، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القابلة للتشغيل بالكامل هي حوالي 2x10^6 مرة من بروتوكول الأمن الاقتصادي الأساسي لـ Polkadot.
علاوة على ذلك، ستؤدي مشكلة توفر البيانات في ZK rollup إلى تفاقم عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين تقديم بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
خاتمة
نهاية القابلية للتوسع يجب ألا تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تسلك Polkadot الطريق الذي يضحي فيه باللامركزية من أجل الأداء، أو بالثقة المسبقة من أجل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات على نطاق أكبر اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التنمية الطويلة الأمد لـ Web3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
10
إعادة النشر
مشاركة
تعليق
0/400
DuskSurfer
· 07-24 17:29
يجب أن تسبق البنية التحتية لتتمكن من التقدم بسرعة
شاهد النسخة الأصليةرد0
TokenRationEater
· 07-24 00:36
لا يكفي بعد ، لقد مرت 22 عامًا
شاهد النسخة الأصليةرد0
LiquidityWhisperer
· 07-22 15:35
لا يمكن الحصول على السرعة والأمان معًا؟
شاهد النسخة الأصليةرد0
DiamondHands
· 07-22 13:17
يجب أن تكون السرعة والأمان متعارضين بشكل طبيعي.
شاهد النسخة الأصليةرد0
GasGuru
· 07-21 22:12
مرة أخرى، هناك سلسلة تعمل على فن التوازن.
شاهد النسخة الأصليةرد0
TokenVelocity
· 07-21 22:10
هل بولكادوت مستقر حقًا؟ أم أنه يُستغل بغباء.
شاهد النسخة الأصليةرد0
BearMarketSage
· 07-21 21:53
لا يمكن الحصول على السمك وذراع الدب في نفس الوقت.
شاهد النسخة الأصليةرد0
MidnightSeller
· 07-21 21:52
التضحية بالأمان من أجل السرعة، يكاد يكون الانتظار على السطح.
كيف تحقق Polkadot التوسع بدون ثقة وتوجه مستقبل Web3
موازنة قابلية التوسع: تحديات Polkadot وWeb3
في عصر تسعى فيه تقنية البلوك تشين لتحقيق كفاءة أعلى، بدأت تظهر مشكلة رئيسية: كيف يمكن تحسين الأداء القابل للتوسع دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام ويب 3، فإن إنشاء نظام أسرع إذا تم على حساب الثقة والأمان غالباً ما يكون من الصعب دعم الابتكار المستدام حقًا.
هل قامت Polkadot، باعتبارها أحد الداعمين الرئيسيين لتوسيع Web3، بالتضحية ببعض الأشياء لتحقيق أهداف عالية في قدرة المعالجة وانخفاض زمن الاستجابة؟ هل قدم نموذج الـ rollup الخاص بها تنازلات في اللامركزية أو الأمان أو التفاعل الشبكي؟
ستتناول هذه المقالة هذه القضايا، وتقوم بتحليل عميق للتوازنات والتنازلات التي تقدمها Polkadot في تصميم التوسع، ومقارنتها مع حلول السلاسل العامة الرئيسية الأخرى، واستكشاف الاختيارات المختلفة بينها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن المرونة واللامركزية
يعتمد هيكل Polkadot على شبكة من المدققين وسلسلة Relay، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن يتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على خصائصه اللامركزية؟
تعتمد عملية Rollup على مرتبة الاتصال بسلسلة الترحيل، حيث تستخدم الاتصالات آلية بروتوكول collator. هذا البروتوكول لا يتطلب إذنًا، ولا يحتاج إلى ثقة، يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، للاتصال بعدد قليل من عقد سلسلة الترحيل، وتقديم طلبات تحويل حالة rollup. ستتم معالجة هذه الطلبات من خلال أحد نوى سلسلة الترحيل، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة rollup.
موازنة التوسع العمودي
يمكن لـ Rollup تحقيق التوسع العمودي من خلال الاستفادة من بنية متعددة النوى في Polkadot. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتل rollup لا يتم تنفيذها بشكل ثابت على نواة معينة، فقد يؤثر ذلك على مرونتها.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة التتابع غير مرخص وموثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لعملية التحقق من التكديس. قد يستغل المهاجمون هذه النقطة من خلال تقديم كتل شرعية تم التحقق منها مسبقًا عدة مرات إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي القدرة الإنتاجية وكفاءة التكديس.
الهدف من Polkadot هو الحفاظ على مرونة الــrollup والاستخدام الفعال لموارد سلسلة النقل دون التأثير على الخصائص الرئيسية للنظام.
هل يمكن الوثوق بـ Sequencer؟
إحدى الحلول البسيطة هي تعيين البروتوكول إلى "مرخص": على سبيل المثال، من خلال اعتماد آلية القائمة البيضاء، أو الثقة الافتراضية في المنظمين لمنع السلوك الضار، مما يضمن نشاط rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا تقديم أي افتراضات ثقة بشأن sequencer، لأننا بحاجة إلى الحفاظ على خصائص "عدم الثقة" و"عدم الإذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل غير مخصص
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل لحل دالة تحويل حالة rollup (Runtime). Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذا يجب أن يتم التصريح بوضوح في المخرجات حول أي نواة من Polkadot يجب أن يتم تنفيذ التحقق عليها.
يحقق هذا التصميم ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية القابلية للاستخدام، وتضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة أي بيانات إلى طبقة قابلية استخدام Polkadot في كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 مدققين بالتحقق من قانونيتها أولاً. يتلقون الإيصالات المرشحة وشهادات الصلاحية المقدمة من المنظم، والتي تحتوي على كتلة rollup وإثباتات التخزين المقابلة. سيتم تقديم هذه المعلومات لمعالجة دالة التحقق على السلاسل المتوازية، حيث سيعيد المدققون في سلسلة الإرسال التنفيذ.
تتضمن نتيجة التحقق محدد core، يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيقوم المدقق بمطابقة هذا الفهرس مع core الذي هو مسؤول عنه؛ إذا لم يتطابق، سيتمdiscardت الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الحاجة إلى الإذن، مما يمنع المتلاعبين مثل المنظمين من التلاعب بمواقع التحقق، ويضمن الحفاظ على المرونة حتى عند استخدام عدة نوى في الـrollup.
الأمان
في سعيها لتحقيق التوسع، لم تقدم Polkadot أي تنازلات بشأن الأمان. يتم تأمين أمان الRollup بواسطة سلسلة الترحيل، وكل ما يتطلبه الأمر هو مرتّب نزيه للحفاظ على البقاء.
بمساعدة بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على core، دون الحاجة إلى أي قيود أو افتراضات بشأن عدد النوى المستخدمة.
لذلك، يمكن لمجموعة Polkadot أن تحقق التوسع الحقيقي دون التضحية بالأمان.
قابلية الاستخدام
لن تؤثر التوسعة المرنة على إمكانية برمجة الـ rollup. يدعم نموذج الـ rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في أقل من 2 ثانية. بفضل التوسعة المرنة، يمكن زيادة إجمالي كمية الحسابات المنفذة في فترة 6 ثوان، لكن نوع الحسابات لا يتأثر.
تعقيد
تؤدي الزيادة في الإنتاجية وتقليل الكمون بشكل غير قابل للتجنب إلى إدخال تعقيد، وهو الطريقة الوحيدة المقبولة للتوازن في تصميم الأنظمة.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليهم تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد لـ rollup ، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في ميمبول العقدة؛
استراتيجيات تلقائية: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمات coretime مسبقًا لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التداخلية
يدعم Polkadot التفاعل بين rollups المختلفة، ولن تؤثر قابلية التوسع المرنة على سعة نقل الرسائل.
تتم اتصالات الرسائل عبر rollup عبر طبقة النقل الأساسية، حيث إن مساحة كتلة الاتصال لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، مع وجود سلسلة الوسيط كواجهة تحكم، وليس كواجهة بيانات. ستعمل هذه الترقية على تحسين قدرة التواصل بين rollups مع تحسين التوسع المرن، مما يعزز قدرة النظام على التوسع العمودي.
ما هي التسويات التي قدمتها بروتوكولات أخرى؟
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض منافسي بولكادوت منخفضة، فإن أدائهم لا يكون مُرضيًا.
سولانا
لا تعتمد سولانا على بنية تقسيم بولكادوت أو إيثيريوم، بل تحقق التوسع من خلال بنية أحادية عالية الإنتاجية، وتعتمد على إثبات التاريخ (PoH) ومعالجة المعالجات المركزية بشكل متوازي وآلية إجماع قائمة على القيادة، ويمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا والتي يمكن التحقق منها:
في بداية كل حقبة (حوالي يومين أو 432,000 فتحة)، يتم توزيع الفتحات بناءً على كمية الرهان؛
كلما زادت المراهنة، زادت التوزيعات. على سبيل المثال، سيحصل المدقق الذي يراهن بنسبة 1% على حوالي 1% من فرص إنشاء الكتل؛
تم الإعلان عن جميع من يقومون بإنشاء الكتل مسبقًا، مما زاد من خطر تعرض الشبكة لهجمات DDoS موجهة، وارتفاع معدل الانقطاع.
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زادت كمية الرهانات، زادت فرص العقد الكبيرة في إنتاج الكتل، في حين أن العقد الصغيرة تكاد لا تمتلك أي slots، مما يزيد من تفاقم المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
تضحى سولانا باللامركزية والقدرة على مقاومة الهجمات من أجل تحقيق 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 النظرية لكل شبكة فرعية إلى ~5,000، مشابهة لفكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمصادقين باختيار المشاركة في الشبكات الفرعية بحرية، ويمكن إعداد الشبكات الفرعية مع متطلبات إضافية مثل الجغرافيا و KYC، مما يضحي باللامركزية والأمان.
في Polkadot، تشارك جميع الـ rollup ضمان الأمان الموحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، ستحتاج إلى التنازل عن الأداء، ومن الصعب تقديم تعهدات أمان مؤكدة.
إيثيريوم
استراتيجية توسيع إيثيريوم تعتمد على التوسع في طبقة الرول أب بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة بل نقلتها إلى الطبقة العليا من المكدس.
التحسين المتفائل
في الوقت الحالي، فإن معظم حلول Optimistic rollup مركزية (بعضها يحتوي على sequencer واحد فقط)، مما يؤدي إلى مشكلات مثل نقص الأمان، والعزلة، وارتفاع التأخير (يجب الانتظار لفترة إثبات الاحتيال، والتي عادةً ما تستغرق بضعة أيام).
زك رول أب
تتأثر تنفيذات ZK rollup بحدود كمية البيانات التي يمكن معالجتها في كل معاملة. متطلبات الحساب لإنتاج الإثباتات الصفرية المعرفة عالية للغاية، و"آلية الفائز يأخذ كل شيء" قد تؤدي إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup حجم المعاملات لكل دفعة، مما قد يؤدي في أوقات الطلب المرتفع إلى ازدحام الشبكة وزيادة الغاز، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القابلة للتشغيل بالكامل هي حوالي 2x10^6 مرة من بروتوكول الأمن الاقتصادي الأساسي لـ Polkadot.
علاوة على ذلك، ستؤدي مشكلة توفر البيانات في ZK rollup إلى تفاقم عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين تقديم بيانات المعاملات الكاملة. وغالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
خاتمة
نهاية القابلية للتوسع يجب ألا تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تسلك Polkadot الطريق الذي يضحي فيه باللامركزية من أجل الأداء، أو بالثقة المسبقة من أجل الكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات على نطاق أكبر اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التنمية الطويلة الأمد لـ Web3.