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