دراسة مشكلة割 في السيولة في عصر طبقة 2

مع تحول الإيثريوم نحو حلول التوسع المستندة إلى طبقة 2 وظهور أدوات مثل RaaS، تطورت العديد من سلاسل الكتل العامة بسرعة. تأمل العديد من الكيانات في بناء سلاسلها الخاصة لتمثيل مصالح مختلفة والسعي للحصول على تقييمات أعلى. ومع ذلك، فإن الزيادة الكبيرة في سلاسل الكتل العامة جعلت من الصعب على تطوير النظام البيئي مواكبة سرعة سلاسل الكتل العامة، مما أدى إلى انهيار العديد من المشاريع عند TGE.

بمساعدة OP Stack، أطلق أحد منصات التداول طبقة 2 الخاصة به، وأصدرت منصة تداول أخرى Ink؛ بمساعدة تقنية ZK، أطلق أحد منصات التداول XLayer؛ أصدرت Sony Soneium، وأطلقت LINE Kaia، وغيرها. اليوم، تم تقليل تكلفة وعتبة التكنولوجيا لبناء سلسلة بشكل كبير، حيث تبلغ تكلفة تشغيل سلسلة تعتمد على OP Stack حوالي 10,000 دولار شهريًا.

سيكون المستقبل بلا شك عصر التعايش المتعدد السلاسل. على الرغم من أن هذه الطبقة 2 قد تختار توافق EVM لتحقيق التواصل، إلا أنه بسبب الكيانات Web2 التي تقف وراءها والتي لديها عدد كبير من التطبيقات السفلية، سيكون من الصعب عليها بناء التطبيقات والوصول إلى توافق في نفس السلسلة.

تواجه البيئة المتعددة السلاسل الحالية تحدياً جديداً: السيولة وتشتت الحالة. نظراً لأن وجود السلاسل المتعددة أمر حتمي، فإن التفاعل بين السلاسل هو مجال يجب استكشافه وحله. هناك حالياً العديد من حلول السيولة، مثل تجريد السلسلة، النوايا، تنفيذ التسوية، CrossChain الأصلي، ZKSharding، ولكن جوهرها الأساسي هو نفسه.

نستخدم هيكل Cake المعترف به في الصناعة لتقديم مكونات الهيكل الأساسية للتجريد عبر السلسلة من الأعلى إلى الأسفل:

طبقة التطبيق (Application Layer)

هذه هي الطبقة التي يتفاعل المستخدمون معها مباشرة، وهي أيضًا أكثر الطبقات تجريدًا في حلول السيولة، لأنها تخفي تمامًا تفاصيل تحويل السيولة. في طبقة التطبيق، يتفاعل المستخدمون مع واجهة المستخدم الأمامية، وقد لا يكونون على دراية بآلية تحويل السيولة الأساسية.

طبقة الأذونات (Permission Layer)

تقع تحت طبقة التطبيقات، حيث يربط المستخدمون محفظتهم بـ dApp ويطلبون عرض الأسعار لتلبية نية التداول. تشير "النية" هنا إلى النتيجة النهائية المتوقعة للتداول (أي الناتج)، وليس إلى مسار التنفيذ المحدد للتداول.

إدارة الحسابات وطبقة التجريد (إدارة المفاتيح وتجريد الحساب)

نظرًا لوجود بيئة متعددة السلاسل، هناك حاجة إلى نظام إدارة حسابات وتجريد يتكيف مع سلاسل مختلفة للحفاظ على هيكل الحسابات الفريد لكل سلسلة. على سبيل المثال، نظام الحسابات القائم على الكائنات في SUI مختلف تمامًا عن EVM. يُعتبر One Balance مشروعًا تمثيليًا في هذا المجال، حيث يبني نظام حسابات موثوق دون الحاجة إلى إنشاء إجماع بين السلاسل، بل يعتمد فقط على الالتزامات الموثوقة بين أنظمة الحسابات الموجودة. يحقق Near Account الإدارة المجردة من خلال إنشاء محفظة حسابات متعددة السلاسل للمستخدمين، مما يحسن بشكل كبير تجربة المستخدم ويقلل من تجزئة UX. ومع ذلك، فإن السيولة تتكامل بشكل رئيسي مع السلاسل العامة الموجودة.

طبقة الحل (Solver Layer)

تتحمل هذه الطبقة مسؤولية استلام وتنفيذ نوايا تداول المستخدمين، حيث يتنافس دور Solver هنا لتقديم تجربة مستخدم أفضل، بما في ذلك أوقات تنفيذ أسرع وسرعة تنفيذ أعلى. بناءً على ذلك، تم بناء مجموعة متنوعة من الحلول المدفوعة بالنوايا. ومن المشتقات الخاصة بهذه النوايا مكون Predicate، الذي يمكن أن يحقق نوايا المستخدمين بموجب قواعد معينة.

طبقة التسوية (Settlement Layer)

هذا هو طبقة الوسيط المستخدمة لتحقيق نية المستخدم. تشمل المكونات الأساسية لحلول السيولة والحالة الموزعة:

• أوراكل (Oracle): يُستخدم للحصول على معلومات الحالة من سلاسل أخرى.
• الجسور (Bridges): مسؤولة عن نقل المعلومات والسيولة عبر السلاسل.
• تأكيد مسبق للخطة (Pre-Confirmation): تقليل وقت التأكيد عبر السلسلة.
• توفر البيانات (DA): توفير إمكانية الوصول إلى البيانات.

بالإضافة إلى ذلك، يجب أخذ السيولة بين السلاسل، التأكيد النهائي (Finality)، وآلية إثبات طبقة 2 في الاعتبار لضمان التشغيل الفعال لنظام متعدد السلاسل بأكمله.

الحلول

حاليًا، توجد العديد من الحلول لمعالجة السيولة المخترقة في السوق، وبعد الاطلاع على العديد من الحلول، وجدنا أن هناك طرقًا رئيسية معينة:

1. مركزًا حول RaaS: مثل حلول Rollup مثل OP Stack، من خلال إضافة مُرتب مشترك محدد وجسور عبر السلاسل للمساعدة في بناء Rollup على OP Stack لمشاركة السيولة والحالة. نأمل أن يكون ذلك قادرًا على حل مشكلة تشتت السيولة والحالة في اتجاه أعلى. هناك تصميم أكثر تفصيلًا وهو تصميم مُرتب مشترك منفصل، وهذه الحلول تستهدف بشكل أكبر طبقة 2 ولا تتمتع بالعمومية.

2. مركزية الحسابات: بناء محفظة حسابات شاملة عبر السلسلة، تدعم توقيع وتنفيذ المعاملات عبر بروتوكولات بلوكتشين متعددة من خلال تقنية تسمى "التوقيع السلسلي". المكون الرئيسي هو شبكة MPC، التي تحل محل المستخدمين في توقيع المعاملات متعددة السلاسل. على الرغم من أن هذه الخطة يمكن أن تحل بشكل كبير مشكلة تجزئة تجربة المستخدم، إلا أنها تتطلب من المطورين تنفيذات خلفية معقدة، ولا تحل بشكل جوهري مشكلة السيولة وتوزيع الحالة.

3. مركزية شبكة نوايا خارج السلسلة: الجوهر هو أن المستخدمين يرسلون نوايا إلى شبكة Solver، حيث يتنافس هذا الدور في تقديم العطاءات لتحقيق أفضل وقت إنجاز وسعر تداول، ويمكن أن تكون هذه الـ Solver عبارة عن وكيل AI، أو CEX، أو صانع سوق، أو حتى بروتوكول متكامل بنفسه. على الرغم من أن النوايا يمكن أن تحقق في النظرية عمليات عبر السلسلة ذات صعوبة معقدة، إلا أن تنفيذها يتطلب وجود Solver ذو سيولة كافية للمساعدة، وعندما تواجه بعض الاحتياجات خارج السلسلة، فإن هناك احتمال للتلاعب من قبل Solver، وإذا تم إدخال أساليب مثل إثبات الاحتيال، ستصبح صعوبة تنفيذ شبكة Solver أعلى، كما سيرتفع عتبة تشغيل Solver.

4. مركزية شبكة السيولة على السلسلة: هذا الاتجاه مخصص لتحسين مشاكل سيولة عبر السلاسل، ولكنه لم يحل مشكلة تشتت الحالة على السلاسل الأخرى. جوهره هو بناء طبقة سيولة، حيث يتم بناء التطبيقات على هذه الطبقة لمشاركة السيولة عبر السلسلة كاملة.

5. موجهة نحو التطبيقات على السلسلة: تقوم هذه التطبيقات ببناء تطبيقات ذات سيولة عالية من خلال دمج MM الكبير أو تطبيقات الطرف الثالث وما إلى ذلك. تتطلب هذه المشاريع إدارة عمليات معقدة عبر السلاسل، مما يضع متطلبات عالية على المطورين، وبالتالي فهي عرضة للغاية لوقوع حوادث الاختراق.

حل مشكلة السيولة هو موضوع مهم جدًا، حيث تمثل السيولة كل شيء في العالم المالي. إذا كان بإمكاننا بناء منصة متكاملة للسيولة، خاصةً دمج السيولة المتفرقة عبر السلسلة بالكامل، فسوف تمتلك إمكانيات كبيرة جدًا، وقد رأينا أيضًا العديد من الحلول المختلفة.

في التصنيفين المذكورين أعلاه، يمكننا أن نرى أن Settlement Layer هو الحل الأكثر ذرية بناءً على هيكل الكعكة. فوق هذه الحلول الذرية مثل الحلول عبر السلاسل، والأوراكل، وحلول Pre-Confirmation، توجد طبقة أكثر تجريدًا، وهي Solver Layer وPermission Layer وApplication Layer. الحلول المختلفة التي قمنا بإدراجها أعلاه لبناء حلول تجريدية أو السيولة تتوافق مع هذه المستويات المختلفة، ويمكن فهمها على أنها علاقة بين الجانبين الأعلى والأسفل. لكن هذه الحلول لا تزال ليست حلولاً ذرية، حيث أن مشكلة انفصال السيولة بأكملها قد أدت إلى ظهور العديد من المشاكل المعقدة. وبالتالي، ظهرت مجموعة متنوعة من الحلول لمشكلة التفاعل بين الأنظمة. ومع ذلك، لا يزال الأمر يعتمد في جوهره على هذه المكونات. بعد ذلك، سنناقش بعض المشاريع النموذجية لمفاهيم تجريد السلاسل، لنرى كيف تحل كل منها مشكلة انفصال السيولة من وجهة نظرها الخاصة.

إنفينيت

INFINIT بنيت خدمة RaaS في مجال DeFi، والتي يمكن أن توفر المكونات اللازمة للبروتوكولات DeFi مثل Oracle، نوع الحوض، IRM، الأصول، وغيرها، كما يمكن أن تقدم مكونات مثل التداول بالرافعة المالية واستراتيجيات العائد التي يمكن تفعيلها على الفور. هذا يعادل أطراف بناء التطبيقات الأخرى، ولكن السيولة النهائية توضع في طبقة السيولة الخاصة بـ Infinit. لكن، حتى الآن لم تكشف عن آلية العمل الأساسية. حتى الآن، حصلت INFINIT على تمويل أولي بقيمة 6 ملايين دولار من بعض المؤسسات الاستثمارية.

شبكة خالاني

قام Khalani ببناء ثلاثة مكونات أساسية، وهي طبقة توافق النية، وال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 و مطور Layer2، حيث يتمتع الفريق بأسس تقنية قوية في ZK. وقد قدموا حل zkSharding، وهو حل يستخدم تقنية ZK لتوسيع شبكة إيثيريوم الرئيسية بشكل أفقي، وينفذ معالجة المعاملات بالتوازي من خلال الشظايا ويولد ZKP، بينما تتحقق الشظية الرئيسية من البيانات، وتتواصل مع إيثيريوم، وتزامن حالة الشبكة بين جميع المدققين. كما تدير الشظية الرئيسية توزيع المدققين والحسابات في الشظايا التنفيذية. بروتوكول الإجماع المستخدم من قبل لجنة المدققين هو أيضاً Hotstuff، وهو شائع جداً في المشاريع الحديثة للتنفيذ المتوازي. =nil; لقد تم تضمين الاتصال عبر الشظايا في البروتوكول منذ البداية. يتم التحقق من الرسائل عبر الشظايا من قبل لجنة المدققين لكل شظية كمعاملات.

فكرتها الأساسية هي بناء هيكلية اتصالات عبر الشظايا داخلية مشابهة لـ IBC من خلال هيكلية Layer2 المجزأة، مما يمكنها من حل مشكلات السيولة وتشتت الحالة. ومع ذلك، فإن فكرتها الأساسية ليست معقولة، لأن مشكلة تشتت السيولة هي مشكلة متعددة السلاسل، بينما ما يتم بناؤه هو Layer2 واحد، مما يعني أنه لحل هذه المشكلة، يجب أن تصبح جميع السلاسل شظية واحدة من ZK-sharding، وهذا صعب التحقيق.

ERC-7683

إيثريوم تعمل أيضًا على معالجة مشكلة السيولة عبر السلاسل، حيث أن بعض المشاريع الشهيرة قد دعمت علنًا معيار ERC7683، والذي يعتمد أيضًا على طريقة عبر السلاسل المعتمدة على النية. الهدف الأساسي هو إنشاء معيار عام لعمليات عبر L2 والسلاسل الجانبية، وتوحيد واجهات الطلبات والتسويات لتحقيق تنفيذ سلس عبر السلاسل، حيث أن جوهر ذلك هو Filler، والذي يمكن أن يُعتبر دور Solver في تجريد السلسلة للدفع بدلاً من ذلك. تم بناء هذا الاقتراح من قبل بعض المشاريع الشهيرة، وهو قيد المراجعة حاليًا من قبل مجموعة Cake.

مجموعة OP

تعتبر OP Stack و ERC-7683 و zkSharding حلولاً داخلية لـ Ethereum لمعالجة تجزئة السيولة بين Layer 2، حيث يتم تناولها على مستويات الهيكل والتوافق والتطبيق. تقوم OP Stack بتصميم حل شامل متعدد Layer 2 لحل مشكلات نقل المعلومات و لامركزية Sequencer دفعة واحدة، وعند استخدامك لهندسة OP Stack، سيتم نشر عقود عبر السلاسل تلقائياً، وسيكون هناك مشرف للتحدي لتجنب نقل معلومات عبر السلاسل وهمية. حالياً، هناك العديد من منصات التداول والمشاريع الشهيرة التي تستخدم هندسة OP Stack.

من أبرزها Unichain. تعتمد Unichain بشكل رئيسي على التعاون مع