المصدر: سيليستيا. مترجم: دينغ تونغ، جولدن فاينانس

تم ترقية Lemongrass في سبتمبر وتم نشرها على شبكة الاختبار الرئيسية ، وهي الترقية الأولى لـ Celestia. الترقية المقبلة التي سيتم إطلاقها هي ترقية Ginger ، أي Celestia-App V3 هي الثانية.

جينجر يزيد الكفاءة بمقدار مضاعف، ويزيد فوريًا توافر بيانات Celestia بمقدار 2 مرة! في الإصدار v3، تم تحقيق ذلك عن طريق تقليل وقت الكتلة من 12 ثانية إلى 6 ثوانٍ، مما يحسن تجربة المستخدم من خلال تحديد وقت الاستقرار للفترة الزمنية للمعاملة بشكل أسرع.

وضعت جنجر أساسًا لحوكمة المجتمع ، حيث زادت حجم الكتلة إلى 8 ميجابايت كحد أقصى كل 6 ثوانٍ ، مما يعادل 1.33 ميجابايت/ثانية.

Ginger في ارابيكا بنسبة 2348907 تفعيل (متوقع في 5 نوفمبر 2024). من المتوقع أن تدخل شبكة Mocha في نوفمبر وتدخل الشبكة الرئيسية BETA في ديسمبر.

سيليستيا ستتغير قريبًا

تحتوي ترقية جنزبور على CIP المحدد في CIP-25 (CIP عنصري).

في جنجر، تتضمن CIP ما يلي:

• CIP-21: إدخال نوع blob الموقع من قبل الموقع
• CIP-24: تقسيم متغيرات برنامج توزيع الغاز
• CIP-26: الإصدار الزمني المحدد
• CIP-27: قيود كتلة لكمية PFB وغير PFB
• CIP-28: قيود حجم التداول

بالإضافة إلى CIP المذكور أعلاه، تحتوي celestia-app v3 أيضًا على تغيير هام آخر: يتطلب الإعتماد على BBR بشكل افتراضي.

افتراضيًا كمسجل الصندوق الأسود

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

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

فتحت هذه الأبواب لزيادة كفاءة النقل والأداء في المستقبل ، مثل التحسينات المعروضة في شبكة اختبار Mammoth Mini. يتطلب celestia-app v3 تفعيل BBR بشكل افتراضي.

نوع blob لمقدمي التوقيع الموثقين

CIP-21 قدم "كتلة الإنشاء" حيث يتم تضمين عنوان الموقع مباشرة في بيانات ميتا الخاصة بالتوقيع. يقوم محققو Celestia الآن بالتحقق مما إذا كان الموقع يتطابق مع من قام بدفع الكتلة، مما يعني عدم الحاجة للتجميع لاسترداد ومعالجة تحويلات PayForBlobs بشكل منفصل. يبسط هذا عملية التحقق من التجميع، مما يتيح لهم التحقق مباشرة من حقل موقع التوقيع في الكتلة لضمان صحته.

متغير برنامج توزيع الغاز المنسق

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

إعداد مهلة الإصدار

سيقوم CIP-26 بتعيين وقت الكتلة وإعدادات الانتهاء المتعلقة بالإصدارات التطبيقية، وسيقلل وقت الكتلة من 12 ثانية في v3 إلى 6 ثوانٍ. يهدف هذا التغيير إلى زيادة قدرة الشبكة وتقليل وقت تحديد المعاملات. كما سيزيد من معلم ttl-num-blocks للذاكرة المؤقتة من 5 إلى 12، للحفاظ على سلوك المعاملات الثابت من خلال زمن الكتلة الأسرع.

الحدود الكتلية لكميات PFB وغير PFB

قامت CIP-27 بتحديد عدد رسائل PayForBlob (PFB) ورسائل غير PFB لكل كتلة. تنفذ هذه الاقتراحات قيودًا على 600 رسالة PFB و 200 رسالة غير PFB في كل كتلة. هذه القيود هي قيود ناعمة في مرحلة PrepareProposal ، مما يعني أنها لا تفرض بدقة على مستوى الإجماع. يتم تحقيق هذا التغيير من خلال تقييد عدد المعاملات التي يمكن التحقق منها في كل كتلة لمنع امتداد وقت معالجة الكتلة. يتم تحديد هذه القيود وفقًا للمعيار والهدف هو أن يكون وقت معالجة كل كتلة حوالي 0.25 ثانية في تكوين المحقق الموصى به.

قيود حجم التداول

CIP-28 يحد من حجم المعاملة الفردية إلى 2MiB (2,097,152 بايت) على Celestia. يتم فرض هذا القيد في جميع مراحل معالجة المعاملات (CheckTx وPrepareProposal وProcessProposal)، وهو تغيير يكسر الإجماع. يعتمد مبدأه الأساسي على منع مشكلات تحديث الصفقات الكبيرة، حتى لو كانت الكتلة 8 ميجابايت أو أكبر. كما يفتح الباب لتقليل وقت الكتلة وزيادة حجم الكتلة لزيادة القدرة في المستقبل.