ثلاثة أمثلة توضح ما يمكن أن تحققه Revive و Polkadot Hub!

هذه المقالة من إعداد PolkaWorld وتستند إلى محتوى كلمة Parity في مؤتمر Sub0.

على مدى السنوات الماضية، تطورت Polkadot لتصبح نظامًا معياريًا قويًا ومرنًا. لكن لديها مشكلة واضحة: العديد من الوظائف الأساسية موزعة على سلاسل مختلفة.

على سبيل المثال:

• محرك العقود الذكية متوفر فقط على بعض السلاسل المتوازية؛ 
• أنظمة الحوكمة، التخزين، والرموز الأصلية موجودة على سلاسل متوازية أو سلاسل نظامية أخرى. 

هذا التوزيع يسبب تعقيدًا كبيرًا. حتى أبسط العمليات قد تتطلب تفاعلًا بين عدة سلاسل، وتعتمد على الاتصالات غير المتزامنة لإكمالها.

Polkadot Hub سيغير هذا الوضع جذريًا، وسيبسط كل شيء بشكل كبير!

Polkadot Hub: جمع كل الوظائف في مكان واحد

اسمحوا لي أن أقدم نفسي، أنا Torsten، مسؤول فريق العقود الذكية في Parity. اليوم، سأتحدث معكم عن Polkadot Hub ومحرك تنفيذ العقود الذكية المدمج فيه، وكيف ستعيد هذه القدرات الجديدة تعريف طريقة بناء التطبيقات على Polkadot.

لنستعرض بإيجاز المشاكل السابقة، ففي البنية القديمة:

• العقود الذكية يمكن نشرها فقط على السلاسل المتوازية؛ 
• الرموز الأصلية، التخزين، والحوكمة موزعة على السلسلة الرئيسية أو سلاسل النظام. 

وهذا يعني أنه إذا احتاج تطبيقك إلى الجمع بين هذه الأنظمة، يجب أن يعتمد على XCM وتدفقات رسائل غير متزامنة معقدة.

والنتيجة:

• المطورون لا يعرفون على أي سلسلة يجب نشر التطبيق؛
• العملية مجزأة، وسلسلة الأدوات غير موحدة؛
• طرق تشغيل السلاسل المختلفة غير متشابهة، مما يؤدي إلى تجربة تطوير مجزأة للغاية. 

لكن الآن، كل شيء على وشك أن يتغير مع اقتراب إطلاق Polkadot Hub!

Polkadot Hub هو "مركز التطبيقات" الجديد في نظام Polkadot البيئي. حيث يجمع كل الوظائف الأساسية التي كانت موزعة سابقًا:

• الأصول 
• الرموز الأصلية 
• العملات المستقرة 
• التخزين 
• الحوكمة 
• العقود الذكية 

كلها في بيئة واحدة موحدة.

مع ظهور Hub، تم إزالة الحدود بين السلاسل، مما يعني أن تطبيقات Polkadot في المستقبل ستبنى وتنشر بطريقة جديدة كليًا.

العقود الذكية تدخل عصر المحرك المزدوج: Revive سيعيد تشكيل طبقة التطبيقات في Polkadot

دعونا نتحدث عن الجزء الذي يهمني أكثر — محرك تنفيذ العقود الذكية في Hub.

هذا المحرك يسمى Revive. وأبرز ما فيه: Revive يدمج بيئتين للتنفيذ، ويمكنه تشغيل نوعين من أنظمة العقود الذكية في نفس الوقت.

• الأولى هي EVM المعروفة، ويمكنها تشغيل عقود EVM المكتوبة بـ Solidity مباشرة؛ 
• والثانية هي PVM الحديثة، وتدعم البرمجة بـ Solidity أو Rust. 

الأهم من ذلك، أن EVM وPVM ليستا عالمين منفصلين، بل تعملان في نفس مساحة العناوين ويمكنهما استدعاء بعضهما البعض. هذا يعني أن عقود النظامين قابلة للتشغيل البيني بالكامل. يمكنها استدعاء بعضها البعض، وحتى عند الاستدعاء، لا تعرف ما إذا كان العقد الآخر هو PVM أو EVM.

بالإضافة إلى ذلك، يتيح Revive للعقود الذكية الوصول المباشر إلى وظائف النظام الأساسية مثل التخزين، الحوكمة، إدارة الأصول، وXCM من خلال precompiles. كل هذه المكونات متصلة بسلاسة مع Revive.

الآن سأشرح بإيجاز كيفية نشر التطبيقات على Revive. حاليًا، يمكنك اختيار لغتين: Solidity أو Rust.

إذا كنت تستخدم Solidity، يمكنك استخدام المترجم التقليدي لـ Solidity لتحويل الكود إلى بايت كود EVM وتشغيله على محرك EVM في Revive. كما يمكنك استخدام مترجم Resource C المطور من Parity لتحويل كود Solidity إلى بايت كود PVM ثم نشره على محرك PVM. سواء كان الكود EVM أو PVM، يمكنهم استدعاء بعضهم البعض. 

إذا كنت تستخدم Rust، فقط استخدم مترجم Rust ويمكنك ترجمة ونشر عقود PVM الذكية. هذه العقود يمكنها أيضًا التفاعل مباشرة مع مكونات النظام. 

الآن سأشرح لماذا يحتاج Revive إلى محركي تنفيذ، وسأتحدث عن مزايا كل منهما.

PVM: محرك تنفيذ عالي الأداء وحديث

PVM هو بيئة تنفيذ عقود ذكية جديدة كليًا، وتوفر قدرة حسابية أعلى بكثير من EVM التقليدية. لذلك:

• يمكنك نشر عقود ذكية أكبر وأكثر تعقيدًا 
• يمكنك بناء تطبيقات جديدة لم يكن من الممكن ظهورها سابقًا 

PVM مبنية على مجموعة تعليمات RISC-V. Ethereum تناقش مستقبلًا استخدام RISC-V، لكن Revive اعتمدتها مسبقًا وأتاحتها للمطورين فورًا.

طرق تنفيذ Revive نوعان:

• وضع التنفيذ التفسيري (الوضع الحالي، أداء متوسط) 
• وضع الترجمة الفورية JIT (سيفتح العام القادم، وسيطلق العنان للأداء الكامل) 

في وضع JIT، يمكنك تنفيذ عمليات حسابية ثقيلة جدًا داخل العقد الذكي، مثل:

• عمليات رياضية معقدة 
• خوارزميات التشفير (وهي شبه مستحيلة على EVM) 

على EVM، إذا أردت إضافة بدائية تشفير جديدة، يجب ترقية precompile على مستوى الشبكة، وهو أمر معقد جدًا؛ أما في PVM، يمكنك تنفيذ "precompile خاص بك" مباشرة داخل العقد الذكي، بفضل القدرة الحسابية الكبيرة.

لماذا ما زلنا بحاجة إلى EVM؟

لأن EVM لها مزايا واضحة أيضًا:

• يمكنك نقل البروتوكولات التي تعمل على Ethereum أو أي سلسلة EVM أخرى إلى Revive مباشرة
• لا حاجة لتعديل الكود 
• لا حاجة لتغيير الأدوات 
• يمكنك الاستمرار في استخدام Foundry وHardhat 
• النشر جاهز للاستخدام 

بالإضافة إلى ذلك، يمكن لعقود EVM وPVM استدعاء بعضها البعض بسلاسة.

أشير إلى هذه النقطة تحديدًا، لأنه إذا كان بروتوكولك الأصلي تم تجميعه بواسطة مترجم Solidity قديم، فقد لا يعمل البايت كود على PVM، لكنه سيعمل بشكل كامل على محرك EVM في Revive.

لهذا السبب ما زلنا بحاجة إلى محرك EVM — فهو يضمن التوافق الكامل مع EVM.

ومع ذلك، هناك فرق رئيسي بين محرك EVM لدينا وEthereum القياسي: طريقة معالجة الغاز والموارد مختلفة.

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

• موارد Polkadot تسمى weights (الأوزان)، وهي ثنائية الأبعاد، أي تشمل نوعين مختلفين من الموارد يجب حسابهما؛ 
• بالإضافة إلى ذلك، أضاف محرك العقود الذكية في Revive نوعًا ثالثًا من الموارد: وديعة التخزين (storage deposit). 

أي أن النظام يدير فعليًا ثلاثة أنواع من الموارد.

لكننا ما زلنا نرغب في الحفاظ على نفس طريقة الاستخدام مع أدوات Ethereum، لذا نقوم بتعيينها إلى مورد واحد "يبدو كأنه غاز". بمعنى آخر، محافظ Ethereum لا تفهم موارد Polkadot الداخلية، لذا نقوم بمحاكاة غاز على طريقة Ethereum. التنفيذ الداخلي هو تعيين الأنواع الثلاثة من الموارد إلى "غاز" بطريقة حتمية.

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

بهذه الآلية، يمكننا الحفاظ على التوافق مع Ethereum وضمان قدرة العقود الذكية على مقاومة هجمات DOS.

ثلاثة أمثلة توضح ما يمكن أن يحققه Revive وPolkadot Hub

الآن، أود أن أعود إلى Polkadot Hub ككل.

يجب أن أذكر هنا مشروعًا مهمًا: Asset Hub Migration (هجرة مركز الأصول). دوره هو وضع الأساس لـ Polkadot Hub، بحيث يمكن للتخزين، الرصيد، الأصول، والحوكمة العمل جميعًا في بيئة موحدة واحدة.

تم الانتهاء من Asset Hub Migration مؤخرًا، قبل بضعة أسابيع فقط.

الآن، كل شيء جاهز، ويمكن لـ Revive أن يطلق كامل قدراته في هذه البيئة.

هذه هي البيئة المثالية التي صممناها لـ Revive، وهي أيضًا أفضل مكان لتشغيل العقود الذكية في Polkadot Hub في المستقبل.

الآن، أود أن أقدم ثلاثة أمثلة توضح ما يمكن أن يحققه Revive وPolkadot Hub.

يجب أن يكون واضحًا الآن: في هذه البيئة الموحدة، يمكن للعقود الذكية:

• الوصول المباشر إلى الحوكمة والتخزين 
• الوصول المباشر إلى الرصيد الأصلي والأصول الأخرى 
• جميع العمليات يمكن تنفيذها بشكل متزامن، دون الحاجة إلى اتصالات غير متزامنة بين السلاسل 

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

مثال آخر: PVM يتيح أعباء عمل أكثر تعقيدًا. كما ذكرت سابقًا، سيطلق وضع الترجمة الفورية JIT في PVM العام القادم، وعندها سيتم إطلاق الأداء الكامل.

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

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

ذكرت سابقًا التشفير. الآن، يمكنك تنفيذ خوارزميات التشفير المعقدة مباشرة داخل العقد الذكي — هذه الخوارزميات تتطلب قدرة حسابية عالية، وPVM مناسبة تمامًا لهذا النوع من العمل. في مجال التشفير، هناك اتجاه مهم جدًا وهو تطبيقات المعرفة الصفرية. إثباتات المعرفة الصفرية شائعة جدًا حاليًا، لكن بسبب متطلبات الحساب الكبيرة، لم يكن بالإمكان تنفيذها فعليًا داخل العقود الذكية. مع ظهور PVM، أصبح من الممكن أخيرًا تنفيذ تطبيقات المعرفة الصفرية داخل العقود الذكية.

بعد ذلك، أود الحديث عن استراتيجية منتجات Parity.

كما سمعتم، سنبني العديد من المنتجات الجديدة، وسيكون Revive وPolkadot Hub الأساس لهذه المنتجات. بالطبع، هناك طبقات أساسية أخرى، لكن طالما أن الأمر يتعلق بمحرك تنفيذ العقود الذكية، فسيعمل على Revive وPolkadot Hub.

من الناحية الهيكلية، يمكن فهمها كالتالي:

• الطبقة الخارجية هي Polkadot Hub، ويعمل Revive داخل Hub؛
• يمكنك اختيار EVM أو PVM لبناء التطبيق حسب احتياجات المشروع؛
• وفوق ذلك، هناك جميع المنتجات الموجهة للمستخدم النهائي.

Polkadot Hub سيبدأ رسميًا في ديسمبر

أخيرًا، أود أن أقدم لمحة سريعة عن المستقبل.

إذا كنت ترغب في البدء في البناء على Revive وPolkadot Hub، يمكنك البدء بالطرق التالية.

إذا كنت تفضل الاستمرار في استخدام طريقة التطوير التي اعتدت عليها — مثل إذا كان لديك سير عمل ناضج بالفعل، أو كنت تستخدم أدوات Ethereum مثل Foundry أو Hardhat — يمكنك اختيار EVM مباشرة، فالمحرك جاهز للاستخدام.

بالطبع، يمكنك أيضًا اختيار PVM. لقد وفرنا أدوات مماثلة لـ Foundry وHardhat لـ PVM، لكنها ليست الإصدارات القياسية، لأنها لا تدعم PVM ولا تحتوي على مترجم PVM. لكننا نوفر إصدارات متوافقة، وطريقة استخدامها متشابهة جدًا.

بالإضافة إلى ذلك، يمكنك التفاعل مع الوظائف الأساسية الأخرى في Polkadot Hub من خلال precompiles.

بالنسبة لموعد الإطلاق، سيتم نشر Polkadot Hub وجميع المكونات ذات الصلة في نوفمبر على Kusama، وسيأتي ذلك قريبًا جدًا. أما الشبكة الرئيسية لـ Polkadot فسيتم إطلاقها رسميًا في ديسمبر.

كما ذكرت سابقًا، تم الانتهاء من جميع الأعمال الأساسية لـ Revive.

سيتم فتح المزيد من الميزات المتقدمة تدريجيًا العام المقبل، وأود أن أؤكد بشكل خاص على محرك JIT الخاص بـ PVM.

نحن نستكشف أيضًا تقنيات أكثر تقدمًا، مثل دعم لغات عقود ذكية جديدة في المستقبل، لن أتوسع في ذلك الآن، لكن يمكنكم متابعة المستجدات.

إذا كنت ترغب في التطوير على Polkadot Hub وRevive، يمكنك مسح رمز الاستجابة السريعة هذا.

مرحبًا بك لتكون جزءًا من مستقبل Parity وPolkadot! شكرًا جزيلًا لكم جميعًا!