تعمل التطبيقات اللامركزية dApps على تحويل المشهد الإلكتروني من خلال توفير إمكانية استقلالية المستخدمين وتعزيز الأمان والشفافية في المعاملات التي تتم بينهم. بخلاف التطبيقات التقليدية التي تعتمد على الخوادم المركزية، يتم بناء التطبيقات اللامركزية (بشكل جزئي أو كلي) على التقنية اللامركزية. في هذا المقال، سوف نكتشف الهيكلية الكاملة full stack للتطبيقات اللامركزية dApps، والتي تشمل الواجهات الأمامية والاستضافة، المحافظ اللامركزية، العقود الذكية، الدخول إلى الأجهزة المشاركة nodes، تخزين البيانات، والمكونات المحتملة الأخرى.
لا شك أن كل طبقة من هذه الطبقات تحتاج إلى مقال كامل لشرحها، ولكن سوف نحاول اختصار الصورة الكاملة بشكل شامل.
الواجهات الأمامية
الواجهة الأمامية (العميل) هي واجهة المستخدم UI للتطبيق اللامركزي. مثلها مثل التطبيقات المركزية المعروفة حيث أنها غالبًا ما يتم بنائها باستخدام تقنيات الويب الشائعة مثل HTML، CSS و JavaScript. كما يشاع استخدام أطر العمل مثل React وAngular وكذلك Vue.js لإنشاء واجهة مستخدم قابلة للاستجابة الديناميكية.
يجب على واجهة المستخدم بطريقة أو بأخرى التواصل مع backend. ولهذا السبب لا بد من الاتصال مع nodes من خلال المكتبات. أكثر مكتبات javascript المشهورة هي Web3.js وEther.js كما أن هناك مكتبات مشهورة أخرى مبنية على البايثون مثل web3.py.
على أي حال، تعتبر مكتبات الجافا سكريبت أكثر شيوعًا ووفرة من مكتبات البايثون خصوصًا تلك التي تدعم React. وبشكل عام، توفر هذه المكتبات الأدوات للتعامل مع منطق الواجهات الأمامية، بما فيها التوقيع على المعاملات، استرجاع معلومات الحساب، إدارة محفظة Web3، والكثير.
علاوة على ذلك، تتطلب dApps أيضًا من الواجهة الأمامية الاتصال مع أجهزة البلوكتشين nodes قبل إرسال طلبات إلى الواجهة الخلفية backend، والتي تتألف من العقود الذكية التي يتم تنفيذها على السلسلة. وعلى الرغم من أن تشغيل جهاز البلوكتشين عن طريق المستخدم نفسه قد يقلل الاعتماد على أي مزود خدمة، إلا أنه يتطلب الكثير من الموارد. لذلك تعمل مزودات مثل Alchemy، QuickNode، Tatum، Ankr أو Infura على توفير حلول مناسبة.
الاستضافة
تعود الاستضافة إلى عملية حفظ وتشغيل ملفات التطبيق، مما يسمح للمستخدمين للدخول والتفاعل معها عبر الإنترنت. تقليديًا، تتكون الاستضافة المركزية من خادم واحد أو عدة خوادم متضامنة مسؤولة عن خدمة محتوى التطبيق. يعتمد هذا النهج عمليًا على سلطة مركزية، وهي مزود خدمة الاستضافة. الأغلبية العظمى للتطبيقات المركزية هذه الأيام تستخدم الاستضافة المركزية، ما يخلق نقطة فشل مركزية محتملة بالإضافة إلى تهديدات أخرى لا يتسع المجال لذكرها.
على الطرف الآخر، تعد استضافة التطبيقات اللامركزية مختلفة عن المركزية من خلال توزيع ملفات التطبيق عبر شبكة من الأجهزة المنتشرة والتي تُدعى nodes، وتساهم كل منها في تقديم خدمات التخزين وتوفير عرض النطاق الترددي bandwidth، كما يمكن استخدام حلول مثل IPFS وكذلك Swarm لدعم عمليات الاستضافة.
المحافظ
يتم استخدام المحافظ لإدارة الأصول الرقمية للمستخدمين، التحقق من المستخدمين والتوقيع على المعاملات على البلوكتشين. في مفهوم dApps، تعمل المحافظ على حفظ المفاتيح الخاصة للمستخدمين وتسهيل المعاملات مع العقود الذكية الأساسية. هناك الكثير من الآراء المختلفة عن أفضل نوع محافظ تعطي تجربة مستخدم معقولة، حيث يجب أن تتمتع بإمكانية دخول سهلة مع عدم إهمال توفر أمان عالٍ للمستخدمين (لسوء الحظ هناك عدد كبير من الجهات الفاعلة السيئة التي تحاول سرقة المفاتيح الخاصة والوصول إلى المحافظ من خلال الهندسة الاجتماعية).
هناك نوعان مختلفان من المحافظ: النوع الأول عبارة عن محافظ مبنية على المتصفح، بينما الأخرى محافظ يمكن إضافتها كأداة إضافية إلى المتصفح، أما من ناحية الخصائص هناك تصنيفان، التصنيف الأول محافظ تُدعى custodial والآخر يُطلق عليها non-custodial.
بعض المتصفحات، مثل Brave أو Opera، تأتي مع محافظ مبنية معها حيث تسمح للمستخدمين لإدارة أصولهم الرقمية والتفاعل مع التطبيقات اللامركزية بشكل مباشر مع المتصفح. كما أثارت شركة مايكروسوفت بأنها سوف تطلق محفظتها اللامركزية المبنية على متصفحها الخاص Edge. أما النوع الآخر وهي المحافظ المضافة إلى المتصفح، مثل MetaMask و Trust Wallet، عبارة عن وظائف إضافية منفصلة يمكن للمستخدمين تثبيتها في المتصفح المفضل لديهم. عمليًا، تعتبر هذه المحافظ أكثر تنوعًا وتدعم مدى أكبر من العملات المشفرة المرتبطة بشبكات البلوكتشين.
تعتبر المحافظ المبنية على المتصفحات محدودة في عدد شبكات البلوكتشين التي تدعمها، بينما تكون المحافظ المضافة إلى المتصفح عادة أكثر عرضة للهجمات مثل التصيد الاحتيالي phishing.
أما من ناحية خصائص المحفظة، فتتم إدارة custodial wallets من خلال طرف ثالث مزود للخدمة، حيث تعمل على تعزيز التحكم في المفاتيح الخاصة للمستخدمين. يدخل المستخدمون إلى المحفظة من خلال منصات مزود الخدمة، ويعتمدون عليهم في التأمين وإدارة الأصول. بينما تعمل المحافظ ذات الخاصية non-custodial على منح المستخدمين التحكم الكامل على مفاتيحهم الخاصة، مما يسمح لهم بإدارة أصولهم الرقمية دون الاعتماد على طرف ثالث. عادة ما يتم استخدام المحافظ من نوع non-custodial للتعامل مع التطبيقات اللامركزية، حيث يجب على المستخدمين إدارة المفاتيح الخاصة بأنفسهم. كما أن هناك أكثر من نهج مختلف لمحافظ non-custodial مثل Magic و Argent وكذلك Metamask.
أجهزة الشبكة (Nodes)
تعتبر nodes خوادم مستقلة تشارك في شبكة البلوكتشين من خلال التحقق من صحة وموثوقية المعاملات. وللتفاعل مع التطبيقات اللامركزية (dApp)، يجب على واجهة العميل أن تتصل مع node بداخل الشبكة. على أي حال يمكن للمستخدمين أيضًا التفاعل مع dApps بشكل مباشر عبر node أو من خلال عقد ذكي آخر! هذا يعني أن الواجهة الأمامية الخاصة بك ليست الطريقة الوحيدة لتفاعل المستخدمين مع الواجهة الخلفية backend إذا كانت العقود الذكية يتم تنفيذها على شبكة البلوكتشين العامة.
علاوة على ذلك، تعمل الخدمات مثل Alchemy وQuickNode على توفير الدخول لخوادم nodes بعيدة، مما يسمح للمطورين التركيز على بناء تطبيقاتهم اللامركزية دون الاكتراث للبنية التحتية. كما يعد Chainstack حلًا قابلًا للتطبيق إذا أردنا استخدام node مخصصة دون الحاجة لإدارتها. بدلًا من ذلك، يمكن للمطورين تشغيل خوادمهم التي يمتلكونها باستخدام برمجيات مثل Geth للإيثيريوم أو Solana's Validator لشبكة Solana.
تدعم nodes عمليات القراءة والكتابة. لذا إذا كان التطبيق يسمح فقط بقراءة البيانات من البلوكتشين فلن يكون هناك رسوم يجب دفعها لتنفيذ المعاملات، أما إذا كان التطبيق يدعم عمليات الكتابة فإن التطبيق يحتاج إلى دفع رسوم تُدعى gas fees.
العقود الذكية
تُعرف العقود الذكية بأنها العمود الفقري لأي تطبيق لامركزي، حيث تسمح للكتابة والقراءة من البلوكتشين. تتم كتابة العقود الذكية باستخدام لغات برمجية مثل solidity للإيثيريوم و Rust لسولانا، كما تعمل على تعريف المنطق والقوانين التي تحكم عمليات التطبيق اللامركزي. عمليًا، بمجرد نشر العقود الذكية، فإن الكود لن يكون قابلًا للتعديل، مما يقودنا إلى بعض الصعوبات عندما نرغب بإصلاح الثغرات أو إضافة خصائص جديدة. على أي حال، تحاول بعض العقود المطورة والتي تُدعى proxy التعامل مع هذه المشكلة عن طريق عزل منطق العقد عن تخزين بيانات العقد. حيث تحتوي هذه العقود على مكونين رئيسيين (بشكل أساسي عقدين ذكيين أو أكثر).
تلعب proxy contract دور الوسيط، يرسل الطلبات الواردة إلى منطق العقد بينما يحافظ على حالة العقد. يبقى هذا العقد غير قابل للتعديل خلال عمليات التطوير. حيث يحتوي منطق العقد على الكود الحقيقي ومنطق العمل للتطبيق، ويمكن للمطورين في هذه الحالة نشر نسخة جديدة من العقد المنطقي وتحديث عقد proxy للوصول إلى المنطق الجديد، مما يسمح بالتحديث دون التأثير على بيانات العقد.
بالإضافة إلى ذلك، يمكن أن يقوم التطبيق اللامركزي باستخدام العقد الذكي الذي تم تطويره داخليًا ولكن يتصل أيضًا مع العقود الذكية (البروتوكولات) التي تم تطويرها من الآخرين. على سبيل المثال، قام التطبيق اللامركزي الشهير 1inch بتطوير عقود ذكية للتعامل مع العقود الذكية لمختلف منصات التحويل اللامركزية مثل Uniswap و Sushiswap.
علاوة على ذلك، لا يمكن أن يتفاعل العقد الذكي الذي يتم نشره على سلسلة واحدة (مثل الإيثيريوم) ببساطة مع عقد ذكي تم نشره على سلسلة أخرى (مثل Polygon). لذلك، سيساعدنا دعم السلاسل المتعددة في خدمة جمهور أكبر من المشاركين كما يمكن أن يجلب خصائص متقدمة مثل zero knowledge proofs أو تسريع عمليات إنجاز المعاملات. الطريقة الوحيدة للتفاعل بين السلاسل هي من خلال تطبيق التجسير bridges مثل Wormhole أو بروتوكولات التشغيل البيني مثل Cosmos للتطبيق اللامركزي.
حلول الفهرسة
تلعب حلول الفهرسة دورًا محوريًا في أنظمة التطبيقات اللامركزية وذلك من خلال جعل بيانات البلوكتشين أكثر قابلية للدخول والاستعلام.
مع كبر حجم البلوكتشين وتعقيدها، تتناقص سرعة الحصول على معلومات محددة بشكل مباشر من السلسلة وترتفع تكلفة المصادر المستخدمة لها. تعمل حلول الفهرسة على حل هذه المشكلة من خلال إنشاء بنية قواعد بيانات مفهرسة تعمل على تمكين استدعاء البيانات بشكل سريع وأكثر نجاعة. توفر معظم حلول الفهرسة تزامنًا للبيانات في الوقت الحقيقي، مما يضمن أن تقوم التطبيقات اللامركزية بإعلامنا على الفور عند حدوث الأحداث ذات الصلة. هذا يسمح للتطبيقات اللامركزية بتشغيل الإجراءات بشكل مباشر للاستجابة للأحداث التي تتم على السلسلة بسرعة ودقة.
أحد الحلول الأكثر شهرة هو The Graph، والتي هي عبارة عن بروتوكول فهرسة لامركزي، لتطوير الرسوم البيانية الفرعية. على أي حال، العديد من موفري الخوادم nodes مثل QuickNode يقدمون ميزات الفهرسة اليوم.
تخزين البيانات
على الرغم من أن البلوكتشين مناسبة لحفظ بيانات التعاملات، إلا أنها ليست ناجحة لحفظ بيانات ذات الحجم الكبير، وذلك بسبب مشاكل التوسع والتكلفة التي تعاني منها. عادة ما يتم استخدام حلول التخزين اللامركزية مثل IPFS أو Filecoin لحفظ بيانات التطبيقات اللامركزية خارج السلسلة، مما يوفر خيارات حفظ أكثر نجاعة وأقل في التكلفة. توفر هذه الخدمات خصائص التشفير والمشاركة لضمان سلامة وخصوصية البيانات. كما يمكن استخدام مكونات تخزين البيانات المركزية عند بناء التطبيقات اللامركزية، ولكنها لن تكون لامركزية أبدًا (وذلك بنفس طريقة الاستضافة التي ناقشناها سابقًا).
الأوراكل
تعمل العقود الذكية على تنفيذ منطق تم تعريفه سابقًا على معلومات متوفرة بداخل شبكة البلوكتشين. على أي حال، تتطلب العديد من حالات الاستخدام بيانات من مصادر خارجية (مثل الطقس، أسعار الأسهم، أو نتائج المباريات الرياضية) لتعمل بشكل فعال. حيث تعمل الأوراكل على سد هذا الاحتياج من خلال توفير بيانات خارج السلسلة إلى العقود الذكية. هناك بعض الأوراكل الشائعة مثل Chainlink و UMA.
الخلاصة
تتألف النظرة الشاملة للتطبيقات اللامركزية من العديد من الطبقات والمكونات، كما أن هناك عددًا من المنهجيات المختلفة التي يمكن أن يتم تطبيقها في المستقبل القريب. كما تعمل هذه النوعية من التطبيقات على تحويل مشهد الإنترنت من الاحتكار إلى التوافر، وكذلك تساهم في حفظ حقوق المستخدمين من خلال ربط أصولهم الرقمية بالمحافظ اللامركزية الخاصة بهم، دون اللجوء إلى الأنظمة المركزية.
استعرض هذا المقال البنية والهيكلة التي يتم بناء التطبيقات اللامركزية من خلالها، حيث تعتمد هذه التطبيقات على شبكة البلوكتشين في أدائها وأعمالها. تتألف هذه النوعية من التطبيقات على Frontend والتي يتم عادة صناعتها بنفس طريقة صناعة التطبيقات المركزية التقليدية. أما backend فهي تحتوي على مجموعة من الأجهزة اللامركزية المبنية على شبكة البلوكتشين وتحكمها خوارزميات الإجماع في أدائها. كما عرض هذا المقال طرق استضافة التطبيقات اللامركزية، حيث يجب استضافتها من خلال أنظمة لامركزية تناسب طبيعة عملها. كما شرح أنواع المحافظ اللامركزية وطرق استخدامها، ثم وضّح وبيّن ماهية العقود الذكية وأجهزة Node، وانتهى هذا المقال ببيان حلول الفهرسة وتخزين البيانات في التطبيقات اللامركزية.