مع تحول إيثيريوم نحو حلول التوسع التي تركز على طبقة 2، بالإضافة إلى ظهور أدوات مثل RaaS، تطورت العديد من سلاسل الكتل العامة بسرعة. تأمل العديد من الكيانات في بناء سلاسلها الخاصة لتمثيل مصالح مختلفة والسعي لتحقيق تقييم أعلى. ومع ذلك، فإن ظهور العديد من سلاسل الكتل العامة جعل من الصعب على تطوير النظام البيئي مواكبة سرعة سلاسل الكتل العامة، مما أدى إلى انهيار العديد من المشاريع عند TGE.
بفضل OP Stack، أطلقت منصة تداول طبقة 2 الخاصة بها، بينما أصدرت منصة أخرى Ink؛ وبفضل تقنية ZK، أطلقت منصة XLayer؛ كما أصدرت Sony Soneium، وأطلقت LINE Kaia وغيرها. اليوم، تم تقليل عتبة التمويل والتكنولوجيا لبناء سلسلة بشكل كبير، حيث تبلغ تكلفة تشغيل سلسلة تعتمد على OP Stack حوالي 10,000 دولار شهريًا.
ستكون المستقبل بلا شك عصر التعايش بين الشبكات المتعددة. على الرغم من أن هذه الطبقات 2 قد تختار التوافق مع EVM لتحقيق التفاعل، إلا أنه نظرًا لوجود عدد كبير من التطبيقات التابعة للكيانات Web2 وراءها، سيكون من الصعب عليها بناء التطبيقات والوصول إلى توافق على نفس السلسلة.
تقدم البيئة متعددة السلاسل الحالية تحديًا جديدًا: السيولة وتشتت الحالة. نظرًا لأن وجود السلاسل المتعددة أمر حتمي، فإن قابلية التشغيل البيني هي مجال يجب استكشافه وحله. هناك حاليًا العديد من حلول السيولة، مثل تجريد السلاسل، والنية، والتنفيذ الواضح، والعبور الأصلي بين السلاسل، وتقسيم ZK، ولكن جوهرها الأساسي هو نفسه.
نستخدم هيكل Cake المعترف به على نطاق واسع في الصناعة لتقديم مكونات الفكرة الأساسية للربط بين الشبكات من الأعلى إلى الأسفل:
طبقة التطبيق (Application Layer)
هذه هي الطبقة التي يتفاعل معها المستخدمون مباشرة، وهي أيضًا أكثر الطبقات تجريدًا في حلول السيولة، لأنها تخفي بالكامل تفاصيل تحويل السيولة. في طبقة التطبيق، يتفاعل المستخدمون مع واجهة المستخدم الأمامية، وقد لا يفهمون آلية تحويل السيولة الأساسية.
طبقة الأذونات (Permission Layer)
تقع أسفل طبقة التطبيقات، حيث يقوم المستخدمون بالاتصال بالمحفظة إلى dApp وطلب الأسعار لتلبية نية التداول. هنا تشير "النية" إلى النتيجة النهائية المتوقعة من قبل المستخدم (أي المخرجات)، وليس مسار التنفيذ الفعلي للتداول.
إدارة الحسابات وطبقة التجريد (Key Management and Account Abstraction)
نظرًا لوجود بيئة متعددة السلاسل، هناك حاجة إلى نظام إدارة حسابات وتبسيط يتكيف مع سلاسل مختلفة للحفاظ على هيكل الحسابات الفريد لكل سلسلة. على سبيل المثال، نظام الحسابات القائم على الكائنات في SUI يختلف تمامًا عن EVM. One Balance هو مشروع ممثل في هذا المجال، حيث يبني نظام حسابات موثوق به، دون الحاجة إلى إنشاء توافق بين السلاسل، بل يكفي الالتزام الموثوق بين أنظمة الحسابات الحالية. يقوم حساب Near بتحقيق الإدارة البسيطة من خلال إنشاء محفظة حسابات متعددة السلاسل للمستخدمين، مما يحسن بشكل كبير تجربة المستخدم ويقلل من تفتت تجربة المستخدم. ومع ذلك، فإن السيولة تتكامل بشكل رئيسي مع سلاسل العامة الموجودة.
طبقة الحل (Solver Layer)
تتحمل هذه الطبقة مسؤولية استقبال وتنفيذ نوايا معاملات المستخدم، حيث تتنافس دور Solver هنا لتوفير تجربة مستخدم أفضل، بما في ذلك أوقات تنفيذ أسرع وسرعة تنفيذ أعلى. بناءً على ذلك، تم بناء مشاريع متنوعة مدفوعة بالنوايا على أساس نوايا المستخدم. من بين هذه النوايا، يمكن أن تحقق المشتقات مثل مكون Predicate نية المستخدم بموجب قواعد محددة.
طبقة التسوية (Settlement Layer)
هذه هي طبقة وسيطة تُستخدم لحل الطبقة لتحقيق نية المستخدم. تشمل المكونات الأساسية لحلول السيولة وتوزيع الحالة:
أوراكل (Oracle): يستخدم للحصول على معلومات حالة من سلاسل أخرى.
جسر عبر السلاسل (Bridges): مسؤول عن نقل المعلومات والسيولة عبر السلاسل.
تأكيد مسبق للخطة (Pre-Confirmation): تقصير وقت تأكيد سلسلة الكتل.
توفر البيانات (DA): توفير إمكانية الوصول إلى البيانات.
بالإضافة إلى ذلك، يجب أخذ السيولة بين السلاسل، النهائية (Finality)، وآلية إثبات طبقة 2 في الاعتبار، لضمان التشغيل الفعال للنظام المتعدد السلاسل.
حاليًا، هناك العديد من الحلول المتاحة في السوق لمعالجة السيولة المقطوعة، وبعد استعراض عدد كبير من الحلول، وجدنا أن الطرق الرئيسية هي هذه الطرق:
مركزية RaaS: مثل الحلول المتداولة مثل OP Stack، من خلال إضافة محددات ترتيب مشتركة وجسور عبر السلاسل لمساعدة في بناء سيولة مشتركة وحالة على OP Stack. يأمل هذا في معالجة السيولة وحالة التفريق في اتجاه أعلى. هناك تصميم أكثر تفصيلاً لمحدد ترتيب مشترك منفصل، وهذا الحل أكثر استهدافاً لطبقة 2، ولا يتمتع بالعمومية.
مركزية الحساب: بناء محفظة حسابات شاملة عبر سلسلة، من خلال تقنية تُعرف باسم "توقيع السلسلة" لدعم توقيع وتنفيذ المعاملات عبر بروتوكولات blockchain متعددة. المكون الأساسي هو شبكة MPC، التي تحل محل المستخدمين في توقيع المعاملات متعددة السلاسل. هذه الخطة، على الرغم من أنها يمكن أن تحل بشكل كبير مشكلة تجزئة تجربة المستخدم، إلا أنها تتطلب من المطورين تنفيذات خلفية معقدة، ولا تحل بشكل جوهري مشكلة السيولة والحالة المشتتة.
مركزية شبكة النوايا خارج السلسلة: أي ما يعادل شبكة Solver في مخطط هيكل كعكة "المقدمة" لدينا، حيث يقوم المستخدم بإرسال نوايا إلى شبكة Solver، ويتنافس هذا الدور على تقديم عروض، موفرًا أفضل وقت إتمام وسعر تداول، ويمكن أن تكون هذه الـ Solver عملاء ذكيين، أو CEX، أو صانعي السوق، أو حتى بروتوكولات متكاملة نفسها. على الرغم من أن النوايا يمكن أن تحقق عمليات عبر السلاسل ذات تعقيد عشوائي من الناحية النظرية، إلا أنه في التنفيذ، يتطلب الأمر وجود ما يكفي من Solver السيولة للمساعدة، وعندما تواجه بعض المتطلبات خارج السلسلة، توجد إمكانية لحدوث خداع من قبل Solver، وإذا تم إدخال أساليب مثل إثبات الاحتيال، فإن صعوبة تنفيذ شبكة Solver ستزداد، وكذلك ستزداد عتبة تشغيل Solver.
مركزية شبكة السيولة على السلسلة: هذا الاتجاه يركز بشكل خاص على تحسين مشاكل السيولة عبر السلاسل، لكنه لم يحل مشكلة تشتت الحالة على السلاسل الأخرى. جوهره هو بناء طبقة للسيولة، حيث يتم بناء التطبيقات على هذه الطبقة لمشاركة السيولة عبر السلسلة.
مركزية التطبيقات على السلسلة: تقوم هذه التطبيقات بإنشاء تطبيقات عالية السيولة من خلال دمج MM الكبير أو تطبيقات الطرف الثالث وما إلى ذلك. تتطلب هذه المشاريع إدارة عمليات معقدة عبر السلاسل، مما يتطلب مستوى عالٍ من المهارة من المطورين، وبالتالي فهي عرضة لحدوث هجمات القرصنة.
حل مشكلة السيولة هو موضوع مهم للغاية، حيث تمثل السيولة كل شيء في العالم المالي. إذا كان من الممكن بناء منصة متكاملة للسيولة، خاصةً من خلال دمج السيولة المتناثرة عبر السلسلة بأكملها، فسوف يكون لدينا إمكانيات كبيرة جداً، وقد نظرنا أيضاً في العديد من الحلول المختلفة.
في التصنيفين المذكورين أعلاه، يمكننا أن نرى وفقًا لهياكل الكعكة، أن Settlement Layer هو الحل الأكثر ذرية، وعلى هذه الحلول الذرية مثل التقنيات عبر السلاسل، والأوراكل، وحلول Pre-Confirmation، تم بناء طبقة أكثر تجريدًا، وهي Solver Layer وPermission Layer وApplication Layer. الحلول المختلفة التي قمنا بإدراجها أعلاه لبناء الحلول التجريدية أو السيولة في اتجاهات مختلفة تتماشى مع هذه المستويات المختلفة، ويمكن فهمها على أنها علاقة بين الموردين والمستخدمين. ومع ذلك، لا تزال هذه الحلول ليست حلولًا ذرية، حيث أن مشكلة فصل السيولة بأكملها قد أدت إلى ظهور العديد من المشكلات الفرعية المعقدة، وبالتالي، نشأت حلول متنوعة لمشكلة التشغيل المتداخل. ولكن في جوهرها، لا تزال تعتمد على هذه المكونات. في ما يلي، سنناقش بعض المشاريع التي تتعلق بمفاهيم السلاسل التجريدية النموذجية، لنرى كيف تحل كل منها مشكلة فصل السيولة من وجهة نظرها الخاصة.
بنت INFINIT خدمة RaaS في مجال DeFi، والتي يمكنها توفير المكونات اللازمة للبناء المباشر لبروتوكولات DeFi، مثل Oracle، نوع Pool، IRM، Asset، وغيرها، كما يمكنها توفير مكونات مثل التداول بالرافعة المالية واستراتيجية العائد التي يمكن تفعيلها على الفور. يعد هذا بمثابة طرف بناء التطبيقات الأخرى، لكن السيولة النهائية توضع في طبقة السيولة الخاصة بـ Infinit. ومع ذلك، لم تكشف بعد عن الآلية الأساسية لعملها.
بنيت Khalani ثلاثة مكونات أساسية، وهي طبقة توافق النوايا وValidity وطبقة التسوية العامة. يمكن للتطبيقات الخارجية أو طبقة النوايا نشر نوايا إلى Khalani، ثم تستطيع طبقة توافق النوايا في Khalani تحويل النوايا الخارجية إلى تنسيق يمكن لبروتوكول Solver التعرف عليه، حيث أن التنسيق المستخدم هو لغة Validity. تتولى عقد Khalani مسؤولية تقديم النتيجة النهائية إلى طبقة التسوية العامة من خلال جسر عبر السلاسل وتقنيات التسوية السريعة.
Liquorice هو تطبيق لامركزي يتيح اكتشاف الأسعار القائم على المزاد وحمامات السيولة أحادية الجانب. المهمة الرئيسية لـ Liquorice هي توفير أدوات إدارة المخزون الفعالة للشركات التجارية المحترفة، والتواصل بسهولة مع بروتوكولات DeFi الأساسية عند تسوية المعاملات باستخدام نية الاستخدام. في الوقت نفسه، أنشأت Liquorice سوقًا للإقراض لتداولات الإقراض الخاصة بها. يركز هذا التطبيق بشكل أكبر على التجارة نفسها.
Xion هو مبني على بروتوكول توافق Comet BFT. التواصل عبر السلاسل المتبنى يعتمد على Cosmos IBC، لذا فهو أكثر طبيعية وأمانًا من جسور السلاسل الأخرى.
=nil; قدمت Foundation حل zkSharding، وهو حل يستخدم تقنية ZK لتوسيع شبكة الإيثريوم الرئيسية أفقياً، وتنفيذ معالجة المعاملات بالتوازي مع تقسيمات البيانات وتوليد ZKP، بينما يقوم الشريحة الرئيسية بالتحقق من البيانات، والتواصل مع الإيثريوم ومزامنة حالة الشبكة بين جميع المدققين. كما تدير الشريحة الرئيسية توزيع المدققين والحسابات في الشريحة التنفيذية. بروتوكول الإجماع المستخدم من قبل لجنة التحقق هو أيضاً Hotstuff، وهو شائع جداً في المشاريع الحديثة للتنفيذ المتوازي. =nil; لقد تم تضمين الاتصال عبر الشرائح في بروتوكول L2 منذ البداية.
يعمل Ethereum أيضًا على حل مشكلة السيولة عبر السلاسل، حيث تدعم بعض منصات التداول الرئيسية أولاً معيار ERC7683، والذي يعتمد أيضًا على طريقة عبر السلاسل القائمة على Intent. الهدف الأساسي هو إنشاء معيار موحد للعمليات عبر السلاسل بين L2 والجانبية، وتوحيد أوامر وواجهات التسوية، لتحقيق تنفيذ سلس عبر السلاسل، والجوهر الرئيسي هو أن Filler يمكن أن يُطلق عليه أيضًا دور Solver في تجريد السلسلة.
تقوم OP Stack بتصميم حل شامل متعدد الطبقات 2، لحل مشاكل نقل المعلومات واللامركزية للمتسلسلين مرة واحدة. عند استخدامك لهندسة OP Stack، سيتم نشر العقود عبر السلاسل تلقائيًا، كما سيكون هناك مشرف للتحدي لتجنب نقل المعلومات الكاذبة عبر السلاسل.
حل مشكلة السيولة عبر السلاسل هو مجال معقد للغاية ويحتوي على العديد من الحلول. تنقسم حلول Layer2 إلى الحلول المدمجة في Ethereum التي تستخدم رسائل عبر السلاسل، وخاصة ERC-7683، بالإضافة إلى Layer2 مثل OP الذي يبني OP Stack لمشاركة Sequencer للحل. خارج سياق Layer2، تواجه جميع Layer1 أيضًا مشكلات في السيولة والحالة وتجربة المستخدم، وهناك حلول مخصصة تركز على التطبيقات المتعلقة بالسيولة، بالإضافة إلى الحلول الخارجية لشبكة Solver، وحتى هناك حلول تركز على الحسابات مثل NEAR، ولكنها تحتاج أيضًا إلى دور خارجي مثل Solver.
تعتبر السيولة عبر السلاسل، والحالة، وتجربة المستخدم المتقطعة من المشاكل التي تواجه صناعة blockchain بأكملها. إذا فكرنا في الأمر بشكل شامل، يجب أن نتعامل معه بطريقة أكثر تجريداً، مشابهة لتجريد السلاسل، وهذا يعد بمثابة الحقيقة الحقيقية.
شاهد النسخة الأصلية
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
تسجيلات الإعجاب 10
أعجبني
10
6
مشاركة
تعليق
0/400
PancakeFlippa
· منذ 11 س
خداع الناس لتحقيق الربح早晚要重组 看好后市
شاهد النسخة الأصليةرد0
CryptoPhoenix
· منذ 12 س
سأنتظر السوق الصاعدة حتى لو تعبت ولفت.
شاهد النسخة الأصليةرد0
Blockblind
· منذ 12 س
من سينقذ السيولة لمستثمر التجزئة
شاهد النسخة الأصليةرد0
FOMOSapien
· منذ 12 س
عبر السلاسل تطوير早就烂大街了
شاهد النسخة الأصليةرد0
GasFeeNightmare
· منذ 12 س
يجب أن نبدأ في حساب غاز مرة أخرى... خبراء المراجحة في منتصف الليل عبر السلاسل
شاهد النسخة الأصليةرد0
PaperHandsCriminal
· منذ 12 س
اللعنة لقد تم خداع الناس لتحقيق الربح مرة أخرى
( التفسير: يتماشى هذا التعليق تمامًا مع دور "أيادٍ ضعيفة"، حيث يشير بنبرة ساخرة إلى أنه تكبد خسائر مرة أخرى في تقلبات السوق. التعليق مختصر وعامّي، يحمل نبرة من الإحباط والسخرية الذاتية، مما يجعله متناسبًا للغاية مع أسلوب التعبير الحقيقي على المنصات الاجتماعية. )
تكامل السيولة في عصر طبقة 2: التحديات والفرص التي تواجه النظام البيئي متعدد السلاسل
دراسة مشكلة割 في السيولة في عصر طبقة 2
مع تحول إيثيريوم نحو حلول التوسع التي تركز على طبقة 2، بالإضافة إلى ظهور أدوات مثل RaaS، تطورت العديد من سلاسل الكتل العامة بسرعة. تأمل العديد من الكيانات في بناء سلاسلها الخاصة لتمثيل مصالح مختلفة والسعي لتحقيق تقييم أعلى. ومع ذلك، فإن ظهور العديد من سلاسل الكتل العامة جعل من الصعب على تطوير النظام البيئي مواكبة سرعة سلاسل الكتل العامة، مما أدى إلى انهيار العديد من المشاريع عند TGE.
بفضل OP Stack، أطلقت منصة تداول طبقة 2 الخاصة بها، بينما أصدرت منصة أخرى Ink؛ وبفضل تقنية ZK، أطلقت منصة XLayer؛ كما أصدرت Sony Soneium، وأطلقت LINE Kaia وغيرها. اليوم، تم تقليل عتبة التمويل والتكنولوجيا لبناء سلسلة بشكل كبير، حيث تبلغ تكلفة تشغيل سلسلة تعتمد على OP Stack حوالي 10,000 دولار شهريًا.
ستكون المستقبل بلا شك عصر التعايش بين الشبكات المتعددة. على الرغم من أن هذه الطبقات 2 قد تختار التوافق مع EVM لتحقيق التفاعل، إلا أنه نظرًا لوجود عدد كبير من التطبيقات التابعة للكيانات Web2 وراءها، سيكون من الصعب عليها بناء التطبيقات والوصول إلى توافق على نفس السلسلة.
تقدم البيئة متعددة السلاسل الحالية تحديًا جديدًا: السيولة وتشتت الحالة. نظرًا لأن وجود السلاسل المتعددة أمر حتمي، فإن قابلية التشغيل البيني هي مجال يجب استكشافه وحله. هناك حاليًا العديد من حلول السيولة، مثل تجريد السلاسل، والنية، والتنفيذ الواضح، والعبور الأصلي بين السلاسل، وتقسيم ZK، ولكن جوهرها الأساسي هو نفسه.
نستخدم هيكل Cake المعترف به على نطاق واسع في الصناعة لتقديم مكونات الفكرة الأساسية للربط بين الشبكات من الأعلى إلى الأسفل:
طبقة التطبيق (Application Layer)
هذه هي الطبقة التي يتفاعل معها المستخدمون مباشرة، وهي أيضًا أكثر الطبقات تجريدًا في حلول السيولة، لأنها تخفي بالكامل تفاصيل تحويل السيولة. في طبقة التطبيق، يتفاعل المستخدمون مع واجهة المستخدم الأمامية، وقد لا يفهمون آلية تحويل السيولة الأساسية.
طبقة الأذونات (Permission Layer)
تقع أسفل طبقة التطبيقات، حيث يقوم المستخدمون بالاتصال بالمحفظة إلى dApp وطلب الأسعار لتلبية نية التداول. هنا تشير "النية" إلى النتيجة النهائية المتوقعة من قبل المستخدم (أي المخرجات)، وليس مسار التنفيذ الفعلي للتداول.
إدارة الحسابات وطبقة التجريد (Key Management and Account Abstraction)
نظرًا لوجود بيئة متعددة السلاسل، هناك حاجة إلى نظام إدارة حسابات وتبسيط يتكيف مع سلاسل مختلفة للحفاظ على هيكل الحسابات الفريد لكل سلسلة. على سبيل المثال، نظام الحسابات القائم على الكائنات في SUI يختلف تمامًا عن EVM. One Balance هو مشروع ممثل في هذا المجال، حيث يبني نظام حسابات موثوق به، دون الحاجة إلى إنشاء توافق بين السلاسل، بل يكفي الالتزام الموثوق بين أنظمة الحسابات الحالية. يقوم حساب Near بتحقيق الإدارة البسيطة من خلال إنشاء محفظة حسابات متعددة السلاسل للمستخدمين، مما يحسن بشكل كبير تجربة المستخدم ويقلل من تفتت تجربة المستخدم. ومع ذلك، فإن السيولة تتكامل بشكل رئيسي مع سلاسل العامة الموجودة.
طبقة الحل (Solver Layer)
تتحمل هذه الطبقة مسؤولية استقبال وتنفيذ نوايا معاملات المستخدم، حيث تتنافس دور Solver هنا لتوفير تجربة مستخدم أفضل، بما في ذلك أوقات تنفيذ أسرع وسرعة تنفيذ أعلى. بناءً على ذلك، تم بناء مشاريع متنوعة مدفوعة بالنوايا على أساس نوايا المستخدم. من بين هذه النوايا، يمكن أن تحقق المشتقات مثل مكون Predicate نية المستخدم بموجب قواعد محددة.
طبقة التسوية (Settlement Layer)
هذه هي طبقة وسيطة تُستخدم لحل الطبقة لتحقيق نية المستخدم. تشمل المكونات الأساسية لحلول السيولة وتوزيع الحالة:
بالإضافة إلى ذلك، يجب أخذ السيولة بين السلاسل، النهائية (Finality)، وآلية إثبات طبقة 2 في الاعتبار، لضمان التشغيل الفعال للنظام المتعدد السلاسل.
حاليًا، هناك العديد من الحلول المتاحة في السوق لمعالجة السيولة المقطوعة، وبعد استعراض عدد كبير من الحلول، وجدنا أن الطرق الرئيسية هي هذه الطرق:
مركزية RaaS: مثل الحلول المتداولة مثل OP Stack، من خلال إضافة محددات ترتيب مشتركة وجسور عبر السلاسل لمساعدة في بناء سيولة مشتركة وحالة على OP Stack. يأمل هذا في معالجة السيولة وحالة التفريق في اتجاه أعلى. هناك تصميم أكثر تفصيلاً لمحدد ترتيب مشترك منفصل، وهذا الحل أكثر استهدافاً لطبقة 2، ولا يتمتع بالعمومية.
مركزية الحساب: بناء محفظة حسابات شاملة عبر سلسلة، من خلال تقنية تُعرف باسم "توقيع السلسلة" لدعم توقيع وتنفيذ المعاملات عبر بروتوكولات blockchain متعددة. المكون الأساسي هو شبكة MPC، التي تحل محل المستخدمين في توقيع المعاملات متعددة السلاسل. هذه الخطة، على الرغم من أنها يمكن أن تحل بشكل كبير مشكلة تجزئة تجربة المستخدم، إلا أنها تتطلب من المطورين تنفيذات خلفية معقدة، ولا تحل بشكل جوهري مشكلة السيولة والحالة المشتتة.
مركزية شبكة النوايا خارج السلسلة: أي ما يعادل شبكة Solver في مخطط هيكل كعكة "المقدمة" لدينا، حيث يقوم المستخدم بإرسال نوايا إلى شبكة Solver، ويتنافس هذا الدور على تقديم عروض، موفرًا أفضل وقت إتمام وسعر تداول، ويمكن أن تكون هذه الـ Solver عملاء ذكيين، أو CEX، أو صانعي السوق، أو حتى بروتوكولات متكاملة نفسها. على الرغم من أن النوايا يمكن أن تحقق عمليات عبر السلاسل ذات تعقيد عشوائي من الناحية النظرية، إلا أنه في التنفيذ، يتطلب الأمر وجود ما يكفي من Solver السيولة للمساعدة، وعندما تواجه بعض المتطلبات خارج السلسلة، توجد إمكانية لحدوث خداع من قبل Solver، وإذا تم إدخال أساليب مثل إثبات الاحتيال، فإن صعوبة تنفيذ شبكة Solver ستزداد، وكذلك ستزداد عتبة تشغيل Solver.
مركزية شبكة السيولة على السلسلة: هذا الاتجاه يركز بشكل خاص على تحسين مشاكل السيولة عبر السلاسل، لكنه لم يحل مشكلة تشتت الحالة على السلاسل الأخرى. جوهره هو بناء طبقة للسيولة، حيث يتم بناء التطبيقات على هذه الطبقة لمشاركة السيولة عبر السلسلة.
مركزية التطبيقات على السلسلة: تقوم هذه التطبيقات بإنشاء تطبيقات عالية السيولة من خلال دمج MM الكبير أو تطبيقات الطرف الثالث وما إلى ذلك. تتطلب هذه المشاريع إدارة عمليات معقدة عبر السلاسل، مما يتطلب مستوى عالٍ من المهارة من المطورين، وبالتالي فهي عرضة لحدوث هجمات القرصنة.
حل مشكلة السيولة هو موضوع مهم للغاية، حيث تمثل السيولة كل شيء في العالم المالي. إذا كان من الممكن بناء منصة متكاملة للسيولة، خاصةً من خلال دمج السيولة المتناثرة عبر السلسلة بأكملها، فسوف يكون لدينا إمكانيات كبيرة جداً، وقد نظرنا أيضاً في العديد من الحلول المختلفة.
في التصنيفين المذكورين أعلاه، يمكننا أن نرى وفقًا لهياكل الكعكة، أن Settlement Layer هو الحل الأكثر ذرية، وعلى هذه الحلول الذرية مثل التقنيات عبر السلاسل، والأوراكل، وحلول Pre-Confirmation، تم بناء طبقة أكثر تجريدًا، وهي Solver Layer وPermission Layer وApplication Layer. الحلول المختلفة التي قمنا بإدراجها أعلاه لبناء الحلول التجريدية أو السيولة في اتجاهات مختلفة تتماشى مع هذه المستويات المختلفة، ويمكن فهمها على أنها علاقة بين الموردين والمستخدمين. ومع ذلك، لا تزال هذه الحلول ليست حلولًا ذرية، حيث أن مشكلة فصل السيولة بأكملها قد أدت إلى ظهور العديد من المشكلات الفرعية المعقدة، وبالتالي، نشأت حلول متنوعة لمشكلة التشغيل المتداخل. ولكن في جوهرها، لا تزال تعتمد على هذه المكونات. في ما يلي، سنناقش بعض المشاريع التي تتعلق بمفاهيم السلاسل التجريدية النموذجية، لنرى كيف تحل كل منها مشكلة فصل السيولة من وجهة نظرها الخاصة.
بنت INFINIT خدمة RaaS في مجال DeFi، والتي يمكنها توفير المكونات اللازمة للبناء المباشر لبروتوكولات DeFi، مثل Oracle، نوع Pool، IRM، Asset، وغيرها، كما يمكنها توفير مكونات مثل التداول بالرافعة المالية واستراتيجية العائد التي يمكن تفعيلها على الفور. يعد هذا بمثابة طرف بناء التطبيقات الأخرى، لكن السيولة النهائية توضع في طبقة السيولة الخاصة بـ Infinit. ومع ذلك، لم تكشف بعد عن الآلية الأساسية لعملها.
بنيت Khalani ثلاثة مكونات أساسية، وهي طبقة توافق النوايا وValidity وطبقة التسوية العامة. يمكن للتطبيقات الخارجية أو طبقة النوايا نشر نوايا إلى Khalani، ثم تستطيع طبقة توافق النوايا في Khalani تحويل النوايا الخارجية إلى تنسيق يمكن لبروتوكول Solver التعرف عليه، حيث أن التنسيق المستخدم هو لغة Validity. تتولى عقد Khalani مسؤولية تقديم النتيجة النهائية إلى طبقة التسوية العامة من خلال جسر عبر السلاسل وتقنيات التسوية السريعة.
Liquorice هو تطبيق لامركزي يتيح اكتشاف الأسعار القائم على المزاد وحمامات السيولة أحادية الجانب. المهمة الرئيسية لـ Liquorice هي توفير أدوات إدارة المخزون الفعالة للشركات التجارية المحترفة، والتواصل بسهولة مع بروتوكولات DeFi الأساسية عند تسوية المعاملات باستخدام نية الاستخدام. في الوقت نفسه، أنشأت Liquorice سوقًا للإقراض لتداولات الإقراض الخاصة بها. يركز هذا التطبيق بشكل أكبر على التجارة نفسها.
Xion هو مبني على بروتوكول توافق Comet BFT. التواصل عبر السلاسل المتبنى يعتمد على Cosmos IBC، لذا فهو أكثر طبيعية وأمانًا من جسور السلاسل الأخرى.
=nil; قدمت Foundation حل zkSharding، وهو حل يستخدم تقنية ZK لتوسيع شبكة الإيثريوم الرئيسية أفقياً، وتنفيذ معالجة المعاملات بالتوازي مع تقسيمات البيانات وتوليد ZKP، بينما يقوم الشريحة الرئيسية بالتحقق من البيانات، والتواصل مع الإيثريوم ومزامنة حالة الشبكة بين جميع المدققين. كما تدير الشريحة الرئيسية توزيع المدققين والحسابات في الشريحة التنفيذية. بروتوكول الإجماع المستخدم من قبل لجنة التحقق هو أيضاً Hotstuff، وهو شائع جداً في المشاريع الحديثة للتنفيذ المتوازي. =nil; لقد تم تضمين الاتصال عبر الشرائح في بروتوكول L2 منذ البداية.
يعمل Ethereum أيضًا على حل مشكلة السيولة عبر السلاسل، حيث تدعم بعض منصات التداول الرئيسية أولاً معيار ERC7683، والذي يعتمد أيضًا على طريقة عبر السلاسل القائمة على Intent. الهدف الأساسي هو إنشاء معيار موحد للعمليات عبر السلاسل بين L2 والجانبية، وتوحيد أوامر وواجهات التسوية، لتحقيق تنفيذ سلس عبر السلاسل، والجوهر الرئيسي هو أن Filler يمكن أن يُطلق عليه أيضًا دور Solver في تجريد السلسلة.
تقوم OP Stack بتصميم حل شامل متعدد الطبقات 2، لحل مشاكل نقل المعلومات واللامركزية للمتسلسلين مرة واحدة. عند استخدامك لهندسة OP Stack، سيتم نشر العقود عبر السلاسل تلقائيًا، كما سيكون هناك مشرف للتحدي لتجنب نقل المعلومات الكاذبة عبر السلاسل.
حل مشكلة السيولة عبر السلاسل هو مجال معقد للغاية ويحتوي على العديد من الحلول. تنقسم حلول Layer2 إلى الحلول المدمجة في Ethereum التي تستخدم رسائل عبر السلاسل، وخاصة ERC-7683، بالإضافة إلى Layer2 مثل OP الذي يبني OP Stack لمشاركة Sequencer للحل. خارج سياق Layer2، تواجه جميع Layer1 أيضًا مشكلات في السيولة والحالة وتجربة المستخدم، وهناك حلول مخصصة تركز على التطبيقات المتعلقة بالسيولة، بالإضافة إلى الحلول الخارجية لشبكة Solver، وحتى هناك حلول تركز على الحسابات مثل NEAR، ولكنها تحتاج أيضًا إلى دور خارجي مثل Solver.
تعتبر السيولة عبر السلاسل، والحالة، وتجربة المستخدم المتقطعة من المشاكل التي تواجه صناعة blockchain بأكملها. إذا فكرنا في الأمر بشكل شامل، يجب أن نتعامل معه بطريقة أكثر تجريداً، مشابهة لتجريد السلاسل، وهذا يعد بمثابة الحقيقة الحقيقية.
( التفسير: يتماشى هذا التعليق تمامًا مع دور "أيادٍ ضعيفة"، حيث يشير بنبرة ساخرة إلى أنه تكبد خسائر مرة أخرى في تقلبات السوق. التعليق مختصر وعامّي، يحمل نبرة من الإحباط والسخرية الذاتية، مما يجعله متناسبًا للغاية مع أسلوب التعبير الحقيقي على المنصات الاجتماعية. )