ماذا يحدث فعليًا عندما تنقر على زر في تطبيق لامركزي؟ 👇
لنفترض أنك تستخدم تطبيقًا لامركزيًا وتنقر على «إرسال رمز مميّز».
يبدو الأمر وكأنه إجراء بسيط واحد. لكن تحدث عدة أمور في الخلفية.
1√ تجهّز الواجهة الأمامية الطلب
يستخدم تطبيقك اللامركزي واجهته البرمجية ورمز التكامل مع العقد لإعداد الإجراء الذي تريد تنفيذه.
2√ تطلب محفظتك موافقتك
في المعاملات التي تغيّر حالة سلسلة الكتل، تتيح لك محفظتك مراجعة الطلب وتوقيعه. لا توقّع أبدًا على شيء لا تفهمه.
3️⃣ تُرسل المعاملة إلى الشبكة
تُرسل المعاملة الموقّعة عبر موفّر RPC إلى شبكة سلسلة الكتل.
4️⃣ ينفّذ العقد الذكي العملية
تعالج الشبكة المعاملة وفقًا لرمز العقد. وإذا نجحت المعاملة، فقد تتغيّر حالة العقد.
5√ يتحقق تطبيقك من النتيجة
يمكن لتطبيقك اللامركزي تتبّع حالة المعاملة وعرض النتيجة بعد تلقي التأكيد ذي الصلة. وفي الإجراءات المهمة، ينبغي له التحقق من إيصال المعاملة والأحداث المتوقعة، بدلًا من الوثوق برسالة نجاح من الواجهة الأمامية.
إليك تفصيلًا يغفل عنه المبتدئون كثيرًا:
قراءة بيانات سلسلة الكتل تختلف عن تغييرها.
- يمكن عادةً استخدام "balanceOf()" لقراءة رصيد رمز مميّز عبر استدعاء للقراءة فقط، من دون دفع رسوم معاملة.
- تغيّر "transfer()" حالة سلسلة الكتل، وتتطلب عمومًا معاملة موقّعة ورسومًا للشبكة.
تعتمد العملية بالتحديد على سلسلة الكتل والمحفظة والعقد الذي تستخدمه.
بصفتنا مطوّرين، يساعدنا فهم هذا المسار على بناء واجهات أفضل، ومعالجة الأخطاء بالشكل الصحيح، وتقديم معلومات أوضح للمستخدمين عن حالة معاملاتهم.
أستكشف هذه المفاهيم من منظور هندسة التطبيقات متكاملة المكدس وWeb3، وأشارك ما أتعلمه على طول الطريق.
سؤال للمطوّرين الآخرين: أي جزء ينبغي أن أشرح بالتفصيل لاحقًا: تكامل المحفظة، أم موفّرو RPC، أم إيصالات المعاملات؟
#Web3Dev #SmartContracts #BinanceSquare