مع تحول الإيثريوم نحو استراتيجية توسيع تركز على طبقة 2، وظهور أدوات مثل RaaS، تتطور العديد من سلاسل الكتل العامة بسرعة. يتطلع العديد من الكيانات إلى بناء سلاسلهم الخاصة لتمثيل مصالح مختلفة والسعي لتحقيق تقييم أعلى. ومع ذلك، فإن ظهور العديد من سلاسل الكتل العامة يجعل من الصعب على تطوير النظام البيئي أن يواكب وتيرة سلاسل الكتل العامة، مما يؤدي إلى فشل العديد من المشاريع عند إصدارها.
بمساعدة OP Stack، أطلقت إحدى منصات التداول طبقة 2 الخاصة بها؛ وبمساعدة تقنية ZK، أطلقت منصة تداول أخرى طبقتها الخاصة؛ أصدرت شركة ما سلسلتها الخاصة، وأطلقت شركة برمجيات اتصالات سلسلتها الخاصة، وما إلى ذلك. اليوم، لقد انخفضت متطلبات التمويل والتكنولوجيا لبناء سلسلة بشكل كبير، حيث تبلغ تكلفة تشغيل سلسلة قائمة على OP Stack حوالي 10,000 دولار شهريًا.
سيكون المستقبل بلا شك عصرًا من التعايش بين سلاسل متعددة. على الرغم من أن هذه الطبقات 2 قد تختار التوافق مع EVM لتحقيق التواصل، إلا أن الكيانات الخلفية لها من Web2 لديها عدد كبير من التطبيقات السفلية، مما يجعل من الصعب بناء التطبيقات والتوصل إلى توافق في الآراء على نفس السلسلة.
تقدم البيئة متعددة السلاسل الحالية تحديًا جديدًا: السيولة وتشتت الحالة. نظرًا لأن وجود السلاسل المتعددة أمر حتمي، فإن التشغيل البيني هو مجال يجب استكشافه وحلّه. هناك حاليًا العديد من حلول السيولة، مثل تجريد السلسلة، النية، تنفيذ التسوية، CrossChain الأصلي، ZKSharding، ولكن جوهرها الأساسي هو نفسه.
نستخدم هيكل Cake المعترف به على نطاق واسع في الصناعة لتقديم مكونات جوهرية للاستخراج عبر السلاسل من الأعلى إلى الأسفل:
طبقة التطبيق(Application Layer)
هذه هي الطبقة التي يتفاعل معها المستخدمون مباشرة، وهي أيضًا أكثر الطبقات تجريدًا في حلول السيولة، لأنها تخفي تمامًا تفاصيل تحويل السيولة. في طبقة التطبيق، يتفاعل المستخدمون مع واجهة المستخدم الأمامية، وقد لا يدركون آليات تحويل السيولة الأساسية.
** طبقة الأذونات (Permission Layer) **
تقع تحت طبقة التطبيق، يقوم المستخدمون بتوصيل المحفظة إلى dApp وطلب الأسعار لتلبية نية التداول. هنا "النية" تشير إلى النتيجة النهائية للتداول التي يتوقعها المستخدم ( أي الإخراج )، وليس مسار التنفيذ المحدد للتداول.
إدارة الحسابات وطبقة التجريد(إدارة المفاتيح وحساب التجريد)
نظرًا لوجود بيئة متعددة السلاسل ، هناك حاجة إلى نظام إدارة حسابات وتجريد يتكيف مع سلاسل مختلفة للحفاظ على الهيكل الفريد للحسابات على كل سلسلة. على سبيل المثال ، نظام الحسابات المركزي القائم على الكائنات في SUI يختلف تمامًا عن EVM. قامت بعض المشاريع ببناء نظام حسابات موثوق به ، دون الحاجة إلى إنشاء توافق بين السلاسل ، بل فقط من خلال الالتزامات الموثوقة بين أنظمة الحسابات الحالية. كما أن هناك مشاريع تحقق إدارة مجردة من خلال إنشاء محافظ حسابات متعددة السلاسل للمستخدمين ، مما يحسن بشكل كبير من تجربة المستخدم ويقلل من تجزئة تجربة المستخدم. ومع ذلك ، فإن السيولة تتكامل بشكل رئيسي مع السلاسل العامة الموجودة.
حل الطبقة(Solver Layer)
تتحمل هذه الطبقة مسؤولية استلام وتنفيذ نوايا المستخدمين في التداول، حيث تتنافس وظيفة Solver هنا لتقديم تجربة مستخدم أفضل، بما في ذلك أوقات تنفيذ أسرع وسرعة تنفيذ أعلى. بناءً على ذلك، قامت المشاريع القائمة على النوايا بتطوير مجموعة متنوعة من الحلول المدفوعة بالنوايا. تشمل مشتقات هذه النوايا مكونات Predicate، التي يمكنها تنفيذ نوايا المستخدمين وفقًا لقواعد معينة.
طبقة التسوية(Settlement Layer)
هذا هو طبقة وسيطة تستخدم لحل الطلبات لتحقيق نية المستخدم. تشمل المكونات الأساسية للحلول المتعلقة بالسيولة وحالة التوزيع:
الأوركل ( Oracle ): للحصول على معلومات حالة من سلاسل أخرى.
جسور跨链(Bridges): مسؤولة عن نقل المعلومات والسيولة عبر السلاسل.
تأكيد مسبق للخطة (Pre-Confirmation): تقصير وقت تأكيد سلسلة الكتل.
توفر البيانات ( DA ): توفر إمكانية الوصول إلى البيانات.
بالإضافة إلى ذلك، يجب مراعاة السيولة بين السلاسل، والتأكيد النهائي (Finality)، وآلية إثبات طبقة 2 وغيرها من العوامل، لضمان التشغيل الفعال لنظام متعدد السلاسل.
حاليًا، هناك العديد من الحلول المتاحة في السوق لمعالجة خداع الناس لتحقيق الربح، وبعد مراجعة العديد من الحلول، وجدنا أن هناك عدة طرق رئيسية:
مركزية RaaS: مشابهة لحلول Rollup مثل OP Stack، من خلال إضافة مُرتب مشترك محدد وجسر عبر السلسلة للمساعدة في بناء Rollup على OP Stack ومشاركة السيولة والحالة. يأمل هذا في حل تشتت السيولة والحالة في اتجاه أعلى. هناك تصميم أكثر تفصيلاً لمُرتب مشترك منفصل، حيث أن هذه الخطة تستهدف بشكل أكبر طبقة 2، ولا تتمتع بالعمومية.
مركزية الحساب: بناء محفظة حسابات شاملة على السلسلة، تدعم توقيع وتنفيذ المعاملات عبر بروتوكولات متعددة من خلال تقنية تُعرف بـ "توقيع السلسلة". المكون الأساسي هو شبكة MPC، التي تتولى توقيع معاملات متعددة السلاسل بدلاً من المستخدمين. على الرغم من أن هذه الخطة يمكن أن تحل بشكل كبير مشكلة تفتيت تجربة المستخدم، إلا أنها تتطلب من المطورين تنفيذات خلفية معقدة، ولا تحل جوهريًا مشكلة السيولة وتوزيع الحالة.
مركزية شبكة نوايا خارج السلسلة: وهي شبكة Solver في مخطط هيكل "المقدمة" لدينا، حيث يقوم المستخدم بإرسال النية إلى شبكة Solver، ويتنافس هذا الدور على تقديم العروض، مقدماً أفضل وقت إنجاز وسعر تداول، يمكن أن تكون هذه الـ Solvers وكيل AI، أو CEX، أو صانع سوق، أو حتى البروتوكول المدمج نفسه. على الرغم من أن النية يمكن أن تحقق عملياً عمليات عبر السلسلة بمعقدات صعبة، إلا أنه يتطلب وجود Solvers سيولة كافية للمساعدة في التنفيذ، وعند مواجهة بعض الطلبات خارج السلسلة، قد يوجد احتمال لخداع الناس لتحقيق الربح من قبل الـ Solvers، وإذا تم إدخال وسائل مثل إثبات الاحتيال، ستصبح صعوبة تنفيذ شبكة Solver أعلى، كما ستزداد عتبة تشغيل الـ Solvers.
مركزية شبكة السيولة على السلسلة: هذا الاتجاه يركز على تحسين مشكلة السيولة عبر السلاسل، لكنه لم يحل المشاكل الأخرى المتعلقة بتوزيع الحالة على السلسلة. جوهره هو بناء طبقة سيولة، يتم بناء التطبيقات على هذه الطبقة، لمشاركة السيولة عبر السلسلة بأكملها.
مركزية التطبيقات على السلسلة: هذه التطبيقات تبني تطبيقات عالية السيولة من خلال دمج MM الكبير، أو تطبيقات الطرف الثالث وغيرها. تتطلب هذه المشاريع إدارة عمليات معقدة عبر السلاسل، مما يضع متطلبات عالية على المطورين، وبالتالي فإنها عرضة بسهولة لحدوث هجمات قرصنة.
حل مشكلة السيولة هو موضوع مهم جداً، حيث تمثل السيولة كل شيء في العالم المالي، إذا استطعت بناء منصة متكاملة للسيولة، وخاصة دمج السيولة المتفرقة من جميع السلاسل معاً، فسوف تمتلك إمكانيات كبيرة، وقد رأينا العديد من الحلول المختلفة.
في التصنيفين أعلاه، يمكننا أن نرى أن وفقًا لهياكل الكعكة، فإن Settlement Layer هو الحل الأكثر ذرية، وفوق هذه الحلول الذرية مثل عبر السلاسل، وأجهزة التنبؤ، وحلول Pre-Confirmation، يتم بناء طبقة أكثر تجريدًا، وهي Solver Layer وPermission Layer وApplication Layer. يمكن فهم المستويات المختلفة التي قمنا بإدراجها أعلاه، والتي تبني حلولًا تجريدية أو حلول السيولة في اتجاهات مختلفة، على أنها علاقة بين المصب والمصب. ولكن هذه الحلول لا تزال ليست حلولًا ذرية، حيث أن مشكلة الانقسام في السيولة قد أدت إلى ظهور العديد من المشكلات الفرعية المعقدة، وبالتالي نشأت حلول متنوعة لمشكلة التشغيل البيني. ولكن في الجوهر، لا يزال يعتمد على هذه المكونات.
حل مشكلة السيولة عبر السلاسل هو مجال معقد للغاية وله العديد من الحلول، مثل حلول الطبقة 2 التي تتنوع بين الحلول التي تعتمد على الرسائل عبر السلاسل، وخاصة ERC-7683، وحل OP Stack المبني على الطبقة 2 لمشاركة Sequencer. بعيدًا عن سياق الطبقة 2، تواجه جميع الطبقات 1 أيضًا مشكلات تتعلق بالسيولة والحالة وتجربة المستخدم، هناك حلول مخصصة تركز على التطبيقات المتعلقة بالسيولة، وكذلك حلول خارج السلسلة عبر شبكة Solver، بل وهناك أيضًا حلول تركز على الحسابات، ولكنها تحتاج أيضًا إلى أن تستند إلى دور Solver الخارجي.
نحن نعتقد أن انقسام السيولة عبر السلاسل، والحالة، وتجربة المستخدم هو مشكلة في صناعة blockchain بأكملها، وإذا فكرنا في الأمر بشكل شامل، نحتاج إلى القيام بذلك بطريقة أكثر تجريدًا، تشبه التجريد من السلاسل، وهذا بمثابة المدخل الحقيقي لـ Web3، حيث يحل الانقسام في تجربة المستخدم، بينما يتم دمج السيولة والحالة في أماكن لا يستطيع المستخدمون إدراكها. كيفية الدمج بالتحديد، ينقسم أيضًا إلى استخدام شبكة Solver خارج السلسلة وتسهيلات الجسور عبر السلاسل ذات الطبيعة الذرية، وكل ذلك يستحق البحث. بشكل عام، سيكون المستقبل متعدد السلاسل، وحل مشكلة تشتت السيولة هو مسألة يجب أن تواجهها الصناعة حتمًا، بينما يوجد مجال واسع للنمو في دمج السيولة عبر السلاسل، مما قد يؤدي إلى بناء مدخل جديد للإنترنت في عصر Web3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 17
أعجبني
17
3
إعادة النشر
مشاركة
تعليق
0/400
FromMinerToFarmer
· 07-25 18:33
خداع الناس لتحقيق الربح هو必然
شاهد النسخة الأصليةرد0
StakeWhisperer
· 07-23 11:21
إذا كانت العملات الرقمية كثيرة والنقود قليلة، فما الفائدة؟
تحديات عصر طبقة 2: استكشاف انقسام السيولة وحلولها في بيئة متعددة السلاسل
دراسة مشكلة割 في السيولة في عصر طبقة 2
مع تحول الإيثريوم نحو استراتيجية توسيع تركز على طبقة 2، وظهور أدوات مثل RaaS، تتطور العديد من سلاسل الكتل العامة بسرعة. يتطلع العديد من الكيانات إلى بناء سلاسلهم الخاصة لتمثيل مصالح مختلفة والسعي لتحقيق تقييم أعلى. ومع ذلك، فإن ظهور العديد من سلاسل الكتل العامة يجعل من الصعب على تطوير النظام البيئي أن يواكب وتيرة سلاسل الكتل العامة، مما يؤدي إلى فشل العديد من المشاريع عند إصدارها.
بمساعدة OP Stack، أطلقت إحدى منصات التداول طبقة 2 الخاصة بها؛ وبمساعدة تقنية ZK، أطلقت منصة تداول أخرى طبقتها الخاصة؛ أصدرت شركة ما سلسلتها الخاصة، وأطلقت شركة برمجيات اتصالات سلسلتها الخاصة، وما إلى ذلك. اليوم، لقد انخفضت متطلبات التمويل والتكنولوجيا لبناء سلسلة بشكل كبير، حيث تبلغ تكلفة تشغيل سلسلة قائمة على OP Stack حوالي 10,000 دولار شهريًا.
سيكون المستقبل بلا شك عصرًا من التعايش بين سلاسل متعددة. على الرغم من أن هذه الطبقات 2 قد تختار التوافق مع EVM لتحقيق التواصل، إلا أن الكيانات الخلفية لها من Web2 لديها عدد كبير من التطبيقات السفلية، مما يجعل من الصعب بناء التطبيقات والتوصل إلى توافق في الآراء على نفس السلسلة.
تقدم البيئة متعددة السلاسل الحالية تحديًا جديدًا: السيولة وتشتت الحالة. نظرًا لأن وجود السلاسل المتعددة أمر حتمي، فإن التشغيل البيني هو مجال يجب استكشافه وحلّه. هناك حاليًا العديد من حلول السيولة، مثل تجريد السلسلة، النية، تنفيذ التسوية، CrossChain الأصلي، ZKSharding، ولكن جوهرها الأساسي هو نفسه.
نستخدم هيكل Cake المعترف به على نطاق واسع في الصناعة لتقديم مكونات جوهرية للاستخراج عبر السلاسل من الأعلى إلى الأسفل:
طبقة التطبيق(Application Layer)
هذه هي الطبقة التي يتفاعل معها المستخدمون مباشرة، وهي أيضًا أكثر الطبقات تجريدًا في حلول السيولة، لأنها تخفي تمامًا تفاصيل تحويل السيولة. في طبقة التطبيق، يتفاعل المستخدمون مع واجهة المستخدم الأمامية، وقد لا يدركون آليات تحويل السيولة الأساسية.
** طبقة الأذونات (Permission Layer) **
تقع تحت طبقة التطبيق، يقوم المستخدمون بتوصيل المحفظة إلى dApp وطلب الأسعار لتلبية نية التداول. هنا "النية" تشير إلى النتيجة النهائية للتداول التي يتوقعها المستخدم ( أي الإخراج )، وليس مسار التنفيذ المحدد للتداول.
إدارة الحسابات وطبقة التجريد(إدارة المفاتيح وحساب التجريد)
نظرًا لوجود بيئة متعددة السلاسل ، هناك حاجة إلى نظام إدارة حسابات وتجريد يتكيف مع سلاسل مختلفة للحفاظ على الهيكل الفريد للحسابات على كل سلسلة. على سبيل المثال ، نظام الحسابات المركزي القائم على الكائنات في SUI يختلف تمامًا عن EVM. قامت بعض المشاريع ببناء نظام حسابات موثوق به ، دون الحاجة إلى إنشاء توافق بين السلاسل ، بل فقط من خلال الالتزامات الموثوقة بين أنظمة الحسابات الحالية. كما أن هناك مشاريع تحقق إدارة مجردة من خلال إنشاء محافظ حسابات متعددة السلاسل للمستخدمين ، مما يحسن بشكل كبير من تجربة المستخدم ويقلل من تجزئة تجربة المستخدم. ومع ذلك ، فإن السيولة تتكامل بشكل رئيسي مع السلاسل العامة الموجودة.
حل الطبقة(Solver Layer)
تتحمل هذه الطبقة مسؤولية استلام وتنفيذ نوايا المستخدمين في التداول، حيث تتنافس وظيفة Solver هنا لتقديم تجربة مستخدم أفضل، بما في ذلك أوقات تنفيذ أسرع وسرعة تنفيذ أعلى. بناءً على ذلك، قامت المشاريع القائمة على النوايا بتطوير مجموعة متنوعة من الحلول المدفوعة بالنوايا. تشمل مشتقات هذه النوايا مكونات Predicate، التي يمكنها تنفيذ نوايا المستخدمين وفقًا لقواعد معينة.
طبقة التسوية(Settlement Layer)
هذا هو طبقة وسيطة تستخدم لحل الطلبات لتحقيق نية المستخدم. تشمل المكونات الأساسية للحلول المتعلقة بالسيولة وحالة التوزيع:
بالإضافة إلى ذلك، يجب مراعاة السيولة بين السلاسل، والتأكيد النهائي (Finality)، وآلية إثبات طبقة 2 وغيرها من العوامل، لضمان التشغيل الفعال لنظام متعدد السلاسل.
حاليًا، هناك العديد من الحلول المتاحة في السوق لمعالجة خداع الناس لتحقيق الربح، وبعد مراجعة العديد من الحلول، وجدنا أن هناك عدة طرق رئيسية:
مركزية RaaS: مشابهة لحلول Rollup مثل OP Stack، من خلال إضافة مُرتب مشترك محدد وجسر عبر السلسلة للمساعدة في بناء Rollup على OP Stack ومشاركة السيولة والحالة. يأمل هذا في حل تشتت السيولة والحالة في اتجاه أعلى. هناك تصميم أكثر تفصيلاً لمُرتب مشترك منفصل، حيث أن هذه الخطة تستهدف بشكل أكبر طبقة 2، ولا تتمتع بالعمومية.
مركزية الحساب: بناء محفظة حسابات شاملة على السلسلة، تدعم توقيع وتنفيذ المعاملات عبر بروتوكولات متعددة من خلال تقنية تُعرف بـ "توقيع السلسلة". المكون الأساسي هو شبكة MPC، التي تتولى توقيع معاملات متعددة السلاسل بدلاً من المستخدمين. على الرغم من أن هذه الخطة يمكن أن تحل بشكل كبير مشكلة تفتيت تجربة المستخدم، إلا أنها تتطلب من المطورين تنفيذات خلفية معقدة، ولا تحل جوهريًا مشكلة السيولة وتوزيع الحالة.
مركزية شبكة نوايا خارج السلسلة: وهي شبكة Solver في مخطط هيكل "المقدمة" لدينا، حيث يقوم المستخدم بإرسال النية إلى شبكة Solver، ويتنافس هذا الدور على تقديم العروض، مقدماً أفضل وقت إنجاز وسعر تداول، يمكن أن تكون هذه الـ Solvers وكيل AI، أو CEX، أو صانع سوق، أو حتى البروتوكول المدمج نفسه. على الرغم من أن النية يمكن أن تحقق عملياً عمليات عبر السلسلة بمعقدات صعبة، إلا أنه يتطلب وجود Solvers سيولة كافية للمساعدة في التنفيذ، وعند مواجهة بعض الطلبات خارج السلسلة، قد يوجد احتمال لخداع الناس لتحقيق الربح من قبل الـ Solvers، وإذا تم إدخال وسائل مثل إثبات الاحتيال، ستصبح صعوبة تنفيذ شبكة Solver أعلى، كما ستزداد عتبة تشغيل الـ Solvers.
مركزية شبكة السيولة على السلسلة: هذا الاتجاه يركز على تحسين مشكلة السيولة عبر السلاسل، لكنه لم يحل المشاكل الأخرى المتعلقة بتوزيع الحالة على السلسلة. جوهره هو بناء طبقة سيولة، يتم بناء التطبيقات على هذه الطبقة، لمشاركة السيولة عبر السلسلة بأكملها.
مركزية التطبيقات على السلسلة: هذه التطبيقات تبني تطبيقات عالية السيولة من خلال دمج MM الكبير، أو تطبيقات الطرف الثالث وغيرها. تتطلب هذه المشاريع إدارة عمليات معقدة عبر السلاسل، مما يضع متطلبات عالية على المطورين، وبالتالي فإنها عرضة بسهولة لحدوث هجمات قرصنة.
حل مشكلة السيولة هو موضوع مهم جداً، حيث تمثل السيولة كل شيء في العالم المالي، إذا استطعت بناء منصة متكاملة للسيولة، وخاصة دمج السيولة المتفرقة من جميع السلاسل معاً، فسوف تمتلك إمكانيات كبيرة، وقد رأينا العديد من الحلول المختلفة.
في التصنيفين أعلاه، يمكننا أن نرى أن وفقًا لهياكل الكعكة، فإن Settlement Layer هو الحل الأكثر ذرية، وفوق هذه الحلول الذرية مثل عبر السلاسل، وأجهزة التنبؤ، وحلول Pre-Confirmation، يتم بناء طبقة أكثر تجريدًا، وهي Solver Layer وPermission Layer وApplication Layer. يمكن فهم المستويات المختلفة التي قمنا بإدراجها أعلاه، والتي تبني حلولًا تجريدية أو حلول السيولة في اتجاهات مختلفة، على أنها علاقة بين المصب والمصب. ولكن هذه الحلول لا تزال ليست حلولًا ذرية، حيث أن مشكلة الانقسام في السيولة قد أدت إلى ظهور العديد من المشكلات الفرعية المعقدة، وبالتالي نشأت حلول متنوعة لمشكلة التشغيل البيني. ولكن في الجوهر، لا يزال يعتمد على هذه المكونات.
حل مشكلة السيولة عبر السلاسل هو مجال معقد للغاية وله العديد من الحلول، مثل حلول الطبقة 2 التي تتنوع بين الحلول التي تعتمد على الرسائل عبر السلاسل، وخاصة ERC-7683، وحل OP Stack المبني على الطبقة 2 لمشاركة Sequencer. بعيدًا عن سياق الطبقة 2، تواجه جميع الطبقات 1 أيضًا مشكلات تتعلق بالسيولة والحالة وتجربة المستخدم، هناك حلول مخصصة تركز على التطبيقات المتعلقة بالسيولة، وكذلك حلول خارج السلسلة عبر شبكة Solver، بل وهناك أيضًا حلول تركز على الحسابات، ولكنها تحتاج أيضًا إلى أن تستند إلى دور Solver الخارجي.
نحن نعتقد أن انقسام السيولة عبر السلاسل، والحالة، وتجربة المستخدم هو مشكلة في صناعة blockchain بأكملها، وإذا فكرنا في الأمر بشكل شامل، نحتاج إلى القيام بذلك بطريقة أكثر تجريدًا، تشبه التجريد من السلاسل، وهذا بمثابة المدخل الحقيقي لـ Web3، حيث يحل الانقسام في تجربة المستخدم، بينما يتم دمج السيولة والحالة في أماكن لا يستطيع المستخدمون إدراكها. كيفية الدمج بالتحديد، ينقسم أيضًا إلى استخدام شبكة Solver خارج السلسلة وتسهيلات الجسور عبر السلاسل ذات الطبيعة الذرية، وكل ذلك يستحق البحث. بشكل عام، سيكون المستقبل متعدد السلاسل، وحل مشكلة تشتت السيولة هو مسألة يجب أن تواجهها الصناعة حتمًا، بينما يوجد مجال واسع للنمو في دمج السيولة عبر السلاسل، مما قد يؤدي إلى بناء مدخل جديد للإنترنت في عصر Web3.