تدور الكثير من المناقشات على تويتر مؤخرًا حول لامركزية اللغة الثانية. هل التراكميات التي نبنيها لامركزية بما فيه الكفاية؟ أم أنهم على الأقل على طريق اللامركزية؟ هل يهم؟
فكرة التراكمية بسيطة: نريد أن يكون المشاركون خارج السلسلة قادرين على إجراء المعاملات التي يمكن التحقق منها بسهولة على السلسلة. باستخدام Rollup ، تسمح الطبقة الأساسية باستخدام قاعدتها من "الثقة" في الأنشطة التي تحدث خارج مجالها المباشر. في المقابل ، يدفع التراكمي رسومًا رمزية (إيجار) للاستفادة من هذه الثقة.
فهل نحن بحاجة إلى التراكمية اللامركزية؟
الجواب البديهي هو نعم! هذه هي الروح التي نبني بها blockchain.
ومع ذلك ، أعتقد أن الإجابة على هذا السؤال ليست بسيطة بنعم أو لا. بدلاً من ذلك ، فإنه يحتوي على جوانب متعددة يجب تحليلها بشكل فردي. في الفصول التالية ، سأفصل هذا السؤال من ثلاث وجهات نظر: فلسفية ، وتكنولوجية ، واقتصادية. **** هذه الثلاثة ليست بالضرورة شاملة أو حصرية ، ولكن يجب أن تعطي منظورًا عامًا جيدًا للمشكلة. **
1. منظور فلسفي
لنبدأ بالارتقاء بالمحادثة إلى مستوى - لماذا نهتم باللامركزية؟
لأننا نريد مستقبلًا غير مرخص به يشجع الابتكار المفتوح. نريد أن يتمكن المستخدمون من بناء أشياء جديدة دون أي قيود ودون الحاجة إلى الوثوق بأي كيان واحد.
في التاريخ القصير لـ blockchain ، كان لدينا الكثير من المطورين المجهولين لبناء أشياء مذهلة. في الواقع ، تم إنشاء Bitcoin نفسها بواسطة كيان مجهول - قد تكون قريبًا العملة التي يستخدمها معظم الناس في العالم للمدفوعات العالمية! هذه هي قوة الابتكار غير المرخص!
يسمح لنا Blockchain بالتعاون مع الأشخاص الذين ليس لديهم أي شيء مشترك ونعلم أنه ليس لديهم طريقة لكسر هذه الثقة - بريستون إيفانز
يسمح لنا الأساس اللامركزي للشبكات غير الموثوقة مثل Bitcoin و Ethereum ببناء مثل هذا المستقبل. ثم من الواضح أن أي سلسلة لها علاقة ثقة مع هذه السلاسل ، مثل Rollups ، يجب أن تكون لامركزية أيضًا!
في الواقع ، إنه يثير سؤالًا مثيرًا للاهتمام ومهمًا:
** إذا لم يكن التراكمي لامركزيًا ، فهل هذا يعني أن Ethereum ليست لامركزية؟ **
هناك طريقة متفائلة إلى حد ما للنظر في هذا الأمر وهي أنه في عالم غير مرخص ، يجب السماح للمجموعات المجمعة ببناء أي شيء يريدونه ، بما في ذلك (على سبيل المثال لا الحصر) السلاسل المرخصة بالكامل - ويجب أن يظل مستخدمو مجموعة التحديثات هذه قادرين على الاستفادة من الأمان في طبقة القاعدة. يجب أن تكون السلاسل المرخصة آمنة للاستخدام طالما أن الطبقة الأساسية لا مركزية ويتم تنفيذ التجميع "بالكامل" (سنتحدث أكثر عن "تم التنفيذ الكامل" في القسم الفني).
لكن الحقيقة هي أن معظم التراكميات اليوم لم تصل بعد إلى مرحلة التنفيذ الكامل ، ولا توفر للمستخدمين المستوى المطلوب من الأمان وعدم الثقة.
إذن ، كيف يبدو التطبيق الصحيح للتجميع؟ دعنا نرى:
2. التكنولوجيا
لفهم مسألة اللامركزية والأمان حقًا على مستوى التراكمية ، نحتاج إلى النظر إليها من المبادئ الأولى. لا يستطيع الكثير من الناس شرح المبادئ الأولى لـ blockchain أفضل من Sreeram Kannan.
blockchain عبارة عن دفتر أستاذ موزع حيث تتبع العقد المختلفة في الشبكة بروتوكولًا محددًا للحصول على إجماع حول حالة دفتر الأستاذ. اعتمادًا على كيفية رؤية هذه العقد للشبكة ، يمكن أن يكون لها قواعد مختلفة لتأكيد الحالة الصحيحة للشبكة في دفتر الأستاذ الخاص بها.
على سبيل المثال ، في بروتوكول Gasper الخاص بـ Ethereum ، هناك قاعدتان مختلفتان للتأكيد - القاعدة المتاحة (بناءً على السلسلة الأثقل) والقاعدة النهائية (بناءً على الكتل التي أكدتها الأداة الذكية).
خاصة في المجموعات ، العقد الكاملة لها قواعد تأكيد مختلفة عن العملاء الخفيفين. في مجموعة العقود الذكية التقليدية (SCR) ، يحتوي العقد الذكي (جسر التحقق) على قواعد التأكيد الخاصة به. إذا لم تكن هناك أحداث سلبية ، فإن قواعد التأكيد هذه تتوافق في النهاية مع ما يسمى "مناطق التناسق". كما يوحي الاسم ، في مناطق الإجماع ، يكون لجميع المشاركين نفس وجهة نظر الشبكة (ولهم نفس التاريخ في دفاتر الأستاذ الخاصة بهم).
إذا كانت جميع قواعد التأكيد آمنة ، فلن تحدث أشياء سيئة. نظرًا لأن Sreeram شارك في المنشور أعلاه ، فإن 5 خصائص تحدد بشكل أساسي أمان قواعد التأكيد هذه.
** نمو دفتر الأستاذ - يجب أن تستمر سلسلة التجميع في النمو (الحيوية) **
** مقاومة الرقابة - يجب أن يكون جميع المستخدمين قادرين على تضمين أي وجميع المعاملات في الطبقة الأساسية **
** مقاومة إعادة الهيكلة - لا ينبغي إعادة المعاملة بمجرد اكتمالها **
** توفر البيانات - يجب نشر بيانات المعاملة في مكان ما **
** الصلاحية - يجب أن تكون المعاملات وتحولات الحالة صالحة **
تحدد الخصائص الأولى والثانية معًا الحالة "الحية" للنظام ، بينما تحدد الخصائص الثلاثة الأخيرة الحالة "الآمنة".
دعونا نلقي نظرة على كل منها من منظور مختلف الجهات الفاعلة في التجميع ومعرفة أي منها يمكن تخفيفه دون اللامركزية.
تعتمد الجهات الفاعلة المختلفة على آليات مختلفة للسلامة والحيوية
العقدة الكاملة:
إذا قمت بتشغيل عقدة كاملة ، يمكنك الوصول إلى البيانات المنشورة والتحقق منها مباشرة. يمكنك بعد ذلك استخدام هذه البيانات لإجراء المعاملات بنفسك وتحديد صلاحية المعاملات والحالة النهائية للمجموعة بعد تلك المعاملات.
وبالتالي ، فإن شروط السلامة المتبقية هي خصائص النشاط ومقاومة إعادة التركيب. بالنسبة للأخير ، تعتمد العقد الكاملة على أدوات التحقق من السلسلة الأساسية وبروتوكول الإجماع الذي يستخدمونه ، بينما بالنسبة لخصائص الحيوية ، تعتمد العقد الكاملة على تطبيقات التسلسل والتجميع.
العميل الخفيف:
يستخدم معظم المستخدمين المحافظ المضمنة في العقد الخفيفة أو يستخدمون خدمات الجهات الخارجية للحصول على بيانات blockchain والتفاعل مع blockchain. يمكن أن تكون العقد الضوئية من أنواع مختلفة:
** State Validator - تحقق من صلاحية انتقالات الحالة ، **
** DA Validator - يتحقق من توفر البيانات ، **
** مدقق الإجماع - التحقق من صحة إثبات الإجماع للطبقة الأساسية ، أو **
** مدقق كامل - يتحقق من كل ما سبق **
إذا قمت بتشغيل عميل ضوئي كامل التحقق من الصحة ، فيمكنك التحقق من توفر البيانات من خلال أخذ عينات توفر البيانات ، ويمكنك التحقق من صحة انتقالات الحالة من خلال إثباتات الصلاحية أو إثباتات الاحتيال ، كما يمكنك التحقق من أن الحالة قد تم الانتهاء منها على القاعدة إجماع طبقة (على Ethereum ، يمكن القيام بذلك باتباع لجنة المزامنة).
عندئذٍ تكون حالة الأمان المتبقية هي خاصية التفعيل ، ويعتمد العملاء الخفيفون على تطبيقات التسلسل والتجميع.
العقد الذكي المدمج (جسر التحقق):
في SCR التقليدي ، "قاعدة التأكيد" للعقد الذكي هي فرض جميع خصائص الأمان الخمسة:
نمو دفتر الأستاذ من خلال بروتوكول استبدال جهاز التسلسل
مقاومة الرقابة بفرض الشمول
بناء مقاومة لإعادة التنظيم فقط فوق الحالة السابقة
يتم تحقيق توفر البيانات عن طريق إرسال DA في الطبقة الأساسية
التحقق من الصلاحية عن طريق إثبات الصلاحية / الغش
تعتمد عقد SCR الكاملة على العقود الذكية لفرض خصائص الفعالية. إنها "تمتص" مقاومة إعادة الهيكلة من الطبقة الأساسية.
تعتمد العقد الخفيفة على العقود الذكية لتعزيز خصائص الحيوية وامتصاص DA ومقاومة إعادة التنظيم من الطبقة الأساسية. يمكنهم التحقق من إثبات الصلاحية بأنفسهم أو عبر العقود الذكية.
إجماع SCR على اتباع السلسلة الأساسية المحددة في العقد الذكي.
** ماذا عن التراكمية السيادية؟ **
التراكمية السيادية ليس لديها عقود ذكية (جسور تحقق) لفرض شروط الصلاحية أو الفعالية. بدلاً من ذلك ، سيثبتون أنهم "يتدحرجون" إلى عقدة تراكمية في اتجاه مجرى النهر. لا تزال هذه العقد تمتص مقاومة DA و Reorg من الطبقة الأساسية.
تمامًا كما هو الحال في SCR ، في عقد التجميع السيادي ، تحتاج إلى بعض الآليات لفرض خاصية lability. لتحديد السلسلة المتعارف عليها ، اختاروا آليات مستقلة مثل بث البراهين من نظير إلى نظير.
ما علاقة كل هذا باللامركزية؟
سواء أكان ذلك تراكمًا ذكيًا للعقد أو تراكمًا سياديًا ، فإن خاصية التيسير تأتي من التنفيذ الصحيح للتجميع. كما رأينا أعلاه ، يجب أن يتضمن التنفيذ الصحيح للتجميع مكونين مهمين:
آليات الإدراج الإلزامي ، و
بروتوكول استبدال جهاز التسلسل
يساعد التضمين الإلزامي في بناء مقاومة الرقابة. تتيح هذه الآلية للمستخدمين "فرض تضمين" معاملاتهم مباشرة في الطبقة الأساسية. يمكن لأي مستخدم في مجموعة التحديثات عندئذٍ فرض الخروج مرة أخرى إلى الطبقة الأساسية بأموالهم. لذلك ، حتى إذا كانت هناك عقدة مجمعة مركزية واحدة للتجميع ، فلا يمكنها مراقبة المستخدمين طالما أن هناك آلية إنفاذ ناضجة في المكان.
لكن هل هذا كاف؟
حتى إذا تمكن المستخدمون من تسجيل الخروج ، فقد يعني هذا أنه إذا عاد معظم المستخدمين إلى المستوى 1 ، فلن يكون لدى المؤسسة الكثير من الحوافز لمواصلة العمل. أيضًا ، عادةً ما تتطلب آلية التضمين الإلزامي وقت انتظار طويل ويمكن أن يكون تنفيذها مكلفًا للغاية بالنسبة للمستخدم العادي. مقاومة الرقابة التي توفرها هذه الآلية ليست عملية تمامًا (أو في الوقت الفعلي). يمكننا أن نطلق على هذا الوضع "ضعف الرقابة".
** ثم لدينا سمة السمة النهائية - نمو دفتر الأستاذ **
إذا أصبح التجميع المركزي ضارًا ، فيمكنه إيقاف نمو سلسلة الملخص عن طريق إيقاف إنتاج الكتل ببساطة. إذا حدث هذا ، فلا يوجد شيء يمكن للمستخدم أو الشركة القيام به لجعل العرض الإجمالي "مباشرًا" مرة أخرى.
لحل هذه المشكلة ، نحتاج إلى بروتوكول استبدال جهاز التسلسل.
فكرة بروتوكول استبدال جهاز التسلسل هي أنه إذا كان جهاز التسلسل يتصرف بطريقة ضارة ، فيمكن للحوكمة الإجمالية بدء تشغيل جهاز التسلسل. تتمثل إحدى طرق تحقيق ذلك في استبدال عقد جهاز التسلسل المركزي ببروتوكول جهاز التسلسل اللامركزي. إذا كان فارز اللامركزية ولا يحتكر اللبنات الأساسية للتجميع ، فمن المستحيل تقريبًا إيقاف التجميع.
وبالتالي ، في حين أن أموال المستخدم تكون دائمًا آمنة في Rollups من خلال آلية التضمين الإلزامية ، فإن بناء بروتوكول قوي لاستبدال الطلبات يساعد على إبقاء Rollups حية ويوفر مقاومة عملية في الوقت الفعلي للرقابة.
هذا كل شيء؟
ليس تماما. من الناحية الفنية ، هناك جانب آخر يجب مراعاته:
ماذا لو كان من الممكن ترقية العقود الذكية نفسها من قبل لجنة مركزية مجمعة؟ لنفترض أن عمليات التجميع يتم تنفيذها حاليًا بشكل صحيح ، ولكن توافق اللجنة غدًا على أننا لم نعد بحاجة إلى عقود ذكية ، ولكننا بدلاً من ذلك نبث أدلة على حالة التجميع إلى شبكة p2p.
إذا كنت ، كمستخدم تراكمي ، لا توافق على مثل هذه الترقية ، فيجب أن تكون قادرًا على الخروج من التراكمية قبل تنفيذ الترقية (على الرغم من أن هذه ليست تجربة مستخدم جيدة وقد تكون سيئة للأعمال). يمكن تحقيق ذلك من خلال "تحديثات الحوكمة المتأخرة". إنها تشبه "فترة الإخطار" التي سيتم بعدها تنفيذ الترقية. يمكن للمستخدمين الذين لا يوافقون على التحديثات الانسحاب خلال فترة الإخطار.
أقصى درجات اللامركزية هو خيار الحصول على عقود ذكية غير قابلة للتغيير تمامًا. لا تخضع هذه العقود لأي محفظة متعددة التوقيعات أو لجنة أخرى ، وبمجرد نشرها لا يمكن ترقيتها أبدًا.
بالطبع ، هذا له مشاكله الخاصة. إذا كان هناك أي أخطاء في الكود ، أو كان هناك حدث كبير يتطلب تحديث العقد الذكي ، فإن الخيار الوحيد لعقدة التجميع هو الانقسام إلى العقد الذكي الجديد - مما يترك أموال المستخدم عالقة في العقد القديم.
الحالة الحالية
لسوء الحظ ، فإن الحالة الحالية لـ Rollup ليست قريبة من التنفيذ الكامل الذي ناقشناه أعلاه. لا تزال معظم القوائم في مرحلة "عجلات التدريب" ، تحاول تصحيحها.
وفقًا لـ L2BEAT ، يعتبر كل من Fuel v1 و DeGate هما الركام الوحيدان اللذان نضجا لتحقيق جميع شروط النشاط والسلامة.
3. الاقتصاد
لنلقِ نظرة على اقتصاديات التراكمية من منظور المستخدمين ومشغلي التراكمية:
** 1) تجربة المستخدم ** - يجب أن يحصل المستخدمون على أسعار رخيصة ولا يضطرون إلى الانتظار طويلاً لإجراء المعاملات
** 2) ربح التجميع ** - يجب أن يكون تشغيل التجميع وحاملي الرموز مربحًا
يتم تحسين تجربة المستخدم عندما يحصل المستخدمون على معاملات سريعة ورخيصة.
تعتمد السرعة التي يتم بها إنهاء المعاملات على السرعة التي يتم بها إنهاء كتل الطبقة الأساسية. يمكن اعتبار المعاملات نهائية كلما تم الانتهاء من البيانات على L1. ومع ذلك ، يمكن للمستخدمين الذين يشغلون العقد الكاملة أيضًا تحقيق النهاية الفورية من خلال تنفيذ المعاملات وتحديد الحالة النهائية.
لكن ليس من العملي للجميع تشغيل عقدة كاملة. لذلك ، تعتبر أداة المقارنة المركزية مفيدة لأنها يمكن أن توفر للمستخدمين "تأكيدًا بسيطًا" بأن معاملتهم مدرجة في كتلة وسيتم إنهاؤها. هذا كافٍ لمعظم حالات الاستخدام. ومع ذلك ، فإنه ينطوي على الاعتماد على حزب مركزي يمكنه العمل ضده.
بينما تتخلى بعض حلول البروتوكول البديلة لمنظم التسلسل (على سبيل المثال المستندة إلى Rollups) عن هذه الخاصية على حساب المستخدمين ، فإن الحلول الأخرى (مثل إجماع نقاط البيع الخارجية (مثل Espresso)) يمكن أن توفر ضمانات مماثلة للتأكيد المسبق دون تكبد المخاطر التالية: جهاز التسلسل المركزي.
يريد المسؤول المركزي الذي يتصرف بعقلانية دائمًا زيادة أرباحه إلى الحد الأقصى ، حتى لو كان ذلك يعني تمرير تكاليف أعلى إلى المستخدمين. ومع ذلك ، تجدر الإشارة إلى أنه لا يمكن حل ذلك بالضرورة عن طريق آلية فارز لامركزية. حتى عقد نقاط البيع في النظام اللامركزي تريد تعظيم أرباحها.
في الواقع ، هذا يخلق مشكلة عدم محاذاة حيث قد لا يرغب المجموع في تسليم الربح إلى فارز خارجي.
الربح التراكمي - بالإضافة إلى رسوم التسلسل ، يمكن أيضًا أن يحقق Rollup ربحًا عن طريق استخراج MEV من معاملات المستخدم بالجملة. غالبًا ما يكون من الصعب عزو هذا MEV لأنه من الصعب معرفة ما إذا كان مقدم الطلب قد قام بتضمين بعض المعاملات الخاصة به في الدفعة.
** إذا تم استبدال التراكمية بإجماع نقاط البيع الخارجية ، فسيعطون هذا MEV للمشغلين الخارجيين. **
وتجدر الإشارة إلى أنه يمكن حل كلتا مشكلتي التسهيلات المتراكمة للإيرادات إلى آليات خارجية من خلال "اتفاقيات التجارة" بين التراكميات والآليات الخارجية ، حيث يمكن حل الرسوم وقيمته المقدرة (MEV) الناتجة عن المعاملات الداخلية والمشتركة. يعيد التوجيه إلى الملخص.
ومع ذلك ، كما هو موضح في حديث Jon Charbonneau خلال Modular Summit والمنشورات اللاحقة ، قد تكون الفكرة الأفضل أن يكون لديك مندوب حوكمة تراكمي يأمر بمجموعة من العقد المرخصة. يمكن اختيار هذه العقد بشكل استراتيجي لتكون موزعة جغرافياً ، ويمكن للحوكمة ببساطة طرد الجهات الفاعلة السيئة.
** يمكن أن يكون هذا حلاً مكونًا من طائرين وحجر واحد ، لأنه يسمح للعروض التراكمية بالحفاظ على الهوامش في المنزل ، مع التخفيف أيضًا من الآثار السلبية للفرز المركزي. **
ولكن عكس ذلك هو أنه مع الدوران المحدود للفرز ، يمكن أن يكون للفرز سلوك غير قصير النظر ، مما قد يؤدي إلى احتكار التسعير / التلاعب بالأسعار على حساب مستخدمي التجميع.
في كلتا الحالتين ، من الواضح أن بعض بروتوكول استبدال جهاز التسلسل ضروري من أجل أن يكون التلخيص فعالاً من حيث التكلفة للمستخدمين. سواء كان ذلك دليلًا على الحوكمة ، أو آلية إجماع خارجية ، أو أي شيء آخر ، فهذه مناقشة لمقال آخر.
4. الخلاصة
نأمل أن يكون من الواضح الآن أنه مهما كان المسار الذي تتخذه Rollup ، فمن الأهمية بمكان أن يكون الهدف هو التنفيذ الكامل مع آليات ناضجة لاستبدال أداة الفرز ، والإدماج القسري ، وتحديثات إدارة التأخر. حتى لو كان مجرد تضمين إلزامي وتحديثات متأخرة ، فإن أموال المستخدمين تكون آمنة عند تنفيذ التراكمية بالكامل ، بغض النظر عما إذا كان المنسق مركزيًا أم لا.
ومع ذلك ، يمكن لبروتوكول استبدال جهاز التسلسل القوي أن يحسن ضمانات الفعالية ويحتمل أن يحسن اقتصاديات مستخدمي Rollup.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
شاهد أهمية اللامركزية التراكمية من ثلاثة جوانب
المؤلف: Shivanshu Madan ؛ المترجم: Huohuo / Vernacular Blockchain
تدور الكثير من المناقشات على تويتر مؤخرًا حول لامركزية اللغة الثانية. هل التراكميات التي نبنيها لامركزية بما فيه الكفاية؟ أم أنهم على الأقل على طريق اللامركزية؟ هل يهم؟
فكرة التراكمية بسيطة: نريد أن يكون المشاركون خارج السلسلة قادرين على إجراء المعاملات التي يمكن التحقق منها بسهولة على السلسلة. باستخدام Rollup ، تسمح الطبقة الأساسية باستخدام قاعدتها من "الثقة" في الأنشطة التي تحدث خارج مجالها المباشر. في المقابل ، يدفع التراكمي رسومًا رمزية (إيجار) للاستفادة من هذه الثقة.
فهل نحن بحاجة إلى التراكمية اللامركزية؟
الجواب البديهي هو نعم! هذه هي الروح التي نبني بها blockchain.
ومع ذلك ، أعتقد أن الإجابة على هذا السؤال ليست بسيطة بنعم أو لا. بدلاً من ذلك ، فإنه يحتوي على جوانب متعددة يجب تحليلها بشكل فردي. في الفصول التالية ، سأفصل هذا السؤال من ثلاث وجهات نظر: فلسفية ، وتكنولوجية ، واقتصادية. **** هذه الثلاثة ليست بالضرورة شاملة أو حصرية ، ولكن يجب أن تعطي منظورًا عامًا جيدًا للمشكلة. **
1. منظور فلسفي
لنبدأ بالارتقاء بالمحادثة إلى مستوى - لماذا نهتم باللامركزية؟
لأننا نريد مستقبلًا غير مرخص به يشجع الابتكار المفتوح. نريد أن يتمكن المستخدمون من بناء أشياء جديدة دون أي قيود ودون الحاجة إلى الوثوق بأي كيان واحد.
في التاريخ القصير لـ blockchain ، كان لدينا الكثير من المطورين المجهولين لبناء أشياء مذهلة. في الواقع ، تم إنشاء Bitcoin نفسها بواسطة كيان مجهول - قد تكون قريبًا العملة التي يستخدمها معظم الناس في العالم للمدفوعات العالمية! هذه هي قوة الابتكار غير المرخص!
يسمح لنا الأساس اللامركزي للشبكات غير الموثوقة مثل Bitcoin و Ethereum ببناء مثل هذا المستقبل. ثم من الواضح أن أي سلسلة لها علاقة ثقة مع هذه السلاسل ، مثل Rollups ، يجب أن تكون لامركزية أيضًا!
في الواقع ، إنه يثير سؤالًا مثيرًا للاهتمام ومهمًا:
** إذا لم يكن التراكمي لامركزيًا ، فهل هذا يعني أن Ethereum ليست لامركزية؟ **
هناك طريقة متفائلة إلى حد ما للنظر في هذا الأمر وهي أنه في عالم غير مرخص ، يجب السماح للمجموعات المجمعة ببناء أي شيء يريدونه ، بما في ذلك (على سبيل المثال لا الحصر) السلاسل المرخصة بالكامل - ويجب أن يظل مستخدمو مجموعة التحديثات هذه قادرين على الاستفادة من الأمان في طبقة القاعدة. يجب أن تكون السلاسل المرخصة آمنة للاستخدام طالما أن الطبقة الأساسية لا مركزية ويتم تنفيذ التجميع "بالكامل" (سنتحدث أكثر عن "تم التنفيذ الكامل" في القسم الفني).
لكن الحقيقة هي أن معظم التراكميات اليوم لم تصل بعد إلى مرحلة التنفيذ الكامل ، ولا توفر للمستخدمين المستوى المطلوب من الأمان وعدم الثقة.
إذن ، كيف يبدو التطبيق الصحيح للتجميع؟ دعنا نرى:
2. التكنولوجيا
لفهم مسألة اللامركزية والأمان حقًا على مستوى التراكمية ، نحتاج إلى النظر إليها من المبادئ الأولى. لا يستطيع الكثير من الناس شرح المبادئ الأولى لـ blockchain أفضل من Sreeram Kannan.
blockchain عبارة عن دفتر أستاذ موزع حيث تتبع العقد المختلفة في الشبكة بروتوكولًا محددًا للحصول على إجماع حول حالة دفتر الأستاذ. اعتمادًا على كيفية رؤية هذه العقد للشبكة ، يمكن أن يكون لها قواعد مختلفة لتأكيد الحالة الصحيحة للشبكة في دفتر الأستاذ الخاص بها.
على سبيل المثال ، في بروتوكول Gasper الخاص بـ Ethereum ، هناك قاعدتان مختلفتان للتأكيد - القاعدة المتاحة (بناءً على السلسلة الأثقل) والقاعدة النهائية (بناءً على الكتل التي أكدتها الأداة الذكية).
خاصة في المجموعات ، العقد الكاملة لها قواعد تأكيد مختلفة عن العملاء الخفيفين. في مجموعة العقود الذكية التقليدية (SCR) ، يحتوي العقد الذكي (جسر التحقق) على قواعد التأكيد الخاصة به. إذا لم تكن هناك أحداث سلبية ، فإن قواعد التأكيد هذه تتوافق في النهاية مع ما يسمى "مناطق التناسق". كما يوحي الاسم ، في مناطق الإجماع ، يكون لجميع المشاركين نفس وجهة نظر الشبكة (ولهم نفس التاريخ في دفاتر الأستاذ الخاصة بهم).
إذا كانت جميع قواعد التأكيد آمنة ، فلن تحدث أشياء سيئة. نظرًا لأن Sreeram شارك في المنشور أعلاه ، فإن 5 خصائص تحدد بشكل أساسي أمان قواعد التأكيد هذه.
تحدد الخصائص الأولى والثانية معًا الحالة "الحية" للنظام ، بينما تحدد الخصائص الثلاثة الأخيرة الحالة "الآمنة".
دعونا نلقي نظرة على كل منها من منظور مختلف الجهات الفاعلة في التجميع ومعرفة أي منها يمكن تخفيفه دون اللامركزية.
تعتمد الجهات الفاعلة المختلفة على آليات مختلفة للسلامة والحيوية
العقدة الكاملة:
إذا قمت بتشغيل عقدة كاملة ، يمكنك الوصول إلى البيانات المنشورة والتحقق منها مباشرة. يمكنك بعد ذلك استخدام هذه البيانات لإجراء المعاملات بنفسك وتحديد صلاحية المعاملات والحالة النهائية للمجموعة بعد تلك المعاملات.
وبالتالي ، فإن شروط السلامة المتبقية هي خصائص النشاط ومقاومة إعادة التركيب. بالنسبة للأخير ، تعتمد العقد الكاملة على أدوات التحقق من السلسلة الأساسية وبروتوكول الإجماع الذي يستخدمونه ، بينما بالنسبة لخصائص الحيوية ، تعتمد العقد الكاملة على تطبيقات التسلسل والتجميع.
العميل الخفيف:
يستخدم معظم المستخدمين المحافظ المضمنة في العقد الخفيفة أو يستخدمون خدمات الجهات الخارجية للحصول على بيانات blockchain والتفاعل مع blockchain. يمكن أن تكون العقد الضوئية من أنواع مختلفة:
إذا قمت بتشغيل عميل ضوئي كامل التحقق من الصحة ، فيمكنك التحقق من توفر البيانات من خلال أخذ عينات توفر البيانات ، ويمكنك التحقق من صحة انتقالات الحالة من خلال إثباتات الصلاحية أو إثباتات الاحتيال ، كما يمكنك التحقق من أن الحالة قد تم الانتهاء منها على القاعدة إجماع طبقة (على Ethereum ، يمكن القيام بذلك باتباع لجنة المزامنة).
عندئذٍ تكون حالة الأمان المتبقية هي خاصية التفعيل ، ويعتمد العملاء الخفيفون على تطبيقات التسلسل والتجميع.
العقد الذكي المدمج (جسر التحقق):
في SCR التقليدي ، "قاعدة التأكيد" للعقد الذكي هي فرض جميع خصائص الأمان الخمسة:
تعتمد عقد SCR الكاملة على العقود الذكية لفرض خصائص الفعالية. إنها "تمتص" مقاومة إعادة الهيكلة من الطبقة الأساسية.
تعتمد العقد الخفيفة على العقود الذكية لتعزيز خصائص الحيوية وامتصاص DA ومقاومة إعادة التنظيم من الطبقة الأساسية. يمكنهم التحقق من إثبات الصلاحية بأنفسهم أو عبر العقود الذكية.
إجماع SCR على اتباع السلسلة الأساسية المحددة في العقد الذكي.
** ماذا عن التراكمية السيادية؟ **
التراكمية السيادية ليس لديها عقود ذكية (جسور تحقق) لفرض شروط الصلاحية أو الفعالية. بدلاً من ذلك ، سيثبتون أنهم "يتدحرجون" إلى عقدة تراكمية في اتجاه مجرى النهر. لا تزال هذه العقد تمتص مقاومة DA و Reorg من الطبقة الأساسية.
تمامًا كما هو الحال في SCR ، في عقد التجميع السيادي ، تحتاج إلى بعض الآليات لفرض خاصية lability. لتحديد السلسلة المتعارف عليها ، اختاروا آليات مستقلة مثل بث البراهين من نظير إلى نظير.
ما علاقة كل هذا باللامركزية؟
سواء أكان ذلك تراكمًا ذكيًا للعقد أو تراكمًا سياديًا ، فإن خاصية التيسير تأتي من التنفيذ الصحيح للتجميع. كما رأينا أعلاه ، يجب أن يتضمن التنفيذ الصحيح للتجميع مكونين مهمين:
آليات الإدراج الإلزامي ، و
بروتوكول استبدال جهاز التسلسل
يساعد التضمين الإلزامي في بناء مقاومة الرقابة. تتيح هذه الآلية للمستخدمين "فرض تضمين" معاملاتهم مباشرة في الطبقة الأساسية. يمكن لأي مستخدم في مجموعة التحديثات عندئذٍ فرض الخروج مرة أخرى إلى الطبقة الأساسية بأموالهم. لذلك ، حتى إذا كانت هناك عقدة مجمعة مركزية واحدة للتجميع ، فلا يمكنها مراقبة المستخدمين طالما أن هناك آلية إنفاذ ناضجة في المكان.
لكن هل هذا كاف؟
حتى إذا تمكن المستخدمون من تسجيل الخروج ، فقد يعني هذا أنه إذا عاد معظم المستخدمين إلى المستوى 1 ، فلن يكون لدى المؤسسة الكثير من الحوافز لمواصلة العمل. أيضًا ، عادةً ما تتطلب آلية التضمين الإلزامي وقت انتظار طويل ويمكن أن يكون تنفيذها مكلفًا للغاية بالنسبة للمستخدم العادي. مقاومة الرقابة التي توفرها هذه الآلية ليست عملية تمامًا (أو في الوقت الفعلي). يمكننا أن نطلق على هذا الوضع "ضعف الرقابة".
** ثم لدينا سمة السمة النهائية - نمو دفتر الأستاذ **
إذا أصبح التجميع المركزي ضارًا ، فيمكنه إيقاف نمو سلسلة الملخص عن طريق إيقاف إنتاج الكتل ببساطة. إذا حدث هذا ، فلا يوجد شيء يمكن للمستخدم أو الشركة القيام به لجعل العرض الإجمالي "مباشرًا" مرة أخرى.
لحل هذه المشكلة ، نحتاج إلى بروتوكول استبدال جهاز التسلسل.
فكرة بروتوكول استبدال جهاز التسلسل هي أنه إذا كان جهاز التسلسل يتصرف بطريقة ضارة ، فيمكن للحوكمة الإجمالية بدء تشغيل جهاز التسلسل. تتمثل إحدى طرق تحقيق ذلك في استبدال عقد جهاز التسلسل المركزي ببروتوكول جهاز التسلسل اللامركزي. إذا كان فارز اللامركزية ولا يحتكر اللبنات الأساسية للتجميع ، فمن المستحيل تقريبًا إيقاف التجميع.
وبالتالي ، في حين أن أموال المستخدم تكون دائمًا آمنة في Rollups من خلال آلية التضمين الإلزامية ، فإن بناء بروتوكول قوي لاستبدال الطلبات يساعد على إبقاء Rollups حية ويوفر مقاومة عملية في الوقت الفعلي للرقابة.
هذا كل شيء؟
ليس تماما. من الناحية الفنية ، هناك جانب آخر يجب مراعاته:
ماذا لو كان من الممكن ترقية العقود الذكية نفسها من قبل لجنة مركزية مجمعة؟ لنفترض أن عمليات التجميع يتم تنفيذها حاليًا بشكل صحيح ، ولكن توافق اللجنة غدًا على أننا لم نعد بحاجة إلى عقود ذكية ، ولكننا بدلاً من ذلك نبث أدلة على حالة التجميع إلى شبكة p2p.
إذا كنت ، كمستخدم تراكمي ، لا توافق على مثل هذه الترقية ، فيجب أن تكون قادرًا على الخروج من التراكمية قبل تنفيذ الترقية (على الرغم من أن هذه ليست تجربة مستخدم جيدة وقد تكون سيئة للأعمال). يمكن تحقيق ذلك من خلال "تحديثات الحوكمة المتأخرة". إنها تشبه "فترة الإخطار" التي سيتم بعدها تنفيذ الترقية. يمكن للمستخدمين الذين لا يوافقون على التحديثات الانسحاب خلال فترة الإخطار.
أقصى درجات اللامركزية هو خيار الحصول على عقود ذكية غير قابلة للتغيير تمامًا. لا تخضع هذه العقود لأي محفظة متعددة التوقيعات أو لجنة أخرى ، وبمجرد نشرها لا يمكن ترقيتها أبدًا.
بالطبع ، هذا له مشاكله الخاصة. إذا كان هناك أي أخطاء في الكود ، أو كان هناك حدث كبير يتطلب تحديث العقد الذكي ، فإن الخيار الوحيد لعقدة التجميع هو الانقسام إلى العقد الذكي الجديد - مما يترك أموال المستخدم عالقة في العقد القديم.
الحالة الحالية
لسوء الحظ ، فإن الحالة الحالية لـ Rollup ليست قريبة من التنفيذ الكامل الذي ناقشناه أعلاه. لا تزال معظم القوائم في مرحلة "عجلات التدريب" ، تحاول تصحيحها.
وفقًا لـ L2BEAT ، يعتبر كل من Fuel v1 و DeGate هما الركام الوحيدان اللذان نضجا لتحقيق جميع شروط النشاط والسلامة.
3. الاقتصاد
لنلقِ نظرة على اقتصاديات التراكمية من منظور المستخدمين ومشغلي التراكمية:
** 1) تجربة المستخدم ** - يجب أن يحصل المستخدمون على أسعار رخيصة ولا يضطرون إلى الانتظار طويلاً لإجراء المعاملات
** 2) ربح التجميع ** - يجب أن يكون تشغيل التجميع وحاملي الرموز مربحًا
يتم تحسين تجربة المستخدم عندما يحصل المستخدمون على معاملات سريعة ورخيصة.
تعتمد السرعة التي يتم بها إنهاء المعاملات على السرعة التي يتم بها إنهاء كتل الطبقة الأساسية. يمكن اعتبار المعاملات نهائية كلما تم الانتهاء من البيانات على L1. ومع ذلك ، يمكن للمستخدمين الذين يشغلون العقد الكاملة أيضًا تحقيق النهاية الفورية من خلال تنفيذ المعاملات وتحديد الحالة النهائية.
لكن ليس من العملي للجميع تشغيل عقدة كاملة. لذلك ، تعتبر أداة المقارنة المركزية مفيدة لأنها يمكن أن توفر للمستخدمين "تأكيدًا بسيطًا" بأن معاملتهم مدرجة في كتلة وسيتم إنهاؤها. هذا كافٍ لمعظم حالات الاستخدام. ومع ذلك ، فإنه ينطوي على الاعتماد على حزب مركزي يمكنه العمل ضده.
بينما تتخلى بعض حلول البروتوكول البديلة لمنظم التسلسل (على سبيل المثال المستندة إلى Rollups) عن هذه الخاصية على حساب المستخدمين ، فإن الحلول الأخرى (مثل إجماع نقاط البيع الخارجية (مثل Espresso)) يمكن أن توفر ضمانات مماثلة للتأكيد المسبق دون تكبد المخاطر التالية: جهاز التسلسل المركزي.
ماذا عن التكلفة التي يتحملها المستخدم؟
عادةً ما يكون السعر الصريح لمعاملة التجميع هو:
** تكلفة غاز L2 = تكلفة غاز L1 + رسوم جهاز التسلسل **
يريد المسؤول المركزي الذي يتصرف بعقلانية دائمًا زيادة أرباحه إلى الحد الأقصى ، حتى لو كان ذلك يعني تمرير تكاليف أعلى إلى المستخدمين. ومع ذلك ، تجدر الإشارة إلى أنه لا يمكن حل ذلك بالضرورة عن طريق آلية فارز لامركزية. حتى عقد نقاط البيع في النظام اللامركزي تريد تعظيم أرباحها.
في الواقع ، هذا يخلق مشكلة عدم محاذاة حيث قد لا يرغب المجموع في تسليم الربح إلى فارز خارجي.
الربح التراكمي - بالإضافة إلى رسوم التسلسل ، يمكن أيضًا أن يحقق Rollup ربحًا عن طريق استخراج MEV من معاملات المستخدم بالجملة. غالبًا ما يكون من الصعب عزو هذا MEV لأنه من الصعب معرفة ما إذا كان مقدم الطلب قد قام بتضمين بعض المعاملات الخاصة به في الدفعة.
** إذا تم استبدال التراكمية بإجماع نقاط البيع الخارجية ، فسيعطون هذا MEV للمشغلين الخارجيين. **
وتجدر الإشارة إلى أنه يمكن حل كلتا مشكلتي التسهيلات المتراكمة للإيرادات إلى آليات خارجية من خلال "اتفاقيات التجارة" بين التراكميات والآليات الخارجية ، حيث يمكن حل الرسوم وقيمته المقدرة (MEV) الناتجة عن المعاملات الداخلية والمشتركة. يعيد التوجيه إلى الملخص.
ومع ذلك ، كما هو موضح في حديث Jon Charbonneau خلال Modular Summit والمنشورات اللاحقة ، قد تكون الفكرة الأفضل أن يكون لديك مندوب حوكمة تراكمي يأمر بمجموعة من العقد المرخصة. يمكن اختيار هذه العقد بشكل استراتيجي لتكون موزعة جغرافياً ، ويمكن للحوكمة ببساطة طرد الجهات الفاعلة السيئة.
** يمكن أن يكون هذا حلاً مكونًا من طائرين وحجر واحد ، لأنه يسمح للعروض التراكمية بالحفاظ على الهوامش في المنزل ، مع التخفيف أيضًا من الآثار السلبية للفرز المركزي. **
ولكن عكس ذلك هو أنه مع الدوران المحدود للفرز ، يمكن أن يكون للفرز سلوك غير قصير النظر ، مما قد يؤدي إلى احتكار التسعير / التلاعب بالأسعار على حساب مستخدمي التجميع.
في كلتا الحالتين ، من الواضح أن بعض بروتوكول استبدال جهاز التسلسل ضروري من أجل أن يكون التلخيص فعالاً من حيث التكلفة للمستخدمين. سواء كان ذلك دليلًا على الحوكمة ، أو آلية إجماع خارجية ، أو أي شيء آخر ، فهذه مناقشة لمقال آخر.
4. الخلاصة
نأمل أن يكون من الواضح الآن أنه مهما كان المسار الذي تتخذه Rollup ، فمن الأهمية بمكان أن يكون الهدف هو التنفيذ الكامل مع آليات ناضجة لاستبدال أداة الفرز ، والإدماج القسري ، وتحديثات إدارة التأخر. حتى لو كان مجرد تضمين إلزامي وتحديثات متأخرة ، فإن أموال المستخدمين تكون آمنة عند تنفيذ التراكمية بالكامل ، بغض النظر عما إذا كان المنسق مركزيًا أم لا.
ومع ذلك ، يمكن لبروتوكول استبدال جهاز التسلسل القوي أن يحسن ضمانات الفعالية ويحتمل أن يحسن اقتصاديات مستخدمي Rollup.