كتب Ingamar في ١٩ ديسمبر ٢٠٢١

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

1- بطئ التطبيقات اللامركزية. 

تظوير برمجيات لويب ٣ Web3 مازال بطي للغاية، خاصة عند مقارنتها بـالويب ٢ Web2. في Web2، تم تحميل وتشغيل برمجيات التطبيق المعقدة إلى خوادم مركزية. على سبيل المثال: عندما يقوم المستخدم بارسال تويت – تغريدة، يقوم برنامج تويتر ببساطة بتقديم طلب إلى واجهة برمجة تطبيقات خوادم تويتر الذي ينشر تغريدة بالنيابة عن المستخدم. هذا يمكّن التطبيقات من أن تكون غير معقدة ودمج عشرات من واجهات برمجة التطبيقات بسلاسة. لكن في الويب ٣ Web3، تتعامل التطبيقات مع هذا المنطق المعقد بنفسها، لأنه تم استبدال الخوادم المركزية بشبكات النظراء P2P و عقود ذكية ذات تكلفة تشغيل مرتفعة.

من أجل دمج بروتوكولات الويب ٣ Web3 في التطبيقات بسرعة، يقوم مطوري البروتوكول باتاحة SDK حزم برمجيات لاستخدامها من قبل مطوري التطبيقات. تتطلب هذه العملية الكثير من الوقت والطاقة، سواء من مطور البروتوكول أو مطور التطبيق. من أجل فهم السبب في أن حزم البرمجيات SDK هذه مطلوبة، و لماذا تستهلك وقتا طويلا للتطوير، يجب أن نفهم أولاً في حدود القدرات التي قد يرغب تطبيق الويب ٣ Web3 النموذجي في إستخدامها. عند بناء تطبيق dApp (تطبيق لا مركزي)، غالبا أنت لا تتعامل فقط مع العقود الذكية. تطبيقات Web3 غالبا ما تحتوى على مجموعة متنوعة من القدرات، مثل: أرسال الرسائل بين الافراد بشكل مباشر، تخزين الملفات لا مركزيا إنتاج توقيعات مشفرة وإثباتات للتعاملات، التفاعل مع المتواليات side blockchains الجانبية، وأشياء اخرى كثيرة. كما نرى ، فإن بناء تطبيق يعمل على شبكة الويب ٣ ليس بسيطا ككتابة كود يتفاعل مع نقطة واجهة تطبيقات واحدة على خادم مركزى. وفيما يلي بعض الأمثلة على حزم بيرمجيات الويب ٣:.

عند كتابة الكود، يجب أن تكون جميع التغييرات التى تتم ناحية البنية التحتية backend مدمجة يدوياً بالكامل مع واجهة التطبيق الأمامية frontend. قد تحتاج أيضا إعادة نشر حزمة تحتوي على جميع عناوين التى يستخدمها العقد الذكى على الشبكة onchain addresses، وتعديل ونشر الإصدار الجديد من Javascript SDK، وأخيراً، دمج هذه الحزم الجديدة في تطبيق الخاص بك أثناء نشر ذلك أيضاً. عملية التطوير هذه تختلف كثيرا عما اعتاد عليه مطوري الويب ٢. عادة، هم قادرون على إجراء التغييرات فى كود البنية التحتية backend وجعلها تنعكس تلقائياً في كود واجهة التطبيق الامامية، طالما لم يحدث تغيير فى كود واجهة البرمجة التى تتعامل معها API.

2. ويب ٣ ليس قاعدة متعددة Web3 is not Multi-Platform

ويب ٣ ليس قاعدة متعددة. مكن ويب٣ Web3 من انتاج الكثير من الابتكارات المذهلة من خلال تطبيقات جافا سكريبت التي تعمل على المتصفح. لكن، عالم البرمجيات أكبر بكثير من المتصفح. يجب أن ننظر الى التطبيقات الاخرى مثل: تطبيقات الهاتف المحمول، برمجيات الخوادم، ألعاب الفيديو، و تطبيقات انترنت الأشياء IoT. في جميع تلك الحالات، عادة ما تكون جافا سكريبت JavaScript ليست اللغة المفضلة. ويرجع هذا في المقام الأول إلى أن المترجم البرمجي للجافاسكريبت ثقيل جدا ومعقد لمحاولة استتخدامه خارج المتصفح. من أجل جلب ويب ٣ Web3 لهذه البيئات البرمجية المختلفة، يقوم المطورين بالفعل بإنشاء وتطير العديد من حزم تطوير برمجيات مناسبة SDK. على سبيل المثال، يمكنك العثور على حزمة تطوير البرمجيات لنظام تخزين الملفات غير المركزي IPFS SDK في اللغات البرمجية التالية

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

3. البروتوكولات قابلة للتمديد ، بينما dApps ليست كذلك

إذاً كيف يتحرك النظام الإيكولوجي في الوقت الحالي؟ حاليا،يمكننا أن ننشر ملحقات للبروتوكولات. ومن الأمثلة العظيمة على ذلك ما يلي:

Aragon و Yearn – هي مجموعة من المنتجات تخدم الاسواق اللامركزية (DeFi) التي توفر تجميع الإقراض وتوليد العائد والتأمين على شبكة ايثيروم . في Yearn، يمكنك نشر استراتيجيات جديدة , إضافتها إلىالخزانة بناء على بروتوكول التوافق. الجانب السلبي هو أن التطبيق لا يقوم بتحديث ديناميكي متزامن مع التفاصيل عن كيفية عمل الاستراتيجية. في سيناريو مثالي، سيسمح تطبيق مخزن لأي مستخدم باختيار استراتيجية، ومراجعة ميكانيكيه عملها، والتفاعل مع عناصر تشغيلها . ولكن في الواقع يتم القيام بذلك خلف الكواليس من قبل مجموعة صغيرة من المشرفين والمهتمين.

في حالة Aragon، يمكن للمطورين نشر اجزاء جديدة للبروتوكول على متوالية (سلسة الكتل) Aragon، ولكن نفس السيناريو يكرر نفسه حيث

التطبيق من جانب العميل لا يتم تحديثه بشكل ديناميكي لدعم الوظيفة الجديدة التي تم اضافتها. على سبيل المثال، إذا قام مطور بإنشاء عقد “ذكي” جديد تصويت-رباعي، ونشره على المتوالية (سلسة الكتل) ، سيكون شيئا رائعا إذا كان تطبيق Aragon  قادرا على عرض واستخدام ذلك العقد تلقائيًا (طالما أنه يتقيد بـواجهة قياسية). السبب الأساسي لعدم إمكانية هذا هو أوجه عدم الأمن (ثغرات أمنية) في الجافاسكريبت. من أجل جعل التطبيق يقوم بتنفيذ الكود الموصوف أعلاه، ستحتاج إلى حقن كود (برمجيات) جديدة ديناميكيا داخل التطبيق. هذا غير آمن على الإطلاق في عالم جافا سكريبت. 

ولكن هناك طرق لحل ذلك من خلال الاستفادة من شيء مثل WebAssembly، حيث من السهل جدا إنشاء وحدة VM جديدة و آمنة. هذا يسمح بحقن آمن للكود، وهذا بدوره يمكن تحديث ديناميكي ناحية تطبيق العميل.

4. تكاليف القابلية لتراكيب المكونات (البرمجية)

ما هي التكاليف المرتبطة بقدرة ويب٣ Web3 على التراكيب للمكونات البرمجية؟ من أجل فهم هذا، يجب أن نتذكر حقيقة أن دمج بروتوكولات ويب ٣ Web3 يتطلب استخدام SDK ناحية تطبيقات العميل. مع إضافة كل بطاقة SDK جديدة، يزداد حجم التطبيق. بالإضافة إلى تضخم التطبيق، غالباً ما تكون لل SDK تبعيات متضاربة، مما يؤدي إلى عدم التوافق والكثير من الصداع. وهذا يعني أنه يوجد في الواقع حد أعلى لعدد التكاملات التي يمكن أن يقوم بها التطبيق. هذا الوضع مختلف تماما عن نموذج “الخدمات المصغرة” microservices المستخدمة في ويب ٢, حيث يمكن الوصول الي أية وظيفة متاحة في واجهة برمجة التطبيق من خلال HTTP request. في Web3، يجب أن يكون كل شيء شفاف وواضح، ومتوافق، ويمكن إعادة استخدامه. هذا هو جمال وروح المصدر المفتوح. إذا طبقنا هذا التفكير هنا، نود أن نتخيل مستقبلا حيث يستخدم تطبيق ويب ٣ العادي Web3 عشرات التكاملات، ولكن هذا يبدو مستبعد إذا استمر الوضع علي ما هو عليه من طريقة الاعتماد علي SDKs من جانب تطبيق العميل

5. وظائف جافاسكريبت الأساسية غير الآمنة

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

التحسينات القادمة لتطوير الويب 3

هناك مشروع الآن يهدف إلى جلب تجربة التطوير في ويب ٢ Web2 إلى ويب Web3 بطريقة لامركزية تماما. Web3API يهدف إلى تقديم حل واحد يمكن أن يساعد في معالجة كل هذه المشاكل. سيسمح Web3API لمطوري التطبيقات اللامركزية dApp بدمج أي بروتوكول ويب ٣ Web3 من خلال GraphQL، وهي لغة استعلام تستخدم على نطاق واسع لمطوري ويب ٢ Web2. سيسمح لك بتجميع العشرات من البروتوكولات في التطبيق اللامركزي dApp دون زيادة حجم التطبيق، وتوفير القدرة على التفاعل مع ويب٣ Web3 بأي لغة برمجة من خلال امكانيات WebAssembly (Rust, J Python, Go, C,C#).