مطور سولانا

# مهارة تطوير Solana

## الغرض من هذه المهارة استخدم هذه المهارة عندما يطلب المستخدم ما يلي: - أعمال واجهة المستخدم لتطبيقات Solana اللامركزية (React / Next.js) - اتصال المحفظة + تدفقات التوقيع - بناء المعاملات / إرسالها / تأكيد تجربة المستخدم (UX) - المعاملات v1 / المعاملات الأكبر (SIMD-0385) — التنسيق الافتراضي للتعليمات البرمجية الجديدة؛ الإرسال، القراءة، الفهرسة - تطوير البرامج على السلسلة (Anchor أو Pinocchio) - هندسة البرامج — تخطيط الحالة، اصطلاحات PDA seed، التسمية، الموازاة، cranks، طوبولوجيا الخزنة (vault topology) - توليد حزمة تطوير العميل (SDK) (عملاء البرامج المكتوبة) - الاختبار المحلي (Surfpool, LiteSVM, Mollusk) واختبار التشويه (fuzz testing) (Trident, cargo-fuzz) - تعزيز الأمان ومراجعات على غرار التدقيق - التحويلات السرية (امتداد Token-2022 ZK) - **إعداد سلسلة الأدوات (Toolchain)، عدم تطابق الإصدارات، أخطاء GLIBC، تعارضات التبعيات** - **ترقية إصدارات Anchor/Solana CLI، الترحيل بين الإصدارات** - **ترحيل التعليمات البرمجية web3.js v1 إلى web3.js v3 أو Kit**

## قرارات المكدس الافتراضية (ذات رأي)

1) **SDK: عملاء المكونات الإضافية @solana/kit 8، المعاملات v1 افتراضيا** - قم ببناء العملاء باستخدام `createClient()` من `@solana/kit`، ثم استخدم المكونات الإضافية `.use(...)`. مرر `transactionConfig: { version: 1 }` إلى المكون الإضافي RPC بحيث تكون كل معاملة يخطط لها العميل من الإصدار v1: ```ts createClient() .use(signer(mySigner)) .use(solanaRpc({ rpcUrl, transactionConfig: { version: 1, priorityFeeLamports: lamports(5_000n) } })); // or solanaLocalRpc / solanaDevnetRpc / solanaMainnetRpc from @solana/kit-plugin-rpc ``` - **المعاملات v1 هي الافتراض للتعليمات البرمجية الجديدة**. اضبط `version: 1`؛ وإلا فإن المخطط يضبط افتراضيا على v0. عملاء المكونات الإضافية يقدرون حدود الحوسبة وبيانات الحسابات المحملة عن طريق المحاكاة. في المسارات اليدوية، استخدم مساعدات تقدير الموارد في Kit بدلا من تخمين الحدود؛ استخدم قيما ثابتة فقط للتجاوزات المقاسة أو الحدود المتعمدة. انظر [transactions-v1.md](references/transactions-v1.md). - `pipe()` اليدوي + `createTransactionMessage({ version: 1 })` هو البديل منخفض المستوى عندما تحتاج إلى التحكم في كل خطوة (أعمار مخصصة، توقيع دون اتصال، مخططين مخصصين) — انظر [kit/advanced.md](references/kit/advanced.md). إنه ليس المسار الافتراضي. - الافتراضي هو `signer()` / `signerFromFile()` / `generatedSigner()` من `@solana/kit-plugin-signer` — حيث يضبطون كلا من `payer` و `identity` على نفس زوج المفاتيح (الحالة الشائعة). بالنسبة للموقعين المحليين/الشبكة التجريبية الجدد، قم بتثبيت المكون الإضافي RPC/LiteSVM بعد `generatedSigner()`، ثم قم بالتمويل باستخدام `airdropSigner(...)`. استخدم المتغيرات الخاصة بالدور (`payer()` + `identity()`) فقط عندما يجب أن تأتي الرسوم والسلطة من أزواج مفاتيح مختلفة. - استخدم مكونات برامج `@solana-program/*` الإضافية (مثل `tokenProgram()`) لواجهات برمجة التطبيقات التعليمية السلسة. - تفضيل أنواع Kit (`Address`, `Signer`, واجهات برمجة تطبيقات رسائل المعاملات، codecs).

2) **واجهة المستخدم (UI): عميل مكون إضافي Kit + @solana/react** - اتصال المحفظة عبر `walletSigner()` من `@solana/kit-plugin-wallet` (اكتشاف Wallet Standard؛ المحفظة المتصلة تملأ أدوار الدافع/الهوية)، مع React hooks من `@solana/kit-plugin-wallet/react`. - قبل إرسال v1 من عميل مدعوم بالمحفظة، تحقق من `connected.supportedTransactionVersions.has(1)` (من `client.wallet.getState()` أو `useConnectedWallet`). المحافظ التي لم تشحن v1 ترفض طلب التوقيع؛ ارجع إلى عميل `version: 0` لها — انظر [frontend.md](references/frontend.md#wallet-connection). - ربط العميل عبر `@solana/react` 8 (`ClientProvider`, `useClient<AppClient>` المكتوب، data hooks، محولات SWR/TanStack). يتم إهمال React hooks القديمة الخاصة ب Wallet Standard — لا تستخدمها. - لا تستخدم `@solana/client` / `@solana/react-hooks` (framework-kit) أو `@solana/wallet-adapter-*` للعمل الجديد.

3) **التوافق مع الإصدارات القديمة: web3.js v3 (RC)** - web3.js v3 (`@solana/web3.js@rc`) هي واجهة برمجة التطبيقات الكلاسيكية القائمة على الفئات والتي أعيد بناؤها على أساسيات Kit. لا تزال مرشح إصدار — تعامل معها كهدف ترحيل لقواعد التعليمات البرمجية v1، وليس توصية افتراضية للعمل الجديد. - ترحيل قاعدة تعليمات برمجية v1: استخدم مهارة الترحيل الرسمية من مستودع solana-web3.js بدلا من الترحيل اليدوي — انظر [kit-web3-interop.md](references/kit-web3-interop.md) للتوجيه. - لا تقدم `@solana/web3-compat` في العمل الجديد — فقد تم تجاوزها. - لا تدع أنواع الفئات القديمة تتسرب عبر التطبيق بأكمله؛ احتفظ بها في وحدات المحول.

4) **البرامج** - الافتراضي: Anchor 1.1.x (تكرار سريع، توليد IDL، أدوات ناضجة). - الأداء/البصمة: Pinocchio (0.11+) عندما تحتاج إلى تحسين CU، حجم ثنائي أدنى، صفر تبعيات، أو تحكم دقيق في التحليل/التخصيص.

5) **الاختبار (المتمحور حول Surfpool)** - اختبارات الوحدة: LiteSVM (داخل العملية، Rust/TS) أو Mollusk (Rust instruction harness). - اختبارات التكامل: **Surfpool** — تفرع الشبكة الرئيسية (mainnet forking) مع استنساخ الحسابات الكسول، 26 رمز غش `surfnet_*` (السفر عبر الزمن، حالة الحساب/الرمز المميز، سيناريوهات الأوراكل، تحليل CU)، قابل للتضمين داخل العملية عبر حزمة تطوير البرامج (SDK) `@solana/surfpool`، ومشغل `anchor test` الافتراضي في Anchor 1.0+. - في TypeScript، قم بتشغيل surfnet من خلال المكون الإضافي Kit: `await`