منذ أن انتقلت إيثريوم إلى حلول التوسع التي تركز على طبقة 2، ومع ظهور أدوات مثل RaaS، تطورت العديد من سلاسل الكتل العامة بسرعة. تأمل العديد من الكيانات في بناء سلاسلها الخاصة لتمثيل مصالح مختلفة والسعي لتحقيق تقييم أعلى. ومع ذلك، فإن ظهور العديد من سلاسل الكتل العامة جعل من الصعب على تطوير النظام البيئي مواكبة وتيرة هذه السلاسل، مما أدى إلى انخفاض قيمة العديد من المشاريع عند TGE.
بمساعدة OP Stack، أطلق أحد منصات التداول طبقة 2 الخاصة به، بينما أصدرت منصة أخرى Ink؛ بمساعدة تقنية ZK، أطلق أحد المنصات XLayer؛ أصدرت Sony Soneium، وأطلقت LINE Kaia وغيرها. اليوم، تم تقليل تكلفة رأس المال والتكنولوجيا لبناء سلسلة بشكل كبير، حيث تبلغ تكلفة تشغيل سلسلة قائمة على OP Stack حوالي 10,000 دولار شهريًا.
سيكون المستقبل بالتأكيد عصر التعايش المتعدد السلاسل. على الرغم من أن هذه الطبقات 2 قد تختار التوافق مع EVM لتحقيق التفاعل، إلا أنه بسبب الكيانات الموجودة خلفها في Web2 التي لديها العديد من التطبيقات السفلية، سيكون من الصعب عليها بناء التطبيقات وتحقيق التوافق على نفس السلسلة.
تقدم البيئة متعددة السلاسل الحالية تحديًا جديدًا: السيولة وتشتت الحالة. نظرًا لأن وجود السلاسل المتعددة أمر حتمي، فإن التوافقية هي مجال يجب استكشافه وحله. هناك حاليًا العديد من حلول السيولة، مثل تجريد السلاسل، والنية، وتنفيذ التسوية، والسلاسل المتقاطعة الأصلية، وZKSharding، لكن جوهرها الأساسي هو نفسه.
نستخدم هيكل Cake المعترف به في الصناعة لتقديم مكونات الجوهرية للاختزال عبر السلاسل من الأعلى إلى الأسفل:
طبقة التطبيقات(Application Layer)
هذه هي الطبقة التي يتفاعل معها المستخدم مباشرة، وهي أيضًا أكثر طبقة مجرّدة في حلول السيولة، لأنها تحجب تمامًا تفاصيل تحويل السيولة. في طبقة التطبيق، يتفاعل المستخدم مع واجهة المقدمة، وقد لا يدرك آلية تحويل السيولة الأساسية.
طبقة 2 ( طبقة الأذونات )
تقع أسفل طبقة التطبيقات، يقوم المستخدمون بتوصيل المحفظة بـ dApp وطلب عرض الأسعار لتحقيق نية التداول. هنا تشير "النية" إلى نتيجة الصفقة النهائية التي يتوقعها المستخدم ( وهي الإخراج )، وليس مسار التنفيذ المحدد للتداول.
إدارة الحسابات وطبقة التجريد(إدارة المفاتيح وتجريد الحساب)
نظرًا لوجود بيئة متعددة السلاسل، هناك حاجة إلى نظام إدارة حسابات وتجريد يتكيف مع سلاسل مختلفة للحفاظ على الهيكل الفريد للحسابات لكل سلسلة. على سبيل المثال، نظام الحسابات القائم على كائنات SUI يختلف تمامًا عن EVM. One Balance هو مشروع تمثيلي في هذا المجال، حيث أنشأ نظام حسابات موثوق دون الحاجة إلى بناء توافق عبر السلاسل، بل يكفي الالتزام الموثوق بين أنظمة الحسابات الحالية. يحقق حساب Near الإدارة المجردة من خلال إنشاء محفظة حسابات متعددة السلاسل للمستخدمين، مما يعزز بشكل كبير تجربة المستخدم ويقلل من تجزئة تجربة المستخدم. ومع ذلك، فإن السيولة تتكامل بشكل أساسي مع السلاسل العامة الموجودة.
حل الطبقة(Solver Layer)
تتحمل هذه الطبقة مسؤولية استلام وتنفيذ نية التداول الخاصة بالمستخدم، حيث يتنافس دور Solver هنا لتقديم تجربة مستخدم أفضل، بما في ذلك أوقات تنفيذ أسرع وسرعة تنفيذ أعلى. بناءً على ذلك، قامت المشاريع المعتمدة على النية ببناء مجموعة متنوعة من الحلول المدفوعة بالنية. ومن بين المشتقات المتعلقة بهذه النية، يمكن لمكونات Predicate تحقيق نية المستخدم وفقًا لقواعد محددة.
طبقة تسوية(Settlement Layer)
هذا هو طبقة وسيطة تستخدم لحل الطبقة لتحقيق نية المستخدم. تشمل المكونات الأساسية لحلول السيولة والحالة الموزعة:
预言机(Oracle):للحصول على معلومات الحالة من سلاسل أخرى.
جسور跨链(Bridges): مسؤولة عن نقل المعلومات والسيولة عبر السلاسل.
تأكيد مسبق للخطة ( تأكيد مسبق ): تقصير وقت تأكيد السلسلة المتقاطعة.
توفر البيانات ( DA ): توفير إمكانية الوصول إلى البيانات.
بالإضافة إلى ذلك، يجب أخذ السيولة بين السلاسل، والنهائية ( Finality )، وآلية إثبات طبقة 2 وغيرها من العوامل في الاعتبار لضمان التشغيل الفعال لنظام متعدد السلاسل.
في الوقت الحالي، هناك العديد من الحلول المتاحة في السوق لمعالجة السيولة المقطوعة، وبعد استعراض عدد كبير من الحلول، وجدنا أن هناك عدة طرق رئيسية:
مركزية RaaS: مثل حلول Rollup مثل OP Stack، من خلال إضافة مرتب خاص مشترك وجسور عبر السلاسل للمساعدة في بناء Rollup على OP Stack ومشاركة السيولة والحالة. يأمل هذا في معالجة السيولة والحالة الموزعة في اتجاه أعلى. هناك جانب أكثر تفصيلاً وهو تصميم مرتب مشترك منفصل، هذه الفكرة تستهدف بشكل أكبر طبقة 2، ولا تتمتع بعمومية.
مركزية الحساب: مشابه لـ NEAR، بناء محفظة حسابات شاملة على السلسلة، من خلال تقنية تسمى "توقيع السلسلة" لدعم توقيع وتنفيذ المعاملات عبر بروتوكولات متعددة على السلسلة. المكون الرئيسي هو شبكة MPC، التي تقوم بتوقيع المعاملات متعددة السلاسل بدلاً من المستخدمين. على الرغم من أن هذه المجموعة من الحلول يمكن أن تحل بشكل كبير مشكلة تجزئة تجربة المستخدم، إلا أنها تتطلب من المطورين تنفيذاً معقداً في الخلفية، ولم تحل بشكل جوهري مشكلة السيولة وتوزيع الحالة.
مركزية الشبكة الخارجية للنوايا: وهي "مقدمة" مخطط هيكل الكعكة في شبكة Solver، حيث يقوم المستخدم بإرسال النوايا إلى شبكة Solver، ويتنافس هذا الدور في تقديم العروض، ويقدم أفضل وقت للإنجاز وسعر للصفقة، ويمكن أن تكون هذه الـ Solvers وكيل AI، أو CEX، أو صانع سوق، أو حتى البروتوكول المتكامل نفسه. على الرغم من أن النوايا يمكن أن تحقق نظريًا عمليات متعددة السلاسل معقدة من أي درجة صعوبة، إلا أنه من الضروري في التنفيذ وجود Solvers ذات سيولة كافية للمساعدة، وعند مواجهة بعض الطلبات الخارجية، هناك احتمال لوجود احتيال من قبل الـ Solvers، وإذا تم إدخال وسائل مثل إثبات الاحتيال، ستصبح صعوبة تنفيذ شبكة Solver أعلى، كما ستزداد عتبة تشغيل Solvers.
مركزية شبكة السيولة على السلسلة: هذا الاتجاه يركز بشكل خاص على تحسين مشكلة السيولة عبر السلاسل، لكنه لم يحل مشكلة تشتت حالة السلاسل الأخرى. جوهره هو بناء طبقة سيولة، يتم بناء التطبيقات عليها، لمشاركة السيولة عبر السلسلة.
مركزية التطبيقات على السلسلة: تقوم هذه التطبيقات ببناء تطبيقات ذات سيولة عالية من خلال دمج MM الكبير، أو تطبيقات الطرف الثالث وغيرها. تحتاج هذه المشاريع إلى إدارة عمليات معقدة عبر السلاسل، مما يتطلب مستوى عالٍ جدًا من المطورين، وبالتالي فإنها عرضة جدًا لحدوث هجمات القراصنة.
حل مشكلة السيولة هو موضوع مهم للغاية، حيث تمثل السيولة كل شيء في عالم المال. إذا كان من الممكن بناء منصة متكاملة للسيولة، خاصةً من خلال دمج السيولة الموزعة على جميع الشبكات، فسيكون لديها إمكانيات كبيرة جداً.
في التصنيفين المذكورين أعلاه، يمكننا أن نرى أن Settlement Layer هو الحل الأكثر ذرية بناءً على هيكل الكعكة، وفوق هذه الحلول الذرية مثل cross-chain و oracles و Pre-Confirmation، يتم بناء طبقة أكثر تجريدًا، وهي Layer Solver و Permission Layer و Application Layer. يمكن فهم المستويات المختلفة التي تم بناؤها في اتجاهات مختلفة لتقديم حلول تجريدية أو السيولة كما هو مذكور أعلاه على أنها علاقات تفاعلية. ومع ذلك، لا تزال هذه الحلول ليست حلولًا ذرية، حيث أن مشكلة انقسام السيولة قد جلبت ظهور العديد من المشكلات المعقدة، وبالتالي، تم تطوير مجموعة متنوعة من الحلول من أجل التفاعل بين الأنظمة. ولكن بشكل أساسي، لا تزال تعتمد على هذه المكونات. في ما يلي، سنتناول عدة مشاريع تمثل مفاهيم تجريد السلاسل لنتعرف على كيفية معالجة كل منها لمشكلة انقسام السيولة من وجهة نظرها.
إنفينيت
بنت INFINIT خدمة RaaS في مجال DeFi، والتي يمكنها توفير المكونات اللازمة للبناء المباشر لبروتوكولات DeFi، مثل Oracle و Pool Type و IRM و Asset وغيرها، كما يمكنها توفير مكونات مثل Leverage Trading و Yield Strategy جاهزة للاستخدام الفوري. مما يعادل بناء التطبيقات الأخرى، لكن السيولة النهائية توضع في طبقة السيولة الخاصة بـ Infinit. ومع ذلك، لم تكشف حتى الآن عن كيفية عملها الأساسية.
شبكة خالداني
خلال بناء ثلاثة مكونات أساسية، وهي طبقة توافق النوايا، والصلاحية، وطبقة التسوية العامة.
يمكن للتطبيقات الخارجية أو طبقة النوايا نشر نوايا إلى Khalani، ثم يمكن لطبقة النوايا المتوافقة في Khalani تحويل النوايا الخارجية إلى التنسيق الذي يمكن لبروتوكول Solver التعرف عليه، والتنسيق المعياري المستخدم هو لغة Validity. يتحمل عقد Khalani مسؤولية تقديم النتائج النهائية إلى طبقة التسوية العامة من خلال جسر عبر السلاسل وتقنيات التسوية السريعة وغيرها. لا يزال هذا المشروع في مرحلة البناء، ولم يتم الكشف عن المزيد من تفاصيل العمل بعد.
عرق السوس
ليكوريس هو تطبيق لامركزي يمكنه تحقيق اكتشاف الأسعار القائم على المزادات وحمامات السيولة أحادية الجانب. المهمة الرئيسية لليكوريس هي توفير أدوات إدارة المخزون الفعالة لشركات التداول المحترفة، والاتصال بسهولة بالبروتوكولات الأساسية للتمويل اللامركزي عند تسوية المعاملات بناءً على نية الاستخدام. في الوقت نفسه، أنشأ ليكوريس سوقًا للإقراض لتسهيل معاملات الإقراض. يركز هذا التطبيق بشكل أكبر على التداول نفسه. لا يزال في مرحلة التطوير.
زيون
Xion هو مشروع تم تطويره من علامة Burnt التجارية، حيث كانت Burnt في السابق تركز على تطبيقات المستهلكين، ثم اكتشف الفريق وجود مشكلة كبيرة في تجزئة التفاعلات على السلسلة، لذلك قاموا ببناء Xion لتحسين هذه المشكلة. Xion مبني على بروتوكول إجماع Comet BFT. الاتصالات عبر السلاسل المستخدمة تعتمد على Cosmos IBC، مما يجعله أكثر أصالة وأمانًا من جسور السلاسل الأخرى.
=nil; مؤسسة
nil هو سوق قوة الحوسبة ZK للإيثريوم، ومعالج ZK و مطور Layer2، حيث يمتلك الفريق خلفية تقنية قوية في ZK. قدموا حل zkSharding، وهو حل يستخدم تقنية ZK لتوسيع شبكة الإيثريوم الرئيسية أفقياً، وتنفيذ معالجة المعاملات بالتوازي من خلال الشظايا وإنشاء ZKP، بينما تتحقق الشظية الرئيسية من البيانات، وتتواصل مع الإيثريوم وتزامن حالة الشبكة بين جميع المدققين. تدير الشظية الرئيسية أيضاً توزيع المدققين والحسابات في الشظايا التنفيذية. بروتوكول الإجماع المستخدم من قبل لجنة التحقق هو أيضاً Hotstuff، وهو شائع في المشاريع الحديثة للتنفيذ المتوازي. =nil; لقد دمجت L2 من البداية التواصل عبر الشظايا في البروتوكول. يتم التحقق من الرسائل عبر الشظايا من قبل لجنة المدققين في كل شظية كمعاملات.
الفكرة الأساسية هي بناء هيكل اتصال عبر القطع مشابه لـ IBC من خلال هيكل Layer2 المجزأ، مما سيمكن من حل مشكلتي السيولة وتشتت الحالة. ومع ذلك، فإن الفكرة الرئيسية ليست معقولة، لأن مشكلة تشتت السيولة تتعلق بمشكلة متعددة السلاسل، بينما ما يتم بناؤه هو Layer2 منفرد، مما يعني أنه لحلها يجب أن تصبح جميع السلاسل قطعة من ZK-sharding، وهو أمر يصعب تحقيقه.
ERC-7683
الإيثيريوم أيضًا يعمل على حل مشكلة السيولة عبر السلاسل، حيث تدعم حاليًا عدة منصات معيار ERC7683، والذي يستخدم أيضًا طريقة عبر السلاسل القائمة على Intent. الهدف الرئيسي هو إنشاء معيار عام لعمليات عبر L2 والسلاسل الجانبية، وتوحيد واجهات الطلبات والتسويات، لتحقيق تنفيذ سلس عبر السلاسل. النقطة الأساسية هي أن Filler يمكن أن يُعتبر أيضًا دور Solver في تجريد السلسلة للدفع بالنيابة. تم بناء هذا الاقتراح من قبل مشروعين مشتركين، وهو قيد المراجعة حاليًا من قبل مجموعة Cake.
OP Stack
OP Stack و ERC-7683 و zkSharding، كلها حلول لتمزيق السيولة بين Layer2 داخل الإيثيريوم، يتم حلها من جوانب الهيكل، والتوافق، والتطبيق. يقوم OP Stack بتصميم حل متعدد Layer2 كاملاً لحل مشكلات نقل المعلومات ولامركزية Sequencer دفعة واحدة، وعند استخدامك لبنية OP Stack، سيتم نشر عقود عبر السلسلة تلقائيًا، وسيكون هناك مشرف لتحدي تجنب نقل معلومات عبر السلسلة مزيفة. حاليًا، هناك العديد من المشاريع المعروفة التي تستخدم هيكل OP Stack.
من بينها، المثال الأكثر وضوحًا هو Unichain. تعتمد Unichain بشكل أساسي على
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تحديات وفوائد السيولة في عصر طبقة 2 وحلولها
دراسة مشكلة السيولة المقطعة في عصر طبقة 2
منذ أن انتقلت إيثريوم إلى حلول التوسع التي تركز على طبقة 2، ومع ظهور أدوات مثل RaaS، تطورت العديد من سلاسل الكتل العامة بسرعة. تأمل العديد من الكيانات في بناء سلاسلها الخاصة لتمثيل مصالح مختلفة والسعي لتحقيق تقييم أعلى. ومع ذلك، فإن ظهور العديد من سلاسل الكتل العامة جعل من الصعب على تطوير النظام البيئي مواكبة وتيرة هذه السلاسل، مما أدى إلى انخفاض قيمة العديد من المشاريع عند TGE.
بمساعدة OP Stack، أطلق أحد منصات التداول طبقة 2 الخاصة به، بينما أصدرت منصة أخرى Ink؛ بمساعدة تقنية ZK، أطلق أحد المنصات XLayer؛ أصدرت Sony Soneium، وأطلقت LINE Kaia وغيرها. اليوم، تم تقليل تكلفة رأس المال والتكنولوجيا لبناء سلسلة بشكل كبير، حيث تبلغ تكلفة تشغيل سلسلة قائمة على OP Stack حوالي 10,000 دولار شهريًا.
سيكون المستقبل بالتأكيد عصر التعايش المتعدد السلاسل. على الرغم من أن هذه الطبقات 2 قد تختار التوافق مع EVM لتحقيق التفاعل، إلا أنه بسبب الكيانات الموجودة خلفها في Web2 التي لديها العديد من التطبيقات السفلية، سيكون من الصعب عليها بناء التطبيقات وتحقيق التوافق على نفس السلسلة.
تقدم البيئة متعددة السلاسل الحالية تحديًا جديدًا: السيولة وتشتت الحالة. نظرًا لأن وجود السلاسل المتعددة أمر حتمي، فإن التوافقية هي مجال يجب استكشافه وحله. هناك حاليًا العديد من حلول السيولة، مثل تجريد السلاسل، والنية، وتنفيذ التسوية، والسلاسل المتقاطعة الأصلية، وZKSharding، لكن جوهرها الأساسي هو نفسه.
نستخدم هيكل Cake المعترف به في الصناعة لتقديم مكونات الجوهرية للاختزال عبر السلاسل من الأعلى إلى الأسفل:
طبقة التطبيقات(Application Layer)
هذه هي الطبقة التي يتفاعل معها المستخدم مباشرة، وهي أيضًا أكثر طبقة مجرّدة في حلول السيولة، لأنها تحجب تمامًا تفاصيل تحويل السيولة. في طبقة التطبيق، يتفاعل المستخدم مع واجهة المقدمة، وقد لا يدرك آلية تحويل السيولة الأساسية.
طبقة 2 ( طبقة الأذونات )
تقع أسفل طبقة التطبيقات، يقوم المستخدمون بتوصيل المحفظة بـ dApp وطلب عرض الأسعار لتحقيق نية التداول. هنا تشير "النية" إلى نتيجة الصفقة النهائية التي يتوقعها المستخدم ( وهي الإخراج )، وليس مسار التنفيذ المحدد للتداول.
إدارة الحسابات وطبقة التجريد(إدارة المفاتيح وتجريد الحساب)
نظرًا لوجود بيئة متعددة السلاسل، هناك حاجة إلى نظام إدارة حسابات وتجريد يتكيف مع سلاسل مختلفة للحفاظ على الهيكل الفريد للحسابات لكل سلسلة. على سبيل المثال، نظام الحسابات القائم على كائنات SUI يختلف تمامًا عن EVM. One Balance هو مشروع تمثيلي في هذا المجال، حيث أنشأ نظام حسابات موثوق دون الحاجة إلى بناء توافق عبر السلاسل، بل يكفي الالتزام الموثوق بين أنظمة الحسابات الحالية. يحقق حساب Near الإدارة المجردة من خلال إنشاء محفظة حسابات متعددة السلاسل للمستخدمين، مما يعزز بشكل كبير تجربة المستخدم ويقلل من تجزئة تجربة المستخدم. ومع ذلك، فإن السيولة تتكامل بشكل أساسي مع السلاسل العامة الموجودة.
حل الطبقة(Solver Layer)
تتحمل هذه الطبقة مسؤولية استلام وتنفيذ نية التداول الخاصة بالمستخدم، حيث يتنافس دور Solver هنا لتقديم تجربة مستخدم أفضل، بما في ذلك أوقات تنفيذ أسرع وسرعة تنفيذ أعلى. بناءً على ذلك، قامت المشاريع المعتمدة على النية ببناء مجموعة متنوعة من الحلول المدفوعة بالنية. ومن بين المشتقات المتعلقة بهذه النية، يمكن لمكونات Predicate تحقيق نية المستخدم وفقًا لقواعد محددة.
طبقة تسوية(Settlement Layer)
هذا هو طبقة وسيطة تستخدم لحل الطبقة لتحقيق نية المستخدم. تشمل المكونات الأساسية لحلول السيولة والحالة الموزعة:
بالإضافة إلى ذلك، يجب أخذ السيولة بين السلاسل، والنهائية ( Finality )، وآلية إثبات طبقة 2 وغيرها من العوامل في الاعتبار لضمان التشغيل الفعال لنظام متعدد السلاسل.
في الوقت الحالي، هناك العديد من الحلول المتاحة في السوق لمعالجة السيولة المقطوعة، وبعد استعراض عدد كبير من الحلول، وجدنا أن هناك عدة طرق رئيسية:
مركزية RaaS: مثل حلول Rollup مثل OP Stack، من خلال إضافة مرتب خاص مشترك وجسور عبر السلاسل للمساعدة في بناء Rollup على OP Stack ومشاركة السيولة والحالة. يأمل هذا في معالجة السيولة والحالة الموزعة في اتجاه أعلى. هناك جانب أكثر تفصيلاً وهو تصميم مرتب مشترك منفصل، هذه الفكرة تستهدف بشكل أكبر طبقة 2، ولا تتمتع بعمومية.
مركزية الحساب: مشابه لـ NEAR، بناء محفظة حسابات شاملة على السلسلة، من خلال تقنية تسمى "توقيع السلسلة" لدعم توقيع وتنفيذ المعاملات عبر بروتوكولات متعددة على السلسلة. المكون الرئيسي هو شبكة MPC، التي تقوم بتوقيع المعاملات متعددة السلاسل بدلاً من المستخدمين. على الرغم من أن هذه المجموعة من الحلول يمكن أن تحل بشكل كبير مشكلة تجزئة تجربة المستخدم، إلا أنها تتطلب من المطورين تنفيذاً معقداً في الخلفية، ولم تحل بشكل جوهري مشكلة السيولة وتوزيع الحالة.
مركزية الشبكة الخارجية للنوايا: وهي "مقدمة" مخطط هيكل الكعكة في شبكة Solver، حيث يقوم المستخدم بإرسال النوايا إلى شبكة Solver، ويتنافس هذا الدور في تقديم العروض، ويقدم أفضل وقت للإنجاز وسعر للصفقة، ويمكن أن تكون هذه الـ Solvers وكيل AI، أو CEX، أو صانع سوق، أو حتى البروتوكول المتكامل نفسه. على الرغم من أن النوايا يمكن أن تحقق نظريًا عمليات متعددة السلاسل معقدة من أي درجة صعوبة، إلا أنه من الضروري في التنفيذ وجود Solvers ذات سيولة كافية للمساعدة، وعند مواجهة بعض الطلبات الخارجية، هناك احتمال لوجود احتيال من قبل الـ Solvers، وإذا تم إدخال وسائل مثل إثبات الاحتيال، ستصبح صعوبة تنفيذ شبكة Solver أعلى، كما ستزداد عتبة تشغيل Solvers.
مركزية شبكة السيولة على السلسلة: هذا الاتجاه يركز بشكل خاص على تحسين مشكلة السيولة عبر السلاسل، لكنه لم يحل مشكلة تشتت حالة السلاسل الأخرى. جوهره هو بناء طبقة سيولة، يتم بناء التطبيقات عليها، لمشاركة السيولة عبر السلسلة.
مركزية التطبيقات على السلسلة: تقوم هذه التطبيقات ببناء تطبيقات ذات سيولة عالية من خلال دمج MM الكبير، أو تطبيقات الطرف الثالث وغيرها. تحتاج هذه المشاريع إلى إدارة عمليات معقدة عبر السلاسل، مما يتطلب مستوى عالٍ جدًا من المطورين، وبالتالي فإنها عرضة جدًا لحدوث هجمات القراصنة.
حل مشكلة السيولة هو موضوع مهم للغاية، حيث تمثل السيولة كل شيء في عالم المال. إذا كان من الممكن بناء منصة متكاملة للسيولة، خاصةً من خلال دمج السيولة الموزعة على جميع الشبكات، فسيكون لديها إمكانيات كبيرة جداً.
في التصنيفين المذكورين أعلاه، يمكننا أن نرى أن Settlement Layer هو الحل الأكثر ذرية بناءً على هيكل الكعكة، وفوق هذه الحلول الذرية مثل cross-chain و oracles و Pre-Confirmation، يتم بناء طبقة أكثر تجريدًا، وهي Layer Solver و Permission Layer و Application Layer. يمكن فهم المستويات المختلفة التي تم بناؤها في اتجاهات مختلفة لتقديم حلول تجريدية أو السيولة كما هو مذكور أعلاه على أنها علاقات تفاعلية. ومع ذلك، لا تزال هذه الحلول ليست حلولًا ذرية، حيث أن مشكلة انقسام السيولة قد جلبت ظهور العديد من المشكلات المعقدة، وبالتالي، تم تطوير مجموعة متنوعة من الحلول من أجل التفاعل بين الأنظمة. ولكن بشكل أساسي، لا تزال تعتمد على هذه المكونات. في ما يلي، سنتناول عدة مشاريع تمثل مفاهيم تجريد السلاسل لنتعرف على كيفية معالجة كل منها لمشكلة انقسام السيولة من وجهة نظرها.
إنفينيت
بنت INFINIT خدمة RaaS في مجال DeFi، والتي يمكنها توفير المكونات اللازمة للبناء المباشر لبروتوكولات DeFi، مثل Oracle و Pool Type و IRM و Asset وغيرها، كما يمكنها توفير مكونات مثل Leverage Trading و Yield Strategy جاهزة للاستخدام الفوري. مما يعادل بناء التطبيقات الأخرى، لكن السيولة النهائية توضع في طبقة السيولة الخاصة بـ Infinit. ومع ذلك، لم تكشف حتى الآن عن كيفية عملها الأساسية.
شبكة خالداني
خلال بناء ثلاثة مكونات أساسية، وهي طبقة توافق النوايا، والصلاحية، وطبقة التسوية العامة.
يمكن للتطبيقات الخارجية أو طبقة النوايا نشر نوايا إلى Khalani، ثم يمكن لطبقة النوايا المتوافقة في Khalani تحويل النوايا الخارجية إلى التنسيق الذي يمكن لبروتوكول Solver التعرف عليه، والتنسيق المعياري المستخدم هو لغة Validity. يتحمل عقد Khalani مسؤولية تقديم النتائج النهائية إلى طبقة التسوية العامة من خلال جسر عبر السلاسل وتقنيات التسوية السريعة وغيرها. لا يزال هذا المشروع في مرحلة البناء، ولم يتم الكشف عن المزيد من تفاصيل العمل بعد.
عرق السوس
ليكوريس هو تطبيق لامركزي يمكنه تحقيق اكتشاف الأسعار القائم على المزادات وحمامات السيولة أحادية الجانب. المهمة الرئيسية لليكوريس هي توفير أدوات إدارة المخزون الفعالة لشركات التداول المحترفة، والاتصال بسهولة بالبروتوكولات الأساسية للتمويل اللامركزي عند تسوية المعاملات بناءً على نية الاستخدام. في الوقت نفسه، أنشأ ليكوريس سوقًا للإقراض لتسهيل معاملات الإقراض. يركز هذا التطبيق بشكل أكبر على التداول نفسه. لا يزال في مرحلة التطوير.
زيون
Xion هو مشروع تم تطويره من علامة Burnt التجارية، حيث كانت Burnt في السابق تركز على تطبيقات المستهلكين، ثم اكتشف الفريق وجود مشكلة كبيرة في تجزئة التفاعلات على السلسلة، لذلك قاموا ببناء Xion لتحسين هذه المشكلة. Xion مبني على بروتوكول إجماع Comet BFT. الاتصالات عبر السلاسل المستخدمة تعتمد على Cosmos IBC، مما يجعله أكثر أصالة وأمانًا من جسور السلاسل الأخرى.
=nil; مؤسسة
nil هو سوق قوة الحوسبة ZK للإيثريوم، ومعالج ZK و مطور Layer2، حيث يمتلك الفريق خلفية تقنية قوية في ZK. قدموا حل zkSharding، وهو حل يستخدم تقنية ZK لتوسيع شبكة الإيثريوم الرئيسية أفقياً، وتنفيذ معالجة المعاملات بالتوازي من خلال الشظايا وإنشاء ZKP، بينما تتحقق الشظية الرئيسية من البيانات، وتتواصل مع الإيثريوم وتزامن حالة الشبكة بين جميع المدققين. تدير الشظية الرئيسية أيضاً توزيع المدققين والحسابات في الشظايا التنفيذية. بروتوكول الإجماع المستخدم من قبل لجنة التحقق هو أيضاً Hotstuff، وهو شائع في المشاريع الحديثة للتنفيذ المتوازي. =nil; لقد دمجت L2 من البداية التواصل عبر الشظايا في البروتوكول. يتم التحقق من الرسائل عبر الشظايا من قبل لجنة المدققين في كل شظية كمعاملات.
الفكرة الأساسية هي بناء هيكل اتصال عبر القطع مشابه لـ IBC من خلال هيكل Layer2 المجزأ، مما سيمكن من حل مشكلتي السيولة وتشتت الحالة. ومع ذلك، فإن الفكرة الرئيسية ليست معقولة، لأن مشكلة تشتت السيولة تتعلق بمشكلة متعددة السلاسل، بينما ما يتم بناؤه هو Layer2 منفرد، مما يعني أنه لحلها يجب أن تصبح جميع السلاسل قطعة من ZK-sharding، وهو أمر يصعب تحقيقه.
ERC-7683
الإيثيريوم أيضًا يعمل على حل مشكلة السيولة عبر السلاسل، حيث تدعم حاليًا عدة منصات معيار ERC7683، والذي يستخدم أيضًا طريقة عبر السلاسل القائمة على Intent. الهدف الرئيسي هو إنشاء معيار عام لعمليات عبر L2 والسلاسل الجانبية، وتوحيد واجهات الطلبات والتسويات، لتحقيق تنفيذ سلس عبر السلاسل. النقطة الأساسية هي أن Filler يمكن أن يُعتبر أيضًا دور Solver في تجريد السلسلة للدفع بالنيابة. تم بناء هذا الاقتراح من قبل مشروعين مشتركين، وهو قيد المراجعة حاليًا من قبل مجموعة Cake.
OP Stack
OP Stack و ERC-7683 و zkSharding، كلها حلول لتمزيق السيولة بين Layer2 داخل الإيثيريوم، يتم حلها من جوانب الهيكل، والتوافق، والتطبيق. يقوم OP Stack بتصميم حل متعدد Layer2 كاملاً لحل مشكلات نقل المعلومات ولامركزية Sequencer دفعة واحدة، وعند استخدامك لبنية OP Stack، سيتم نشر عقود عبر السلسلة تلقائيًا، وسيكون هناك مشرف لتحدي تجنب نقل معلومات عبر السلسلة مزيفة. حاليًا، هناك العديد من المشاريع المعروفة التي تستخدم هيكل OP Stack.
من بينها، المثال الأكثر وضوحًا هو Unichain. تعتمد Unichain بشكل أساسي على