التطبيقات اللامركزية (dApps): شرح مبسط للمبتدئين

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

قد يبدو هذا التحول بسيطًا، لكنه يغير من يتحكم في ماذا، ويغير أيضًا مكان تركز المخاطر.

• ما هي الـ dApp؟ هي تطبيق يعتمد في منطقه الأساسي على العقود الذكية التي تعمل على شبكة البلوكتشين.
• ما الذي تغيره؟ يمكن للمستخدمين التفاعل مع الأسواق، والألعاب، والمنظمات اللامركزية المستقلة (DAOs)، وأدوات التمويل اللامركزي مباشرةً من محافظهم الرقمية.
• المخاطر الرئيسية. قد تؤدي الموافقات الخاطئة، والواجهات الأمامية المزيفة، والعقود الذكية المعيبة إلى تعريض أموال المحفظة للخطر.

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

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

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

عادةً ما تشترك الـ dApps في بعض الخصائص:

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

عند استخدامك لـ dApp، فإنك تتعامل مع أربعة مكونات منفصلة: واجهة الموقع الإلكتروني أو التطبيق، المحفظة، العقد الذكي، وشبكة البلوكتشين. لكل مكون وظيفة مختلفة، وفهم هذا الفصل هو أسرع طريقة لاستيعاب أين يمكن أن تحدث المشاكل.

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

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

من المهم فهم هذه الأجزاء المتحركة بوضوح، لأن الـ dApps قد تكون مربكة في البداية:

• الواجهة الأمامية (frontend) هي الصفحة أو التطبيق الذي تنقر عليه.
• تحفظ المحفظة مفاتيحك وتقدم طلبات للموافقة عليها أو رفضها.
• يتحقق العقد الذكي من الإجراء ويحدّث سجلاته.
• ترتب الشبكة المعاملات وتفرض الرسوم.
• يساعد المؤشرون (Indexers) ومقدمو خدمة RPC الواجهة على قراءة البيانات من السلسلة.

بالنسبة للمستخدمين، الدرس العملي هو: الشاشة ليست مصدر الحقيقة. المعاملة الموقعة هي كذلك.

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

هذه المقايضة لها جانبان؛ فبينما تتيح تطبيقات dApp رؤية الأرصدة والقواعد على دفتر أستاذ عام وشفاف، فإنها تضع مسؤولية أكبر على عاتق المستخدم. فإذا قامت محفظتك بتوقيع معاملة ضارة، فإن البلوك تشين تسجلها كما هي تمامًا دون إمكانية للتراجع، ولا يوجد هنا ما يُعرف بـ “تذكرة دعم فني” لحل المشكلة.

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

تُستخدم الـ dApps في مجموعة واسعة من التطبيقات، مثل التداول والإقراض والألعاب والـ NFTs والـ DAOs والأدوات الاجتماعية وأسواق التنبؤ. القاسم المشترك بينها هو سبب محدد لاستخدام تقنية البلوكتشين بدلاً من قاعدة بيانات حسابات عادية، سواء كان ذلك للحضانة المشتركة، أو القواعد الشفافة، أو الملكية القابلة للتحويل.

تُعد التمويل اللامركزي (DeFi) الفئة الأكبر من حيث الوعي العام، حيث يقوم المستخدمون بالتداول والإقراض والاقتراض وتوفير السيولة عبر العقود الذكية بدلاً من سجل وسيط داخلي. يقوم التبادل اللامركزي (DEX) بتوجيه عمليات المقايضة عبر مجمعات السيولة أو منطق الطلبات الآلي بدلاً من دفتر أوامر مركزي. تُعد بروتوكولات مثل Uniswap و Aave من بين الأمثلة الأكثر شيوعًا، لأن منطق عقودها عام ويعمل منذ فترة كافية لدراسته بعمق.

خارج عالم DeFi، تتفرع الفئات بسرعة. تضع تطبيقات الألعاب اللامركزية (dApps) الأصول أو ملكية العناصر أو المكافآت داخل اللعبة على السلسلة، بحيث يمتلكها اللاعبون فعليًا. تنسق تطبيقات DAO عمليات التصويت وقرارات الخزانة ووصول المساهمين عبر العقود الذكية. تتعامل تطبيقات NFT مع سك العملات الرقمية غير القابلة للاستبدال، والتداول، والعضوية، وملكية الوسائط. تتخذ أسواق التنبؤ الرائدة نهجًا مختلفًا: فبدلاً من تداول الأصول، يتداول المستخدمون المراكز بناءً على نتائج الأحداث، مع قيام العقد بتسجيل وتسوية تلك المراكز على السلسلة. يُعد Polymarket المثال الأكثر استخدامًا في هذه الفئة.

تشمل فئات الـ dApp الشائعة ما يلي:

• تطبيقات DeFi للمقايضات، والإقراض، والاقتراض، والمشتقات، وزراعة العائد.
• تطبيقات الألعاب التي تضع الأصول أو المكافآت أو ملكية العناصر على السلسلة.
• تطبيقات DAO التي تنسق التصويت، وقرارات الخزانة، ووصول المساهمين.
• تطبيقات NFT لسك العملات الرقمية غير القابلة للاستبدال، والتداول، والعضوية، أو ملكية الوسائط.
• تطبيقات أسواق التنبؤ التي تتيح للمستخدمين تداول نتائج الأحداث.
• التطبيقات الاجتماعية التي تخزن الهوية، وروابط المحتوى، أو وصول المبدعين على السلسلة.

ليست كل الـ dApps مالية. فأدوات DAO، وألعاب البلوكتشين، والتطبيقات الاجتماعية على السلسلة، كلها تستخدم المحافظ والعقود الذكية، لكنها تعرض مخاطر مختلفة تمامًا وتتطلب عادات مختلفة من المستخدمين.

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

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

بالإضافة إلى هاتين الشبكتين، تُشغل شبكات الطبقة الثانية (Layer 2) تطبيقات بأسلوب Ethereum برسوم أقل، لكنها تُضيف اعتبارات خاصة بالجسور وعمليات السحب. أما السلاسل الخاصة بالتطبيقات (App-specific chains) فتوفر تجربة مستخدم أكثر تخصيصًا، ولكنها تعتمد بشكل أكبر على السيولة ودعم المحافظ الخاصة بنظامها البيئي.

يعتمد اختيار المحفظة على الشبكة المستخدمة. غالبًا ما يبدأ مستخدمو Ethereum بمحافظ المتصفح المتوافقة مع EVM مثل MetaMask، بينما يبدأ العديد من مستخدمي Solana بمحفظة Phantom Wallet. يمكن للمحفظة متعددة السلاسل أن تقلل من صعوبة التبديل بين الشبكات، لكنها لا تلغي الحاجة إلى قراءة كل طلب توقيع بعناية قبل الموافقة عليه.

يمكنك الاطلاع على مراجعتنا لمحفظة MetaMask ومراجعة Phantom Wallet قبل اتخاذ قرارك النهائي!

عند ربط محفظة بتطبيق لامركزي (dApp)، فإنك تشارك عنوانك العام معه. هذا الإجراء بحد ذاته لا ينقل الأموال. تبدأ المخاطر عندما تطلب المحفظة منك توقيع رسالة، أو إرسال معاملة، أو الموافقة على إنفاق الرموز، وهذا هو الجزء الذي يربك معظم المبتدئين.

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

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

قبل الربط، تأكد من فهم هذه الإجراءات جيدًا:

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

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

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

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

قد تنشر الـ dApp كود عقدها ومع ذلك تظل واجهتها مربكة. يمكنها العمل على شبكة مفتوحة ومع ذلك تعتمد على واجهة أمامية مركزية. يمكن أن تكون غير احتجازية (non-custodial) ومع ذلك تُنشئ مخاطر موافقة إذا منح المستخدمون أذونات واسعة للرموز دون قراءة ما وقّعوا عليه.

تتركز معظم مخاطر تطبيقات dApp في لحظة حاسمة واحدة: عندما تطلب منك المحفظة الموافقة على إجراء ما. تقوم مواقع التصيد الاحتيالي (Phishing) بنسخ تصميم تطبيقات dApp الحقيقية وتستخدم نوافذ منبثقة مزيفة للمحفظة لطلب موافقات واسعة النطاق على الرموز (token approvals). حتى الواجهة الأمامية لتطبيق dApp حقيقي يمكن اختراقها، لتقديم طلبات ضارة عبر عنوان URL شرعي.

غالبًا ما لا تكون لحظة الاتصال الأولى هي الأكثر خطورة. بل هي الموافقة على الرمز (token approval) التي تمنح العقد إذنًا مستمرًا بإنفاق أصولك. يبقى هذا الإذن نشطًا حتى بعد إغلاق علامة التبويب، وقطع الاتصال بالموقع، ونسيان وجود تطبيق dApp.

قبل التوقيع، اتبع هذه الإجراءات الوقائية:

• تأكد من صحة النطاق (domain) من خلال إشارة مرجعية (bookmark) أو مصدر موثوق، وليس من رابط في نتائج البحث.
• تحقق من أن المحفظة متصلة بالشبكة الصحيحة قبل الموافقة.
• اقرأ اسم الرمز والمبلغ المعروضين في المطالبة.
• ارفض الموافقات غير المحدودة إذا كان حد أدنى يغطي الإجراء المطلوب.
• اختبر تطبيقات dApp غير المألوفة باستخدام محفظة صغيرة تحتوي فقط على ما تحتاجه.
• قم بإلغاء الموافقات القديمة بعد الاستخدام، واعتبر ذلك صيانة روتينية.
• تعامل مع روابط الإنزال الجوي (airdrop) أو سك العملات (mint) أو الدعم العاجلة على أنها مشبوهة بشكل افتراضي.

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

تقلل عمليات تدقيق الأمان والفرق العلنية من المخاطر لكنها لا تقضي عليها تمامًا. الروتين الأكثر أمانًا لتطبيقات dApp هو الذي يمكنك تكراره دون تفكير: احفظ عناوين URL المعروفة في الإشارات المرجعية، واحتفظ بأموالك طويلة الأجل في محفظة منفصلة، وتوقف عندما تطلب أي مطالبة وصولاً أكثر مما يتطلبه الإجراء المحدد.

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

على شبكة Ethereum، يبدأ تطوير تطبيقات الـ dApp عادةً بعقود Solidity، وأطر الاختبار، وواجهة ويب أمامية، ومكتبات المحفظة التي تتعامل مع طلبات التوقيع. أما على شبكة Solana، فيقوم المطورون بكتابة برامج تعمل مع الحسابات والتعليمات بدلاً من تخزين العقود بأسلوب Ethereum.

يتضمن مكدس تطبيقات الـ dApp النموذجي ما يلي:

• العقود الذكية أو البرامج على السلسلة للقواعد الأساسية والتسوية.
• واجهة أمامية تعرض الأرصدة والنماذج ومعاينات المعاملات.
• مكتبات اتصال المحفظة التي تطلب التوقيعات من المستخدم.
• مقدمو خدمة RPC لقراءة حالة السلسلة وإرسال المعاملات.
• الفهارس (Indexers) لتسريع البحث وسجل المعاملات.
• التخزين اللامركزي مثل IPFS عندما تحتاج الملفات العامة إلى عنونة المحتوى.
• الاوراكل (Oracles) عندما تحتاج العقود إلى بيانات خارج السلسلة، مثل أسعار الأصول أو نتائج الأحداث.

تستحق الاوراكل (Oracles) اهتمامًا خاصًا؛ فالبلوك تشين لا تعرف تلقائيًا الحقائق التي تنشأ خارج السلسلة. على سبيل المثال، يحتاج تطبيق إقراض لامركزي إلى أسعار الأصول الحالية، ويحتاج تطبيق مشتقات لامركزي إلى بيانات التسوية، بينما يتطلب تطبيق سوق تنبؤات لامركزي نتائج أحداث مؤكدة. تُعد Chainlink شبكة الاوراكل الأكثر استخدامًا في بنية تطبيقات الـ dApp، وتُستخدم لتغذيات الأسعار وبيانات الأحداث والاتصال عبر السلاسل.

يتمثل تحدي المطورين في تحقيق التوازن: فوجود الكثير من المكونات على السلسلة يجعل التطبيق مكلفًا وبطيئًا، بينما القليل جدًا يجعل تسمية “dApp” فارغة من معناها. التصميم الجيد يستغل البلوك تشين حيث يكون التنفيذ المشترك أو الحضانة أو الشفافية هي الغاية الحقيقية للمنتج.

عند ربط محفظة بتطبيق dApp لأول مرة، تبدو العملية بسيطة: تنقر على “Connect Wallet”، تختار محفظتك من القائمة، ويتعرف الموقع على عنوانك. هذا الجزء لا يحمل أي مخاطر تقريبًا. تظهر المخاطر فورًا بعد ذلك، عندما يطلب منك الموقع التوقيع على شيء ما.

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

عندما تكون مستعدًا للربط، اتبع هذه الخطوات:

1. انتقل إلى الموقع عن طريق كتابة عنوان URL مباشرة أو استخدام إشارة مرجعية. لا تتبع الروابط من نتائج البحث، أو منشورات وسائل التواصل الاجتماعي، أو الرسائل المباشرة.
2. انقر على “Connect Wallet” واختر محفظتك. سيطلب الموقع رؤية عنوانك العام. هذه الخطوة وحدها لا تحرك الأموال.
3. تحقق من الشبكة المعروضة في محفظتك قبل الموافقة على أي شيء. الموافقة على شبكة خاطئة خطأ شائع ولا يمكن التراجع عنه.
4. اقرأ كل طلب توقيع قبل التأكيد. انظر إلى token name، الـ amount، والعقد الذي يقدم الطلب.
5. “Reject” أي موافقة تطلب إنفاق token غير محدود. حدد “limit” معينًا يغطي فقط الـ action الذي تنوي القيام به.
6. بعد الاختبار، قم بإلغاء “token approvals” عبر “approval manager” في محفظتك. “Disconnecting” الموقع لا يلغي “token permissions” الحالية.

بعض العادات التي تمنع المشاكل الأكثر شيوعًا:

• لا توقع أبدًا على “message” لا تفهمه. الـ “prompts” غير الواضحة هي إشارة توقف، وليست إزعاجًا بسيطًا.
• تعامل مع أي ادعاء عاجل حول airdrop، أو mint deadline، أو wallet issue كمحاولة تصيد احتيالي حتى يثبت العكس.
• لا تعيد استخدام محفظة اختبار للتخزين طويل الأمد. بمجرد أن تتصل المحفظة بتطبيقات dApp متعددة، ابقها منفصلة عن أي أموال لا يمكنك تحمل خسارتها.

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