ملخص أجاف 2.0

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

‍

• تحسينات وإعادة هيكلة شاملة لقاعدة الكود والتحسينات
• مكافآت حصة الحقبة المقسمة
• مكافأة رسوم الأولوية الكاملة للمحققين
• الجدول الزمني المركزي الجديد مُفعل بشكل افتراضي الآن
• برنامج إثبات ZK ElGamal
• احصل على متغير النظام Syscall
• احصل على دور Syscall
• نقل الرهن ونقل اللامبورتس
• إزالة الطرق البرمجية البديلة
• إعادة تسمية الصندوق

‍

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

ما الذي يجعل الإصدار 2.0 تحديثًا رئيسيًا؟

لم يعد هناك 'مُعدِّل وحيد لـ 'سولانا'. تعتمد Agave 2.0 على العالم الجديد لـ 'سولانا' ذو العميل المتعدد وتمثل فاصلًا نظيفًا عن القديم.مستودع سولانا لابس في جيتهاب. سيتم أرشفة مستودع Solana Labs، ولن يتم قبول طلبات السحب الجديدة أو المشاكل بعد الآن. في السابق، كان هذا المستودع يعكس النشاط من مستودع Agave. يجب على المطورين ترحيل جميع الأنشطة إلىمستودع Anza Agave GitHubإذا لم يفعلوا ذلك بالفعل. البوابةعملية هجرة شركة سولانا لابس إلى أجاڤيبدأ في 1 مارس ويتم تتبعه علنًا على مستودعهم على GitHub.

‍

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

‍

‍

الصناديق المتأثرة هي:

‍

solana-validator، solana-ledger-tool، solana-watchtower، solana-install، solana-geyser-plugin-interface، solana-cargo-registry

‍

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

إطلاق الميزات

في وقت كتابة هذا التقرير ، ~ 20.7٪ من المدققين يقومون بتشغيل الإصدار 2.0.14. يتم إيقاف عمليات تنشيط بوابة الميزات على الشبكة الرئيسية مؤقتا للسماح لاعتماد الإصدار 2.0 بالمحاذاة بشكل أوثق مع عمليات التنشيط على testnet و devnet. بمجرد اعتماد مجموعة الشبكة الرئيسية على نطاق واسع الإصدار 2.0 ، من المتوقع استئناف عمليات تنشيط بوابة الميزات وفقا لترتيب التنشيط المجدول.

الميزات الكاملة الجديدة التي تمت مناقشتها في الأقسام التالية ليست مباشرة حاليا وسيتم طرحها ببطء على مدار دورة حياة 2.0 باستخدام نظام بوابة المعالم. يتم تنشيط الميزات في عصور معينة بناء على الأولوية النسبية والترتيب الذي تم تنشيطها به على مجموعات testnet و devnet.

‍

مكافأة رسوم الأولوية الكاملة للمحققين

هذا المنتظر بشدة وتحديث اقتصادي مثير للجدل كثيراًيتم تنفيذه حاليًا بعد الاقتراح،SIMD-0096، الذي خضع لتصويت حوكمة المدقق في مايو. اختتم التصويت في نهاية الحقبة 620 ، مشاركة 51.17% من حصة التصويت و 77.77% من التصويت بالموافقة. ستغير التحديث المحظور الميزة معالجة الشبكة بشكل جوهريرسوم الأولوية. بدلا من النموذج الحالي ، الذي يقسم الرسوم مع حرق 50٪ ومكافأة 50٪ للمدققين ، سيخصص النموذج الجديد 100٪ من رسوم الأولوية مباشرة إلى المدققين.

أعلاه: رسوم الأولوية الأسبوعية Solana بالدولار الأمريكي (مصدر)

‍

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

‍

رسوم التفضيل = سعر وحدة الحساب (ميكرو لامبورتس) × حد الوحدة الحسابية

‍

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

‍

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

‍

مكافآت الحقبة المقسمة

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

تحت هذا النهج الجديد، سيتم تقسيم حساب وتوزيع مكافأة الرهان عند حدود الحقبة إلى مرحلتين متميزتين:

‍

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

‍

لتيسير ومراقبة العملية، حساب Sysvar،EpochRewards, ستتتبع وتحقق من توزيع المكافآت طوال مرحلة التوزيع. يسجل EpochRewards Sysvar ما إذا كانت مرحلة توزيع المكافآت قيد التقدم والمعلومات اللازمة لاستئناف التوزيع عند بدء التشغيل من اللقطة.

حساب المكافأة

سيتم إجراء حسابات المكافآت في الكتلة الأولى من الحقبة. بمجرد حسابها، يتم تقسيم المكافآت إلى قطع توزيع مخزنة في البنك، والتي ستوزع خلال مرحلة توزيع المكافآت.

‍

لتقليل التأثير على وقت معالجة الكتلة خلال مرحلة توزيع الجوائز وضمان توزيع مجموعة فرعية من الجوائز بطريقة محددة في كل كتلة، سيتم توزيع 4،096 جائزة للحصة في كل كتلة. وللحماية من النمو المفاجئ في عدد حسابات الحصة، يتم وضع حد لعدد الكتل بنسبة 10٪ من الفتحات الإجمالية في فترة زمنية محددة. فقط إذا تم الوصول إلى هذا الحد المحدد للكتل يُسمح بتجاوز الحسابات في كل جزء بالعدد المستهدف 4،096.

توزيع الجوائز

تبدأ توزيعات الجوائز على الفور بعد مرحلة حساب الجوائز، بدءًا من الكتلة الثانية من الحقبة. تحدث توزيعات الجوائز في أعلى الكتلة قبل معالجة المعاملات العادية.

‍

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

‍

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

‍

المجدول المركزي مفعل الآن بشكل افتراضي

تم تقديم المجدول المركزي، المعروف سابقًا بـ "المجدول"، كميزة في تحديث v1.18 للمرة الأولى، ولم يكن مفعّلًا افتراضيًا وكان يتعين تفعيله من قبل المشغلين باستخدام علم --block-production-method central-scheduler عند بدء التشغيل. والآن تم تشغيله بشكل افتراضي. كان لتنفيذ المجدول السابق العديد من المشكلات التي يمكن أن تؤثر سلبًا على الأداء. تؤدي نقاط الضعف في معالجة المعاملات في كثير من الأحيان إلى تقطع أو تفاوت في ترتيب وترتيب الصفقات.

‍

يحل التطبيق الأحدث محل النموذج السابق المكون من أربعة خيوط مصرفية مستقلة ، يدير كل منها أولويات المعاملات ومعالجتها الخاصة. في هذا الهيكل المنقح ، يكون المجدول المركزي هو المتلقي الوحيد للمعاملات من مرحلة SigVerify الخاصة ب TPU. يقوم ببناء قائمة انتظار أولوية ونشر رسم بياني للتبعية ، يعرف باسم prio-graph ، لإدارة معالجة المعاملات المتعارضة وتحديد أولوياتها بشكل أفضل. يزيد تصميم المجدول الجديد هذا من قابلية التوسع والمرونة ، مما يسمح بزيادة عدد سلاسل الرسائل دون المخاوف السابقة من زيادة تعارضات القفل. وقد تبين أن الطرح الأولي للجدولة المركزية يولد مكافآت أفضل ، مما يؤدي إلى تحسين الأرباح للعديد من المشغلين. تمت تغطية منشور هيليوس السابق على تحديث Solana v1.18 على نطاق واسعكيف يعمل المجدول المركزي.

‍

برنامج ZK الجمل للإثبات

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

‍

لمعرفة المزيد حول برنامج برهان رمز ZK، اقرأ لديناالكتابة الأصلية على مدونة هيليوس.

الحصول على استدعاء Sysvar

تطلب مكالمات النظام أو استدعاءات النظام خدمات من نواة نظام التشغيل. في سياق Solana ، يمكن Syscall البرامج التي تعمل داخل Solana Virtual Machine (SVM) من التفاعل مع الموارد والخدمات الخارجية.

‍

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

‍

تم اقتراح Get-Sysvar Syscall في البداية فيSIMD-127 بواسطة مهندس Anza جو كولفيلد, يقدم واجهة Syscall موحدة للوصول إلى بيانات Sysvar. يتيح لهذا الترقية استرداد بيانات Sysvar التي كانت غير قابلة للوصول سابقًا، بما في ذلك SlotHashes و StakeHistory. من خلال هذه الواجهة الجديدة، يمكن للمطورين الوصول إلى شظايا محددة من بيانات Sysvar - مثل استدعاءSlotHashes::get_slot(slot) و StakeHistory::get_entry(epoch)—دون الحاجة إلى تكرار هياكل البيانات بأكملها.

‍

يقلل التحديث أيضا من الحمل عند تعديل تخطيطات بيانات Sysvar أو إضافة Sysvars جديدة. في السابق ، تطلب كل Sysvar جديد إضافة Syscall المقابلة ، مما أدى إلى إنشاء علاقة مقترنة بإحكام أدت إلى تضخيم واجهة Syscall بمرور الوقت والصيانة المعقدة. الآن ، سيخدم sol_get_Sysvar واحد Syscall جميع واجهات Sysvar ، مما يتيح استرجاع البيانات بشكل متسق وفعال من أي Sysvar.

‍

يؤدي تقديم Syscall الجديد إلى تبسيط عملية تعديل وإضافة Sysvars جديدة. إنه يقلل بشكل كبير من متطلبات التعقيد والصيانة لواجهة Syscall. بالإضافة إلى ذلك، يمهد هذا التحديث الطريق لتوسيع وصول برنامج BPF إلى بيانات Sysvar، مما يمكن البرامج على السلسلة من قراءة المزيد من معلومات Sysvar دون التأثير على حجم المعاملة.

‍

GetEpochStake Syscall

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

‍

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

‍

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

‍

موف حصة وموف لامبورتس

تعليمات برنامج حصة جديدتان،MoveStake و MoveLamportsتم طرح تلك التعليمات لأول مرة، وهي تهدف إلى تسهيل عمليات تحويل القيمة بين حسابات المساهمة. سيمد-0148، يساعد المطورين عن طريق السماح بتحريك الأموال بين الحسابات ذات السلطات المطابقة دون التحكم بسلطة السحب.

‍

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

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

‍

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

‍

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

‍

المكافأة: صندوق Solana-SVM

مع إصدار Agave 2.0 يأتيحاوية سولانا الجديدة بنظام البيئة الافتراضيةتتيح للمطورين الوصول المباشر إلى مكونات SVM الأساسية من خلال واجهة برمجة التطبيقات المبسطة مستقلة عن إطار الصلاحية الكامل. يفتح هذا مجال معالجة المعاملات عالية الأداء لـ Solana لتطبيقات خارج الصلاحية ، مثل الخدمات خارج السلسلة ، والعملاء الخفيفة ، وقنوات الحالة ، والتصغير.

‍

من خلال فصل واجهة برمجة التطبيقات (API) عن بقية الوقت التشغيل، يزيل هذا الحاوية الحاجة إلى مكونات مثل مثيلات البنك، مما يقلل من العبء التشغيلي. يمكن للمطورين الآن الاستفادة من نفس المكونات القوية التي تدعم الشبكة الرئيسية لـ Solana لبناء مشاريع مخصصة لـ SVM مثل العملاء الخفيفة، والقنوات الحالة، والتجميعات، والخدمات خارج السلسلة. يتكون جوهر هذا الواجهة البرمجية من الهيكل TransactionBatchProcessor، الذي يتيح للتطبيقات معالجة دفعات من المعاملات المعقمة لـ Solana مع مجموعة كاملة من مكونات Agave التالية، بما في ذلك BPF Loader، eBPF، والجهاز الظاهري.

‍

أعلاه: معالج دفعة المعاملات (مصدر الصورة: أنزا)

‍

اقرأ التحليل العميق لـ واجهة برمجة تطبيقات SVM الجديدة من Anza للحصول على تفاصيل كاملة حول هذا التطور المثير.

‍

تمت إزالة نقاط النهاية RPC

تمت إزالة العديد من نقاط النهاية v1 Agave RPC العفا عنها والمهجورة. فريق Helius Devrel تواصل مع جميع العملاء الذين يستخدمون هذه النقاط النهائية. من خلال التحليل الداخلي، تم تحديد مجموعة صغيرة من العملاء الذين يستخدمون بنشاط النقاط النهائية التالية والتي تم تعيينها للإزالة:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

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

‍

أعلاه: قائمة كاملة لنقاط نهاية Agave RPC v1 التي تم تجاوزها وإزالتها

‍

ملاحظة: يمكن استخدام الطريقة البديلة للحصول على معلومات الحساب الموضحة في الصورةوجد هنا.

‍

تتضمن التغييرات الكبيرة في SDK:

‍

• تمت إزالة الدعم لـ Borsh v0.9 ، يرجى استخدام v1 أو v0.10#1440)
• تم إيقاف تشغيل نسخة الصفةعلى Rent و EpochSchedule؛ التبديل إلى استخدام clone()
• solana-sdk: الرموز المهجورة) تمت إزالتها
• تمت إزالة الرموز المهجورة في برنامج سولانا

‍

بالنسبة لمشغلي المصادقة ، سيتم إزالة عدة وسيطات مصادقة مهجورة عند إصدار Agave v2.0. يمكن العثور على قائمة كاملة من هذه.هنا.

‍

الاستنتاج

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

‍

موارد إضافية / قراءة أخرى

• جدول إصدار Agave v2.0
• سجل التغييرات Agave v2.0
• إصدارات إطلاق أجاڤي

تنصل:

1. تم نقل هذه المقالة من [gatehelius)]. جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [ضائع في]. إذا كان هناك اعتراضات على هذا النشر مرجعاً، يرجى الاتصال بالبوابة التعلمالفريق، وسوف يتولى التعامل معها على الفور.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك التي يعبر عنها المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق تعلم بوابة. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوعة.