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