هل سيتم تسليم JAM خلال 12-20 شهرًا؟ ثلاثة مطورين أساسيين يكشفون عن نموذج الاقتصاد M1 و PoP ومستقبل ZK!

JAM، هذا الاسم الذي تمت مناقشته لفترة طويلة داخل مجتمع Polkadot. ومع إعلان Gavin Wood عن سلسلة من المعلومات الهامة في Web3 Summit، وصلت توقعات وأسئلة الجميع حول JAM إلى ذروتها — ما هو JAM بالضبط؟ ما التغييرات التي سيجلبها إلى Polkadot؟ كم تبقى حتى إطلاقه الرسمي؟

ولمساعدة المجتمع على فهم أعمق، دعت PolkaWorld ثلاثة ضيوف يشاركون مباشرة في تطوير JAM الأساسي — Bryan من فريق Acala، Junha مطور تنفيذ JAM بلغة Rust تحت اسم "FastRoll"، وBoy Maas مطور تنفيذ JAM بلغة Zig تحت اسم "JAMZig" والمؤسس المشارك لمشروع Polona.

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

في هذه المقابلة، سيأخذوننا من منظورهم الأول إلى عالم JAM:

• ما الذي تعنيه التحديثات الكبرى التي أعلنها Gavin حول JAM؟
• كيف سيغير الحد الأقصى لرموز JAM (π × 1,000,000,000) وآلية PoP (Proof of Personhood) النموذج الاقتصادي لـ Polkadot؟
• ما هي أهداف وتقدم milestone 1 التقنية؟ ومتى سيتم إطلاق شبكة الاختبار؟
• كيف سيتكامل ZK (Zero-Knowledge Proof) مع JAM في المستقبل؟
• كيف ستؤثر آلية الحوكمة في JAM ولجنة تحرير Gray Paper على تطور البروتوكول على المدى الطويل؟

إذا كنت ترغب في معرفة مستقبل JAM وكيف سيعيد تشكيل بنية Polkadot التحتية — لا تفوت هذه الحلقة.

تعرف على فرق تطوير JAM الثلاثة

Kristen: مرحباً جميعاً، أنا Kristen، واليوم لدينا ثلاثة من المطورين الأساسيين في JAM، وهم يشاركون مباشرة في تطوير JAM. إذا كنت تتابع PolkaWorld أو أحدث أخبار Polkadot، فربما تعلم أن Web3 Summit يُعقد حالياً، وقد أعلن Gavin في المؤتمر عن بعض الأخبار الهامة حول JAM. بدأ المجتمع بالفعل في إرسال العديد من الأسئلة إلينا، لذا نظمنا هذه الجلسة المباشرة بشكل عاجل، ونأمل من خلال مشاركة الضيوف الثلاثة أن نساعد المجتمع على فهم شامل لما أعلنه Gavin حول JAM في Web3 Summit.

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

Junha: شكراً لدعوتك Kristen. مرحباً جميعاً، أنا Junha، وهذه أول مرة أشارك في هذا البرنامج.

حالياً أعمل على تنفيذ بروتوكول JAM بلغة Rust، واسم المشروع هو "FastRoll". حالياً أنا المطور الوحيد في فريقي، ويمكن اعتباري مطوراً مستقلاً.

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

Kristen: مرحباً بك Junha! الآن ننتقل إلى Bryan ليقدم نفسه.

Bryan: مرحباً جميعاً، أنا Bryan من فريق Acala. حالياً أقود فريقاً صغيراً لتطوير نسخة أخرى من تنفيذ بروتوكول JAM، واسم المشروع هو "Boka".

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

Kristen: شكراً لك Bryan على عودتك إلى برنامجنا، في الواقع كنت أول ضيف لدينا لتقديم مشروع JAM، سعيد بعودتك. وأخيراً نرحب بـ Boy Maas، وقد أجرينا مقابلة خاصة معك سابقاً.

Boy Maas: نعم، نعم، مرحباً جميعاً، أنا Boy Maas. أنا مطور مستقل لتنفيذ بروتوكول JAM بلغة Zig، وعميلنا يُسمى "JAMZig".

وفي الوقت نفسه، أنا المؤسس المشارك لمشروع في نظام JAM البيئي، هدفنا هو نقل أدوات Solana وسلسلة Solana الافتراضية (SVM) بالكامل إلى JAM. لقد أكملنا بالفعل مرحلة إثبات المفهوم الأولية، أي أننا تمكنا من تشغيل بعض الوظائف الأساسية.

هل سيتم تسليم JAM رسمياً خلال 12 إلى 20 شهراً؟

Kristen: مرحباً بك Boy Maas، Polona هو بالفعل مشروع رائد يهدف إلى جذب مطوري Solana إلى نظام Polkadot البيئي، فكرة رائعة! حسناً، نرحب بضيوفنا الثلاثة.

الموضوع الأول الذي أود مناقشته هو مع Boy Maas، لقد شاركت في Web3 Summit، وقد رأينا العديد من الأخبار حول خطاب Gavin على تويتر، لكن أود أن تشاركنا تجربتك من منظورك الأول، هل شاهدت خطاب Gavin؟ هل يمكنك مشاركة أهم المعلومات التي لفتت انتباهك؟

Boy Maas: بالطبع، كان من الرائع حقاً أن أكون هناك. يمكنك مقابلة العديد من أعضاء مجتمع Polkadot، وهناك العديد من المشاركات المثيرة للاهتمام التي تجعلك تشعر حقاً بديناميكية المجتمع، الجو كله إيجابي ومليء بالحيوية، ويجعلك متحمساً للمستقبل. اليوم هو اليوم الأخير، وأنا متحمس لنقل هذه التجربة إلى تطويرنا المستمر.

Kristen: هل شاهدت خطاب Gavin؟

Boy Maas: نعم، شاهدته.

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

Boy Maas: بالطبع. تحدث Gavin عن العديد من الأمور في خطابه. إنه شخص ذو رؤية بعيدة وخبرة كبيرة، لذا فإن بعض قراراته وأفكاره الجديدة تؤثر بشكل كبير على اتجاه المجتمع المستقبلي.

أهم نقطة هي أنه أعلن أن إجمالي عرض رموز JAM سيكون له حد أقصى ثابت "π مضروباً في 1,000,000,000" (π × 1,000,000,000)، وهذا أمر مهم للغاية وسيكون له العديد من التأثيرات اللاحقة.

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

كمطورين، نحن نفهم التفاصيل التقنية لـ JAM، لكنني أفهم أيضاً أن معظم الناس لا يزالون في مرحلة "غير متأكدين من التغييرات التي سيجلبها JAM". الجميع يحاول رسم صورة لعالم المستقبل الذي يقوده JAM.

Kristen: يبدو الأمر مثيراً جداً للاهتمام. لاحظت أيضاً أن Gavin ذكر أن JAM سيتم تسليمه رسمياً خلال 12 إلى 20 شهراً، ويبدو أن مشروعكم Polona يعتمد أيضاً على هذا الجدول الزمني؟ هل سيتزامن تقدم تطويركم مع جدول JAM؟

Boy Maas: نعم، Kristen، أنت على حق تماماً. لم نكن نستعد بشكل خاص لنكون جاهزين عند إطلاق شبكة الاختبار، لكن وفقاً للجدول الزمني الحالي، وجدنا أن خطتنا تتوافق تماماً، وبمجرد إطلاق شبكة اختبار JAM، سنكون قادرين على استخدامها فوراً. وعندما يبدأ تشغيل الشبكة رسمياً، سنكون من أوائل المستخدمين.

ما هو M1 في JAM؟

Kristen: جيد، سعيد بسماع هذا التقدم. الآن أود أن أوجه السؤال إلى Junha.

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

Junha: بالطبع. كما ذكرت، تم تحديث "Gray Paper" الخاص بـ JAM مؤخراً إلى الإصدار 0.7.0. وذكر Gavin في خطابه أنه من هذا الإصدار، يمكن لـ Polkadot Fellowship البدء في تقييم milestone 1. لذا فإن معظم الفرق التي تعمل على تنفيذ عميل عقدة JAM تستعد لهذا التقييم.

هدف milestone 1 هو تسليم عميل عقدة يمكنه "استيراد الكتل بشكل صحيح"، أي التحقق من منطق التشغيل الأساسي لـ JAM.

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

تقييم milestone 1 هو التحقق مما إذا كان تنفيذ العقدة يمكنه، بعد استيراد هذه الكتل، إنتاج الحالة اللاحقة الصحيحة.

طريقة التقييم مباشرة أيضاً: نعد مجموعة من كتل الاختبار، ثم نقارن الحالة اللاحقة التي تنتجها كل تنفيذ. يمكن تلخيص نتيجة الحالة هذه بجذر عمودي (vertical root)، لذا فإن المقارنة سهلة جداً. هناك بالفعل أداة اختبار تُسمى JAM Conformance Fuzzer، يمكنها توليد العديد من الكتل العشوائية واستخدامها لاختبار ما إذا كانت جميع التنفيذات تنتج نفس جذر الحالة.

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

Kristen: فهمت، متى تتوقع إطلاق شبكة الاختبار؟

Junha: هل تقصد شبكة اختبار JAM؟ بعض الفرق حاولت بالفعل التفاعل بين التنفيذات المختلفة باستخدام ملفات ثنائية مجمعة ذاتياً، لكنني أعتقد شخصياً أن شبكة اختبار قابلة للتشغيل حقاً ستكون أكثر نضجاً بعد milestone 2.

لأن milestone 1 يركز بشكل رئيسي على التحقق من منطق تحويل الحالة للعقدة، وهذا غير كافٍ لدعم تشغيل شبكة اختبار كاملة. بينما milestone 2 سيبدأ في تقييم ما إذا كانت كل تنفيذ قد أكملت تنفيذ بروتوكول الاتصال الشبكي (networking spec). لكن هذه المواصفات لا تزال غير مستقرة، ولم تُكتب بعد في Gray Paper. بمجرد استقرار مواصفات بروتوكول الشبكة، وإكمال التنفيذات التطوير المناسب، يمكن اختبار التفاعل بين العقد.

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

Kristen: جيد. هل تعتقد أن المحتوى الجديد الذي أعلنه Gavin في القمة سيؤثر على تقدم تطويرك؟

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

بالطبع، على مدى فترة أطول من سنة إلى ثلاث سنوات، قد يكون لهذه الاتجاهات الجديدة تأثير، لكن في الوقت الحالي، سأركز على إكمال milestone 1 بشكل جيد.

ماذا سيحدث إذا استبدلت PoP بـ NPoS؟

Kristen: فهمت، شكراً لمشاركتك! الآن أود أن أطرح سؤالاً "تقنياً" على Bryan، يتعلق بالاقتصاد الرمزي. نعلم جميعاً أن المطورين عادة لا يحبون تقييم فعالية النماذج الاقتصادية، لكن هذا من أكثر الأمور التي يهتم بها المجتمع. ذكر Gavin في القمة أنه سيتم استبدال NPoS بـ PoP (Proof of Personhood)، وستصبح مكافآت المدققين ثابتة، مع إدخال آلية تقليل سنوية للحد من إجمالي عرض DOT. كمطور، ما رأيك في هذه التغييرات؟ ما هو التأثير الأكبر برأيك؟ هل تدعم ذلك شخصياً؟ هل لديك مخاوف أو اقتراحات؟

Bryan: بالفعل، هذا تغيير كبير.

دعني أراجع الخلفية بإيجاز: سواء كان إثبات العمل (PoW)، أو إثبات الحصة (PoS)، أو الآن إثبات الشخصية (Proof of Personhood، PoP)، فهذه الآليات تهدف في جوهرها إلى حماية أمان الشبكة ومنع هجمات الإنفاق المزدوج أو انقسام السلسلة.

كل آلية لها تكلفتها التشغيلية، مثل تكلفة PoW التي تظهر في مكافآت الكتل، وتتطلب الكثير من الطاقة وقوة الحوسبة، بينما PoS يتطلب مكافآت للمشاركين في الستيكينغ.

آلية إثبات الشخصية الجديدة هذه تختلف كثيراً في نظام المكافآت. كان Polkadot يستخدم NPoS (إثبات الحصة بالترشيح)، وعلى الرغم من أنه ليس مكلفاً مثل PoW، إلا أنه لا يزال هناك مشكلة: للحفاظ على أمان الشبكة، يجب إصدار رموز جديدة باستمرار لمكافأة المدققين والمرشحين، مما يؤدي إلى التضخم.

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

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

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

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

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

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

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

ما هو zkJAM؟

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

الآن ننتقل إلى موضوع تقني — ZKJAM. رأيت هذا المصطلح في عرض Gavin التقديمي، ويبدو أنه لا يزال مفهوماً إلى حد ما. لكن "الإثباتات عديمة المعرفة" (ZK) أصبحت شائعة جداً في مجال Web3 في السنوات الأخيرة، ويقول الكثيرون إن ZK هو الحل النهائي لـ Rollups وقابلية التوسع. إذا تم دمج ZK مع JAM في المستقبل، كيف سيكون السيناريو؟ أود أن أسمع آراءكم الثلاثة. Junha، ابدأ أنت.

Junha: حسناً. شبه Gavin في خطابه JAM بأنه "حاسوب عاري لامركزي فائق"، والخدمات المختلفة التي تعمل عليه تشبه أنظمة التشغيل مثل Windows أو macOS التي تعمل على الأجهزة.

إذا تم دمج ZK في JAM في المستقبل، فمن منظور مطوري الخدمات أو التطبيقات، لن يكون هناك تغيير "ثوري" كبير، ويجب أن تظل تجربة التطوير وتجربة المستخدم كما هي تقريباً.

حتى إذا تم ترقية آلية أمان JAM من "نموذج إعادة التنفيذ القائم على التدقيق" الحالي إلى "نموذج قائم على إثباتات ZK"، طالما أن هذه الترقية تم التحقق منها بدقة وأثبتت فعاليتها، فهي تستحق التبني تماماً.

لذا أعتقد أنه إذا كان من الواضح أن ZK يتوافق جيداً مع JAM، وكان أكثر فائدة من الطريقة الحالية، فإن الترقية ممكنة، ولن تتغير التجربة العامة كثيراً.

Kristen: شكراً لمشاركتك. أعتقد أن بعض المستمعين قد شعروا بالارتباك من المصطلحات التقنية، لكن لا تقلقوا، سيكون هناك مراجعة مكتوبة يمكنكم قراءتها مراراً لفهم المحتوى. الآن ننتقل إلى Bryan لسماع رأيك.

Bryan: أعتقد أن الجميع بحاجة أولاً إلى التمييز بين مفهومين: الأول هو JAM كبنية تحتية تدعم Rollup الآمن بواسطة ZK، والثاني هو JAM نفسه الذي يضمن أمانه بواسطة ZK. هذان أمران مختلفان تماماً.

من خلال PVM في JAM، يمكن نشر أي خوارزمية أو بنية متعلقة بـ ZK، مثل بروتوكولات ZK-Rollup الجديدة، كخدمة على JAM. هذا الجزء سهل التنفيذ نسبياً.

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

لذا، إذا ظهر في المستقبل تكامل ZK مفيد حقاً، يمكنه جعل JAM أكثر أماناً، فأنا بالتأكيد أؤيد استخدامه.

Kristen: فهمت، نأمل أن يشهد هذا المجال اختراقاً حقيقياً. Boy Maas، كمطور مخضرم، ما رأيك في هذا الموضوع؟

Boy Maas: في الواقع، أعتقد أن Bryan وJunha قالا كل شيء تقريباً. أحد أسباب إعجابي بـ JAM هو أنه نظام عملي للغاية. جميع خيارات التصميم فيه تهدف إلى تشغيل النظام فعلياً وتنفيذ العمليات الحسابية. كما قال Bryan، استخدام ZK للقيام بكل ذلك الآن مكلف للغاية وغير واقعي. لذا أتصور أنه في المستقبل قد يتم اعتماد "نموذج هجين"، أي استخدام الطريقة التقليدية للتدقيق وZK معاً.

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

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

JAM ستؤسس لجنة تحرير Gray Paper

Kristen: شكراً لمشاركتكم. الآن ننتقل إلى الموضوع التالي: آلية الحوكمة في JAM.

سيواصل Gavin شغل منصب رئيس تحرير Gray Paper، كما أعلن عن تأسيس "لجنة تحرير Gray Paper"، والتي ستتكون من مساهمين يشاركون بعمق في تطوير JAM ويتمتعون بقدرات تقنية، وستقرر هذه اللجنة مستقبلاً تحديثات بروتوكول JAM والأولويات والقرارات الرئيسية. أود أن أسأل كل واحد منكم كمطورين، هل تعتقدون أن طريقة الحوكمة هذه بواسطة لجنة قابلة للتطبيق؟ هل من الممكن أن تنحرف عن الهدف الأصلي؟ وإذا حدث ذلك، كيف يجب التعامل معه؟ لنبدأ مع Boy Maas.

Boy Maas: أعتقد أن هذا سؤال مهم جداً. بالنسبة لمجال عالي التقنية ومتخصص للغاية كهذا، وجود لجنة مسؤولة عن تحديث Gray Paper أمر منطقي وضروري للغاية. لأن من يتخذ هذه القرارات يجب أن يكون لديه فهم عميق وطويل الأمد لمبادئ JAM الأساسية ليتمكن من اتخاذ قرارات حكيمة. وقيادة Gavin لهذه اللجنة أمر منطقي تماماً، لذا أنا أؤيد تماماً طريقة الحوكمة هذه.

Kristen: إذن تعتقد أن اتخاذ القرارات من قبل فريق محترف هو أمر جيد؟

Boy Maas: نعم، أوافق تماماً.

Kristen: جيد، Bryan، ما رأيك في هذا الموضوع؟

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

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

محتوى Gray Paper معقد للغاية، تقريباً جميع مطوري فرق تنفيذ JAM قرأوا نسخاً مختلفة عدة مرات. لكن بصراحة، ربما لا أحد يفهمها بنسبة 100% سوى Gavin، وربما حتى Gavin نفسه لا يمكنه الإلمام بكل التفاصيل. هناك العديد من الأشخاص يشاركون في تعديل الوثيقة، مثل تصحيح الأخطاء الإملائية، وتعديل الصيغ، وتحسين المنطق، وهذا بحد ذاته عملية تعاونية.

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

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

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

Kristen: فهمت، أذكر أن مجتمع Bitcoin لديه لجنة مطورين مماثلة لدفع التطوير.

Bryan: نعم، لدى مجتمع Bitcoin مجموعة من المطورين الأساسيين، لكن القرار النهائي يتم عبر الانقسام (fork)، والسلسلة التي تحصل على أكبر قوة حوسبة هي التي تفوز.

Kristen: فهمت، شكراً لتوضيحك. وأخيراً، دعونا نستمع إلى رأي Junha في هذا الموضوع.

Junha: أعتقد أن تأسيس لجنة تحرير هو خطوة طبيعية وذات مغزى كبير. مشروع JAM نفسه فريد للغاية: قبل تطوير برنامج كامل قابل للتشغيل، تم إصدار وثيقة مواصفات تقنية كاملة (Gray Paper). تحتوي هذه الوثيقة على العديد من الصيغ الرياضية لتحديد سلوك النظام من حيث المدخلات والمخرجات. إصدار الوثيقة قبل التطوير يهدف في الواقع إلى تحقيق مزيد من اللامركزية وقوة النظام.

لهذا السبب، تم تعديل Gray Paper عدة مرات منذ صدورها، ومن المرجح أن تستمر التعديلات حتى بعد إصدار النسخة 1.0.

مع بدء المزيد من الفرق في تنفيذ بروتوكول JAM وبناء شبكات اختبار، سنكتشف بالتأكيد أن بعض الأجزاء يمكن تحسينها أكثر، لجعل البروتوكول أكثر كفاءة أو قابلية للتنفيذ. لذا، بطبيعة مشروع JAM، من الطبيعي أن تستمر Gray Paper في التطور حتى بعد إطلاق الشبكة الرئيسية، وربما يحدث انقسام صلب (hard fork).

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

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

قد نكون نقلل من شأن ما سيجلبه JAM للبلوكشين

Kristen: جيد، إنها بالفعل بداية جيدة. إذا كان كل شيء شفافاً، فسيكون ذلك رائعاً. شكراً لمشاركتكم، أعتقد أننا انتهينا من جميع المواضيع التي أعددناها اليوم.

قبل الختام، هل لديكم أي إضافات؟ حول JAM، أو حول مؤتمر Web3، هل هناك شيء لم تتح لكم الفرصة لذكره؟ لنبدأ مع Bryan.

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

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

Kristen: شكراً لك. Boy Maas، هل لديك أي إضافات حول Polona أو JAM؟

Boy Maas: بالطبع. أولاً، أود الحديث عن JAM. أذكر أنه في لشبونة، قدم Gavin عرضاً عن JAM. في ذلك الوقت، شعرت بشدة أننا قد نقلل من شأن ما سيجلبه هذا النظام الأساسي لمجتمع البلوكشين.

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

وأضيف خبراً آخر، مشروعنا Polona يتقدم بسرعة كبيرة، وقد شغلنا بالفعل نسخة إثبات مفهوم (PoC) على JAM. لقد نقلنا SVM الخاص بـ Solana إلى PVM، أي أنه يمكنك الآن تشغيل bytecode الخاص بـ Solana مباشرة على JAM، بما في ذلك وظائف الاستدعاء بين العقود، وكل شيء يعمل، وهذا رائع حقاً. وهذا يوضح قوة خدمات JAM.

Kristen: رائع، شكراً لك! وأخيراً، دعونا نستمع إلى Junha.

Junha: آمل أن يبدأ المزيد من الناس في الاهتمام بـ JAM وPolkadot وGray Paper. أود حقاً التواصل مع المزيد من الأشخاص ومشاركة بعض الأفكار.

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

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

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