تحليل بنية تكنولوجيا Solana: الأداء العالي والتحديات المتزامنة، تطوير البيئة يشهد فرصًا جديدة

إعادة تفسير بنية تقنية Solana: هل ستشهد ربيعاً ثانياً؟

Solana هو منصة بلوكتشين عالية الأداء ، تستخدم بنية تقنية فريدة لتحقيق معدل نقل عالٍ وزمن استجابة منخفض. تشمل تقنيتها الأساسية خوارزمية Proof of History (POH) التي تضمن ترتيب المعاملات وساعة عالمية ، وجدول تدوير القائد وآلية توافق Tower BFT التي تعزز معدل إنتاج الكتل. تعمل آلية Turbine على تحسين انتشار الكتل الكبيرة من خلال ترميز Reed-solomon. تسارع Solana Virtual Machine (SVM) ومحرك التنفيذ المتوازي Sealevel من سرعة تنفيذ المعاملات. هذه كلها تصميمات معمارية لتمكين Solana من تحقيق أداء عالٍ ، ولكنها أيضًا جلبت بعض المشكلات مثل تعطل الشبكة ، وفشل المعاملات ، ومشكلات MEV ، ونمو الحالة بسرعة كبيرة ومشكلات التركيز ، وسنوضح في هذه المقالة المشكلات الناتجة عن هذه الآلية.

إعادة تفسير بنية تكنولوجيا Solana: هل ستشهد ربيعًا ثانيًا؟

تتطور بيئة Solana بسرعة، حيث شهدت جميع مؤشرات البيانات نمواً سريعاً في النصف الأول من العام، خاصة في مجالات DeFi والبنية التحتية وGameFi/NFT وDePin/AI وتطبيقات المستهلك. توفر TPS العالية لـ Solana واستراتيجيتها الموجهة لتطبيقات المستهلك، بالإضافة إلى البيئة البيئية ذات التأثير العلامي الضعيف، فرصاً غنية لرواد الأعمال والمطورين. في مجال تطبيقات المستهلك، عرضت Solana رؤيتها لدفع استخدام تقنية blockchain في مجالات أوسع. من خلال دعم مثل Solana Mobile وSDK المصمم خصيصاً لتطبيقات المستهلك، تسعى Solana إلى دمج تقنية blockchain في التطبيقات اليومية، مما يزيد من قبول المستخدمين وراحتهم. على سبيل المثال، تقدم تطبيقات مثل Stepn تجارب جديدة في اللياقة البدنية والتواصل الاجتماعي من خلال دمج blockchain والتكنولوجيا المحمولة. على الرغم من أن العديد من تطبيقات المستهلك لا تزال تبحث عن أفضل نماذج الأعمال وتحديد السوق، إلا أن المنصة التقنية والنظام البيئي الذي تقدمه Solana يوفر بلا شك دعماً قوياً لهذه المحاولات الابتكارية. مع استمرار تقدم التكنولوجيا ونضوج السوق، من المتوقع أن تحقق Solana المزيد من الإنجازات والحالات الناجحة في مجال تطبيقات المستهلك.

إعادة تفسير بنية تقنية Solana: هل ستشهد ربيعها الثاني؟

على الرغم من أن سولانا قد حصلت على حصة سوقية كبيرة في صناعة blockchain بفضل قدرتها العالية على معالجة المعاملات وتكاليفها المنخفضة، إلا أنها تواجه أيضًا منافسة شديدة من سلاسل الكتل الناشئة الأخرى. تعتبر إحدى منصات التداول منافسًا محتملاً في نظام EVM، حيث يتزايد عدد العناوين النشطة على شبكتها بسرعة، بينما حقق إجمالي قيمة القفل (TVL) في مجال DeFi على سولانا أعلى مستوى له على الإطلاق، إلا أن المنافسين مثل إحدى منصات التداول الأخرى يكتسبون حصة سوقية بسرعة، كما أن التمويل في نظام إحدى منصات التداول تجاوز سولانا لأول مرة في الربع الثاني.

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

الهيكل الفني

تشتهر Solana بخوارزمية POH، وآلية الإجماع Tower BFT، وشبكة نقل البيانات Trubine، وSVM الافتراضية التي توفر TPS عالية وFinality سريعة. سنقوم بتقديم لمحة موجزة عن كيفية عمل كل من هذه المكونات، وكيف تحقق هدف أدائها العالي في تصميم المعمارية، بالإضافة إلى العيوب والمشاكل المشتقة الناتجة عن هذا التصميم المعماري.

إعادة تفسير بنية تقنية Solana: هل ستأتي ربيعها الثاني؟

خوارزمية POH

POH (Proof of History) هي تقنية تحدد الوقت العالمي، وليست آلية توافق، بل هي خوارزمية تحدد ترتيب المعاملات. تستند تقنية POH إلى تقنية التشفير الأساسية SHA256. تُستخدم SHA256 عادةً لحساب سلامة البيانات، حيث إنه عند إعطاء مدخل X، يكون هناك مخرج Y فريد فقط، وبالتالي أي تغيير في X سيؤدي إلى Y مختلف تمامًا.

في تسلسل POH الخاص بـ Solana، يمكن ضمان سلامة التسلسل بأكمله من خلال تطبيق خوارزمية sha256، مما يضمن سلامة المعاملات فيه. على سبيل المثال، إذا قمنا بتجميع المعاملات في كتلة واحدة، وإنشاء قيمة hash خوارزمية sha256 المقابلة، فإن المعاملات داخل هذه الكتلة تعتبر مؤكدة، وأي تغيير سيؤدي إلى تغيير في قيمة hash. بعد ذلك، ستستخدم قيمة hash هذه كجزء من X في دالة sha256 التالية، ثم تُضاف قيمة hash الخاصة بالكتلة التالية، وبالتالي يتم تأكيد الكتلة السابقة والكتلة التالية، وأي تغيير سيؤدي إلى Y جديدة مختلفة.

هذا هو المعنى الأساسي لتقنية Proof of History الخاصة بها، حيث سيتم استخدام تجزئة الكتلة السابقة كجزء من دالة sha256 التالية، مشابهًا لسلسلة، حيث تحتوي أحدث Y دائمًا على دليل التاريخ.

إعادة تفسير بنية تقنية Solana: هل ستستقبل ربيعها الثاني؟

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

لتجنب حدوث عطل نقطة واحدة في عقدة Leader، تم إدخال قيود زمنية. في Solana، يتم تقسيم وحدة الزمن إلى epochs، حيث يحتوي كل epoch على 432،000 slot (فترة زمنية)، وتستمر كل slot لمدة 400 مللي ثانية، في كل slot، يقوم نظام التناوب بتعيين عقدة Leader واحدة داخل كل slot، ويجب على عقدة Leader نشر الكتلة ضمن وقت slot المحدد (400 مللي ثانية)، وإلا سيتم تجاوز هذه slot وإعادة انتخاب عقدة Leader للslot التالي.

بشكل عام، يمكن أن تجعل آلية POH المستخدمة من قبل عقدة Leader جميع المعاملات التاريخية مؤكدة. وحدة الوقت الأساسية في Solana هي Slot، ويحتاج عقدة Leader لبث الكتلة خلال Slot واحد. يقوم المستخدمون بإرسال المعاملات إلى عقدة Leader عبر عقدة RPC، ثم تقوم عقدة Leader بتعبئة المعاملات وترتيبها ثم تنفيذها لإنشاء الكتلة، وتنتشر الكتلة إلى بقية المدققين، ويحتاج المدققون إلى استخدام آلية للتوصل إلى توافق، والتوصل إلى توافق بشأن المعاملات داخل الكتلة وترتيبها، والآلية المستخدمة لهذا التوافق هي آلية توافق Tower BFT.

آلية توافق برج BFT

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

إعادة تفسير بنية تقنية Solana: هل ستشهد الربيع الثاني؟

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

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

توربين

يقوم عقد Leader بتقسيم الكتل إلى كتل فرعية تسمى شرد من خلال عملية تسمى Sharding، حيث يتم قياس حجمها بوحدات MTU (أقصى وحدة نقل، وهي أقصى كمية من البيانات يمكن إرسالها من عقدة إلى أخرى دون الحاجة إلى تقسيمها إلى وحدات أصغر). ثم يتم ضمان سلامة البيانات وقابليتها للاستخدام من خلال استخدام خطة ترميز Reed-solomon.

إعادة تفسير بنية تقنية Solana: هل ستشهد ربيعها الثاني؟

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

في نقل البيانات على المستوى الأساسي، عادة ما يتم النظر في استخدام بروتوكولات UDP/TCP، نظرًا لأن Solana تتحمل معدل فقد الحزم بشكل أكبر، فإنها تستخدم بروتوكول UDP للنقل، وعيبها هو أنها لا تعيد النقل عند فقد الحزم، ولكن ميزتها هي سرعة النقل الأسرع. على العكس، فإن بروتوكول TCP سيعيد النقل عدة مرات عند فقد الحزم، مما يقلل بشكل كبير من سرعة النقل والإنتاجية، مع وجود Reed-solomon، يمكن أن تزيد هذه الخطة بشكل كبير من إنتاجية Solana، وفي البيئات الحقيقية، يمكن أن تزيد الإنتاجية بمعدل 9 مرات.

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

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

  2. مجموعة العقد: ثم سيقوم كل مدقق موجود في الطبقة الأولى بإنشاء قائمة عقد خاصة به لبناء طبقة أولى خاصة به.

  3. تشكيل الطبقات: تقسيم العقد من أعلى القائمة إلى طبقات من خلال تحديد قيمتين هما العمق والعرض، مما يمكن من تحديد الشكل العام للشجرة، وهذا العامل سيؤثر على سرعة انتشار الشريدات.

إعادة تفسير بنية Solana التقنية: هل ستشهد ربيعها الثاني؟

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

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

SVM

تستطيع Solana معالجة آلاف المعاملات في الثانية، ويرجع السبب الرئيسي في ذلك إلى آلية POH، وإجماع Tower BFT، وآلية انتشار البيانات Turbine. ومع ذلك، فإن SVM كآلة افتراضية لتحويل الحالة، إذا كانت سرعة معالجة SVM بطيئة أثناء تنفيذ المعاملات من قبل العقدة الرئيسية، فإن ذلك سيؤدي إلى انخفاض إجمالي سعة النظام، لذلك قدمت Solana محرك التنفيذ المتوازي Sealevel لتسريع سرعة تنفيذ المعاملات.

إعادة تفسير بنية تقنية Solana: هل ستشهد ربيعها الثاني؟

في SVM، تتكون التعليمات من 4 أجزاء، تشمل معرف البرنامج، تعليمات البرنامج، وقائمة حسابات البيانات للقراءة/الكتابة. من خلال تحديد ما إذا كانت الحسابات الحالية في حالة قراءة أو كتابة، وما إذا كانت العمليات التي تتطلب تغيير الحالة تتعارض، يمكن السماح بتوازي تعليمات المعاملات للحسابات التي لا تتعارض في الحالة، حيث يتم تمثيل كل تعليمات بواسطة معرف البرنامج. وهذا هو أحد الأسباب التي تجعل متطلبات المدققين في Solana مرتفعة للغاية، لأنهم يحتاجون إلى أن يدعم GPU/CPU الخاص بهم SIMD (تعليمات واحدة، بيانات متعددة) و AVX.

SOL2.43%
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • 5
  • مشاركة
تعليق
0/400
FancyResearchLabvip
· 07-30 11:46
مرة أخرى أتيت لدراسة أي ميزة متطورة، حقًا أشعر بالقلق على محفظتك.
شاهد النسخة الأصليةرد0
FundingMartyrvip
· 07-28 11:16
ساعد إيمان سول في إطلاق ما ينتمي إليه
شاهد النسخة الأصليةرد0
FarmHoppervip
· 07-28 11:15
وصل سول!
شاهد النسخة الأصليةرد0
ChainSauceMastervip
· 07-28 11:13
sol لذيذ
شاهد النسخة الأصليةرد0
LuckyBlindCatvip
· 07-28 11:11
هل يحق لهذا أن يسمى ربيعًا ثانيًا؟ هل ابتعدت كثيرًا؟
شاهد النسخة الأصليةرد0
  • تثبيت