Web3.js

ما هو Web3.js؟

Web3.js مكتبة JavaScript وTypeScript يستخدمها المطورون للتفاعل مع Ethereum وغيرها من شبكات البلوكشين المتوافقة مع EVM.

تساعد التطبيقات على قراءة بيانات البلوكشين وإرسال المعاملات والتفاعل مع العقود الذكية وإدارة الحسابات والاشتراك في الأحداث والاتصال بعُقد البلوكشين عبر المزوّدين.

تصف وثائق Web3.js الرسمية Web3.js بأنها مجموعة من مكتبات TypeScript وJavaScript للتفاعل مع عُقد Ethereum المحلية أو البعيدة وشبكات البلوكشين المتوافقة مع EVM عبر اتصالات HTTP أو IPC أو WebSocket.

ببساطة، Web3.js مجموعة أدوات للمطورين تتيح لموقع ويب أو خادم أو نص برمجي أو تطبيق لامركزي التواصل مع بلوكشين.

لا يتفاعل المستخدم عادةً مع Web3.js مباشرة.

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

Web3.js ليست عملة مشفرة.

وليست بلوكشين.

وليست محفظة بحد ذاتها.

وليست لغة للعقود الذكية.

إنها مكتبة JavaScript تغلف استدعاءات Ethereum JSON-RPC في دوال سهلة للمطورين.

الوضع الحالي لـ Web3.js

تتمتع Web3.js بأهمية تاريخية، لكنها لم تعد التوصية الافتراضية لكثير من مشاريع Ethereum الجديدة.

تحذر الصفحة الرسمية لمكتبات JavaScript API الخاصة بـ Ethereum من أن Web3.js أُرشفت في 4 مارس 2025، وتنصح المطورين بالنظر في مكتبات أخرى تحظى بصيانة نشطة للمشاريع الجديدة.

كما يذكر مستودع Web3.js الرسمي على GitHub أن مكتبات Web3.js كانت تدخل مرحلة الإيقاف في 4 مارس 2025، ويصف Web3.js بأنه تنفيذ TypeScript لواجهة Ethereum JSON-RPC وأدوات مرتبطة بها تحت صيانة ChainSafe Systems.

لا يعني ذلك أن كل تطبيق قديم يستخدم Web3.js توقف عن العمل فورًا.

لكنه يعني أن على المطورين توخي الحذر قبل اختيار Web3.js لمشروع إنتاجي جديد.

قد تستمر التطبيقات اللامركزية القديمة والدروس التعليمية والنصوص الداخلية وقواعد التعليمات البرمجية الأقدم في استخدام Web3.js.

وينبغي للمطورين الذين يحافظون على تلك الأنظمة فهم آلية عمل Web3.js، وكيفية اتصاله بالعُقد، ومخاطر الترحيل المحتملة.

في مسرد الكريبتو، ينبغي شرح Web3.js كمكتبة JavaScript رئيسية لـ Ethereum ذات أهمية تاريخية قوية وحالة إيقاف واضحة.

لماذا يهم Web3.js في الكريبتو؟

يهم Web3.js لأنه ساعد على تسهيل تطوير تطبيقات Ethereum لمطوري JavaScript.

تُستخدم JavaScript على نطاق واسع في المواقع وخدمات الخلفية وأدوات سطر الأوامر ولوحات المعلومات ونصوص المطورين.

ومن خلال إتاحة وسيلة لمطوري JavaScript للتواصل مع عُقد Ethereum، ساعد Web3.js في توسيع منظومة التطبيقات اللامركزية المبكرة.

يمكن للمطور استخدام Web3.js للتحقق من رصيد ETH أو استدعاء دالة عقد ذكي أو تقدير رسوم الغاز أو إرسال معاملة أو الاستماع لأحداث العقد أو فك ترميز بيانات البلوكشين.

ولهذا كان Web3.js أحد أشهر الأسماء في تطوير Ethereum لسنوات عديدة.

وحتى إن اختارت المشاريع الجديدة مكتبات مختلفة اليوم، ما زال كثير من المطورين يواجهون Web3.js في الدروس القديمة ومستودعات GitHub والتطبيقات اللامركزية المنشورة والنصوص التحليلية والبنية التحتية القديمة لـ DeFi.

يساعد فهم Web3.js على فهم كيفية تواصل الواجهات الأمامية مع العقود الذكية.

كما يساعد على فهم أهمية مزودي RPC والمحافظ وABIs ورسوم الغاز وتوقيع المعاملات ومعرفات السلاسل في تطوير Web3.

Web3.js وEthereum JSON-RPC

يعمل Web3.js بإرسال الطلبات إلى عُقد Ethereum عبر API الخاص بـ JSON-RPC.

JSON-RPC صيغة لاستدعاء الإجراءات عن بُعد تتيح للبرامج إرسال طلبات منظمة واستقبال استجابات منظمة.

توضح وثائق Ethereum JSON-RPC أن مكتبات JavaScript والخلفية توفر غالبًا أغلفة فوق API الخاص بـ JSON-RPC، ليستخدم المطورون أساليب أسهل بدل إنشاء كل طلب يدويًا.

فعلى سبيل المثال، قد يطلب طلب JSON-RPC خام من عقدة رصيد عنوان ما، بينما يتيح Web3.js للمطور استدعاء دالة أبسط.

في الخلفية، تظل المكتبة تتواصل مع العقدة عبر مزود.

ولهذا يعتمد Web3.js على الوصول إلى العُقد.

لا يستطيع التطبيق اللامركزي قراءة بيانات Ethereum ما لم تكن لديه وسيلة للاتصال بعقدة Ethereum أو نقطة نهاية RPC.

وقد تأتي نقطة النهاية من عقدة محلية أو مزود عُقد مستضاف أو محفظة متصفح أو مزود بنية تحتية خاصة أو شبكة تطوير.

مزودو Web3.js

المزود هو طبقة الاتصال بين Web3.js وعقدة بلوكشين.

يوضح دليل مزودي Web3.js أن المزودين يتيحون اتصال Web3.js بـ Ethereum وهم ضروريون للاستعلام عن البيانات وإرسال المعاملات والتفاعل مع العقود الذكية.

تشمل الأنواع الشائعة مزودي HTTP وWebSocket وIPC ومزودي محافظ المتصفح المحقونة.

يُستخدم مزود HTTP غالبًا لاستعلامات البلوكشين العادية القائمة على الطلب والاستجابة.

ويفيد مزود WebSocket عندما يريد المطور اشتراكات مباشرة، مثل الاستماع إلى الكتل الجديدة أو أحداث العقود.

ويمكن استخدام مزود IPC عند الاتصال بعقدة محلية على الجهاز نفسه.

وغالبًا ما توفر محفظة متصفح مزودًا محقونًا كي تطلب صفحة الويب اتصال المحفظة وتوقيع المعاملات.

يؤثر اختيار المزود في الموثوقية والخصوصية والسرعة والتكلفة وتجربة المستخدم.

وقد يؤدي المزود الضعيف إلى معاملات فاشلة أو قراءات بطيئة أو أحداث فائتة أو حدود للمعدل أو واجهات مستخدم غير دقيقة.

ينبغي لتنفيذ جيد لـ Web3.js التعامل مع المزود كقرار بنية تحتية أساسي، لا كتفصيل إعداد بسيط.

Web3.js والعقود الذكية

يُستخدم Web3.js عادةً للتفاعل مع العقود الذكية.

العقد الذكي برنامج منشور على بلوكشين.

للتفاعل معه، يحتاج المطور عادةً إلى عنوان العقد وABI.

تعني ABI واجهة التطبيق الثنائية.

وتخبر ABI مكتبة Web3.js بكيفية ترميز استدعاءات الدوال وفك ترميز البيانات المعادة.

باستخدام Web3.js، يستطيع المطور إنشاء كائن عقد واستدعاء الدوال للقراءة فقط وإرسال المعاملات التي تغيّر الحالة وتقدير رسوم الغاز والاستماع إلى الأحداث المُصدرة.

لا يغير استدعاء القراءة فقط حالة البلوكشين، ولا يتطلب عادةً رسوم غاز من المستخدم.

أما المعاملة التي تغير الحالة فتعدل حالة البلوكشين ويجب توقيعها من حساب يملك أموالًا كافية لدفع الرسوم.

وهذا الفرق مهم لمستخدمي التطبيقات اللامركزية.

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

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

Web3.js والمحافظ

يمكن أن يعمل Web3.js مع مزودي المحافظ، لكنه ليس محفظة بحد ذاته.

تدير المحفظة الحسابات والمفاتيح الخاصة والتوقيع وموافقة المستخدم.

يوفر Web3.js دوالًا تطلب البيانات وتجهز المعاملات وترسل المعاملات الموقعة عبر مزود.

في تطبيق لامركزي عبر المتصفح، تحقن المحفظة عادةً مزودًا في الصفحة.

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

غالبًا ما يُناقش سلوك مزود المحافظ الحديث من خلال معايير مثل EIP-1193، الذي يحدد API لمزود Ethereum بلغة JavaScript للتواصل بين المحفظة والتطبيق.

ومعيار آخر ذو صلة هو EIP-6963، الذي يعالج اكتشاف مزودي المحافظ المتعددة لتقليل التعارضات عندما يثبت المستخدم أكثر من محفظة متصفح.

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

ويظل التطبيق اللامركزي الذي يستخدم Web3.js بحاجة إلى طلبات محفظة آمنة ومعالجة صحيحة للسلسلة وشرح واضح للمعاملات.

حسابات Web3.js

يتضمن Web3.js أدوات مرتبطة بالحسابات، لكن ينبغي للمطورين التعامل معها بحذر.

قد تساعد أدوات الحسابات في إنشاء الحسابات وتوقيع المعاملات وتوقيع الرسائل واستعادة التوقيعات أو إدارة التدفقات المعتمدة على المفاتيح الخاصة.

قد تفيد هذه الميزات خدمات الخلفية والنصوص والاختبارات والبنية التحتية الخاضعة للتحكم.

لكنها قد تكون خطيرة عند استخدامها بصورة سيئة.

لا ينبغي لتطبيق لامركزي في الواجهة الأمامية أن يطلب من المستخدمين لصق مفاتيحهم الخاصة في موقع ويب.

ولا ينبغي للخادم تخزين المفاتيح الخاصة دون ضوابط أمنية قوية.

ولا ينبغي للنص البرمجي كشف المفاتيح الخاصة في السجلات أو ملفات البيئة أو حزم المتصفح أو المستودعات العامة.

تتحكم المفاتيح الخاصة وعبارات الاسترداد في الأموال.

قد يوفر Web3.js أدوات للتوقيع، لكنه لا يستطيع حماية مفتاح يخزنه المطور بصورة خاطئة.

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

Web3.js والمعاملات

يمكن أن يساعد Web3.js المطورين على إنشاء المعاملات وتوقيعها وإرسالها ومراقبتها.

قد تنقل المعاملة العملة الأصلية أو تستدعي عقدًا ذكيًا أو تنشر عقدًا أو توافق على توكن أو تسك NFT أو تطالب بإيردروب أو تتفاعل مع بروتوكول DeFi.

تتطلب المعاملات معرف السلسلة الصحيح وعنوان المستلم والقيمة وإعدادات الغاز وnonce وحقل البيانات.

وقد يسبب الخطأ في أي من هذه الحقول فشلًا أو خسارة.

يمكن لـ Web3.js تقدير الغاز وترميز استدعاءات دوال العقود وإرسال المعاملات عبر مزود.

لكن المكتبة لا تستطيع تحديد ما إذا كانت المعاملة آمنة اقتصاديًا.

ولا تستطيع معرفة ما إذا كانت الموافقة على توكن محفوفة بالمخاطر ما لم يتحقق التطبيق من ذلك.

ولا يمكنها ضمان أن العقد الذكي آمن.

ولا يمكنها عكس معاملة بعد تأكيدها.

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

Web3.js ورسوم الغاز

رسوم الغاز هي تكاليف المعاملات المدفوعة لتنفيذ العمليات على Ethereum وغيرها من السلاسل المتوافقة مع EVM.

يمكن لـ Web3.js المساعدة في تقدير الغاز للمعاملات وقراءة البيانات المتعلقة بالرسوم من الشبكة.

لكن تقدير الغاز ليس مثاليًا.

قد تفشل المعاملة إذا تغيرت شروط العقد قبل التنفيذ.

وقد يكون تقدير الغاز منخفضًا جدًا إذا تغير مسار المعاملة.

وقد تصبح المعاملة مكلفة أثناء ازدحام الشبكة.

وقد يدفع المستخدم الغاز حتى عند ارتداد المعاملة، وفقًا لمدى تقدم التنفيذ.

لا ينبغي للمطورين الذين يستخدمون Web3.js إخفاء معلومات الغاز عن المستخدمين.

ينبغي أن يعرضوا الرسوم المقدرة ويحذروا من احتمال الفشل ويتعاملوا مع الأخطاء بوضوح.

بالنسبة لمستخدمي الكريبتو، تُعد رسوم الغاز جزءًا من تكلفة المعاملة الفعلية، لا تفصيلًا تقنيًا بسيطًا.

Web3.js والأحداث

يمكن للعقود الذكية إصدار أحداث، ويمكن لـ Web3.js الاستماع إليها.

تفيد الأحداث لأنها تتيح للتطبيقات تتبع نشاط العقد مثل التحويلات والموافقات والمبادلات والإيداعات والسحوبات والأصوات وعمليات السك.

قد يستخدم التطبيق اللامركزي سجلات الأحداث لتحديث واجهات المستخدم أو عرض سجل المعاملات أو تشغيل الإشعارات أو بناء التحليلات.

غالبًا ما تستخدم مزودات WebSocket لاشتراكات الأحداث المباشرة.

ويمكن استخدام مزودي HTTP أيضًا للاستعلام عن السجلات السابقة.

تتطلب معالجة الأحداث الحذر لأن إعادة تنظيم البلوكشين قد تحدث.

لا ينبغي للتطبيق أن يفترض أن كل حدث نهائي فور ظهوره.

قد تنتظر التطبيقات التأكيدات قبل التعامل مع الحدث باعتباره نهائيًا.

وقد يصبح فهرسة سجلات الأحداث الكبيرة مكلفًا أو بطيئًا.

في التطبيقات الإنتاجية، قد يجمع المطورون Web3.js مع خدمات الفهرسة أو قواعد البيانات أو معالجات الأحداث المخصصة.

Web3.js وواجهات التطبيقات اللامركزية

يُستخدم Web3.js غالبًا في الواجهات الأمامية للتطبيقات اللامركزية.

واجهة التطبيق اللامركزي هي واجهة الموقع أو التطبيق التي يتفاعل معها المستخدمون.

قد تعرض الواجهة الأرصدة وأسعار التوكنات ومراكز التخزين وبيانات NFT وسجل المعاملات ومقترحات الحوكمة أو مراكز DeFi.

يمكن لـ Web3.js مساعدة الواجهة في قراءة بيانات العقود الذكية وطلب إجراءات المحفظة.

لكن واجهة Web3 بيئة عالية المخاطر لأن المستخدمين قد يوقعون المعاملات منها.

إذا تعرضت الواجهة للاختراق، فقد يُخدع المستخدمون للموافقة على معاملات ضارة.

وإذا كان ABI أو عنوان العقد خاطئًا، فقد يتفاعل التطبيق مع العقد الخطأ.

وإذا كان معرف السلسلة خاطئًا، فقد يرسل المستخدمون معاملات على الشبكة الخطأ.

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

ينبغي لتطوير واجهات Web3.js الجيدة أن يشمل الأمن وسهولة الاستخدام وطلبات المحفظة الواضحة.

Web3.js ونصوص الخلفية

يمكن استخدام Web3.js أيضًا في نصوص الخلفية وتطبيقات الخوادم.

قد تستخدمه الخلفية لمراقبة الإيداعات ومسح أحداث العقود وتحديث قاعدة بيانات وإرسال المعاملات وإدارة عمليات الخزينة أو تشغيل أتمتة البلوكشين.

تختلف حالات استخدام الخلفية عن حالات استخدام الواجهة الأمامية.

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

لا ينبغي لنظام خلفي تخزين المفاتيح الخاصة بلا مبالاة في التعليمات البرمجية المصدرية.

ينبغي استخدام إدارة آمنة للبيئة وضوابط وصول وأدوات أمن الأجهزة وخدمات إدارة المفاتيح أو ممارسات أمنية قوية أخرى حسب الاقتضاء.

كما ينبغي لنظام خلفي يستخدم Web3.js التعامل بعناية مع إخفاقات RPC.

قد تتأخر عُقد البلوكشين أو تعيد أخطاء أو تحد من الطلبات أو تختلف مؤقتًا في ظروف الشبكة.

تحتاج أنظمة الكريبتو الإنتاجية إلى أكثر من نص بسيط منسوخ من درس تعليمي.

Web3.js والسلاسل المتوافقة مع EVM

يُستخدم Web3.js غالبًا خارج الشبكة الرئيسية لـ Ethereum لأن كثيرًا من شبكات البلوكشين متوافقة مع EVM.

تدعم السلسلة المتوافقة مع EVM عقودًا ذكية بأسلوب Ethereum وسلوك Ethereum JSON-RPC.

وهذا يعني أن Web3.js يمكنه غالبًا الاتصال بشبكات متعددة عبر تغيير نقطة نهاية RPC وإعداد السلسلة.

لكن توافق EVM لا يعني أن كل السلاسل تتصرف بالطريقة نفسها تمامًا.

قد تختلف الشبكات في أوقات الكتل وأنظمة الرسوم وافتراضات النهائية وخصائص RPC ودعم precompile ومخاطر الجسور وأدوات المستكشف.

وقد لا يملك عقد منشور على سلسلة EVM عنوانًا أو حالة مماثلة على سلسلة أخرى.

وقد يوجد رمز توكن كذلك على سلاسل متعددة مع تمثيله لعقود مختلفة.

يجب على المطورين الذين يستخدمون Web3.js عبر السلاسل التحقق من معرف السلسلة وعنوان العقد وعنوان التوكن وموثوقية RPC وإعدادات شبكة محفظة المستخدم.

يعد الالتباس عبر السلاسل من أسهل الطرق التي قد يرتكب بها المستخدمون أخطاء مكلفة.

Web3.js الإصدار 1 مقابل الإصدار 4

مر Web3.js بإصدارات رئيسية خلال عمره.

تستخدم الدروس الأقدم غالبًا أنماط Web3.js 0.x أو 1.x.

وقدمت الإصدارات اللاحقة Web3.js 4.x بتحسينات تركز على TypeScript وحزم معيارية ودعم الإضافات ووثائق محدثة.

يصف دليل RPC المخصص لـ Web3.js دعم الإضافات في Web3.js 4.x باعتباره طريقة لتوسيع المكتبة بأساليب JSON-RPC جديدة.

هذا مهم لأن أمثلة التعليمات البرمجية القديمة قد لا تعمل مباشرةً مع إصدارات الحزم الأحدث.

ينبغي للمطورين الذين يحافظون على كود Web3.js التحقق من الإصدار الذي يستخدمه المشروع قبل نسخ الصياغة من درس.

وينبغي لهم كذلك مراجعة أدلة الترحيل عند الترقية.

قد يسبب عدم تطابق الإصدارات استيرادات معطلة أو أنواع إرجاع مختلفة أو سلوك مزود متغير أو معالجة غير متوقعة للمعاملات.

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

Web3.js مقابل Web3

Web3.js وWeb3 مصطلحان مرتبطان، لكنهما لا يعنيان الشيء نفسه.

Web3 فكرة واسعة حول إنترنت مبني بالبلوكشين والملكية الرقمية والمحافظ والتوكنات والتطبيقات اللامركزية والبيانات التي يتحكم بها المستخدم.

أما Web3.js فهو مكتبة JavaScript محددة تستخدم للتفاعل مع شبكات البلوكشين بأسلوب Ethereum.

يمكن للمستخدم تعلم Web3 دون كتابة كود.

وقد يستخدم المطور Web3.js لبناء تطبيق Web3.

وقد يربك تشابه الأسماء المبتدئين.

عندما يقول درس «install web3»، فقد يقصد حزمة Web3.js.

وعندما تقول مقالة «Web3 is changing the internet»، فعادةً ما تقصد مفهوم الإنترنت الأوسع القائم على البلوكشين.

في المسرد، يهم هذا التمييز لنوايا البحث.

Web3.js مكتبة، بينما Web3 فكرة منظومية.

Web3.js مقابل Solidity

Web3.js وSolidity أداتان مختلفتان تُستخدمان في أجزاء مختلفة من تطوير البلوكشين.

Solidity لغة برمجة تستخدم لكتابة العقود الذكية.

Web3.js مكتبة JavaScript تستخدم للتفاعل مع العقود الذكية وعُقد البلوكشين.

قد يكتب المطور عقد توكن بلغة Solidity، ثم يستخدم Web3.js لنشر العقد أو استدعاء دواله أو قراءة الأرصدة أو بناء واجهة مستخدم له.

يعمل كود Solidity على السلسلة بعد النشر.

بينما يعمل كود Web3.js عادةً خارج السلسلة في متصفح أو خادم أو نص برمجي أو بيئة تطوير.

قد يؤدي الخلط بينهما إلى بنية سيئة.

ينبغي أن يكون منطق العقود الذكية في Solidity أو لغة عقود أخرى.

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

Web3.js مقابل JSON-RPC

Web3.js وJSON-RPC ليسا الشيء نفسه.

JSON-RPC واجهة الاتصال منخفضة المستوى المستخدمة لطلب البيانات أو الإجراءات من عُقد Ethereum.

أما Web3.js فهو مكتبة JavaScript عالية المستوى تجعل JSON-RPC أسهل استخدامًا.

يمكن للمطور استدعاء Ethereum JSON-RPC مباشرة دون Web3.js.

لكن الاستدعاءات المباشرة قد تكون مطولة وعرضة للأخطاء.

يغلف Web3.js كثيرًا من عمليات JSON-RPC الشائعة في أساليب أبسط.

فبدل إنشاء حمولة JSON-RPC يدويًا لرصيد عنوان، يمكن للمطور استدعاء دالة Web3.js.

يوفر ذلك الوقت ويحسن قابلية القراءة.

لكن المقابل هو وجوب فهم المطورين لما تفعله المكتبة في الخلفية.

عند تصحيح مشكلات الإنتاج، غالبًا ما تكون معرفة طريقة JSON-RPC الأساسية ضرورية.

مخاطر أمان Web3.js

يمكن أن يكون Web3.js آمنًا عند استخدامه بصورة صحيحة، لكنه لا يزيل مخاطر أمان الكريبتو.

الخطر الأول هو كشف المفتاح الخاص.

إذا خزّن المطورون المفاتيح في كود الواجهة الأمامية أو السجلات أو المستودعات العامة أو الخوادم غير المؤمنة، فقد تُسرق الأموال.

الخطر الثاني هو توقيع المعاملات الضارة.

قد يستخدم تطبيق لامركزي Web3.js لتجهيز معاملة لا يفهمها المستخدمون بالكامل.

الخطر الثالث هو عناوين العقود الخاطئة.

قد يؤدي التفاعل مع عقد مزيف أو قديم إلى فقدان الأصول.

الخطر الرابع هو الموافقات غير الآمنة على التوكنات.

قد يوافق المستخدم على إنفاق غير محدود للتوكنات من قبل عقد ضار أو مخترق.

الخطر الخامس هو الثقة في RPC.

قد تعيد نقطة نهاية RPC سيئة أو مخترقة بيانات مضللة أو تفرض رقابة على المعاملات.

الخطر السادس هو مخاطر التبعيات.

تعتمد تطبيقات JavaScript على مديري الحزم والحزم الخارجية، ما قد يخلق مخاطر في سلسلة التوريد.

ينبغي للمطورين تثبيت الإصدارات وتدقيق التبعيات ومراجعة مصادر الحزم ومراقبة التنبيهات الأمنية.

في الكريبتو، قد يتحول خلل برمجي عادي إلى خسارة مالية مباشرة.

Web3.js وسلامة المستخدم

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

قد يطلب تطبيق يستخدم Web3.js الاتصال بمحفظة، أو تبديل الشبكات، أو توقيع رسالة، أو الموافقة على توكن، أو إرسال معاملة.

ينبغي للمستخدمين قراءة طلبات المحفظة بعناية قبل الموافقة على أي شيء.

يكون اتصال المحفظة وحده عادةً أقل خطورة من الموافقة على معاملة، لكنه قد يكشف العناوين والنشاط.

وقد يكون توقيع رسالة آمنًا أو خطيرًا حسب ما يصرح به.

وقد تسمح موافقة التوكن لعقد بنقل التوكنات لاحقًا.

وقد تغيّر المعاملة حالة البلوكشين بصورة دائمة.

لا يحتاج أي تطبيق لامركزي شرعي إلى عبارة استرداد للتفاعل مع Web3.js.

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

Web3.js والاختبار

الاختبار مهم لتطوير Web3.js لأن أخطاء البلوكشين قد تكون مكلفة.

ينبغي للمطورين اختبار تفاعلات العقود على الشبكات المحلية أو شبكات الاختبار أو البيئات المتفرعة قبل استخدام أموال حقيقية.

يمكن لشبكة تطوير محلية المساعدة على اختبار استدعاءات العقود بسرعة.

وقد تساعد شبكة اختبار عامة في اختبار تدفقات المحفظة وسلوك المعاملات في بيئة شبكة أكثر واقعية.

وقد يساعد تفرع الشبكة الرئيسية على اختبار التفاعلات مع العقود المنشورة فعليًا مع تجنب خسارة الأصول الحقيقية.

ينبغي أن تغطي اختبارات Web3.js استدعاءات القراءة ومعاملات الكتابة ومعالجة الأحداث ومعالجة الأخطاء وحالات الشبكة الخاطئة وتوقيعات المحفظة المرفوضة والمعاملات الفاشلة وتعطل RPC.

لا ينبغي للمطورين اختبار المسار السلس فقط.

بل ينبغي اختبار ما يحدث عندما يرفض المستخدمون التوقيعات أو يغيرون الحسابات أو السلاسل أو يفقدون الاتصال أو يرسلون معاملات ترتد.

يحسن الاختبار الجيد الأمن وتجربة المستخدم معًا.

Web3.js والكود القديم

ما زالت كثير من تطبيقات Ethereum القديمة تتضمن كود Web3.js.

قد يستخدم الكود القديم أنماط مزودين أقدم أو أساليب قائمة على callbacks أو إصدارات حزم قديمة أو افتراضات قديمة عن المحافظ.

ينبغي للمطورين الذين يحافظون على هذه الأنظمة توخي الحذر.

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

لا ينبغي استعجال الترحيل دون اختبار لأن تكاملات البلوكشين حساسة.

قد يسبب ترحيل معطل بيانات معاملات خاطئة أو استدعاءات عقود فاشلة أو مخاطر على أصول المستخدمين.

يستحق كود Web3.js القديم صيانة دقيقة بدل النسخ العابر.

Web3.js والترحيل

بسبب إيقاف Web3.js، قد ترحل فرق كثيرة في النهاية الكود القديم إلى مكتبات Ethereum أخرى تحظى بصيانة نشطة.

الترحيل ليس مهمة بحث واستبدال فقط.

قد تتعامل المكتبات المختلفة مع المزودين وقيم BigInt وكائنات العقود ومرشحات الأحداث والتوقيعات والبيانات المكتوبة وتعبئة المعاملات ورسائل الخطأ بشكل مختلف.

ينبغي أن تبدأ خطة الترحيل بحصر جميع حالات استخدام Web3.js في المشروع.

قد تشمل هذه الحالات اتصال المحفظة وقراءة الأرصدة وقراءات العقود وكتابات العقود واشتراكات الأحداث وإيصالات المعاملات وتقدير الغاز وتوقيع الرسائل وأتمتة الخلفية.

ينبغي للفريق بعد ذلك إنشاء اختبارات تثبت السلوك الحالي.

وبعد ذلك فقط، يستبدل الفريق استدعاءات المكتبة ويقارن المخرجات.

ينبغي اختبار الترحيل على الشبكات المحلية وشبكات الاختبار قبل الإنتاج.

لا ينبغي تعريض المستخدمين لتدفقات توقيع جديدة حتى تُراجع بعناية.

في تطوير الكريبتو، تكون مخاطر الترحيل حقيقية لأن فرقًا صغيرًا في الترميز أو التوقيع قد يغير ما تفعله المعاملة.

فوائد Web3.js

الفائدة الأولى لـ Web3.js هي دعم المنظومة التاريخية.

تستخدمه كثير من الدروس والأمثلة وقواعد التعليمات البرمجية الأقدم.

والفائدة الثانية هي وظائف Ethereum الواسعة.

يتضمن Web3.js أدوات للحسابات والعقود والمزودين والأدوات المساعدة والمعاملات والأحداث.

والفائدة الثالثة هي توافق JavaScript.

يمكن لمطوري JavaScript استخدامه في المتصفحات وخدمات الخلفية والنصوص وأدوات المطورين.

والفائدة الرابعة هي تجريد JSON-RPC.

إذ يستطيع المطورون استخدام أساليب أسهل بدل كتابة طلبات JSON-RPC الخام يدويًا.

والفائدة الخامسة هي توافق EVM.

يمكن لـ Web3.js الاتصال غالبًا بكثير من شبكات بأسلوب Ethereum عبر نقاط نهاية RPC.

والفائدة السادسة هي القيمة التعليمية.

يساعد تعلم Web3.js المطورين على فهم المزودين وABIs والغاز والأحداث واستدعاءات العقود.

والفائدة السابعة هي قيمة صيانة الكود القديم.

قد يحتاج المطورون الذين يحافظون على تطبيقات لامركزية أقدم إلى فهم Web3.js بعمق.

قيود Web3.js

القيد الأول هو حالة الإيقاف.

أُرشفت Web3.js في 2025، ولذلك ينبغي للمشاريع الجديدة أن تدرس بعناية ما إذا كانت الخيار الصحيح.

والقيد الثاني هو تعقيد الكود القديم.

قد تستخدم الإصدارات الأقدم والأحدث أنماطًا مختلفة، ما قد يربك المطورين.

والقيد الثالث هو مخاطر التبعيات.

تعتمد تطبيقات الكريبتو بـ JavaScript على أمن الحزم والتحكم الدقيق في الإصدارات.

والقيد الرابع هو الاعتماد على المزود.

تكون موثوقية Web3.js بقدر موثوقية المزود وبنية RPC خلفه.

والقيد الخامس هو مسؤولية واجهة المستخدم.

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

والقيد السادس هو المسؤولية الأمنية.

لا يمنع Web3.js تلقائيًا الموافقات غير الآمنة أو عناوين العقود السيئة أو التصيد الاحتيالي أو كشف المفتاح الخاص.

والقيد السابع هو ضغط الترحيل.

قد تحتاج الفرق التي تستخدم Web3.js إلى تخطيط طويل الأجل للترحيل لأن الدعم النشط في المنظومة قد تحول.

مفاهيم خاطئة شائعة حول Web3.js

من المفاهيم الخاطئة أن Web3.js هو نفسه Web3. Web3 فكرة واسعة للمنظومة، بينما Web3.js مكتبة JavaScript.

ومنها أن Web3.js محفظة. ليس محفظة، رغم أنه يمكنه الاتصال بمزودي المحافظ.

ومنها أن Web3.js يخزن الأموال. فهو لا يخزن الأموال بحد ذاته.

ومنها أن Web3.js يجعل العقود الذكية آمنة. فهو لا يدقق العقود ولا يزيل مخاطر العقود الذكية.

ومنها أن معاملات Web3.js يمكن عكسها. تكون معاملات البلوكشين نهائية عمومًا بعد التأكيد ولا يمكن للمكتبة التراجع عنها.

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

ومنها أن المستخدمين يحتاجون إلى فهم Web3.js لاستخدام التطبيقات اللامركزية. يحتاج المستخدمون أساسًا إلى فهم طلبات المحفظة والموافقات والرسوم ومخاطر المعاملات.

Web3.js ببساطة

Web3.js مكتبة JavaScript للتواصل مع شبكات البلوكشين بأسلوب Ethereum.

تساعد المطورين على الاتصال بالعُقد وقراءة البيانات وإرسال المعاملات والتفاعل مع العقود الذكية.

تستخدم المزودين للوصول إلى شبكات البلوكشين.

وتستخدم ABIs لفهم دوال العقود الذكية.

وتستخدم JSON-RPC في الخلفية.

ويمكن أن تعمل في المواقع والخوادم والنصوص وأدوات التطوير.

وليست بلوكشين أو محفظة أو توكنًا أو لغة عقود ذكية.

كانت مهمة جدًا في تاريخ التطوير المبكر والمتوسط لـ Ethereum.

لكن Web3.js أُرشفت في 2025، ولذلك ينبغي للمطورين التعامل معها بحذر في مشاريع الإنتاج الجديدة.

بالنسبة للمبتدئين، الخلاصة الأبسط هي: Web3.js مجموعة أدوات JavaScript قياسية سابقًا لـ Ethereum ساعدت التطبيقات اللامركزية على التواصل مع البلوكشين، لكنها اليوم مهمة أساسًا للكود القديم والتعلم وسياق الترحيل.

الأسئلة الشائعة

ما هو Web3.js؟

Web3.js مكتبة JavaScript وTypeScript للتفاعل مع Ethereum وغيرها من شبكات البلوكشين المتوافقة مع EVM.

هل Web3.js عملة مشفرة؟

لا، Web3.js ليست عملة مشفرة أو توكنًا.

هل Web3.js بلوكشين؟

لا، Web3.js مكتبة برمجية تساعد التطبيقات على التواصل مع البلوكشين.

هل Web3.js هو نفسه Web3؟

لا، Web3 مفهوم واسع للإنترنت القائم على البلوكشين، بينما Web3.js مكتبة JavaScript محددة.

فيما يستخدم Web3.js؟

يستخدم Web3.js لقراءة بيانات البلوكشين وإرسال المعاملات والتفاعل مع العقود الذكية وإدارة الحسابات وتقدير الغاز والاستماع إلى الأحداث.

هل يعمل Web3.js مع Ethereum فقط؟

لا، يمكن أن يعمل Web3.js أيضًا مع كثير من شبكات البلوكشين المتوافقة مع EVM عبر نقاط نهاية RPC متوافقة.

ما هو المزود في Web3.js؟

المزود هو الاتصال بين Web3.js وعقدة بلوكشين أو محفظة.

ما أنواع المزودين التي يدعمها Web3.js؟

تشمل الأنواع الشائعة HTTP وWebSocket وIPC ومزودي المحافظ المحقونة.

ما هو JSON-RPC في Web3.js؟

JSON-RPC هو API الاتصال الذي يستخدمه Web3.js في الخلفية لإرسال الطلبات إلى عُقد Ethereum.

ما هو ABI في Web3.js؟

ABI واجهة عقد تخبر Web3.js بكيفية ترميز استدعاءات الدوال وفك ترميز بيانات العقد.

هل يستطيع Web3.js توقيع المعاملات؟

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

هل يحمي Web3.js المفاتيح الخاصة؟

لا، يجب على المطورين حماية المفاتيح الخاصة عبر ممارسات آمنة للمحفظة أو الخادم أو إدارة المفاتيح.

هل أُرشفت Web3.js؟

نعم، تنص وثائق Ethereum على أن Web3.js أُرشفت في 4 مارس 2025.

هل ينبغي للمشاريع الجديدة استخدام Web3.js؟

ينبغي للمشاريع الجديدة مراجعة توصيات المنظومة الحالية بعناية لأن Web3.js دخلت مرحلة الإيقاف.

هل ما زالت التطبيقات اللامركزية القديمة تستطيع استخدام Web3.js؟

نعم، قد تظل التطبيقات اللامركزية القديمة تتضمن كود Web3.js، لكن ينبغي للقائمين على صيانتها فهم حالة الإيقاف والتخطيط بعناية للدعم طويل الأجل.

ما أكبر مخاطر استخدام Web3.js؟

تشمل أكبر المخاطر تدفقات المعاملات غير الآمنة وكشف المفاتيح الخاصة ومخاطر التبعيات وسلوك المزود الخاطئ ومخاطر الصيانة طويلة الأجل بعد إيقاف المكتبة.

هل يحتاج المستخدمون Web3.js لاستخدام تطبيق لامركزي؟

لا، لا يثبت المستخدمون Web3.js مباشرةً في معظم الحالات لأن مطور التطبيق اللامركزي يستخدمه خلف الواجهة.

هل يستطيع Web3.js عكس معاملة بلوكشين؟

لا، لا يستطيع Web3.js عكس معاملات البلوكشين المؤكدة.

الخلاصة

Web3.js واحدة من أهم مكتبات JavaScript في تاريخ تطوير Ethereum.

أتاحت للمطورين وسيلة عملية لربط المواقع والنصوص والخوادم والتطبيقات بـ Ethereum وغيرها من شبكات البلوكشين المتوافقة مع EVM.

عبر المزودين، يستطيع Web3.js التواصل مع عُقد البلوكشين عبر اتصالات HTTP أو IPC أو WebSocket.

وعبر ABIs، يمكنه التفاعل مع العقود الذكية.

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

كان دوره مهمًا في منظومة الكريبتو لأن كثيرًا من التطبيقات اللامركزية والدروس وتدفقات عمل المطورين المبكرة اعتمدت عليه.

لكن ينبغي فهم Web3.js في سياقه الحالي.

تنص وثائق Ethereum الرسمية على أن Web3.js أُرشفت في 4 مارس 2025، ويذكر مستودع Web3.js على GitHub أن المكتبات كانت تدخل مرحلة الإيقاف.

وهذا يعني أن Web3.js مهمة الآن بوجه خاص للكود القديم والفهم التاريخي والتخطيط للترحيل.

ينبغي للمطورين الذين يحافظون على مشاريع Web3.js مراجعة الإصدارات والمزودين وتدفقات المعاملات وأمن التبعيات ومعايير المحافظ وخيارات الترحيل بعناية.

وينبغي للمطورين الذين يبدؤون مشاريع جديدة تقييم خيارات المكتبات الحالية واحتياجات الصيانة طويلة الأجل قبل اختيار مكتبة عميل للبلوكشين.

بالنسبة للمستخدمين، النقطة الأساسية أبسط.

Web3.js ليس شيئًا يشترونه أو يحتفظون به.

إنه جزء من طبقة برمجية تساعد التطبيقات اللامركزية على التواصل مع البلوكشين.

والطريقة الأكثر أمانًا لفهم Web3.js هي اعتباره مجموعة أدوات JavaScript قوية وناضجة تاريخيًا لـ Ethereum ساعدت في بناء Web3، بينما ينبغي للمشاريع الحديثة الآن مراعاة حالة إيقافه وتطور منظومة المطورين.