دراسة مشكلة خداع الناس لتحقيق الربح في عصر طبقة 2

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

بمساعدة OP Stack، أطلق أحد منصات التداول طبقة 2 الخاصة به، بينما أصدرت منصة تداول أخرى مشروع blockchain جديد؛ بمساعدة تقنية ZK، أطلقت إحدى منصات التداول طبقة جديدة. كما أصدرت بعض الشركات التكنولوجية الكبرى مشاريع blockchain الخاصة بها. اليوم، تم تقليل عتبة الأموال والتكنولوجيا لبناء سلسلة بشكل كبير، حيث أن تكلفة تشغيل سلسلة تعتمد على OP Stack تصل إلى حوالي 10,000 دولار في الشهر.

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

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

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

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

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

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

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

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

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

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

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

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

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

5. بالتركيز على تطبيقات السلسلة: تقوم هذه التطبيقات بدمج صانعي السوق الكبار أو التطبيقات من طرف ثالث لبناء تطبيقات ذات سيولة عالية. تتطلب هذه المشاريع إدارة عمليات عبر السلاسل معقدة، مما يرفع من متطلبات المطورين بشكل كبير، وبالتالي من السهل جدًا أن تظهر بها ثغرات أمنية.

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

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

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

بني مشروع ما خدمة RaaS في عالم DeFi، والتي يمكنها تقديم المكونات اللازمة لبناء بروتوكولات DeFi مباشرة، مثل Oracle و Pool Type و IRM و Asset، بالإضافة إلى توفير مكونات مثل Leverage Trading و Yield Strategy التي يمكن تفعيلها على الفور. ويعادل ذلك بناء تطبيقات أخرى، ولكن السيولة النهائية توضع في طبقة السيولة الخاصة بالمشروع. ومع ذلك، لم يتم الكشف عن آلية العمل الأساسية حتى الآن.

بنى مشروع آخر ثلاثة مكونات أساسية، وهي طبقة توافق Intent وValidity وطبقة التسوية العامة. يمكن للتطبيقات الخارجية أو طبقة النية نشر نوايا إلى هذا المشروع، ثم يمكن لطبقة توافق Intent تحويل النوايا الخارجية إلى تنسيق يمكن لـ Solver البروتوكول التعرف عليه، والصيغة المستخدمة هي لغة Validity. تتحمل عقد المشروع مسؤولية تقديم النتائج النهائية إلى طبقة التسوية العامة من خلال جسر عبر السلاسل، وتقنيات التسوية السريعة، وما إلى ذلك. لا يزال هذا المشروع في مرحلة البناء، ولم يتم الكشف عن المزيد من تفاصيل العمل بعد.

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

某 مشروع هو ترقية لعلامة تجارية أخرى، كان يركز سابقًا على تطبيقات المستهلك، ثم اكتشف الفريق وجود مشكلة كبيرة في تجزئة التفاعلات على السلسلة، لذلك أنشأوا مشروعًا جديدًا لتحسين هذه المشكلة. إنه مبني على بروتوكول توافق Comet BFT. تعتمد الاتصالات عبر السلاسل المستخدمة عليه على Cosmos IBC، وبالتالي فهي أكثر أصالة وأمانًا من الجسور عبر السلاسل الأخرى.

تعتبر مؤسسة معينة مطورًا لسوق قوة ZK على إيثريوم، ومعالجات ZK وطبقة 2، حيث يتمتع الفريق بخلفية تقنية عميقة في ZK. وقد قدمت حلاً يسمى zkSharding، والذي يستخدم تقنية ZK لتوسيع شبكة إيثريوم الرئيسية أفقيًا، وينفذ معالجة المعاملات بالتجزئة بشكل متوازي ويولد ZKP، بينما تتحقق شريحة البيانات الرئيسية، وتتواصل مع إيثريوم، وتزامن حالة الشبكة بين جميع المدققين. تدير الشريحة الرئيسية أيضًا توزيع المدققين والحسابات في شريحة التنفيذ. بروتوكول الإجماع الذي تستخدمه لجنة التحقق هو أيضًا Hotstuff، وهذا شائع في أحدث المشاريع التنفيذية المتوازية. وقد تم دمج الاتصال عبر الشرائح في البروتوكول منذ البداية. يتم التحقق من الرسائل عبر الشرائح من قبل لجنة المدققين في كل شريحة كمعاملات.

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

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

تعتبر بعض التقنيات، والمعايير المذكورة أعلاه ERC، و zkSharding، حلولاً داخلية على الإيثريوم لمشكلة تجزئة السيولة بين Layer2، حيث يتم التعامل معها على مستويات البنية التحتية، ومستوى الإجماع، ومستوى التطبيقات. يقوم هذا المكدس التكنولوجي بتصميم حل كامل متعدد Layer2 لحل قضايا نقل المعلومات واللامركزية للـ Sequencer مرة واحدة، وعند استخدامك لهذا المكدس المعماري، سيتم نشر عقود عبر السلاسل تلقائيًا، كما سيكون هناك مشرف لتحدي تجنب نقل معلومات كاذبة عبر السلاسل. حالياً، هناك العديد من المشاريع المعروفة التي تستخدم هذا المكدس المعماري.

حل مشكلة السيولة عبر السلاسل هو مجال معقد للغاية ويحتوي على العديد من الحلول. على سبيل المثال، تنقسم حلول Layer2 إلى حلول تعتمد على الرسائل عبر السلاسل المدمجة في إيثريوم، وخاصة المعايير ERC المذكورة أعلاه، بالإضافة إلى Sequencer المشترك المبني على بعض تقنيات السلسلة. بعيدا عن سياق Layer2، تعتبر جميع Layer1 أيضًا.