فعّلت شبكة Pi بروتوكولها 24.1 في مايو، مع طلب من جميع مشغّلي العقد إنهاء عملية الانتقال من v23.0 إلى v24.1 قبل الموعد النهائي في 2 يونيو. وقد يؤدي تفويت الموعد النهائي إلى فصل العقد عن شبكة Pi mainnet، كما سيتطلب الأمر مزامنة كاملة من جديد للعودة إلى الشبكة.
إرشادات تشغيلية لترقية v24.1: ثلاث طرق مؤكدة
الطريقة الأولى (الطريقة الرئيسية): لمستخدمي Docker، قم بتحديث إصدار الصورة في ملف docker-compose.yml إلى: pinetwork/pi-node-docker:organization_mainnet-v1.0-p24.1.0 ثم تشغيل docker-compose up -d
الطريقة الثانية: أعد تشغيل تطبيق Pi Node على Pi Desktop (Windows / macOS)؛ إذ سيؤدي أحدث إصدار تلقائيًا إلى تشغيل الترقية.
الطريقة الثالثة: على Linux Node CLI، نفّذ pi-node update-protocol، واستخدم watch pi-node status لمراقبة الحالة، واعتبر العملية مكتملة عندما يظهر "تمت المزامنة".
الطريقة الوحيدة الموثوقة للتأكد من اكتمال الانتقال: قارن قيمة ingest_latest_ledger داخل العقد (القيمة في curl). عندما تكون القيمتان متقاربَتين جدًا، فهذا يعني أن الانتقال قد اكتمل. تنبيه مهم: خلال عملية الانتقال، لن تتغير هذه القيمة تدريجيًا؛ بل سيتم تحديثها مرة واحدة فقط عند نهاية عملية الانتقال، وتظل القيمة ثابتة أثناء فترة الانتقال؛ ولا يعني ثباتها خلال المدة أن الانتقال فشل.
قواعد تشغيلية محورية مؤكدة: أربع نقاط
（المصدر: Pi Network）
الترقية على دفعات: لا تُرقِّ كل العقد في وقت واحد، بل نفّذ على مراحل. وأثناء الترقية، انقل حركة المرور إلى العقد الأخرى أو إلى عقد احتياطية.
لا تبدأ من تلقاء نفسك v25.1 أو v26.0: تم وضع هذين الإصدارين ضمن وسم "يرجى عدم التشغيل"، ويجب الانتظار حتى تصدر إشارة تشغيل رسمية من فريق Pi الأساسي.
2 يونيو هو الموعد النهائي الصارم: ألا تتجاوز مدة الانتقال 5 دقائق. ويقترح فريق Pi الأساسي إنهاء العملية في وقت مبكر بدلًا من انتظار اللحظة الأخيرة.
يجب تأكيد الإكمال عبر جانب دفتر الأستاذ: لا تفترض اكتمال الانتقال بمجرد إعادة تشغيل العقد؛ بل يجب عليك تأكيد ذلك عبر مقارنة ingest_latest_ledger.
الأسئلة الشائعة
ما منطق تصميم تسلسل ترقية Pi Network من v19 إلى v26، ولماذا تُعد كل خطوة إجبارية؟
تسلسل الترقية في Pi Network هو تصميم يعتمد على التبعية الخطية: فكل إصدار جديد تُبنى ميزاته على أساس الإصدار السابق، ولا يمكن تخطي أي خطوة. يضمن هذا التصميم بقاء الشبكة على توافق إصدار البروتوكول في أي لحظة، ويمنع العقد من عدم القدرة على التواصل بكفاءة بسبب اختلاف الإصدارات. كلما زاد عدد العقد التي تعمل بإصدار قديم داخل الشبكة، كلما تأخر النشر الكامل لميزات الإصدار الجديد على مستوى الشبكة. لذلك تهدف المواعيد النهائية الإلزامية إلى ضمان انتقال سريع للشبكة إلى الإصدار التالي. يُعد v23.0 أكثر خطوة تعقيدًا في هذا التسلسل، إذ تم فيه في الوقت ذاته ترقية نظام التشغيل وقاعدة البيانات؛ بينما يُقدّم v24.1 على هذا الأساس، عبر دمج الإصدارات الجديدة من Stellar-Core وHorizon.
بعد ترقية بروتوكول Pi mainnet إلى v24.1، هل سيتم تفعيل العقود الذكية وميزات dApp؟
لا. أكّد فريق Pi الأساسي بشكل واضح أن تفعيل العقود الذكية وتطبيقات اللامركزية (dApp) على شبكة Pi mainnet لم يتم الإعلان عنه رسميًا بعد. يقوم البروتوكول 23.0 بمحاذاة Pi مع Stellar Core v23، والذي يوفّر من الناحية التقنية إطارًا أساسياً لهذه الميزات. ويواصل v24.1 هذا المسار عبر دمج Stellar-Core v24.1.0، لكن تفعيل العقود الذكية و dApp هو قرار رسمي منفصل يحتاجه فريق Pi الأساسي، وهو حدث مستقل عن ترقية نسخة البروتوكول. يركز تسلسل الترقية الحالي أساسًا على استقرار البنية التحتية وتحسين الأداء.
إذا واجه مشغّلو العقد مشكلة خلال ترقية v23.0، فهل ستكون صعوبة انتقال v24.1 بنفس المستوى؟
وفقًا لتأكيد فريق Pi الأساسي، تُعد v24.1 عملية انتقال قياسية لبيانات داخلية، مع وجود اختلاف جوهري عن v23.0: يتطلب v23.0 إجراء ترقية نظام التشغيل (Ubuntu 20→24) وترقية قاعدة البيانات (PostgreSQL 12→16) وانتقال البروتوكول في آن واحد. كما أن العملية تتضمن إعادة كتابة ملفات قاعدة البيانات، ما يستدعي اتخاذ تدابير احتياطية للنسخ الاحتياطي مسبقًا، وبالتالي يستغرق وقت تشغيل أطول. أما v24.1 فهي انتقال لبيانات داخلية فقط، دون إعادة كتابة ملفات قاعدة البيانات، ولا تتطلب خطوات نسخ احتياطي خاصة. وفي معظم الحالات، لا تتجاوز مدة الانتقال 5 دقائق، كما أن سرعة إعادة التشغيل أسرع بكثير من v23.0. تعود صعوبة ترقية v23.0 أساسًا إلى تعقيد ترقية المزامنة متعددة الطبقات، بينما لا يوجد لدى v24.1 التعقيد نفسه.
