نموذج حساب سولانا: دليل تقني

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

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

كل معاملة في سولانا تمس حساباً ما. كل رمز تمتلكه، كل برنامج تنشره، كل رمز غير قابل للاستبدال (NFT) تسكه: كل ذلك يعيش في الحسابات. قبل أن تكتب سطراً واحداً من كود سولانا، فإن فهم كيفية عمل الحسابات ليس معلومة خلفية اختيارية، بل هو المتطلب الأساسي لكل شيء آخر.

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

نظرة عامة على الدليل التقني لنموذج حساب سولانا

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

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

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

إذا كنت قادماً من إيثيريوم، فإن هذا التمييز مهم: تخزن عقود إيثيريوم الذكية حالتها الخاصة داخلياً، بينما برامج سولانا عديمة الحالة (stateless). المقارنة الكاملة موجودة في قسم مخصص أدناه.

تشريح حساب سولانا

كل حساب في سولانا، سواء كان يخزن عملات SOL أو كود البرنامج أو حالة التطبيق، مبني من نفس الحقول الخمسة.

الحقول الخمسة لكل حساب سولانا

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

lamports: هو الرصيد من عملة SOL لهذا الحساب، معبراً عنه باللامبورتات (أصغر وحدة في سولانا، مشروحة في القسم التالي). في تشبيه خزانة الملفات، هذه هي القيمة النقدية المختومة على غلاف المجلد.

data: مصفوفة بايتات خام (Vec<u8>) تخزن أي حالة يحتاجها البرنامج المالك. بالنسبة لحساب البرنامج، يحتوي هذا الحقل على كود BPF المجمع. بالنسبة لحساب البيانات، فإنه يحتوي على حالة التطبيق المتسلسلة. تحدد البرامج تنسيق التسلسل الخاص بها (عادةً Borsh) للقراءة والكتابة للبيانات المنظمة في هذا الحقل. ما يعادل ذلك في خزانة الملفات هو المحتويات المادية داخل المجلد.

owner: المفتاح العمومي للبرنامج المصرح له بتعديل حقل البيانات لهذا الحساب. لا يمكن لأي برنامج آخر الكتابة فيه. هذا هو ختم القسم على غلاف المجلد.

executable: علامة منطقية (boolean). عندما تكون قيمتها true (صواب)، يخزن الحساب كود البرنامج ويمكن تنفيذه. عندما تكون false (خطأ)، يكون الحساب عبارة عن حاوية بيانات.

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

يتم تحديد كل حساب في سولانا بواسطة مفتاح عمومي فريد بطول 256 بت مشتق من زوج مفاتيح ed25519، والذي يعمل كعنوان له ومعرف له داخل الكتلة. يبلغ الحد الأقصى لحجم حقل البيانات لحساب واحد 10 ميجابايت اعتباراً من ترقيات البروتوكول الأخيرة؛ تحقق من الحدود الحالية في وثائق حساب سولانا,) لأن هذه القيمة تغيرت عبر تاريخ سولانا.

اللامبورتات: أصغر وحدة في سولانا

اللامبورت (Lamport) هو أصغر فئة من عملة SOL: حيث يساوي 1 SOL ما يعادل 1,000,000,000 لامبورت (10⁹). الوحدة سميت على اسم ليزلي لامبورت، عالم الكمبيوتر الذي يكمن عمله في الأنظمة الموزعة والتسامح مع الأخطاء وراء الكثير من نظرية الحوسبة الموزعة الحديثة. اللامبورتات موجودة لأن جميع العمليات الحسابية داخل الكتلة، بما في ذلك حسابات الإيجار ورسوم المعاملات وأرصدة الحسابات، يجب أن تستخدم الحساب الصحيح (integer arithmetic) لتجنب أخطاء دقة النقطة العائمة. التعبير عن القيم باللامبورتات يجعل كل عملية حسابية دقيقة.

هل حساب سولانا هو نفسه المحفظة؟

حساب سولانا والمحفظة ليسا نفس الشيء. ما تعتبره محفظتك، مثل تطبيق Phantom أو Solflare على هاتفك، هو برنامج خارج الكتلة يدير مفتاح سري. الكيان الموجود داخل الكتلة هو حساب نظام يحتفظ برصيد SOL الخاص بك. تتحكم محفظتك في حساب نظام؛ وهي ليست حساباً بحد ذاتها. حسابات الرموز (Tokens)، وحسابات البرامج، وحسابات البيانات ليس لها ما يعادل المحفظة: فهي حاويات بيانات داخل الكتلة فقط لا يمثلها أي تطبيق محفظة للمستهلكين بشكل مباشر.

أنواع حسابات سولانا

تنقسم حسابات سولانا إلى أربع فئات، يتم تحديد كل منها من خلال البرنامج المالك وعلامة القابلية للتنفيذ (executable flag).

1. حسابات النظام: مملوكة لبرنامج النظام (System Program)؛ وتُستخدم لتخزين SOL ومحافظ المستخدمين.
2. حسابات البرامج: حسابات قابلة للتنفيذ تخزن كود BPF المجمع.
3. حسابات البيانات/الحالة: مملوكة للبرامج؛ وتخزن الحالة الخاصة بالتطبيق.
4. حسابات الرموز المميزة: حسابات بيانات متخصصة مملوكة لبرنامج SPL Token (مع حسابات الرموز المرتبطة كفئة فرعية معيارية).

حسابات النظام

حسابات النظام مملوكة لبرنامج النظام، ومحافظ المستخدمين هي حسابات نظام. برنامج النظام هو برنامج سولانا الأصلي المسؤول عن ثلاث عمليات أساسية: إنشاء حسابات جديدة (تخصيص مساحة بيانات داخل الكتلة)، وتعيين ملكية الحساب (ضبط حقل المالك لبرنامج محدد)، وتحويل SOL بين الحسابات. يبدأ كل حساب جديد في سولانا كحساب نظام مملوك لبرنامج النظام.

برنامج النظام له عنوان معروف: 11111111111111111111111111111111 (32 واحداً بنظام base58). راجع وثائق برنامج النظام) لمجموعة تعليماته الكاملة. عندما يقوم مطور بإنشاء حساب بيانات لبرنامجه، فإنه يستدعي تعليمة "إنشاء حساب" (Create Account) الخاصة ببرنامج النظام، مع تحديد حجم البيانات، وإيداع اللامبورتات المعفى من الإيجار، والمفتاح العمومي للبرنامج المالك الجديد.

حسابات البرامج

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

حسابات البيانات والحالة

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

حسابات الرموز المميزة وحسابات الرموز المميزة المرتبطة

حسابات الرموز المميزة هي حسابات بيانات مملوكة لبرنامج SPL Token، حيث يحتفظ كل منها بـ الرصيد من رمز مميز واحد محدد لمحفظة واحدة محددة. يمكن لعنوان محفظة واحد أن يحتفظ بحسابات رموز مميزة متعددة، واحد لكل نوع رمز مميز يحتفظ به.

حساب الرموز المميزة المرتبط (ATA) هو حساب الرموز المميزة المتعارف عليه لزوج محدد من [عنوان المحفظة، عنوان السك]. يتم اشتقاق حسابات ATA بشكل حتمي كعنوان مشتق من البرنامج (PDA) باستخدام عنوان المحفظة وعنوان سك الرمز المميز كبذور. يضمن هذا أن كل محفظة لديها حساب "رسمي" واحد بالضبط لكل نوع رمز مميز. حسابات ATA هي المعيار المستخدم من قبل المحافظ مثل Phantom و Solflare، ومن قبل المنصات، ومن قبل البروتوكولات: عندما تتلقى رمزاً مميزاً في واجهة مستخدم محفظتك، فإنه يذهب إلى حساب ATA الخاص بك لهذا الرمز المميز.

إذا لم يكن حساب ATA موجوداً لزوج [محفظة، سك] معين، فيجب إنشاؤه قبل التمكن من استلام الرموز المميزة، وتكلف عملية الإنشاء إيداع Lamport معفى من الإيجار. وهذا هو السبب في أن بعض المعاملات تتضمن "رسوم إنشاء حساب" صغيرة في واجهات مستخدم المحفظة. للحصول على مواصفات ATA الكاملة، راجع وثائق حساب الرموز المميزة المرتبط بـ SPL.) حساب ATA هو حساب رمز مميز، ولكن ليس كل حساب رمز مميز هو ATA، والتمييز مهم عند تصحيح أخطاء البرامج المتعلقة بالرموز المميزة.

ملكية الحساب: كيف تتحكم Solana في الوصول إلى البيانات

ملكية الحساب في Solana هي آلية سلطة كتابة، وليست مفهوماً لملكية الأصول.

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

يقوم برنامج النظام (System Program) بتعيين الملكية أثناء إنشاء الحساب. عندما يقوم المطور بإنشاء حساب بيانات لبرنامجه، فإن تعليمات إنشاء الحساب (Create Account) تعين حقل المالك إلى المفتاح العمومي لبرنامجه. يمكن إعادة تعيين الملكية، ولكن فقط من قبل برنامج المالك الحالي باستخدام تعليمات التعيين (Assign). لا يمكن لأي طرف خارجي نقل الملكية من جانب واحد.

المالك مقابل السلطة: تمييز حاسم

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

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

الملكية في الممارسة: مثال على DEX

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

إيجار الحساب والإعفاء من الإيجار

إيجار Solana هو آلية تكلفة تخزين، وليس رسوماً دورية.

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

الإعفاء من الإيجار هو معيار الإنتاج لجميع حسابات Solana المنشورة. الحد الأدنى للرصيد للإعفاء من الإيجار هو حوالي 6,960 Lamports مضروباً في حجم بيانات الحساب بالبايت، بالإضافة إلى مبلغ أساسي قدره 890,880 Lamports تقريباً لحساب ذي صفر بايت.

مثال عملي: حساب بيانات بحجم 100 بايت يتطلب حوالي 890,880 + (6,960 × 100) = 1,586,880 Lamports، أو ما يقرب من 0.00159 SOL. هذه الأرقام تقريبية وعرضة للتغيير. تحقق من القيم الحالية باستخدام أمر Solana CLI solana rent <bytes> أو وثائق إيجار Solana.). لم يتم تفعيل تغيير مقترح لتحويل الإيجار إلى نموذج رسوم المعاملات حتى وقت كتابة هذا التقرير؛ استشر الوثائق الحالية لمعرفة آخر حالة للبروتوكول.

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

لا يتم إغلاق الحسابات المعفاة من الإيجار تلقائياً بواسطة وقت التشغيل. يتم تمويل حسابات الإنتاج دائماً حتى عتبة الإعفاء من الإيجار، لذا فإن عملية جمع القمامة (garbage collection) لا تؤثر عليها. إغلاق الحسابات عمداً هو نمط منفصل ومتعمد: يمكن للبرامج إغلاق حسابات البيانات لاسترداد إيداع Lamport. في بروتوكول DeFi، على سبيل المثال، يؤدي إغلاق مركز إقراض إلى إعادة SOL الذي مول حساب بيانات ذلك المركز إلى المستخدم. هذا نمط تصميم بروتوكول شائع، وليس حذفاً غير طوعي.

شرح العناوين المشتقة من البرنامج (PDAs)

تحل العناوين المشتقة من البرنامج مشكلة محددة: كيف يمكن لبرنامج التحكم في حساب دون أن يحمل أي شخص مفتاح سري المقابل.

العنوان المشتق من البرنامج (PDA) هو عنوان حساب يتم إنشاؤه بشكل حتمي ومشتق من معرّف البرنامج وقيمة بذرة واحدة أو أكثر باستخدام تشفير SHA-256. يتم وضع عناوين PDA عمداً خارج المنحنى الإهليلجي ed25519، مما يعني أنه ليس لها مفتاح سري مطابق. يمكن للبرنامج المالك فقط توقيع المعاملات للحسابات في عناوين PDA. راجع وثائق PDA الخاصة بـ Solana) للحصول على المواصفات الكاملة.

تقع جميع عناوين حسابات Solana العادية على منحنى ed25519 الإهليلجي. بينما توضع عناوين البرامج المشتقة (PDAs) قصداً خارج هذا المنحنى. خاصية "خارج المنحنى" ليست خللاً؛ بل هي آلية التصميم التي تجعل وجود مفتاح سري مستحيلاً من الناحية الرياضية. لا يمكن لأي إنسان، ولا أي محفظة أجهزة، ولا أي نظام لإدارة المفاتيح إصدار المفتاح السري لعنوان PDA لأنه لا يوجد مثل هذا المفتاح على المنحنى.

لماذا تهم عناوين PDAs: الحضانة التي يتحكم فيها البرنامج

النتيجة المترتبة على عدم وجود مفتاح سري هي أن البرنامج المالك فقط هو من يمكنه تفويض المعاملات لعنوان PDA. وهذا يتيح حضانة يتحكم فيها البرنامج دون الحاجة للثقة: فالبرنامج يمتلك السلطة على الحساب دون الاعتماد على أي إنسان لحماية مفتاح سري.

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

ثلاث حالات استخدام واقعية لعنوان PDA

تظهر عناوين PDAs في ثلاثة أنماط متكررة عبر برامج Solana.

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

لا يمكن لأي فرد تنفيذ عملية "السحب" (Rug Pull) لسلطة سك مجموعة NFT. تعمل سلطة سك NFT من خلال جعل برامج Metaplex تتحكم في السك عبر عنوان PDA مشتق من عنوان السك. ولأنه لا يوجد مفتاح سري لعنوان PDA هذا، فإن قواعد سك المجموعة تُنفذ بواسطة كود البرنامج وحده بعد النشر.

كيف يقوم البرنامج بتخزين بيانات كل مستخدم دون الاحتفاظ بفهرس مركزي؟ يستخدم تخزين حالة كل مستخدم عنوان PDA فريداً مشتقاً من [program_id, user_pubkey]. ينتج عن هذا عنوان حساب محدد وخاص بالمستخدم لتخزين درجة لعبة ذلك المستخدم، أو مركز الإقراض الخاص به، أو سجل الحصص (staking). يعرف البرنامج دائماً مكان العثور على بيانات كل مستخدم.

تحدد الوظيفتان findProgramAddress() و createProgramAddressSync() مواقع العناوين الصالحة خارج المنحنى عن طريق اختبار العناوين المرشحة بـ "بذرة القفز" (bump seed) متزايدة حتى يخرج أحدها عن المنحنى.

متى يجب عليك استخدام PDA؟

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

Solana مقابل Ethereum: كيف تختلف نماذج الحسابات

الفرق الجوهري بين نماذج حسابات Solana و Ethereum هو مكان وجود الحالة (state).

في Ethereum، العقود الذكية هي عقود ذات حالة: فهي تخزن حالتها الخاصة داخلياً بجانب الكود الخاص بها. يحتفظ عقد Solidity بتعييناته ومتغيرات حالته داخل مخزن العقد، الذي تديره آلة إيثريوم الافتراضية (EVM). في Solana، البرامج عديمة الحالة؛ فكل الحالات تعيش في حسابات خارجية تقرأها البرامج وتكتب عليها أثناء التنفيذ. وحيث تقوم Ethereum بتشغيل البرامج في EVM، تستخدم Solana بيئة تشغيل تعتمد على BPF تنفذ البرامج مقابل حسابات يتم التصريح عنها مسبقاً في المعاملة.

المقايضات تسير في كلا الاتجاهين. يحمل نموذج الحالة في Ethereum ميزة حقيقية لتجربة المطور: نموذج ذهني أبسط، لا توجد إدارة صريحة للحسابات، وعبء إدراكي أقل للعديد من حالات الاستخدام. يمكن للمطور كتابة ونشر عقد ERC-20 دون التفكير في حجم حساب البيانات، أو ودائع الإعفاء من الإيجار، أو اشتقاق PDA.

يستبدل نموذج Solana عديم الحالة تلك البساطة بتوازي التنفيذ وفصل الاهتمامات. تصريحات الحسابات المطلوبة في كل معاملة هي المدخلات لخوارزمية جدولة Sealevel، التي تنفذ المعاملات غير المتعارضة في وقت واحد. تعتمد سلاسل كتل أخرى من الطبقة الأولى مثل Aptos و Sui متغيراتها الخاصة لفصل الحالة القائم على الموارد، ولكل منها ملفات تعريف مقايضة مختلفة. لا يُعتبر نهج Ethereum ولا نهج Solana متفوقاً بشكل قاطع؛ بل هما يعكسان أولويات تصميم مختلفة لأعباء عمل مختلفة.

لماذا تهم هذه البنية: Sealevel والتنفيذ المتوازي

البرامج عديمة الحالة ليست قيداً تصميمياً؛ بل هي الآلية التي تجعل التنفيذ المتوازي ممكناً.

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

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

البناء باستخدام الحسابات: تنفيذ المطور

يجب إنشاء كل حساب يعمل معه برنامج Solana، وتمويله، وتعيينه لمالك قبل أن يتمكن البرنامج من القراءة منه أو الكتابة فيه.

إنشاء حساب باستخدام برنامج النظام

تُكتب برامج Solana بلغة Rust، وهي لغة برمجة نظم، وتُجمع في كود BPF الثانوي قبل النشر. يتبع إنشاء حساب على Solana هذه الخطوات، كل منها يقابل متغيراً في تعليمة إنشاء حساب (Create Account) الخاصة ببرنامج النظام:

1. from_pubkey: تحديد الحساب الذي يمول عملية الإنشاء (الدافع)
2. new_account_pubkey: تحديد عنوان الحساب الجديد
3. lamports: حساب مبلغ الرصيد المعفى من الإيجار بناءً على حجم البيانات
4. space: تحديد حجم البيانات بالبايت لتخصيصها للحساب
5. owner: تحديد المفتاح العمومي للبرنامج الذي سيمتلك هذا الحساب ويكتب فيه

// إنشاء حساب بيانات جديد باستخدام برنامج النظام
let create_account_ix = system_instruction::create_account(
    &payer.pubkey(),         // from_pubkey: من يمول هذا الحساب
    &new_account.pubkey(),   // new_account_pubkey: عنوان الحساب
    rent_exempt_balance,     // lamports: كافٍ ليكون معفى من الإيجار
    data_size as u64,        // space: البايتات المخصصة لبيانات الحساب
    &program_id,             // owner: البرنامج الذي يتحكم في هذا الحساب
);

تحدد هذه التعليمات ملكية الحساب. بعد تنفيذها، يمكن للبرنامج الموجود في program_id فقط الكتابة في حقل بيانات هذا الحساب.

استخدام إطار عمل Anchor

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

// Anchor: تحديد قيود الحساب باستخدام الماكرو #[derive(Accounts)]
#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,                        // إنشاء هذا الحساب إذا لم يكن موجودًا
        payer = user,                // يقوم المستخدم بدفع إيداع الإعفاء من الإيجار
        space = 8 + MyData::LEN,    // مميز 8 بايت + حجم البيانات
    )]
    pub my_account: Account<'info, MyData>,     // حساب البيانات الجديد
    #[account(mut)]
    pub user: Signer<'info>,                    // الموقّع والدافع للمعاملة
    pub system_program: Program<'info, System>, // مطلوب لإنشاء الحساب
}

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

موارد بنية Solana ذات الصلة

يمكن للمطورين الذين يبحثون عن مسار تنفيذ أقصر استخدام دليل نموذج الحساب الموجه للمطورين؛ يتم تغطية اصطلاحات برنامج الرمز المميز في نظرة عامة على مكتبة برامج Solana. تهتم صفحة أسعار SOL) و سوق SOL/USDT للتداول الفوري) بالوصول إلى السوق، وليس بملكية الحساب أو سلطة البرنامج.

الأسئلة الشائعة: نموذج حساب Solana: دليل فني

ما هو الحساب في Solana؟

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

كيف يختلف نموذج حساب Solana عن نموذج Ethereum؟

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

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

عنوان مشتق من البرنامج (PDA) هو عنوان حساب تم إنشاؤه بشكل حتمي مشتق من معرف البرنامج وقيم البذور باستخدام تجزئة SHA-256. تقع عناوين PDA خارج منحنى ed25519 الإهليلجي، لذلك ليس لها مفتاح سري مطابق. يمكن للبرنامج المالك فقط توقيع المعاملات للحسابات الموجودة في عناوين PDA، مما يتيح الحضانة الموثوقة التي يتحكم فيها البرنامج لحسابات الضمان، وسلطات السك، وتخزين الحالة لكل مستخدم.

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

اللامبورتس هي أصغر وحدة تقسيم لـ SOL على بلوكتشين Solana: 1 SOL يساوي 1,000,000,000 لامبورت (10^9). سُميت على اسم ليزلي لامبورت، رائدة الحوسبة الموزعة، وتُستخدم اللامبورتس لجميع أرصدة SOL ورسوم المعاملات وحسابات الإيجار داخل الكتلة. يؤدي تحديد المبالغ باللامبورتس إلى تجنب أخطاء دقة الأرقام العشرية التي قد تنشأ عن استخدام قيم SOL الكسرية في العمليات الحسابية داخل الكتلة.

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

هناك ثلاثة أنواع رئيسية لحسابات Solana: (1) حسابات النظام، المملوكة لبرنامج النظام وتستخدم لأرصدة SOL ومحافظ المستخدمين؛ (2) حسابات البرامج، وهي حسابات قابلة للتنفيذ تخزن شفرة BPF الثنائية المجمعة؛ (3) حسابات البيانات/الحالة، المملوكة للبرامج وتخزن حالة خاصة بالتطبيق. حسابات الرموز المميزة هي مجموعة فرعية متخصصة من حسابات البيانات المملوكة لبرنامج رمز Solana المميز.

يتطلب نموذج حساب Solana المزيد من التفكير الأولي مقارنة بنموذج الحالة في Ethereum، ولكن هذا الاستثمار المعرفي هو ما يجعل التنفيذ المتوازي ممكنًا.

• تعيش كل قطعة من الحالة على Solana في حساب؛ تقرأ البرامج وتكتب إلى الحسابات التي تم تمريرها أثناء التنفيذ، وليس التخزين الداخلي
• لكل حساب خمسة حقول: لامبورتس، بيانات، مالك، قابل للتنفيذ، وحقل الإيجار القديم
• يمكن لبرنامج المالك فقط تعديل حقل بيانات الحساب؛ هذا هو آلية التحكم في الوصول الأساسية في Solana
• يتم تمويل الحسابات الإنتاجية إلى عتبة الإعفاء من الإيجار ولا يتم جمعها تلقائيًا أبدًا بواسطة وقت التشغيل
• تتيح عناوين البرامج المشتقة الحضانة الموثوقة التي يتحكم فيها البرنامج عن طريق استخدام عناوين خارج المنحنى التي ليس لها مفتاح سري
• يقوم وقت تشغيل Sealevel في Solana بتنفيذ المعاملات بالتوازي عن طريق تحليل قوائم الوصول المعلنة للحسابات عبر المعاملات غير المتضاربة

هل أنت مستعد للبناء على هذا الأساس؟ تابع مع:

• كيفية عمل برامج Solana: دليل المطور للتنفيذ عديم الحالة
• دليل إطار عمل Anchor لبناء برامج Solana
• شرح استدعاء البرامج عبر (CPI): كيف تتصل برامج Solana ببعضها البعض
• كيفية عمل إثبات التاريخ في بنية Solana

للحصول على أحدث مواصفات البروتوكول لأحجام الحسابات وحسابات الإيجار وسلوك وقت التشغيل، استشر وثائق حساب Solana الرسمية مباشرة.