بوابة نشر Polkadot: لماذا تختار المشاريع النشر على Polkadot بدلاً من أن تصبح Layer 2؟

في الماضي، لم يكن نشر Rollup على Polkadot أمرًا سهلاً أبدًا. فكلما كان النظام أكثر مرونة، كان ذلك يعني غالبًا أن عملية النشر أكثر تعقيدًا: من تحديثات SDK، إلى مزادات الفتحات، ثم الحوكمة وترقيات وقت التشغيل، كل مرحلة يمكن أن تشكل تحديًا للفريق.

لتغيير هذا الوضع، أطلقت Parity هذا العام Polkadot Deployment Portal (PDP) — وهو "بوابة شاملة" من البناء إلى النشر ثم الوصول. هدفها واضح: خفض العتبة، تبسيط العملية، وجعل أي فريق قادرًا على بدء وتشغيل Rollup الخاص به بسرعة واستقرار على Polkadot.

في هذه المقالة، سيأخذنا Santi Balaguer، رئيس تطوير المنتجات في Parity، في جولة لمراجعة تطور تجربة نشر Polkadot خلال السنوات الماضية، وتحليل فلسفة التصميم وراء PDP، ومشاركة كيف غيّر هذا الأداة تدريجيًا طريقة إطلاق Rollup.

تجربة النشر على Polkadot: كلما كان النظام أكثر مرونة، كان أكثر تعقيدًا

Jay: مرحبًا بك في Space Monkeys، اليوم معنا Santi Balaguer المسؤول عن تطوير المنتجات في Parity. سنتحدث اليوم عن PDP، ما هو الاسم الكامل لـ PDP؟

Santi: هو Polkadot Deployment Portal — بوابة نشر Polkadot.

Jay: قبل أن تبدأ في PDP، ما الذي كنت تفعله في Parity خلال الأربع أو خمس سنوات الماضية؟

Santi: كنت دائمًا على اتصال وثيق مع مجتمع المطورين، وكنت أساعدهم بشكل أساسي في إطلاق السلاسل المتوازية وRollups على Polkadot. كما قلت، كنت في Parity منذ ما قبل إطلاق السلاسل المتوازية.

Jay: ما هي بعض المشاريع التي تواصلت معها كثيرًا والتي قد نكون على دراية بها؟

Santi: كنت مسؤولاً عن مشروع Substrate Builders، وكان هناك العديد من المشاريع المعروفة. أكثر ما أتذكره هو فريق Hydration. ما زلت أذكر عندما قدم Jakub عرضًا وشرح فكرة Omnipool الخاصة بهم والمشاكل التي يريد Hydration حلها. عرض صورة meme شهيرة "money printer goes brrrr" لشرح سبب اقتراحهم لحل جديد. ما زلت أمزح مع Jakub حول هذا حتى الآن.

Jay: هاها، رائع. بالتأكيد رأيت العديد من المشاريع تنجح على Polkadot، وسمعت عن الكثير من مشاكلهم. هل يمكنك التحدث عن أكثر الأمور المزعجة في نشر المشاريع على Polkadot خلال السنوات الماضية؟

Santi: بالطبع. Polkadot هو نظام معقد للغاية، يجب أن تفهمه حقًا حتى يعمل مشروعك بسلاسة. هذه التعقيد يأتي من مرونته — كلما كان النظام أكثر مرونة، كان أكثر تعقيدًا.

في البداية، إذا أردت تشغيل سلسلة متوازية على Polkadot، كان عليك أولاً التعامل مع تحديثات SDK "التدميرية". في ذلك الوقت لم يكن هناك Polkadot SDK، فقط Substrate، وكان الأمر مختلفًا عما هو عليه الآن. بعد إعداد بيئة التطوير، كان عليك جمع الدعم من المجتمع والمشاركة في مزاد الفتحات. المزاد نفسه كان تحديًا، تحتاج إلى دعم كافٍ، ونتيجة المزاد لا تعرفها حتى اللحظة الأخيرة. حتى إذا فزت، عليك الانتظار ثلاثة أشهر حتى يتم تشغيل السلسلة المتوازية فعليًا. بالإضافة إلى ذلك، يتم تأجير الفتحة لمدة عامين فقط. لذا كان عليك أن تبذل جهدًا كبيرًا في التطوير التقني والتعبئة المجتمعية في نفس الوقت للحصول على مكان على Polkadot.

Jay: صحيح. في السنوات الأخيرة، تحسنت التجربة كثيرًا. هل يمكنك التحدث عن عملية هذا التغيير؟

Santi: بالتأكيد. أعتقد أن Parity بذلت جهدًا كبيرًا، خاصة في تقليل تحديثات Polkadot SDK التدميرية.

على الرغم من وجود تحديثات الآن، إلا أن الاستقرار أفضل بكثير من قبل، والتوافق بين الإصدارات أصبح أفضل. الآن يمكن للمطورين الاعتماد على إصدار SDK الذي يستخدمونه. حتى أن بعض السلاسل المتوازية لا تزال تستخدم إصدارات قديمة من Substrate، لكنها لا تزال تعمل بشكل طبيعي على Polkadot.

هناك أيضًا إدخال Cortime (على الرغم من أنه معقد إلى حد ما)، لكنه خفض بشكل كبير عتبة المطورين. جعل من السهل على الجميع المحاولة، وخفض الحواجز لدخول Polkadot كثيرًا، وأعتقد أنه يجب علينا الاستفادة من ذلك قدر الإمكان.

لماذا تختار المشاريع الآن النشر على Polkadot بدلاً من عمل L2 على Ethereum؟

Jay: على الرغم من وجود العديد من التحديات في ذلك الوقت، إلا أن العديد منها تم حله الآن. لماذا تعتقد أن مشروعًا اليوم قد يختار النشر على Polkadot؟ لماذا لا يذهب إلى Ethereum ويعمل L2، أو يطلق L1 خاص به؟ ما السبب؟

Santi: هذا سؤال مثير للاهتمام. أولاً، أعتقد أنه كمجتمع، يجب أن نقوم بمزيد من التواصل والترويج في هذا المجال. من وجهة نظري الشخصية، Polkadot هو حاليًا السلسلة الوحيدة التي تم تصميمها منذ البداية لتحمل Rollup بشكل أصلي. يوفر للمطورين بنية تحتية لا توجد في أماكن أخرى.

• على سبيل المثال، يوفر Polkadot طبقة توافر بيانات (data availability) ضخمة لـ Rollup، بينما إذا كنت على L2 في Ethereum، عليك الاعتماد على أنظمة خارجية أو "blob" لحل ذلك.

• أيضًا، التواصل الأصلي بين السلاسل المتوازية (الاتصال عبر السلاسل)، هذا غير موجود في Rollup الأخرى. غياب هذه الميزة يقلل من أمان النظام.

• أما بالنسبة للأداء، فقد أثبت Spamming أن مستوى TPS في Rollup على Polkadot بارز جدًا في الصناعة.

• هناك أيضًا التوسع المرن، Polkadot هو النظام الوحيد حاليًا الذي يمكنه توسيع أو تقليص البنية التحتية حسب الحاجة في أي وقت. على سبيل المثال، إذا أرادت Mythical إطلاق لعبة جديدة فجأة، وتوقعت زيادة المستخدمين عشرة أضعاف في الأسبوع الأول، يمكنهم دعم هذا التدفق على الفور تقريبًا دون تغييرات كبيرة.

أعتقد أننا في مناقشاتنا السابقة حول "السلاسل المتوازية وRollup" لم نضع Polkadot في مركز الاهتمام، وفوتنا بعض الفرص. لكن لا يزال لدينا فرصة لإعادته إلى المسرح الرئيسي.

Jay: نعم، قلت لي من قبل أن Polkadot تم تصميم بنيته الأساسية منذ البداية من أجل Rollup. فقط لم نكن نسميه Rollup في البداية.

Santi: صحيح، وهناك نقطة غالبًا ما نتجاهلها، وهي الأمان المشترك. إذا نظرنا إلى تطور البلوكشين: بدأ الأمر مع Bitcoin، ثم جاء Ethereum. بعد ذلك بدأ الجميع في إطلاق "Ethereum" جديدة، ويعلنون أن "سلسلتنا أفضل لأنها تحتوي على ميزات A وB وC". لكن المشكلة هي أن ضمان أمان سلسلة جديدة أمر صعب للغاية. تحتاج إلى مجموعة تحقق كبيرة وقوية، وهذا ليس سهلاً.

في ذلك الوقت، فكر Gavin: لماذا لا أقدم الأمان كخدمة، وأدمجه في الطبقة الأساسية؟ هذا هو ما يميز Polkadot. فهو لا يوفر فقط الأمان المشترك، بل يحقق أيضًا تواصل فعال بين هذه الـ Rollup، وهذا ما يتقنه Polkadot بشكل خاص.

كيف نشأت فكرة PDP؟

Jay: رائع. إذا أراد Rollup طبقة توافر بيانات مدمجة (وبحجم كبير)، ولا يريد الاعتماد على مشاريع أخرى، ويريد أيضًا أداء TPS وقدرة معالجة قوية، بالإضافة إلى تواصل سلس مع Rollup أخرى، فإن Polkadot بالفعل جذاب جدًا. لكن قبل ظهور PDP، كان نشر سلسلة متوازية معقدًا ويستغرق وقتًا طويلاً. لماذا ظهرت فكرة أداة PDP في البداية؟

Santi: في الواقع، هذه الفكرة كانت قيد التحضير لبعض الوقت، رغم أننا بدأنا العمل فعليًا في نوفمبر الماضي.

ثم بدأ فريقنا في مارس أو أبريل من هذا العام في التركيز الكامل على هذا المشروع، والتقدم سريع جدًا الآن، والجميع يعمل على تحويل هذه الفكرة إلى واقع خطوة بخطوة. كانت هذه الفكرة قيد التحضير منذ فترة، وهناك بالفعل بعض الحلول المشابهة في الصناعة. على سبيل المثال، في نظام Ethereum هناك Conduit وGelato؛ وفي Polkadot كان هناك Tanssi، لكنهم انتقلوا لاحقًا إلى Ethereum، والفكرة متشابهة.

رأينا أن Polkadot لم يتمكن من تنفيذ ذلك، فقررنا أن نقوم بذلك بأنفسنا لضمان نجاح الأمر. نحن نفهم Polkadot بشكل أعمق، ونعرف كيف نجعل نشر المشاريع أسهل للمطورين، وهذا هو هدف PDP.

نحن لا نتخذ القرارات للمطورين، بل نقدم الإرشاد والخيارات

Jay: إذًا، من هو الجمهور المستهدف لـ PDP؟ أذكر أن Polkadot في البداية كان لديها مشكلة أن بعض المشاريع بدأت مباشرة في عمل Rollup، بينما كان يكفي أن تكون عقدًا ذكيًا. برأيك، ما نوع المشاريع التي تناسب أن يكون لديها Rollup خاص بها؟

Santi: هذا سؤال جيد، لكن لا أعتقد أن هناك إجابة ثابتة. حتى الآن نجد بعض المشاريع التي يمكن أن تكون عقدًا ذكيًا فقط. لكن أحيانًا يحتاج الفريق إلى الاستقلالية، ولا يريد الاعتماد على بنية تحتية لسلاسل أخرى؛ وأحيانًا يتوقعون أن يكون لديهم حجم معالجة كبير في المستقبل، لذا يفضلون البدء بـ Rollup، وهناك أسباب أخرى تجعلهم يحتاجون إلى سلسلة خاصة بهم أو استقلالية أكبر في البنية التحتية.

على سبيل المثال، Omnipool من Hydration، يمكننا الجدال حول ما إذا كان يمكن أن يكون مجرد عقد، لكن أعتقد أنه من المنطقي أن يكون سلسلة. من ناحية أخرى، انظر إلى Uniswap على Ethereum، بدأ كعقد، ثم أنشأ سلسلة خاصة به، لكن هل يحتاجون حقًا إلى سلسلة؟ ربما لا، لكن لديهم اعتباراتهم التجارية الخاصة.

لذا لا يوجد جواب مطلق، بل هو نتيجة لتفاعل التقنية والأعمال. بالنسبة لي، الأهم هو: نحن لا نتخذ القرارات للمطورين، بل نقدم الإرشاد ونترك لهم حرية الاختيار. سواء أرادوا عمل Rollup أو عقد، يجب أن يكون من السهل عليهم التجربة والمحاولة.

تجربة PDP الكاملة: من البناء إلى النشر ثم الوصول، إطلاق Rollup أصبح سهلاً للغاية

Jay: حسنًا، لنفترض أن فريقًا اتخذ القرار، سواء بنفسه أو بمساعدة Magenta Labs أو فريق BD. في النهاية قرروا نشر rollup على Polkadot. ما هي تجربتهم عند دخول PDP؟ كيف هي عملية النشر الآن؟

Santi: في تصميم PDP، قسمنا العملية إلى ثلاث مراحل رئيسية: Build (البناء) — Deploy (النشر) — Access (الوصول)، وهذه الأجزاء مترابطة.

في مرحلة "البناء"، السؤال الأساسي هو "كيف أبدأ". فكرتنا هي: أفضل طريقة هي من خلال قوالب وقت التشغيل (runtime templates). حاليًا، يعمل فريق OpenZeppelin على تطوير قوالب ذات صلة، وفريق Pop CLI وفريق ROG يعملون أيضًا في هذا المجال. Pop CLI هو أداة يمكنك استخدامها على جهازك لكتابة Rollup. نحن نتعاون معهم لربطها مع المرحلتين الأخريين في PDP (النشر والوصول).

على سبيل المثال، بعد بناء Rollup على Pop CLI، يمكنك ربطه مباشرة بـ PDP ونشره، هكذا صممنا ونفذنا ذلك. بهذه الطريقة، يمكن للمطورين إكمال العملية بالكامل باستخدام CLI، مثل Heroku أو Vercel في Web2، حيث لديهم CLI خاص بهم. إذا كنت تفضل هذه الطريقة، يمكنك استخدام CLI مباشرة؛ أو يمكنك استخدام الواجهة الرسومية بالكامل. كلا الطريقتين متاحتين.

Jay: أي أنه بالإضافة إلى البناء باستخدام القوالب، يمكنك أيضًا البناء باستخدام Pop CLI ثم النشر. هل PDP نفسه يساعد المطورين في اتخاذ بعض الخيارات؟ أم أنه مجرد أداة تعتمد على الفريق نفسه؟

Santi: كلاهما. نأمل أن يكون PDP أداة خدمة ذاتية للمطورين. لكن إذا واجهوا مشاكل رئيسية، سنكون بجانبهم لدعمهم وضمان حصولهم على المساعدة اللازمة. وبالطبع، إذا أراد أحدهم التجربة بنفسه، فلا مشكلة هاها.

Jay: ممتع. هل يمكنك إعطاء بعض أمثلة القوالب؟ ما هي المفضلة لديك؟

Santi: على سبيل المثال، لدى فريق ROG قالب Pilot Revive جاهز يمكنك استخدامه مباشرة للإطلاق. لدى OpenZeppelin قالب Frontier، إذا أردت تشغيل سلسلة تدعم EVM، يمكنك استخدامه مباشرة.

Jay: رائع، إذًا هناك عدة خيارات متعلقة بالعقود الذكية.

Santi: صحيح. وهناك قوالب بدون عقود ذكية. على سبيل المثال، إذا أراد أحدهم فقط إنشاء سلسلة لإدارة الأصول، خاصة المشاريع المتعلقة بالأصول الواقعية (RWA)، هناك قوالب مناسبة لذلك أيضًا. باختصار، هناك العديد من الخيارات في البداية، ويمكنك التوسع لاحقًا.

Jay: هل يمكن إضافة Pallet جديدة إلى القالب حسب الحاجة؟

Santi: في البداية لا. الفكرة هي أن تبدأ من القالب، ثم نوجهك خطوة بخطوة لترقية وقت التشغيل. نأمل من خلال ذلك أن يساعد الفريق في العثور على توافق المنتج مع السوق تدريجيًا. هذا التصميم مثير للاهتمام، وهو أحد الميزات التي نركز عليها حاليًا. نحن نستخدم أداة رائعة من فريق Puppet، تقارن بين وقت التشغيل الجديد الذي ستقوم بترقيته ووقت التشغيل الحالي، وتنتج تقريرًا يوضح ما تغير، وما قد يؤثر على المطورين، وما يجب الانتباه إليه.

Jay: نعم، رأيت أنكم دمجتم هذا مؤخرًا، رائع.

Santi: نعم، انتهينا منه هذا الأسبوع فقط. ستحصل على تقرير ترقية وقت التشغيل، للتأكد من أن ما ستنشره يتوافق مع توقعاتك. نريد أيضًا إضافة ميزة: محاكاة تشغيل عدة كتل في الخلفية لاختبار وقت التشغيل الجديد. إذا كان كل شيء طبيعيًا، سنخبرك "يمكنك النشر"؛ إذا كان هناك مشكلة، سنخبرك "الاختبار لم ينجح، من الأفضل أن تراجع". هذا يساعد الفرق على تجنب الأخطاء أثناء الترقية. نعتقد أن إحدى ميزات Polkadot هي دعم ترقيات وقت التشغيل المرنة، ويمكن للفرق الاستفادة من ذلك للتكرار السريع والعثور على توافق المنتج مع السوق.

Jay: انتظر، هل هذه المرحلة تعتبر جزءًا من "النشر"؟ ما تحدثنا عنه من البناء إلى وقت التشغيل، هل هذا ضمن النشر؟

Santi: نعم، هناك بعض التداخل هنا. يمكنك أن تفهم أن البناء يبدأ من القالب؛ أما النشر فيتعلق بالبنية التحتية الأساسية. في السابق، كنت بحاجة إلى فريق DevOps خاص بك لبناء عقد collator وإدارة العمليات، أما الآن فلا داعي للقلق بشأن ذلك في البداية. إذا تطور المشروع وأصبح لديك تمويل وموارد، يمكنك تشكيل فريق إدارة خاص بك، وسنساعدك في الانتقال. لكن في البداية، نحن نتولى هذه الأمور.

Jay: من يقوم بذلك الآن؟

Santi: حاليًا Parity هي من تقدم ذلك. لكن في المستقبل سنسمح للمطورين باختيار منصة السحابة التي يريدون النشر عليها، وربما حتى IBP (مزود البنية التحتية)، لكن تجريد هذه الطبقة يحتاج بعض الوقت، لذا الآن لضمان التجربة، نستخدم بنية Parity الخاصة بنا، لكن في النهاية سنفتح المزيد من الخيارات.

أطلقنا أيضًا مفهومًا يسمى BDU (Basic Deployment Unit، وحدة النشر الأساسية)، إذا أردت نشر Rollup على الشبكة الإنتاجية، سننشر لك بنية تحتية موحدة، تتضمن ثلاثة عقد collator، أحدها يمكن استخدامه كنقطة نهاية RPC، وسنضيف لك indexer أيضًا.

نحن نتعاون الآن مع Subscan، لديهم حل مفتوح المصدر، ونخطط لدمجه في PDP. بذلك ستحصل ليس فقط على indexer، بل أيضًا على مستعرض كتل، وهذه الأمور كانت تتطلب من الفرق وقتًا طويلاً لبنائها، أما الآن فنحن نوفرها لك في مكان واحد، وهذا تصميم جيد جدًا.

Jay: واو، يبدو رائعًا. هل هذه المرحلة تعتبر بناء؟

Santi: هذه هي النشر.

Jay: فهمت، إذًا في هذه المرحلة يكون Rollup قد بدأ العمل؟ بدأ في إنتاج الكتل؟ ويمكن للفريق ترقية وقت التشغيل باستمرار للتجربة والتكرار والعثور على توافق المنتج مع السوق؟ ثم تأتي الخطوة الأخيرة "الوصول (Access)"، صحيح؟ ما هي هذه؟

Santi: صحيح! Access هو ما يميز Polkadot، وأعتقد أنه ما يمنح فرق Rollup قيمة فريدة. البناء والنشر يتعلقان بوقت التشغيل والبنية التحتية، ويمكن للجميع اكتشافهما بسرعة، لكن الاستفادة الحقيقية من ميزات Polkadot تظهر هنا. على سبيل المثال، Coretime، وهو جزء من Access، سيقوم PDP بشراء Coretime مسبقًا، بحيث يمكن للمطورين نشر Rollup فورًا دون الانتظار 28 يومًا لبدء إنتاج الكتل، وهذا تحسين كبير في تجربة المستخدم.

Jay: إذا أردت النشر، هل يجب أن أشتري Coretime بنفسي من PDP؟

Santi: سنشتريه لك، ثم نحصّل الرسوم منك. في الواقع، نقدم خيارات مختلفة لـ Coretime. إذا أردت البدء بقوة، يمكنك استخدام نواة كاملة. لكننا نقدم أيضًا "نواة مقسمة"، أي جزء من النواة، فإذا أردت تجربة الأمر أولاً دون إنفاق الكثير، يمكنك استخدام جزء صغير فقط.

Jay: هل هذه الميزة متاحة الآن؟

Santi: متاحة بالفعل على PDP. وهي تعمل الآن على شبكتي Westend وPaseo. أطلقت Paseo مؤخرًا النواة المقسمة، وفي Westend يمكنك تداول جزء من النواة مباشرة، والعيب هو أن وقت إنتاج الكتل سيصبح أطول، لكن الميزة هي خفض العتبة بشكل كبير، ويمكنك تجربة الأمر بتكلفة منخفضة جدًا. إذا نجحت التجربة، يمكنك الترقية إلى نواة كاملة والاستمتاع بسرعة إنتاج كتل كل ست ثوانٍ، وكل ذلك يمكن إكماله على PDP. لكن آلية الوصول لا تزال بحاجة لحل كيفية الاستفادة الفعالة من Polkadot. حاليًا، Polkadot Hub كوظيفة مهمة على وشك الإطلاق، ونحن متحمسون جدًا لذلك.