القابلية للتوسع والموازنة: خيارات تكنولوجية بين Polkadot وبيئة Web3
في عصر تسعى فيه تقنية البلوكشين لتحقيق كفاءة أعلى، تبرز مسألة رئيسية تدريجيًا: كيف يمكن تحقيق الأداء المتوسع مع مراعاة الأمان ومرونة النظام في الوقت نفسه؟ هذه ليست مجرد تحديات على المستوى الفني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام Web3، فإن السعي وراء نظام أسرع على حساب الثقة والأمان، لن يدعم الابتكار المستدام حقًا.
كأحد المحركات الرئيسية لتوسيع نطاق Web3، هل ضحت Polkadot ببعض الأمور أثناء سعيها لتحقيق أهداف عالية من حيث القدرة على المعالجة وانخفاض الكمون؟ هل نموذج rollup الخاص بها قد يتنازل عن اللامركزية أو الأمان أو التداخل الشبكي؟ ستتناول هذه المقالة هذه الأسئلة، وتقوم بتحليل عميق للتوازنات والتنازلات التي قامت بها Polkadot في تصميم التوسع، وتقارنها مع حلول سلاسل الكتل الرئيسية الأخرى، مستكشفة الخيارات المختلفة التي اتخذتها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة من المدققين وسلسلة الترحيل، فهل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقاط فشل أو تحكم فردي، مما يؤثر على خصائصها اللامركزية؟
يعتمد تشغيل Rollup على مرتبة متصلة بسلسلة الوسيط، ويستخدم التواصل آلية بروتوكول collator. هذا البروتوكول لا يتطلب ترخيصًا أو ثقة على الإطلاق، يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، والتواصل مع عدد قليل من عقد سلسلة الوسيط، وتقديم طلبات تحويل حالة rollup. ستتم معالجة هذه الطلبات من خلال أحد التحقق من core في سلسلة الوسيط، بشرط واحد فقط: يجب أن تكون تحويل الحالة صالحًا، وإلا فلن يتم دفع حالة rollup.
توازن التوسع العمودي
يمكن لـ Rollup تحقيق التوسع الرأسي من خلال استغلال بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أن التحقق من كتل Rollup لا يتم تنفيذه بشكل ثابت على نواة معينة، مما قد يؤثر على مرونتها.
نظرًا لأن البروتوكول الخاص بتقديم الكتل إلى سلسلة التتابع لا يتطلب إذنًا أو ثقة، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق منها. قد يستغل المهاجمون هذه النقطة عن طريق تقديم كتل شرعية تم التحقق منها مسبقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي قدرة rollup وكفاءته.
الهدف من Polkadot هو الحفاظ على مرونة rollup واستخدام موارد سلسلة الترحيل بشكل فعال دون التأثير على الخصائص الأساسية للنظام.
مشكلة موثوقية Sequencer
طريقة بسيطة للحل هي ضبط البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو افتراض أن مُرتب الثقة لن يقوم بأي سلوك ضار، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا القيام بأي افتراضات موثوقة حول sequencer، لأننا نحتاج إلى الحفاظ على خصائص "عدم الثقة" و "عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل غير مُساوم
الحل النهائي الذي اختاره Polkadot هو: ترك المشكلة بالكامل لوظيفة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الموثوق الوحيد لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة Polkadot يجب أن يتم التحقق منها.
يحقق هذا التصميم ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوافر، وضمان صحة توزيع core من خلال بروتوكول الاقتصاد المشفر ELVES.
قبل كتابة أي بيانات من rollup إلى طبقة قابلية استخدام البيانات (DA) في Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين بالتحقق من قانونيتها أولاً. يتلقون الإيصالات المرشحة وإثباتات الفعالية المقدمة من المُرتب، والتي تحتوي على كتل rollup وإثباتات التخزين المقابلة. سيتم تسليم هذه المعلومات لمعالجة دالة التحقق من السلاسل المتوازية، حيث سيقوم المدققون على سلسلة الترحيل بإعادة التنفيذ.
تتضمن نتيجة التحقق محدد core، يستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيتحقق المدقق من ما إذا كانت هذه الفهرس تتطابق مع core الذي يتحمل مسؤوليته؛ إذا لم تتطابق، فسيتم تجاهل هذه الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الإذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core يمكن أن تبقى مرونة.
الأمان
في سعيها نحو القابلية للتوسع، لم تتنازل بولكادوت عن الأمان. يتم تأمين rollup بواسطة سلسلة الوسيط، حيث يكفي وجود مُرتب صادق للحفاظ على البقاء.
من خلال بروتوكول ELVES، ستقوم Polkadot بتوسيع سلامتها بالكامل لتشمل جميع rollup، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن لـ rollup الخاص بـ Polkadot تحقيق توسع حقيقي دون التضحية بالأمان.
قابلية التعميم
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في غضون ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات التي يمكن تنفيذها في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
التعقيد
من المؤكد أن زيادة السعة وتقليل التأخير يجلبان تعقيدًا، وهذه هي الطريقة الوحيدة المقبولة للتوازن في تصميم الأنظمة.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. يجب عليهم أيضًا تنفيذ بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجية إدارة الموارد للـ rollup، والتي قد تعتمد على المتغيرات الموجودة على السلسلة أو خارجها. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عددًا ثابتًا من النوى، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة الوزن: مراقبة أحمال المعاملات المحددة في ميمبول العقد.
استراتيجيات الأتمتة: استدعاء خدمة coretime مسبقًا من خلال بيانات التاريخ وواجهة XCM لتكوين الموارد.
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار قد ارتفعت بشكل ملحوظ.
التفاعل بين الأنظمة
يدعم Polkadot التشغيل البيني بين مختلف rollups، بينما لا تؤثر التوسعة المرنة على قدرة نقل الرسائل.
تتم الاتصالات الرسائلية عبر rollup من خلال طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم بولكادوت أيضًا نقل الرسائل خارج السلسلة، حيث سيكون هناك سلسلة وسيطة كواجهة تحكم، بدلاً من واجهة البيانات. ستؤدي هذه الترقية إلى تحسين قدرة الاتصال بين الــrollups مع التوسع المرن، مما يعزز بشكل أكبر القدرة على التوسع العمودي للنظام.
التوازنات في البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالباً ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لبولكادوت منخفضة، فإن أدائها لا يزال دون المستوى.
سلسلة الكتل العامة A
لا تعتمد سلسلة الكتل العامة A على بنية تجزئة Polkadot أو Ethereum، بل تعتمد على بنية ذات طبقة واحدة عالية الإنتاجية لتحقيق القابلية للتوسع، مستندة إلى إثبات التاريخ، المعالجة المتوازية لوحدات المعالجة المركزية، وآلية توافق قائمة على القائد، حيث يمكن أن يصل TPS النظري إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل فترة (حوالي يومين أو 432,000 فتحة) ، يتم تخصيص الفتحات وفقًا لمقدار الرهانات؛
كلما زادت نسبة الرهن، زادت نسبة التوزيع. على سبيل المثال، فإن رهن 1% من المدققين سيحصلون على فرصة كتلة تبلغ حوالي 1%.
جميع معدني الكتل تم الإعلان عنهم مسبقًا، مما زاد من خطر تعرض الشبكة لهجمات DDoS موجهة، والانقطاعات المتكررة.
التاريخ يثبت أن المعالجة المتوازية تتطلب متطلبات عالية جداً من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زاد عدد العقد المراهنة، زادت فرصها في إنتاج الكتل، في حين أن العقد الصغيرة تكاد لا تملك أي فتحة، مما يزيد من حدة المركزية، ويزيد أيضاً من خطر تعطل النظام بعد الهجوم.
تضحي شبكة البلوكتشين A من أجل تحقيق TPS باللامركزية وقدرة مقاومة الهجمات، حيث أن معامل ناكاموتو الخاص بها لا يتجاوز 20، وهو أقل بكثير من 172 الخاصة بـ Polkadot.
سلسلة بلوكشين معينة B
تدعي سلسلة الكتل العامة B أن معدل المعاملات في الثانية (TPS) يمكن أن يصل إلى 104,715، لكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظل ظروف مثالية من الشبكة والأجهزة. بينما وصلت Polkadot في شبكة عامة لامركزية إلى 128K TPS.
توجد ثغرة أمنية في آلية توافق الشبكة العامة B: هوية عقد التحقق المقسمة قد تتعرض للكشف مسبقًا. كما أن الورقة البيضاء للشبكة العامة B تشير بوضوح إلى أن هذا قد يحسن من عرض النطاق الترددي، لكنه قد يُستغل بشكل خبيث. نظرًا لعدم وجود آلية "إفلاس المقامر"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة الكاملة على جزء معين، أو قطع الاتصال بالمحققين الصادقين من خلال هجوم DDoS، مما يؤدي إلى تعديل الحالة.
بالمقارنة، فإن مصدقو Polkadot يتم تعيينهم عشوائيًا ويُكشف عنهم بتأخير، مما يجعل من المستحيل على المهاجمين معرفة هوية المصدقين مسبقًا. يجب أن يراهن المهاجمون على السيطرة الكاملة لتحقيق النجاح، طالما أن هناك مصدقًا أمينًا واحدًا يبدأ نزاعًا، فسوف يفشل الهجوم ويتسبب في خسارة المهاجم لرهانه.
سلسلة عامة معينة C
تستخدم سلسلة الكتل العامة C بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، و P-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة بولكادوت: تقليل الحمل على shard واحد لتحقيق التوسع. ولكن إحدى سلاسل الكتل العامة C تسمح للمحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن أن تضع الشبكة الفرعية متطلبات إضافية مثل الجغرافيا و KYC، مما يضحي باللامركزية والأمان.
في بولكادوت، تشارك جميع الأنظمة المجمعة ضمان أمان موحد؛ بينما الشبكة الفرعية لسلسلة معينة C ليس لديها ضمان أمان افتراضي، وبعضها قد يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، لا يزال يتعين عليك التنازل عن الأداء، ومن الصعب تقديم وعود أمان حاسمة.
سلسلة معينة D
استراتيجية التوسع لسلسلة الكتل العامة D تركز على قابلية التوسع في طبقة rollup بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
معظم عمليات التدوير المتفائلة الحالية مركزية (بعضها يحتوي حتى على مكون واحد فقط) مما يؤدي إلى مشاكل مثل عدم كفاية الأمان، والعزلة، والارتفاع في التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادة ما تستغرق عدة أيام).
زك رول أب
تواجه تنفيذات ZK rollup قيودًا بسبب كمية البيانات التي يمكن معالجتها في صفقة واحدة. تتطلب الحسابات اللازمة لتوليد الإثباتات صفرية المعرفة موارد حسابية عالية جدًا، وآلية "الفائز يأخذ كل شيء" يمكن أن تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما تحد ZK rollup من حجم المعاملات في كل دفعة، مما يمكن أن يؤدي إلى الازدحام الشبكي وارتفاع الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، تكلفة ZK rollup القابلة للتنفيذ بشكل كامل تيرلينغ حوالي 2x10^6 ضعف تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي ل Polkadot.
بالإضافة إلى ذلك، فإن مشكلة توفر البيانات في ZK rollup ستزيد من عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين تقديم بيانات المعاملات الكاملة. غالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا يجب أن تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم يتبع Polkadot نهج التنازل عن المركزية من أجل الأداء، أو الاعتماد على الثقة المسبقة من أجل الكفاءة، بل حقق توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر على أرض الواقع اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور المستدام لـ Web3.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
تسجيلات الإعجاب 14
أعجبني
14
6
مشاركة
تعليق
0/400
FlashLoanKing
· منذ 20 س
يمكنك الفوز فقط بالسرعة؟ ألقِ اللوم على المستخدمين إذن.
شاهد النسخة الأصليةرد0
LiquidityWizard
· منذ 20 س
من الناحية النظرية، فإن مقياس دوت = 73.8% من تنازل الأمن... ليس مثالياً بصراحة
شاهد النسخة الأصليةرد0
0xOverleveraged
· منذ 20 س
لا يزال كما هو، انظر إلى كل شيء وابدأ في rollup
شاهد النسخة الأصليةرد0
OneBlockAtATime
· منذ 20 س
دوت هي الأساس، أما البقية فهي وهم.
شاهد النسخة الأصليةرد0
WalletDoomsDay
· منذ 20 س
خليها تتكسر، دعني أبدأ. ما الذي يجعل البلوكتشين معقدًا؟
شاهد النسخة الأصليةرد0
ContractSurrender
· منذ 20 س
تضحية بالأمان وما إلى ذلك، حسناً، من الأفضل الاستسلام في وقت مبكر.
توسيع بولكادوت المرن: التوازن بين القابلية للتوسع والأمان في نظام Web3 البيئي
القابلية للتوسع والموازنة: خيارات تكنولوجية بين Polkadot وبيئة Web3
في عصر تسعى فيه تقنية البلوكشين لتحقيق كفاءة أعلى، تبرز مسألة رئيسية تدريجيًا: كيف يمكن تحقيق الأداء المتوسع مع مراعاة الأمان ومرونة النظام في الوقت نفسه؟ هذه ليست مجرد تحديات على المستوى الفني، بل هي خيارات عميقة في تصميم الهيكل. بالنسبة لنظام Web3، فإن السعي وراء نظام أسرع على حساب الثقة والأمان، لن يدعم الابتكار المستدام حقًا.
كأحد المحركات الرئيسية لتوسيع نطاق Web3، هل ضحت Polkadot ببعض الأمور أثناء سعيها لتحقيق أهداف عالية من حيث القدرة على المعالجة وانخفاض الكمون؟ هل نموذج rollup الخاص بها قد يتنازل عن اللامركزية أو الأمان أو التداخل الشبكي؟ ستتناول هذه المقالة هذه الأسئلة، وتقوم بتحليل عميق للتوازنات والتنازلات التي قامت بها Polkadot في تصميم التوسع، وتقارنها مع حلول سلاسل الكتل الرئيسية الأخرى، مستكشفة الخيارات المختلفة التي اتخذتها في الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
توازن المرونة واللامركزية
تعتمد بنية Polkadot على شبكة من المدققين وسلسلة الترحيل، فهل من الممكن أن يؤدي ذلك إلى إدخال مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن تتشكل نقاط فشل أو تحكم فردي، مما يؤثر على خصائصها اللامركزية؟
يعتمد تشغيل Rollup على مرتبة متصلة بسلسلة الوسيط، ويستخدم التواصل آلية بروتوكول collator. هذا البروتوكول لا يتطلب ترخيصًا أو ثقة على الإطلاق، يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، والتواصل مع عدد قليل من عقد سلسلة الوسيط، وتقديم طلبات تحويل حالة rollup. ستتم معالجة هذه الطلبات من خلال أحد التحقق من core في سلسلة الوسيط، بشرط واحد فقط: يجب أن تكون تحويل الحالة صالحًا، وإلا فلن يتم دفع حالة rollup.
توازن التوسع العمودي
يمكن لـ Rollup تحقيق التوسع الرأسي من خلال استغلال بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال وظيفة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أن التحقق من كتل Rollup لا يتم تنفيذه بشكل ثابت على نواة معينة، مما قد يؤثر على مرونتها.
نظرًا لأن البروتوكول الخاص بتقديم الكتل إلى سلسلة التتابع لا يتطلب إذنًا أو ثقة، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها لـ rollup للتحقق منها. قد يستغل المهاجمون هذه النقطة عن طريق تقديم كتل شرعية تم التحقق منها مسبقًا مرارًا وتكرارًا إلى نوى مختلفة، مما يؤدي إلى استهلاك الموارد بشكل ضار، وبالتالي تقليل إجمالي قدرة rollup وكفاءته.
الهدف من Polkadot هو الحفاظ على مرونة rollup واستخدام موارد سلسلة الترحيل بشكل فعال دون التأثير على الخصائص الأساسية للنظام.
مشكلة موثوقية Sequencer
طريقة بسيطة للحل هي ضبط البروتوكول ليكون "مرخصًا": على سبيل المثال، استخدام آلية القائمة البيضاء، أو افتراض أن مُرتب الثقة لن يقوم بأي سلوك ضار، مما يضمن نشاط الـ rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا القيام بأي افتراضات موثوقة حول sequencer، لأننا نحتاج إلى الحفاظ على خصائص "عدم الثقة" و "عدم الحاجة إلى إذن" للنظام. يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل غير مُساوم
الحل النهائي الذي اختاره Polkadot هو: ترك المشكلة بالكامل لوظيفة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الموثوق الوحيد لجميع معلومات الإجماع، لذلك يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة Polkadot يجب أن يتم التحقق منها.
يحقق هذا التصميم ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوافر، وضمان صحة توزيع core من خلال بروتوكول الاقتصاد المشفر ELVES.
قبل كتابة أي بيانات من rollup إلى طبقة قابلية استخدام البيانات (DA) في Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين بالتحقق من قانونيتها أولاً. يتلقون الإيصالات المرشحة وإثباتات الفعالية المقدمة من المُرتب، والتي تحتوي على كتل rollup وإثباتات التخزين المقابلة. سيتم تسليم هذه المعلومات لمعالجة دالة التحقق من السلاسل المتوازية، حيث سيقوم المدققون على سلسلة الترحيل بإعادة التنفيذ.
تتضمن نتيجة التحقق محدد core، يستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيتحقق المدقق من ما إذا كانت هذه الفهرس تتطابق مع core الذي يتحمل مسؤوليته؛ إذا لم تتطابق، فسيتم تجاهل هذه الكتلة.
تضمن هذه الآلية أن يحتفظ النظام دائمًا بخصائص عدم الثقة وعدم الإذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core يمكن أن تبقى مرونة.
الأمان
في سعيها نحو القابلية للتوسع، لم تتنازل بولكادوت عن الأمان. يتم تأمين rollup بواسطة سلسلة الوسيط، حيث يكفي وجود مُرتب صادق للحفاظ على البقاء.
من خلال بروتوكول ELVES، ستقوم Polkadot بتوسيع سلامتها بالكامل لتشمل جميع rollup، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذلك، يمكن لـ rollup الخاص بـ Polkadot تحقيق توسع حقيقي دون التضحية بالأمان.
قابلية التعميم
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في غضون ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات التي يمكن تنفيذها في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
التعقيد
من المؤكد أن زيادة السعة وتقليل التأخير يجلبان تعقيدًا، وهذه هي الطريقة الوحيدة المقبولة للتوازن في تصميم الأنظمة.
يمكن لـ Rollup تعديل الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. يجب عليهم أيضًا تنفيذ بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجية إدارة الموارد للـ rollup، والتي قد تعتمد على المتغيرات الموجودة على السلسلة أو خارجها. على سبيل المثال:
على الرغم من أن الأسلوب الآلي أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار قد ارتفعت بشكل ملحوظ.
التفاعل بين الأنظمة
يدعم Polkadot التشغيل البيني بين مختلف rollups، بينما لا تؤثر التوسعة المرنة على قدرة نقل الرسائل.
تتم الاتصالات الرسائلية عبر rollup من خلال طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم بولكادوت أيضًا نقل الرسائل خارج السلسلة، حيث سيكون هناك سلسلة وسيطة كواجهة تحكم، بدلاً من واجهة البيانات. ستؤدي هذه الترقية إلى تحسين قدرة الاتصال بين الــrollups مع التوسع المرن، مما يعزز بشكل أكبر القدرة على التوسع العمودي للنظام.
التوازنات في البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالباً ما يأتي على حساب اللامركزية والأمان. ولكن من منظور معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لبولكادوت منخفضة، فإن أدائها لا يزال دون المستوى.
سلسلة الكتل العامة A
لا تعتمد سلسلة الكتل العامة A على بنية تجزئة Polkadot أو Ethereum، بل تعتمد على بنية ذات طبقة واحدة عالية الإنتاجية لتحقيق القابلية للتوسع، مستندة إلى إثبات التاريخ، المعالجة المتوازية لوحدات المعالجة المركزية، وآلية توافق قائمة على القائد، حيث يمكن أن يصل TPS النظري إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
التاريخ يثبت أن المعالجة المتوازية تتطلب متطلبات عالية جداً من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زاد عدد العقد المراهنة، زادت فرصها في إنتاج الكتل، في حين أن العقد الصغيرة تكاد لا تملك أي فتحة، مما يزيد من حدة المركزية، ويزيد أيضاً من خطر تعطل النظام بعد الهجوم.
تضحي شبكة البلوكتشين A من أجل تحقيق TPS باللامركزية وقدرة مقاومة الهجمات، حيث أن معامل ناكاموتو الخاص بها لا يتجاوز 20، وهو أقل بكثير من 172 الخاصة بـ Polkadot.
سلسلة بلوكشين معينة B
تدعي سلسلة الكتل العامة B أن معدل المعاملات في الثانية (TPS) يمكن أن يصل إلى 104,715، لكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظل ظروف مثالية من الشبكة والأجهزة. بينما وصلت Polkadot في شبكة عامة لامركزية إلى 128K TPS.
توجد ثغرة أمنية في آلية توافق الشبكة العامة B: هوية عقد التحقق المقسمة قد تتعرض للكشف مسبقًا. كما أن الورقة البيضاء للشبكة العامة B تشير بوضوح إلى أن هذا قد يحسن من عرض النطاق الترددي، لكنه قد يُستغل بشكل خبيث. نظرًا لعدم وجود آلية "إفلاس المقامر"، يمكن للمهاجمين الانتظار حتى يتمكنوا من السيطرة الكاملة على جزء معين، أو قطع الاتصال بالمحققين الصادقين من خلال هجوم DDoS، مما يؤدي إلى تعديل الحالة.
بالمقارنة، فإن مصدقو Polkadot يتم تعيينهم عشوائيًا ويُكشف عنهم بتأخير، مما يجعل من المستحيل على المهاجمين معرفة هوية المصدقين مسبقًا. يجب أن يراهن المهاجمون على السيطرة الكاملة لتحقيق النجاح، طالما أن هناك مصدقًا أمينًا واحدًا يبدأ نزاعًا، فسوف يفشل الهجوم ويتسبب في خسارة المهاجم لرهانه.
سلسلة عامة معينة C
تستخدم سلسلة الكتل العامة C بنية الشبكة الرئيسية + الشبكة الفرعية للتوسع، حيث تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS)، C-Chain (العقود الذكية، ~100-200 TPS)، و P-Chain (إدارة المدققين والشبكات الفرعية).
يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى ~5000، مشابهة لفكرة بولكادوت: تقليل الحمل على shard واحد لتحقيق التوسع. ولكن إحدى سلاسل الكتل العامة C تسمح للمحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن أن تضع الشبكة الفرعية متطلبات إضافية مثل الجغرافيا و KYC، مما يضحي باللامركزية والأمان.
في بولكادوت، تشارك جميع الأنظمة المجمعة ضمان أمان موحد؛ بينما الشبكة الفرعية لسلسلة معينة C ليس لديها ضمان أمان افتراضي، وبعضها قد يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، لا يزال يتعين عليك التنازل عن الأداء، ومن الصعب تقديم وعود أمان حاسمة.
سلسلة معينة D
استراتيجية التوسع لسلسلة الكتل العامة D تركز على قابلية التوسع في طبقة rollup بدلاً من معالجة المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
رول أب متفائل
معظم عمليات التدوير المتفائلة الحالية مركزية (بعضها يحتوي حتى على مكون واحد فقط) مما يؤدي إلى مشاكل مثل عدم كفاية الأمان، والعزلة، والارتفاع في التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادة ما تستغرق عدة أيام).
زك رول أب
تواجه تنفيذات ZK rollup قيودًا بسبب كمية البيانات التي يمكن معالجتها في صفقة واحدة. تتطلب الحسابات اللازمة لتوليد الإثباتات صفرية المعرفة موارد حسابية عالية جدًا، وآلية "الفائز يأخذ كل شيء" يمكن أن تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالبًا ما تحد ZK rollup من حجم المعاملات في كل دفعة، مما يمكن أن يؤدي إلى الازدحام الشبكي وارتفاع الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، تكلفة ZK rollup القابلة للتنفيذ بشكل كامل تيرلينغ حوالي 2x10^6 ضعف تكلفة بروتوكول أمان الاقتصاد المشفر الأساسي ل Polkadot.
بالإضافة إلى ذلك، فإن مشكلة توفر البيانات في ZK rollup ستزيد من عيوبه. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين تقديم بيانات المعاملات الكاملة. غالبًا ما يعتمد ذلك على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا يجب أن تكون تسوية.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم يتبع Polkadot نهج التنازل عن المركزية من أجل الأداء، أو الاعتماد على الثقة المسبقة من أجل الكفاءة، بل حقق توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم بروتوكولات بدون إذن، وطبقة أمان موحدة، وآليات إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر على أرض الواقع اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور المستدام لـ Web3.