Solana Web3.js 2.x الإصدار: تقسيم الوظائف وتحسين الأداء

تم إصدار الإصدار 2.x من مكتبة JavaScript الغنية بالوظائف Solana Web3.js رسميًا في نوفمبر. مقارنةً بالإصدار 1.x، شهد الإصدار الجديد تغييرات كبيرة. ستقوم هذه المقالة بتلخيص التغييرات الرئيسية.

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

مقارنة الإصدارات

الإصدار القديم كان استخدامه بسيطًا نسبيًا، حيث كان يحتوي فقط على حزمة واحدة @solana/web3.js، وكانت جميع الوظائف مركزة فيها. يعتمد على تصميم الكلاسات، ويغلف العديد من العمليات الشائعة الاستخدام. على سبيل المثال، توفر فئة Connection العشرات من الطرق التي تغطي تقريبًا جميع الوظائف التي يحتاجها المطورون. بالإضافة إلى ذلك، فإن العديد من أمثلة التعليمات البرمجية المقدمة في كتاب الطبخ الخاص بـ Solana توفر أيضًا سهولة للمطورين.

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

اعتمدت النسخة 2.x استراتيجيات مختلفة. قام الفريق الرسمي بتقسيم قاعدة الشيفرة الأصلية إلى عدة وحدات أصغر، مثل @solana/accounts، @solana/codecs، @solana/rpc، @solana/signers، @solana/transactions، وغيرها. في الوقت نفسه، تخلوا عن التنفيذ القائم على الفئات، واعتمدوا بشكل أكبر على أسلوب الوظائف الفردية. هذه التغييرات مفيدة لتحسين بناء شيفرة JavaScript، حيث سيتم حذف الشيفرة غير المستخدمة، ولن يتم تحميلها على أجهزة المستخدمين. وفقًا للإحصاءات الواردة في الوثائق الرسمية، يمكن أن تحصل DApps التي تستخدم النسخة الجديدة على تحسين في الحجم بنسبة 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 الأصلي. العديد من طرق واجهة برمجة تطبيقات تشفير الويب غير متزامنة. ومع ذلك ، يجب ألا تسبب هذه التغييرات أي إزعاج كبير لمطوري JavaScript المألوفين بالوعود.

إرسال المعاملة

فئة Transaction و VersionedTransaction المستخدمة بشكل شائع في الإصدار 1.x لم تعد موجودة في الإصدار 2.x.

لم تعد طرق نظام البرنامج المقدمة في الإصدار القديم موجودة أيضًا، ويجب استيراد الطرق الثابتة من فئة SystemProgram من أماكن أخرى.

على سبيل المثال، يتطلب أمر transfer استدعاء دالة getTransferSolInstruction في @solana-program/system.

نظرًا لعدم توفير class بعد الآن، توفر Web3.js شكل pipe الشائع في البرمجة الوظيفية. فيما يلي مثال على استخدام دالة pipe لتنفيذ وظيفة التحويل الأصلية 1.x:

جافا سكريبت استيراد { الأنابيب } من "@solana / وظيفي" ؛ import { getTransferSolInstruction } من "@solana / system" ؛ استيراد { createSolanaRpc ، إرسال المعاملة ، setTransactionFeePayer ، إنشاء المعاملة, appendTransactionInstruction ، } من "@solana/web3.js";

const rpc = createSolanaRpc("");

معاملة CONST = pipe( createTransaction()، setTransactionFeePayer(payer.address) ، appendTransactionInstruction( getTransferSolInstruction({ fromAddress: payer.address, toAddress: المستلم, المبلغ، }) ) );

توقيع const = انتظر sendTransaction(rpc ، معاملة ، [payer]) ؛

بالمقارنة مع إصدار 1.x، زادت كمية الشفرة، ولكن قابلية التخصيص أصبحت أقوى.

يتم بدء المعاملات من خلال HTTPS RPC، ثم يتم تأكيد نتائج المعاملات من خلال الاشتراك في WSS RPC. الطريقة الجديدة تعتمد بشكل أكبر على WSS، مما يضع متطلبات أعلى على استقرار خدمات مزودي RPC.

رد فعل

يتضمن مشروع @solana/web3.js مكتبة تُدعى @solana/react، والتي توفر بعض Hooks الخاصة بـ React، مع ميزات مدمجة مثل signIn.

ملخص

إصدار النسخة 2.x من @solana/web3.js يعكس التزام فريق Solana بالتطوير المستمر والتحسين. يوفر للمطورين طريقة فعالة ومرنة وقابلة للتخصيص للتفاعل مع شبكة Solana، مما يساعد على تعزيز اعتماد هذه المنصة وتطويرها.