تطوير واجهة DApp تتصل بشبكة Solana باستخدام محفظة Phantom

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

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

فهم بنية الاتصال بين الواجهة ومحفظة Phantom

في بيئة Solana لا نتعامل عادة مع عقد ذكي بصيغة Solidity، بل مع Programs مكتوبة غالباً بلغة Rust. الواجهة الأمامية تتصل بالشبكة عبر مكتبة @solana/web3.js، بينما تؤدي محفظة Phantom دور مزود التوقيع وإدارة المفاتيح.

هذا التصميم قريب مفاهيمياً من فكرة ربط الواجهات بالمحافظ في عالم Web3، ويمكنك مقارنة ذلك بما شرحناه سابقاً في هندسة الويب اللامركزي (Web3.js & Ethers.js): كيف نربط الواجهات بالعقود الذكية؟. الفرق أن Phantom تضيف الكائن window.solana بدلاً من واجهات مثل window.ethereum.

المكونات الأساسية في أي تكامل ناجح

• اكتشاف وجود المحفظة داخل المتصفح.
• طلب إذن الاتصال من المستخدم.
• إنشاء كائن Connection نحو شبكة Devnet أو Mainnet.
• جلب المفتاح العام publicKey وقراءة الرصيد.
• بناء معاملة ثم طلب توقيعها وإرسالها عبر المحفظة.

إعداد البيئة البرمجية للمشروع

أفضل نقطة انطلاق هي مشروع React أو Next.js. أما على مستوى أدوات Solana فيستحسن تثبيت المكتبة الرسمية وفهم بنية البيئة من خلال تثبيت بيئة عمل Solana وإطار عمل Anchor لتسهيل كتابة العقود، خصوصاً إن كنت ستتعامل لاحقاً مع Programs مخصّصة.

الحزم المطلوبة

• @solana/web3.js للاتصال بالشبكة وإنشاء المعاملات.
• React hooks لإدارة حالة الاتصال والرصيد.
• محفظة Phantom مثبّتة على المتصفح ومضبوطة على Devnet.

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

بناء منطق الاتصال بالمحفظة

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

import React, { useEffect, useState } from "react";
import {
  Connection,
  PublicKey,
  clusterApiUrl,
  LAMPORTS_PER_SOL,
  SystemProgram,
  Transaction
} from "@solana/web3.js";

const network = clusterApiUrl("devnet");
const connection = new Connection(network, "confirmed");

export default function SolanaPhantomApp() {
  const [walletAddress, setWalletAddress] = useState("");
  const [balance, setBalance] = useState(0);

  const getProvider = () => {
    if ("solana" in window) {
      const provider = window.solana;
      if (provider.isPhantom) return provider;
    }
    window.open("https://phantom.app/", "_blank");
  };

  const connectWallet = async () => {
    try {
      const provider = getProvider();
      const response = await provider.connect();
      setWalletAddress(response.publicKey.toString());
    } catch (error) {
      console.error("Wallet connection failed:", error);
    }
  };

  const fetchBalance = async (address) => {
    const publicKey = new PublicKey(address);
    const lamports = await connection.getBalance(publicKey);
    setBalance(lamports / LAMPORTS_PER_SOL);
  };

  useEffect(() => {
    if (walletAddress) {
      fetchBalance(walletAddress);
    }
  }, [walletAddress]);

  return (
    <div>
      {!walletAddress ? (
        <button onClick={connectWallet}>Connect Phantom</button>
      ) : (
        <div>
          <p>Wallet: {walletAddress}</p>
          <p>Balance: {balance} SOL</p>
        </div>
      )}
    </div>
  );
}

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

لماذا نقرأ الرصيد بعد الاتصال مباشرة؟

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

إرسال معاملة بسيطة من الواجهة

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

const sendTransaction = async () => {
  try {
    const provider = getProvider();
    const fromPubkey = provider.publicKey;
    const toPubkey = new PublicKey("TARGET_WALLET_PUBLIC_KEY");

    const transaction = new Transaction().add(
      SystemProgram.transfer({
        fromPubkey,
        toPubkey,
        lamports: 1000000
      })
    );

    transaction.feePayer = fromPubkey;
    const { blockhash } = await connection.getLatestBlockhash();
    transaction.recentBlockhash = blockhash;

    const signedTransaction = await provider.signTransaction(transaction);
    const signature = await connection.sendRawTransaction(
      signedTransaction.serialize()
    );

    await connection.confirmTransaction(signature, "confirmed");
    console.log("Transaction signature:", signature);
    await fetchBalance(fromPubkey.toString());
  } catch (error) {
    console.error("Transaction failed:", error);
  }
};

هذا المثال يرسل قيمة صغيرة بوحدة lamports، وهي الوحدة الأدق من SOL. النمط هنا يشبه من حيث الفكرة مقال كتابة البيانات وإرسال المعاملات (Transactions) من واجهة الويب إلى العقد الذكي، لكن التنفيذ على Solana يعتمد على حسابات وتعليمات مختلفة.

لا ترسل أي معاملة من الواجهة اعتماداً على عنوان مستلم مُدخل من المستخدم دون التحقق من صحته باستخدام PublicKey ومعالجة الأخطاء بشكل واضح. خطأ صغير في العنوان قد يؤدي إلى فشل المعاملة أو تحويل الأصول إلى جهة غير مقصودة.

أفضل ممارسات تجربة المستخدم والأمان

1) إدارة حالات الاتصال

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

2) تجنب الإفراط في طلب التوقيع

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

3) دعم الشبكات التجريبية أثناء التطوير

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

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

كيف يتطور هذا النموذج إلى DApp متكامل؟

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

كما أن فهم بنية المفاتيح يظل ضرورياً عند التعامل مع التوقيع والصلاحيات، ولهذا يبقى مقال التشفير والمفاتيح: كيف تعمل المحافظ الرقمية (Public & Private Keys) برمجياً؟ مرجعاً مهماً لفهم ما يحدث فعلياً عندما يضغط المستخدم على زر الموافقة داخل المحفظة.

خلاصة عملية

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

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