فهم التراكمية اللامركزية في مقال واحد

العنوان الأصلي: "التراكميات اللامركزية"

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

كما ذكر فريق Espresso ، ستواجه Rollups المركزية في النهاية أسعارًا احتكارية ومشكلات MEV. بالإضافة إلى ذلك ، تعمل التراكمية المركزية بطبيعتها على كسر القابلية للتركيب ، مما يؤدي إلى تجميعات مجمعة مجزأة. **

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

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

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

** التراكمية اللامركزية **

في zkRollups ، توصل كل من Polygon و Starknet إلى حلول لإضفاء اللامركزية على التراكميات الخاصة بهم.

** المضلع **

قبل تقديم POE (إثبات الكفاءة) ، اعتمد Polygon zkEVM POD (إثبات التبرع) ، مما مكّن عامل الفرز من المزايدة على فرصة إنشاء دفعة المعاملة التالية. ومع ذلك ، فإن هذا يؤدي إلى مشكلة تتمثل في أن طرفًا ضارًا واحدًا يمكنه التحكم في الشبكة بأكملها عن طريق تقديم أعلى عرض سعر.

بعد اعتماد POE ، سيشارك المُنشئ والمُثبِّت في الشبكة غير المرخصة بكفاءة أكبر في ظل ظروف الأجهزة الخاصة بهما. يمكن لأي شخص الانضمام إلى Polygon zkEVM طالما كان ذلك منطقيًا من الناحية الاقتصادية.

في Polygon zkEVM ، تتطلب أداة الفرز 16 جيجابايت من ذاكرة الوصول العشوائي ووحدة معالجة مركزية رباعية النوى ، بينما يتطلب المثل الأعلى 1 تيرابايت من ذاكرة الوصول العشوائي ووحدة المعالجة المركزية 128 نواة. بالإضافة إلى ذلك ، هناك دور يسمى المُجمِّع ، وهو مسؤول عن جمع بيانات L1 ، وإرسالها إلى المُثبِّت ، واستلام الدليل وتقديمه إلى L1. يمكننا اعتبار المُجمِّع والمُثِّل نفس الموضوع ، لأن العلاقة بين المُجمِّع والمُثبِّت بسيطة للغاية ، ويدفع المُجمِّع للمُثِّل لإنتاج الدليل.

هذه البنية بسيطة للغاية: يمكن لأي طالب حزم المعاملات بناءً على الحالة السابقة في L1 دون إذن ، وتحديث الحالة المقابلة. في الوقت نفسه ، يمكن لأي مجمّع تقديم إثبات للتحقق من الحالة المحدّثة.

في POE ، لا تشير الكفاءة فقط إلى كفاءة الشبكة للمشاركين الذين يتنافسون مع بعضهم البعض ، ولكن أيضًا إلى الكفاءة الاقتصادية لجهاز التسلسل والمثبِّت أنفسهم. في L2 ، يشترك مُنشئ الطلب والمُثبِّت في رسوم المعاملة ، ويدفع مُرسِل الطلب رسوم الدُفعة إلى المُجمِّع لإنشاء الإثبات. وهذا يضمن تحفيز المشاركين اقتصاديًا للمساهمة في كفاءة الشبكة ، مما يؤدي إلى نظام بيئي أكثر قوة واستدامة.

** فارز **

  • الدخل: رسوم المعاملات L2
  • التكلفة: رسوم دفعة (محسوبة في MATIC بالدولار الأمريكي) + رسوم معاملة L1 (طريقة تسلسل المكالمات)

** المُجمّع (المُثبِت) **

  • الدخل: دفعة الرسوم (محسوبة في MATIC $)
  • التكلفة: تكلفة إثبات + رسوم معاملة L1 (طريقة التحقق من الدفاتر الموثوق بها)

** المنسق: دفعة الرسوم **

  • المعلمة الأولية
  • دفعة الرسوم = 1 دولار ماتيك
  • veryBatchTimeTarget = 30 دقيقة. هذا هو الوقت المستهدف لمجموعة التحقق من الصحة. سيقوم البروتوكول بتحديث متغير الدفعه لتحقيق هذا الوقت المستهدف.
  • دفعة المضاعف = 1002. هذا هو مضاعف الرسوم الدفعية ، والذي يتراوح من 1000 إلى 1024 ، مع 3 منازل عشرية.
  • منظم
  • diffBatches: عدد الدُفعات المجمَّعة> 30 دقيقة مطروحًا منه عدد الدُفعات <= 30 دقيقة. القيمة القصوى هي 12.
  • عملية التنسيق
  • زيادة مكافأة التجميع لتحفيز المجمعين عند diffBatches> 0.

  • عندما يكون diffBatches <0 ، قلل مكافأة التجميع لقمع المجمّع وإبطاء عملية التجميع.

** ستاركنت **

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

بالمقارنة مع الآلية البسيطة لـ Polygon zkEVM ، فإن مخطط Starknet أكثر تعقيدًا لأنه يتضمن إجماع L2 وإثبات بروتوكول متسلسل في شبكة الإثبات.

** فارز **

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

بالنسبة لبروتوكول L2 المباشر ، يمكن اعتماد آليات إجماع مختلفة ، مثل أنظمة PoS المقاومة لـ Sybil مثل Tendermint أو DAGs. من ناحية أخرى ، يتضمن بروتوكول L1 الآمن عقودًا متعددة تتعامل مع إدارة الحصة والتحقق من الإثبات وتحديث الحالة على التوالي.

سير العمل النموذجي لاتفاقية إجماع دفتر الأستاذ المزدوج هو كما يلي:

  1. أولاً ، استخدم إخراج دفتر الأستاذ المباشر L2 كمدخل لدفتر الأستاذ الآمن L1 لإنشاء دفتر الأستاذ المباشر الذي تم فحصه.

  2. بعد ذلك ، خذ دفتر الأستاذ المباشر الذي تم التحقق منه كمدخل وأدخله مرة أخرى في بروتوكول الإجماع الخالص لـ L2 للتأكد من أن دفتر الأستاذ المباشر الذي تم فحصه هو دائمًا بادئة دفتر الأستاذ المباشر.

  3. كرر العملية المذكورة أعلاه.

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

من أجل تقليل تكاليف الغاز على L2 ، يقسم Starknet نقاط التفتيش إلى "مستوى الدقيقة" و "مستوى الساعة". بالنسبة لنقاط التفتيش "على مستوى الدقيقة" ، فإن الدولة نفسها فقط هي التي تلتزم بالسلسلة ، بينما يتم إرسال بقية البيانات (إثباتات الصلاحية ، وتوافر البيانات ، وما إلى ذلك) عبر شبكة StarkNet L2. يتم تخزين هذه البيانات والتحقق منها بواسطة عقد StarkNet الكاملة. من ناحية أخرى ، يتم التحقق من صحة نقاط التفتيش "كل ساعة" علنًا في L1. كلا النوعين من نقاط التفتيش يقدمان نفس التأكيد النهائي. بالنسبة لنقاط التفتيش "على مستوى الدقيقة" ، يتم التحقق من صحة إثبات الصلاحية بواسطة عقد StarkNet الكاملة ، ويمكن إصداره بواسطة أي عقدة على L1 لإعطاء L1 نهائيًا لنقاط التفتيش "على مستوى الدقيقة". لذلك ، يحتاج المُثبِّت إلى إنشاء براهين صغيرة لنشرها على نطاق واسع في شبكة اللغة الثانية.

لتقليل الكمون بشكل أكبر ، يقترح Starknet بروتوكول انتخاب الزعيم لتحديد القائد مقدمًا. المنطق الأساسي هو كما يلي: يتم تحديد زعيم الحقبة الحالية i مسبقًا بناءً على مقدار L1 المحصن وبعض العشوائية. على وجه التحديد ، في العصر الأول والثاني ، يقوم القائد \ _طريقة الانتخاب بتقسيم الفرز معجمًا بناءً على مقدار التعهدات في العصر الأول -3. ثم ، أرسل معاملة لتحديث nonce واختر نقطة بشكل عشوائي. سيكون فارز الموضع الذي تسقط فيه النقطة هو قائد العصر الأول.

** مصدّق **

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

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

بالإضافة إلى المنافسة بين المحفزات ، يجب خفض حاجز الدخول حتى يتمكن المزيد من المحققين من المشاركة في الشبكة. يقترح Starknet بروتوكولًا معقدًا يستخدم براهين متكررة تسمى بروتوكولات البروتوكول المتسلسلة.

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

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

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

تنسيق

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

** شهادة اللامركزية **

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

في الواقع ، ليس فقط Rollups و zkBridge و zkOracle يحتاجون أيضًا إلى شبكة الأمثال. كلهم يحتاجون إلى شبكة موزعة قوية من المحترفين.

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

** سوق إثبات **

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

مِلكِي

أنشأت مينا سوقًا إثباتًا يسمى Snarketplace حيث يتم تداول براهين Snark. أصغر وحدة هنا هي إثبات Snark لمعاملة واحدة. تستخدم مينا إثباتًا تعاوديًا لشجرة الحالة تسمى حالة المسح الضوئي.

حالة الفحص عبارة عن مجموعة من الأشجار الثنائية حيث تكون كل معاملة عبارة عن عقدة. يتم إنشاء دليل واحد في أعلى الشجرة يمكنه إثبات جميع المعاملات في الشجرة. وللمثل مهمتان: الأولى إنشاء البراهين والثانية دمج البراهين.

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

** = لا شيء ؛ مؤسسة**

تم تصميم سوق إثبات مينا لبروتوكوله الخاص ، بينما = لا شيء ؛ تقترح المؤسسة سوق إثبات عام لخدمة السوق بالكامل.

تتكون خدمة السوق من ثلاثة مكونات: DROP DATABASE و zkLLVM و Proof Market.

  • DROP DATABASE: إنه بروتوكول نظام إدارة قاعدة البيانات ، والذي يمكن اعتباره طبقة DA.
  • Proof Market: هو تطبيق يعمل على DROP DATABASE ، على غرار ما يسميه البعض "التبادل اللامركزي" ضد zk-proof.
  • zkLLVM: مترجم يحول لغات البرمجة عالية المستوى إلى مدخلات لبروتوكولات حوسبة يمكن إثباتها.

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

سير العمل على النحو التالي: يمكن لجانب الطلب من الإثبات كتابة التعليمات البرمجية بلغة برمجة عالية المستوى ، ثم إدخالها إلى = لا شيء ؛ zkLLVM من خلال سلسلة الأدوات ، مما يؤدي إلى إنشاء دائرة واحدة ستصبح زوجًا تجاريًا فريدًا في السوق.

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

** التزام بخطوتين **

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

  • الخطوة 1: إرسال تجزئة إثبات عدم المعرفة للكتلة T.
  • بدءًا من الكتلة T + 11 ، لم يعد يُسمح للمُثبتين الجدد بإرسال تجزئات.
  • الخطوة 2: إرسال إثبات عدم المعرفة
  • بعد مجموعة T + 11 ، يمكن لأي مقدم تقديم إثبات عدم معرفة. إذا نجح إثبات عدم معرفة واحد على الأقل في عملية التحقق ، فسيتم استخدامه للتحقق من جميع التجزئة المقدمة ، وسيتلقى المُثبَّت الذي تم التحقق منه مكافآت إثبات العمل (PoW) بما يتناسب مع مبلغ الرهن العقاري.
  • إذا لم يتم التحقق من دليل عدم المعرفة الصفرية قبل مجموعة T + 20 ، فسيتم معاقبة جميع المحققين الذين أرسلوا تجزئات. ثم أعد فتح الفرز ، يمكنك إرسال تجزئة جديدة ، والعودة إلى الخطوة 1.

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

** فارز اللامركزية **

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

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

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

إجماع

بروتوكول الإجماع مسؤول بشكل أساسي عن طلب المعاملات وضمان توافرها ، وليس تنفيذها. ومع ذلك ، فإن إضافة طبقة إجماع أخرى بشكل مباشر ، كما ذكرنا سابقًا ، ليس حلاً سهلاً.

لتحسين الاستجابة ، من الأساليب الشائعة الاعتماد على مجموعة أصغر من المدققين. على سبيل المثال ، يستخدم Algorand و Polkadot لجانًا أصغر عينات عشوائيًا لتجميع المعاملات. تستخدم جميع العقد إشارات عشوائية ووظيفة عشوائية يمكن التحقق منها (VRF) ، مع احتمال أن يتم تضمينها في لجنة في فترة معينة بما يتناسب مع مقدارها المحصن.

لتقليل حركة مرور الشبكة ، يمكن استخدام لجان أصغر توفر البيانات (DA). أو استخدم VID (تشتت المعلومات التي يمكن التحقق منها). يوزع VID رمز محو البيانات على جميع العقد المشاركة في الإجماع ، بحيث يمكن لأي مجموعة فرعية من العقد التي تحتوي على نسبة تعهد عالية بما فيه الكفاية أن تتعاون لاستعادة البيانات. تتمثل مفاضلة هذا النهج في تقليل تعقيد البث ، ولكن زيادة تعقيد استعادة البيانات.

اختارت Arbitrum الكيانات ذات السمعة الطيبة لتشكيل مجموعة المدققين ، مثل ConsenSys و Ethereum Foundation و L2BEAT و Mycelium و Offchain Labs و P2P و Quicknode ومركز أبحاث دفتر الأستاذ الموزع التابع لـ IFF (DLRC) والوحدة 410 للانضمام إلى لجنة الفرز. تتمثل المقايضة في هذا النهج في تعويض النقص في الكمية عن طريق تحسين جودة اللامركزية.

** شبكة جهاز التسلسل المشترك **

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

** أستريا **

تقوم Astria بتطوير blockchain للبرامج الوسيطة للنظام البيئي لـ Celestia's Rollup ، والذي يتضمن مجموعته الخاصة من الطلبات الموزعة. هذه المجموعة من الطلبات مسؤولة عن قبول المعاملات من مجموعات متعددة وكتابتها إلى الطبقة الأساسية دون تنفيذها.

يركز دور Astria بشكل أساسي على طلب المعاملات ويعمل بشكل مستقل عن الطبقة الأساسية و Rollup. يتم تخزين بيانات المعاملة على الطبقة الأساسية (مثل Celestia) ، بينما تحافظ العقد الكاملة التراكمية على الحالة وتنفيذ العمليات. هذا يضمن فصل Astria عن Rollup.

للنهاية ، توفر Astria مستويين من الالتزام:

  • "الالتزام الناعم": يُمكِّن العرض التراكمي من توفير تأكيدات الحظر السريع لمستخدميه النهائيين.
  • "التزام راسخ": السرعة هي نفس الطبقة الأساسية ، مما يضمن مستوى أعلى من الأمان والنهائية.

إسبرسو

قدمت Espresso مساهمة كبيرة في مجال تكنولوجيا المعرفة الصفرية. أحدث تطوير لهم هو حل شامل للفرز اللامركزي الذي يمكن تطبيقه على Optimistic Rollups و zkRollups.

تتكون شبكة الطلبات اللامركزية من:

  • إجماع HotShot: إعطاء الأولوية للإنتاجية العالية والنهاية السريعة على التوافر الديناميكي.
  • Espresso DA: الجمع بين حل DA المستند إلى اللجنة و VID ، حيث تقوم العقد ذات النطاق الترددي العالي بتغذية البيانات إلى جميع العقد الأخرى. يتم دعم توفر كل كتلة فردية أيضًا من قبل لجنة صغيرة منتخبة عشوائيًا. توفر VIDs نسخًا احتياطيًا موثوقًا به ولكن أبطأ ، مما يضمن التوافر طالما لم يتم المساس بنسبة عالية بما فيه الكفاية من وزن جميع العقد.
  • Rollup REST API: Ethereum متوافق مع JSON-RPC.
  • عقد جهاز التسلسل: تحقق من إجماع HotShot (أي العمل كعميل خفيف) وقم بتسجيل نقاط التفتيش (أي ، قم بالتزام تشفير للمعاملة) ، وقم بإدارة جدول تعهد HotShot.
  • شبكة P2P: بروتوكول القيل والقال.

بالمقارنة مع Astria ، تقدم Espresso DA. لذلك ، سيكون سير العمل مختلفًا قليلاً ، على النحو التالي:

  1. يقوم المستخدم بإنشاء وتقديم معاملة إلى التراكمية.

  2. يتم نشر المعاملة من خلال شبكة الأمر والاحتفاظ بها في مجموعة الذاكرة.

  3. عيّن قائدًا من خلال آلية تعهد HotShot ، واقترح كتلة ، ثم انشرها مرة أخرى إلى منفذي ومثبتات Rollup.

  4. يرسل القائد المعاملة إلى لجنة توافر البيانات ويتلقى شهادة DA كملاحظات.

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

تقدم Espresso بروتوكول Gossip للبراهين لتوفير تجربة مستخدم أكثر مرونة. يوفر ثلاثة خيارات لنهائية المعاملة:

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

بالإضافة إلى التحسينات المذكورة أعلاه ، تخطط Espresso أيضًا لجعل مدقق Ethereum بأكمله يشارك في تشغيل بروتوكول طلب Espresso. سيوفر استخدام نفس مجموعة أدوات التحقق أمانًا مشابهًا ، وستكون مشاركة القيمة مع مدققات L1 أكثر أمانًا. بالإضافة إلى ذلك ، يمكن أن تستفيد Espresso أيضًا من حل إعادة تخزين ETH الذي توفره EigenLayer.

نصف القطر

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

تستهدف الطبقة العليا معاملات المستخدم المنتظمة وتوفر حماية تشفير ضد MEV غير المرغوب فيها من خلال استخدام ألغاز timelock. على وجه التحديد ، تستخدم تقنية التشفير المؤجل العملي (PVDE) ، والتي ستولد أدلة على المعرفة الصفرية لألغاز timelock المستندة إلى RSA في 5 ثوانٍ. توفر هذه الطريقة حلاً عمليًا لحماية المستخدمين من MEVs الضارة. باختصار ، لا يمكن معرفة محتوى المعاملة حتى يحدد التسلسل ترتيب المعاملات.

تم تصميم الطبقة الأساسية لمنشئي الكتل وتسمح لهم بالمشاركة في الأنشطة المدرة للدخل مع تخفيف الأثر السلبي لـ MEV.

** التراكمية القائمة **

Based Rollup هو مفهوم تم اقتراحه مؤخرًا من قبل Justin Drake ، حيث يتعاون مقدمو L1 مع الباحثين والبناة L1 لتضمين كتل التجميع في كتلة L1 التالية دون إذن. يمكن اعتبارها شبكة من أجهزة التسلسل المشتركة على L1. مزايا وعيوب Based Rollup واضحة.

على الجانب الإيجابي ، تستفيد Based Rollup من الحيوية واللامركزية التي توفرها L1 ، وتنفيذها بسيط وفعال. كما يتوافق التراكم القائم على المستوى الاقتصادي مع L1. ومع ذلك ، هذا لا يعني أن Based Rollup يهدد سيادته. على الرغم من تسليم MEV إلى L1 ، لا يزال بإمكان Based Rollup امتلاك رموز الحوكمة وتحصيل الرسوم الأساسية. استنادًا إلى الفرضية ، يمكن أن تستفيد Based Rollup من هذه المزايا ، وتحقق الهيمنة ، وتعظيم العوائد في النهاية.

ختاماً

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

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

لتحقيق مقاومة الرقابة ، تسمح هذه القوائم أيضًا للمستخدمين بإرسال المعاملات مباشرة على L1. على سبيل المثال ، يستخدم zkSync قائمة انتظار ذات أولوية لمثل هذه المعاملات المرسلة في L1. وبالمثل ، يتضمن Polygon zkEVM طريقة دفعة القوة في العقد L1. عندما لا يحدث أي تجميع في غضون أسبوع ، يمكن للمستخدم استدعاء هذه الطريقة على L1 وتقديم مصفوفة بايت المعاملة و bathFee إلى المُثبِت.

ما هو مؤكد هو أنه في المستقبل المنظور ، ستكون لامركزية Rollup حلاً مشتركًا ، والذي قد يشمل الحلول المهمة المذكورة أعلاه أو بعض المتغيرات المبتكرة الأخرى.

شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
  • أعجبني
  • تعليق
  • مشاركة
تعليق
0/400
لا توجد تعليقات
  • تثبيت