قبل شهر ، أثار Vibhu ، مؤسس DRiP ، أكبر تطبيق للمستهلكين على Solana يوزع NFTs مجانا من كبار الفنانين ، نقاشا تشتد الحاجة إليه ببيانه:
سيكون لدى Solana ويحتاج إلى L2s و / أو مجموعات
نشأ إحباطه لأن DRiP كان يسرب قيمة كبيرة (~ 20 ألف دولار / أسبوع) إلى الطبقة الأساسية ، وذلك بفضل ارتفاع أسعار SOL و ازدحام الشبكة. زيادة النشاط على Solana يؤدي إلى:
ومع ذلك ، فإن DRiP ، الذي يستخدم Solana بشكل أساسي مثل البنية التحتية لتوزيع ملايين NFTs أسبوعيا من الفنانين إلى آلاف المحافظ ، لا يستفيد من قابلية التركيب العالية. إن النمو في TVL وتدفق رأس المال في Solana ليس له تأثير يذكر على DRiP ، الذي يعاني في المقام الأول من عيوب ، مثل ارتفاع تكاليف البنية التحتية.
يشير فيبهو إلى أن "قابلية التركيب لها عوائد متناقصة". ويشير أيضا إلى أن مطوري التطبيقات Solana يناقشون بشكل خاص رغبتهم في مجموعات بسبب:
على مدى الأشهر القليلة الماضية ، شهدت Solana العديد من حوادث الازدحام ، بدءا من عمليات الإنزال الجوي مثل JUP إلى تعدين ORE وذروة تداول عملات الميمز. بينما قد يجادل المرء بأن Firedancer يمكنه حل كل هذه المشكلات ، فلنكن واقعيين: لا يزال الجدول الزمني غير مؤكد ، ولا يمكن أن يتجاوز 10x في الوقت الحالي. على الرغم من ذلك ، صحيح أنه من بين جميع السلاسل الرئيسية التي تم اختبارها في المعركة ، تقف Solana كآخر متراصة حقيقية متبقية.
هل يجب أن تظل Solana متراصة أم تصبح وحدات؟ هل سيتطور Solana أيضا مثل إثيريوم مع حلول L2 و L3 المجزأة ، من بين حلول أخرى؟ ما هو المشهد الحالي لسلاسل التطبيقات مجموعات على Solana؟
لمعالجة هذه الأسئلة وتلخيص النقاش بأكمله ، سوف يستكشف هذا المقال جميع الاحتمالات ، ويناقش المشاريع المختلفة ، ويقيم إيجابياتها وسلبياتها.
لن تتعمق هذه المقالة في الجوانب الفنية ولكنها ستتبنى بدلا من ذلك منظورا أكثر توجها نحو السوق وعمليا في مناقشة مناهج التوسع المختلفة لتقديم نظرة عامة.
كل الأفكار ، لا زغب - بالإضافة إلى الكثير من ألفا.
باختصار ، سنناقش:
لنبدأ بمخاطبة في الغرفة: كانت شبكة Solana مزدحمة للغاية مؤخرا (تم حلها الآن في الغالب) بسبب عمليات الإنزال الجوي ، وكمية كبيرة من نشاط التداول عملات الميمز ، وما إلى ذلك ، متصدر إلى أوقات ping عالية ، ونسبة عالية من المعاملات الفاشلة ، وزيادة رسوم الشبكة بسبب ارتفاع رسوم الأولوية. على الرغم من كل هذا ، عالجت Solana باستمرار حوالي 1-2 ألف TPS ، أكثر من جميع سلاسل EVM مجتمعة. أود أن أقول إنها مشكلة جيدة بالنسبة ل blockchain ، وقد وضعت أيضا أطروحة Solana المتجانسة على المحك.
نشرت مؤسسة Solana مؤخرا مدونة تحث المشاريع على اتخاذ إجراءات فورية لتعزيز أداء الشبكة، بما في ذلك:
ومع ذلك ، فإن كل هذه الإجراءات تعمل فقط على تحسين إتمام المعاملة إلى حد ما ولا تضمن تجربة مستخدم سلسة للمعاملات. أحد الحلول الفورية لهذه المشكلة هو برنامج جدولة المعاملات الجديد الذي طال انتظاره ، والمقرر إصداره في الإصدار 1.18 المستهدف في أواخر أبريل. سيتم تقديمه جنبا إلى جنب مع المجدول الحالي ولكن لن يتم تمكينه افتراضيا ، مما يسمح المدققون بمراقبة أداء المجدول الجديد والعودة بسهولة إلى المجدول القديم في حالة ظهور أي مشاكل. يهدف هذا المجدول الجديد إلى ملء الكتل بشكل أكثر كفاءة واقتصادا ، وتحسين أوجه القصور في المجدول القديم. اقرأ هذه المقالة لمعرفة المزيد من التفاصيل حول @harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">new Scheduler.
Anza (كيان منبثق من Solana Labs) كان cيحاول باستمرار حل ازدحام الشبكة التي تم تحديدها على أنها مشكلات تتعلق بتنفيذ QUIC ، وسلوك عميل مدقق Agave (Solana Labs) ، عندما يطلب منه معالجة عدد كبير من الطلبات.
بينما دعا مؤيدو النمطية بقوة إلى "خارطة طريق معيارية" ل Solana ، لا تزال Solana Labs / Anza (المشرف الأساسي على Solana بروتوكول) تركز على تحسين إنتاجية الطبقة الأساسية و وقت الإستجابة. تتضمن بعض التحسينات المحتملة ما يلي:
إصلاح أسواق الرسوم وزيادة الرسوم الأساسية (المحددة حاليا عند 5000 Lamports أو 0.000005 SOL).
تنفيذ رسوم قفل الكتابة الأسية للحسابات ، أي زيادة الرسوم بشكل تدريجي بمرور الوقت لتثبيط البريد العشوائي.
تحسين طلبات ميزانية CU من خلال نظام العقوبات.
تعزيز البنية الشاملة للشبكة.
حتى مع هذه التحسينات في القياس الرأسي (سلسلة واحدة) ، لا يمكننا استبعاد إمكانية اعتماد Solana القياس الأفقي (مجموعات). الحقيقة هي أن Solana يمكن أن تصبح مزيجا من كليهما - يمكن أن تكون بمثابة طبقة أساسية ممتازة مجموعات ، وتتميز بأوقات كتلة وقت الإستجابة منخفضة للغاية (~ 400 مللي ثانية) من شأنها أن تستفيد بشكل كبير مجموعات ، مثل تمكين التأكيد الناعم فائق السرعة من أجهزة التسلسل. أفضل جزء هو أن Solana كانت سريعة تاريخيا في تنفيذ التغييرات ، مما قد يجعلها طبقة أكثر كفاءة مجموعات من إثيريوم.
تحديث: قامت Anza الآن بدفع بعض التصحيحات للمساعدة في تخفيف بعض ازدحام الشبكة المستمرة ، وسيتبعها المزيد من التحسينات في الإصدار 1.18.
لقد بدأت بالفعل الجهود المبذولة لجعل Solana معيارية. كما يشير منشور Anza DevRel ، فإن مدقق Solana و SVM (بيئة التنفيذ التي تعالج المعاملات و العقود الذكية / البرامج) مقترنان بإحكام ويتم صيانتهما بواسطة Anza (كيان عرضي من Solana Labs). ومع ذلك، سيتم فصل عميل المدقق ووقت تشغيل SVM خلال الأشهر القليلة القادمة. سيسهل هذا الفصل تفرع SVM وإنشاء "سلاسل تطبيقات Solana" بسهولة.
على سبيل مجموعات ، يمكن أن تأتي الفائدة من تحسين طبقة Solana توفر البيانات (DA) / blob ، على الرغم من أن هذا قد يحدث في مرحلة لاحقة.
المصدر: أنزا ديفريل
Joe C (مهندس في Anza) كشف النقاب أيضا عن خطط لجعل SVM معياريا ، حيث سيتم إخراج خط أنابيب معالجة المعاملات من المدقق ووضعه في SVM. سيمكن هذا المطورين من تشغيل تنفيذ SVM والعمل بشكل مستقل عن أي مدقق.
سيكون SVM المعزول عبارة عن مجموعة من الوحدات المستقلة تماما. يمكن لأي تطبيق SVM دفع هذه الوحدات من خلال واجهات محددة جيدا ، مما يقلل بشكل أكبر من الحواجز أمام المشاريع المتوافقة مع SVM من خلال تقليل النفقات العامة المطلوبة لتصميم حلول مخصصة بشكل كبير. يمكن للفرق تنفيذ الوحدات التي تهتم بها فقط ، مع استخدام التطبيقات المعمول بها للباقي ، مثل تلك الموجودة في Agave أو Firedancer.
في قصير ، سيكون Solana المزيد من التوصيل والتشغيل ، مما يجعل سلاسل التطبيقات Solana مجموعات أسهل بكثير.
على نطاق واسع ، هناك اتجاهان ، حيث يمكن أن يذهب هذا: Layer-2s / Rollups و Appchains. سنلقي نظرة على كليهما - واحدا تلو الآخر.
تعرف أيضا باسم شوكات SVM ، وهي في الأساس شوكات لسلسلة Solana المخصصة لتطبيقات محددة. كان Pyth أول سلسلة تطبيقات Solana ، لكن المفهوم اكتسب الاهتمام حقا عندما تسبب Rune ، مؤسس أحد أكبر بروتوكولات DeFi ، الصانع ، في ضجة كبيرة باقتراحه لتطوير سلسلة تطبيقات الصانع (للحوكمة) بناء على قاعدة بيانات Solana (SVM). اختار SVM نظرا لمجتمع المطورين القوي والتفوق التقني على الأجهزة الافتراضية الأخرى ، بهدف fork السلسلة الأكثر أداء لتلبية احتياجات المستهلكين بشكل أفضل. على الرغم من أنه لم يتم تنفيذ أي شيء حتى الآن ، إلا أن هذه الخطوة أثارت نقاشا تشتد الحاجة إليه حول سلاسل التطبيقات Solana.
على نطاق واسع ، يمكن أن يكون من نوعين:
Pyth - OG Solana Appchain:
في وقت واحد ، استحوذت Pyth على 10-20٪ من جميع المعاملات على الشبكة الرئيسية Solana. ومع ذلك ، لم يتطلب الأمر أي قابلية للتركيب ، لذلك قاموا ببساطة بتقسيم قاعدة بيانات Solana. سمح لهم ذلك بالاستفادة من وقت الكتلة Solana السريع البالغ 400 مللي ثانية لتحديثات الأسعار عالية التردد. كانت Pythnet أول شبكة تتبنى SVM لسلسلة تطبيقاتها.
سلسلة تطبيقات Pythnet هي fork إثبات السلطة لشبكة Solana الرئيسية ، وتعمل كطبقة أساسية حسابية لمعالجة وتجميع البيانات التي توفرها شبكة ناشري البيانات في Pyth.
لماذا تحرك بيث؟
- لم يتطلب قابلية تركيب عالية (خاصة للتطبيقات غير Solana) وبالتالي كان خاليا من ازدحام الشبكة الرئيسية.
Cube Exchange هو مثال آخر ، CEX هجين تم نشره كسلسلة تطبيقات SVM ذات سيادة (مع كتاب خارج السلسلة طلب تماما وتسوية على سلسلة تطبيقات SVM الخاصة بهم)
بعض الأمثلة على Solana Appchains يمكن أن تكون:
على الرغم من أن إنشاء سلسلة تطبيقات قد يكون أمرا بسيطا نسبيا، إلا أن ضمان الاتصال عبر جميع سلاسل التطبيقات أمر بالغ الأهمية لإمكانية التشغيل البيني. مستوحاة من انهيار ثلجي الشبكات الفرعية (المتصلة بواسطة انهيار ثلجي Warp Messaging الأصلية) وسلاسل تطبيقات Cosmos (المتصلة بواسطة IBC) ، يمكن Solana أيضا إنشاء إطار مراسلة أصلي لربط سلاسل التطبيقات هذه.
يمكن للمرء أيضا إنشاء برنامج وسيط يشبه Cosmos-SDK ، مما يوفر حلا جاهزا لإنشاء سلاسل التطبيقات مع الدعم مدمجة للأوراكل (مثل Pyth أو Switchboard) ، و RPCs (مثل Helius) ، واتصال المراسلة (مثل Wormhole) ، من بين أمور أخرى.
Polygon AggLayer سيكون أيضا نهجا مثيرا للاهتمام ، حيث يمكن للمطورين توصيل أي سلسلة L1 أو L2 ب AggLayer ، والتي تجمع براهين ZK من جميع السلاسل المتصلة.
على الرغم من أن سلاسل التطبيقات لا تتراكم بشكل مباشر على SOL ، لأنها لن تدفع رسوما في SOL أو تستخدم SOL كرمز غاز - ما لم يتم استخدام SOL المعاد تخزينه للأمن الاقتصادي - إلا أنها تفيد بشكل كبير النظام البيئي SVM. تماما كما توجد "تأثيرات شبكة EVM" ، فإن المزيد من شوكات SVM وسلاسل التطبيقات ستعزز تأثيرات شبكة SVM. ينطبق نفس المنطق الذي يجعل Eclipse (SVM L2 on إثيريوم) صاعد ل SVM ، على الرغم من أنه منافس مباشر للشبكة الرئيسية Solana.
Solana Layer-2s، أو مجموعات، هي سلاسل منفصلة منطقيا تقوم بنشر البيانات إلى طبقة توفر البيانات (DA) الخاصة بالسلسلة المضيفة وإعادة استخدام آلية إجماع السلسلة المضيفة. يمكنهم أيضا استخدام طبقات DA أخرى مثل Celestia ، ومع ذلك ، فإنها لا تظل مجموعة بيانات حقيقية. "RollApp" هو مصطلح يستخدم بشكل عام للمجموعات الخاصة بالتطبيقات (والتي تستكشفها معظم التطبيقات Solana).
هل ستكون Solana Rollups هي نفسها إثيريوم؟
على ما يبدو لا. على Solana ، سيتم تجريد Rollups في الغالب للمستخدم النهائي. على الجبهة الأيديولوجية ، كانت إثيريوم مجموعات من أعلى إلى أسفل ، حيث قررت مؤسسة إثيريوم والقادة أن أفضل طريقة للتوسع هي من خلال مجموعات ، وبدأوا في دعم مختلف L2s بعد فشل CryptoKitties. بينما في Solana ، يكون الطلب من أسفل إلى أعلى ، أي يأتي من مطوري التطبيقات الذين يعتمدون المستهلك بشكل كبير. نتيجة لذلك ، فإن معظم المسرحيات الحالية هي مسرحيات تسويقية وهي مدفوعة بالسرد أكثر من كونها مدفوعة بطلب المستهلك. هذا فرق كبير وقد يؤدي إلى مستقبل مختلف مجموعات عما رأيناه في إثيريوم.
هل الضغط = تراكمات؟
سلاسل كتل الطبقة الأساسية لمقياس L2s (L1s) عن طريق تنفيذ المعاملات على L2 ، وتجميع بيانات المعاملة ، وضغطها. ثم يتم إرسال البيانات المضغوطة إلى L1 واستخدامها إما في دليل على الاحتيال (مجموعة التحديثات المتفائلة) أو إثبات صحة (zk rollup). يشار إلى عملية الإثبات هذه باسم "التسوية". وبالمثل ، يقوم الضغط بإلغاء تحميل المعاملات من الشبكة الرئيسية ، مما يقلل من التنافس على الحالة على الطبقة الأساسية. والجدير بالذكر أن Grass L2 ستستفيد من ضغط الحالة من أجل التراكم.
Two 'rollapps إلى حد ما' موجودان حاليا:
يتيح تطبيق المدفوعات المزود بحزمة SDK للمدفوعات الصغيرة لأي شخص الدفع وقبول المدفوعات على الفور ويستخدم أيضا مجموعة بيانات زائفة لتطبيقه. إنه يخلق نوايا لجميع المعاملات ويستخدم جهاز تسلسل يشبه التراكمي ، والذي يستقر على Solana بعد فترات N.
يؤدي استخدام بنية تشبه مجموعة التحديثات إلى:
طورت MagicBlocks ، وهي بنية تحتية لألعاب web3 ، مجموعات سريعة (أو مؤقتة) ، خاصة للألعاب. يستخدم الهيكل الحساب ل SVM ويتم تقسيم حالة اللعبة إلى مجموعات. ينقل الحالة مؤقتا إلى طبقة مساعدة أو "مجموعة التحديثات المؤقتة" ، وهي طبقة مخصصة قابلة للتكوين. تعمل مجموعة التحديثات سريعة الزوال كوقت تشغيل SVM متخصص أو مجموعة تراكمية لتسهيل معالجة المعاملات بمعدل نقل مرتفع.
يتيح استخدام بنية تشبه مجموعة التحديثات ما يلي:
يسهل هذا النهج نظاما قابلا للتطوير بدرجة كبيرة قادرا على إطلاق مجموعات عند الطلب والتوسع التلقائي أفقيا لاستيعاب المستخدمين الذين يقومون بملايين المعاملات ، دون المفاضلات النموذجية ل L2s التقليدية. بينما يركز MagicBlock بشكل خاص على الألعاب ، يمكن تطبيق هذا النهج على تطبيقات أخرى مثل المدفوعات.
يتطلب Grass 1 مليون طلب ويب في الثانية ، وهو أمر غير ممكن على الشبكة الرئيسية Solana. لذلك ، يخططون لعمل إثباتات ZK لبيانات الأصل لجميع مجموعات البيانات وتجميعها للتسوية على Solana L1. إنهم يفكرون في استخدام ضغط الحالة من مجموعة أخرى وتسوية الجذور على mainnet-beta.
سيؤدي هذا التطور إلى وضع Grass كطبقة أساسية لمجموعة واسعة من التطبيقات التي لا يمكن تحقيقها إلا فوق Grass (لاحظ أن المنصات والبنية التحتية غالبا ما تتطلب تقييمات أعلى بكثير وأن Grass ستطلق الرمز المميز قريبا :P).
تحتوي Perp DEXs على PMF فوري ل مجموعات لأنها تحسن تجربة المستخدم بشكل كبير. فقط اسأل شخصا قام بالتداول على Hyperliquid أو Aevo مقابل Solana perp DEXs ، حيث يتعين عليك التوقيع على كل معاملة ، وتنبثق المحفظة ، وعليك الانتظار ~ 10-20 ثانية. علاوة على ذلك ، لا تتطلب perps تنفيذا متزامنا وتوفر قابلية عالية للتركيب مع بقية DeFi ، لا سيما في الجانب التجاري مطابق.
ومن المثير للاهتمام أن أرماني (المؤسس المشارك لحقيبة الظهر) أيضا غردوا أنهم يميلون الآن إلى L2.
Sonic تقوم أيضا ببناء سلسلة SVM معيارية (Hypergrid) ستمكن الألعاب من نشر سلاسلها الخاصة على Solana. هناك أيضا إثيريوم مجموعات تستند إلى SVM مثل Eclipse و NitroVM التي تستخدم SVM كمحرك تنفيذ. يعمل النيون كملف L2 متوافق مع EVM على Solana. بالإضافة إلى ذلك ، هناك مشاريع في مرحلة الفكرة ، مثل Molecule (SVM بيتكوين طبقة 2).
Sovereign SDK هو إطار عمل آخر مشابه ل node.js ، ولكن لبناء مجموعات. يجلب المستخدمون رمز Rust الخاص بهم ، ونحوله إلى مجموعة تراكمية متفائلة أو ZK يمكن نشرها على أي blockchain. يمكن أن يكون رمز Rust هو منطق تطبيقك المحدد ، أو أي VM.
ينطبق نفس المبدأ على Solana. سوف يلتف مجتمع Solana حول أي حل يعزز ممتلكاتهم SOL - الأمر بهذه البساطة. مع توسع النظام البيئي Solana ، ستصبح "أموال SOL" التي تم تجاهلها ذات يوم ذات أهمية. تذكر أن معظم عمليات التجميع هي على أي حال "لعبة تسويقية" وتعطي استحقاقا أفضل لقيمة الرمز المميز حيث لا تزال الأسواق تقدر البنية التحتية أكثر من التطبيقات.
وبالمثل ، سيحدث هذا مع Solana. التعلم من إثيريوم ، فإن معظم Solana Rollapps لن تجعل المستخدمين يشعرون وكأنهم يستخدمون سلسلة منفصلة (على سبيل المثال ، Getcode).
علاوة على ذلك ، أشعر أن L2s للأغراض العامة على Solana قد تؤدي إلى نفس مشاكل إثيريوم القديمة ، أي مجموعات المركزية والازدحام وتجزئة السيولة.
بالنسبة لحالات الاستخدام المصرح بها والتخصيص ، يخدم ملحق عملة أيضا معظم الاحتياجات مثل منطق توثيق KYC / النقل مع الاحتفاظ بقابلية التركيب.
لذا ، هل سيكون DRiP L2 / appchain؟
يستخدم DRiP حاليا Solana من أجل:
* محافظ إنشاء المستخدم (يمكن أن يكون على L2 / appchain)
* توزيع NFTs المضغوطة (يمكن أن يكون على L2 / appchain)
* تداول NFTs المضغوطة (يمكن أن يكون على L2 / appchain ، ولكن يجب سد الأموال)
إذا توسعت أطروحة rollapp/appchain، فسيستفيد موفرو البنية التحتية الحاليون بشكل كبير عند دخولهم إلى أسواق جديدة:
بالتأكيد لا. لنكن واقعيين: حتى مع الأخذ في الاعتبار قانون مور (أن أداء الأجهزة سيستمر في التحسن ، ويتم تحسين Solana لمثل هذه التطورات في الأجهزة) ، فهذا غير عملي. أعتقد أن جميع المعاملات الأقل أهمية (مثل إرسال DRiP ل NFTs) ستنتقل في النهاية إلى سلاسلها الخاصة ، بينما ستبقى المعاملات الأكثر قيمة على السلسلة الرئيسية ، حيث تكون قابلية التركيب الحقيقية ضرورية (على سبيل المثال ، فوري DEXs).
ولا ، هذا لا يعني أن Solana قد خسر في معركة المتراصة والتركيب ؛ سيدير الحالات التي تعتمد على قابلية التركيب وانخفاض وقت الإستجابة أفضل من السلاسل الأخرى. ولا ، Sui / Aptos / Sei / Monad ، وما إلى ذلك ليست أفضل حتى الآن ، لأننا لا نعرف ولم يتم اختبارها بعد من أجل نشاط المستخدم الحقيقي العالي.
على عكس إثيريوم ، لا تهدف Solana الشبكة الرئيسية إلى أن تكون "سلسلة B2B" ؛ كانت وستظل دائما سلسلة المستهلكين. يعد بناء الأنظمة الموزعة على نطاق واسع أمرا صعبا للغاية ، وتتمتع Solana بأفضل إمكانات لتصبح دفتر الأستاذ المشترك العالمي للمعاملات الأكثر قيمة.
Solana يحتاج إلى رفقاء الروح: هل يمكن أن تكون Appchains و rollups هي المباراة المثالية؟
لا تتردد في الاتصال بي على Yash Agarwal (@yashhsm على تويتر) للحصول على أي اقتراحات أو إذا كان لديك أي آراء. إذا وجدت هذا ثاقبا بعض الشيء ، فيرجى مشاركته - يبرر أسابيع جهدي ويحصل على المزيد من مقل العيون :)
شكر خاص ل Karthik (PepperDEX)، Brian Breslow (Dorahacks)، Parth (Arana Ventures)، Rex (Anza)، Het Dagli (Superteam)، Kash (Superteam)، و Akshay (Superteam)، الذي راجع وقدم رؤى في مراحل مختلفة من المسودة.
قبل شهر ، أثار Vibhu ، مؤسس DRiP ، أكبر تطبيق للمستهلكين على Solana يوزع NFTs مجانا من كبار الفنانين ، نقاشا تشتد الحاجة إليه ببيانه:
سيكون لدى Solana ويحتاج إلى L2s و / أو مجموعات
نشأ إحباطه لأن DRiP كان يسرب قيمة كبيرة (~ 20 ألف دولار / أسبوع) إلى الطبقة الأساسية ، وذلك بفضل ارتفاع أسعار SOL و ازدحام الشبكة. زيادة النشاط على Solana يؤدي إلى:
ومع ذلك ، فإن DRiP ، الذي يستخدم Solana بشكل أساسي مثل البنية التحتية لتوزيع ملايين NFTs أسبوعيا من الفنانين إلى آلاف المحافظ ، لا يستفيد من قابلية التركيب العالية. إن النمو في TVL وتدفق رأس المال في Solana ليس له تأثير يذكر على DRiP ، الذي يعاني في المقام الأول من عيوب ، مثل ارتفاع تكاليف البنية التحتية.
يشير فيبهو إلى أن "قابلية التركيب لها عوائد متناقصة". ويشير أيضا إلى أن مطوري التطبيقات Solana يناقشون بشكل خاص رغبتهم في مجموعات بسبب:
على مدى الأشهر القليلة الماضية ، شهدت Solana العديد من حوادث الازدحام ، بدءا من عمليات الإنزال الجوي مثل JUP إلى تعدين ORE وذروة تداول عملات الميمز. بينما قد يجادل المرء بأن Firedancer يمكنه حل كل هذه المشكلات ، فلنكن واقعيين: لا يزال الجدول الزمني غير مؤكد ، ولا يمكن أن يتجاوز 10x في الوقت الحالي. على الرغم من ذلك ، صحيح أنه من بين جميع السلاسل الرئيسية التي تم اختبارها في المعركة ، تقف Solana كآخر متراصة حقيقية متبقية.
هل يجب أن تظل Solana متراصة أم تصبح وحدات؟ هل سيتطور Solana أيضا مثل إثيريوم مع حلول L2 و L3 المجزأة ، من بين حلول أخرى؟ ما هو المشهد الحالي لسلاسل التطبيقات مجموعات على Solana؟
لمعالجة هذه الأسئلة وتلخيص النقاش بأكمله ، سوف يستكشف هذا المقال جميع الاحتمالات ، ويناقش المشاريع المختلفة ، ويقيم إيجابياتها وسلبياتها.
لن تتعمق هذه المقالة في الجوانب الفنية ولكنها ستتبنى بدلا من ذلك منظورا أكثر توجها نحو السوق وعمليا في مناقشة مناهج التوسع المختلفة لتقديم نظرة عامة.
كل الأفكار ، لا زغب - بالإضافة إلى الكثير من ألفا.
باختصار ، سنناقش:
لنبدأ بمخاطبة في الغرفة: كانت شبكة Solana مزدحمة للغاية مؤخرا (تم حلها الآن في الغالب) بسبب عمليات الإنزال الجوي ، وكمية كبيرة من نشاط التداول عملات الميمز ، وما إلى ذلك ، متصدر إلى أوقات ping عالية ، ونسبة عالية من المعاملات الفاشلة ، وزيادة رسوم الشبكة بسبب ارتفاع رسوم الأولوية. على الرغم من كل هذا ، عالجت Solana باستمرار حوالي 1-2 ألف TPS ، أكثر من جميع سلاسل EVM مجتمعة. أود أن أقول إنها مشكلة جيدة بالنسبة ل blockchain ، وقد وضعت أيضا أطروحة Solana المتجانسة على المحك.
نشرت مؤسسة Solana مؤخرا مدونة تحث المشاريع على اتخاذ إجراءات فورية لتعزيز أداء الشبكة، بما في ذلك:
ومع ذلك ، فإن كل هذه الإجراءات تعمل فقط على تحسين إتمام المعاملة إلى حد ما ولا تضمن تجربة مستخدم سلسة للمعاملات. أحد الحلول الفورية لهذه المشكلة هو برنامج جدولة المعاملات الجديد الذي طال انتظاره ، والمقرر إصداره في الإصدار 1.18 المستهدف في أواخر أبريل. سيتم تقديمه جنبا إلى جنب مع المجدول الحالي ولكن لن يتم تمكينه افتراضيا ، مما يسمح المدققون بمراقبة أداء المجدول الجديد والعودة بسهولة إلى المجدول القديم في حالة ظهور أي مشاكل. يهدف هذا المجدول الجديد إلى ملء الكتل بشكل أكثر كفاءة واقتصادا ، وتحسين أوجه القصور في المجدول القديم. اقرأ هذه المقالة لمعرفة المزيد من التفاصيل حول @harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">new Scheduler.
Anza (كيان منبثق من Solana Labs) كان cيحاول باستمرار حل ازدحام الشبكة التي تم تحديدها على أنها مشكلات تتعلق بتنفيذ QUIC ، وسلوك عميل مدقق Agave (Solana Labs) ، عندما يطلب منه معالجة عدد كبير من الطلبات.
بينما دعا مؤيدو النمطية بقوة إلى "خارطة طريق معيارية" ل Solana ، لا تزال Solana Labs / Anza (المشرف الأساسي على Solana بروتوكول) تركز على تحسين إنتاجية الطبقة الأساسية و وقت الإستجابة. تتضمن بعض التحسينات المحتملة ما يلي:
إصلاح أسواق الرسوم وزيادة الرسوم الأساسية (المحددة حاليا عند 5000 Lamports أو 0.000005 SOL).
تنفيذ رسوم قفل الكتابة الأسية للحسابات ، أي زيادة الرسوم بشكل تدريجي بمرور الوقت لتثبيط البريد العشوائي.
تحسين طلبات ميزانية CU من خلال نظام العقوبات.
تعزيز البنية الشاملة للشبكة.
حتى مع هذه التحسينات في القياس الرأسي (سلسلة واحدة) ، لا يمكننا استبعاد إمكانية اعتماد Solana القياس الأفقي (مجموعات). الحقيقة هي أن Solana يمكن أن تصبح مزيجا من كليهما - يمكن أن تكون بمثابة طبقة أساسية ممتازة مجموعات ، وتتميز بأوقات كتلة وقت الإستجابة منخفضة للغاية (~ 400 مللي ثانية) من شأنها أن تستفيد بشكل كبير مجموعات ، مثل تمكين التأكيد الناعم فائق السرعة من أجهزة التسلسل. أفضل جزء هو أن Solana كانت سريعة تاريخيا في تنفيذ التغييرات ، مما قد يجعلها طبقة أكثر كفاءة مجموعات من إثيريوم.
تحديث: قامت Anza الآن بدفع بعض التصحيحات للمساعدة في تخفيف بعض ازدحام الشبكة المستمرة ، وسيتبعها المزيد من التحسينات في الإصدار 1.18.
لقد بدأت بالفعل الجهود المبذولة لجعل Solana معيارية. كما يشير منشور Anza DevRel ، فإن مدقق Solana و SVM (بيئة التنفيذ التي تعالج المعاملات و العقود الذكية / البرامج) مقترنان بإحكام ويتم صيانتهما بواسطة Anza (كيان عرضي من Solana Labs). ومع ذلك، سيتم فصل عميل المدقق ووقت تشغيل SVM خلال الأشهر القليلة القادمة. سيسهل هذا الفصل تفرع SVM وإنشاء "سلاسل تطبيقات Solana" بسهولة.
على سبيل مجموعات ، يمكن أن تأتي الفائدة من تحسين طبقة Solana توفر البيانات (DA) / blob ، على الرغم من أن هذا قد يحدث في مرحلة لاحقة.
المصدر: أنزا ديفريل
Joe C (مهندس في Anza) كشف النقاب أيضا عن خطط لجعل SVM معياريا ، حيث سيتم إخراج خط أنابيب معالجة المعاملات من المدقق ووضعه في SVM. سيمكن هذا المطورين من تشغيل تنفيذ SVM والعمل بشكل مستقل عن أي مدقق.
سيكون SVM المعزول عبارة عن مجموعة من الوحدات المستقلة تماما. يمكن لأي تطبيق SVM دفع هذه الوحدات من خلال واجهات محددة جيدا ، مما يقلل بشكل أكبر من الحواجز أمام المشاريع المتوافقة مع SVM من خلال تقليل النفقات العامة المطلوبة لتصميم حلول مخصصة بشكل كبير. يمكن للفرق تنفيذ الوحدات التي تهتم بها فقط ، مع استخدام التطبيقات المعمول بها للباقي ، مثل تلك الموجودة في Agave أو Firedancer.
في قصير ، سيكون Solana المزيد من التوصيل والتشغيل ، مما يجعل سلاسل التطبيقات Solana مجموعات أسهل بكثير.
على نطاق واسع ، هناك اتجاهان ، حيث يمكن أن يذهب هذا: Layer-2s / Rollups و Appchains. سنلقي نظرة على كليهما - واحدا تلو الآخر.
تعرف أيضا باسم شوكات SVM ، وهي في الأساس شوكات لسلسلة Solana المخصصة لتطبيقات محددة. كان Pyth أول سلسلة تطبيقات Solana ، لكن المفهوم اكتسب الاهتمام حقا عندما تسبب Rune ، مؤسس أحد أكبر بروتوكولات DeFi ، الصانع ، في ضجة كبيرة باقتراحه لتطوير سلسلة تطبيقات الصانع (للحوكمة) بناء على قاعدة بيانات Solana (SVM). اختار SVM نظرا لمجتمع المطورين القوي والتفوق التقني على الأجهزة الافتراضية الأخرى ، بهدف fork السلسلة الأكثر أداء لتلبية احتياجات المستهلكين بشكل أفضل. على الرغم من أنه لم يتم تنفيذ أي شيء حتى الآن ، إلا أن هذه الخطوة أثارت نقاشا تشتد الحاجة إليه حول سلاسل التطبيقات Solana.
على نطاق واسع ، يمكن أن يكون من نوعين:
Pyth - OG Solana Appchain:
في وقت واحد ، استحوذت Pyth على 10-20٪ من جميع المعاملات على الشبكة الرئيسية Solana. ومع ذلك ، لم يتطلب الأمر أي قابلية للتركيب ، لذلك قاموا ببساطة بتقسيم قاعدة بيانات Solana. سمح لهم ذلك بالاستفادة من وقت الكتلة Solana السريع البالغ 400 مللي ثانية لتحديثات الأسعار عالية التردد. كانت Pythnet أول شبكة تتبنى SVM لسلسلة تطبيقاتها.
سلسلة تطبيقات Pythnet هي fork إثبات السلطة لشبكة Solana الرئيسية ، وتعمل كطبقة أساسية حسابية لمعالجة وتجميع البيانات التي توفرها شبكة ناشري البيانات في Pyth.
لماذا تحرك بيث؟
- لم يتطلب قابلية تركيب عالية (خاصة للتطبيقات غير Solana) وبالتالي كان خاليا من ازدحام الشبكة الرئيسية.
Cube Exchange هو مثال آخر ، CEX هجين تم نشره كسلسلة تطبيقات SVM ذات سيادة (مع كتاب خارج السلسلة طلب تماما وتسوية على سلسلة تطبيقات SVM الخاصة بهم)
بعض الأمثلة على Solana Appchains يمكن أن تكون:
على الرغم من أن إنشاء سلسلة تطبيقات قد يكون أمرا بسيطا نسبيا، إلا أن ضمان الاتصال عبر جميع سلاسل التطبيقات أمر بالغ الأهمية لإمكانية التشغيل البيني. مستوحاة من انهيار ثلجي الشبكات الفرعية (المتصلة بواسطة انهيار ثلجي Warp Messaging الأصلية) وسلاسل تطبيقات Cosmos (المتصلة بواسطة IBC) ، يمكن Solana أيضا إنشاء إطار مراسلة أصلي لربط سلاسل التطبيقات هذه.
يمكن للمرء أيضا إنشاء برنامج وسيط يشبه Cosmos-SDK ، مما يوفر حلا جاهزا لإنشاء سلاسل التطبيقات مع الدعم مدمجة للأوراكل (مثل Pyth أو Switchboard) ، و RPCs (مثل Helius) ، واتصال المراسلة (مثل Wormhole) ، من بين أمور أخرى.
Polygon AggLayer سيكون أيضا نهجا مثيرا للاهتمام ، حيث يمكن للمطورين توصيل أي سلسلة L1 أو L2 ب AggLayer ، والتي تجمع براهين ZK من جميع السلاسل المتصلة.
على الرغم من أن سلاسل التطبيقات لا تتراكم بشكل مباشر على SOL ، لأنها لن تدفع رسوما في SOL أو تستخدم SOL كرمز غاز - ما لم يتم استخدام SOL المعاد تخزينه للأمن الاقتصادي - إلا أنها تفيد بشكل كبير النظام البيئي SVM. تماما كما توجد "تأثيرات شبكة EVM" ، فإن المزيد من شوكات SVM وسلاسل التطبيقات ستعزز تأثيرات شبكة SVM. ينطبق نفس المنطق الذي يجعل Eclipse (SVM L2 on إثيريوم) صاعد ل SVM ، على الرغم من أنه منافس مباشر للشبكة الرئيسية Solana.
Solana Layer-2s، أو مجموعات، هي سلاسل منفصلة منطقيا تقوم بنشر البيانات إلى طبقة توفر البيانات (DA) الخاصة بالسلسلة المضيفة وإعادة استخدام آلية إجماع السلسلة المضيفة. يمكنهم أيضا استخدام طبقات DA أخرى مثل Celestia ، ومع ذلك ، فإنها لا تظل مجموعة بيانات حقيقية. "RollApp" هو مصطلح يستخدم بشكل عام للمجموعات الخاصة بالتطبيقات (والتي تستكشفها معظم التطبيقات Solana).
هل ستكون Solana Rollups هي نفسها إثيريوم؟
على ما يبدو لا. على Solana ، سيتم تجريد Rollups في الغالب للمستخدم النهائي. على الجبهة الأيديولوجية ، كانت إثيريوم مجموعات من أعلى إلى أسفل ، حيث قررت مؤسسة إثيريوم والقادة أن أفضل طريقة للتوسع هي من خلال مجموعات ، وبدأوا في دعم مختلف L2s بعد فشل CryptoKitties. بينما في Solana ، يكون الطلب من أسفل إلى أعلى ، أي يأتي من مطوري التطبيقات الذين يعتمدون المستهلك بشكل كبير. نتيجة لذلك ، فإن معظم المسرحيات الحالية هي مسرحيات تسويقية وهي مدفوعة بالسرد أكثر من كونها مدفوعة بطلب المستهلك. هذا فرق كبير وقد يؤدي إلى مستقبل مختلف مجموعات عما رأيناه في إثيريوم.
هل الضغط = تراكمات؟
سلاسل كتل الطبقة الأساسية لمقياس L2s (L1s) عن طريق تنفيذ المعاملات على L2 ، وتجميع بيانات المعاملة ، وضغطها. ثم يتم إرسال البيانات المضغوطة إلى L1 واستخدامها إما في دليل على الاحتيال (مجموعة التحديثات المتفائلة) أو إثبات صحة (zk rollup). يشار إلى عملية الإثبات هذه باسم "التسوية". وبالمثل ، يقوم الضغط بإلغاء تحميل المعاملات من الشبكة الرئيسية ، مما يقلل من التنافس على الحالة على الطبقة الأساسية. والجدير بالذكر أن Grass L2 ستستفيد من ضغط الحالة من أجل التراكم.
Two 'rollapps إلى حد ما' موجودان حاليا:
يتيح تطبيق المدفوعات المزود بحزمة SDK للمدفوعات الصغيرة لأي شخص الدفع وقبول المدفوعات على الفور ويستخدم أيضا مجموعة بيانات زائفة لتطبيقه. إنه يخلق نوايا لجميع المعاملات ويستخدم جهاز تسلسل يشبه التراكمي ، والذي يستقر على Solana بعد فترات N.
يؤدي استخدام بنية تشبه مجموعة التحديثات إلى:
طورت MagicBlocks ، وهي بنية تحتية لألعاب web3 ، مجموعات سريعة (أو مؤقتة) ، خاصة للألعاب. يستخدم الهيكل الحساب ل SVM ويتم تقسيم حالة اللعبة إلى مجموعات. ينقل الحالة مؤقتا إلى طبقة مساعدة أو "مجموعة التحديثات المؤقتة" ، وهي طبقة مخصصة قابلة للتكوين. تعمل مجموعة التحديثات سريعة الزوال كوقت تشغيل SVM متخصص أو مجموعة تراكمية لتسهيل معالجة المعاملات بمعدل نقل مرتفع.
يتيح استخدام بنية تشبه مجموعة التحديثات ما يلي:
يسهل هذا النهج نظاما قابلا للتطوير بدرجة كبيرة قادرا على إطلاق مجموعات عند الطلب والتوسع التلقائي أفقيا لاستيعاب المستخدمين الذين يقومون بملايين المعاملات ، دون المفاضلات النموذجية ل L2s التقليدية. بينما يركز MagicBlock بشكل خاص على الألعاب ، يمكن تطبيق هذا النهج على تطبيقات أخرى مثل المدفوعات.
يتطلب Grass 1 مليون طلب ويب في الثانية ، وهو أمر غير ممكن على الشبكة الرئيسية Solana. لذلك ، يخططون لعمل إثباتات ZK لبيانات الأصل لجميع مجموعات البيانات وتجميعها للتسوية على Solana L1. إنهم يفكرون في استخدام ضغط الحالة من مجموعة أخرى وتسوية الجذور على mainnet-beta.
سيؤدي هذا التطور إلى وضع Grass كطبقة أساسية لمجموعة واسعة من التطبيقات التي لا يمكن تحقيقها إلا فوق Grass (لاحظ أن المنصات والبنية التحتية غالبا ما تتطلب تقييمات أعلى بكثير وأن Grass ستطلق الرمز المميز قريبا :P).
تحتوي Perp DEXs على PMF فوري ل مجموعات لأنها تحسن تجربة المستخدم بشكل كبير. فقط اسأل شخصا قام بالتداول على Hyperliquid أو Aevo مقابل Solana perp DEXs ، حيث يتعين عليك التوقيع على كل معاملة ، وتنبثق المحفظة ، وعليك الانتظار ~ 10-20 ثانية. علاوة على ذلك ، لا تتطلب perps تنفيذا متزامنا وتوفر قابلية عالية للتركيب مع بقية DeFi ، لا سيما في الجانب التجاري مطابق.
ومن المثير للاهتمام أن أرماني (المؤسس المشارك لحقيبة الظهر) أيضا غردوا أنهم يميلون الآن إلى L2.
Sonic تقوم أيضا ببناء سلسلة SVM معيارية (Hypergrid) ستمكن الألعاب من نشر سلاسلها الخاصة على Solana. هناك أيضا إثيريوم مجموعات تستند إلى SVM مثل Eclipse و NitroVM التي تستخدم SVM كمحرك تنفيذ. يعمل النيون كملف L2 متوافق مع EVM على Solana. بالإضافة إلى ذلك ، هناك مشاريع في مرحلة الفكرة ، مثل Molecule (SVM بيتكوين طبقة 2).
Sovereign SDK هو إطار عمل آخر مشابه ل node.js ، ولكن لبناء مجموعات. يجلب المستخدمون رمز Rust الخاص بهم ، ونحوله إلى مجموعة تراكمية متفائلة أو ZK يمكن نشرها على أي blockchain. يمكن أن يكون رمز Rust هو منطق تطبيقك المحدد ، أو أي VM.
ينطبق نفس المبدأ على Solana. سوف يلتف مجتمع Solana حول أي حل يعزز ممتلكاتهم SOL - الأمر بهذه البساطة. مع توسع النظام البيئي Solana ، ستصبح "أموال SOL" التي تم تجاهلها ذات يوم ذات أهمية. تذكر أن معظم عمليات التجميع هي على أي حال "لعبة تسويقية" وتعطي استحقاقا أفضل لقيمة الرمز المميز حيث لا تزال الأسواق تقدر البنية التحتية أكثر من التطبيقات.
وبالمثل ، سيحدث هذا مع Solana. التعلم من إثيريوم ، فإن معظم Solana Rollapps لن تجعل المستخدمين يشعرون وكأنهم يستخدمون سلسلة منفصلة (على سبيل المثال ، Getcode).
علاوة على ذلك ، أشعر أن L2s للأغراض العامة على Solana قد تؤدي إلى نفس مشاكل إثيريوم القديمة ، أي مجموعات المركزية والازدحام وتجزئة السيولة.
بالنسبة لحالات الاستخدام المصرح بها والتخصيص ، يخدم ملحق عملة أيضا معظم الاحتياجات مثل منطق توثيق KYC / النقل مع الاحتفاظ بقابلية التركيب.
لذا ، هل سيكون DRiP L2 / appchain؟
يستخدم DRiP حاليا Solana من أجل:
* محافظ إنشاء المستخدم (يمكن أن يكون على L2 / appchain)
* توزيع NFTs المضغوطة (يمكن أن يكون على L2 / appchain)
* تداول NFTs المضغوطة (يمكن أن يكون على L2 / appchain ، ولكن يجب سد الأموال)
إذا توسعت أطروحة rollapp/appchain، فسيستفيد موفرو البنية التحتية الحاليون بشكل كبير عند دخولهم إلى أسواق جديدة:
بالتأكيد لا. لنكن واقعيين: حتى مع الأخذ في الاعتبار قانون مور (أن أداء الأجهزة سيستمر في التحسن ، ويتم تحسين Solana لمثل هذه التطورات في الأجهزة) ، فهذا غير عملي. أعتقد أن جميع المعاملات الأقل أهمية (مثل إرسال DRiP ل NFTs) ستنتقل في النهاية إلى سلاسلها الخاصة ، بينما ستبقى المعاملات الأكثر قيمة على السلسلة الرئيسية ، حيث تكون قابلية التركيب الحقيقية ضرورية (على سبيل المثال ، فوري DEXs).
ولا ، هذا لا يعني أن Solana قد خسر في معركة المتراصة والتركيب ؛ سيدير الحالات التي تعتمد على قابلية التركيب وانخفاض وقت الإستجابة أفضل من السلاسل الأخرى. ولا ، Sui / Aptos / Sei / Monad ، وما إلى ذلك ليست أفضل حتى الآن ، لأننا لا نعرف ولم يتم اختبارها بعد من أجل نشاط المستخدم الحقيقي العالي.
على عكس إثيريوم ، لا تهدف Solana الشبكة الرئيسية إلى أن تكون "سلسلة B2B" ؛ كانت وستظل دائما سلسلة المستهلكين. يعد بناء الأنظمة الموزعة على نطاق واسع أمرا صعبا للغاية ، وتتمتع Solana بأفضل إمكانات لتصبح دفتر الأستاذ المشترك العالمي للمعاملات الأكثر قيمة.
Solana يحتاج إلى رفقاء الروح: هل يمكن أن تكون Appchains و rollups هي المباراة المثالية؟
لا تتردد في الاتصال بي على Yash Agarwal (@yashhsm على تويتر) للحصول على أي اقتراحات أو إذا كان لديك أي آراء. إذا وجدت هذا ثاقبا بعض الشيء ، فيرجى مشاركته - يبرر أسابيع جهدي ويحصل على المزيد من مقل العيون :)
شكر خاص ل Karthik (PepperDEX)، Brian Breslow (Dorahacks)، Parth (Arana Ventures)، Rex (Anza)، Het Dagli (Superteam)، Kash (Superteam)، و Akshay (Superteam)، الذي راجع وقدم رؤى في مراحل مختلفة من المسودة.