عندما ننظر إلى الرؤية وخريطة الطريق لحلول التجميع المختلفة ، فسنجد أن جميع المجموعات الإجمالية تقريبًا لها هدف نهائي. إذا تم تكثيف هذا الهدف في جملة واحدة: بناء كومة تقنية ، وتقديمها إلى المجتمع ، وحل توسيع blockchain ، وفي النهاية اللامركزية في مجموعة التكنولوجيا للعمليات والحوكمة. هذا يؤدي إلى مصطلح التراكمية اللامركزية.
إذن ما هي اللامركزية بالضبط؟ ما هو تقسيم العمل بين مختلف أجزاء نظام التراكمية؟ هل تعني اللامركزية تعظيم المشاركين في تشغيل النظام؟ ما هو تأثير فارز مركزي؟ كيف ينبغي تصميم نظام الطلب المشترك والإجماع المحلي L2؟ ما هي وظيفة المُثبِت الفريد في ZK-Rollup؟ كيف ستبدو شبكة المثقفين اللامركزية المفتوحة؟ لماذا نحتاج تسريع أجهزة zk؟ ما هو الحل لمشكلة توافر البيانات؟ ....
هناك مناقشات لا حصر لها حول التراكمية اللامركزية في المجتمع ، لذلك نظمت شبكة الاتصالات الإلكترونية (ECN) سلسلة من المقابلات الصوتية مع موضوع "اللامركزية التراكمية" ، ودعت المؤسسين والباحثين البارزين في هذا المجال للحديث عن فهمهم للتفاهم اللامركزي.
مع تدفق المزيد والمزيد من السيولة في النظام الأساسي من الطبقة الثانية ، يظهر المزيد والمزيد من مزودي خدمة التجميع ، ليس فقط حلول تجميعية للأغراض العامة ، وسلاسل تجميع خاصة بالتطبيقات ، ولكن أيضًا منصات التجميع كخدمة. لذلك ، يشعر المزيد والمزيد من الأشخاص بالقلق من أن دور "منظم التسلسل" الحاسم للغاية في جميع مجموعات التحديثات تقريبًا لا يزال مركزيًا. ما هي مخاطر فارز مركزي؟ هل الفرز اللامركزي مهمة عاجلة؟
** في الحلقة الثانية ، قمنا بدعوة ياوقي جيا ، مؤسس شبكة AltLayer ، وتغرول محرموف ، باحثة Scroll ، وعبد الحميد باختا ، رئيس Starknet Exploration Lead ، لإجراء مناقشة مائدة مستديرة حول موضوع الفرز اللامركزي ، بحيث يكون الجمهور والقراء. يمكن فهم بعض التقدم والمعضلات الحالية للفرز اللامركزي. **
! [Dialogue with AltLayer، Scroll، Starknet team: Shared Sorter and L2 Consensus] (https://img.gateio.im/social/moments-69a80767fe-7ae6578082-dd1a6f-62a40f)
** الضيوف في هذا العدد: **
Yaoqi Jia ، مؤسس شبكة AltLayer ، twitterjiayaoqi
باحث في التمرير توغرول محرموف ، تويترtoghrulmaharram
Starknet Exploration Lead Abdelhamid Bakhta, twitter @dimahledba
ماضي
المشكلة 1: كيفية تطبيق اللامركزية التراكمية؟
الباحث في التحكيم باتريك ماكوري
معاينة
المشكلة 3: شبكة Prover وتسريع أجهزة zk
يي تشانغ ، المؤسس المشارك لـ Scroll
ليو فان ، المؤسس المشارك لشركة Cysic
المشكلة 4: توافر البيانات والتخزين اللامركزي
Qi Zhou ، مؤسس EthStorage
يستمع
انقر للاشتراك في البودكاست لمعرفة المزيد:
موقع YouTube:
عالم مصغر:
** الطابع الزمني **
00:49 Yaoqi يقدم نفسه
01:37 يقدم عبد الحميد نفسه
02:50 يقدم توغرول نفسه
04:03 دور الفارز في التجميع
08:37 النظام اللامركزي: تحسين تجربة المستخدم ومعالجة قضايا النشاط والرقابة
19:43 كيف ستركن ستاركنت اللامركزية فارز
22:59 كيف سيقوم Scroll بإلغاء مركزية الفارز
26:34 الفرق بين إجماع L2 في سياق التراكمية المتفائلة و zkRollup
32:28 zkRollup لا مركزية الفارز ويحتاج أيضًا إلى مراعاة المثل
36:01 ما هو التراكم الأساسي؟
40:53 عيوب جهاز التسلسل المشترك والتجميع المستند إلى سيناريوهات التطبيق
49:02 ما هو تأثير الأمر اللامركزي على MEV؟
مقدمة الضيف
** ياوقي **
أنا مؤسس AltLayer. تقوم AltLayer ببناء منصة "Rollup as a Service" حيث يقوم المطورون ببساطة بالنقر فوق بعض الأزرار وتكوين المعلمات. باستخدام لوحة التشغيل أو لوحة التحكم الخاصة بنا ، يمكنهم تشغيل مجموعات خاصة بالتطبيقات بسرعة في غضون دقائق. هذا ما نحاول القيام به الآن ، لتزويد المطورين ببيئة ووظائف تنفيذ مشتركة. نوفر أيضًا أجهزة تسلسل متعددة وأنظمة متعددة للآلات الافتراضية وأنظمة إثبات متنوعة للمطورين للاختيار من بينها.
** عبد الحميد **
أعمل في Starkware وأنا قائد فريق الاستكشاف. تهدف هذه المجموعة بشكل أساسي إلى إطلاق مشاريع مفتوحة المصدر تشبه البحث ولكن مع تركيز هندسي. هدفنا هو العمل على مشاريع مفتوحة المصدر بالتعاون الوثيق مع المجتمع ومع أشخاص من أنظمة بيئية أخرى. أحد هذه المشاريع هو Madara ، وهو في الواقع فارز Starknet. إنه ليس مرشحًا لشبكة Starknet العامة فحسب ، بل إنه أيضًا مُسلسِل لسلسلة تطبيقات Starknet و Layer3. يرتبط هذا أيضًا بما قاله الضيف السابق ، فنحن نفكر أيضًا في توفير التجميع كوظيفة خدمة ، ويمكن للأشخاص طرح سلسلة تطبيقات Starknet الخاصة بهم واختيار حلول مختلفة لتوافر البيانات بطريقة معيارية إلى حد ما. قبل ذلك ، عملت كمطور أساسي في Ethereum لمدة أربع سنوات ، وكنت مسؤولاً بشكل أساسي عن عمل EIP-1559.
خيار
أنا باحث في Scroll ، ومسؤولياتي الرئيسية في Scroll هي تصميم البروتوكول ، وتصميم الجسر ، واللامركزية ، والحوافز ، وهذا النوع من الأشياء. لذلك عندما لا أقوم بالتغريد ، فأنا في معظم الوقت أعمل فقط على كيفية تطبيق اللامركزية على البروتوكول أو أوامر الشراء ، والمحترفين ، وأشياء من هذا القبيل. مثل Starkware ، أحد الأشياء التي نعمل عليها هو مجموعة SDK. وبالتالي ، يمكنك إصدار مجموعة تستند إلى Scroll ، واستخدام خيارات مختلفة لتوافر البيانات بشكل نمطي وما إلى ذلك. ما زلنا ندرس خيارًا يمكن للمجموعات المستندة إلى Scroll SDK أن تستخدم فارز Scroll لمساعدتهم على تحقيق اللامركزية دون الحاجة إلى كل مجموعة للتعامل مع اللامركزية بنفسها. بالطبع ، لم يتم الانتهاء من الخطة بعد. ومع ذلك ، هذا أيضًا هو الاتجاه الذي نعمل عليه.
قسم المقابلة
** الموضوع الاول **
اشرح فارز التراكمية؟
** عبد الحميد **
يعد عامل الفرز مكونًا مهمًا جدًا في بنية الطبقة 2 ، حيث يتلقى هذا المكون المعاملات من المستخدمين ، ثم يقوم بتجميعها وتجميعها في كتل ، وتنفيذ المعاملات ، وما إلى ذلك. إنه أمر بالغ الأهمية لأن هذا هو المكون المسؤول عن إنشاء الكتل ، نظرًا لأن layer2 هي أيضًا blockchain مع كتل المعاملات. ينشئ الأمرون هذه الكتل ، ويشهد المحققون على هذه الكتل.
** ياوقي **
كما ذكر عبد ، فإن الطلب عبارة عن مزيج من العديد من الوظائف في blockchain. لذلك قد نعطي الأمر في الواقع الكثير من المسؤولية الآن مقارنةً بـ blockchain العام النموذجي. يحتاج أولاً إلى تجميع جميع المعاملات من المستخدمين ، ثم فرز تلك المعاملات ، إما بناءً على سعر الغاز أو على أساس من يأتي أولاً يخدم أولاً. بعد ذلك ، يحتاج منظم التسلسل إلى تنفيذ هذه المعاملات. مثل الآن ، تستخدم بعض Layer2s EVM (لدى Starware جهاز افتراضي مختلف) ، ولكن يحتاج جهاز التسلسل في الأساس إلى استخدام جهاز افتراضي مخصص لتنفيذ المعاملات وإنشاء الحالة. ثم تصل المعاملة إلى مرحلة التأكيد المسبق ، مما يعني أنه إذا رأيت وقت تأكيد يبلغ ثانية واحدة أو ثانيتين ، أو حتى ثوانٍ فرعية ، فهي في الأساس حالة تأكيد مسبق أكملها المُسلسِل. بعد ذلك ، بالنسبة لمعظم الفرز ، يحتاجون أيضًا إلى تحميل أو نشر نقاط التفتيش أو تجزئة الحالة إلى L1. هذا تأكيد على المستوى L1 ، والذي نسميه توفر البيانات. إذن ، يلعب فارز الفرز بالفعل العديد من الأدوار في نظام التجميع. لكن بشكل عام ، أعتقد أنه العنصر الأكثر أهمية في نظام التجميع.
** الموضوع 2 **
لماذا الفرز اللامركزي مهم؟ إذا استخدمنا فارز مركزي ، فما هي الأخطار المخفية على المستخدمين والنظام؟
خيار
بادئ ذي بدء ، نحتاج إلى معرفة أنه باستثناء وقود V1 في المرحلة الحالية ، لا يوجد تراكم حقيقي ، لأن مجموعات أخرى لا تزال تحتوي على عجلات تدريب.
ومع ذلك ، يمكننا القول أنه بمجرد تصنيفها على أنها تراكمية ، فهذا يعني أنه تمت إزالة mult-sig وما إلى ذلك. ثم تصبح مشكلة اللامركزية في الفرز مشكلة في تجربة المستخدم ، وليست مشكلة أمنية. لذلك عندما يتحدث الناس ، على سبيل المثال ، عن لامركزية L1 ، فإن المشكلة مختلفة تمامًا. لأن L1 يجب أن تقدم ضمانات للطلب والعملاء الخفيفين. لذلك إذا أراد العميل الخفيف التحقق من صحة الحالة ، فيجب أن يثق في مدقق L1. بالنسبة إلى التراكمية ، ليس هذا هو الحال. لأن الفارز يوفر فقط فرزًا مؤقتًا ، والذي يتم بعد ذلك إنهاءه بواسطة L1. ولأن التراكمية مضمونة أيضًا لمقاومة الرقابة ، لسنا بحاجة إلى اللامركزية لتحقيق ذلك.
لذلك ، هناك عدة أسباب وراء حاجتك إلى فارز لامركزي. أولاً ، إذا كان إنهاء L1 بطيئًا (إما لأن إثباتات الصلاحية التي قدمتها بطيئة جدًا ، أو بسبب آلية فترة التحدي الخاصة بإثباتات الاحتيال التفاؤلية) ، فعليك الاعتماد على شيء ما لتحقيق تأكيد سريع للمعاملة. في هذه المرحلة من التأكيد السريع ، على الرغم من أنه يمكنك الوثوق في أن Starkware أو Scroll لن يخدعك ، إلا أنهما يشيران إلى أنه بعد تأكيد الحظر ، لن يكون هناك إعادة تنظيم. هذا هو افتراض الثقة. ويمكن أن تضيف اللامركزية بعض الضمانات الاقتصادية ، وما إلى ذلك.
ولكن بناءً على ذلك ، لا يوجد ضمان نهائي في الوقت الفعلي. بشكل أساسي ، يمكنك فرض حزم المعاملات من خلال L1 ، لكن الأمر يستغرق ساعات لحزم تلك المعاملة. لذلك على سبيل المثال ، إذا كان هناك أوراكل مسؤول عن التحديث وكان الوقت متقلبًا ، فعندئذٍ بشكل أساسي إذا تم تحديث أوراكل لمدة ساعة أو أكثر ، فلن تكون التطبيقات الموجودة في مجموعة التحديثات متاحة. تتيح لنا اللامركزية بشكل أساسي تقديم بعض الضمانات القوية المقاومة للرقابة في الوقت الفعلي ، لأنه عندئذٍ سيحتاج الخصم إلى تسوية ليس فقط كيانًا واحدًا أو مجموعة من الكيانات ، ولكن شبكة الطلبات بالكامل.
لذلك بالنسبة لنا ، تعتبر اللامركزية حلاً أكثر لتحسين تجربة المستخدم أو إصلاح الحالة الأساسية لتحديثات أوراكل ، وما إلى ذلك. بدلاً من توفير ضمانات الأمان الأساسية ، هذا ما يفعله L1.
** عبد الحميد **
نعم ، السؤال عن الفارز اللامركزي الذي ذكرته ليس تمامًا مثل L1 اللامركزي ، والذي أعتقد أنه مهم جدًا. لأنه عندما نرى بعض L1s ينتقدون أجهزة الفرز المركزية ، فإنهم لا ينظرون بشكل صحيح إلى المفاضلات التي يقوم بها الفرز المركزي.
على هذا الأساس ، أود أن أضيف شيئًا متعلقًا بتجربة المستخدم المتعلقة بالنشاط. لأنه عندما يكون لديك فارز واحد فقط ، فأنت أكثر عرضة لخطر تعطل عامل الفرز. لذلك ، يزيد الأمر اللامركزي أيضًا من المرونة والحيوية على الشبكة. ولكن حتى في سياق مركزي ، لدينا أمان جيد عندما يتعلق الأمر بالأمن. لأنه عندما يمكنك فرض معاملات الحزم من خلال L1 ، يكون الفرق بين الاثنين هو المخطط الزمني فقط. كما أن وجود فارز لامركزي يتيح لك الحصول على ضمانات سريعة لمقاومة الرقابة ، كما ذكرت توغرول. لذا ، أريد فقط أن أضيف أنه من المهم أيضًا للحيوية أن يكون لديك شبكة لامركزية من الطلبات.
** ياوقي **
أود أن أضيف شيئا. ربما يكون النشاط هو أهم شيء نحتاج إلى مراعاته في هذه المرحلة. شهدت أحدث حالات الإنزال الجوي على L2s الأكثر شيوعًا ، مثل التفاؤل و Arbitrum ، فترة توقف. لذلك ، أعتقد أن ما نحتاج إلى حله هو كيفية التعامل مع آلاف طلبات المعاملات في الثانية عندما يكون لدينا فارز واحد فقط. حتى من الناحية النظرية ، إذا كان لديك عقدة واحدة فقط ، فلن تتمكن حقًا من التعامل مع العديد من الطلبات في نفس الوقت. لذا ، فيما يتعلق بالحيوية ، نحن بالتأكيد بحاجة إلى أدوات فرز متعددة. نقطة واحدة للفشل هي عقبة حقيقية ، ليس فقط للويب 3 ، حتى Web2 يمثل مشكلة كبيرة.
أبعد من ذلك ، هناك قضية الرقابة. إذا كان لدينا منسق واحد فقط ، حتى لو رأينا أنه يمكن للفريق إدارته ، فلا يزال يتعين عليك إثبات أن الفريق لن يقوم بالفعل بمراجعة المعاملات. في بعض الأحيان يكون من الممكن والقادر على الأطراف الخبيثة إدراج بعض المعاملات في القائمة السوداء. هذا هو نظام طلب لامركزي ، يمكنهم أيضًا محاولة إرسال المعاملات من خلال الطلبات الأخرى. لهذا السبب تلقينا الكثير من الانتقادات حول أجهزة الفرز الفردية مؤخرًا.
علاوة على ذلك ، هناك بعض المشكلات الأخرى مثل MEV والتشغيل المبكر. في نظام به فارزات مركزية ، خاصة بالنسبة لبروتوكولات DeFi ، قد يتمكنوا من التحقق من mempool بسهولة. ربما ليس في شكل المرشح الأوفر حظًا ، لكن لديهم فرصة أفضل لتخريب التجارة والتحكيم فيها.
الكثير من هذه المشاكل ، لأسباب مختلفة ، على الرغم من أننا نرى أن L2 مختلفة تمامًا عن L1. لكن في النهاية ، ما زلنا بحاجة إلى جعله لامركزيًا قدر الإمكان. لذلك يتعين علينا مواجهة بعض المشكلات المماثلة التي نواجهها مع blockchains العامة أو L1.
** عبد الحميد **
نعم ، أوافق على أهمية فارز اللامركزية. لكني أريد أيضًا أن أقول ، كما نعلم جميعًا ، هذا ليس بالسؤال السهل.
أيضًا ، ** نظرًا لأن التجميعات لها بنية محددة جدًا ، مع كيانات متعددة. هناك أمر واحد نتحدث عنه ، ولكن هناك أيضًا مَثَّل ، ونحن بحاجة إلى تطبيق اللامركزية على حد سواء. ** ستكون هناك بعض المقايضات وبعض الصعوبة في كيفية تسعير المعاملات لأن هناك حاجة إلى عوامل مختلفة لتشغيل الشبكة. لذا ، كيف تسعير الصفقة؟ الفرز والمثقف لهما متطلبات مختلفة للأجهزة ، والمثل يحتاج إلى آلة فائقة القوة وما إلى ذلك. لذلك ، تعد معاملات التسعير في عالم لامركزي مشكلة صعبة للغاية ، ولهذا السبب نحتاج إلى وقت للمضي قدمًا ببطء.
لذلك سنواجه جميعًا مثل هذه المقايضة.إذا أردنا اللامركزية بسرعة ، فقد نحتاج إلى اتخاذ بعض عجلات التدريب واللامركزية تدريجياً ، لأننا إذا أردنا بشكل مباشر بنية مثالية ، فسوف يستغرق الأمر عدة سنوات. لذلك أعتقد أننا سنتخذ مقاربة براغماتية ونحاول تدريجياً تطبيق اللامركزية. على الأقل هذه هي خطتنا الحالية ، مثل البدء بآلية إجماع بسيطة لـ BFT ثم إضافة آلية إجماع أخرى على المدى القصير أو شيء من هذا القبيل. لذلك أريد فقط أن أقول ، إنه ليس سؤالاً سهلاً. لأنه من الواضح أن هناك مفاضلة بين سرعة التطوير ومدى قابلية التطبيق على البيئة اللامركزية.
** الموضوع 3 **
كيف يتم تطبيق اللامركزية على الفارز؟
** عبد الحميد **
هناك العديد من الميزات التي نريد تحقيق اللامركزية فيها ، ولكل منها مقايضات مختلفة.
على سبيل المثال ، عند تطبيق اللامركزية ، فأنت تريد تقديم نوع من آلية التوافق. في آلية التوافق ، ومع ذلك ، هناك أجزاء متعددة. الأول هو انتخاب القائد ، أي كيفية اختيار من سيقوم بإنشاء الكتل ، ومن سيكون المسؤول عن إنشاء الكتل في خانة معينة أو في غضون وقت معين. ** ما يخطط فريق Starknet للقيام به هو استخدام layer1 قدر الإمكان. وهذا يعني ، في خوارزمية انتخاب القادة لدينا ، نريد المشاركة في layer1. على سبيل المثال ، لدينا الرموز المميزة ، وسيتم التعهد على العقد الذكي لـ layer1 Ethereum ، والذي يستخدم لتحديد آلية انتخاب القائد. ** هذا يعني أننا بحاجة إلى بعض التفاعل حيث سيقوم مُنشئ L2 بالاستعلام عن عقد Ethereum الذكي لمعرفة من سيكون القائد التالي أو شيء من هذا القبيل. لذلك من الواضح أن هناك حاجة إلى نوع من العشوائية وأشياء أخرى. لذا فهو ليس سؤالًا بسيطًا. لكن هذا هو الجزء الأول. إذن أنت بحاجة إلى آلية للإجماع نفسه. هناك خيارات متعددة: إما آلية السلسلة الأطول أو BFT ، أو مزيج من الاثنين. مثل Ethereum ، لديها LMG Ghost و Casper FFG للنهاية.
لذلك قد نتبنى نهجًا عمليًا ونبدأ بـ BFT أولاً. لماذا ؟ عندما تنظر layer2 في اللامركزية ، فإن هدفنا ليس الحصول على مقياس فارز كبير مثل layer1. على سبيل المثال ، في Ethereum ، الهدف هو مشاركة الملايين من المدققين. في هذه الحالة ، لا يمكنك استخدام آلية BFT فقط ، لأنها ستكون سيئة للغاية من حيث الكفاءة ، وستتسبب في مشاكل كبيرة جدًا. على سبيل المثال ، إذا كانت هناك مشكلة في شبكة Bitcoin ، وإذا كانت آلية BFT ، فستتوقف السلسلة تمامًا. لكن هذا ليس هو الحال ، تواصل شبكة Bitcoin إنشاء كتل ، ويتم مهاجمة آلية النهاية فقط.
ولكن في الطبقة 2 ، إذا كان الهدف هو بضع مئات إلى 1000 فارز ، فقد يكون من الجيد البدء بآلية BFT. إذن ، لدينا آلية انتخاب الزعيم ، ثم الإجماع ، ثم هناك جزءان آخران ، لكنني سأترك الأمر للضيوف الآخرين لمواصلة الإضافة. لكن الجزأين الآخرين هما تحديثات الحالة وإنشاء الدليل.
خيار
أولاً ، في المستوى الثاني ، تعتبر اللامركزية مشكلة متعددة الأوجه ، كما وصفها عبد. خاصة في zkRollup ، نظرًا لوجود مُحَفِذِين وطلبات طلب ، يجب عليك التنسيق بينهما ، وعليك إلغاء مركزية كليهما. هذه المشكلة مختلفة تمامًا عن L1.
الفرق الآخر هو أنه في L2 ، كل تصميمك هو إقناع الجسر الأساسي بأن الإجماع صحيح ، وليس لإقناع أي عدد من العقد الأخرى. من الواضح أنك يجب أن تفعل الشيء نفسه ، ولكن يجب أن يكون تركيزك الأساسي على الجسر نفسه.
حاليا ، نحن نعمل في اتجاهين مختلفين. رقم واحد ، أعتقد ، مثل أي شخص آخر ، نحن نعمل على بروتوكول BFT. هذا ليس فعالًا للغاية وهناك بعض مكامن الخلل التي يجب حلها. لقد توصلنا إلى حل تقريبي ، لكنه لا يزال غير مثالي. على سبيل المثال ، أحد الأسئلة هو ، كيف يمكنك الموازنة بين الحوافز بين أدوات الفرز والمحققين؟ نظرًا لأن الأمر يتحكم في MEV ، ولا يستطيع المُثبِّت الوصول إلى MEV ، فهناك حافز للأشخاص لتشغيل الأمر بدلاً من المُثبِّت. لكن في الواقع ، نحن بحاجة إلى عدد أكبر من المحفزات أكثر من الطلبات ، فكيف يمكنك موازنة الحوافز بين الاثنين؟ هذه واحدة من تلك المشاكل.
الحل الثاني الذي نعمل عليه هو اتجاه آخر. تذكر أن الأشياء قد تتغير. مقترحات جديدة تخرج كل يوم. على سبيل المثال ، كان هناك الكثير من الحديث مؤخرًا حول تجميع البيانات على أساس وكيف يمكنك الاستعانة بمصادر خارجية لفرز L1. الاتجاه الثاني هو التخلص من الفارز تمامًا واستخدام بعض المنشئ الخارجي. على سبيل المثال ، يقترح صانعو الإيثيريوم أو Flashbots SUAVE وما إلى ذلك الكتل المرتبة ثم يُجرون الإجماع داخل المُثقف. الميزة هنا هي أنك لست مضطرًا للتعامل مع الحوافز لأنه يمكنك بشكل أساسي استخدام دعم السلوك الإيجابي داخل البروتوكول ويقوم بإنشاء بروتوكول أبسط. لكن العيب هو أنه نظرًا لأننا نحتاج إلى عدد كبير من المحفزات (لأنه يمكننا إثبات ذلك بالتوازي) ، فمن الصعب جدًا تشغيل بروتوكول BFT كلاسيكي معهم. لذا فإن السؤال هو كيف يمكنك تحسين بروتوكول BFT الحالي ليعمل مع المئات ، أو حتى الآلاف ، من المحققين؟ وهذا ليس سؤالاً سهلاً للإجابة عليه.
هل تقديم إجماع L2 ضروري لمنظم لامركزي؟
** ياوقي **
يمكنني الإجابة على هذا السؤال تقريبًا لأننا طرحنا مؤخرًا شيئًا من هذا القبيل.
لذا فإن تقديم الإجماع لا يعتمد على ما إذا كنا نريده أم لا. بمجرد أن يكون لديك العديد من الطلبات أو حتى مجرد عقد ، عليك أن تجعلهم يوافقون. حقا يعتمد على افتراضاتك. إذا كان افتراضًا بيزنطيًا ، فيمكننا استخدام BFT أو أي بروتوكول إجماع بيزنطي موجود. إذا كان إعدادًا غير بيزنطي ، على سبيل المثال ، إذا افترضنا فقط أن العقدة يمكن أن تكون متصلة وغير متصلة بالإنترنت فقط ، وأنه لا يمكنها التصرف بشكل ضار ، فيمكننا استخدام بروتوكول Raft أو بروتوكول إجماع آخر أسرع. لكن على أي حال ، إذا كان لدينا مجموعة من الطلبات أو المحققين ، إذا أردنا تنظيمهم معًا لإنتاج الكتل على مدار فترة زمنية ، فيجب أن يكون لديك بروتوكول إجماع حولهم.
لذلك ، كما ذكر توغرول وعبدال للتو ، أعتقد أن هناك الكثير من المقترحات وموضوعات البحث حول كيفية تنفيذ نظام ترتيب أو إثبات لامركزي. لذلك ، نظرًا لأننا أطلقنا للتو testnet لنظام تجميع متعدد الفرز (حاليًا يدعم فقط إثباتات الاحتيال للتجميعات المتفائلة) ، بناءً على خبرتنا في التصميم والتنفيذ ، هناك بعض الأشياء التي يمكنني مشاركتها حول الصعوبات. وكما ذكر توغرول للتو ، فإن الصعوبة لا تكمن في بروتوكول الإجماع نفسه ، فالصعوبة الحقيقية تكمن في أشياء أخرى غير ذلك ، مثل جزء الإثبات. لأنه إذا كان فارزًا واحدًا ، فلن تحتاج إلى العديد من العقد. يمكننا اعتبارها آلة افتراضية ، آلة افتراضية. لذا ، ما عليك سوى إحضار المعاملات وتنفيذها ، وإجراء انتقالات الحالة. المُثبِت مسؤول عن إنشاء البراهين لانتقال الحالة لمجموعة المعاملات السابقة. ومع ذلك ، إذا قمنا بتشغيل بروتوكول الإجماع للمضارب والمثقف على التراكمي ، فإننا نحتاج إلى تقديم منطق إجماع إضافي هناك. علاوة على ذلك ، تحتاج أيضًا إلى نظام إثبات لبروتوكول الإجماع. لذلك ، سيقدم هذا الكثير من العمل ليقوم نظام الإثبات بإنشائه. ثم بمجرد إنشاء الدليل ، يمكنك التحقق منه بسهولة على L1 Ethereum.
لهذا السبب بطريقة ما ، عندما أطلقنا أول شبكة اختبار متعددة الطلبات ، كان للتجميع المتفائل بعض المزايا في هذا الصدد. بشكل عام ، يمكنك تبسيط الكثير من الأشياء ، مثل عدم مراعاة جزء إثبات الصلاحية. مثلنا ، نقارن كل شيء بشكل أساسي بـ WASM. لذا فهي في النهاية تعليمات WASM. لذلك ، من خلال التحقق من تعليمات WASM هذه ، من السهل نسبيًا التحقق باستخدام كود Solidity. إذا قمنا للتو بإعادة تنفيذ جميع تفسيرات تعليمات WASM على Ethereum.
لكن بشكل عام ، المشكلة ليست مشكلة فردية. إذا كان لدينا حل للمشكلة ، فسيكون هناك بعض أعمال المتابعة الأخرى التي يجب حلها في نفس الوقت. بالطبع ، ستكون هناك مشكلات MEV ، مثل كيفية توزيع MEV بشكل عادل. يمكنك تعيين جميع الطلبات والمثبتات بناءً على ما إذا كانوا قد قاموا بإنشاء كتلة أو التحقق من صحة كتلة. لكن في النهاية ، إنها في الحقيقة مزيج من العديد من القضايا ، ليس فقط القضايا التقنية ، ولكن الحوافز الاقتصادية أيضًا.
وعلينا أن نتذكر أن L2 مقترح لأننا نريد تقليل تكلفة الغاز بشكل كبير. لذلك لا يمكن أن يكون لدينا الكثير من العقد. حتى في إنشاء البراهين ، قد تكون L2 أغلى من L1. لذلك نحتاج حقًا إلى التوصل إلى نهج متوازن لهذا النوع من المشاكل.
** عبد الحميد **
أود أن أضيف نقطة أخرى. أولاً ، لا يوجد حاليًا دليل فعلي غير مصرح به على الاحتيال من أجل التراكم المتفائل. وما زلت أؤكد على هذا في كل فرصة أتيحت لي ، لأنه من المهم أن نكون صادقين بشأن هذا عند المقارنة. لذا فهم ليسوا L2 على الإطلاق. هذا أول شيء.
ثم أود أن أضيف شيئًا عن عدم التزامن بين الفرز والبراهين ، لأنه مهم جدًا. كما قلت ، نريد تحسين الفرز ، لأن هذا يمثل حاليًا عنق الزجاجة لجميع الحلول. لكن هذا جيد في سياق الفرز المركزي ، لأننا نعلم أن أداة الفرز ستنتج انتقالات قيمة فقط وسنكون قادرين على التحقق منها. لكن سيكون الأمر أكثر صعوبة في سياق النوع اللامركزي ، لأنه ربما يكون فارزك قادرًا على إنتاج شيء لا يمكن التحقق منه. ثم ستحتاج إلى التعامل مع ذلك لاحقًا.
في سياق الفرز المركزي ، لتحسين الفرز ، نظرًا لأنه لا يتعين علينا إنشاء البراهين أثناء عملية الفرز ، يمكننا محاولة القيام بذلك بالسرعة المحلية ، وهو ما نريد القيام به. قم بترجمة القاهرة إلى لغة آلية منخفضة المستوى مثل LLVM وقم بتشغيلها بسرعة فائقة على الفارز. ثم يمكنك أن تثبت بشكل غير متزامن. وأروع شيء في البراهين هو أنه يمكنك القيام بها بالتوازي. يتم تحقيق التوازي الهائل من خلال إثبات أن العودية ممكنة. لهذا السبب سنتمكن من اللحاق بسرعة الفارز. لكن الأمر صعب عندما يكون لامركزيًا ، لأننا نحتاج إلى التأكد من أن المنظم ينتج انتقالات حالة صالحة فقط.
خيار
سأضيف أنني لست متأكدًا مما يفعله Starknet هنا. لكن بالنسبة لنا ، أعتقد أنه من الافتراضات العامة لكل zkRollup أنه إذا قمت بإضفاء اللامركزية على الفارز ، يجب أن يكون نظام الإثبات الخاص بك قادرًا على التعامل مع الدُفعات غير الصالحة. لذلك ، بشكل أساسي ، إذا قمت ، على سبيل المثال ، بإرسال دفعة بتوقيع غير صالح ، فيجب أن تكون قادرًا على إثبات أن الحالة الناتجة تعادل حالة البداية. لذلك سيكون هناك بعض الحمل في كلتا الحالتين. يتعلق الأمر بكيفية تقليل احتمالية حدوث ذلك.
** عبد الحميد **
نعم هذا صحيح. لهذا السبب قدمنا سييرا في القاهرة 1 لجعل كل شيء قابل للتحقق. سيضمن هذا التمثيل الوسيط أن كل برنامج كايرو 1 يمكن التحقق منه حتى نتمكن من تضمين معاملة عائدة.
ما هو أساس التراكمية؟
** ياوقي **
جاء التجميع المستند في الأصل من منشور مدونة بواسطة Justin Drake في منتديات Ethereum. تتمثل إحدى أفكاره في أنه يمكننا إعادة استخدام بعض أدوات التحقق من Ethereum للتحقق من معاملات التجميع ، بحيث لا نحتاج إلى مجموعة منفصلة من العقد للتحقق من معاملات التجميع المختلفة. على وجه الخصوص ، سيكون لدينا العديد من القوائم في المستقبل ، بما في ذلك المجموعات العامة للأغراض العامة والعديد من المجموعات الخاصة بالتطبيقات. لذلك ، في هذه الحالة ، سيكون رائعًا إذا تمكنا من العثور على مكان مشترك مثل مجموعة التحقق من Ethereum للتحقق من صحة هذه المعاملات.
بالطبع ، هذه مجرد فكرة ، لأنها تقدم أيضًا الكثير من الصعوبات الفنية. على سبيل المثال ، من الناحية النظرية ، يمكننا أن نطلب مدققي Ethereum للتحقق من معاملات التجميع ، ولكن من الصعب جدًا الحصول على منطق التحقق من المجموعات المجمعة أو المضمنة في بروتوكول Ethereum نفسه. نحن نسمي هذا التحقق داخل البروتوكول ، والذي يتطلب شوكة صلبة لعقد Ethereum. بالطبع ، في هذه الحالة ، يمكننا التحقق من بعض معاملات التجميع. ولكن إذا فعلنا ذلك ، فسترى المشاكل. يشبه الأمر إلى حد ما أننا نريد مجموعة L2 لمشاركة ضغط Ethereum ، ولكن في النهاية ما زلنا نطلب من مدققي Ethereum أن يقوموا ببعض الأعمال التي تم تفريغها إلى L2. لذا يتحدث الكثير من الناس عن كيفية القيام بذلك.
ثم تحدثنا إلى Barnabe ، الباحث في مؤسسة Ethereum الذي يعمل حاليًا على PBS. هذا اقتراح من Ethereum ، والذي يقضي بتقسيم مهمة المدققين إلى أدوار متعددة وبناة وعارضين. الآن لدينا Flashbots لتولي دور البناة في PBS ، فهم يؤلفون كل الكتل ويرسلونها إلى عروض Ethereum. لذلك بمجرد تجميع هذه الكتل في شبكة Ethereum ، سيحصل البناة أيضًا على بعض المكافآت. ثم في هذه الحالة ، كيف تكافئ هؤلاء المدققين من شبكة Ethereum؟ كما أنهم مسؤولون عن التحقق من صحة مجموعة التحديثات.
أحد الحلول هو "الاستعادة" ، والذي ربما تكون قد سمعته كثيرًا من EigenLayer أو بعض البروتوكولات الأخرى. يمكن للمستخدمين إعادة مشاركة ETH على شبكات الفرز الأخرى. أو قم بمكافأة مدققي Ethereum على تشغيل البرنامج فعليًا للقيام بعمل التحقق من صحة مجموعة التحديثات. في هذه الحالة ، يمكن مكافأتهم من المستوى 2 ومن خلال بروتوكول إعادة التخزين. كانت هناك العديد من المقترحات لهذا حتى الآن ، ولكن بشكل عام إنها فكرة عن كيفية التمكن من إعادة توظيف مدققي Ethereum الحاليين. كيف يمكننا إعادة استخدام ETH الحالي للمساعدة في الدخول في عصر جديد من أنظمة التجميع أو L2؟ لذلك فهي تحاول بشكل أساسي تبسيط الكثير من الأشياء لمشروع التجميع. إذا أرادت مجموعة التحديثات نوعًا جديدًا من الفرز ، إذا كانوا يريدون مصدرًا جديدًا للضمانات ، فيمكنهم إعادة استخدام البنية التحتية الحالية أو الضمانات الحالية. لهذا السبب تم بناؤه فوق Ethereum ، ومن ثم يمكن إعادة استخدام المزيد من البنية التحتية والتخزين للتجميع و L2 أيضًا.
عيوب جهاز التسلسل المشترك والتجميع المستند إلى سيناريوهات التطبيقات الخاصة بهم.
خيار
أريد تقديم شكوى بشأن هذا الاقتراح ، لست مقتنعًا بالاقتراح المتعلق بجهاز التسلسل المشترك. بالطبع ، ما زالوا في مهدهم ، وإذا تحسنت هذه التصميمات في المستقبل ، فمن الممكن تمامًا أن أؤيدهم. الأمر مجرد أن الشكل الحالي غير مقنع بالنسبة لي. هناك العديد من الأسباب.
أولاً ، بالنسبة لي ، يتمثل عرض القيمة الرئيسي لجهاز الفرز المشترك في السماح للمستخدمين باكتساب قابلية التركيب الذري بين تجميعات الأغراض العامة مثل Scroll أو Starknet. لكن المشكلة هي أنه إذا كانت لديك قابلية تكوين ذرية ، فإن مجموعة التحديثات الخاصة بك تكون نهائية مثل أبطأ مجموعة تتكامل معها. لذلك ، بافتراض دمج Scroll مع Optimistic Rollup ، ستكون النهاية النهائية لـ Scroll سبعة أيام. بينما يتمثل عرض القيمة الرئيسي لـ ZKRollup في تحقيق نهائية سريعة نسبيًا ، يمكن للمستخدمين الانسحاب إلى L1 في غضون دقائق. وفي هذه الحالة ، التخلي عن ذلك أساسًا.
الجانب السلبي الآخر هو أنك إذا كنت تريد نهائية خارج السلسلة ، فأنت بحاجة إلى تشغيل عقدة L2 ، وطالما تم الانتهاء من البيانات المرسلة إلى السلسلة بواسطة L1 ، فستحصل على نهائية محليًا في L2. إذا لم تقم كل L2 مدمجة بتشغيل عقدة كاملة ، فمن المستحيل عمليا تحقيق الإنهاء المحلي. هذا يعني أن تشغيل هذا النظام يمكن أن يكون أكثر تكلفة من تشغيل نظام مثل Solana ، لأن لديك عدة عقد كاملة تعمل في نفس الوقت ، بنفقاتها العامة الخاصة وما إلى ذلك.
لذلك ، لهذه الأسباب ، لا أعتقد أنه من المنطقي بالنسبة لـ L2. الأمر مختلف قليلاً بالنسبة لـ L3 ، لأنه إذا أراد شخص ما إنشاء سلسلة خاصة بالتطبيق ولا يريد التعامل مع اللامركزية. لنفترض أنني أقوم ببناء لعبة وأريد فقط التعامل مع بناء اللعبة ، ثم يمكنني الاستعانة بمصادر خارجية للعمل اللامركزي. لكنني لا أعتقد أنه من المنطقي بالنسبة لـ L2 في الوقت الحالي.
بالنسبة إلى التراكمية القائمة ، لدي أيضًا مخاوف لدي. على سبيل المثال ، كيف تشارك أرباح MEV مع المحققين؟ لأنه إذا لم يتم النظر في مشكلة التخصيص ، فيمكن أن تحصل L1 بشكل أساسي على جميع أرباح MEV. شيء صغير آخر هو أن وقت التأكيد الخاص به يساوي وقت التأكيد L1 ، وهو 12 دقيقة ، والذي لا يمكن أن يكون أسرع. هناك مشكلة أخرى تتمثل في أنه نظرًا لعدم وجود إذن ، يمكن للعديد من الباحثين إرسال دفعات المعاملات في نفس الوقت ، مما يعني أنه قد ينتهي الأمر بنتائج مركزية. لأن البناة يتم تحفيزهم لتضمين معاملاتهم إذا كان أحد الباحثين يتواصل بسهولة أكبر من الآخرين. لذلك ، قد يؤدي ذلك إلى قيام باحث واحد فقط باقتراح دفعات لـ L2 في النهاية ، وهذا ليس حلاً جيدًا للغاية ، لأنه إذا حدث ذلك ، فإننا نعود أساسًا إلى المربع الأول.
** ياوقي **
من المثير للاهتمام ، أنني تلقيت مكالمة مع Ben ، مؤسس Espresso ، في الواقع الأسبوع الماضي. نناقش هذا كثيرًا في موضوع الفرز المشترك. كما ذكر توغرول ، أعتقد أن هناك بعض عدم اليقين بشأن سيناريوهات الاستخدام لنظام الطلب المشترك. هذا يرجع أساسًا إلى أنه بالنسبة إلى L2 للأغراض العامة ، ليس لدينا عادةً عدد كبير من أجهزة الفرز بسبب الكفاءة والتعقيد والاقتصاد. وما زلت أشعر أنه سواء كان ذلك من أجل جهاز التسلسل المشترك ، أو التجميع القائم ، أو الاستراحة ، فإن أفضل حالة استخدام هي في الغالب لـ RAS (Rollup as a Service) أو مثل هذه الأنظمة الأساسية حيث يمكننا طرح الكثير من التجميعات. لا نحتاج حقًا إلى شبكة فرز كبيرة لنكون صادقين إذا لم يكن هناك العديد من التجميعات. هذه المجموعات لديها بالفعل أنظمة الفرز الخاصة بها ، ولديها بالفعل مجتمعاتها الخاصة أو شركائها ، عندما لا يكون هناك سوى بعض L2s العامة. لا يحتاجون حقًا إلى شبكة منفصلة وطرف ثالث. أيضًا ، يعد هذا عبئًا على شبكة الطرف الثالث ، لأنه يتعين عليك التخصيص لكل L2 ، ولكل L2 مجموعة اختبار مختلفة. هذا يتطلب الكثير من التغييرات على شبكتك الخاصة.
لكن في نفس الوقت ، كما ذكر توغرول ، لبعض حالات الاستخدام الخاصة. على سبيل المثال ، إذا أردنا أن يكون لدينا بعض قابلية التشغيل البيني على مستوى الفارز ، يمكن أن تكون أدوات الفرز المشتركة طريقة محتملة للعمل. على سبيل المثال ، يتم استخدام نفس فارز البيانات المتعددة. في هذه الحالة ، يمكن لهذا الفرز التعامل بشكل أساسي مع بعض معاملات التجميع المتقاطع لضمان الذرية المتقاطعة بين التجميع A و B و C.
ولكن يمكنك أيضًا رؤية المشكلة هنا عندما أصف الموقف. إذا كان لدينا بالفعل العديد من هذه المتسلسلات المشتركة ، فإنها ستصبح مرة أخرى عنق زجاجة ونقطة فشل واحدة جديدة. نحن نعطي الكثير من القوة لمن يسمون بالطلبات المشتركة. لقد أصبحوا أشبه بشبكة ، حيث يتحكمون في العديد من مجموعات التحديثات. أخيرًا ، نحتاج مرة أخرى إلى التوصل إلى طريقة لإضفاء اللامركزية على هذا الفرز المشترك.
لكن على أي حال ، أعتقد أنه من الجيد أن يكتشف الناس تدريجيًا المزيد والمزيد من المشاكل ويتوصلون إلى المزيد والمزيد من الحلول. بشكل عام ، من المثير رؤية كل ما هو جديد في هذا المجال كل يوم. مع كل هذه الحلول الجديدة ، نحن على الأقل نسير على الطريق الصحيح لإضفاء اللامركزية حقًا على مساحة التجميع بالكامل.
** عبد **
نعم ، أنا أتفق معكما. أعتقد أنه من المنطقي أكثر لـ Layer3 و Lisk لأنهم لا يريدون تحمل مسؤولية تحفيز شبكة لامركزية بعد الآن ويحتاجون إلى إيجاد شركاء لبدء أشياء مثل أدوات الفرز. لذلك أعتقد أنه من المنطقي بالنسبة لـ Lisk. ولكن مثل توغرول ، لا أعتقد أن هذا منطقي جدًا بالنسبة إلى Layer2 حتى الآن.
** الموضوع 4 **
ما هو تأثير الأمر اللامركزي على MEV؟
** عبد **
بالنسبة إلى Starknet ، في سياق المركزية ، لا نقوم بأي نوع من MEV ، ونعتمد نموذجًا لمن يأتي أولاً يخدم أولاً. وهذا يعني أنه في سياق اللامركزية ، بالطبع ، سيتم جلب المزيد من MEV في وقت لاحق. لكن من السابق لأوانه تحديد النسبة ، لأنها تعتمد أيضًا على تصميم آلية التوافق والجوانب الأخرى.
خيار
ولكن الشيء هو ، حتى لو لم تفعل MEV ، فقد يكون هناك بعض MEV لا يزال يحدث في Starknet. حسنًا ، لا تؤدي اللامركزية في حد ذاتها إلى تقليل MEV أو زيادة MEV. بالطبع ، إذا قمت بتطبيق نوع من بروتوكول الطلب العادل أو تشفير العتبة ، على سبيل المثال ، فعندئذٍ نعم ، فإنك تقلل MEV. لكن لا يمكنك القضاء عليه تمامًا. فلسفتي هي: MEV لا يمكن القضاء عليها. لكن لنفترض أنك تقوم للتو بإنشاء إجماع BFT ، أو تبني شيئًا ما فوق إجماع BFT. هذا في الواقع لا يؤثر على MEV على الإطلاق. لا يزال MEV موجودًا ، يجب أن يكون السؤال عن كيفية عمل الباحث مع الفارز لاستخراج MEV.
** ياوقي **
المشكلة هي أنه حتى نموذج من يأتي أولاً يخدم أولاً به أجزاء صعبة. بمجرد أن نكشف عن mempool لبعض الباحثين ، لا يزال لديهم ميزة اللعب أكثر. على سبيل المثال ، بالنسبة لأجهزة التسلسل ، فهي تعادل الانتظار عند باب مكتبك. لذلك في هذه الحالة ، بمجرد أن يروا نوعًا من فرصة المراجحة ، ليس فقط حول التشغيل الأمامي أو هجوم الساندويتش ، بمجرد أن يرسل المستخدم معاملة ، يمكنهم رؤيتها على الفور في mempool. لذلك ، يمكنهم وضع تداولاتهم بسرعة قبل الآخرين. لذلك ، لديهم ميزة على الباحثين الآخرين.
لكن بالعودة إلى اللامركزية ، أعتقد أن الأمر يتعلق في الغالب بمقاومة الرقابة ، كما ناقشنا في البداية. يدير الفريق أجهزة التسلسل. يمكن للفريق أن يقول إنه عادل للجميع. لكن هذا لا يمنع في الكود. لذا ، إذا كان بإمكاننا الحصول على شبكة P2P ، فسيكون رائعًا إذا شعرنا أن هذه العقد تفحص معاملاتي ومن ثم يمكننا إرسالها إلى العقد الأخرى. لذلك ، يتعلق الأمر حقًا بإنصاف معالجة المعاملات في L2.
بالنسبة إلى MEVs ، لأنه في الآونة الأخيرة ، بالإضافة إلى MEVs التي تم إنشاؤها ضمن مجموعة واحدة ، هناك بعض MEVs التي تم إنشاؤها عبر الجسور. في شبكة الفرز اللامركزية نسبيًا ، سيكون لديك المزيد من الفرص لاستخراج MEV. بافتراض أن لدينا شبكة أوامر مشتركة ، إذا كان بإمكانك بطريقة ما التأثير على الأمر المشترك لإعادة ترتيب المعاملات ، فأنت تمتلك ميزة كبيرة على أي شخص آخر.
هناك مزايا وعيوب لشبكة التسلسل المشتركة. على الجانب الإيجابي ، يمكننا زيادة اللامركزية في نظام التصنيف. ولكن على الجانب الآخر ، كل شخص لديه الفرصة ليكون فارزًا. لذلك ، يمكنهم في الأساس فعل ما يريدون ، وهي غابة مظلمة مرة أخرى. لذلك ، قدمنا اللامركزية ، ومن ثم كان علينا أن نواجه مشكلات مماثلة واجهناها في Ethereum. لهذا السبب يريد Flashbots و Ethereum Foundation المضي قدمًا مع PBS ، والعروض المنفصلة والبناة ، ثم محاولة الحصول على حل واحد من جانب المنشئ.
لذلك عندما ننظر إلى المشكلة ، فهي ليست مشكلة واحدة فقط. لم تعد مشكلة فردية ، بل مشكلة شخص لشخص ، وأكثر من ذلك.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
حوار مع فرق AltLayer و Scroll و Starknet: المُسلسل المشترك وتوافق L2
مقدمة
عندما ننظر إلى الرؤية وخريطة الطريق لحلول التجميع المختلفة ، فسنجد أن جميع المجموعات الإجمالية تقريبًا لها هدف نهائي. إذا تم تكثيف هذا الهدف في جملة واحدة: بناء كومة تقنية ، وتقديمها إلى المجتمع ، وحل توسيع blockchain ، وفي النهاية اللامركزية في مجموعة التكنولوجيا للعمليات والحوكمة. هذا يؤدي إلى مصطلح التراكمية اللامركزية.
إذن ما هي اللامركزية بالضبط؟ ما هو تقسيم العمل بين مختلف أجزاء نظام التراكمية؟ هل تعني اللامركزية تعظيم المشاركين في تشغيل النظام؟ ما هو تأثير فارز مركزي؟ كيف ينبغي تصميم نظام الطلب المشترك والإجماع المحلي L2؟ ما هي وظيفة المُثبِت الفريد في ZK-Rollup؟ كيف ستبدو شبكة المثقفين اللامركزية المفتوحة؟ لماذا نحتاج تسريع أجهزة zk؟ ما هو الحل لمشكلة توافر البيانات؟ ....
هناك مناقشات لا حصر لها حول التراكمية اللامركزية في المجتمع ، لذلك نظمت شبكة الاتصالات الإلكترونية (ECN) سلسلة من المقابلات الصوتية مع موضوع "اللامركزية التراكمية" ، ودعت المؤسسين والباحثين البارزين في هذا المجال للحديث عن فهمهم للتفاهم اللامركزي.
مع تدفق المزيد والمزيد من السيولة في النظام الأساسي من الطبقة الثانية ، يظهر المزيد والمزيد من مزودي خدمة التجميع ، ليس فقط حلول تجميعية للأغراض العامة ، وسلاسل تجميع خاصة بالتطبيقات ، ولكن أيضًا منصات التجميع كخدمة. لذلك ، يشعر المزيد والمزيد من الأشخاص بالقلق من أن دور "منظم التسلسل" الحاسم للغاية في جميع مجموعات التحديثات تقريبًا لا يزال مركزيًا. ما هي مخاطر فارز مركزي؟ هل الفرز اللامركزي مهمة عاجلة؟
** في الحلقة الثانية ، قمنا بدعوة ياوقي جيا ، مؤسس شبكة AltLayer ، وتغرول محرموف ، باحثة Scroll ، وعبد الحميد باختا ، رئيس Starknet Exploration Lead ، لإجراء مناقشة مائدة مستديرة حول موضوع الفرز اللامركزي ، بحيث يكون الجمهور والقراء. يمكن فهم بعض التقدم والمعضلات الحالية للفرز اللامركزي. **
! [Dialogue with AltLayer، Scroll، Starknet team: Shared Sorter and L2 Consensus] (https://img.gateio.im/social/moments-69a80767fe-7ae6578082-dd1a6f-62a40f)
** الضيوف في هذا العدد: **
ماضي
المشكلة 1: كيفية تطبيق اللامركزية التراكمية؟
معاينة
المشكلة 3: شبكة Prover وتسريع أجهزة zk
المشكلة 4: توافر البيانات والتخزين اللامركزي
يستمع
انقر للاشتراك في البودكاست لمعرفة المزيد:
موقع YouTube:
عالم مصغر:
** الطابع الزمني **
00:49 Yaoqi يقدم نفسه
01:37 يقدم عبد الحميد نفسه
02:50 يقدم توغرول نفسه
04:03 دور الفارز في التجميع
08:37 النظام اللامركزي: تحسين تجربة المستخدم ومعالجة قضايا النشاط والرقابة
19:43 كيف ستركن ستاركنت اللامركزية فارز
22:59 كيف سيقوم Scroll بإلغاء مركزية الفارز
26:34 الفرق بين إجماع L2 في سياق التراكمية المتفائلة و zkRollup
32:28 zkRollup لا مركزية الفارز ويحتاج أيضًا إلى مراعاة المثل
36:01 ما هو التراكم الأساسي؟
40:53 عيوب جهاز التسلسل المشترك والتجميع المستند إلى سيناريوهات التطبيق
49:02 ما هو تأثير الأمر اللامركزي على MEV؟
مقدمة الضيف
** ياوقي **
أنا مؤسس AltLayer. تقوم AltLayer ببناء منصة "Rollup as a Service" حيث يقوم المطورون ببساطة بالنقر فوق بعض الأزرار وتكوين المعلمات. باستخدام لوحة التشغيل أو لوحة التحكم الخاصة بنا ، يمكنهم تشغيل مجموعات خاصة بالتطبيقات بسرعة في غضون دقائق. هذا ما نحاول القيام به الآن ، لتزويد المطورين ببيئة ووظائف تنفيذ مشتركة. نوفر أيضًا أجهزة تسلسل متعددة وأنظمة متعددة للآلات الافتراضية وأنظمة إثبات متنوعة للمطورين للاختيار من بينها.
** عبد الحميد **
أعمل في Starkware وأنا قائد فريق الاستكشاف. تهدف هذه المجموعة بشكل أساسي إلى إطلاق مشاريع مفتوحة المصدر تشبه البحث ولكن مع تركيز هندسي. هدفنا هو العمل على مشاريع مفتوحة المصدر بالتعاون الوثيق مع المجتمع ومع أشخاص من أنظمة بيئية أخرى. أحد هذه المشاريع هو Madara ، وهو في الواقع فارز Starknet. إنه ليس مرشحًا لشبكة Starknet العامة فحسب ، بل إنه أيضًا مُسلسِل لسلسلة تطبيقات Starknet و Layer3. يرتبط هذا أيضًا بما قاله الضيف السابق ، فنحن نفكر أيضًا في توفير التجميع كوظيفة خدمة ، ويمكن للأشخاص طرح سلسلة تطبيقات Starknet الخاصة بهم واختيار حلول مختلفة لتوافر البيانات بطريقة معيارية إلى حد ما. قبل ذلك ، عملت كمطور أساسي في Ethereum لمدة أربع سنوات ، وكنت مسؤولاً بشكل أساسي عن عمل EIP-1559.
خيار
أنا باحث في Scroll ، ومسؤولياتي الرئيسية في Scroll هي تصميم البروتوكول ، وتصميم الجسر ، واللامركزية ، والحوافز ، وهذا النوع من الأشياء. لذلك عندما لا أقوم بالتغريد ، فأنا في معظم الوقت أعمل فقط على كيفية تطبيق اللامركزية على البروتوكول أو أوامر الشراء ، والمحترفين ، وأشياء من هذا القبيل. مثل Starkware ، أحد الأشياء التي نعمل عليها هو مجموعة SDK. وبالتالي ، يمكنك إصدار مجموعة تستند إلى Scroll ، واستخدام خيارات مختلفة لتوافر البيانات بشكل نمطي وما إلى ذلك. ما زلنا ندرس خيارًا يمكن للمجموعات المستندة إلى Scroll SDK أن تستخدم فارز Scroll لمساعدتهم على تحقيق اللامركزية دون الحاجة إلى كل مجموعة للتعامل مع اللامركزية بنفسها. بالطبع ، لم يتم الانتهاء من الخطة بعد. ومع ذلك ، هذا أيضًا هو الاتجاه الذي نعمل عليه.
قسم المقابلة
** الموضوع الاول **
اشرح فارز التراكمية؟
** عبد الحميد **
يعد عامل الفرز مكونًا مهمًا جدًا في بنية الطبقة 2 ، حيث يتلقى هذا المكون المعاملات من المستخدمين ، ثم يقوم بتجميعها وتجميعها في كتل ، وتنفيذ المعاملات ، وما إلى ذلك. إنه أمر بالغ الأهمية لأن هذا هو المكون المسؤول عن إنشاء الكتل ، نظرًا لأن layer2 هي أيضًا blockchain مع كتل المعاملات. ينشئ الأمرون هذه الكتل ، ويشهد المحققون على هذه الكتل.
** ياوقي **
كما ذكر عبد ، فإن الطلب عبارة عن مزيج من العديد من الوظائف في blockchain. لذلك قد نعطي الأمر في الواقع الكثير من المسؤولية الآن مقارنةً بـ blockchain العام النموذجي. يحتاج أولاً إلى تجميع جميع المعاملات من المستخدمين ، ثم فرز تلك المعاملات ، إما بناءً على سعر الغاز أو على أساس من يأتي أولاً يخدم أولاً. بعد ذلك ، يحتاج منظم التسلسل إلى تنفيذ هذه المعاملات. مثل الآن ، تستخدم بعض Layer2s EVM (لدى Starware جهاز افتراضي مختلف) ، ولكن يحتاج جهاز التسلسل في الأساس إلى استخدام جهاز افتراضي مخصص لتنفيذ المعاملات وإنشاء الحالة. ثم تصل المعاملة إلى مرحلة التأكيد المسبق ، مما يعني أنه إذا رأيت وقت تأكيد يبلغ ثانية واحدة أو ثانيتين ، أو حتى ثوانٍ فرعية ، فهي في الأساس حالة تأكيد مسبق أكملها المُسلسِل. بعد ذلك ، بالنسبة لمعظم الفرز ، يحتاجون أيضًا إلى تحميل أو نشر نقاط التفتيش أو تجزئة الحالة إلى L1. هذا تأكيد على المستوى L1 ، والذي نسميه توفر البيانات. إذن ، يلعب فارز الفرز بالفعل العديد من الأدوار في نظام التجميع. لكن بشكل عام ، أعتقد أنه العنصر الأكثر أهمية في نظام التجميع.
** الموضوع 2 **
لماذا الفرز اللامركزي مهم؟ إذا استخدمنا فارز مركزي ، فما هي الأخطار المخفية على المستخدمين والنظام؟
خيار
بادئ ذي بدء ، نحتاج إلى معرفة أنه باستثناء وقود V1 في المرحلة الحالية ، لا يوجد تراكم حقيقي ، لأن مجموعات أخرى لا تزال تحتوي على عجلات تدريب.
ومع ذلك ، يمكننا القول أنه بمجرد تصنيفها على أنها تراكمية ، فهذا يعني أنه تمت إزالة mult-sig وما إلى ذلك. ثم تصبح مشكلة اللامركزية في الفرز مشكلة في تجربة المستخدم ، وليست مشكلة أمنية. لذلك عندما يتحدث الناس ، على سبيل المثال ، عن لامركزية L1 ، فإن المشكلة مختلفة تمامًا. لأن L1 يجب أن تقدم ضمانات للطلب والعملاء الخفيفين. لذلك إذا أراد العميل الخفيف التحقق من صحة الحالة ، فيجب أن يثق في مدقق L1. بالنسبة إلى التراكمية ، ليس هذا هو الحال. لأن الفارز يوفر فقط فرزًا مؤقتًا ، والذي يتم بعد ذلك إنهاءه بواسطة L1. ولأن التراكمية مضمونة أيضًا لمقاومة الرقابة ، لسنا بحاجة إلى اللامركزية لتحقيق ذلك.
لذلك ، هناك عدة أسباب وراء حاجتك إلى فارز لامركزي. أولاً ، إذا كان إنهاء L1 بطيئًا (إما لأن إثباتات الصلاحية التي قدمتها بطيئة جدًا ، أو بسبب آلية فترة التحدي الخاصة بإثباتات الاحتيال التفاؤلية) ، فعليك الاعتماد على شيء ما لتحقيق تأكيد سريع للمعاملة. في هذه المرحلة من التأكيد السريع ، على الرغم من أنه يمكنك الوثوق في أن Starkware أو Scroll لن يخدعك ، إلا أنهما يشيران إلى أنه بعد تأكيد الحظر ، لن يكون هناك إعادة تنظيم. هذا هو افتراض الثقة. ويمكن أن تضيف اللامركزية بعض الضمانات الاقتصادية ، وما إلى ذلك.
ولكن بناءً على ذلك ، لا يوجد ضمان نهائي في الوقت الفعلي. بشكل أساسي ، يمكنك فرض حزم المعاملات من خلال L1 ، لكن الأمر يستغرق ساعات لحزم تلك المعاملة. لذلك على سبيل المثال ، إذا كان هناك أوراكل مسؤول عن التحديث وكان الوقت متقلبًا ، فعندئذٍ بشكل أساسي إذا تم تحديث أوراكل لمدة ساعة أو أكثر ، فلن تكون التطبيقات الموجودة في مجموعة التحديثات متاحة. تتيح لنا اللامركزية بشكل أساسي تقديم بعض الضمانات القوية المقاومة للرقابة في الوقت الفعلي ، لأنه عندئذٍ سيحتاج الخصم إلى تسوية ليس فقط كيانًا واحدًا أو مجموعة من الكيانات ، ولكن شبكة الطلبات بالكامل.
لذلك بالنسبة لنا ، تعتبر اللامركزية حلاً أكثر لتحسين تجربة المستخدم أو إصلاح الحالة الأساسية لتحديثات أوراكل ، وما إلى ذلك. بدلاً من توفير ضمانات الأمان الأساسية ، هذا ما يفعله L1.
** عبد الحميد **
نعم ، السؤال عن الفارز اللامركزي الذي ذكرته ليس تمامًا مثل L1 اللامركزي ، والذي أعتقد أنه مهم جدًا. لأنه عندما نرى بعض L1s ينتقدون أجهزة الفرز المركزية ، فإنهم لا ينظرون بشكل صحيح إلى المفاضلات التي يقوم بها الفرز المركزي.
على هذا الأساس ، أود أن أضيف شيئًا متعلقًا بتجربة المستخدم المتعلقة بالنشاط. لأنه عندما يكون لديك فارز واحد فقط ، فأنت أكثر عرضة لخطر تعطل عامل الفرز. لذلك ، يزيد الأمر اللامركزي أيضًا من المرونة والحيوية على الشبكة. ولكن حتى في سياق مركزي ، لدينا أمان جيد عندما يتعلق الأمر بالأمن. لأنه عندما يمكنك فرض معاملات الحزم من خلال L1 ، يكون الفرق بين الاثنين هو المخطط الزمني فقط. كما أن وجود فارز لامركزي يتيح لك الحصول على ضمانات سريعة لمقاومة الرقابة ، كما ذكرت توغرول. لذا ، أريد فقط أن أضيف أنه من المهم أيضًا للحيوية أن يكون لديك شبكة لامركزية من الطلبات.
** ياوقي **
أود أن أضيف شيئا. ربما يكون النشاط هو أهم شيء نحتاج إلى مراعاته في هذه المرحلة. شهدت أحدث حالات الإنزال الجوي على L2s الأكثر شيوعًا ، مثل التفاؤل و Arbitrum ، فترة توقف. لذلك ، أعتقد أن ما نحتاج إلى حله هو كيفية التعامل مع آلاف طلبات المعاملات في الثانية عندما يكون لدينا فارز واحد فقط. حتى من الناحية النظرية ، إذا كان لديك عقدة واحدة فقط ، فلن تتمكن حقًا من التعامل مع العديد من الطلبات في نفس الوقت. لذا ، فيما يتعلق بالحيوية ، نحن بالتأكيد بحاجة إلى أدوات فرز متعددة. نقطة واحدة للفشل هي عقبة حقيقية ، ليس فقط للويب 3 ، حتى Web2 يمثل مشكلة كبيرة.
أبعد من ذلك ، هناك قضية الرقابة. إذا كان لدينا منسق واحد فقط ، حتى لو رأينا أنه يمكن للفريق إدارته ، فلا يزال يتعين عليك إثبات أن الفريق لن يقوم بالفعل بمراجعة المعاملات. في بعض الأحيان يكون من الممكن والقادر على الأطراف الخبيثة إدراج بعض المعاملات في القائمة السوداء. هذا هو نظام طلب لامركزي ، يمكنهم أيضًا محاولة إرسال المعاملات من خلال الطلبات الأخرى. لهذا السبب تلقينا الكثير من الانتقادات حول أجهزة الفرز الفردية مؤخرًا.
علاوة على ذلك ، هناك بعض المشكلات الأخرى مثل MEV والتشغيل المبكر. في نظام به فارزات مركزية ، خاصة بالنسبة لبروتوكولات DeFi ، قد يتمكنوا من التحقق من mempool بسهولة. ربما ليس في شكل المرشح الأوفر حظًا ، لكن لديهم فرصة أفضل لتخريب التجارة والتحكيم فيها.
الكثير من هذه المشاكل ، لأسباب مختلفة ، على الرغم من أننا نرى أن L2 مختلفة تمامًا عن L1. لكن في النهاية ، ما زلنا بحاجة إلى جعله لامركزيًا قدر الإمكان. لذلك يتعين علينا مواجهة بعض المشكلات المماثلة التي نواجهها مع blockchains العامة أو L1.
** عبد الحميد **
نعم ، أوافق على أهمية فارز اللامركزية. لكني أريد أيضًا أن أقول ، كما نعلم جميعًا ، هذا ليس بالسؤال السهل.
أيضًا ، ** نظرًا لأن التجميعات لها بنية محددة جدًا ، مع كيانات متعددة. هناك أمر واحد نتحدث عنه ، ولكن هناك أيضًا مَثَّل ، ونحن بحاجة إلى تطبيق اللامركزية على حد سواء. ** ستكون هناك بعض المقايضات وبعض الصعوبة في كيفية تسعير المعاملات لأن هناك حاجة إلى عوامل مختلفة لتشغيل الشبكة. لذا ، كيف تسعير الصفقة؟ الفرز والمثقف لهما متطلبات مختلفة للأجهزة ، والمثل يحتاج إلى آلة فائقة القوة وما إلى ذلك. لذلك ، تعد معاملات التسعير في عالم لامركزي مشكلة صعبة للغاية ، ولهذا السبب نحتاج إلى وقت للمضي قدمًا ببطء.
لذلك سنواجه جميعًا مثل هذه المقايضة.إذا أردنا اللامركزية بسرعة ، فقد نحتاج إلى اتخاذ بعض عجلات التدريب واللامركزية تدريجياً ، لأننا إذا أردنا بشكل مباشر بنية مثالية ، فسوف يستغرق الأمر عدة سنوات. لذلك أعتقد أننا سنتخذ مقاربة براغماتية ونحاول تدريجياً تطبيق اللامركزية. على الأقل هذه هي خطتنا الحالية ، مثل البدء بآلية إجماع بسيطة لـ BFT ثم إضافة آلية إجماع أخرى على المدى القصير أو شيء من هذا القبيل. لذلك أريد فقط أن أقول ، إنه ليس سؤالاً سهلاً. لأنه من الواضح أن هناك مفاضلة بين سرعة التطوير ومدى قابلية التطبيق على البيئة اللامركزية.
** الموضوع 3 **
كيف يتم تطبيق اللامركزية على الفارز؟
** عبد الحميد **
هناك العديد من الميزات التي نريد تحقيق اللامركزية فيها ، ولكل منها مقايضات مختلفة.
على سبيل المثال ، عند تطبيق اللامركزية ، فأنت تريد تقديم نوع من آلية التوافق. في آلية التوافق ، ومع ذلك ، هناك أجزاء متعددة. الأول هو انتخاب القائد ، أي كيفية اختيار من سيقوم بإنشاء الكتل ، ومن سيكون المسؤول عن إنشاء الكتل في خانة معينة أو في غضون وقت معين. ** ما يخطط فريق Starknet للقيام به هو استخدام layer1 قدر الإمكان. وهذا يعني ، في خوارزمية انتخاب القادة لدينا ، نريد المشاركة في layer1. على سبيل المثال ، لدينا الرموز المميزة ، وسيتم التعهد على العقد الذكي لـ layer1 Ethereum ، والذي يستخدم لتحديد آلية انتخاب القائد. ** هذا يعني أننا بحاجة إلى بعض التفاعل حيث سيقوم مُنشئ L2 بالاستعلام عن عقد Ethereum الذكي لمعرفة من سيكون القائد التالي أو شيء من هذا القبيل. لذلك من الواضح أن هناك حاجة إلى نوع من العشوائية وأشياء أخرى. لذا فهو ليس سؤالًا بسيطًا. لكن هذا هو الجزء الأول. إذن أنت بحاجة إلى آلية للإجماع نفسه. هناك خيارات متعددة: إما آلية السلسلة الأطول أو BFT ، أو مزيج من الاثنين. مثل Ethereum ، لديها LMG Ghost و Casper FFG للنهاية.
لذلك قد نتبنى نهجًا عمليًا ونبدأ بـ BFT أولاً. لماذا ؟ عندما تنظر layer2 في اللامركزية ، فإن هدفنا ليس الحصول على مقياس فارز كبير مثل layer1. على سبيل المثال ، في Ethereum ، الهدف هو مشاركة الملايين من المدققين. في هذه الحالة ، لا يمكنك استخدام آلية BFT فقط ، لأنها ستكون سيئة للغاية من حيث الكفاءة ، وستتسبب في مشاكل كبيرة جدًا. على سبيل المثال ، إذا كانت هناك مشكلة في شبكة Bitcoin ، وإذا كانت آلية BFT ، فستتوقف السلسلة تمامًا. لكن هذا ليس هو الحال ، تواصل شبكة Bitcoin إنشاء كتل ، ويتم مهاجمة آلية النهاية فقط.
ولكن في الطبقة 2 ، إذا كان الهدف هو بضع مئات إلى 1000 فارز ، فقد يكون من الجيد البدء بآلية BFT. إذن ، لدينا آلية انتخاب الزعيم ، ثم الإجماع ، ثم هناك جزءان آخران ، لكنني سأترك الأمر للضيوف الآخرين لمواصلة الإضافة. لكن الجزأين الآخرين هما تحديثات الحالة وإنشاء الدليل.
خيار
أولاً ، في المستوى الثاني ، تعتبر اللامركزية مشكلة متعددة الأوجه ، كما وصفها عبد. خاصة في zkRollup ، نظرًا لوجود مُحَفِذِين وطلبات طلب ، يجب عليك التنسيق بينهما ، وعليك إلغاء مركزية كليهما. هذه المشكلة مختلفة تمامًا عن L1.
الفرق الآخر هو أنه في L2 ، كل تصميمك هو إقناع الجسر الأساسي بأن الإجماع صحيح ، وليس لإقناع أي عدد من العقد الأخرى. من الواضح أنك يجب أن تفعل الشيء نفسه ، ولكن يجب أن يكون تركيزك الأساسي على الجسر نفسه.
حاليا ، نحن نعمل في اتجاهين مختلفين. رقم واحد ، أعتقد ، مثل أي شخص آخر ، نحن نعمل على بروتوكول BFT. هذا ليس فعالًا للغاية وهناك بعض مكامن الخلل التي يجب حلها. لقد توصلنا إلى حل تقريبي ، لكنه لا يزال غير مثالي. على سبيل المثال ، أحد الأسئلة هو ، كيف يمكنك الموازنة بين الحوافز بين أدوات الفرز والمحققين؟ نظرًا لأن الأمر يتحكم في MEV ، ولا يستطيع المُثبِّت الوصول إلى MEV ، فهناك حافز للأشخاص لتشغيل الأمر بدلاً من المُثبِّت. لكن في الواقع ، نحن بحاجة إلى عدد أكبر من المحفزات أكثر من الطلبات ، فكيف يمكنك موازنة الحوافز بين الاثنين؟ هذه واحدة من تلك المشاكل.
الحل الثاني الذي نعمل عليه هو اتجاه آخر. تذكر أن الأشياء قد تتغير. مقترحات جديدة تخرج كل يوم. على سبيل المثال ، كان هناك الكثير من الحديث مؤخرًا حول تجميع البيانات على أساس وكيف يمكنك الاستعانة بمصادر خارجية لفرز L1. الاتجاه الثاني هو التخلص من الفارز تمامًا واستخدام بعض المنشئ الخارجي. على سبيل المثال ، يقترح صانعو الإيثيريوم أو Flashbots SUAVE وما إلى ذلك الكتل المرتبة ثم يُجرون الإجماع داخل المُثقف. الميزة هنا هي أنك لست مضطرًا للتعامل مع الحوافز لأنه يمكنك بشكل أساسي استخدام دعم السلوك الإيجابي داخل البروتوكول ويقوم بإنشاء بروتوكول أبسط. لكن العيب هو أنه نظرًا لأننا نحتاج إلى عدد كبير من المحفزات (لأنه يمكننا إثبات ذلك بالتوازي) ، فمن الصعب جدًا تشغيل بروتوكول BFT كلاسيكي معهم. لذا فإن السؤال هو كيف يمكنك تحسين بروتوكول BFT الحالي ليعمل مع المئات ، أو حتى الآلاف ، من المحققين؟ وهذا ليس سؤالاً سهلاً للإجابة عليه.
هل تقديم إجماع L2 ضروري لمنظم لامركزي؟
** ياوقي **
يمكنني الإجابة على هذا السؤال تقريبًا لأننا طرحنا مؤخرًا شيئًا من هذا القبيل.
لذا فإن تقديم الإجماع لا يعتمد على ما إذا كنا نريده أم لا. بمجرد أن يكون لديك العديد من الطلبات أو حتى مجرد عقد ، عليك أن تجعلهم يوافقون. حقا يعتمد على افتراضاتك. إذا كان افتراضًا بيزنطيًا ، فيمكننا استخدام BFT أو أي بروتوكول إجماع بيزنطي موجود. إذا كان إعدادًا غير بيزنطي ، على سبيل المثال ، إذا افترضنا فقط أن العقدة يمكن أن تكون متصلة وغير متصلة بالإنترنت فقط ، وأنه لا يمكنها التصرف بشكل ضار ، فيمكننا استخدام بروتوكول Raft أو بروتوكول إجماع آخر أسرع. لكن على أي حال ، إذا كان لدينا مجموعة من الطلبات أو المحققين ، إذا أردنا تنظيمهم معًا لإنتاج الكتل على مدار فترة زمنية ، فيجب أن يكون لديك بروتوكول إجماع حولهم.
لذلك ، كما ذكر توغرول وعبدال للتو ، أعتقد أن هناك الكثير من المقترحات وموضوعات البحث حول كيفية تنفيذ نظام ترتيب أو إثبات لامركزي. لذلك ، نظرًا لأننا أطلقنا للتو testnet لنظام تجميع متعدد الفرز (حاليًا يدعم فقط إثباتات الاحتيال للتجميعات المتفائلة) ، بناءً على خبرتنا في التصميم والتنفيذ ، هناك بعض الأشياء التي يمكنني مشاركتها حول الصعوبات. وكما ذكر توغرول للتو ، فإن الصعوبة لا تكمن في بروتوكول الإجماع نفسه ، فالصعوبة الحقيقية تكمن في أشياء أخرى غير ذلك ، مثل جزء الإثبات. لأنه إذا كان فارزًا واحدًا ، فلن تحتاج إلى العديد من العقد. يمكننا اعتبارها آلة افتراضية ، آلة افتراضية. لذا ، ما عليك سوى إحضار المعاملات وتنفيذها ، وإجراء انتقالات الحالة. المُثبِت مسؤول عن إنشاء البراهين لانتقال الحالة لمجموعة المعاملات السابقة. ومع ذلك ، إذا قمنا بتشغيل بروتوكول الإجماع للمضارب والمثقف على التراكمي ، فإننا نحتاج إلى تقديم منطق إجماع إضافي هناك. علاوة على ذلك ، تحتاج أيضًا إلى نظام إثبات لبروتوكول الإجماع. لذلك ، سيقدم هذا الكثير من العمل ليقوم نظام الإثبات بإنشائه. ثم بمجرد إنشاء الدليل ، يمكنك التحقق منه بسهولة على L1 Ethereum.
لهذا السبب بطريقة ما ، عندما أطلقنا أول شبكة اختبار متعددة الطلبات ، كان للتجميع المتفائل بعض المزايا في هذا الصدد. بشكل عام ، يمكنك تبسيط الكثير من الأشياء ، مثل عدم مراعاة جزء إثبات الصلاحية. مثلنا ، نقارن كل شيء بشكل أساسي بـ WASM. لذا فهي في النهاية تعليمات WASM. لذلك ، من خلال التحقق من تعليمات WASM هذه ، من السهل نسبيًا التحقق باستخدام كود Solidity. إذا قمنا للتو بإعادة تنفيذ جميع تفسيرات تعليمات WASM على Ethereum.
لكن بشكل عام ، المشكلة ليست مشكلة فردية. إذا كان لدينا حل للمشكلة ، فسيكون هناك بعض أعمال المتابعة الأخرى التي يجب حلها في نفس الوقت. بالطبع ، ستكون هناك مشكلات MEV ، مثل كيفية توزيع MEV بشكل عادل. يمكنك تعيين جميع الطلبات والمثبتات بناءً على ما إذا كانوا قد قاموا بإنشاء كتلة أو التحقق من صحة كتلة. لكن في النهاية ، إنها في الحقيقة مزيج من العديد من القضايا ، ليس فقط القضايا التقنية ، ولكن الحوافز الاقتصادية أيضًا.
وعلينا أن نتذكر أن L2 مقترح لأننا نريد تقليل تكلفة الغاز بشكل كبير. لذلك لا يمكن أن يكون لدينا الكثير من العقد. حتى في إنشاء البراهين ، قد تكون L2 أغلى من L1. لذلك نحتاج حقًا إلى التوصل إلى نهج متوازن لهذا النوع من المشاكل.
** عبد الحميد **
أود أن أضيف نقطة أخرى. أولاً ، لا يوجد حاليًا دليل فعلي غير مصرح به على الاحتيال من أجل التراكم المتفائل. وما زلت أؤكد على هذا في كل فرصة أتيحت لي ، لأنه من المهم أن نكون صادقين بشأن هذا عند المقارنة. لذا فهم ليسوا L2 على الإطلاق. هذا أول شيء.
ثم أود أن أضيف شيئًا عن عدم التزامن بين الفرز والبراهين ، لأنه مهم جدًا. كما قلت ، نريد تحسين الفرز ، لأن هذا يمثل حاليًا عنق الزجاجة لجميع الحلول. لكن هذا جيد في سياق الفرز المركزي ، لأننا نعلم أن أداة الفرز ستنتج انتقالات قيمة فقط وسنكون قادرين على التحقق منها. لكن سيكون الأمر أكثر صعوبة في سياق النوع اللامركزي ، لأنه ربما يكون فارزك قادرًا على إنتاج شيء لا يمكن التحقق منه. ثم ستحتاج إلى التعامل مع ذلك لاحقًا.
في سياق الفرز المركزي ، لتحسين الفرز ، نظرًا لأنه لا يتعين علينا إنشاء البراهين أثناء عملية الفرز ، يمكننا محاولة القيام بذلك بالسرعة المحلية ، وهو ما نريد القيام به. قم بترجمة القاهرة إلى لغة آلية منخفضة المستوى مثل LLVM وقم بتشغيلها بسرعة فائقة على الفارز. ثم يمكنك أن تثبت بشكل غير متزامن. وأروع شيء في البراهين هو أنه يمكنك القيام بها بالتوازي. يتم تحقيق التوازي الهائل من خلال إثبات أن العودية ممكنة. لهذا السبب سنتمكن من اللحاق بسرعة الفارز. لكن الأمر صعب عندما يكون لامركزيًا ، لأننا نحتاج إلى التأكد من أن المنظم ينتج انتقالات حالة صالحة فقط.
خيار
سأضيف أنني لست متأكدًا مما يفعله Starknet هنا. لكن بالنسبة لنا ، أعتقد أنه من الافتراضات العامة لكل zkRollup أنه إذا قمت بإضفاء اللامركزية على الفارز ، يجب أن يكون نظام الإثبات الخاص بك قادرًا على التعامل مع الدُفعات غير الصالحة. لذلك ، بشكل أساسي ، إذا قمت ، على سبيل المثال ، بإرسال دفعة بتوقيع غير صالح ، فيجب أن تكون قادرًا على إثبات أن الحالة الناتجة تعادل حالة البداية. لذلك سيكون هناك بعض الحمل في كلتا الحالتين. يتعلق الأمر بكيفية تقليل احتمالية حدوث ذلك.
** عبد الحميد **
نعم هذا صحيح. لهذا السبب قدمنا سييرا في القاهرة 1 لجعل كل شيء قابل للتحقق. سيضمن هذا التمثيل الوسيط أن كل برنامج كايرو 1 يمكن التحقق منه حتى نتمكن من تضمين معاملة عائدة.
ما هو أساس التراكمية؟
** ياوقي **
جاء التجميع المستند في الأصل من منشور مدونة بواسطة Justin Drake في منتديات Ethereum. تتمثل إحدى أفكاره في أنه يمكننا إعادة استخدام بعض أدوات التحقق من Ethereum للتحقق من معاملات التجميع ، بحيث لا نحتاج إلى مجموعة منفصلة من العقد للتحقق من معاملات التجميع المختلفة. على وجه الخصوص ، سيكون لدينا العديد من القوائم في المستقبل ، بما في ذلك المجموعات العامة للأغراض العامة والعديد من المجموعات الخاصة بالتطبيقات. لذلك ، في هذه الحالة ، سيكون رائعًا إذا تمكنا من العثور على مكان مشترك مثل مجموعة التحقق من Ethereum للتحقق من صحة هذه المعاملات.
بالطبع ، هذه مجرد فكرة ، لأنها تقدم أيضًا الكثير من الصعوبات الفنية. على سبيل المثال ، من الناحية النظرية ، يمكننا أن نطلب مدققي Ethereum للتحقق من معاملات التجميع ، ولكن من الصعب جدًا الحصول على منطق التحقق من المجموعات المجمعة أو المضمنة في بروتوكول Ethereum نفسه. نحن نسمي هذا التحقق داخل البروتوكول ، والذي يتطلب شوكة صلبة لعقد Ethereum. بالطبع ، في هذه الحالة ، يمكننا التحقق من بعض معاملات التجميع. ولكن إذا فعلنا ذلك ، فسترى المشاكل. يشبه الأمر إلى حد ما أننا نريد مجموعة L2 لمشاركة ضغط Ethereum ، ولكن في النهاية ما زلنا نطلب من مدققي Ethereum أن يقوموا ببعض الأعمال التي تم تفريغها إلى L2. لذا يتحدث الكثير من الناس عن كيفية القيام بذلك.
ثم تحدثنا إلى Barnabe ، الباحث في مؤسسة Ethereum الذي يعمل حاليًا على PBS. هذا اقتراح من Ethereum ، والذي يقضي بتقسيم مهمة المدققين إلى أدوار متعددة وبناة وعارضين. الآن لدينا Flashbots لتولي دور البناة في PBS ، فهم يؤلفون كل الكتل ويرسلونها إلى عروض Ethereum. لذلك بمجرد تجميع هذه الكتل في شبكة Ethereum ، سيحصل البناة أيضًا على بعض المكافآت. ثم في هذه الحالة ، كيف تكافئ هؤلاء المدققين من شبكة Ethereum؟ كما أنهم مسؤولون عن التحقق من صحة مجموعة التحديثات.
أحد الحلول هو "الاستعادة" ، والذي ربما تكون قد سمعته كثيرًا من EigenLayer أو بعض البروتوكولات الأخرى. يمكن للمستخدمين إعادة مشاركة ETH على شبكات الفرز الأخرى. أو قم بمكافأة مدققي Ethereum على تشغيل البرنامج فعليًا للقيام بعمل التحقق من صحة مجموعة التحديثات. في هذه الحالة ، يمكن مكافأتهم من المستوى 2 ومن خلال بروتوكول إعادة التخزين. كانت هناك العديد من المقترحات لهذا حتى الآن ، ولكن بشكل عام إنها فكرة عن كيفية التمكن من إعادة توظيف مدققي Ethereum الحاليين. كيف يمكننا إعادة استخدام ETH الحالي للمساعدة في الدخول في عصر جديد من أنظمة التجميع أو L2؟ لذلك فهي تحاول بشكل أساسي تبسيط الكثير من الأشياء لمشروع التجميع. إذا أرادت مجموعة التحديثات نوعًا جديدًا من الفرز ، إذا كانوا يريدون مصدرًا جديدًا للضمانات ، فيمكنهم إعادة استخدام البنية التحتية الحالية أو الضمانات الحالية. لهذا السبب تم بناؤه فوق Ethereum ، ومن ثم يمكن إعادة استخدام المزيد من البنية التحتية والتخزين للتجميع و L2 أيضًا.
عيوب جهاز التسلسل المشترك والتجميع المستند إلى سيناريوهات التطبيقات الخاصة بهم.
خيار
أريد تقديم شكوى بشأن هذا الاقتراح ، لست مقتنعًا بالاقتراح المتعلق بجهاز التسلسل المشترك. بالطبع ، ما زالوا في مهدهم ، وإذا تحسنت هذه التصميمات في المستقبل ، فمن الممكن تمامًا أن أؤيدهم. الأمر مجرد أن الشكل الحالي غير مقنع بالنسبة لي. هناك العديد من الأسباب.
أولاً ، بالنسبة لي ، يتمثل عرض القيمة الرئيسي لجهاز الفرز المشترك في السماح للمستخدمين باكتساب قابلية التركيب الذري بين تجميعات الأغراض العامة مثل Scroll أو Starknet. لكن المشكلة هي أنه إذا كانت لديك قابلية تكوين ذرية ، فإن مجموعة التحديثات الخاصة بك تكون نهائية مثل أبطأ مجموعة تتكامل معها. لذلك ، بافتراض دمج Scroll مع Optimistic Rollup ، ستكون النهاية النهائية لـ Scroll سبعة أيام. بينما يتمثل عرض القيمة الرئيسي لـ ZKRollup في تحقيق نهائية سريعة نسبيًا ، يمكن للمستخدمين الانسحاب إلى L1 في غضون دقائق. وفي هذه الحالة ، التخلي عن ذلك أساسًا.
الجانب السلبي الآخر هو أنك إذا كنت تريد نهائية خارج السلسلة ، فأنت بحاجة إلى تشغيل عقدة L2 ، وطالما تم الانتهاء من البيانات المرسلة إلى السلسلة بواسطة L1 ، فستحصل على نهائية محليًا في L2. إذا لم تقم كل L2 مدمجة بتشغيل عقدة كاملة ، فمن المستحيل عمليا تحقيق الإنهاء المحلي. هذا يعني أن تشغيل هذا النظام يمكن أن يكون أكثر تكلفة من تشغيل نظام مثل Solana ، لأن لديك عدة عقد كاملة تعمل في نفس الوقت ، بنفقاتها العامة الخاصة وما إلى ذلك.
لذلك ، لهذه الأسباب ، لا أعتقد أنه من المنطقي بالنسبة لـ L2. الأمر مختلف قليلاً بالنسبة لـ L3 ، لأنه إذا أراد شخص ما إنشاء سلسلة خاصة بالتطبيق ولا يريد التعامل مع اللامركزية. لنفترض أنني أقوم ببناء لعبة وأريد فقط التعامل مع بناء اللعبة ، ثم يمكنني الاستعانة بمصادر خارجية للعمل اللامركزي. لكنني لا أعتقد أنه من المنطقي بالنسبة لـ L2 في الوقت الحالي.
بالنسبة إلى التراكمية القائمة ، لدي أيضًا مخاوف لدي. على سبيل المثال ، كيف تشارك أرباح MEV مع المحققين؟ لأنه إذا لم يتم النظر في مشكلة التخصيص ، فيمكن أن تحصل L1 بشكل أساسي على جميع أرباح MEV. شيء صغير آخر هو أن وقت التأكيد الخاص به يساوي وقت التأكيد L1 ، وهو 12 دقيقة ، والذي لا يمكن أن يكون أسرع. هناك مشكلة أخرى تتمثل في أنه نظرًا لعدم وجود إذن ، يمكن للعديد من الباحثين إرسال دفعات المعاملات في نفس الوقت ، مما يعني أنه قد ينتهي الأمر بنتائج مركزية. لأن البناة يتم تحفيزهم لتضمين معاملاتهم إذا كان أحد الباحثين يتواصل بسهولة أكبر من الآخرين. لذلك ، قد يؤدي ذلك إلى قيام باحث واحد فقط باقتراح دفعات لـ L2 في النهاية ، وهذا ليس حلاً جيدًا للغاية ، لأنه إذا حدث ذلك ، فإننا نعود أساسًا إلى المربع الأول.
** ياوقي **
من المثير للاهتمام ، أنني تلقيت مكالمة مع Ben ، مؤسس Espresso ، في الواقع الأسبوع الماضي. نناقش هذا كثيرًا في موضوع الفرز المشترك. كما ذكر توغرول ، أعتقد أن هناك بعض عدم اليقين بشأن سيناريوهات الاستخدام لنظام الطلب المشترك. هذا يرجع أساسًا إلى أنه بالنسبة إلى L2 للأغراض العامة ، ليس لدينا عادةً عدد كبير من أجهزة الفرز بسبب الكفاءة والتعقيد والاقتصاد. وما زلت أشعر أنه سواء كان ذلك من أجل جهاز التسلسل المشترك ، أو التجميع القائم ، أو الاستراحة ، فإن أفضل حالة استخدام هي في الغالب لـ RAS (Rollup as a Service) أو مثل هذه الأنظمة الأساسية حيث يمكننا طرح الكثير من التجميعات. لا نحتاج حقًا إلى شبكة فرز كبيرة لنكون صادقين إذا لم يكن هناك العديد من التجميعات. هذه المجموعات لديها بالفعل أنظمة الفرز الخاصة بها ، ولديها بالفعل مجتمعاتها الخاصة أو شركائها ، عندما لا يكون هناك سوى بعض L2s العامة. لا يحتاجون حقًا إلى شبكة منفصلة وطرف ثالث. أيضًا ، يعد هذا عبئًا على شبكة الطرف الثالث ، لأنه يتعين عليك التخصيص لكل L2 ، ولكل L2 مجموعة اختبار مختلفة. هذا يتطلب الكثير من التغييرات على شبكتك الخاصة.
لكن في نفس الوقت ، كما ذكر توغرول ، لبعض حالات الاستخدام الخاصة. على سبيل المثال ، إذا أردنا أن يكون لدينا بعض قابلية التشغيل البيني على مستوى الفارز ، يمكن أن تكون أدوات الفرز المشتركة طريقة محتملة للعمل. على سبيل المثال ، يتم استخدام نفس فارز البيانات المتعددة. في هذه الحالة ، يمكن لهذا الفرز التعامل بشكل أساسي مع بعض معاملات التجميع المتقاطع لضمان الذرية المتقاطعة بين التجميع A و B و C.
ولكن يمكنك أيضًا رؤية المشكلة هنا عندما أصف الموقف. إذا كان لدينا بالفعل العديد من هذه المتسلسلات المشتركة ، فإنها ستصبح مرة أخرى عنق زجاجة ونقطة فشل واحدة جديدة. نحن نعطي الكثير من القوة لمن يسمون بالطلبات المشتركة. لقد أصبحوا أشبه بشبكة ، حيث يتحكمون في العديد من مجموعات التحديثات. أخيرًا ، نحتاج مرة أخرى إلى التوصل إلى طريقة لإضفاء اللامركزية على هذا الفرز المشترك.
لكن على أي حال ، أعتقد أنه من الجيد أن يكتشف الناس تدريجيًا المزيد والمزيد من المشاكل ويتوصلون إلى المزيد والمزيد من الحلول. بشكل عام ، من المثير رؤية كل ما هو جديد في هذا المجال كل يوم. مع كل هذه الحلول الجديدة ، نحن على الأقل نسير على الطريق الصحيح لإضفاء اللامركزية حقًا على مساحة التجميع بالكامل.
** عبد **
نعم ، أنا أتفق معكما. أعتقد أنه من المنطقي أكثر لـ Layer3 و Lisk لأنهم لا يريدون تحمل مسؤولية تحفيز شبكة لامركزية بعد الآن ويحتاجون إلى إيجاد شركاء لبدء أشياء مثل أدوات الفرز. لذلك أعتقد أنه من المنطقي بالنسبة لـ Lisk. ولكن مثل توغرول ، لا أعتقد أن هذا منطقي جدًا بالنسبة إلى Layer2 حتى الآن.
** الموضوع 4 **
ما هو تأثير الأمر اللامركزي على MEV؟
** عبد **
بالنسبة إلى Starknet ، في سياق المركزية ، لا نقوم بأي نوع من MEV ، ونعتمد نموذجًا لمن يأتي أولاً يخدم أولاً. وهذا يعني أنه في سياق اللامركزية ، بالطبع ، سيتم جلب المزيد من MEV في وقت لاحق. لكن من السابق لأوانه تحديد النسبة ، لأنها تعتمد أيضًا على تصميم آلية التوافق والجوانب الأخرى.
خيار
ولكن الشيء هو ، حتى لو لم تفعل MEV ، فقد يكون هناك بعض MEV لا يزال يحدث في Starknet. حسنًا ، لا تؤدي اللامركزية في حد ذاتها إلى تقليل MEV أو زيادة MEV. بالطبع ، إذا قمت بتطبيق نوع من بروتوكول الطلب العادل أو تشفير العتبة ، على سبيل المثال ، فعندئذٍ نعم ، فإنك تقلل MEV. لكن لا يمكنك القضاء عليه تمامًا. فلسفتي هي: MEV لا يمكن القضاء عليها. لكن لنفترض أنك تقوم للتو بإنشاء إجماع BFT ، أو تبني شيئًا ما فوق إجماع BFT. هذا في الواقع لا يؤثر على MEV على الإطلاق. لا يزال MEV موجودًا ، يجب أن يكون السؤال عن كيفية عمل الباحث مع الفارز لاستخراج MEV.
** ياوقي **
المشكلة هي أنه حتى نموذج من يأتي أولاً يخدم أولاً به أجزاء صعبة. بمجرد أن نكشف عن mempool لبعض الباحثين ، لا يزال لديهم ميزة اللعب أكثر. على سبيل المثال ، بالنسبة لأجهزة التسلسل ، فهي تعادل الانتظار عند باب مكتبك. لذلك في هذه الحالة ، بمجرد أن يروا نوعًا من فرصة المراجحة ، ليس فقط حول التشغيل الأمامي أو هجوم الساندويتش ، بمجرد أن يرسل المستخدم معاملة ، يمكنهم رؤيتها على الفور في mempool. لذلك ، يمكنهم وضع تداولاتهم بسرعة قبل الآخرين. لذلك ، لديهم ميزة على الباحثين الآخرين.
لكن بالعودة إلى اللامركزية ، أعتقد أن الأمر يتعلق في الغالب بمقاومة الرقابة ، كما ناقشنا في البداية. يدير الفريق أجهزة التسلسل. يمكن للفريق أن يقول إنه عادل للجميع. لكن هذا لا يمنع في الكود. لذا ، إذا كان بإمكاننا الحصول على شبكة P2P ، فسيكون رائعًا إذا شعرنا أن هذه العقد تفحص معاملاتي ومن ثم يمكننا إرسالها إلى العقد الأخرى. لذلك ، يتعلق الأمر حقًا بإنصاف معالجة المعاملات في L2.
بالنسبة إلى MEVs ، لأنه في الآونة الأخيرة ، بالإضافة إلى MEVs التي تم إنشاؤها ضمن مجموعة واحدة ، هناك بعض MEVs التي تم إنشاؤها عبر الجسور. في شبكة الفرز اللامركزية نسبيًا ، سيكون لديك المزيد من الفرص لاستخراج MEV. بافتراض أن لدينا شبكة أوامر مشتركة ، إذا كان بإمكانك بطريقة ما التأثير على الأمر المشترك لإعادة ترتيب المعاملات ، فأنت تمتلك ميزة كبيرة على أي شخص آخر.
هناك مزايا وعيوب لشبكة التسلسل المشتركة. على الجانب الإيجابي ، يمكننا زيادة اللامركزية في نظام التصنيف. ولكن على الجانب الآخر ، كل شخص لديه الفرصة ليكون فارزًا. لذلك ، يمكنهم في الأساس فعل ما يريدون ، وهي غابة مظلمة مرة أخرى. لذلك ، قدمنا اللامركزية ، ومن ثم كان علينا أن نواجه مشكلات مماثلة واجهناها في Ethereum. لهذا السبب يريد Flashbots و Ethereum Foundation المضي قدمًا مع PBS ، والعروض المنفصلة والبناة ، ثم محاولة الحصول على حل واحد من جانب المنشئ.
لذلك عندما ننظر إلى المشكلة ، فهي ليست مشكلة واحدة فقط. لم تعد مشكلة فردية ، بل مشكلة شخص لشخص ، وأكثر من ذلك.