شرح نموذج حساب سولانا
Learn how Solana's account model stores state, manages ownership, and enables parallel transaction processing for developers and investors.
يخزن نموذج حساب سولانا الأرصدة، وكود البرنامج، وحيازات الرموز، وحالة التطبيق في حسابات منفصلة بقواعد ملكية واضحة. هذا الدليل باللغة الإنجليزية البسيطة يشرح النموذج للقراء العامين قبل الانتقال إلى الحقول، وأنواع الحسابات، والإعفاء من الإيجار، والأمثلة الواقعية.
يمكن أن تتغير تفاصيل التنفيذ مثل معالجة الإيجار، وحدود حجم الحساب، وواجهات برمجة التطبيقات للعملاء. يجب على المطورين التحقق من وثائق سولانا الحالية والاستعلام عن معلمات الشبكة الحالية قبل النشر.
إذا كنت قادمًا من إيثريوم، فسيبدو نموذج حساب سولانا معكوسًا في البداية. هذا رد الفعل هو نقطة البداية الصحيحة. النموذج العقلي الذي بنيته على إيثريوم لا ينتقل بشكل نظيف، ومحاولة فرضه يخلق ارتباكًا في كل خطوة.
نموذج حساب سولانا هو النظام المعماري الذي يتم من خلاله تخزين جميع الحالات داخل الكتلة في وحدات تخزين منفصلة تسمى الحسابات. كل رصيد محفظة، برنامج، حيازة رمز، وسجل حالة تطبيق يعيش في حساب منفصل بمالك محدد، ورصيد لامبورت، وقواعد واضحة تحكم من يمكنه القراءة أو الكتابة إليه. لا يوجد شيء على سولانا خارج الحساب.
فكر في سولانا كنظام ملفات عالمي. كل قطعة بيانات تعيش في ملف منفصل يسمى حسابًا. البرامج هي التطبيقات التي تقرأ وتكتب هذه الملفات، ولكن لا يمكن للبرنامج تعديل إلا الملف الذي يملكه. يفرض وقت التشغيل قواعد الملكية هذه على مستوى البروتوكول، دون استثناءات.
تغطي هذه المقالة الحقول الخمسة داخل كل حساب سولانا، والأنواع الخمسة المميزة للحسابات، وكيف تعمل الإيجار والإعفاء من الإيجار، وما هي عناوين المشتقة من البرامج (PDAs) ولماذا توجد، وكيف يتم إنشاء الحسابات وإغلاقها، ولماذا تجعل هذه البنية معالجة المعاملات المتوازية لسولانا ممكنة. تتم كتابة برامج سولانا بلغة Rust (أو C/C++)، على الرغم من أن أطر العمل مثل Anchor تجرد الكثير من التعليمات البرمجية القياسية لإدارة الحسابات. تغطي هذه المقالة الأساس المفاهيمي الذي يتطلبه كلاهما.
نموذج حساب سولانا: تشريح الحساب
حساب سولانا هو فتحة تخزين مسماة على الشبكة تحتوي على رصيد باللامبورت، وحمولة بيانات اعتباطية، ومجموعة من حقول البيانات الوصفية التي تحدد من يملكها وماذا يمكنها فعله. في سولانا، يتم تخزين جميع البيانات، من أرصدة المحفظة إلى حالة البرنامج إلى حيازات الرموز، في حسابات.
اللامبورت هي أصغر فئة من عملة SOL، الرمز الأصلي للشبكة. اللامبورت بالنسبة لـ SOL كما السنتات بالنسبة للدولار، باستثناء تسع منازل عشرية للدقة: 1 SOL يساوي 1,000,000,000 لامبورت. يحمل كل حساب رصيد لامبورت يمول استمرار وجود الحساب على الشبكة ويمثل قيمة قابلة للتحويل.
يحتوي كل حساب سولانا بالضبط على خمسة حقول:
lamports(u64): رصيد الحساب باللامبورت. يمول هذا الحقل الإيجار ويمكن تحويله إلى حسابات أخرى.data(مصفوفة بايت): تخزين ثنائي خام. في الحسابات القابلة للتنفيذ، يحمل هذا الحقل بايت كود BPF/SBF المترجم. في حسابات البيانات، يحمل حالة التطبيق المنظمة. الحد الأقصى لحجم حقل البيانات هو 10 ميجابايت في معلمات مينيت الحالية.owner(Pubkey): المفتاح العمومي بحجم 32 بايت للبرنامج الذي لديه سلطة كتابة حصرية على حقل بيانات هذا الحساب. هذا هو الحقل الأكثر بديهية لمطوري إيثريوم. عنوان محفظتك ليس مملوكًا لك على مستوى البروتوكول؛ بل هو مملوك لبرنامج النظام. المعالجة الكاملة لحقل المالك تظهر في قسم ملكية الحساب وسلطته.executable(bool): علامة منطقية. عندما تكون صحيحة، يحتوي حقل البيانات على بايت كود البرنامج ويعمل الحساب كبرنامج. عندما تكون خاطئة، يخزن الحساب الحالة أو يحتفظ برصيد.rent_epoch(u64): حقل قديم كان يتتبع الحقبة التي تم فيها تحصيل الإيجار آخر مرة. اعتبارًا من عام 2024، تم إيقاف تحصيل الإيجار لصالح نموذج الإعفاء من الإيجار افتراضيًا. هذا الحقل يظل في هيكل الحساب ولكنه لم يعد مستخدمًا بنشاط.
إليك كيف يبدو حساب المحفظة كهيكل بيانات:
{
"lamports": 1000000000,
"data": [],
"owner": "11111111111111111111111111111111",
"executable": false,
"rent_epoch": 0
}
حقل المالك هو مفهوم على مستوى البروتوكول: البرنامج الذي يتحكم في الوصول للكتابة إلى حقل البيانات. السلطة هي اتفاقية منفصلة مخزنة داخل البيانات التي يديرها البرنامج، مثل حقل سلطة التحويل داخل حساب الرمز المميز. هذان ليسا نفس الشيء؛ قسم الملكية يرسم هذا التمييز بدقة.
الأنواع الخمسة لحسابات سولانا
لدى سولانا خمسة أنواع مميزة للحسابات، يؤدي كل منها دورًا معماريًا محددًا تحدده حقل المالك الخاص به وعلامة التنفيذ الخاصة به. لا يتم تخزين النوع كحقل منفصل؛ بل يتم استنتاجه من مالك الحساب وما إذا كان يحتوي على كود قابل للتنفيذ.
الحسابات المملوكة للنظام (حسابات المحفظة)
يحتفظ حساب مملوك للنظام برصيد SOL للمستخدم ولا شيء آخر. المالك هو دائمًا برنامج النظام (11111111111111111111111111111111)، وعلامة التنفيذ خاطئة، وحقل البيانات فارغ. عندما تشارك عنوان محفظتك مع Phantom أو Solflare، فإنك تشارك عنوان حساب مملوك للنظام. تتحكم فيه عن طريق توقيع المعاملات بمفتاحك السري، ولكن برنامج النظام هو المالك على مستوى البروتوكول.
حسابات البرامج (الحسابات القابلة للتنفيذ)
حساب البرنامج هو حساب قابل للتنفيذ يحتوي على بايت كود BPF/SBF مترجم. علامة التنفيذ صحيحة، والمالك هو BPF Loader. حسابات البرامج عديمة الحالة بحكم تصميمها؛ فهي تحتوي فقط على الكود، ولا تحتوي أبدًا على الحالة. في إيثريوم، يخزن العقد الذكي كل من الكود الخاص به وحالته في عنوان عقد واحد. في سولانا، يعيش الكود في حساب برنامج وتعيش الحالة في حسابات بيانات منفصلة، مخزنة دائمًا بشكل منفصل.
يمكن لحسابات البرامج تخزين كود قابل للتنفيذ، مع executable = true وبايت كود BPF/SBF في حقل البيانات. حسابات البيانات غير القابلة للتنفيذ لديها executable = false وتخزن الحالة بدلاً من ذلك.
حسابات البيانات (الحسابات المملوكة للبرامج)
حساب البيانات هو حساب غير قابل للتنفيذ مملوك لبرنامج معين يخزن حالة البرنامج في حقل البيانات الخاص به. علامة التنفيذ خاطئة. المالك هو أي برنامج أنشأ الحساب وأداره. رصيد عملة USDC الخاص بك، أو مركز إقراض DeFi، أو سجل بيانات NFT؛ كل منها يعيش في حساب بيانات مخصص خاص به مملوك للبرنامج المعني.
حسابات البرامج الأصلية
حسابات البرامج الأصلية هي برامج مدمجة تم نشرها في عناوين ثابتة عند إنشاء الشبكة. وتشمل برنامج النظام، و BPF Loader، وبرنامج التصويت، وبرنامج التخزين. هذه برامج بنية تحتية أساسية لا يمكن للمستخدمين استبدالها أو ترقيتها. علامة التنفيذ الخاصة بها صحيحة.
حسابات Sysvar هي حسابات للقراءة فقط تم تعبئتها مسبقًا بواسطة وقت تشغيل سولانا والتي تمنح البرامج وصولاً إلى حالة الشبكة الحالية. فكر في حسابات Sysvar كلوحة إعلانات حكومية في مبنى محكمة: قابلة للقراءة علنًا، وتحافظ عليها جهة موثوقة، ولكن لا يمكن لأي طرف خاص تعديلها. يوفر Clock sysvar في SysvarC1ock11111111111111111111111111111111 الطابع الزمني الحالي للجلسة ورقم الجلسة. يوفر Rent sysvar معلمات الإيجار الحالية.
| نوع الحساب | المالك | قابل للتنفيذ | الاستخدام الأساسي | مثال |
|---|---|---|---|---|
| مملوك للنظام (محفظة) | برنامج النظام | خطأ | احتفظ بالـ الرصيد الخاص بـ SOL | عنوان محفظة Phantom |
| حساب البرنامج | محمل BPF | صواب | تخزين الشيفرة الثنائية للبرنامج | برنامج رموز SPL |
| حساب البيانات | برنامج محدد | خطأ | تخزين حالة البرنامج | حساب رموز USDC |
| برنامج أصلي | وقت التشغيل (التكوين الأولي) | صواب | البنية التحتية الأساسية | برنامج التصويت |
| حساب Sysvar | وقت تشغيل Solana | خطأ | الوصول إلى حالة الشبكة | Sysvar الساعة |
البرامج عديمة الحالة على Solana. كل الحالة تعيش في حسابات البيانات التي تمتلكها وتتحكم بها. هذا الفصل بين المنطق والحالة هو قرار التصميم الذي يجعل كل شيء آخر في هذه المقالة ممكنًا.
البرامج مقابل حسابات البيانات: فصل المنطق عن الحالة
برامج Solana عديمة الحالة. لا تحتفظ بأي بيانات خاصة بها، وكل قطعة من الحالة التي تعمل عليها تعيش في حسابات بيانات منفصلة يتم تمريرها إلى البرنامج في وقت التشغيل.
فكر في برنامج Solana كبرنامج معالجة المعاملات الخاص بالبنك، وحسابات البيانات كسجلات لحسابات العملاء الفردية. يعرف البرنامج كيفية معالجة عمليات الإيداع والسحب، ولكن الرصيد الفعلي يعيش في ملف العميل، وليس داخل البرنامج نفسه. في Ethereum، ما يعادله هو بنك حيث تشترك البرامج وسجل كل عميل في نفس الغرفة المغلقة، مع فصل البرنامج وحالته بشكل لا يمكن فصله في عنوان واحد.
تحدد أربع خصائص كيفية تفاعل برامج Solana مع الحسابات:
- تعالج البرامج التعليمات وتقرأ من الحسابات الممررة إليها وقت الاستدعاء أو تكتب إليها. لا تحتفظ بحالتها الخاصة.
- البرامج غير قابلة للتغيير بمجرد نشرها، ما لم يختار المطور محمل الترقية عند النشر.
- فقط البرنامج الذي يمتلك حساب بيانات يمكنه تعديل حقل بيانات هذا الحساب. يمكن لأي مستخدم استدعاء برنامج، ولكن الوصول للكتابة إلى أي حساب يتم تقييده حسب الملكية.
- يفرض علم
executable(قابل للتنفيذ) هذا التمييز على مستوى البروتوكول ولا يمكن تغييره بعد النشر.
برامج Solana عديمة الحالة، ولكن نظام Solana ككل ذو حالة. تستمر الحالة؛ فهي تعيش في حسابات البيانات. التمييز هو أن الحالة دائمًا خارجية للبرنامج، وليست مجمعة بداخله أبدًا.
هذا الفصل له عواقب على الأداء. نظرًا لأنه يجب على كل معاملة الإعلان عن الحسابات التي ستقرأها أو تكتبها قبل بدء التنفيذ، يمكن لوقت تشغيل Sealevel تحديد المعاملات غير المتداخلة وتشغيلها في وقت واحد. الشرح الكامل لـ كيف يسمح نموذج الحساب بالتنفيذ المتوازي يتبع أدناه.
ملكية الحساب والسلطة: من يتحكم في ماذا على Solana
يحدد حقل المالك في حساب Solana البرنامج الذي لديه إذن حصري لتعديل بيانات هذا الحساب. فقط هذا البرنامج، على مستوى البروتوكول، يمكنه الكتابة إلى حقل البيانات.
يخزن حقل المالك مفتاحًا عموميًا للبرنامج بحجم 32 بايت. بالنسبة لحسابات المحافظ، المالك هو برنامج النظام. بالنسبة لحسابات الرموز، المالك هو برنامج رموز SPL. بالنسبة لحسابات البيانات المخصصة، المالك هو أي برنامج قام بإنشائها. يتم تعيين الملكية عند إنشاء الحساب ويفرضها وقت تشغيل Solana على كل معاملة.
ضع في اعتبارك صندوق ودائع آمن في بنك. يمتلك البنك الصندوق وهو الكيان الوحيد الذي يمكنه فعليًا فتح محتوياته وتعديلها. أنت تحمل مفتاحًا يتيح لك توجيه البنك بما يجب فعله بصندوقك، ولكن البنك فقط هو من يلمس المحتويات. على Solana، البرنامج هو البنك، وأنت حامل الحساب الذي لديه مفتاح.
التمييز بين المالك والسلطة يربك العديد من مطوري Ethereum:
- المالك (حقل البروتوكول): معرف البرنامج الذي يمكنه تعديل حقل
data(البيانات) للحساب. يتم تعيينه عند إنشاء الحساب. يتم فرضه بواسطة وقت تشغيل Solana، وليس بواسطة منطق أي برنامج. - السلطة (اصطلاح البيانات): مفتاح عمومي مخزن داخل حقل
data(البيانات) للحساب بواسطة البرنامج المالك. يخول عمليات محددة ضمن منطق هذا البرنامج. يتم فرضه بواسطة البرنامج نفسه، وليس وقت التشغيل.
بالنسبة لحساب رموز USDC، يعتبر برنامج الرموز هو المالك ويمكنه تعديل الرصيد المخزن في حقل البيانات. محفظتك هي سلطة التحويل، وهي مفتاح عمومي مسجل داخل حقل البيانات يتحقق منه برنامج الرموز قبل تنفيذ التحويل. هذه مفاتيح مختلفة تؤدي وظائف مختلفة. الخلط بينها هو أحد أكثر الأخطاء شيوعًا في تطوير Solana الجديد.
إيجار Solana والإعفاء من الإيجار مشروحان
الإيجار على Solana هو رسوم تخزين، مقومة بالـ lamports، يتم فرضها على الحسابات لتعويض المدققين عن صيانة الحالة داخل الكتلة. الحسابات التي تحتفظ بـ رصيد lamport أدنى، وهو عتبة الإعفاء من الإيجار، تكون معفاة بشكل دائم من رسوم الإيجار ولن يتم حذفها أبدًا بواسطة وقت التشغيل.
ما هو الإيجار على Solana؟
يجب على المدققين تخزين جميع حالات الحسابات النشطة في الذاكرة. يمكن أن تكون أعداد لا نهائية من الحسابات ذات الرصيد الصفري متجهًا لرفض الخدمة ضد الشبكة، لذلك تتطلب Solana من الحسابات الاحتفاظ بـ رصيد lamport أدنى كالتزام بدفع تكاليف التخزين. كان نموذج الإيجار الأصلي يفرض رسومًا لكل حقبة تتناسب مع حجم البيانات، مع خضوع الحسابات الأقل من الحد الأدنى لجمع القمامة. تم إهمال هذا النموذج.
اعتبارًا من معلمات Solana مينيت الحالية (التي تم إضفاء الطابع الرسمي عليها في SIMD-0084)، يجب أن تكون جميع الحسابات الجديدة معفاة من الإيجار عند الإنشاء. حقل rent_epoch (حقبة الإيجار) في بنية الحساب هو الآن حقل قديم.
لجعل حسابك معفيًا من الإيجار، قم بتمويله بـ رصيد lamport الأدنى على الأقل لحجم بياناته عند تقديم معاملة الإنشاء. في معلمات الشبكة الحالية:
- حساب بحجم 0 بايت (محفظة): حوالي 890,880 lamports (~0.00089 SOL)
- حساب بحجم 165 بايت (حساب رمز قياسي): حوالي 2,039,280 lamports (~0.00204 SOL)
- حساب بيانات بحجم 1024 بايت: حوالي 7,180,800 lamports (~0.00718 SOL)
هذه القيم تقريبية وتخضع لتغييرات في معلمات وقت التشغيل. احسب الحد الأدنى الحالي الدقيق باستخدام Solana CLI أو طريقة RPC getMinimumBalanceForRentExemption:
solana rent 0 # إعفاء من الإيجار لحساب بحجم 0 بايت
solana rent 165 # إعفاء من الإيجار لحساب رمز قياسييعمل الإعفاء من الإيجار مثل وديعة تأمين لوحدة تخزين. تقوم بتأمين رصيد lamport أدنى لضمان وجود الحساب على الشبكة. على عكس الرسوم، هذه الوديعة قابلة للاسترداد بالكامل. عندما تغلق الحساب، تعود هذه الـ lamports إليك.
يتم تعريف فئة lamport المستخدمة في جميع حسابات الإيجار في قسم تشريح الحساب. لجعل حساب بيانات معفيًا من الإيجار عندما يقوم برنامجك بإنشائه، قم باستدعاء getMinimumBalanceForRentExemption(dataSize) من جانب العميل قبل بناء معاملة الإنشاء، ثم قم بتضمين مبلغ الـ lamport هذا في التعليمات.
Solana مقابل Ethereum مقابل Bitcoin: مقارنة نماذج الحساب
ما الفرق بين حسابات Solana وحسابات Ethereum؟
في Ethereum، تقوم الـ عقود الذكية بتجميع الكود والحالة معًا في عنوان واحد. يمتلك حساب العقد كلاً من المنطق والبيانات التي يعمل عليها. على Solana، يتم دائمًا فصل الكود والحالة في حسابات منفصلة: تعيش البرامج (المنطق) في حسابات قابلة للتنفيذ، وتعيش جميع الحالات في حسابات بيانات مميزة مملوكة لتلك البرامج. هذا الفصل هو الأساس المعماري لكل ما تفعله Solana بشكل مختلف.
يتخذ Bitcoin نهجًا مختلفًا تمامًا، باستخدام نموذج UTXO (مخرجات المعاملات غير المنفقة). تشبه UTXOs الشيكات غير المنفقة في دفتر الشيكات: تستهلك كل معاملة المخرجات الموجودة وتنشئ مخرجات جديدة. لا يوجد حساب دائم يحتفظ بـ رصيد بمرور الوقت. رصيدك هو مجموع المخرجات غير المنفقة المرتبطة بمفاتيحك. يسبق نموذج Bitcoin مفهوم الحالة القابلة للبرمجة، ولهذا السبب تقتصر إمكانيات العقد الذكي الخاصة به على Bitcoin Script.
| الميزة | بيتكوين (نموذج UTXO) | إيثيريوم (نموذج EVM) | سولانا (نموذج الحساب) |
|---|---|---|---|
| وحدة تخزين الحالة | مخرجات المعاملات غير المنفقة (UTXO) | الحساب (EOA أو عقد) | الحساب (5 أنواع مختلفة) |
| المنطق والحالة | لا ينطبق (لا توجد حالة للعقد) | مدمجة في حساب العقد | منفصلة دائماً (البرنامج + حساب البيانات) |
| ملكية الحساب | يتم إنفاق الـ UTXO، ولا يمتلك بشكل دائم | متحكم به بواسطة مفتاح سري (EOA) أو كود العقد | مملوك لبرنامج النظام أو برنامج محدد |
| آلية تكلفة التخزين | لا توجد رسوم تخزين دائمة | غاز لكل عملية؛ لا يوجد إيداع | إيداع لامبورت (Lamport) للإعفاء من الإيجار (قابلة للاسترداد) |
| التنفيذ المتوازي | محدود (مسح مجموعة UTXO) | متسلسل (تعارضات الحالة العامة) | مرتفع (إعلانات الحساب المسبقة تتيح الجدولة) |
| نموذج العقد الذكي | محدود (Bitcoin Script) | كامل (Solidity، حالة مدمجة) | كامل (البرامج عديمة الحالة، الحالة خارجية) |
تشترك الشبكات المتوافقة مع EVM، بما في ذلك إيثيريوم وPolygon وBNB Chain وAvalanche C-Chain، جميعها في نفس نموذج الحساب الذي تختلف عنه سولانا. لذا تغطيهم جميعاً مقارنة واحدة.
على إيثيريوم، تسمى محافظ المستخدمين بالحسابات المملوكة خارجياً (EOAs). في سولانا، المكافئ هو حساب مملوك للنظام يتم التحكم فيه بواسطة زوج مفاتيح؛ الآلية متشابهة، ولكن يتم تعيين حقل المالك صراحةً إلى برنامج النظام بدلاً من أن يكون ضمنياً.
ما يجب على مطوري إيثيريوم التخلي عنه
هناك ثلاثة تحولات في النموذج الذهني مطلوبة قبل كتابة برنامج سولانا فعال:
- لا تحتفظ البرامج بحالتها الخاصة. بل تفعل ذلك حسابات البيانات. توقف عن البحث عن الحالة في عنوان البرنامج.
- مالك محفظتك ليس أنت على مستوى البروتوكول. أنت تتحكم في الحساب من خلال التوقيع؛ بينما يمتلك برنامج النظام حقل البيانات.
- التخزين ليس مجانياً. يتطلب كل حساب بيانات إيداع لامبورت للإعفاء من الإيجار. ضع هذه التكلفة في الحسبان عند تصميم البرامج التي تنشئ حسابات.
يعد فصل سولانا الصارم للكود عن الحالة هو المتطلب الأساسي للتنفيذ المتوازي، وهو ارتباط تم استكشافه بالكامل في قسم Sealevel والتنفيذ المتوازي.
كيف يدعم نموذج الحساب سرعة سولانا: Sealevel والتنفيذ المتوازي
يتيح نموذج حساب سولانا المعالجة المتوازية لأن كل معاملة يجب أن تعلن صراحةً عن القائمة الكاملة للحسابات التي ستقرأ منها أو تكتب فيها قبل بدء التنفيذ. يستخدم Sealevel، وهو بيئة تشغيل العقود الذكية المتوازية في سولانا، تلك الإعلانات المسبقة لتحديد المعاملات التي تلمس حسابات مختلفة وتنفيذها في وقت واحد.
إليك السلسلة السببية خطوة بخطوة:
- تتضمن معاملة سولانا قائمة كاملة بجميع الحسابات التي ستصل إليها، مع وضع علامة للقراءة فقط أو القراءة والكتابة على كل منها، قبل حدوث أي تنفيذ.
- يفحص Sealevel جميع المعاملات المعلقة في الفتحة (slot) الحالية.
- يتم ترتيب المعاملات التي تشترك في حساب واحد على الأقل للقراءة والكتابة بشكل متسلسل. أما المعاملات التي تصل إلى حسابات مختلفة تماماً، فيتم تحديدها على أنها غير متعارضة.
- يتم تنفيذ المعاملات غير المتعارضة في وقت واحد عبر نوى وحدة المعالجة المركزية المتعددة.
ينفذ نظام EVM الخاص بإيثيريوم المعاملات بشكل متسلسل مقابل حالة عامة مشتركة. ونظراً لأن حالة العقد مدمجة مع كود العقد، فإن تحديد تعارضات القراءة/الكتابة يتطلب تنفيذ المعاملة أولاً، مما يجعل الجدولة الثابتة مستحيلة قبل التنفيذ.
فكر في Sealevel مثل سوبر ماركت به العديد من ممرات الدفع. كل معاملة هي متسوق لديه قائمة معلنة من السلع. طالما أن متسوقين لا يحاولان الوصول إلى نفس السلعة، فإنهما يدفعان في وقت واحد. تعرف سولانا مسبقاً بالضبط ما تحتاجه كل معاملة، لأن نموذج الحساب يفرض ذلك الإعلان المسبق.
يوفر إثبات التاريخ (PoH)، الذي ابتكره المؤسس المشارك لسولانا أناتولي ياكوفينكو، ساعة تشفير تسمح للمصدقين بالاتفاق على ترتيب المعاملات دون تنسيق في الوقت الفعلي. تستخدم سولانا إثبات الحصة (PoS) لتحقيق الإجماع، حيث يقوم المصدقون بعملية تخزين لعملة SOL للمشاركة في إنتاج الكتل، وتستخدم PoH كطبقة توقيت. بالإضافة إلى الإعلانات المسبقة للحسابات في نموذج الحساب، تتيح هذه البنية لـ Sealevel معالجة المعاملات غير المتعارضة بالتوازي دون انتظار تأكيد على مستوى الشبكة في كل خطوة.
نموذج الحساب ليس مجرد مخطط تخزين بمعزل عن غيره. إنه المتطلب الأساسي للتوازي، وهو الجذر التقني لميزة الإنتاجية والقابلية للتوسع في سولانا.
أمثلة من الواقع: حسابات الرموز، و NFTs، و DeFi على سولانا
كل أصل على سولانا، سواء كان الرصيد من الرموز، أو NFT، أو مركز DeFi، هو حساب سولانا بتنسيق بيانات محدد. تظهر البنية التجريدية الموصوفة أعلاه في ثلاثة أنماط يواجهها كل مستخدم لسولانا.
حسابات رموز SPL
تتم إدارة رموز SPL، وهي المكافئ في سولانا لرموز ERC-20 في إيثيريوم، بواسطة برنامج رموز SPL، الذي يمتلك جميع حسابات الرموز على الشبكة. يحمل عنوان محفظتك عملات SOL فقط (لامبورتس). كل رمز تمتلكه، سواء كان USDC أو JTO أو BONK أو أي رمز آخر، يعيش في حساب رمز مخصص خاص به مملوك لبرنامج رموز SPL.
يخزن حقل بيانات حساب الرمز ثلاث معلومات: عنوان سك الرمز (أي رمز يحمله هذا الحساب)، والمفتاح العمومي لسلطة المالك (عنوان محفظتك، الذي يصرح بالتحويلات)، والرصيد الحالي للرمز. في إيثيريوم، تعيش جميع أرصدة ERC-20 لرمز معين داخل الخريطة الداخلية لعقد الرمز. في سولانا، يتطلب كل زوج (مستخدم، رمز) حسابه المخصص.
هذا هو السبب في أن محافظ سولانا تطلب منك إنشاء حساب رموز عند استلام رمز جديد لأول مرة. يتطلب هذا الإنشاء إيداع لامبورت معفى من الإيجار يبلغ حوالي 0.00204 SOL للحساب القياسي المكون من 165 بايت وفقاً لمعايير الشبكة الحالية.
حسابات الرموز المرتبطة (ATAs)
حساب الرموز المرتبط (ATA) هو حساب رموز يتم اشتقاق عنوانه (PDA) بشكل محدد من عنوان محفظتك وعنوان سك الرمز. ونظراً لأن العنوان محدد، يمكن لأي بروتوكول حساب المكان الذي يجب أن يكون فيه حساب USDC الخاص بك دون تخزين جدول بحث. تعد ATAs نوع حساب الرموز القياسي المستخدم من قبل جميع محافظ وبروتوكولات سولانا تقريباً.
تعد الـ ATAs تطبيقاً لاشتقاق PDA. يمكنك امتلاك حسابات رموز متعددة لنفس السك، ولكن حساب ATA الخاص بك هو الحساب الأساسي الذي تعتمده البروتوكولات افتراضياً.
الرموز غير القابلة للاستبدال (NFTs) على سولانا
تتكون NFT على سولانا من حسابين على الأقل: حساب سك (Mint Account) مملوك لبرنامج الرموز يحدد عرض الرمز بـ 1 بالضبط، وحساب بيانات وصفية (Metadata Account) مملوك لبرنامج Metaplex Token Metadata يخزن اسم الـ NFT ورمزها ورابط الصورة (URI) وتكوين الإتاوات. لا يتم تخزين صورة الـ NFT داخل الكتلة؛ بل يعيش الرابط الذي يشير إليها فقط في حساب البيانات الوصفية. يتم تخزين رصيد الرمز (1 NFT) في حساب رموز، مماثل لأي رمز SPL آخر.
تقوم بروتوكولات DeFi على سولانا، بما في ذلك البورصات اللامركزية ومنصات الإقراض ومجمعات السيولة، بتخزين كل مركز للمستخدم وحالة المجمع وتكوين البروتوكول في حسابات بيانات مخصصة، مع تحكم PDAs المملوكة للبرنامج في الأموال المجمعة بشكل مستقل.
لماذا يهم نموذج حساب سولانا لعملة SOL
ملاحظة: يوضح هذا القسم كيف يؤثر نموذج حساب سولانا على الفائدة التقنية لعملة SOL. لا يوجد شيء في هذا المقال يشكل نصيحة مالية أو توصية استثمارية.
نموذج الحساب ليس مجرد اهتمام للمطورين. تعمل SOL، المتوفرة في بورصات العملات الرقمية الكبرى، كرمز المنفعة الأصلي للشبكة. نموذج الحساب هو الآلية الأساسية التي يتم من خلالها طلب SOL واستخدامها في طبقة الشبكة.
يتم استخدام SOL في نموذج الحساب من خلال ثلاث آليات متميزة:
ودائع الإعفاء من الإيجار: يجب أن يحتفظ كل حساب على سولانا برصيد لامبورت ليكون موجوداً على الشبكة. ومع وجود ملايين من حسابات الرموز، وحسابات بيانات البرامج، وسجلات NFT، وحسابات حالة DeFi النشطة في أي وقت، فإن هذا يخلق طلباً أساسياً مستمراً على SOL. يتم قفل هذه الـ لامبورتس في الحسابات وإزالتها من السيولة المتداولة طالما ظلت الحسابات مفتوحة.
رسوم المعاملات: تدفع كل معاملة تنشئ حسابات أو تعدلها رسوماً أساسية بعملة lamports. يتم حرق جزء من كل رسوم بموجب هيكل الرسوم الحالي، مما يقلل من العرض المتداول مع كل معاملة.
تخزين الموثقين: يقوم الموثقون بعملية تخزين (stake) لعملة SOL للمشاركة في الإجماع بموجب آلية إثبات الحصة (Proof of Stake) الخاصة بـ Solana، ويكسبون مكافآت مقابل التحقق من انتقالات حالة الحساب عبر الشبكة.
مع نمو النشاط داخل الكتلة، وزيادة بروتوكولات DeFi، والمزيد من مجموعات NFT، والمزيد من عمليات إطلاق التوكنات، ينمو عدد الحسابات بشكل طردي. وتتطلب المزيد من الحسابات المزيد من عملة SOL المحجوزة في إيداعات الإعفاء من الإيجار.
تعمل الـ lamports المحجوزة في حسابات معفاة من الإيجار مثل التأمينات التي تحتفظ بها الشبكة: لا تُنفق، ولكن يتم الالتزام بها طالما ظلت تلك الحسابات مفتوحة. وعند إغلاق الحسابات، تعود تلك الـ lamports إلى أصحابها.
موارد هندسة Solana ذات الصلة
من الأسهل فهم حسابات التوكنات إلى جانب مكتبة برامج Solana، بينما يتم شرح التزامن في دليل معالجة Sealevel المتوازية. يمكن للقراء مراجعة صفحة سعر SOL;)، ويمكن للمستخدمين الذين يقيمون المنتجات المتعلقة بالتخزين مراجعة SOL Earn,) بشكل منفصل، بما في ذلك شروطه ومخاطره الحالية.
الأسئلة الشائعة: نموذج حساب Solana
ما الفرق بين حسابات Solana وحسابات Ethereum؟
في Ethereum، يخزن العقد الذكي كلاً من الكود والحالة الخاصة به في عنوان واحد. أما في Solana، فيكون الكود والحالة دائماً في حسابات منفصلة: البرامج هي حسابات قابلة للتنفيذ عديمة الحالة، وتعيش جميع الحالات في حسابات بيانات متميزة مملوكة لتلك البرامج. يتيح هذا الفصل لـ Sealevel تنفيذ المعاملات غير المتعارضة بالتوازي، وهو أمر غير ممكن مع نموذج الحالة المشتركة في Ethereum.
ما هو الإيجار (Rent) في Solana وكيف يعمل؟
الإيجار في Solana هو تكلفة تخزين البيانات على الشبكة، ويُقاس بالـ lamports. بدلاً من دفع رسوم جارية، يجب على الحسابات إيداع حد أدنى من الرصيد بعملة lamport مسبقاً، وهو حد الإعفاء من الإيجار، لتجنب الحذف بواسطة بيئة التشغيل. الإيداع قابل للاسترداد: عند إغلاق الحساب، تعود الـ lamports إلى المالك. بالنسبة لحساب توكن قياسي بحجم 165 بايت، يبلغ الإيداع حوالي 0.00204 SOL وفقاً لمعايير الشبكة الحالية.
ما هو العنوان المشتق من البرنامج (PDA) في Solana؟
إن PDA هو عنوان حساب Solana مشتق بشكل محدد من معرف البرنامج ومجموعة من قيم البذور (seeds). ليس له مفتاح سري مقابل، لذا فإن البرنامج الذي اشتقه هو الوحيد الذي يمكنه تفويض المعاملات نيابة عنه عبر استدعاء البرامج البينية (Cross-Program Invocation). تمنح عناوين PDA للبرامج تحكماً مستقلاً وموثوقاً في الحسابات، وهو مطلب لبروتوكولات DeFi، وضمانات NFT، وحسابات التوكنات المرتبطة.
كيف يتيح نموذج حساب Solana المعالجة المتوازية؟
يجب أن تصرح كل معاملة في Bybit عن القائمة الكاملة للحسابات التي ستقرأها أو تكتب فيها قبل التنفيذ. يستخدم Sealevel، وهو بيئة تشغيل العقود الذكية المتوازية في Solana، تلك التصريحات لتحديد المعاملات غير المتعارضة وتنفيذها في وقت واحد عبر نوى وحدة المعالجة المركزية المتعددة. لا يمكن إجراء هذه الجدولة الثابتة إلا لأن الكود والحالة يعيشان في حسابات منفصلة ومملوكة صراحةً، مما يجعل تعارضات القراءة/الكتابة قابلة للكشف قبل بدء التنفيذ.
ما هو حقل المالك (Owner) في حساب Solana؟
حقل المالك هو المفتاح العمومي المكون من 32 بايت الذي يحدد البرنامج الذي لديه سلطة تعديل حقل بيانات الحساب. بالنسبة لحسابات المحفظة، المالك هو "برنامج النظام". بالنسبة لحسابات التوكنات، المالك هو "برنامج توكن SPL". حقل المالك هو مفهوم على مستوى البروتوكول تفرضه بيئة تشغيل Solana. وهو يختلف عن حقل "السلطة" الموجود داخل حسابات بيانات معينة يديرها البرنامج مثل حسابات التوكنات.
كيف يتم استخدام SOL في نموذج الحساب؟
تُستخدم SOL في نموذج الحساب من خلال ثلاث آليات: يجب أن يمتلك كل حساب الرصيد بعملة lamport (SOL) للوجود على الشبكة؛ ويتطلب إنشاء الحسابات عملة SOL لتمويل إيداع الإعفاء من الإيجار؛ ويجب على الموثقين الذين يعالجون ويخزنون حالة الحساب تخزين (stake) عملة SOL للمشاركة في الإجماع. ومع نمو الشبكة، ينمو الطلب الهيكلي على SOL معها.
ما هو Sealevel وما علاقته بالحسابات؟
Sealevel هو بيئة تشغيل العقود الذكية المتوازية في Solana. يمكنه تنفيذ معاملات متعددة في وقت واحد لأن نموذج حساب Solana يتطلب من كل معاملة التصريح مسبقاً عن الحسابات التي ستقرأها أو تكتب فيها. يستخدم Sealevel تلك التصريحات لتحديد المعاملات غير المتعارضة وجدولتها لتعمل بالتوازي. وبدون التصريحات المسبقة لنموذج الحساب، ستكون هذه الجدولة الثابتة مستحيلة.
ما الفرق بين حساب المحفظة وحساب البرنامج في Solana؟
حساب المحفظة هو حساب مملوك للنظام مع حقل بيانات فارغ يحتفظ فقط برصيد SOL، ويتم التحكم فيه بواسطة زوج من المفاتيح. حساب البرنامج هو حساب قابل للتنفيذ مع ضبط القيمة executable = true ويحتوي على كود BPF/SBF المجمع؛ وهو مملوك لـ BPF Loader ولا يحتفظ بأي حالة خاصة به. يوضح جدول أنواع الحسابات في قسم أنواع حسابات Solana الخمسة جميع المتغيرات الخمسة جنباً إلى جنب.
كم عدد الحسابات التي يمكن لمعاملة Solana الإشارة إليها؟
يمكن لمعاملة Solana الواحدة الإشارة إلى ما يصل إلى 64 حساباً وفقاً لمعايير مينيت الحالية، بعد أن تمت زيادتها من 32 حساباً أصلياً عبر جداول البحث عن العناوين (Address Lookup Tables). يجب التصريح بكل حساب كـ "للقراءة فقط" أو "قراءة وكتابة" قبل بدء التنفيذ. هذا التصريح المسبق هو ما يسمح لـ Sealevel بجدولة التنفيذ المتوازي دون تشغيل المعاملات أولاً لاكتشاف التعارضات.
هل يمكن لحساب Solana واحد أن يحتفظ بتوكنات متعددة؟
لا. يتطلب كل نوع توكن SPL حساب توكن مخصصاً له. يحتفظ عنوان المحفظة بـ SOL فقط؛ ويتطلب كل توكن إضافي حساب توكن منفصلاً مرتبطاً بالمحفظة عبر حقل السلطة الخاص به. هذا هو السبب في أن محافظ Solana تطلب منك إنشاء حساب توكن جديد عند تلقي توكن لم تكن تمتلكه من قبل، وسبب تكلفة ذلك الإنشاء إيداع lamport بسيط معفى من الإيجار.
أهم النقاط المستفادة
- تعيش كل حالة داخل الكتلة (on-chain) على Solana في حساب يحتوي على خمسة حقول:
lamportsوdataوownerوexecutableوrent_epoch. - البرامج عديمة الحالة. وتعيش جميع الحالات في حسابات بيانات منفصلة تمتلكها البرامج وتتحكم فيها.
- تتطلب الحسابات إيداع lamport (إعفاء من الإيجار) للاستمرار على الشبكة. هذا الإيداع قابل للاسترداد عند إغلاق الحساب.
- عناوين PDA هي عناوين لا تحتوي على مفتاح سري، ويتم اشتقاقها بشكل محدد من معرف البرنامج والبذور (seeds)، ولا يمكن التوقيع عليها إلا من خلال البرنامج الذي أنشأها عبر تعليمات البرمجة البينية (CPI).
- تصرح كل معاملة عن قائمة الوصول إلى حسابها مسبقاً. يستخدم Sealevel تلك التصريحات لتنفيذ المعاملات غير المتعارضة في وقت واحد.
الخطوات التالية
- للحصول على تفاصيل التنفيذ، راجع وثائق حسابات Solana) على docs.solana.com.
- يمكن للمطورين الذين يبنون أول برنامج لهم على Solana البدء باستخدام إطار عمل Anchor,) الذي يختصر الكثير من الأكواد البرمجية المتكررة لإدارة الحسابات (تتم كتابة البرامج بلغة Rust أو C/C++).
- للحصول على وصفات برمجية عملية وأمثلة تطبيقية بلغة JavaScript/TypeScript، يوفر Solana Cookbook) مواد مرجعية تطبيقية.