أول قرار لـ Gavin بعد عودته: Parity لن تكتفي ببناء البنية التحتية، بل ستبدأ في تطوير المنتجات!

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

يمكن تشغيل DeFi، لكن باقي سيناريوهات Web3 تكاد تكون متوقفة. لم يستخدم المطورون الخارجيون Polkadot لبناء التطبيقات كما كان متوقعاً، وواجه توسع النظام البيئي عنق زجاجة.

لذا عندما عاد Gavin لقيادة Parity، أصبح أمر واحد واضحاً بشكل غير مسبوق — إذا لم يقم أحد ببناء تطبيقات Web3، فعلى Parity أن تبدأ بنفسها.

هذا ليس مجرد "صنع بعض النماذج التجريبية". بل هو تحول استراتيجي — من "Parity مسؤولة عن البنية التحتية والتطبيقات يبنيها النظام البيئي" إلى "Parity تصنع أولاً نماذج تطبيقات قادرة فعلاً على استبدال Web2 وتثبت قيمة تقنية Polkadot بنفسها".

في هذه المقابلة المطولة من سلسلة "Space Monkeys"، يشرح نائب الرئيس للهندسة Pierre لأول مرة بشكل منهجي:

• لماذا فشل نموذج البناء الخارجي 
• لماذا يجب إعادة تطوير المنتجات 
• لماذا يجب أن يبدأ Polkadot Hub بـ EVM قبل PVM 
• لماذا يدفع Gavin نحو "تكرار كل أسبوعين" 
• لماذا تعيد Polkadot بناء طبقة التطبيقات الكاملة للحوسبة والتخزين والإشعارات والهوية بشكل لامركزي 

سترى بوضوح أن Parity تبني "طبقة بديلة لـ AWS + Web2 بشكل لامركزي". هذا سيحدد ما إذا كانت Polkadot ستعود للصدارة في العصر الثاني.

لماذا قررت Parity "بناء التطبيقات بنفسها"؟

Jay: مرحباً بكم في الحلقة الأحدث من برنامج "Space Monkeys"! ضيفنا اليوم هو نائب رئيس الهندسة في Parity، Pierre Aubert. نحن محظوظون جداً باستضافته مجدداً، فقد مر وقت منذ زيارته الأخيرة، وكان حينها قد انضم حديثاً إلى Parity. اليوم سنتحدث عن ما تعلمه خلال هذه الفترة، والتغيرات التي لاحظها، والاتجاهات المستقبلية. مرحباً بعودتك، Pierre!

Pierre: شكراً، مرحباً بالجميع!

Jay: لقد عملت سابقاً في Google، وكنت تفكر حينها في شكل أنظمة Web3 ودورك فيها. ما الذي تعلمته الآن؟

Pierre: الآن لدي فهم أوضح لكيفية عمل النظام ككل، ولدي بعض الأفكار الجيدة حول ما يمكننا فعله. إمكانيات هذا النظام هائلة، وهناك الكثير مما يمكن تحقيقه، لكن التنفيذ ليس سهلاً.

الوضع الحالي لـ Web3 هو أن التقدم بطيء في جميع المجالات باستثناء DeFi (التمويل اللامركزي). مؤخراً عاد Gav لقيادة الشركة وقرر أن تركز الشركة أكثر على تطوير المنتجات، وأعتقد أن هذا هو الاتجاه الصحيح تماماً.

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

لذا، الخطوة الأولى هي أن نبني هذه التطبيقات بأنفسنا ونستخدمها بأنفسنا، أي ما يسمى "dogfooding" (اختبار المنتج داخلياً). العديد من التطبيقات الأولية ستركز على الأدوات التي نستخدمها يومياً، والهدف هو استبدالها بأنظمة لامركزية. عندما تصبح هذه التطبيقات ناضجة بما فيه الكفاية داخلياً، سنطرحها للمستخدمين. على سبيل المثال، في قمة Web3، لم نستخدم تقنيتنا الخاصة: تم شراء التذاكر عبر شركات Web2 التقليدية، والدفع كان باليورو؛ ونظام الدخول كان أيضاً بنية Web2. هذا في الواقع سيناريو يمكننا الدخول فيه، ويمكننا تماماً استخدام تقنيتنا لبناء نظام أكثر أماناً وانفتاحاً.

Jay: هذه الأنظمة الحالية فعالة ومستقرة جداً. ما الفائدة من تحويلها إلى أنظمة Web3؟

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

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

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

كيف تعزز Parity كفاءة العمل؟

Jay: خلال العامين الماضيين، استثمرتم الكثير في بناء أنظمة لامركزية. منذ أن أصبحت نائب رئيس الهندسة، ما هي الجوانب التي برعت فيها Parity؟

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

Jay: بالنسبة لأي شخص يقود فريقاً، حتى لو كان فريقاً صغيراً، هل لديك نصائح عملية، مثل كيفية تقييم الموظفين أو اتخاذ قرارات الترقية أو التفويض؟ ما الصفات التي تركز عليها في نمو الموظفين؟

Pierre: نحن نركز أكثر على النتائج، وليس العملية. مثلاً، هناك من يعمل بجد ويجعل الجميع يعرف كم هو مجتهد، لكن في النهاية لا يحقق نتائج. وعلى العكس، هناك من يعمل بذكاء، ربما يقضي عشرين ساعة فقط في الأسبوع، لكنه ينجز الأمور ويحقق تأثيراً حقيقياً. هذا هو الأهم. ببساطة: العمل بذكاء أهم من العمل بجد.

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

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

لذا، جعل الأهداف واضحة ومحددة هو الأهم. وهناك نقطة أخرى مهمة، أحياناً يواجه أعضاء الفريق مشكلة ولا يعرفون من يجب أن يتواصلوا معه لحلها. سابقاً لم تكن Parity جيدة في هذا الجانب، لكننا حسنّا ذلك الآن: أصبح من الواضح من المسؤول عن كل شيء. في النهاية، يجب أن يكون الشخص المسؤول قادراً على اتخاذ القرار: "هل نذهب يساراً أم يميناً؟" بمجرد أن يصبح هذا واضحاً، يمكن للفريق التقدم بسلاسة.

Jay: صحيح، هذا أمر اختبرته بنفسي. كان هناك دائماً من يتهرب من المسؤولية: "هذا القرار يجب أن يتخذه شخص آخر، يجب أن أنتظر حتى يقرروا لأتمكن من المتابعة." هكذا يتوقف العمل.

Pierre: نعم، تحديد المسؤولية هو المفتاح. وليس بالأمر المعقد، غالباً يكفي كتابة الأمور وتوضيحها. وهناك ظاهرة غير جيدة، وهي أن البعض ينسب النجاح لنفسه، لكن عند الفشل يلوم الآخرين. هذا غير مقبول. لا يمكنك أن تأخذ الفضل في النجاح وتلقي اللوم على الآخرين عند الفشل.

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

استراتيجية Polkadot Hub: EVM أولاً ثم PVM

Jay: دعنا نتحدث عن مشروع Polkadot Hub. هل يعتبر هذا المشروع ناجحاً أم فاشلاً؟

Pierre: أقول نعم ولا. من حيث جودة المنتج، هو مشروع ناجح، والنتيجة النهائية جيدة.

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

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

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

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

Jay: فهمت. هل شاركت في تنفيذ مشروع Hub؟ سمعت أنكم تحاولون جذب مشاريع أخرى للانتقال إليه.

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

Jay: هدفنا من بناء هذا النظام البيئي هو تسهيل نشر المشاريع التي تعرف EVM أو عقود Solidity الذكية. ما هي المشاريع التي ستنضم في المرحلة الأولى؟ كيف ستكون عملية النشر؟ هل ستكون مباشرة على EVM أم ستنتقل إلى PVM؟

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

Jay: تقصد بروتوكولات DeFi "الزرقاء" المنتشرة في جميع الشبكات الرئيسية.

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

Jay: مثل ماذا تحديداً؟

Pierre: يمكنك حساب ZK-SNARK في الوقت الفعلي على السلسلة. في الواقع، يمكنك تنفيذ الكثير من الأمور على PVM لا يمكن تنفيذها على EVM. أعتقد أن هذا جيد للنظام البيئي للعملات المشفرة، فكلما وضعنا المزيد من الأمور على السلسلة، قللنا من الاعتماد على الحلول الخارجية الغريبة أو على أوراكل الطرف الثالث.

بشكل عام، وضع المزيد من المنطق على السلسلة له فوائد أكثر من الأضرار. إذا تعلم عالم التشفير من Web2، سيستمر الناس في استهلاك كل موارد CPU؛ وكلما أعطيتهم موارد حسابية أكثر، سيجدون طريقة لاستخدامها.

الآن لدينا نظام الحوسبة Polkadot، ونبني نظام التخزين ونظام الإشعارات

Jay: حسناً. بالحديث عن التحول نحو المنتجات، ذكر Gavin في اجتماع داخلي لـ Parity أن هدفه هو دورة تطوير منتجات كل أسبوعين، ويريد إنتاج العديد من المنتجات بسرعة. هل ستستخدم هذه المنتجات PVM وHub؟ أم ستنشر على تقنيات أخرى؟

Pierre: يعتمد ذلك على المنتج، لكن معظم المنتجات ستستخدم نوعاً من العقود الذكية.

Jay: أوه، حسناً. إذن معظم المنتجات قد لا تبدأ بحل rollup + parachain؟

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

Jay: كيف يتقدم مشروع التخزين؟ أشعر أننا جربنا عدة حلول تخزين مختلفة، لكن لم نوحدها بعد في حل كامل.

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

Jay: تقصد أشياء مثل DataHaven؟

Pierre: نعم، مثل DataHaven، وأيضاً Eiger (يعملون على بعض البدائيات الأساسية). Parity نفسها تطور تخزيناً مدمجاً على السلسلة؛ وهناك مشاريع مثل JamDA. الآن هناك العديد من الفرق تعمل على مشاريع تخزين لامركزي، ولكل منها ميزاته، وقد نحتاج لأكثر من حل تخزين واحد: نحتاج تخزين لامركزي رخيص (مثل تحميل الصور، يجب ألا يكون مكلفاً)، ونحتاج أيضاً تخزيناً "سريعاً" للقراءة والكتابة المتكررة دون الحاجة لتخزين كميات ضخمة من البيانات.

لذا من المحتمل أن تتعايش عدة حلول تخزين، أو يكون هناك برنامج واحد يمكن تهيئته بأنماط مختلفة. الفكرة الحالية هي استخدام JamDA كحل تخزين مؤقت/قصير الأجل: البيانات مؤقتة، مثلاً تنتهي صلاحيتها بعد 28 يوماً.

(قد يكون هناك خطأ في كتابة JamDA، يرجى التصحيح إذا لزم الأمر)

Jay: إلا إذا قمت بتجديد الفترة بنفسك؟

Pierre: نعم، يمكن التجديد. أو يمكننا بناء نظام لامركزي موزع واسع النطاق فوق JamDA، يسمح لك باختيار الاحتفاظ بالبيانات لفترة طويلة. مثلاً، إذا كتبت ورقة بحثية وتريد حفظها علناً لفترة طويلة، هنا نستخدم التخزين طويل الأجل. لذا قد يكون لدينا نظام من مرحلتين: "مؤقت + طويل الأجل".

Jay: ما الميزات التي لا يوفرها IPFS في هذا النظام؟

Pierre: مثلاً، IPFS لا يضمن توفر البيانات. يمكنك رفع مستند، لكن لا يوجد ضمان أنك ستتمكن من قراءته لاحقاً.

Jay: هل ستستخدم كل هذه الحلول أمان Polkadot في النهاية؟ أي أنها ستعمل ضمن نموذج أمان Polkadot؟

Pierre: في النهاية نعم، لكن في البداية قد لا يكون الأمر كذلك.

Jay: ماذا تعني؟

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

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

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

Jay: صحيح. نحن نقترب أكثر فأكثر من بناء "سحابة" أو "خادم" لامركزي، وكل المكونات تتحسن تدريجياً.

Pierre: صحيح، خطوة بخطوة. سترى أننا نعيد بناء العديد من الخدمات الشائعة في Web2 بشكل لامركزي، بميزات مختلفة، لكنها في جوهرها نفس النوع من الأنظمة. الآن لدينا نظام الحوسبة Polkadot، ونبني نظام التخزين ونظام الإشعارات.

Jay: ذكرت "نظام الإشعارات"، ماذا تقصد تحديداً؟

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

Jay: مثل إنشاء غرفة دردشة خاصة.

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

تابعوا حساب PolkaWorld على WeChat، سنشارك المزيد من مقابلة Pierre في المقالة القادمة!