لفترة طويلة، كانت لدي دائمًا فكرة حل بعض المشكلات التي تواجهها مجموعة Rollup حاليًا من خلال تصميم Multi-Rollup. لمدة عام ونصف تقريبًا، اعتقدت أن شخصًا ما سيبنيه، لكنني لم أتعمق أبدًا في تفاصيل مثل هذا النظام أو أفكر فيه.
لقد مر وقت طويل الآن ولا يبدو أن هناك تصميمًا واحدًا يحل المشكلة التي وصفتها في هذا المنشور، لذلك سأقوم بملء تفاصيل هذا النظام بأفضل ما أستطيع على أمل أن يتمكن شخص ما من ذلك يمكنك الحصول على بعض الإلهام منه، أو حتى من مجموعة التحديثات الموجودة، واستعارة بعض الأفكار.
يقدم
اليوم، إحدى المشاكل التي تواجهها مجموعة التحديثات هي تجربة المستخدم. في العديد من التصميمات، تكون المجموعات المجمعة عبارة عن أنظمة بيئية مستقلة ذات خصائص مختلفة. هناك طرق للتشغيل البيني، لكن ربط أنظمة متعددة غير متجانسة يمثل تحديًا كبيرًا. علاوة على ذلك، فإن جذب المستخدمين للتسجيل في كل هذه المجموعات أمر صعب. يجب عليهم فهم كل مجموعة على حدة، وتقييم العقود الذكية المرتبطة بها، وربط محافظهم بنقاط نهاية RPC الجديدة، وربط الأصول بالسلسلة، وما إلى ذلك.
ماذا لو كان هناك تصميم مجموعة محتسبة يوفر تجربة موحدة لجميع مجموعات القيمة المحتسبة؟ ماذا سيكون شكلها؟
لقد سألت نفسي هذا السؤال وخرجت بالأفكار الخمس التالية:
يجب أن يوفر RPC موحدًا للاستعلام عن العقود الذكية المختلفة واستدعاءها عبر مجموعة التحديثات. يجب أن يكون للعقود الذكية عنوان فريد لا يعتمد على المجموعة التي تنتمي إليها.
ينبغي أن يسمح بتوسيع النطاق لأعلى ولأسفل بناءً على الطلب. المزيد من المعاملات يجب أن يعني المزيد من المجموعات المجمعة لمعالجتها، ويجب موازنة التحميل غير المتساوي بين المجموعات المجمعة.
يجب أن يحفز المُسلسلات في مجموعات مختلفة للبقاء على الإنترنت. يجب أن يشجع النظام الفارزين الآخرين على استبدال الفارز غير المتصل بالإنترنت.
يجب أن يدعم عمليات النقل الفورية عبر السلسلة. يجب تسوية المعاملات بسرعة كافية حتى تكون العمليات عبر السلسلة منطقية.
يجب أن يحافظ على وظيفة العميل الخفيف ويحظر وظائف المستكشف عبر عمليات الدمج المتعددة. يجب أن توفر مستكشفات الكتل رؤية موحدة لـ blockchain، ويجب أن يسمح العملاء الخفيفون بالتحقق بتكلفة منخفضة.
مع أخذ كل هذا في الاعتبار، توصلت إلى تصميم يتكون من مركز مجموعة محتسبة وعدد متغير من مجموعات مجموعات فرعية. يعد مركز التحديثات المجمعة بمثابة سجل وموازن تحميل لجميع المجموعات الفرعية، ولكنه لا يقوم بأي معالجة ذكية للعقود. يتم التعامل مع العقود الذكية في مجموعات فرعية.
في الأقسام التالية، سأستعرض مسودة تصميم لشرح الاعتبارات الخمسة التي ذكرتها أعلاه.
نظرة عامة على التصميم
يتكون النظام من مكونين رئيسيين: مركز التراكمي والتراكمي الفرعي. يحتوي نظام مركز التراكمي على مكونين رئيسيين: مركز التراكمي والفرعي. مركز القيمة المحتسبة هو عبارة عن مجموعة محتسبة تحتوي على كافة سجلات العقود الذكية لجميع المجموعات الفرعية وتحدد المجموعة المسؤولة عن أي عقد ذكي. بالإضافة إلى ذلك، يحتوي مركز التراكمي على تسجيل لكافة أجهزة التسلسل لمجموعة تراكمية فرعية أخرى. السلاسل الفرعية مسؤولة عن تنفيذ معاملات العقود الذكية المخصصة لها بواسطة مركز التجميع في سجل العقود الذكية. يحتوي سجل الفارز على مكونين رئيسيين لكل نظام فارز: مركز القيمة المحتسبة والقيمة المحتسبة التابعة. مركز القيمة المحتسبة هو عبارة عن مجموعة محتسبة تحتوي على كافة سجلات العقود الذكية لجميع المجموعات الفرعية وتحدد المجموعة المسؤولة عن أي عقد ذكي. بالإضافة إلى ذلك، يحتوي مركز التراكمي على تسجيل لكافة أجهزة التسلسل لمجموعة تراكمية فرعية أخرى. السلاسل الفرعية مسؤولة عن تنفيذ معاملات العقود الذكية المخصصة لها بواسطة مركز التجميع في سجل العقود الذكية. يحتوي سجل جهاز التسلسل على كل نقطة نهاية RPC لجهاز التسلسل وعنوان DA.
يعمل سجل التسلسل بمثابة تعيين لعناوين العقود الذكية العالمية لعناوين العقود الذكية. يتم استخدام هذا لتوجيه مكالمات RPC إلى جهاز التسلسل RPC المحدد المطابق للعقد الذكي الذي تم الاستعلام عنه أو المحدث.
سجل العقود الذكية
يعمل سجل العقود الذكية بمثابة خريطة من عناوين العقود الذكية العالمية إلى عناوين العقود الذكية.
سلسلة التجميع
عادةً ما يكون للسلاسل الفرعية جذر حالة. يمكن تحديث مسار الحالة هذا عن طريق استدعاء العقد الذكي مباشرة أو عندما يقوم مركز القيمة المحتسبة بتعيين العقد الذكي إلى مجموعة محتسبة أخرى. في هذه الحالة، يجب حذف العقد الذكي واستبداله. تتم إضافته إلى العقود الذكية الأخرى.
** RPC الموحد **
الهدف: عدم الاضطرار إلى الاتصال بسلسلة جديدة لكل مجموعة مجمعة، وجعل المعاملات المجمعة شفافة للمستخدمين.
يستعيد RPC الموحد تجربة المستخدم لسلسلة واحدة في شبكة مجموعات متعددة، ولا يتعين على المستخدمين الاتصال بشبكات مختلفة لاستخدام مجموعات مجموعات مختلفة.
يستخدم النظام سجل أوامر القيمة المحتسبة من مركز القيمة المحتسبة للعثور على نقطة نهاية RPC الخاصة بالطلب المتوافقة مع عقد ذكي معين. ثم يتم إرسال الطلب مباشرة إلى جهاز التسلسل هذا. يمكن إكمال معاملات متعددة عن طريق إرسال الطلبات إلى مجموعات مختلفة. تحقق من الأقسام التالية لمزيد من التفاصيل.
** طريقة العمل **
يحتفظ مركز التجميع بسجل أجهزة التسلسل لجميع السلاسل الفرعية.
عندما يريد المستخدم إرسال معاملة جديدة، ستقوم محفظة المستخدم بالاستعلام عن سجل العقد الذكي للحصول على معرف تراكمي للعقد الذكي، والاستعلام عن سجل جهاز التسلسل للحصول على نقطة نهاية RPC لجهاز التسلسل في نفس المجموعة.
يتم بعد ذلك إرسال المعاملة إلى نقطة نهاية RPC الخاصة بالأمر.
توزيع الحمل
الهدف: موازنة تكاليف جميع عمليات التجميع
تسمح موازنة التحميل بموازنة الحمل في مجموعة التحديثات. عندما يصبح النظام مسدودًا، يمكن إنشاء مجموعات جديدة للتعامل مع الحمل. عندما لا يكون هناك الكثير من الاستخدام، يمكن إزالة الإظهار لحفظ الموارد. بالإضافة إلى ذلك، يمكن للنظام تجنب ارتفاع الرسوم عن طريق نقل العقود الذكية ذات الطلب المرتفع في المعاملات إلى مجموعات مجمعة ذات سعة متاحة أكبر.
في كل فترة، يقوم مركز القيمة المحتسبة بتقييم حمل كافة مجموعات القيمة المحتسبة في النظام. يجب أن تستمر العصور بضع ساعات (ربما من 6 إلى 24 ساعة) لتجنب عمليات إعادة تخصيص العقود الذكية على نطاق واسع.
يمكن لمركز التجميع أن يقرر العقود الذكية التي سيتم إعادة توزيعها، ومتى يتم إنشاء أو حذف التحديثات، والتي يمكن تحديدها بشكل مستقل باستخدام الإدارة أو استخدام سجل استهلاك الغاز للعقود الذكية المختلفة.
يتحقق مركز القيمة المحتسبة مما إذا كان أي تراكم يحتوي على حمل معاملة أعلى من المتوسط (أي الرسوم مرتفعة) أو أقل من المتوسط (أي الرسوم منخفضة).
إذا كانت مجموعة القيمة المحتسبة تحتوي على حمل أعلى من المتوسط، يقوم مركز القيمة المحتسبة بتقييم العقود الذكية التي تستهلك أكبر قدر من الغاز ويعيد توزيعها على مجموعة محتسبة مختلفة يمكنها تحمل الحمل الإضافي. ستتم بعد ذلك إزالة العقد الذكي من حالة تراكم المضيف الأولية الخاصة به.
إذا كان متوسط تحميل كافة مجموعات القيمة المحتسبة أعلى من المتوسط، فسيقوم مركز القيمة المحتسبة بإنشاء مجموعة محتسبة جديدة وتعيين بعض العقود الذكية إلى مجموعة محتسبة جديدة. وبالمثل، إذا كان متوسط تحميل جميع مجموعات القيمة المحتسبة أقل من المتوسط، فسيقوم مركز القيمة المحتسبة بحذف مجموعة محتسبة وإعادة تعيين عقده الذكي إلى مجموعات محتسبة أخرى.
يجب أن تنظر سلاسل القيمة المحتسبة إلى مركز القيمة المحتسبة كل فترة، وتنزيل مساحة التخزين لأي عقود ذكية جديدة مخصصة لها، وحذف أي عقود ذكية لم تعد مسؤولة عنها.
ملاحظة: قد لا يكون تنزيل مساحة تخزين بعض العقود الذكية أمرًا تافهًا. أولاً، الحالة غير متوفرة في طبقة DA وهي كبيرة الحجم جدًا. وهذا يحد من الحد الأدنى لوقت العصر ويتطلب فترة سماح لإعداد تخزين العقد الذكي.
فرز الحوافز
الهدف: تحفيز طلبات النسخ الاحتياطي بمكافآت جزئية في الرموز الأصلية.
يتم إنشاء معظم المجموعات المجمعة اليوم على سلسلة واحدة، ويديرها واحد أو عدد قليل جدًا من الطلبات، بهدف زيادة وقت التشغيل المجمع إلى الحد الأقصى. في المقابل، في نظام المجموعات المتعددة، توجد عدة مجموعات فرعية مستقلة، يجب أن يكون كل منها متصلاً بالإنترنت ليظل نشطًا في النظام بأكمله.
سيتم بطبيعة الحال تحفيز الفارزين للانضمام إلى مجموعة التحديثات لجمع MEV، ولكن من الأفضل تقديم مكافآت مناسبة لهؤلاء الفارزين حيث أنهم أكثر اتساقًا ولا يخطئون في محاذاة الحوافز مثل MEV. يجب أن تأتي هذه المكافآت من السياسة النقدية لمركز التجميع.
بالإضافة إلى ذلك، من الجيد أن يكون لديك العديد من الطلبات في وضع الاستعداد وجاهزين للدخول، ويمكن لهؤلاء الطلبات الانضمام إلى النظام عندما يزيد طلب المعاملات، وترك النظام عندما لا تكون هناك موارد حاسوبية.
سيبقى جهاز التسلسل الاحتياطي في قائمة انتظار جهاز التسلسل وسيحصل على مكافأة صغيرة لالتزام التوفر. وعندما يتم تبادلها في مجموعة التحديثات، فإنهم يحصلون على المكافأة الكاملة. ستأتي المكافآت من آلية حرق الرسوم الخاصة بمركز التجميع.
كيف تستعمل
يمكن لمقدمي الطلبات الانضمام إلى قائمة انتظار الطلبات الخاصة بمركز القيمة المحتسبة عن طريق إرسال سند مالي (على غرار نظام القيمة المحتسبة الحالي).
يحتاج مقدمو الطلبات الموجودون في قائمة الانتظار إلى تقديم دليل DA على أن لديهم حالة مركز القيمة المحتسبة ويمكن قراءتها للانضمام إلى القيمة المحتسبة في أي وقت.
عندما يقدمون الأدلة، سيتم مكافأتهم جزئيًا، الرمز الأصلي للنظام. هذا الرمز المميز هو مؤشر على مركز التراكمي.
إذا قرر مركز القيمة المحتسبة أنهم بحاجة إلى مجموعة محتسبة جديدة، فسيتم تعيينهم والحصول على المكافأة الكاملة. يتم تحديد هذه المكافأة على أساس المبلغ الإجمالي للرسوم المستهلكة في النظام.
المعاملات المجمعة
الهدف: يجب أن تكون المعاملات المجمعة فورية وشفافة للمستخدمين.
يجب أن تتكون معاملة القيمة المحتسبة المتبادلة بين مجموعة القيمة أ ومجموعة القيمة ب من جزأين: 1) المعاملة في مجموعة القيمة المحتسبة أ 2) المعاملة في مجموعة القيمة المحتسبة ب. ولن تحدث إلا عندما تكون المعاملة في مجموعة القيمة أ ناجحة ونهائية.
للتأكيد السريع، يمكن لمحافظ المستخدم التحقق مما إذا تم إرسال المعاملة إلى طبقة DA الأساسية وإثبات صلاحيتها باستخدام ZK. إذا كانت المعاملة مضمنة وصالحة، فيجب أن يصل المُسلسِل إلى نفس النتيجة لتلك المعاملة المعينة.
يعود الفضل في الفكرة إلى مصطفى البسام وشركة Sovereign Labs.
كيف تستعمل
يرسل المستخدم معاملة تتضمن ثلاث مجموعات، على سبيل المثال RollupA وB وC.
دعونا نفكر في مثال محدد، Rollup A لديه عقد ذكي للعملة المستقرة، وRollup B لديه DEX، وRollup C لديه بروتوكول إقراض. في هذا المثال، يريد المستخدم استبدال عملته المستقرة باتفاقية قرض ورمز مميز مختلف.
يجب على المستخدمين أولاً إرسال معاملة Rollup A لنقل العملات المستقرة إلى DEX في Rollup B.
ويمكنهم بعد ذلك إرسال معاملة Rollup B DEX التي تستبدل العملة المستقرة بالرمز المميز المطلوب في Rollup B.
وفي المقابل، كان من المفترض أن يتم نقل الرمز المميز إلى RollupC، لذلك أرسل المستخدم معاملة ثالثة، وهو ما حدث بالضبط.
أخيرًا، يرسل المستخدم المعاملة الرابعة والأخيرة، حيث يقوم بإيداع الرموز المميزة في بروتوكول الإقراض.
** العقدة الخفيفة ومستكشف الكتلة **
الهدف: يجب أن تكون العقد الخفيفة قادرة على التحقق من العقود الذكية عبر المجموعات المجمعة، ويجب أن توفر مستكشفات المجموعات رؤية موحدة للسلسلة.
يجب أن يسمح نظام blockchain لأي شخص بتشغيل العقدة والتحقق من السلسلة نفسها. في هذا التصميم متعدد المجموعات، حيث يتم إعادة تعيين العقود الذكية باستمرار إلى مجموعات فرعية مختلفة، يجب أن تكون هناك طريقة لتتبع هذه العقود الذكية المحددة. يعد هذا تحولًا في التفكير من التحقق من صحة سلسلة واحدة أو أكثر إلى التحقق من صحة واحد أو أكثر من العقود الذكية. يمكن للعقد الخفيفة استخدام بروفات ZK للتحقق من جميع مجموعات البيانات التابعة بتكلفة منخفضة.
يجب أن تدعم العقد المجمعة وضع التحقق من الصحة، إلى جانب وضع التسلسل.
يتحقق وضع التحقق من حالة عقد ذكي واحد، على عكس وضع التسلسل، الذي يرسل دفعات المعاملات إلى طبقة DA.
إذا قام عقد ذكي بتغيير مجموعة فرعية، فسيحتاج المدققون فقط إلى تحديث المجموعة الفرعية التي يستمعون إليها نظرًا لأنهم يمتلكون بالفعل مخزن العقد الذكي حتى إعادة التخصيص.
يجب معالجة العقود الذكية في مجموعة واحدة في كل مرة. نظرًا لأنها مقيدة بالمجموعة المجمعة، يجب أن يكون التحقق من العقد بنفس المواصفات قادرًا على تتبعها والتحقق منها.
يمكن للعقد الخفيفة استخدام إثباتات ZK للتحقق من حالة السلسلة بتكلفة زهيدة.
تعد مستكشفات الكتل جزءًا لا يتجزأ من نظام blockchain. إنها تسهل الاستعلامات عن الرصيد للأصول الأصلية، واستعلامات العقود الذكية، وتحافظ على سجل المعاملات من الكتلة الأولى إلى الكتلة الحالية. في نظام المجموعات المتعددة هذا، يجب أن يوفر مستكشف الكتل عرضًا موحدًا لجميع المجموعات الفرعية.
يجب أن يدعم مستكشف الكتل الاستعلام عن رصيد مركز التجميع (للأصول الأصلية) وسجل المعاملات لجميع المجموعات الفرعية.
على غرار نظام التجميع الفردي، تستخدم مستكشفات المجموعات فهرسًا لتحقيق ذلك. يجب أن يقوم نظام المجموعات المتعددة بفهرسة جميع المجموعات المجمعة لتوفير خدمات الاستعلام لأي عقد ذكي في النظام.
إذا قرر مركز القيمة المحتسبة زيادة عدد المجموعات الفرعية، فيجب أن يكون مستكشف الكتل جاهزًا للتعامل معها. ويجب أن توفر المزيد من سعة التجميع الفرعي، أو أن يكون لديها نظام تنسيق حاوية (مثل Kubernetes) لتوسيع نطاق المجموعات الفرعية تلقائيًا.
يجب عليهم استخدام أرقام الكتل من طبقة DA لتحقيق الاتساق عبر جميع المجموعات المجمعة.
ختاماً
التصميم أعلاه هو مجرد فكرة في الوقت الحالي وقد لا أنفذها أبدًا، ولكن أتمنى أن تنال الرؤية اهتمامك. إذا تم قبول التصميم، أتوقع أن يتم استخدامه في مشاريع التجميع والاقتراب من إمكانيات التوسع في EIP-4844 أو Celestia أو Avail.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
توسيع المستقبل: مفهوم تصميم نظام متعدد القوائم
المؤلف: AndreasTzionis؛ المصدر: ethresear.ch؛ التجميع: Yvonne, MarsBit
لفترة طويلة، كانت لدي دائمًا فكرة حل بعض المشكلات التي تواجهها مجموعة Rollup حاليًا من خلال تصميم Multi-Rollup. لمدة عام ونصف تقريبًا، اعتقدت أن شخصًا ما سيبنيه، لكنني لم أتعمق أبدًا في تفاصيل مثل هذا النظام أو أفكر فيه.
لقد مر وقت طويل الآن ولا يبدو أن هناك تصميمًا واحدًا يحل المشكلة التي وصفتها في هذا المنشور، لذلك سأقوم بملء تفاصيل هذا النظام بأفضل ما أستطيع على أمل أن يتمكن شخص ما من ذلك يمكنك الحصول على بعض الإلهام منه، أو حتى من مجموعة التحديثات الموجودة، واستعارة بعض الأفكار.
يقدم
اليوم، إحدى المشاكل التي تواجهها مجموعة التحديثات هي تجربة المستخدم. في العديد من التصميمات، تكون المجموعات المجمعة عبارة عن أنظمة بيئية مستقلة ذات خصائص مختلفة. هناك طرق للتشغيل البيني، لكن ربط أنظمة متعددة غير متجانسة يمثل تحديًا كبيرًا. علاوة على ذلك، فإن جذب المستخدمين للتسجيل في كل هذه المجموعات أمر صعب. يجب عليهم فهم كل مجموعة على حدة، وتقييم العقود الذكية المرتبطة بها، وربط محافظهم بنقاط نهاية RPC الجديدة، وربط الأصول بالسلسلة، وما إلى ذلك.
ماذا لو كان هناك تصميم مجموعة محتسبة يوفر تجربة موحدة لجميع مجموعات القيمة المحتسبة؟ ماذا سيكون شكلها؟
لقد سألت نفسي هذا السؤال وخرجت بالأفكار الخمس التالية:
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-24cc855280-dd1a6f-6d2ef1)
مع أخذ كل هذا في الاعتبار، توصلت إلى تصميم يتكون من مركز مجموعة محتسبة وعدد متغير من مجموعات مجموعات فرعية. يعد مركز التحديثات المجمعة بمثابة سجل وموازن تحميل لجميع المجموعات الفرعية، ولكنه لا يقوم بأي معالجة ذكية للعقود. يتم التعامل مع العقود الذكية في مجموعات فرعية.
في الأقسام التالية، سأستعرض مسودة تصميم لشرح الاعتبارات الخمسة التي ذكرتها أعلاه.
نظرة عامة على التصميم
يتكون النظام من مكونين رئيسيين: مركز التراكمي والتراكمي الفرعي. يحتوي نظام مركز التراكمي على مكونين رئيسيين: مركز التراكمي والفرعي. مركز القيمة المحتسبة هو عبارة عن مجموعة محتسبة تحتوي على كافة سجلات العقود الذكية لجميع المجموعات الفرعية وتحدد المجموعة المسؤولة عن أي عقد ذكي. بالإضافة إلى ذلك، يحتوي مركز التراكمي على تسجيل لكافة أجهزة التسلسل لمجموعة تراكمية فرعية أخرى. السلاسل الفرعية مسؤولة عن تنفيذ معاملات العقود الذكية المخصصة لها بواسطة مركز التجميع في سجل العقود الذكية. يحتوي سجل الفارز على مكونين رئيسيين لكل نظام فارز: مركز القيمة المحتسبة والقيمة المحتسبة التابعة. مركز القيمة المحتسبة هو عبارة عن مجموعة محتسبة تحتوي على كافة سجلات العقود الذكية لجميع المجموعات الفرعية وتحدد المجموعة المسؤولة عن أي عقد ذكي. بالإضافة إلى ذلك، يحتوي مركز التراكمي على تسجيل لكافة أجهزة التسلسل لمجموعة تراكمية فرعية أخرى. السلاسل الفرعية مسؤولة عن تنفيذ معاملات العقود الذكية المخصصة لها بواسطة مركز التجميع في سجل العقود الذكية. يحتوي سجل جهاز التسلسل على كل نقطة نهاية RPC لجهاز التسلسل وعنوان DA.
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-30f0cf6d9f-dd1a6f-6d2ef1)
سجل التسلسل
يعمل سجل التسلسل بمثابة تعيين لعناوين العقود الذكية العالمية لعناوين العقود الذكية. يتم استخدام هذا لتوجيه مكالمات RPC إلى جهاز التسلسل RPC المحدد المطابق للعقد الذكي الذي تم الاستعلام عنه أو المحدث.
سجل العقود الذكية
يعمل سجل العقود الذكية بمثابة خريطة من عناوين العقود الذكية العالمية إلى عناوين العقود الذكية.
سلسلة التجميع
عادةً ما يكون للسلاسل الفرعية جذر حالة. يمكن تحديث مسار الحالة هذا عن طريق استدعاء العقد الذكي مباشرة أو عندما يقوم مركز القيمة المحتسبة بتعيين العقد الذكي إلى مجموعة محتسبة أخرى. في هذه الحالة، يجب حذف العقد الذكي واستبداله. تتم إضافته إلى العقود الذكية الأخرى.
** RPC الموحد **
الهدف: عدم الاضطرار إلى الاتصال بسلسلة جديدة لكل مجموعة مجمعة، وجعل المعاملات المجمعة شفافة للمستخدمين.
يستعيد RPC الموحد تجربة المستخدم لسلسلة واحدة في شبكة مجموعات متعددة، ولا يتعين على المستخدمين الاتصال بشبكات مختلفة لاستخدام مجموعات مجموعات مختلفة.
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-74756eed1e-dd1a6f-6d2ef1)
يستخدم النظام سجل أوامر القيمة المحتسبة من مركز القيمة المحتسبة للعثور على نقطة نهاية RPC الخاصة بالطلب المتوافقة مع عقد ذكي معين. ثم يتم إرسال الطلب مباشرة إلى جهاز التسلسل هذا. يمكن إكمال معاملات متعددة عن طريق إرسال الطلبات إلى مجموعات مختلفة. تحقق من الأقسام التالية لمزيد من التفاصيل.
** طريقة العمل **
يحتفظ مركز التجميع بسجل أجهزة التسلسل لجميع السلاسل الفرعية.
عندما يريد المستخدم إرسال معاملة جديدة، ستقوم محفظة المستخدم بالاستعلام عن سجل العقد الذكي للحصول على معرف تراكمي للعقد الذكي، والاستعلام عن سجل جهاز التسلسل للحصول على نقطة نهاية RPC لجهاز التسلسل في نفس المجموعة.
يتم بعد ذلك إرسال المعاملة إلى نقطة نهاية RPC الخاصة بالأمر.
توزيع الحمل
الهدف: موازنة تكاليف جميع عمليات التجميع
تسمح موازنة التحميل بموازنة الحمل في مجموعة التحديثات. عندما يصبح النظام مسدودًا، يمكن إنشاء مجموعات جديدة للتعامل مع الحمل. عندما لا يكون هناك الكثير من الاستخدام، يمكن إزالة الإظهار لحفظ الموارد. بالإضافة إلى ذلك، يمكن للنظام تجنب ارتفاع الرسوم عن طريق نقل العقود الذكية ذات الطلب المرتفع في المعاملات إلى مجموعات مجمعة ذات سعة متاحة أكبر.
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-632aa78015-dd1a6f-6d2ef1)
** طريقة العمل **
في كل فترة، يقوم مركز القيمة المحتسبة بتقييم حمل كافة مجموعات القيمة المحتسبة في النظام. يجب أن تستمر العصور بضع ساعات (ربما من 6 إلى 24 ساعة) لتجنب عمليات إعادة تخصيص العقود الذكية على نطاق واسع.
يمكن لمركز التجميع أن يقرر العقود الذكية التي سيتم إعادة توزيعها، ومتى يتم إنشاء أو حذف التحديثات، والتي يمكن تحديدها بشكل مستقل باستخدام الإدارة أو استخدام سجل استهلاك الغاز للعقود الذكية المختلفة.
يتحقق مركز القيمة المحتسبة مما إذا كان أي تراكم يحتوي على حمل معاملة أعلى من المتوسط (أي الرسوم مرتفعة) أو أقل من المتوسط (أي الرسوم منخفضة).
إذا كانت مجموعة القيمة المحتسبة تحتوي على حمل أعلى من المتوسط، يقوم مركز القيمة المحتسبة بتقييم العقود الذكية التي تستهلك أكبر قدر من الغاز ويعيد توزيعها على مجموعة محتسبة مختلفة يمكنها تحمل الحمل الإضافي. ستتم بعد ذلك إزالة العقد الذكي من حالة تراكم المضيف الأولية الخاصة به.
إذا كان متوسط تحميل كافة مجموعات القيمة المحتسبة أعلى من المتوسط، فسيقوم مركز القيمة المحتسبة بإنشاء مجموعة محتسبة جديدة وتعيين بعض العقود الذكية إلى مجموعة محتسبة جديدة. وبالمثل، إذا كان متوسط تحميل جميع مجموعات القيمة المحتسبة أقل من المتوسط، فسيقوم مركز القيمة المحتسبة بحذف مجموعة محتسبة وإعادة تعيين عقده الذكي إلى مجموعات محتسبة أخرى.
يجب أن تنظر سلاسل القيمة المحتسبة إلى مركز القيمة المحتسبة كل فترة، وتنزيل مساحة التخزين لأي عقود ذكية جديدة مخصصة لها، وحذف أي عقود ذكية لم تعد مسؤولة عنها.
ملاحظة: قد لا يكون تنزيل مساحة تخزين بعض العقود الذكية أمرًا تافهًا. أولاً، الحالة غير متوفرة في طبقة DA وهي كبيرة الحجم جدًا. وهذا يحد من الحد الأدنى لوقت العصر ويتطلب فترة سماح لإعداد تخزين العقد الذكي.
فرز الحوافز
الهدف: تحفيز طلبات النسخ الاحتياطي بمكافآت جزئية في الرموز الأصلية.
يتم إنشاء معظم المجموعات المجمعة اليوم على سلسلة واحدة، ويديرها واحد أو عدد قليل جدًا من الطلبات، بهدف زيادة وقت التشغيل المجمع إلى الحد الأقصى. في المقابل، في نظام المجموعات المتعددة، توجد عدة مجموعات فرعية مستقلة، يجب أن يكون كل منها متصلاً بالإنترنت ليظل نشطًا في النظام بأكمله.
سيتم بطبيعة الحال تحفيز الفارزين للانضمام إلى مجموعة التحديثات لجمع MEV، ولكن من الأفضل تقديم مكافآت مناسبة لهؤلاء الفارزين حيث أنهم أكثر اتساقًا ولا يخطئون في محاذاة الحوافز مثل MEV. يجب أن تأتي هذه المكافآت من السياسة النقدية لمركز التجميع.
بالإضافة إلى ذلك، من الجيد أن يكون لديك العديد من الطلبات في وضع الاستعداد وجاهزين للدخول، ويمكن لهؤلاء الطلبات الانضمام إلى النظام عندما يزيد طلب المعاملات، وترك النظام عندما لا تكون هناك موارد حاسوبية.
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-02c28a977e-dd1a6f-6d2ef1)
سيبقى جهاز التسلسل الاحتياطي في قائمة انتظار جهاز التسلسل وسيحصل على مكافأة صغيرة لالتزام التوفر. وعندما يتم تبادلها في مجموعة التحديثات، فإنهم يحصلون على المكافأة الكاملة. ستأتي المكافآت من آلية حرق الرسوم الخاصة بمركز التجميع.
كيف تستعمل
يمكن لمقدمي الطلبات الانضمام إلى قائمة انتظار الطلبات الخاصة بمركز القيمة المحتسبة عن طريق إرسال سند مالي (على غرار نظام القيمة المحتسبة الحالي).
يحتاج مقدمو الطلبات الموجودون في قائمة الانتظار إلى تقديم دليل DA على أن لديهم حالة مركز القيمة المحتسبة ويمكن قراءتها للانضمام إلى القيمة المحتسبة في أي وقت.
عندما يقدمون الأدلة، سيتم مكافأتهم جزئيًا، الرمز الأصلي للنظام. هذا الرمز المميز هو مؤشر على مركز التراكمي.
إذا قرر مركز القيمة المحتسبة أنهم بحاجة إلى مجموعة محتسبة جديدة، فسيتم تعيينهم والحصول على المكافأة الكاملة. يتم تحديد هذه المكافأة على أساس المبلغ الإجمالي للرسوم المستهلكة في النظام.
المعاملات المجمعة
الهدف: يجب أن تكون المعاملات المجمعة فورية وشفافة للمستخدمين.
يجب أن تتكون معاملة القيمة المحتسبة المتبادلة بين مجموعة القيمة أ ومجموعة القيمة ب من جزأين: 1) المعاملة في مجموعة القيمة المحتسبة أ 2) المعاملة في مجموعة القيمة المحتسبة ب. ولن تحدث إلا عندما تكون المعاملة في مجموعة القيمة أ ناجحة ونهائية.
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-6899964b00-dd1a6f-6d2ef1)
للتأكيد السريع، يمكن لمحافظ المستخدم التحقق مما إذا تم إرسال المعاملة إلى طبقة DA الأساسية وإثبات صلاحيتها باستخدام ZK. إذا كانت المعاملة مضمنة وصالحة، فيجب أن يصل المُسلسِل إلى نفس النتيجة لتلك المعاملة المعينة.
يعود الفضل في الفكرة إلى مصطفى البسام وشركة Sovereign Labs.
كيف تستعمل
يرسل المستخدم معاملة تتضمن ثلاث مجموعات، على سبيل المثال RollupA وB وC.
دعونا نفكر في مثال محدد، Rollup A لديه عقد ذكي للعملة المستقرة، وRollup B لديه DEX، وRollup C لديه بروتوكول إقراض. في هذا المثال، يريد المستخدم استبدال عملته المستقرة باتفاقية قرض ورمز مميز مختلف.
يجب على المستخدمين أولاً إرسال معاملة Rollup A لنقل العملات المستقرة إلى DEX في Rollup B.
ويمكنهم بعد ذلك إرسال معاملة Rollup B DEX التي تستبدل العملة المستقرة بالرمز المميز المطلوب في Rollup B.
وفي المقابل، كان من المفترض أن يتم نقل الرمز المميز إلى RollupC، لذلك أرسل المستخدم معاملة ثالثة، وهو ما حدث بالضبط.
أخيرًا، يرسل المستخدم المعاملة الرابعة والأخيرة، حيث يقوم بإيداع الرموز المميزة في بروتوكول الإقراض.
** العقدة الخفيفة ومستكشف الكتلة **
الهدف: يجب أن تكون العقد الخفيفة قادرة على التحقق من العقود الذكية عبر المجموعات المجمعة، ويجب أن توفر مستكشفات المجموعات رؤية موحدة للسلسلة.
يجب أن يسمح نظام blockchain لأي شخص بتشغيل العقدة والتحقق من السلسلة نفسها. في هذا التصميم متعدد المجموعات، حيث يتم إعادة تعيين العقود الذكية باستمرار إلى مجموعات فرعية مختلفة، يجب أن تكون هناك طريقة لتتبع هذه العقود الذكية المحددة. يعد هذا تحولًا في التفكير من التحقق من صحة سلسلة واحدة أو أكثر إلى التحقق من صحة واحد أو أكثر من العقود الذكية. يمكن للعقد الخفيفة استخدام بروفات ZK للتحقق من جميع مجموعات البيانات التابعة بتكلفة منخفضة.
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-69f308abb1-dd1a6f-6d2ef1)
كيف يعمل (العميل الخفيف)
يجب أن تدعم العقد المجمعة وضع التحقق من الصحة، إلى جانب وضع التسلسل.
يتحقق وضع التحقق من حالة عقد ذكي واحد، على عكس وضع التسلسل، الذي يرسل دفعات المعاملات إلى طبقة DA.
إذا قام عقد ذكي بتغيير مجموعة فرعية، فسيحتاج المدققون فقط إلى تحديث المجموعة الفرعية التي يستمعون إليها نظرًا لأنهم يمتلكون بالفعل مخزن العقد الذكي حتى إعادة التخصيص.
يجب معالجة العقود الذكية في مجموعة واحدة في كل مرة. نظرًا لأنها مقيدة بالمجموعة المجمعة، يجب أن يكون التحقق من العقد بنفس المواصفات قادرًا على تتبعها والتحقق منها.
يمكن للعقد الخفيفة استخدام إثباتات ZK للتحقق من حالة السلسلة بتكلفة زهيدة.
تعد مستكشفات الكتل جزءًا لا يتجزأ من نظام blockchain. إنها تسهل الاستعلامات عن الرصيد للأصول الأصلية، واستعلامات العقود الذكية، وتحافظ على سجل المعاملات من الكتلة الأولى إلى الكتلة الحالية. في نظام المجموعات المتعددة هذا، يجب أن يوفر مستكشف الكتل عرضًا موحدًا لجميع المجموعات الفرعية.
! [Rollup] (https://img-cdn.gateio.im/resize-social/moments-40baef27dd-217876ee66-dd1a6f-6d2ef1)
كيف يعمل (مستكشف الكتلة)
يجب أن يدعم مستكشف الكتل الاستعلام عن رصيد مركز التجميع (للأصول الأصلية) وسجل المعاملات لجميع المجموعات الفرعية.
على غرار نظام التجميع الفردي، تستخدم مستكشفات المجموعات فهرسًا لتحقيق ذلك. يجب أن يقوم نظام المجموعات المتعددة بفهرسة جميع المجموعات المجمعة لتوفير خدمات الاستعلام لأي عقد ذكي في النظام.
إذا قرر مركز القيمة المحتسبة زيادة عدد المجموعات الفرعية، فيجب أن يكون مستكشف الكتل جاهزًا للتعامل معها. ويجب أن توفر المزيد من سعة التجميع الفرعي، أو أن يكون لديها نظام تنسيق حاوية (مثل Kubernetes) لتوسيع نطاق المجموعات الفرعية تلقائيًا.
يجب عليهم استخدام أرقام الكتل من طبقة DA لتحقيق الاتساق عبر جميع المجموعات المجمعة.
ختاماً
التصميم أعلاه هو مجرد فكرة في الوقت الحالي وقد لا أنفذها أبدًا، ولكن أتمنى أن تنال الرؤية اهتمامك. إذا تم قبول التصميم، أتوقع أن يتم استخدامه في مشاريع التجميع والاقتراب من إمكانيات التوسع في EIP-4844 أو Celestia أو Avail.