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