Solana Web3.js 2.x إصدار: تفسير ترقية مكتبة JavaScript الغنية بالميزات
تم إصدار Solana Web3.js، كمكتبة JavaScript غنية بالميزات، رسميًا في نوفمبر من هذا العام بإصدار 2.x. بالمقارنة مع الإصدار 1.x، جلب الإصدار الجديد العديد من التغييرات الكبيرة. ستقوم هذه المقالة بتحليل موجز لهذه التغييرات الرئيسية.
على الرغم من أن إصدار 2.x قد تم إصداره مؤخرًا، إلا أن استخدامه ليس مرتفعًا، ولم تقم العديد من المكتبات الشائعة بالتبديل بعد، إلا أن فهم هذه التغييرات أمر بالغ الأهمية لعمل الترحيل في المستقبل.
مقارنة الإصدارات
استخدام الإصدار 1.x بسيط نسبيًا. إنه يحتوي فقط على حزمة واحدة: @solana/web3.js، حيث تتركز جميع الوظائف فيها. تم تصميمها بناءً على الفئات وتغلف العديد من العمليات الشائعة، مثل فئة Connection التي توفر عشرات الطرق، مما يغطي تقريبًا جميع الوظائف التي يحتاجها المطورون.
ومع ذلك، فإن هذا التصميم يأتي أيضًا مع بعض المشكلات. على الرغم من أن المطورين عادةً ما يستخدمون فقط جزء صغير من الوظائف، إلا أنه يتم تنزيل مكتبة الشيفرة الكاملة على أجهزة المستخدمين، ونظرًا لحجم الشيفرة الكبير، قد يستغرق ذلك بعض الوقت.
اعتمد الإصدار 2.x منهجية مختلفة. قامت الفريق الرسمي بتقسيم قاعدة الشيفرة الأصلية إلى وحدات صغيرة متعددة، مثل @solana/accounts، @solana/codecs، @solana/rpc، @solana/signers، @solana/transactions، وغيرها. في الوقت نفسه، تخلت النسخة الجديدة عن التنفيذ القائم على الفئات، وفضلت بشكل أكبر استخدام الوظائف الفردية. هذه التغييرات مفيدة لتحسين بناء شيفرة JavaScript، حيث سيتم حذف الشيفرة غير المستخدمة، ولن يتم تنزيلها على أجهزة المستخدمين. وفقًا لإحصائيات الوثائق الرسمية، عادةً ما يمكن أن تحقق التطبيقات اللامركزية (DApp) التي تستخدم النسخة الجديدة تحسينًا بنسبة 30% في حجم الشيفرة، وإذا تم استخدام عدد قليل من الوظائف فقط، قد تكون نسبة التحسين أعلى.
هذا التغيير يفرض متطلبات أعلى على جودة الوثائق لفريق Solana. كيف يمكن مساعدة المطورين في العثور بسرعة على الوظائف المطلوبة أصبح سؤالاً محورياً. حالياً، تتمتع أسماء الحزم بمعاني جيدة، ويمكن فهم أغراضها تقريباً من أسمائها، مما يقلل إلى حد ما من صعوبة انتقال المطورين.
ومع ذلك، نظرًا لأنه تم إصداره مؤخرًا، فإن العديد من المشاريع لم تنتقل بعد. الأمثلة حول الإصدار 2.x على Solana Cookbook لا تزال قليلة نسبيًا. بالإضافة إلى ذلك، يميل الإصدار الجديد إلى استخدام الوظائف المدمجة في وقت التشغيل (مثل توليد أزواج المفاتيح)، لكن الوثائق تفتقر إلى وصف تفصيلي لهذه الأجزاء، مما يؤدي إلى شعور بعض المطورين بالارتباك.
تتمثل إحدى الميزات المهمة الأخرى في إصدار 2.x في عدم الاعتماد على أي شيء خارجي. على الرغم من أن هذا قد لا يكون الأكثر أهمية للعديد من المستخدمين، إلا أنه بالنظر إلى هجوم سلسلة التوريد الذي وقع في أوائل ديسمبر هذا العام على إصدارات @solana/web3.js 1.95.5 و 1.95.6، فإن المزيد من المدخلات والاعتماد الخارجي سيزيد بشكل كبير من احتمالية حدوث الأحداث الأمنية. مع إصدار 2.x، قرر فريق تطوير Web3.js استخدام الميزات الأصلية بشكل أكبر، وإلغاء الاعتماد الخارجي وإدخال Polyfills. على الرغم من أنه قد تكون هناك تغييرات في المستقبل، إلا أن إصدار 2.x قد أزال جميع الاعتماد الخارجي.
النقاط الهامة للتغيير
الاتصال
في إصدار 1.x، توفر فئة Connection عددًا كبيرًا من الطرق. على الرغم من أن وظيفتها الأساسية هي إنشاء مُرسل طلبات من خلال تكوين عنوان طلب RPC، ثم إرسال طلبات مختلفة من خلاله.
اعتمد الإصدار 2.x نهجًا أكثر وظيفية لتنفيذ هذه الميزة:
عند استدعاء sendAndConfirmTransaction لإرسال المعاملة، سيقوم النظام تلقائيًا بإجراء طلب HTTPS، وإنشاء اتصال WSS للاشتراك في حالة المعاملة، وعند تأكيد المعاملة، سيتم إرجاع تجزئة المعاملة.
زوج المفاتيح
حدثت تغييرات كبيرة أيضًا في الجزء المتعلق بالمفتاح العام والمفتاح الخاص. لم تعد الفئات المعروفة Keypair و PublicKey المستخدمة في الإصدار 1.x موجودة، وتم استبدالها ببعض الدوال.
على سبيل المثال، يمكن الآن استخدام await generateKeyPair() لإنشاء زوج مفاتيح، بدلاً من Keypair.generate() السابق.
من الجدير بالذكر أن الدالة الجديدة generateKeyPair ترجع Promise بدلاً من إرجاع زوج المفاتيح مباشرة. وذلك لأن التنفيذ الجديد يستخدم واجهة برمجة التطبيقات Web Crypto API الخاصة بـ JavaScript قدر الإمكان، ويستخدم تنفيذ Ed25519 الأصلي. العديد من طرق واجهة برمجة التطبيقات Web Crypto غير متزامنة. ومع ذلك، فإن هذا التغيير ليس غير مقبول، ففي عام 2024 الذي يوشك على الانتهاء، أصبح مطورو JavaScript مألوفين جدًا مع Promise.
إرسال الصفقة
يجب أن يكون مستخدمو الإصدار 1.x على دراية بفئتين هما Transaction و VersionedTransaction. في الإصدار 2.x، لم تعد هاتين الفئتين موجودتين.
لم تعد الأساليب المتعلقة ببرنامج النظام المتاحة في الإصدار السابق موجودة، لذا يجب استيراد جميع الأساليب الثابتة على فئة SystemProgram من مكان آخر.
على سبيل المثال، تحتاج الآن تعليمات transfer إلى استدعاء دالة getTransferSolInstruction من @solana-program/system.
نظرًا لعدم توفر الفئات بعد الآن ، فإن Web3.js يوفر شكل pipe المستخدم في البرمجة الوظيفية. فيما يلي مثال على تنفيذ وظيفة التحويل الأصلية من الإصدار 1.x باستخدام دالة pipe:
جافا سكريبت
استيراد { الأنابيب } من '@solana / وظيفي' ؛
استيراد {generateKeyPair } من '@solana/web3.js';
import { getTransferSolInstruction } من '@solana / system-program' ؛
استيراد { createTransaction } من '@solana / transactions' ؛
يمكن ملاحظة أن المعاملات لم تعد تتم عبر Connection، بل يتم إنشاء دالة معينة من خلال موفر RPC الذي حددناه، ثم يتم استدعاء هذه الدالة لبدء المعاملة. مقارنةً بالإصدار 1.x، زادت كمية الكود، ولكن أصبح التخصيص أكثر قوة.
تبدأ المعاملات من خلال HTTPS RPC ثم يتم تأكيد نتائج المعاملات عبر الاشتراك في WSS RPC. يمكن الشعور بأن الطريقة الجديدة تعتمد بشكل كبير على WSS، وأعتقد أن تطبيقات WSS ستصبح أكثر شيوعًا في المستقبل، وهذا يضع متطلبات أعلى على استقرار خدمات مقدمي RPC.
رد فعل
من المثير للاهتمام أن مشروع @solana/web3.js يتضمن أيضًا مكتبة تسمى @solana/react، والتي توفر بعض React Hook، مع ميزات مدمجة مثل signIn.
ملخص
إن إصدار النسخة 2.x من @solana/web3.js يجسد التزام فريق Solana بالتطور المستمر والتحسين. إنها توفر للمطورين وسيلة فعالة ومرنة وقابلة للتخصيص للتفاعل مع شبكة Solana، مما يساعد على دفع اعتماد هذه المنصة وتطورها. على الرغم من أن الاستخدام الحالي ليس مرتفعاً، إلا أنه مع مرور الوقت، نعتقد أن المزيد والمزيد من المشاريع ستنتقل إلى هذه النسخة الجديدة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 17
أعجبني
17
4
مشاركة
تعليق
0/400
BearMarketSurvivor
· منذ 23 س
تقرير الجبهة: يبدو أن الترقية أُطلقت كأول رصاصة في عش فارغ.
شاهد النسخة الأصليةرد0
OPsychology
· منذ 23 س
لا تتعجل في التغيير قبل أن تستقر الترقية.
شاهد النسخة الأصليةرد0
RugResistant
· منذ 23 س
همم تم اكتشاف نقاط ضعف أمنية محتملة... بحاجة إلى تدقيق شامل بصراحة
تحليل ترقية Solana Web3.js 2.0: التصميم المعياري يعزز الأداء والأمان
Solana Web3.js 2.x إصدار: تفسير ترقية مكتبة JavaScript الغنية بالميزات
تم إصدار Solana Web3.js، كمكتبة JavaScript غنية بالميزات، رسميًا في نوفمبر من هذا العام بإصدار 2.x. بالمقارنة مع الإصدار 1.x، جلب الإصدار الجديد العديد من التغييرات الكبيرة. ستقوم هذه المقالة بتحليل موجز لهذه التغييرات الرئيسية.
على الرغم من أن إصدار 2.x قد تم إصداره مؤخرًا، إلا أن استخدامه ليس مرتفعًا، ولم تقم العديد من المكتبات الشائعة بالتبديل بعد، إلا أن فهم هذه التغييرات أمر بالغ الأهمية لعمل الترحيل في المستقبل.
مقارنة الإصدارات
استخدام الإصدار 1.x بسيط نسبيًا. إنه يحتوي فقط على حزمة واحدة: @solana/web3.js، حيث تتركز جميع الوظائف فيها. تم تصميمها بناءً على الفئات وتغلف العديد من العمليات الشائعة، مثل فئة Connection التي توفر عشرات الطرق، مما يغطي تقريبًا جميع الوظائف التي يحتاجها المطورون.
ومع ذلك، فإن هذا التصميم يأتي أيضًا مع بعض المشكلات. على الرغم من أن المطورين عادةً ما يستخدمون فقط جزء صغير من الوظائف، إلا أنه يتم تنزيل مكتبة الشيفرة الكاملة على أجهزة المستخدمين، ونظرًا لحجم الشيفرة الكبير، قد يستغرق ذلك بعض الوقت.
اعتمد الإصدار 2.x منهجية مختلفة. قامت الفريق الرسمي بتقسيم قاعدة الشيفرة الأصلية إلى وحدات صغيرة متعددة، مثل @solana/accounts، @solana/codecs، @solana/rpc، @solana/signers، @solana/transactions، وغيرها. في الوقت نفسه، تخلت النسخة الجديدة عن التنفيذ القائم على الفئات، وفضلت بشكل أكبر استخدام الوظائف الفردية. هذه التغييرات مفيدة لتحسين بناء شيفرة JavaScript، حيث سيتم حذف الشيفرة غير المستخدمة، ولن يتم تنزيلها على أجهزة المستخدمين. وفقًا لإحصائيات الوثائق الرسمية، عادةً ما يمكن أن تحقق التطبيقات اللامركزية (DApp) التي تستخدم النسخة الجديدة تحسينًا بنسبة 30% في حجم الشيفرة، وإذا تم استخدام عدد قليل من الوظائف فقط، قد تكون نسبة التحسين أعلى.
هذا التغيير يفرض متطلبات أعلى على جودة الوثائق لفريق Solana. كيف يمكن مساعدة المطورين في العثور بسرعة على الوظائف المطلوبة أصبح سؤالاً محورياً. حالياً، تتمتع أسماء الحزم بمعاني جيدة، ويمكن فهم أغراضها تقريباً من أسمائها، مما يقلل إلى حد ما من صعوبة انتقال المطورين.
ومع ذلك، نظرًا لأنه تم إصداره مؤخرًا، فإن العديد من المشاريع لم تنتقل بعد. الأمثلة حول الإصدار 2.x على Solana Cookbook لا تزال قليلة نسبيًا. بالإضافة إلى ذلك، يميل الإصدار الجديد إلى استخدام الوظائف المدمجة في وقت التشغيل (مثل توليد أزواج المفاتيح)، لكن الوثائق تفتقر إلى وصف تفصيلي لهذه الأجزاء، مما يؤدي إلى شعور بعض المطورين بالارتباك.
تتمثل إحدى الميزات المهمة الأخرى في إصدار 2.x في عدم الاعتماد على أي شيء خارجي. على الرغم من أن هذا قد لا يكون الأكثر أهمية للعديد من المستخدمين، إلا أنه بالنظر إلى هجوم سلسلة التوريد الذي وقع في أوائل ديسمبر هذا العام على إصدارات @solana/web3.js 1.95.5 و 1.95.6، فإن المزيد من المدخلات والاعتماد الخارجي سيزيد بشكل كبير من احتمالية حدوث الأحداث الأمنية. مع إصدار 2.x، قرر فريق تطوير Web3.js استخدام الميزات الأصلية بشكل أكبر، وإلغاء الاعتماد الخارجي وإدخال Polyfills. على الرغم من أنه قد تكون هناك تغييرات في المستقبل، إلا أن إصدار 2.x قد أزال جميع الاعتماد الخارجي.
النقاط الهامة للتغيير
الاتصال
في إصدار 1.x، توفر فئة Connection عددًا كبيرًا من الطرق. على الرغم من أن وظيفتها الأساسية هي إنشاء مُرسل طلبات من خلال تكوين عنوان طلب RPC، ثم إرسال طلبات مختلفة من خلاله.
اعتمد الإصدار 2.x نهجًا أكثر وظيفية لتنفيذ هذه الميزة:
جافا سكريبت استيراد { createSolanaRpc } من "@solana / web3.js" ؛
const rpc = createSolanaRpc("");
عند استدعاء sendAndConfirmTransaction لإرسال المعاملة، سيقوم النظام تلقائيًا بإجراء طلب HTTPS، وإنشاء اتصال WSS للاشتراك في حالة المعاملة، وعند تأكيد المعاملة، سيتم إرجاع تجزئة المعاملة.
زوج المفاتيح
حدثت تغييرات كبيرة أيضًا في الجزء المتعلق بالمفتاح العام والمفتاح الخاص. لم تعد الفئات المعروفة Keypair و PublicKey المستخدمة في الإصدار 1.x موجودة، وتم استبدالها ببعض الدوال.
على سبيل المثال، يمكن الآن استخدام await generateKeyPair() لإنشاء زوج مفاتيح، بدلاً من Keypair.generate() السابق.
من الجدير بالذكر أن الدالة الجديدة generateKeyPair ترجع Promise بدلاً من إرجاع زوج المفاتيح مباشرة. وذلك لأن التنفيذ الجديد يستخدم واجهة برمجة التطبيقات Web Crypto API الخاصة بـ JavaScript قدر الإمكان، ويستخدم تنفيذ Ed25519 الأصلي. العديد من طرق واجهة برمجة التطبيقات Web Crypto غير متزامنة. ومع ذلك، فإن هذا التغيير ليس غير مقبول، ففي عام 2024 الذي يوشك على الانتهاء، أصبح مطورو JavaScript مألوفين جدًا مع Promise.
إرسال الصفقة
يجب أن يكون مستخدمو الإصدار 1.x على دراية بفئتين هما Transaction و VersionedTransaction. في الإصدار 2.x، لم تعد هاتين الفئتين موجودتين.
لم تعد الأساليب المتعلقة ببرنامج النظام المتاحة في الإصدار السابق موجودة، لذا يجب استيراد جميع الأساليب الثابتة على فئة SystemProgram من مكان آخر.
على سبيل المثال، تحتاج الآن تعليمات transfer إلى استدعاء دالة getTransferSolInstruction من @solana-program/system.
نظرًا لعدم توفر الفئات بعد الآن ، فإن Web3.js يوفر شكل pipe المستخدم في البرمجة الوظيفية. فيما يلي مثال على تنفيذ وظيفة التحويل الأصلية من الإصدار 1.x باستخدام دالة pipe:
جافا سكريبت استيراد { الأنابيب } من '@solana / وظيفي' ؛ استيراد {generateKeyPair } من '@solana/web3.js'; import { getTransferSolInstruction } من '@solana / system-program' ؛ استيراد { createTransaction } من '@solana / transactions' ؛
معاملة CONST = pipe( createTransaction()، addInstruction(getTransferSolInstruction({ fromPubkey: sender.publicKey, toPubkey: المستلم ، لامبورتس: الكمية ، })), setRecentBlockhash(blockhash)، addSigners([sender]) );
توقيع const = await rpc.sendAndConfirmTransaction(transaction);
يمكن ملاحظة أن المعاملات لم تعد تتم عبر Connection، بل يتم إنشاء دالة معينة من خلال موفر RPC الذي حددناه، ثم يتم استدعاء هذه الدالة لبدء المعاملة. مقارنةً بالإصدار 1.x، زادت كمية الكود، ولكن أصبح التخصيص أكثر قوة.
تبدأ المعاملات من خلال HTTPS RPC ثم يتم تأكيد نتائج المعاملات عبر الاشتراك في WSS RPC. يمكن الشعور بأن الطريقة الجديدة تعتمد بشكل كبير على WSS، وأعتقد أن تطبيقات WSS ستصبح أكثر شيوعًا في المستقبل، وهذا يضع متطلبات أعلى على استقرار خدمات مقدمي RPC.
رد فعل
من المثير للاهتمام أن مشروع @solana/web3.js يتضمن أيضًا مكتبة تسمى @solana/react، والتي توفر بعض React Hook، مع ميزات مدمجة مثل signIn.
ملخص
إن إصدار النسخة 2.x من @solana/web3.js يجسد التزام فريق Solana بالتطور المستمر والتحسين. إنها توفر للمطورين وسيلة فعالة ومرنة وقابلة للتخصيص للتفاعل مع شبكة Solana، مما يساعد على دفع اعتماد هذه المنصة وتطورها. على الرغم من أن الاستخدام الحالي ليس مرتفعاً، إلا أنه مع مرور الوقت، نعتقد أن المزيد والمزيد من المشاريع ستنتقل إلى هذه النسخة الجديدة.