بنية سولانا: 8 ابتكارات وراء سرعة SOL

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

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

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

النقاط الرئيسية

تعتمد بنية سولانا على ثمانية ركائز، كل منها يحل عنق زجاجة أداء محدد:

1. إثبات التاريخ (PoH): ساعة تشفيرية تحدد طوابع زمنية للأحداث قبل تشغيل آلية التوافق.
2. Tower BFT: آلية توافق تستخدم طوابع PoH الزمنية في التصويت.
3. Turbine: نشر كتل يقسم الكتل إلى حزم أصغر.
4. Gulf Stream: إعادة توجيه معاملات بناءً على القادة المجدولين.
5. Sealevel: رانتايم لتنفيذ العقود الذكية بشكل متوازٍ.
6. Pipelining: معالجة معاملات مرحلية.
7. Cloudbreak: قاعدة بيانات حسابات مصممة للوصول المتزامن.
8. Archivers: اقتراح تخزين موزّع تاريخي.

ملاحظة الأداء: تختلف معدلات TPS التاريخية النظرية، ووقت الهدف للفتحة، والتأكيد، والنهائية، والرسوم الأساسية، والرسوم ذات الأولوية. تحقق من المقاييس الحالية المؤرخة والمنهجية وراءها.

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

المشكلة التي صُممت سولانا لحلها

تواجه البلوكتشين تقليديًا قيدًا أساسيًا: "البلوك تشين والمعضلة الثلاثية"، وهو مفهوم روّج له فيتاليك بوتيرين، ينص على أنه يمكن للشبكة تحقيق خاصيتين كحد أقصى من ثلاث خصائص في وقت واحد. هذه الخصائص هي قابلية التوسع (إنتاجية عالية)، والأمان (مقاومة الهجوم)، واللامركزية (التحكم الموزع). فكر في الأمر كمثلث حيث يؤدي دفع زاوية إلى الخارج دائمًا إلى سحب الزاويتين الأخريين إلى الداخل. تعالج شبكة بيتكوين حوالي 7 معاملات في الثانية (TPS) مع أوقات كتلة تبلغ 10 دقائق، مع إعطاء الأولوية للأمان واللامركزية على حساب الإنتاجية. عالجت شبكة إيثيريوم حوالي 15-30 معاملة في الثانية (TPS) على طبقتها الأساسية قبل إضافة حلول التوسع، كما أعطت الأولوية للأمان واللامركزية.

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

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

ركائز بنية سولانا الثمانية: نظرة عامة

يغطي الإطار التاريخي المكون من ثمانية أجزاء إثبات التاريخ، وآلية التوافق Tower BFT، وبروتوكول Turbine، وبروتوكول Gulf Stream، ورانتايم Sealevel، وتقنية Pipelining، وقاعدة بيانات Cloudbreak، وبروتوكول Archivers. لا ينبغي افتراض أن كل عنصر سيظل نظامًا فرعيًا منفصلاً مطبقًا حاليًا، خاصة اقتراح Archivers.

1. إثبات التاريخ (Proof of History): سلسلة تجزئة SHA-256 متسلسلة تنشئ سجل طابع زمني قابل للتحقق قبل تشغيل آلية التوافق.
2. Tower BFT: آلية توافق معززة بـ PoH (إثبات التاريخ) قائمة على تحمل الأخطاء البيزنطية (Byzantine Fault Tolerant) تستخدم طوابع PoH الزمنية للتصويت بكفاءة.
3. Turbine: بروتوكول نشر كتل مستوحى من BitTorrent يقوم بتقسيم الكتل إلى حزم صغيرة مشفرة قابلة للمحو تسمى "shreds".
4. Gulf Stream: بروتوكول إعادة توجيه معاملات خالٍ من الميمبول (mempool-less) يوجه المعاملات مباشرة إلى قادة المدققين القادمين.
5. Sealevel: رانتايم لتنفيذ العقود الذكية بشكل متوازٍ يقوم بتشغيل آلاف البرامج غير المتعارضة في وقت واحد.
6. Pipelining: نظام تحسين التحقق من المعاملات (TVO) يقوم بمعالجة المعاملات عبر أربع مراحل للأجهزة المتزامنة.
7. Cloudbreak: قاعدة بيانات حسابات قابلة للتوسع أفقيًا تستخدم ملفات معينة في الذاكرة (memory-mapped files) لدعم القراءات والكتابات المتزامنة.
8. Archivers: اقتراح تاريخي لتخزين توزيع دفتر الأستاذ باستخدام مفاهيم إثبات النسخ (proof-of-replication).

يتم تغطية كل ركيزة بعمق في الأقسام أدناه.

إثبات التاريخ (PoH): محرك التوقيت في سولانا

إثبات التاريخ (PoH) هو سلسلة تجزئة SHA-256 متسلسلة تنشئ سجلًا قابلاً للتحقق ومنظمًا زمنيًا للأحداث قبل تشغيل آلية التوافق، ويعمل كساعة تشفير مشتركة للشبكة بأكملها. PoH ليس آلية التوافق الخاصة بسولانا؛ هذا الدور ينتمي إلى Tower BFT. PoH هو طبقة التوقيت التي تجعل Tower BFT سريعة.

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

من الناحية الفنية، PoH هي سلسلة تجزئة SHA-256 متسلسلة حيث يصبح كل ناتج هو المدخل للحساب التالي. نظرًا لأنه لا يمكن موازاة SHA-256 في هذا الشكل المتسلسل، فإن طول السلسلة هو سجل غير قابل للتلاعب بالوقت المنقضي. المدقق الذي ينتج سلسلة من N تجزئات يكون قد قضى بشكل واضح الوقت اللازم لحساب N عملية تجزئة متسلسلة. لا توجد اختصارات. وصف أناتولي ياكوفينكو هذه الآلية لأول مرة في ورقته البحثية لشهر نوفمبر 2017، "إثبات التاريخ: ساعة للبلوكتشين" (https://solana.com/solana-whitepaper.pdf).

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

من خلال إنشاء مرجع ترتيب قابل للتحقق، يمكن لـ PoH تقليل بعض التنسيق الزمني. لا تزيل رسائل التوافق أو تضمن بشكل مباشر وقتًا معينًا للفتحة أو التأكيد أو النهائيّة.

توضيح حاسم: توصف سولانا أحيانًا بأنها "البلوكتشين الخاصة بإثبات التاريخ"، مما يعني أن PoH يحل محل إثبات الحصة (PoS). هذا غير صحيح. سولانا هي بلوكتشين لإثبات الحصة على مستوى أمانها الاقتصادي. يقوم المدققون بتخزين SOL كضمان ويواجهون خفضًا (slashing) للسلوك غير الأمين. PoH هي الساعة التشفيرية التي تجعل آلية التوافق الخاصة بسولانا، المطبقة من خلال Tower BFT، أسرع وأكثر كفاءة. كلا الطبقتين ضروريتان؛ لا يحل أي منهما محل الآخر.

Tower BFT: آلية التوافق الخاصة بسولانا

Tower BFT هي آلية التوافق الخاصة بسولانا: نسخة محسّنة بـ PoH من تحمل الخطأ البيزنطي العملي (pBFT) التي تستخدم سجل PoH الزمني كساعة مشتركة، مما يسمح للمدققين بالتصويت على حالة دفتر الأستاذ دون تبادل رسائل مزامنة الساعة.

يصف تحمل الخطأ البيزنطي (BFT) خاصية النظام الموزع التي تسمح له بالوصول إلى التوافق بشكل صحيح حتى عندما يتصرف بعض المشاركين بشكل ضار أو غير متوقع، ويُطلق عليه هذا الاسم نسبةً إلى مشكلة الجنرالات البيزنطيين في الحوسبة الموزعة. تتطلب خوارزميات pBFT التقليدية تبادل رسائل مكثف بين العقد لإنشاء رؤية مشتركة للوقت، مما يجعلها غير عملية على نطاق واسع. تستبدل Tower BFT سجل PoH بتبادل الرسائل هذا. يشارك المدققون بالفعل ساعة PoH؛ لا يحتاجون إلى التفاوض على الطوابع الزمنية.

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

يتحمل Tower BFT سلوكًا بيزنطيًا يصل إلى ثلث مجموعة المدققين. إذا تصرف أقل من ثلث المدققين بشكل ضار، فإن الشبكة تصل إلى توافق صحيح. هذه العتبة تنبع من المتطلبات الرياضية لمشكلة الجنرالات البيزنطيين، والتي صاغها في الأصل لامبورت وشستاك وبيز في عام 1982. سلسلة التوافق للباحثين: أسس pBFT (كاسترو وليسكوف، 1999) الخوارزمية الأساسية؛ حسنت المتغيرات اللاحقة بما في ذلك HotStuff و Tendermint عليها؛ Tower BFT (2017) تتخذ خطوة إضافية تتمثل في إزالة الحمل الزائد لمزامنة الساعة من خلال PoH.

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

Turbine: انتشار الكتل على نطاق واسع

سيؤدي بث كتلة كاملة إلى كل مدقق عند 65,000 معاملة في الثانية نظريًا إلى إنشاء عنق زجاجة في عرض النطاق الترددي ينمو خطيًا مع حجم الشبكة. يحل Turbine هذه المشكلة بنفس الطريقة التي يحل بها BitTorrent توزيع الملفات الكبيرة: عن طريق تقسيم البيانات إلى أجزاء صغيرة ونشر حمل الانتشار عبر الشبكة.

Turbine هو بروتوكول انتشار الكتل الخاص بسولانا، مستوحى من نموذج التوزيع القائم على الأجزاء الخاص بـ BitTorrent. بدلاً من أن يقوم قائد واحد ببث كتلة كاملة إلى كل مدقق في وقت واحد، يقسم Turbine الكتل إلى حزم صغيرة مرمزة بالمسح تسمى "shreds" ويوزعها عبر شبكة مدققين ذات هيكل شجري.

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

لا يؤدي توسيع مجموعة المدققين إلى زيادة متناسبة في متطلبات عرض النطاق الترددي لكل عقدة. لا تتطلب شبكة تضم 2000 مدقق من كل مدقق التعامل مع 2000 ضعف عرض النطاق الترددي لنظام مركزي. توزع شجرة الانتشار الحمل. هيكل "shreds" الخاص بـ Turbine ذو صلة لمشغلي المدققين عند تخطيط سعة استقبال البيانات وإعادة بناء الكتل.

Gulf Stream: إعادة توجيه المعاملات بدون ميمبول

يستخدم Gulf Stream إعادة توجيه مدركة للقائد بدلاً من ميمبول عالمي مشترك تقليدي. هذا يغير نموذج الانتظار ولكنه لا يلغي الازدحام أو حوافز ترتيب المعاملات.

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

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

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

يغيّر عدم وجود ميمبول أنماط تقديم المعاملات للمطورين الذين يبنون على سولانا. تتمتع المعاملات بمسار إعادة توجيه متوقع، مما يتيح التأكيد المتفائل قبل النهائيّة الكاملة. مساحة سطح MEV على سولانا أصغر بكثير من إيثيريوم، وإن لم تكن صفرًا؛ يخلق ترتيب المعاملات الموزون بالتخزين ديناميكيات خاصة به يجب على مصممي dApp دراستها قبل البناء.

Sealevel: تنفيذ العقود الذكية المتوازي

Sealevel هو محرك التنفيذ المتوازي للعقود الذكية الخاص بسولانا، وهو المحرك الذي يشغّل البرامج داخل الكتلة (مصطلح سولانا لما تسميه إيثيريوم العقود الذكية). على عكس EVM الخاص بإيثيريوم، الذي ينفذ العقود بشكل تسلسلي واحدة تلو الأخرى، ينفذ Sealevel آلاف البرامج غير المتعارضة في وقت واحد عبر نوى GPU و CPU المتاحة.

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

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

تُكتب البرامج داخل الكتلة بشكل أساسي بلغة Rust، وتُترجم إلى بايت كود Berkeley Packet Filter (BPF)، وتُنفذ بواسطة وقت تشغيل Sealevel. التنفيذ المتوازي عبر نوى GPU و CPU هو ما يجعل 65,000 معاملة في الثانية (TPS) النظرية قابلة للتحقيق فعليًا على مستوى الأجهزة.

ما يعنيه هذا للمطورين

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

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

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

التوروبيب: التحقق من المعاملات كخط تجميع

خط تجميع السيارات لا يبني سيارة واحدة بالكامل قبل البدء بالسيارة التالية. كل محطة (لحام، طلاء، تركيب داخلي) تعمل على سيارة مختلفة في وقت واحد. تطبق سولانا هذا المنطق نفسه على التحقق من المعاملات من خلال تحسين التحقق من المعاملات (TVO).

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

المراحل الأربع هي:

1. الجلب: وحدة في مساحة النواة تجلب بيانات المعاملات الواردة من الشبكة
2. التحقق من التوقيع (SigVerify): تقوم وحدة معالجة الرسوميات (GPU) بالتحقق من التوقيعات التشفيرية عبر الدفعة بالتوازي
3. الخدمة المصرفية: تقوم وحدة المعالجة المركزية (CPU) بمعالجة منطق المعاملة، والتحقق من أرصدة الحسابات، وتحديث حالة الحساب
4. تأكيد الكتابة: يقوم القرص بكتابة تغييرات الحالة النهائية

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

يعد التوروبيب أحد الأعمدة الثلاثة، إلى جانب Sealevel و Gulf Stream، التي تنتج معًا القدرة الإجمالية لمعالجة المعاملات في سولانا. تستخلص سولانا إنتاجية أكبر من نفس الأجهزة عن طريق إبقاء كل مكون معالجة يعمل طوال الوقت، بدلاً من السماح لأي مرحلة بالبقاء خاملة بين الدفعات.

Cloudbreak: قاعدة بيانات حسابات قابلة للتوسع أفقيًا

Cloudbreak هو نظام الملفات الذي يسمح لمعالجات سولانا المتوازية بقراءة وكتابة بيانات الحسابات في وقت واحد دون الحاجة إلى قوائم انتظار. بدونها، ستؤدي طبقة التخزين إلى تسلسل جميع عمليات قراءة وكتابة الحسابات، وستتبدد مكاسب التوازي التي يحققها Sealevel عند حدود قاعدة البيانات.

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

يتم توزيع الحسابات عبر هياكل بيانات متعددة يمكن الوصول إليها بالتوازي. يسمح الإدخال/الإخراج المعين في الذاكرة لنظام التشغيل لـ Cloudbreak بمعاملة بيانات الحساب الموجودة على القرص كما لو كانت في ذاكرة الوصول العشوائي، مما يلغي زمن الوصول إلى البحث ويمكّن الوصول المتزامن على مستوى الخيوط. عندما يقوم Sealevel بجدولة 10,000 معاملة متوازية، تعالج Cloudbreak 10,000 عملية قراءة وكتابة للحسابات متزامنة دون تسلسل الطلبات في قائمة انتظار.

هندسة قاعدة البيانات ووقت تشغيل التنفيذ مترابطتان: لا يقدم أي منهما إنتاجية بدون الآخر. تتطلب أنماط الإدخال/الإخراج الخاصة بـ Cloudbreak أقراص NVMe SSD عالية الأداء. لا يمكن لمحركات الأقراص الدوارة القياسية تحمل إنتاجية القراءة/الكتابة العشوائية التي يتطلبها نموذج الوصول المتزامن لـ Cloudbreak. فهم نموذج حسابات Cloudbreak هو أساس تصميم برامج سولانا: كل الحالة موجودة في كائنات حسابات منفصلة، تعمل البرامج بدون حالة على تلك الحسابات، وقرارات تخطيط الحسابات تؤثر مباشرة على أداء القراءة/الكتابة في وقت التشغيل.

Archivers: اقتراح تخزين تاريخي

يظهر مفهوم Archivers في مواد تصميم سولانا المبكرة ولكنه لا ينبغي تقديمه كنظام فرعي منتج مطبق حاليًا بدون دليل أساسي حديث.

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

مع وجود جميع الأعمدة المعمارية الثمانية في مكانها، ينتج النظام المجمع معايير أداء تفصل سولانا عن معظم سلاسل الكتل العامة الأخرى، والتي يحددها القسم التالي كميًا.

معايير أداء سولانا: المعاملات في الثانية، الرسوم، ونهائية الكتلة

~65,000 معاملة في الثانية (TPS) في معايير الأداء النظرية التاريخية هي الحد الأقصى النظري لسولانا في ظروف معملية مثالية، وليست رقمًا مستدامًا في العالم الحقيقي. هذا التمييز مهم لأي شخص يستخدم هذه الأرقام في تحليل الاستثمار أو تصميم النظام.

استخدم مصادر أساسية حالية ومنهجية قياس متسقة للمقارنات بين الأداء.

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

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

يزيد نظام الطبقة الثانية من Ethereum (بما في ذلك منصة Arbitrum وOptimism) وترقيات التجزئة المستقبلية من إنتاجية Ethereum الفعلية بما يتجاوز رقم الطبقة الأساسية بكثير. يجب أن يأخذ أي مقارنة كاملة في الاعتبار تلك السعة الموسعة عند تقييم المنصتين لحالة استخدام محددة.

من الهندسة المعمارية إلى التطبيق: كيف يُمكّن تصميم Solana حالات الاستخدام الحقيقي

تنتج خيارات Solana المعمارية نتائج محددة وقابلة للقياس للتطبيقات المبنية عليها، وليست أرقام أداء مجردة.

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

DeFi: يمكن لوقت تشغيل Solana معالجة المعاملات غير المتعارضة بالتوازي، بينما يمكن أن تدعم الرسوم المنخفضة عمومًا التفاعلات المتكررة. يشمل وقت استجابة المبادلة الفعلي وتكلفتها التوجيه، والانزلاق السعري، ورسوم الأولوية، والمعاملات الفاشلة، وحساب البرنامج، وظروف السوق. لا تلغي تقنية Gulf Stream مخاطر القيمة المستخرجة من المعدنين (MEV) أو التشغيل الاستباقي.

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

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

الخيارات المعمارية نفسها التي تُمكّن هذه التطبيقات تأتي أيضًا مع مقايضات موثقة، والتي يتناولها القسم التالي دون تلطيف.

المقايضات المعمارية: موثوقية الشبكة، واللامركزية، والسرعة

شهدت Solana انقطاعات موثقة في الشبكة منذ إطلاق مينيت في مارس 2020، والتي نجمت بشكل أساسي عن فيضانات المعاملات التي أنشأتها البوتات والتي أرهقت ذاكرة المدققين وتسببت في خروج المدققين عن الإجماع.

انقطاعات الشبكة

يعالج تصميم الإنتاجية العالية في Solana المعاملات بأدنى حد من التصفية المسبقة، مما يخلق نقطة ضعف محددة. عندما تغمر البوتات الشبكة بمعاملات عشوائية، يمكن للمدققين استنفاد الذاكرة المتاحة قبل وصول المعاملات إلى مرحلة التصفية، مما يتسبب في توقف الإجماع. تشمل الانقطاعات الرئيسية الموثقة انقطاعًا في سبتمبر 2021 استمر حوالي 17 ساعة، ناتجًا عن زيادة في حجم المعاملات من حدث عرض عملة أولي (IDO) مدفوع بالبوتات، وانقطاعًا في يناير 2022 متعلقًا بالمعاملات المكررة المفرطة من المدققين. حدثت انقطاعات إضافية أقصر في عامي 2022 و2023.

نفذت Solana Labs حلين معماريين أساسيين للتخفيف من حدة هذه المشكلة. حل بروتوكول شبكة QUIC محل UDP لاستيعاب المعاملات، مما يوفر تحكمًا في التدفق على مستوى الاتصال يحد من عدد المعاملات التي يمكن لأي مصدر واحد إرسالها. تعطي جودة الخدمة المرجحة بالتخزين (QoS) الأولوية لإعادة توجيه المعاملات من المدققين الذين لديهم حصص SOL أكبر، مما يجعل إغراق البريد العشوائي من قبل المصادر ذات التخزين المنخفض أقل فعالية. تخلق أسواق الرسوم لوحدات الحساب احتكاكًا اقتصاديًا ضد البريد العشوائي في الأحجام العالية. انخفض تكرار الانقطاع منذ نشر هذه الحلول التخفيفية. يظل تاريخ الانقطاع عامل خطر معروف للتطبيقات التي تتطلب توفرًا عاليًا ومستمرًا.

مخاوف مركزية المدققين

يتطلب مدققو Solana أجهزة قوية. وفقًا لـ وثائق مدققي مؤسسة Solana Foundation,)، تتضمن المواصفات الموصى بها ذاكرة رام سعة 128 جيجابايت فأكثر، وقرص NVMe SSD عالي الأداء، واتصال إنترنت عالي النطاق الترددي. تحقق من المواصفات الحالية في وقت القراءة، حيث تتطور المتطلبات مع ترقيات البروتوكول. تتجاوز هذه المتطلبات بشكل كبير ما يحتاجه مدققو Ethereum للمشاركة في إجماع إثبات الحصة (PoS).

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

البلوك تشين والمعضلة الثلاثية

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

يُعد تاريخ الانقطاعات، والضغوط المركزية الناتجة عن متطلبات أجهزة المدقق، والتموضع في المعضلة الثلاثية مدخلات جوهرية لأي تقييم فني دقيق لشبكة Solana.

Solana ضد Ethereum ضد Bitcoin: مقارنة الهندسة المعمارية

تعطي المعايير التاريخية لـ Solana ملف إنتاجية في الطبقة الأساسية أعلى من مينيت Ethereum، لكن القياسات ليست متشابهة تمامًا. يوفر PoH ترتيبًا مسبقًا للإجماع، ويدير Sealevel الأعمال غير المتعارضة في وقت واحد، وتغير إعادة التوجيه المدركة للقائد توجيه المعاملات. أرقام المعاملات في الثانية (TPS) التي غالبًا ما يتم الاستشهاد بها بحوالي 65,000 و15-30 هي نقاط مرجعية قديمة تعتمد على المنهجية وليست خصائص دائمة للشبكة.

نموذج الإنتاجية والتنفيذ

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

مقارنة منصة المطورين

يعد نظام المطورين في Ethereum (Solidity، وأدوات EVM، وبروتوكولات DeFi القائمة مع سنوات من الكود المدقق) أكبر وأكثر نضجًا من نظام Solana. يوفر نموذج Rust وSealevel في Solana إنتاجية أعلى في الطبقة الأساسية ورسومًا أقل، ولكنه يتطلب فهم نموذج الحسابات ومتطلبات إعلان الوصول إلى الحساب، والتي ليس لها معادل مباشر في Ethereum. التطبيقات التي تكون فيها الإنتاجية وتكلفة الرسوم هي القيود الملزمة تناسب بنية Solana جيدًا. التطبيقات التي تعطي الأولوية للتوافق مع EVM، أو أوسع مجموعة من المواهب البرمجية، أو أقصى قدر من اللامركزية في الطبقة الأساسية تناسب الطبقة الأساسية لـ Ethereum أو نظام الطبقة الثانية الخاص بها بشكل أفضل.

Bitcoin كنقطة مرجعية ثالثة

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

للمقارنة الكاملة للبيانات عبر الأبعاد الخمسة، راجع جدول معايير الأداء أعلاه.

أسئلة متكررة حول بنية سولانا

ما هو إثبات التاريخ (Proof of History) في سولانا؟

إثبات التاريخ (PoH) هو سلسلة تجزئة SHA-256 متسلسلة تنشئ سجلاً موثوقًا ومرتبًا زمنيًا للأحداث قبل تشغيل آلية التوافق. يعمل كساعة تشفير مشتركة عبر شبكة المدققين، مما يسمح للمدققين بمعالجة المعاملات دون تبادل رسائل الطوابع الزمنية. PoH ليس آلية التوافق الخاصة بسولانا. تتولى Tower BFT آلية التوافق، باستخدام الطوابع الزمنية لـ PoH كمرجع زمني مشترك.

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

شارك في تأسيس سولانا كل من أناتولي ياكوفينكو وجريج فيتزجيرالد. وصف ياكوفينكو، مهندس كوالكوم سابق عمل على الأنظمة الموزعة ومزامنة الساعة، آلية إثبات التاريخ لأول مرة في ورق أبيض في نوفمبر 2017. تقود شركة Solana Labs، الشركة التطويرية الربحية التي شاركا في تأسيسها، هندسة البروتوكول. تدعم مؤسسة سولانا، وهي منظمة غير ربحية منفصلة مقرها في جنيف، تطوير النظام البيئي.

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

تجمع المواد المبكرة البنية في إثبات التاريخ، و Tower BFT، و Turbine، و Gulf Stream، و Sealevel، و Pipelining، و Cloudbreak، و Archivers. هذا إطار توضيحي تاريخي، وليس دليلاً على أن كل عنصر مسمى - وخاصة Archivers - يظل نظامًا فرعيًا منفصلاً تم نشره اليوم.

Tower BFT هي آلية التصويت واختيار الانقسام (fork-choice) الخاصة بسولانا الموزونة بالحصص (stake-weighted)، والمبنية حول فتحات PoH وزيادة مهلات التصويت. لا تفترض تطبيقًا معينًا للتقليم التلقائي (slashing) أو تعامل المدققين بالتساوي: العتبات البيزنطية موزونة بالحصص، وتتطلب افتراضات السلامة والحيوية معالجة أكثر دقة.

يصف Gulf Stream إعادة توجيه المعاملات المدركة للقادة بدلاً من ميمبول (mempool) عالمي تقليدي. قد يقلل من بعض قوائم الانتظار، ولكنه لا يلغي منافسة رسوم الأولوية، أو الازدحام، أو إسقاط المعاملات، أو MEV، أو مخاطر المقدمات. يجب التحقق من سلوك الشبكة الحالي من وثائق التنفيذ.

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

نعم. تستخدم سولانا إثبات الحصة (PoS) كطبقة الأمان الاقتصادي الخاصة بها. يقوم المدققون بتخزين (stake) عملة SOL كضمان ويواجهون عقوبات تقليم (slashing) للسلوك غير الأمين أو غير المتناسق. إثبات التاريخ هو آلية منفصلة لحفظ الوقت التشفيري تجعل آلية توافق سولانا أسرع. PoH لا يحل محل PoS؛ بل يعزز كفاءة Tower BFT، آلية التوافق القائمة على PoS.

كانت انقطاعات شبكة سولانا الموثقة ناجمة بشكل أساسي عن تدفقات المعاملات التي تم إنشاؤها بواسطة الروبوتات (bots) والتي أدت إلى إغراق ذاكرة المدققين، مما تسبب في خروج المدققين من آلية التوافق. يضع التصميم عالي الإنتاجية للبنية المعمارية المعاملات بأقل قدر من التصفية المسبقة، مما يخلق نقطة ضعف لهجمات البريد العشوائي بكميات كبيرة. نفذت Solana Labs شبكات QUIC وجودة خدمة موزونة بالحصص (stake-weighted QoS) كإجراءات تخفيف معمارية قللت من تكرار الانقطاعات. راجع قسم المقايضات المعمارية للحصول على أحداث موثقة محددة.

الاختلافات المعمارية الأساسية هي نموذج التنفيذ (Sealevel المتوازي مقابل EVM التسلسلي)، وتوجيه المعاملات (Gulf Stream بدون ميمبول مقابل ميمبول عالمي)، ولغة البرمجة (Rust مقابل Solidity)، والإنتاجية الأساسية (حوالي 65000 TPS نظري مقابل 15-30 TPS). تستخدم كلتا البلوكتشين إثبات الحصة للأمان الاقتصادي. النظام البيئي الأكبر للمطورين في الإيثيريوم وخيارات الطبقة الثانية (Layer-2) تخدم المشاريع المتوافقة مع EVM بشكل جيد؛ الإنتاجية الأساسية في سولانا وهيكلها الرسومي تخدم التطبيقات التي تكون فيها حجم المعاملات والتكلفة هي القيود الأساسية.

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

تتم كتابة البرامج داخل الكتلة (on-chain programs) في سولانا بشكل أساسي بلغة Rust، ويتم تجميعها إلى بايت كود Berkeley Packet Filter (BPF)، ويتم تنفيذها بواسطة بيئة تشغيل Sealevel. C و C++ مدعومتان أيضًا. إطار عمل Anchor، وهو مجموعة أدوات قائمة على Rust توفر وحدات ماكرو وتجريدات تبسط أنماط البرامج الشائعة، هو مجموعة الأدوات الأكثر استخدامًا للتطوير. بالنسبة لأدوات النظام البيئي الحالية، راجع وثائق مطوري سولانا.

تشمل تكلفة معاملة سولانا رسمًا أساسيًا وقد تشمل تكاليف الأولوية والتكاليف المتعلقة بالحوسبة. تتغير القيمة بالدولار الأمريكي مع سعر SOL، بينما يؤثر الازدحام وسلوك التطبيق على تكلفة التنفيذ الإجمالية. Gulf Stream لا يلغي منافسة الرسوم.

حتى وقت كتابة هذا التقرير، تضم سولانا أكثر من 1000 مدقق نشط. تحقق من العدد الحالي والتوزيع عبر إحصائيات مدققي مؤسسة سولانا.) . يتطلب المدققون استثمارًا كبيرًا في الأجهزة، بما في ذلك 128+ جيجابايت من ذاكرة الوصول العشوائي (RAM) وأقراص NVMe SSD عالية الأداء، مما يخلق حاجز دخول أعلى من معظم سلاسل إثبات الحصة الأخرى وهو المصدر الرئيسي لمخاوف اللامركزية المستمرة.

استكشف SOL على Bybit

يمكن للقراء مراجعة معلومات سوق SOL الحالية) أو سوق SOL/USDT الفوري (Spot) .). توفر هذه الروابط الوصول إلى السوق ولا تثبت أن سولانا، أو محفظة، أو بروتوكول طرف ثالث (third-party) مناسب لكل قارئ.

تجمع بنية سولانا بين العديد من القرارات التصميمية المترابطة. يوفر PoH مرجع ترتيب، وتقوم Sealevel بتوازي التنفيذ غير المتعارض، ويغير التوجيه المدرك للقادة توجيه المعاملات، وتعالج Pipelining و Cloudbreak و Turbine المعالجة والتخزين والانتشار. يجب أن يتم تضمين تاريخ الانقطاعات الموثق ومتطلبات موارد المدقق في نفس التقييم الفني الذي يتم فيه تقييم فوائد الأداء.

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

بالنسبة للباحثين، يظل إثبات التاريخ: ساعة للبلوكتشين (نوفمبر 2017) لأناتولي ياكوفينكو المصدر الأساسي الأصلي لتصميم PoH. تحتفظ Solana Labs بالوثائق المعمارية الحالية على docs.solana.com. تنشر مؤسسة سولانا إحصائيات شبكة المدققين على solana.org/validators. تتوفر بيانات الشبكة في الوقت الفعلي عبر Solana Beach.

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

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

قراءات ذات صلة

• إثبات تاريخ سولانا
• آلية توافق سولانا
• SolanaVM
• سرعة سولانا