بالإضافة إلى Validity Rollup و Optimistic Rollup ، ما هي طرق تصنيف التراكم المختلفة؟
** بقلم: NIC Lin **
علم مسبق:
تعرّف على كيفية عمل "مجموعة التحديثات" ومشكلة توفر البيانات (توفر البيانات) في "مجموعة التحديثات"
خلاصة على التراكمي
بغض النظر عما إذا كانت مجموعة Validity أو Optimistic Rollup ، فسوف يقومون بتحميل البيانات إلى L1 (مثل Ethereum) ، بحيث يمكن للجميع الوصول إلى بيانات Rollup عن طريق الوصول إلى L1 ، واستخدامها لاشتقاق أحدث حالة من Rollup ، مثل لدى أليس 10 دولارات أمريكية و 5 دولارات أمريكية لبوب.
أولئك الذين لا يقومون بتحميل البيانات إلى L1 لا ينتمون إلى Rollup (مثل Validium أو zkPorter أو Arbitrum AnyTrust) ، وهم ليسوا موضوع هذه المقالة. بالإضافة إلى ذلك ، لن تناقش هذه المقالة كيفية التحقق التراكمي من صحة الحالة ، أي الفرق بين Validity Rollup و Optimistic Rollup.
سيقدم الجزء الأول من هذه المقالة مجموعة السيادية التراكمية. التراكمية السيادية ، كما يوحي اسمها ، هي تراكمية تتمتع بالاستقلالية. تحدث جميع ترقيات إصدار التراكم أو الهارد فورك على Sovereign Rollups ، على عكس Rollups التي يعرفها الجميع الآن (يشار إليها فيما يلي باسم Classic Rollups). موقع الشوكة هو ليس في Classic Rollup ، ولكن على عقد L1 Rollup: ينفذ عقد L1 Rollup ترقيات الإصدار من خلال محافظ متعددة التوقيع أو تصويت الحوكمة. أي أن العقد على L1 يحدد الإصدار الذي يجب أن تستخدمه مجموعة التحديثات في الوقت الحالي. وإذا كان هناك هجوم على Rollup في L1 ، مثل مهاجمة آلية الحوكمة أو مهاجمة عقد Rollup نفسه ، فسوف تتأثر Rollup. على العكس من ذلك ، نظرًا لأن Sovereign Rollup يعتبر L1 ببساطة مكانًا لتخزين البيانات ، يمكن لجميع أعضاء Sovereign Rollup تحديد الإصدار الذي يجب استخدامه حاليًا ضمن السلسلة ، وبغض النظر عما يحدث لـ L1 ، طالما أن L1 نفسها لم تتعرض للهجوم (مثل كإعادة تنظيم أو إيقاف تشغيل متسلسل) ، لن يتأثر التراكم السيادي.
سيقدم الجزء الثاني المستند إلى التراكمية. يزيل المستند التراكمي دور جهاز التسلسل ، ويسلم قوة فرز المعاملات إلى عمال المناجم L1 ، والمدققين ، وباحثي MEV ، وما إلى ذلك. فهو لا يجعل معاملات الفرز أكثر لامركزية فحسب ، بل إنه يبسط التصميم ويزيل العديد من مكونات النظام.
التراكمية السيادية
طبقة توافر البيانات وطبقة التسوية
التراكمية الكلاسيكية مثل Arbitrum ، و Optimism ، و StarkNet ، وما إلى ذلك ، لا تعتبر فقط Ethereum (L1) مكانًا لتخزين البيانات (أي طبقة توفر البيانات) ، ولكنها تعتبر أيضًا Ethereum طبقة تسوية في نفس الوقت: التسوية هي يتم إجراؤها على Ethereum ، وحالة L2 هي (أي رصيد كل عنوان في L2) تتم كتابتها إلى L1.
لماذا تحتاج إلى كتابة حالة L2 إلى L1؟ لأنه بهذه الطريقة ، يمكن لـ L2 و L1 تبادل المعلومات والأصول: يمكن لـ L1 / L2 dApps مزامنة المعلومات والتعاون ، ويمكن نقل L1's ETH بأمان بين L1 / L2 ، ويمكن أيضًا نقل ARB / OP الخاص بـ L2 بأمان بين L1 / L2. النقل بين L2.
يمكن لـ L1 قراءة حالة L2 ، ويمكنه نقل الرسائل بأمان ، ويمكن لـ L1 / L2 التواصل مع بعضهما البعض *
يزيل التراكم السيادي طبقة التسوية (أو يحول نفسه إلى طبقة تسوية) ، ويستخدم ببساطة L1 كطبقة إتاحة البيانات.
يقرأ L1 فقط الكتلة أو بيانات المعاملة التي يضعها Sovereign Rollup في L1 ، لكنه لا يعرف آخر حالة لـ L2 ، لذلك لا توجد طريقة للتواصل *
لماذا إزالة طبقة التسوية؟ هناك أسباب أو أسباب مختلفة:
كما ذكرنا في البداية ، إذا كانت طبقة تسوية Rollup في L1 ، فسوف تتأثر بـ L1 ، سواء تمت ترقيتها أو مهاجمتها
ربما لا يدعم L1 نفسه العمليات الحسابية المعقدة لتسجيل حالة التجميع واستخدام هذه الحالة لتوصيل أصول المعلومات. على سبيل المثال ، في Celestia ، يمكنك فقط وضع البيانات عليها ، أو على Bitcoin ، يمكنك فقط إجراء العمليات الحسابية بقدرات محدودة ، ولا يمكن أن يصبح هذا المستوى 1 طبقة تسوية
ربما لا تحتاج مجموعة التحديثات نفسها إلى سلسلة أخرى مثل طبقة التسوية ، فلها رموزها المميزة وبيئتها الأصلية ، ولا تحتاج إلى تبادل الأصول مع L1
كيف يعمل التراكم السيادي
يستخدم Sovereign Rollup ببساطة L1 كطبقة إتاحة البيانات ، ويقوم بتحميل البيانات إلى L1 ، ويعتمد على L1 لضمان توفر البيانات ولن يتغير ترتيب البيانات. تعتمد عقد التجميع السيادية على قراءة البيانات الموجودة على L1 وتفسيرها لحساب أحدث حالة من التجميع السيادي. يمثل "التفسير والحساب" في الواقع قواعد الإجماع الخاصة بالتجميع السيادي ووظيفة انتقال الحالة: كيفية تصفية الكتل والمعاملات التي تتوافق مع تنسيق التجميع السيادي والقواعد من بيانات L1 ، وكيفية التحقق من هذه الكتل والمعاملات بعد الفرز ، ثم التحقق من كيفية تنفيذ هذه المعاملات لحساب أحدث حالة.
تقوم عقدة Sovereign Rollup بشطب كتلها الخاصة من بيانات L1 ، وتفسر وتحسب أحدث حالة *
إذا كانت العقدتان السياديتان من إصدارات مختلفة ، فيمكنهما تفسير بيانات مختلفة أو حساب حالات حديثة مختلفة ، وبالتالي لن تكون هاتان العقدتان على نفس السلسلة ، فما تراهما هو في الواقع واحدة من سلسلتين متشعبتين.
قد تحصل الإصدارات المختلفة من العقد على حالات مختلفة ، ويتم تقسيمها إلى سلاسل مختلفة *
هذا هو في الواقع نفس تشغيل إصدارات مختلفة من عقد Ethereum ، قد لا يكون الإصداران نفس السلسلة. على سبيل المثال ، بعد الهارد فورك ، أولئك الذين ينسون تحديث إصدار العقدة أو لا يرغبون في تحديث إصدار العقدة سيبقون بشكل طبيعي في السلسلة الأصلية (مثل ETC ، ETHPoW) ، بينما أولئك الذين يقومون بتحديث إصدار العقدة سيكونون على سلسلة جديدة (ETH).
يجب أن يعرف القراء هنا أيضًا سبب تسميته التراكمية السيادية ، لأنه في Sovereign Rollup ، يمكن للجميع اختيار إصدار العقدة وتفسير البيانات وفقًا للإجماع (الاجتماعي) لمجموعتهم الخاصة. إذا كان هناك خلاف في مجتمع Sovereign Rollup اليوم مثل ETHPoW vs ETH ، فهذا يعني أن كل شخص يسلك طريقه الخاص ويختار إصدارات مختلفة من العقد لتفسير البيانات ، لكن البيانات لا تزال هي الأصل ولم تتغير.
ملاحظة: بالطبع ، بعد الانقسام ، ستقوم العقد الخاصة بإصداراتها الخاصة بتحميل البيانات التي تتوافق مع قواعدها الخاصة إلى L1 ، ثم يقوم كلا الجانبين بتصفية البيانات التي تم تحميلها من قبل الطرف الآخر مباشرة. *
في منتصف الوقت ، تم تقسيم العقد التالية إلى الإصدار v1.1.2 ، ثم كانت كتل بعضها البعض مستقلة *
ما هي التراكمية السيادية الموجودة؟
لا توجد حاليًا أمثلة على التراكمية السيادية ، ولكن نظرًا لأن اتجاه التصميم المعياري لـ blockchain أصبح أكثر شيوعًا ، سيكون هناك بالتأكيد العديد من التراكميات السيادية. على سبيل المثال ، يمكن للإطار المعياري Rollkit الذي تصممه Celestia إنشاء مجموعة Sovereign Rollup من خلال Cosmos SDK. على عكس السلسلة الأصلية (L1) التي تم إنشاؤها باستخدام Cosmos SDK ، والتي ستحتاج إلى تنفيذ إجماع Tendermint لتحديد ترتيب المعاملات ، يمكن لـ Sovereign Rollup استخدام متسلسل واحد لفرز المعاملات مثل التجميع الحالي المشترك ، مما يلغي الحاجة إلى إجماع متعدد العقد والاعتماد على مخاوفها الأمنية والموارد المستهلكة لتنفيذ خوارزمية الإجماع. ويقوم Sovereign Rollup بتحميل بيانات المعاملة إلى Celestia ، ولكن في نفس الوقت ، نظرًا لأنه عبارة عن تراكم سيادي ، فلن يتأثر بـ L1 (مثل الترقية أو التعرض للهجوم).
الملاحظة 1: دعم Rollkit لاحقًا أيضًا استخدام Bitcoin كطبقة توفر البيانات.يمكن لمثل هذه المجموعة أن ترث أمان Bitcoin ولكن الإنتاجية ستقتصر على Bitcoin. *
ملاحظة 2: في الأساس ، يمكن تسمية السلاسل القائمة على Celestia باسم Sovereign Rollup. *
أو افترض أن Arbitrum لم تعد تستخدم Ethereum كطبقة تسوية ، ولم تعد بحاجة إلى تبادل المعلومات أو الأصول مع Ethereum ، واعتبرت Ethereum ببساطة مكانًا لتخزين البيانات ، ثم ستصبح Arbitrum أيضًا مجموعة Sovereign Rollup.
تجميع التسوية
هناك أيضًا تعريفات مثل مجموعة التسوية ، ولكنها في الأساس عبارة عن تراكم سيادي ، ومن ثم ستكون هذه المجموعة السيادية أيضًا طبقة التسوية للسلاسل الأخرى. وهذا يعني ، إذا كانت هناك سلاسل أخرى في مجموعة السيادية ، واعتبرتها مجموعات أخرى على أنها طبقة تسوية ، فيمكن تسمية مجموعة التراكمية السيادية هذه بمجموعة التسوية التراكمية.
ملاحظة: لكي تصبح طبقة التسوية للسلاسل الأخرى ، يجب أن تتمتع بوظائف العقد الذكية الأساسية ، بحيث يمكن للجانبين تبادل المعلومات والأصول. *
إذا تم تغيير Ethereum لتحميل جميع معلومات السلسلة إلى Celestia اليوم ، فسيكون هذا Ethereum عبارة عن تراكم سيادي على Celestia ، وسيكون أيضًا مجموعة تسوية ، نظرًا لوجود العديد من السلاسل على Ethereum ، ويعتبرها العديد من Rollups طبقة تسوية .
Ethereum هو التجميع السيادي على Celestia وكذلك التسوية التراكمية *
ملاحظة: ربما في المستقبل ، سيتعرف الجميع تدريجيًا على الوحدات النمطية ووظائف الطبقات المختلفة ، ولن يبدأوا من منظور التراكمية ، وستختفي المصطلحات مثل التجميع السيادي أو مجموعة التسوية تدريجياً. على أي حال ، الشيء المهم هو كيفية تصميم سلسلتك (سواء كانت L1 أو L2 أو L3 وما إلى ذلك) ، وكيفية إجراء المقايضات واختيار أدوات البناء المناسبة لطبقات مختلفة.
القائمة التراكمية
ظهر تصنيف تراكمي آخر مؤخرًا هو Based Rollup ، أو يُعرف باسم L1-Sequenced Rollup. يشير المستند المستند إلى التجميع إلى معاملات الفرز. لا يتم تسليم التجميع إلى جهاز التسلسل (أو أجهزة التسلسل المتعددة) لفرز المعاملات ، ولكن يتم تسليمه بالكامل إلى عمال المناجم L1 أو المدققين أو الباحثين عن MEV ، وما إلى ذلك لفرز المعاملات. عندما يقوم Classic Rollup بتحميل البيانات إلى L1 ، فإن عقد L1 Rollup سيتحقق مما إذا كان قد تم تحميله بواسطة مُسلسِل مؤهل ، بينما لا توجد قيود على Based Rollup ويمكن لأي شخص تحميله.
يمكن لأي شخص تحميل كتل من التراكمية القائمة *
أكبر ميزة لـ Based Rollup هي أنه لا يوجد جهاز التسلسل ، لذلك لا توجد نقطة واحدة للفشل أو حتى تحتاج إلى القلق بشأن حصول Sequencer على قوة طلب معاملات كاملة ، أي أنه لا داعي للقلق بشأن تعطل جهاز التسلسل والتسبب في إيقاف تشغيل السلسلة أو عدم قبول المعاملات عمدًا من مستخدمين محددين ، أو القلق من أن يلتقط جهاز التسلسل MEV الخاص بالمستخدم بشكل ضار. يرث التراكم القائم تمامًا درجة اللامركزية في L1 في إنشاء الكتلة.
يحتوي Based Rollup على المزايا التالية:
التكلفة التي يتكبدها المستخدمون لمغادرة Rollup منخفضة جدًا
بشكل عام ، ستصمم Rollup آلية Force Inclusion أو آلية Escape Hatch بحيث يمكن للمستخدمين تثبيت أنفسهم مباشرةً في L1 دون استخدام Sequencer من أجل منع Sequencer عن قصد عدم قبول معاملات مستخدم معينة أو انقطاعات التسلسل التي تمنع المستخدمين من مغادرة Rollup. المعاملات في كتلة L2. ومع ذلك ، فإن التكلفة الأولى لمثل هذا التصميم هي تكلفة عالية. يتعين على المستخدمين دفع رسوم L1 لإدخال المعاملات. والتكلفة الثانية هي أن المعاملات المدرجة من L1 قد تؤثر على عملية حزم Sequencer L2: من الممكن أن L1 سوف يؤدي إدراج المعاملة إلى إبطال المعاملة التي ينوي جهاز التسلسل جمعها في كتلة L2. على سبيل المثال ، تحول المعاملة التي أدخلتها Alice في L1 كل الأموال إلى Bob ، مما أدى إلى فشل المعاملة التي تقوم فيها Alice بتحويل الأموال إلى Carol في كتلة L2.
بعد استلام معاملة Alice ، يؤكد Sequencer نتيجة المعاملة ويضعها في الكتلة التالية *
لكن Alice ترسل معاملة أخرى مباشرة إلى L1 من خلال Force Inclusion ، مما يتسبب في فشل معاملة Alice التي يتلقاها Sequencer *
من أجل منع المعاملة التي تم إدراجها بواسطة L1 من التأثير على عملية حزم L2 لتعبئة Sequencer ، لن يتم تفعيل Arbitrum على الفور عندما تحتاج المعاملة التي تم إدراجها بواسطة L1 إلى انتظار Sequencer لتقديم طلب فعال للمعاملة ليتم تضمينها في أحدث كتلة قبل سيصبح ساري المفعول ، أو إذا لم يستجب Sequencer ، فسيصبح ساري المفعول بعد فترة من الزمن. التفاؤل يسمح للمعاملة أن تصبح سارية المفعول على الفور.إذا كانت المعاملة التي تم إدراجها بواسطة L1 تؤثر على المعاملة في كتلة L2 ، فيجب على Sequencer إيجاد طريقة للتعامل معها. يمكنك قراءة هذه المقدمة لمعرفة المزيد حول المقارنة بين Arbitrum و Optimism في معالجة معاملات تحديد المستوى L1.
تصميم أبسط بكثير
دور Rollup المستندة أقل من دور Sequencer من Rollup العام ، مما يعني عبء أقل على الأجهزة (لا داعي للقلق بشأن تحميل آلة Sequencer) وأي آلية لجعل معاملات الطلب أكثر عدلاً (مثل آلية Sequencer اللامركزية). ثم ليست هناك حاجة لآلية Force Inclusion / Escape Hatch ، بما في ذلك العقود ذات الصلة بـ L1 والأدوات خارج السلسلة ذات الصلة لتسهيل قيام المستخدمين بوضع المعاملات في L1 بأنفسهم.
لكن Based Rollup له أيضًا بعض العيوب:
لا توجد خدمة تأكيد المعاملات مقدمًا
باستخدام Sequencer ، يمكن لـ Sequencer إخبار المستخدم بسرعة نتيجة تنفيذ معاملته. طالما أن المستخدم يثق في جهاز التسلسل ، يمكن تأكيد نتيجة المعاملة على الفور دون انتظار تحميل المعاملة إلى L1.
في Based Rollup ، تنتظر Alice حتى يتم تحميل المعاملة إلى L1 قبل أن تعتقد أن معاملتها مضمنة ، وعليها الانتظار حتى كتلة L1 واحدة على الأقل *
بشكل عام تراكمي ، إذا اعتقدت أليس أن جهاز التسلسل سيقبل معاملتها ، فيمكنها على الفور تأكيد ما إذا كان سيتم قبول المعاملة أم لا.
بروتوكول يفقد مصدر إيرادات MEV
لم يعد يتم تسليم MEV إلى Sequencer لفحصها واستخراجها ، ولكن إلى L1 ، لذلك لا يوجد لدى L2 نفسها طريقة للحصول على مزايا MEV. يمكن الحصول على إيرادات MEV من خلال تصميم آلية تقديم العطاءات لحقوق إنتاج الكتلة ، ولكنها ستزيد نسبيًا من الحد الأدنى للمشاركة في إنتاج الكتلة ، مما سيقلل من درجة اللامركزية ، وسيؤدي إدخال آلية تقديم العطاءات أيضًا إلى زيادة درجة معينة من التعقيد.
مراجع ومزيد من القراءة الموصى بها
** التراكم السيادي **
** تراكمي قائم **
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
مقال واحد لفهم تصنيف التراكمية
** بقلم: NIC Lin **
علم مسبق:
تعرّف على كيفية عمل "مجموعة التحديثات" ومشكلة توفر البيانات (توفر البيانات) في "مجموعة التحديثات"
خلاصة على التراكمي
بغض النظر عما إذا كانت مجموعة Validity أو Optimistic Rollup ، فسوف يقومون بتحميل البيانات إلى L1 (مثل Ethereum) ، بحيث يمكن للجميع الوصول إلى بيانات Rollup عن طريق الوصول إلى L1 ، واستخدامها لاشتقاق أحدث حالة من Rollup ، مثل لدى أليس 10 دولارات أمريكية و 5 دولارات أمريكية لبوب.
أولئك الذين لا يقومون بتحميل البيانات إلى L1 لا ينتمون إلى Rollup (مثل Validium أو zkPorter أو Arbitrum AnyTrust) ، وهم ليسوا موضوع هذه المقالة. بالإضافة إلى ذلك ، لن تناقش هذه المقالة كيفية التحقق التراكمي من صحة الحالة ، أي الفرق بين Validity Rollup و Optimistic Rollup.
سيقدم الجزء الأول من هذه المقالة مجموعة السيادية التراكمية. التراكمية السيادية ، كما يوحي اسمها ، هي تراكمية تتمتع بالاستقلالية. تحدث جميع ترقيات إصدار التراكم أو الهارد فورك على Sovereign Rollups ، على عكس Rollups التي يعرفها الجميع الآن (يشار إليها فيما يلي باسم Classic Rollups). موقع الشوكة هو ليس في Classic Rollup ، ولكن على عقد L1 Rollup: ينفذ عقد L1 Rollup ترقيات الإصدار من خلال محافظ متعددة التوقيع أو تصويت الحوكمة. أي أن العقد على L1 يحدد الإصدار الذي يجب أن تستخدمه مجموعة التحديثات في الوقت الحالي. وإذا كان هناك هجوم على Rollup في L1 ، مثل مهاجمة آلية الحوكمة أو مهاجمة عقد Rollup نفسه ، فسوف تتأثر Rollup. على العكس من ذلك ، نظرًا لأن Sovereign Rollup يعتبر L1 ببساطة مكانًا لتخزين البيانات ، يمكن لجميع أعضاء Sovereign Rollup تحديد الإصدار الذي يجب استخدامه حاليًا ضمن السلسلة ، وبغض النظر عما يحدث لـ L1 ، طالما أن L1 نفسها لم تتعرض للهجوم (مثل كإعادة تنظيم أو إيقاف تشغيل متسلسل) ، لن يتأثر التراكم السيادي.
سيقدم الجزء الثاني المستند إلى التراكمية. يزيل المستند التراكمي دور جهاز التسلسل ، ويسلم قوة فرز المعاملات إلى عمال المناجم L1 ، والمدققين ، وباحثي MEV ، وما إلى ذلك. فهو لا يجعل معاملات الفرز أكثر لامركزية فحسب ، بل إنه يبسط التصميم ويزيل العديد من مكونات النظام.
التراكمية السيادية
طبقة توافر البيانات وطبقة التسوية
التراكمية الكلاسيكية مثل Arbitrum ، و Optimism ، و StarkNet ، وما إلى ذلك ، لا تعتبر فقط Ethereum (L1) مكانًا لتخزين البيانات (أي طبقة توفر البيانات) ، ولكنها تعتبر أيضًا Ethereum طبقة تسوية في نفس الوقت: التسوية هي يتم إجراؤها على Ethereum ، وحالة L2 هي (أي رصيد كل عنوان في L2) تتم كتابتها إلى L1.
لماذا تحتاج إلى كتابة حالة L2 إلى L1؟ لأنه بهذه الطريقة ، يمكن لـ L2 و L1 تبادل المعلومات والأصول: يمكن لـ L1 / L2 dApps مزامنة المعلومات والتعاون ، ويمكن نقل L1's ETH بأمان بين L1 / L2 ، ويمكن أيضًا نقل ARB / OP الخاص بـ L2 بأمان بين L1 / L2. النقل بين L2.
يزيل التراكم السيادي طبقة التسوية (أو يحول نفسه إلى طبقة تسوية) ، ويستخدم ببساطة L1 كطبقة إتاحة البيانات.
لماذا إزالة طبقة التسوية؟ هناك أسباب أو أسباب مختلفة:
كيف يعمل التراكم السيادي
يستخدم Sovereign Rollup ببساطة L1 كطبقة إتاحة البيانات ، ويقوم بتحميل البيانات إلى L1 ، ويعتمد على L1 لضمان توفر البيانات ولن يتغير ترتيب البيانات. تعتمد عقد التجميع السيادية على قراءة البيانات الموجودة على L1 وتفسيرها لحساب أحدث حالة من التجميع السيادي. يمثل "التفسير والحساب" في الواقع قواعد الإجماع الخاصة بالتجميع السيادي ووظيفة انتقال الحالة: كيفية تصفية الكتل والمعاملات التي تتوافق مع تنسيق التجميع السيادي والقواعد من بيانات L1 ، وكيفية التحقق من هذه الكتل والمعاملات بعد الفرز ، ثم التحقق من كيفية تنفيذ هذه المعاملات لحساب أحدث حالة.
إذا كانت العقدتان السياديتان من إصدارات مختلفة ، فيمكنهما تفسير بيانات مختلفة أو حساب حالات حديثة مختلفة ، وبالتالي لن تكون هاتان العقدتان على نفس السلسلة ، فما تراهما هو في الواقع واحدة من سلسلتين متشعبتين.
هذا هو في الواقع نفس تشغيل إصدارات مختلفة من عقد Ethereum ، قد لا يكون الإصداران نفس السلسلة. على سبيل المثال ، بعد الهارد فورك ، أولئك الذين ينسون تحديث إصدار العقدة أو لا يرغبون في تحديث إصدار العقدة سيبقون بشكل طبيعي في السلسلة الأصلية (مثل ETC ، ETHPoW) ، بينما أولئك الذين يقومون بتحديث إصدار العقدة سيكونون على سلسلة جديدة (ETH).
يجب أن يعرف القراء هنا أيضًا سبب تسميته التراكمية السيادية ، لأنه في Sovereign Rollup ، يمكن للجميع اختيار إصدار العقدة وتفسير البيانات وفقًا للإجماع (الاجتماعي) لمجموعتهم الخاصة. إذا كان هناك خلاف في مجتمع Sovereign Rollup اليوم مثل ETHPoW vs ETH ، فهذا يعني أن كل شخص يسلك طريقه الخاص ويختار إصدارات مختلفة من العقد لتفسير البيانات ، لكن البيانات لا تزال هي الأصل ولم تتغير.
ما هي التراكمية السيادية الموجودة؟
لا توجد حاليًا أمثلة على التراكمية السيادية ، ولكن نظرًا لأن اتجاه التصميم المعياري لـ blockchain أصبح أكثر شيوعًا ، سيكون هناك بالتأكيد العديد من التراكميات السيادية. على سبيل المثال ، يمكن للإطار المعياري Rollkit الذي تصممه Celestia إنشاء مجموعة Sovereign Rollup من خلال Cosmos SDK. على عكس السلسلة الأصلية (L1) التي تم إنشاؤها باستخدام Cosmos SDK ، والتي ستحتاج إلى تنفيذ إجماع Tendermint لتحديد ترتيب المعاملات ، يمكن لـ Sovereign Rollup استخدام متسلسل واحد لفرز المعاملات مثل التجميع الحالي المشترك ، مما يلغي الحاجة إلى إجماع متعدد العقد والاعتماد على مخاوفها الأمنية والموارد المستهلكة لتنفيذ خوارزمية الإجماع. ويقوم Sovereign Rollup بتحميل بيانات المعاملة إلى Celestia ، ولكن في نفس الوقت ، نظرًا لأنه عبارة عن تراكم سيادي ، فلن يتأثر بـ L1 (مثل الترقية أو التعرض للهجوم).
الملاحظة 1: دعم Rollkit لاحقًا أيضًا استخدام Bitcoin كطبقة توفر البيانات.يمكن لمثل هذه المجموعة أن ترث أمان Bitcoin ولكن الإنتاجية ستقتصر على Bitcoin. *
ملاحظة 2: في الأساس ، يمكن تسمية السلاسل القائمة على Celestia باسم Sovereign Rollup. *
أو افترض أن Arbitrum لم تعد تستخدم Ethereum كطبقة تسوية ، ولم تعد بحاجة إلى تبادل المعلومات أو الأصول مع Ethereum ، واعتبرت Ethereum ببساطة مكانًا لتخزين البيانات ، ثم ستصبح Arbitrum أيضًا مجموعة Sovereign Rollup.
تجميع التسوية
هناك أيضًا تعريفات مثل مجموعة التسوية ، ولكنها في الأساس عبارة عن تراكم سيادي ، ومن ثم ستكون هذه المجموعة السيادية أيضًا طبقة التسوية للسلاسل الأخرى. وهذا يعني ، إذا كانت هناك سلاسل أخرى في مجموعة السيادية ، واعتبرتها مجموعات أخرى على أنها طبقة تسوية ، فيمكن تسمية مجموعة التراكمية السيادية هذه بمجموعة التسوية التراكمية.
إذا تم تغيير Ethereum لتحميل جميع معلومات السلسلة إلى Celestia اليوم ، فسيكون هذا Ethereum عبارة عن تراكم سيادي على Celestia ، وسيكون أيضًا مجموعة تسوية ، نظرًا لوجود العديد من السلاسل على Ethereum ، ويعتبرها العديد من Rollups طبقة تسوية .
ملاحظة: ربما في المستقبل ، سيتعرف الجميع تدريجيًا على الوحدات النمطية ووظائف الطبقات المختلفة ، ولن يبدأوا من منظور التراكمية ، وستختفي المصطلحات مثل التجميع السيادي أو مجموعة التسوية تدريجياً. على أي حال ، الشيء المهم هو كيفية تصميم سلسلتك (سواء كانت L1 أو L2 أو L3 وما إلى ذلك) ، وكيفية إجراء المقايضات واختيار أدوات البناء المناسبة لطبقات مختلفة.
القائمة التراكمية
ظهر تصنيف تراكمي آخر مؤخرًا هو Based Rollup ، أو يُعرف باسم L1-Sequenced Rollup. يشير المستند المستند إلى التجميع إلى معاملات الفرز. لا يتم تسليم التجميع إلى جهاز التسلسل (أو أجهزة التسلسل المتعددة) لفرز المعاملات ، ولكن يتم تسليمه بالكامل إلى عمال المناجم L1 أو المدققين أو الباحثين عن MEV ، وما إلى ذلك لفرز المعاملات. عندما يقوم Classic Rollup بتحميل البيانات إلى L1 ، فإن عقد L1 Rollup سيتحقق مما إذا كان قد تم تحميله بواسطة مُسلسِل مؤهل ، بينما لا توجد قيود على Based Rollup ويمكن لأي شخص تحميله.
أكبر ميزة لـ Based Rollup هي أنه لا يوجد جهاز التسلسل ، لذلك لا توجد نقطة واحدة للفشل أو حتى تحتاج إلى القلق بشأن حصول Sequencer على قوة طلب معاملات كاملة ، أي أنه لا داعي للقلق بشأن تعطل جهاز التسلسل والتسبب في إيقاف تشغيل السلسلة أو عدم قبول المعاملات عمدًا من مستخدمين محددين ، أو القلق من أن يلتقط جهاز التسلسل MEV الخاص بالمستخدم بشكل ضار. يرث التراكم القائم تمامًا درجة اللامركزية في L1 في إنشاء الكتلة.
يحتوي Based Rollup على المزايا التالية:
التكلفة التي يتكبدها المستخدمون لمغادرة Rollup منخفضة جدًا
بشكل عام ، ستصمم Rollup آلية Force Inclusion أو آلية Escape Hatch بحيث يمكن للمستخدمين تثبيت أنفسهم مباشرةً في L1 دون استخدام Sequencer من أجل منع Sequencer عن قصد عدم قبول معاملات مستخدم معينة أو انقطاعات التسلسل التي تمنع المستخدمين من مغادرة Rollup. المعاملات في كتلة L2. ومع ذلك ، فإن التكلفة الأولى لمثل هذا التصميم هي تكلفة عالية. يتعين على المستخدمين دفع رسوم L1 لإدخال المعاملات. والتكلفة الثانية هي أن المعاملات المدرجة من L1 قد تؤثر على عملية حزم Sequencer L2: من الممكن أن L1 سوف يؤدي إدراج المعاملة إلى إبطال المعاملة التي ينوي جهاز التسلسل جمعها في كتلة L2. على سبيل المثال ، تحول المعاملة التي أدخلتها Alice في L1 كل الأموال إلى Bob ، مما أدى إلى فشل المعاملة التي تقوم فيها Alice بتحويل الأموال إلى Carol في كتلة L2.
من أجل منع المعاملة التي تم إدراجها بواسطة L1 من التأثير على عملية حزم L2 لتعبئة Sequencer ، لن يتم تفعيل Arbitrum على الفور عندما تحتاج المعاملة التي تم إدراجها بواسطة L1 إلى انتظار Sequencer لتقديم طلب فعال للمعاملة ليتم تضمينها في أحدث كتلة قبل سيصبح ساري المفعول ، أو إذا لم يستجب Sequencer ، فسيصبح ساري المفعول بعد فترة من الزمن. التفاؤل يسمح للمعاملة أن تصبح سارية المفعول على الفور.إذا كانت المعاملة التي تم إدراجها بواسطة L1 تؤثر على المعاملة في كتلة L2 ، فيجب على Sequencer إيجاد طريقة للتعامل معها. يمكنك قراءة هذه المقدمة لمعرفة المزيد حول المقارنة بين Arbitrum و Optimism في معالجة معاملات تحديد المستوى L1.
تصميم أبسط بكثير
دور Rollup المستندة أقل من دور Sequencer من Rollup العام ، مما يعني عبء أقل على الأجهزة (لا داعي للقلق بشأن تحميل آلة Sequencer) وأي آلية لجعل معاملات الطلب أكثر عدلاً (مثل آلية Sequencer اللامركزية). ثم ليست هناك حاجة لآلية Force Inclusion / Escape Hatch ، بما في ذلك العقود ذات الصلة بـ L1 والأدوات خارج السلسلة ذات الصلة لتسهيل قيام المستخدمين بوضع المعاملات في L1 بأنفسهم.
لكن Based Rollup له أيضًا بعض العيوب:
لا توجد خدمة تأكيد المعاملات مقدمًا
باستخدام Sequencer ، يمكن لـ Sequencer إخبار المستخدم بسرعة نتيجة تنفيذ معاملته. طالما أن المستخدم يثق في جهاز التسلسل ، يمكن تأكيد نتيجة المعاملة على الفور دون انتظار تحميل المعاملة إلى L1.
بروتوكول يفقد مصدر إيرادات MEV
لم يعد يتم تسليم MEV إلى Sequencer لفحصها واستخراجها ، ولكن إلى L1 ، لذلك لا يوجد لدى L2 نفسها طريقة للحصول على مزايا MEV. يمكن الحصول على إيرادات MEV من خلال تصميم آلية تقديم العطاءات لحقوق إنتاج الكتلة ، ولكنها ستزيد نسبيًا من الحد الأدنى للمشاركة في إنتاج الكتلة ، مما سيقلل من درجة اللامركزية ، وسيؤدي إدخال آلية تقديم العطاءات أيضًا إلى زيادة درجة معينة من التعقيد.
مراجع ومزيد من القراءة الموصى بها