في زمن يسعى فيه البلوكتشين نحو كفاءة أعلى، تظهر مسألة رئيسية تدريجياً: كيف يمكن تحسين الأداء مع تجنب التضحية بالأمان ومرونة النظام؟
هذه ليست مجرد تحديات على المستوى التقني، بل هي أيضًا اختيارات عميقة في تصميم الهيكل. خاصة بالنسبة لبيئة Web3، إذا كان النظام الأسرع يعتمد على التضحية بالثقة والأمان، فمن الصعب غالبًا دعم الابتكار المستدام حقًا.
كودات كأحد المحفزين الرئيسيين لقابلية التوسع في Web3، هل ضحت ببعض الأشياء من أجل تحقيق هدفها في ارتفاع القدرة على المعالجة وانخفاض الكمون؟ هل قدم نموذج rollup الخاص بها تنازلات في اللامركزية أو الأمان أو التفاعل بين الشبكات؟
ستتناول هذه المقالة هذه القضايا، وتقوم بتحليل عميق للاختيارات والموازنات التي تتبناها Polkadot في تصميم قابلية التوسع، ومقارنتها مع حلول سلاسل الكتل الرئيسية الأخرى، واستكشاف الخيارات المختلفة التي تتخذها هذه السلاسل في ما يتعلق بالأداء والأمان واللامركزية.
تحديات تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المدققين وسلسلة الترحيل (Relay Chain)، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن يتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على خصائصه اللامركزية؟
يعتمد تشغيل Rollup على مُرتب السلسلة الوسيطة (sequencer) المتصل، حيث تستخدم الاتصالات آلية تُعرف باسم بروتوكول collator. هذا البروتوكول غير مرخص تمامًا وغير موثوق، حيث يمكن لأي شخص لديه اتصال بالشبكة استخدامه، للاتصال بعدد قليل من عقد السلسلة الوسيطة وتقديم طلبات تحويل حالة Rollup. ستتم معالجة هذه الطلبات من خلال تحقق core معين من السلسلة الوسيطة، بشرط واحد: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة Rollup.
موازنة التوسع العمودي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن" (Elastic Scaling). خلال عملية التصميم ، اكتشفنا أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه على نواة معينة ، فقد يؤثر ذلك على مرونتها.
بما أن بروتوكول إرسال الكتلة إلى سلسلة التتابع غير مصرح به وغير موثوق، يمكن لأي شخص تقديم الكتلة إلى أي نواة تم تخصيصها للـ rollup للتحقق. قد يستغل المهاجمون هذه النقطة، ويقومون بإعادة تقديم كتل شرعية تم التحقق منها مسبقًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي قدرة الـ rollup وكفاءته.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة النقل دون التأثير على الخصائص الأساسية للنظام.
هل Sequencer موثوق به؟
طريقة بسيطة للحل هي تعيين البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو الثقة الافتراضية في المنظمين بأنهم لن يقوموا بسلوكيات خبيثة، مما يضمن نشاط الـrollup.
ومع ذلك، في تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة بشأن sequencer، لأنه يجب الحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
Polkadot: حل غير مقبول
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل إلى دالة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة Polkadot يجب تنفيذ التحقق عليها.
هذا التصميم يحقق ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية القابلية للاستخدام، وتضمن بروتوكول الاقتصاد التشفيري ELVES صحة تخصيص core.
قبل كتابة بيانات rollup كتلة على طبقة توفر البيانات (DA) في Polkadot، ستقوم مجموعة مكونة من حوالي 5 مُحققين أولاً بالتحقق من شرعيتها. يتلقون الإيصالات المرشحة (candidate receipt) و إثباتات الصلاحية (PoV) المقدمة من المُرتب، والتي تحتوي على كتلة rollup و إثباتات التخزين المقابلة. ستتم معالجة هذه المعلومات بواسطة دالة التحقق على السلاسل المتوازية، وسيتولى المُحققون على السلسلة المتوسطة تنفيذها مجددًا.
نتيجة التحقق تحتوي على محدد core، يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيقوم المدقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يتطابق، سيتم تجاهل هذه الكتلة.
تضمن هذه الآلية أن يظل النظام دائمًا خاليًا من الثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بموقع التحقق، مما يضمن أن تظل مرنة حتى عند استخدام عدة نوى في الـ rollup.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين الأمان للـ rollup بواسطة سلسلة الترحيل، ولا يتطلب الأمر سوى مُرتب صادق للحفاظ على البقاء.
من خلال بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بشكل كامل إلى جميع rollup، والتحقق من جميع العمليات الحسابية على core، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot توسعًا حقيقيًا دون التضحية بالأمان.
قابلية الاستخدام
لن تؤثر التوسعة المرنة على قابلية برمجة الـ rollup. يدعم نموذج الـ rollup في Polkadot تنفيذ حسابات Turing كاملة في بيئة WebAssembly، طالما أن التنفيذ الواحد يكتمل في غضون ثانيتين. بفضل التوسعة المرنة، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
إن زيادة معدل نقل البيانات وتقليل التأخير لا بد أن يؤديان إلى تعقيد، وهذه هي الطريقة الوحيدة المقبولة للتوازن في تصميم النظام.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان موحد. يجب عليهم أيضًا تنفيذ بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد الخاصة بالـ rollup، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في mempool العقدة؛
استراتيجيات مؤتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمة coretime مسبقًا لتكوين الموارد.
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكلفة التنفيذ والاختبار قد ارتفعت بشكل ملحوظ.
التفاعل بين الأنظمة
يدعم Polkadot التشغيل البيني بين مختلف rollups، ولن تؤثر التوسعة المرنة على قدرة نقل الرسائل.
تتم عملية التواصل عبر rollup عن طريق طبقة النقل الأساسية، حيث تكون المساحة المخصصة لكتلة التواصل لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا تبادل الرسائل خارج السلسلة (off-chain messaging)، حيث ستكون سلسلة الترحيل هي الواجهة التحكمية، وليس واجهة البيانات. ستعمل هذه الترقية على تعزيز قدرة التواصل بين rollup مع التوسع المرن، مما يعزز بشكل أكبر القدرة العمودية للنظام على التوسع.
ما هي التنازلات التي قدمتها البروتوكولات الأخرى؟
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. لكن من منظور معامل ناكاموتو، حتى وإن كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائهم لا يزال غير مرضٍ.
سولانا
لا تعتمد سولانا على بنية تقسيم بولكادوت أو إيثيريوم، بل تحقق التوسع من خلال بنية أحادية عالية الإنتاجية، معتمدةً على إثبات التاريخ (PoH) ومعالجة المعالجات المركزية المتوازية وآلية الإجماع القائمة على القائد، مع إمكانية الوصول إلى TPS نظرية قدرها 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل عصر (حوالي يومين أو 432,000 فتحة)، يتم تخصيص الفتحات بناءً على كمية الرهان؛
كلما زادت نسبة الرهن، زادت نسبة التوزيع. على سبيل المثال، ستحصل نسبة 1% من المدققين المرهنين على حوالي 1% من فرص إنشاء الكتل؛
جميع مُنتجي الكتل يعلنون مسبقًا، مما يزيد من مخاطر تعرض الشبكة لهجمات DDoS موجهة، وتكرار الانقطاع.
تتطلب تقنية PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزة العقد المُصادقة. كلما زادت كمية الرهان، زادت فرصة العقد في إنتاج الكتل، بينما تكاد تكون فرص العقد الصغيرة في الحصول على slots معدومة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
سولانا sacrificed اللامركزية و القدرة على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20، وهو أقل بكثير من 172 الخاصة بـ Polkadot.
طن
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف مثالية من الشبكة والأجهزة. بينما وصلت Polkadot إلى 128 ألف عملية في الثانية على شبكة عامة لامركزية.
توجد ثغرات أمنية في آلية الإجماع الخاصة بـ TON: هوية عقد التحقق في الشظايا ستكشف مسبقًا. كما أشار الكتاب الأبيض لـ TON بوضوح إلى أن هذا يمكن أن يحسن عرض النطاق الترددي، لكنه قد يُستغل أيضًا بشكل خبيث. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة الكاملة على شظية معينة، أو من خلال هجمات DDoS عرقلة المصدقين الأمناء، وبالتالي تغيير الحالة.
بالمقارنة، يتم تعيين المدققين في Polkadot بشكل عشوائي وكشفهم متأخر، مما يعني أن المهاجمين لا يمكنهم معرفة هوية المدققين مسبقًا، ويتطلب الهجوم السيطرة الكاملة على النجاح، طالما أن هناك مدققًا واحدًا نزيهًا يبدأ نزاعًا، سيفشل الهجوم ويتسبب في خسارة المهاجم لرهانهم.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، وP-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5,000 ، مشابه لفكرة Polkadot: تقليل الحمل على كل كتلة لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكات الفرعية بحرية ، ويمكن أن تضع الشبكات الفرعية متطلبات إضافية مثل الجغرافيا و KYC ، مما يضحي باللامركزية والأمان.
في Polkadot، تشارك جميع rollups ضمان أمان موحد؛ بينما لا تمتلك الشبكات الفرعية في Avalanche ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في تعزيز الأمان، فلا بد من تقديم تنازلات في الأداء، ومن الصعب تقديم وعود أمان حاسمة.
إيثيريوم
استراتيجية توسيع إيثريوم هي الرهان على قابلية التوسع في طبقة rollup بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، معظم الـ Optimistic rollup مركزي (بعضها يحتوي على sequencer واحد فقط)، مما يؤدي إلى مشكلات تتعلق بالسلامة، والعزلة، وزيادة التأخير (يجب الانتظار لفترة إثبات الاحتيال، وعادة ما تكون عدة أيام).
زك رول أب
تؤثر قيود كمية البيانات القابلة للمعالجة لكل معاملة على تنفيذ ZK rollup. تتطلب حسابات توليد الإثباتات الصفرية معرفة عالية، و آلية "الفائز يأخذ الكل" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقارنة، تكلفة ZK rollup القابلة للتطوير بشكل تام هي حوالي 2x10^6 مرة من بروتوكول الأمان الاقتصادي الأساسي ل Polkadot.
علاوة على ذلك، فإن مشكلة توفر بيانات ZK rollup ستزيد من عيوبها. لضمان أن يتمكن أي شخص من التحقق من المعاملات، لا يزال من الضروري توفير بيانات المعاملات الكاملة. يعتمد ذلك عادةً على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدم.
الخاتمة
نهاية القابلية للتوسع يجب ألا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم يتبع بولكادوت الطريق الذي يعتمد على المركزية لتحسين الأداء، أو على الثقة المسبقة لزيادة الكفاءة، بل حقق توازناً متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، وطبقات أمان موحدة وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا، قد تكون "قابلية التوسع بدون ثقة" التي تلتزم بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور الطويل الأمد لـ Web3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
5
مشاركة
تعليق
0/400
SignatureCollector
· 07-30 01:18
نقطة سلسلة اسرع ارتفع ارتفع
شاهد النسخة الأصليةرد0
ForumMiningMaster
· 07-30 01:15
دخل شهري قدره مائة ألف يعتمد على هذه السلاسل القليلة.
توسيع بولكادوت المرن: الطريق عالي الأداء لـ Web3 بدون تنازلات
توازن قابلية توسيع البلوكتشين: استكشاف Polkadot وWeb3 الإيكولوجية
في زمن يسعى فيه البلوكتشين نحو كفاءة أعلى، تظهر مسألة رئيسية تدريجياً: كيف يمكن تحسين الأداء مع تجنب التضحية بالأمان ومرونة النظام؟
هذه ليست مجرد تحديات على المستوى التقني، بل هي أيضًا اختيارات عميقة في تصميم الهيكل. خاصة بالنسبة لبيئة Web3، إذا كان النظام الأسرع يعتمد على التضحية بالثقة والأمان، فمن الصعب غالبًا دعم الابتكار المستدام حقًا.
كودات كأحد المحفزين الرئيسيين لقابلية التوسع في Web3، هل ضحت ببعض الأشياء من أجل تحقيق هدفها في ارتفاع القدرة على المعالجة وانخفاض الكمون؟ هل قدم نموذج rollup الخاص بها تنازلات في اللامركزية أو الأمان أو التفاعل بين الشبكات؟
ستتناول هذه المقالة هذه القضايا، وتقوم بتحليل عميق للاختيارات والموازنات التي تتبناها Polkadot في تصميم قابلية التوسع، ومقارنتها مع حلول سلاسل الكتل الرئيسية الأخرى، واستكشاف الخيارات المختلفة التي تتخذها هذه السلاسل في ما يتعلق بالأداء والأمان واللامركزية.
تحديات تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المدققين وسلسلة الترحيل (Relay Chain)، هل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن يتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على خصائصه اللامركزية؟
يعتمد تشغيل Rollup على مُرتب السلسلة الوسيطة (sequencer) المتصل، حيث تستخدم الاتصالات آلية تُعرف باسم بروتوكول collator. هذا البروتوكول غير مرخص تمامًا وغير موثوق، حيث يمكن لأي شخص لديه اتصال بالشبكة استخدامه، للاتصال بعدد قليل من عقد السلسلة الوسيطة وتقديم طلبات تحويل حالة Rollup. ستتم معالجة هذه الطلبات من خلال تحقق core معين من السلسلة الوسيطة، بشرط واحد: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة Rollup.
موازنة التوسع العمودي
يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن" (Elastic Scaling). خلال عملية التصميم ، اكتشفنا أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه على نواة معينة ، فقد يؤثر ذلك على مرونتها.
بما أن بروتوكول إرسال الكتلة إلى سلسلة التتابع غير مصرح به وغير موثوق، يمكن لأي شخص تقديم الكتلة إلى أي نواة تم تخصيصها للـ rollup للتحقق. قد يستغل المهاجمون هذه النقطة، ويقومون بإعادة تقديم كتل شرعية تم التحقق منها مسبقًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي قدرة الـ rollup وكفاءته.
الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة النقل دون التأثير على الخصائص الأساسية للنظام.
هل Sequencer موثوق به؟
طريقة بسيطة للحل هي تعيين البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو الثقة الافتراضية في المنظمين بأنهم لن يقوموا بسلوكيات خبيثة، مما يضمن نشاط الـrollup.
ومع ذلك، في تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة بشأن sequencer، لأنه يجب الحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
Polkadot: حل غير مقبول
الخيار النهائي لـ Polkadot هو: ترك المشكلة بالكامل إلى دالة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة Polkadot يجب تنفيذ التحقق عليها.
هذا التصميم يحقق ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية القابلية للاستخدام، وتضمن بروتوكول الاقتصاد التشفيري ELVES صحة تخصيص core.
قبل كتابة بيانات rollup كتلة على طبقة توفر البيانات (DA) في Polkadot، ستقوم مجموعة مكونة من حوالي 5 مُحققين أولاً بالتحقق من شرعيتها. يتلقون الإيصالات المرشحة (candidate receipt) و إثباتات الصلاحية (PoV) المقدمة من المُرتب، والتي تحتوي على كتلة rollup و إثباتات التخزين المقابلة. ستتم معالجة هذه المعلومات بواسطة دالة التحقق على السلاسل المتوازية، وسيتولى المُحققون على السلسلة المتوسطة تنفيذها مجددًا.
نتيجة التحقق تحتوي على محدد core، يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيقوم المدقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يتطابق، سيتم تجاهل هذه الكتلة.
تضمن هذه الآلية أن يظل النظام دائمًا خاليًا من الثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بموقع التحقق، مما يضمن أن تظل مرنة حتى عند استخدام عدة نوى في الـ rollup.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين الأمان للـ rollup بواسطة سلسلة الترحيل، ولا يتطلب الأمر سوى مُرتب صادق للحفاظ على البقاء.
من خلال بروتوكول ELVES، ستقوم Polkadot بتوسيع أمانها بشكل كامل إلى جميع rollup، والتحقق من جميع العمليات الحسابية على core، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن أن تحقق rollup الخاصة بـ Polkadot توسعًا حقيقيًا دون التضحية بالأمان.
قابلية الاستخدام
لن تؤثر التوسعة المرنة على قابلية برمجة الـ rollup. يدعم نموذج الـ rollup في Polkadot تنفيذ حسابات Turing كاملة في بيئة WebAssembly، طالما أن التنفيذ الواحد يكتمل في غضون ثانيتين. بفضل التوسعة المرنة، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
إن زيادة معدل نقل البيانات وتقليل التأخير لا بد أن يؤديان إلى تعقيد، وهذه هي الطريقة الوحيدة المقبولة للتوازن في تصميم النظام.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان موحد. يجب عليهم أيضًا تنفيذ بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد الخاصة بالـ rollup، والتي قد تعتمد على المتغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في mempool العقدة؛
استراتيجيات مؤتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمة coretime مسبقًا لتكوين الموارد.
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكلفة التنفيذ والاختبار قد ارتفعت بشكل ملحوظ.
التفاعل بين الأنظمة
يدعم Polkadot التشغيل البيني بين مختلف rollups، ولن تؤثر التوسعة المرنة على قدرة نقل الرسائل.
تتم عملية التواصل عبر rollup عن طريق طبقة النقل الأساسية، حيث تكون المساحة المخصصة لكتلة التواصل لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا تبادل الرسائل خارج السلسلة (off-chain messaging)، حيث ستكون سلسلة الترحيل هي الواجهة التحكمية، وليس واجهة البيانات. ستعمل هذه الترقية على تعزيز قدرة التواصل بين rollup مع التوسع المرن، مما يعزز بشكل أكبر القدرة العمودية للنظام على التوسع.
ما هي التنازلات التي قدمتها البروتوكولات الأخرى؟
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. لكن من منظور معامل ناكاموتو، حتى وإن كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائهم لا يزال غير مرضٍ.
سولانا
لا تعتمد سولانا على بنية تقسيم بولكادوت أو إيثيريوم، بل تحقق التوسع من خلال بنية أحادية عالية الإنتاجية، معتمدةً على إثبات التاريخ (PoH) ومعالجة المعالجات المركزية المتوازية وآلية الإجماع القائمة على القائد، مع إمكانية الوصول إلى TPS نظرية قدرها 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل عصر (حوالي يومين أو 432,000 فتحة)، يتم تخصيص الفتحات بناءً على كمية الرهان؛
كلما زادت نسبة الرهن، زادت نسبة التوزيع. على سبيل المثال، ستحصل نسبة 1% من المدققين المرهنين على حوالي 1% من فرص إنشاء الكتل؛
جميع مُنتجي الكتل يعلنون مسبقًا، مما يزيد من مخاطر تعرض الشبكة لهجمات DDoS موجهة، وتكرار الانقطاع.
تتطلب تقنية PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزة العقد المُصادقة. كلما زادت كمية الرهان، زادت فرصة العقد في إنتاج الكتل، بينما تكاد تكون فرص العقد الصغيرة في الحصول على slots معدومة، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد الهجوم.
سولانا sacrificed اللامركزية و القدرة على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20، وهو أقل بكثير من 172 الخاصة بـ Polkadot.
طن
تدعي TON أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف مثالية من الشبكة والأجهزة. بينما وصلت Polkadot إلى 128 ألف عملية في الثانية على شبكة عامة لامركزية.
توجد ثغرات أمنية في آلية الإجماع الخاصة بـ TON: هوية عقد التحقق في الشظايا ستكشف مسبقًا. كما أشار الكتاب الأبيض لـ TON بوضوح إلى أن هذا يمكن أن يحسن عرض النطاق الترددي، لكنه قد يُستغل أيضًا بشكل خبيث. نظرًا لعدم وجود آلية "إفلاس المقامرين"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة الكاملة على شظية معينة، أو من خلال هجمات DDoS عرقلة المصدقين الأمناء، وبالتالي تغيير الحالة.
بالمقارنة، يتم تعيين المدققين في Polkadot بشكل عشوائي وكشفهم متأخر، مما يعني أن المهاجمين لا يمكنهم معرفة هوية المدققين مسبقًا، ويتطلب الهجوم السيطرة الكاملة على النجاح، طالما أن هناك مدققًا واحدًا نزيهًا يبدأ نزاعًا، سيفشل الهجوم ويتسبب في خسارة المهاجم لرهانهم.
أفالانش
تستخدم Avalanche بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، وP-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5,000 ، مشابه لفكرة Polkadot: تقليل الحمل على كل كتلة لتحقيق التوسع. لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكات الفرعية بحرية ، ويمكن أن تضع الشبكات الفرعية متطلبات إضافية مثل الجغرافيا و KYC ، مما يضحي باللامركزية والأمان.
في Polkadot، تشارك جميع rollups ضمان أمان موحد؛ بينما لا تمتلك الشبكات الفرعية في Avalanche ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في تعزيز الأمان، فلا بد من تقديم تنازلات في الأداء، ومن الصعب تقديم وعود أمان حاسمة.
إيثيريوم
استراتيجية توسيع إيثريوم هي الرهان على قابلية التوسع في طبقة rollup بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
في الوقت الحالي، معظم الـ Optimistic rollup مركزي (بعضها يحتوي على sequencer واحد فقط)، مما يؤدي إلى مشكلات تتعلق بالسلامة، والعزلة، وزيادة التأخير (يجب الانتظار لفترة إثبات الاحتيال، وعادة ما تكون عدة أيام).
زك رول أب
تؤثر قيود كمية البيانات القابلة للمعالجة لكل معاملة على تنفيذ ZK rollup. تتطلب حسابات توليد الإثباتات الصفرية معرفة عالية، و آلية "الفائز يأخذ الكل" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما تقيد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة الغاز في أوقات الطلب العالي، مما يؤثر على تجربة المستخدم.
بالمقارنة، تكلفة ZK rollup القابلة للتطوير بشكل تام هي حوالي 2x10^6 مرة من بروتوكول الأمان الاقتصادي الأساسي ل Polkadot.
علاوة على ذلك، فإن مشكلة توفر بيانات ZK rollup ستزيد من عيوبها. لضمان أن يتمكن أي شخص من التحقق من المعاملات، لا يزال من الضروري توفير بيانات المعاملات الكاملة. يعتمد ذلك عادةً على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدم.
الخاتمة
نهاية القابلية للتوسع يجب ألا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم يتبع بولكادوت الطريق الذي يعتمد على المركزية لتحسين الأداء، أو على الثقة المسبقة لزيادة الكفاءة، بل حقق توازناً متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، وطبقات أمان موحدة وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا، قد تكون "قابلية التوسع بدون ثقة" التي تلتزم بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور الطويل الأمد لـ Web3.