ما هي المشكلة التي تريد Layer2 حلها؟ كيفية تحديد التراكمية الآمنة واللامركزية؟
مقدمة
عندما ننظر إلى الرؤية وخريطة الطريق لمختلف حلول Rollup ، سنجد أن جميع Rollups تقريبًا لها هدف نهائي. إذا تم تكثيف هذا الهدف في جملة واحدة: بناء كومة تقنية ، وتقديمها إلى المجتمع ، وحل مشكلة التوسع blockchain ، وفي النهاية اللامركزية في مجموعة التكنولوجيا للعمليات والحوكمة. هذا يؤدي إلى مصطلح التراكمية اللامركزية.
إذن ما هي اللامركزية بالضبط؟ ما هو تقسيم العمل بين مختلف أجزاء نظام التراكمية؟ هل تعني اللامركزية تعظيم المشاركين في تشغيل النظام؟ ما هو تأثير فارز مركزي؟ كيف ينبغي تصميم نظام الطلب المشترك والإجماع المحلي L2؟ ما هي وظيفة المُثبِت الفريد في ZK-Rollup؟ كيف ستبدو شبكة المثقفين اللامركزية المفتوحة؟ لماذا نحتاج تسريع أجهزة zk؟ ما هو الحل لمشكلة توافر البيانات؟ ....
هناك مناقشات لا حصر لها حول التراكمية اللامركزية في المجتمع ، لذلك نظمت شبكة الاتصالات الإلكترونية (ECN) سلسلة من المقابلات الصوتية مع موضوع "اللامركزية التراكمية" ، ودعت المؤسسين والباحثين البارزين في هذا المجال للحديث عن فهمهم للتفاهم اللامركزي.
دعا العدد الأول باتريك ماكوري ، الباحث من مؤسسة Arbitrum Foundation. هذه الحلقة بمثابة ملخص للمسلسل ، وتتحدث بشكل أساسي عن المشكلات التي تريد الطبقة الثانية حلها ، ومعنى التراكمية اللامركزية ، وكيفية فهم سماتها الأمنية ، وكيف حوكمة DAO تعمل في التراكم اللامركزي.
ضيف هذه الحلقة: باتريك ماكوري ، twitter @ stonecoldpat0
المنسق: Franci، twitter @ FrancixDeng
جَرَّار
المرحلة 2: المُسلسل المشترك وإجماع L2
ياو تشي ، مؤسس شبكة AltLayer
باحث في التمرير توغرول محرموف
قائد التنقيب في StarkNet عبد الحميد بخطة
المشكلة 3: شبكة Prover وتسريع أجهزة zk
يي تشانغ ، المؤسس المشارك لـ Scroll
ليو فان ، المؤسس المشارك لشركة Cysic
المشكلة 4: توافر البيانات والتخزين اللامركزي
Qi Zhou ، مؤسس EthStorage
يستمع
انقر للاشتراك في البودكاست لمعرفة المزيد:
موقع YouTube:
عالم مصغر:
** الطابع الزمني **
01:49 مقدمة شخصية باتريك ماكوري
03:26 لماذا توجد layer2 وما الذي تحاول حله؟
11:56 ما هي الأسلحة التي يستخدمونها للحفاظ على سلامة المستخدمين؟
14:40 ماذا تعني سلامة وحيوية التراكمية
17:47 اشرح أمان التراكم من توافر البيانات وصلاحية انتقال الحالة ومكافحة الرقابة
19:45 دور الكيان الوحيد الصادق ، الذي يعمل ككيان واحد صادق للتجميع؟
28:47 ما رأيك في التراكم اللامركزي؟ ما هو الهدف الأكثر إلحاحًا في الوقت الحالي؟
37:21 أهمية حوكمة DAO في تجميع اللامركزية
** قسم المقابلة **
** مشاكل Layer2 تريد حلها **
فرانشي: ما سنستكشفه في هذه الحلقة هو ، ما الذي يعنيه وجود تراكم لامركزي؟ لماذا هو مهم ما المشكلة التي يحاولون حلها؟ آمل أنه من خلال هذا الحديث ، يمكن للقراء والمستمعين أن يفهموا أخيرًا ما هو التراكم اللامركزي الحقيقي والأهداف التي يجب عليهم تحقيقها. دع ضيفنا ، باتريك ماكوري ، يقدم نفسه.
باتريك: مرحباً بالجميع. أعتقد من التجربة أنني منحاز نحو البحث الأكاديمي. من عام 2013 إلى عام 2016 ، كان اتجاه الدكتوراه الخاص بي مرتبطًا ببيتكوين وإيثريوم. ثم من عام 2016 إلى عام 2019 تقريبًا ، كنت باحثًا في جامعات مثل UCL و King's College London و UIUC. خلال هذا الوقت ، كنت مهتمًا جدًا ببروتوكولات الطبقة الثانية. بما في ذلك Bitcoin Lightning Network والبلازما وبالطبع Rollup. لذلك في عام 2019 ، حاولت بدء تشغيل. ثم تركت الكلية ، أنا وصديقي ، شخصان وكلب. نحاول أن نكون شركة ناشئة تركز على layer2. لكنها كانت سوقًا هابطة ، ثم استحوذت علينا Infura. ثم غادرت Infura وانضممت مؤخرًا إلى مؤسسة Arbitrum. لذلك عدت للتركيز على البحث التراكمي بدوام كامل. خلال هذه الفترة بأكملها ، ركزت بشكل أساسي على التعليم ، وشرح لماذا يجب أن نهتم ببروتوكولات الطبقة الثانية.
فرانسي: لنبدأ بالمواضيع الأساسية. بشكل عام ، ما هو نظام L2؟ ماذا يعني قيام المستخدم بإيداع الأموال في نظام L2 وإجراء معاملة هناك؟
باتريك: بالحديث عن هذه المشكلة ، أعتقد أننا بحاجة إلى التراجع والتفكير ، ما هو الهدف من blockchain؟ ما الهدف من كل هذه الأنظمة التي نحاول بناءها؟ بمجرد أن نفكر في هذا ، يصبح من المنطقي أن نشرح L2. الشيء الحقيقي وراء شبكة blockchain مثل Bitcoin أو Ethereum هو مجرد قاعدة بيانات. هي قاعدة بيانات عامة يمكن لأي شخص قراءتها والكتابة إليها. لذلك ، فهي قاعدة بيانات لأرصدة الحسابات ، وبالطبع ، في Ethereum ، هناك العديد من البرامج إلى جانب أرصدة الحسابات. لذا يمكنني نشر الكود الخاص بي في قاعدة البيانات. يمكن أن يكون لبرنامجي حالة معينة ويمكنني إجراء معاملات عليه ، ويمكن للجميع رؤية التحديثات لقاعدة البيانات. في الأساس ، نحن نتعامل فقط مع قواعد البيانات. يبدو مملا.
وأهمية blockchain نفسها ، إنها في الحقيقة مجرد مسار تدقيق. لذلك يخزن قائمة المعاملات ، وإذا أعطيتك نسخة من blockchain ، يمكنك إعادة حساب قاعدة البيانات هذه بنفسك. في الأساس ، نحن نبني قاعدة بيانات عامة يمكن لأي شخص قراءتها وحسابها والكتابة إليها بشكل مستقل. حسنًا ، هذا هو layer1.
سواء كانت Bitcoin أو Ethereum layer1 ، فإن المشكلة هي أنها تحتاج إلى تعظيم اللامركزية. هناك ثلاث طرق مختلفة للتفكير في اللامركزية. الأول هو المشغل: من يدير الشبكة ، ومن ينتج الكتل ، ومن يؤكد المعاملات. مع العديد من هذه الشبكات ، نرغب دائمًا في تعظيم إمكانية مشاركة أي شخص في العملية. بهذه الطريقة لا توجد نقطة واحدة للفشل. من ناحية أخرى ، تحتاج أيضًا إلى التفكير في من يمكنه التحقق من كل تحديث لقاعدة البيانات ، ومن يمكنه التحقق من أن المشغلين يقومون بعملهم ، وأن قاعدة البيانات صحيحة ، وما إذا كانت هناك مشكلات أخرى. عملهم وقواعد بياناتهم صحيحة وصالحة في جميع الأوقات. في هذه المرحلة ، سيكون لديك هذا الشبك. تريد زيادة عدد الأشخاص المشاركين في التحقق من الشبكة ، وتريد زيادة عدد الأشخاص الذين يقومون بتشغيل الشبكة. لذا ، فهي تشبه نوعًا ما قتال حجم كتلة البيتكوين القديم. قم بتحديث الكتل ويمكنك معالجة المزيد من المعاملات. ولكن بعد ذلك سيكون الأمر أكثر صعوبة ، لأنك بحاجة إلى متطلبات أجهزة أعلى للتحقق من الشبكة في الوقت الفعلي ، وأخيرًا تصبح مشغل شبكة. هذا هو السؤال عن كيفية النظر في اللامركزية على مستوى الطبقة 1. الجانب الثالث هو جعلها في متناول الجميع. إذا دفعنا 200 دولار أمريكي للمعاملات على شبكة ، فهل هي حقًا لا مركزية؟ يبدو أنه ليس كذلك. لذلك ، بمعنى ما ، هذه مشكلة ثلاثية متخلفة من التاريخ.
لقد علقنا لفترة طويلة مع هذه الثلاثية ، لأنه إذا حاولت معالجة المزيد من المعاملات ، فسوف يتضرر أحد الأطراف بطريقة ما ، إما أن ترتفع الرسوم ، أو ترتفع متطلبات الأجهزة ، أو تصبح جاهزة للعمل أكثر صعوبة. هذه مناقشة للامركزية في سياق L1.
فرانسي: كما قلت ، سينظر المستخدمون في تكلفة المعاملات. ثم قد يختارون إيداع أموالهم في بورصة مركزية. بشكل عام ، هل هذا نوع من L2؟
باتريك: أعتقد أنها طريقة جيدة للتفكير في الأمر من منظور التبادلات. التبادل المركزي يشبه قاعدة البيانات. لكن المشكلة هي أنها قاعدة بيانات خاصة. إذن قاعدة بيانات التبادل هي فقط القادرة على القراءة والكتابة. والمستخدمون مثلك ومثلي ، لا يمكننا تدقيق قاعدة البيانات هذه ، ولا يمكننا التحقق من صحتها. لكن ميزة التداول في البورصة هي أنها رخيصة جدًا. الغرض من نظام L1 blockchain هو أن يكون لامركزيًا قدر الإمكان ، لكن التكلفة مرتفعة للغاية.
لذلك عندما نفكر في عالم L2 ، في عالم L2 ، لا نريد حقًا إعادة إنشاء L1. لا نريد حقًا أن نضطر إلى بناء شبكة لامركزية تزيد من عدد المشاركين. لأننا نعلم بالفعل أنه ، تاريخيًا ، كان من الصعب جدًا بناء هذه الأنواع من الأنظمة وجعلها تتوسع كثيرًا من حيث الإنتاجية. لذلك نعتقد ، هل يمكننا بناء نظام يشبه التبادل ، لكنه لا يزال يحتفظ بخصائص نظام blockchain ، حيث تكون قاعدة البيانات عامة؟ يمكن لأي شخص قراءة قاعدة البيانات ، ويمكن لأي شخص الكتابة إليها ، ويمكن لأي شخص حمايتها. هذا هو هدف L2.
عندما تبدأ في مقارنة التبادلات بما قمنا ببنائه في L2 ، فإننا في نهاية اليوم نقارن عناصر هندسة الجسور. الجسر الذي أتحدث عنه هو أنه سيكون هناك عقد ذكي على Ethereum ، وأنا أقفل الأصول في هذا العقد الذكي المسمى "الجسر". بمجرد قفله على الجسر ، سيظهر في قواعد البيانات الأخرى. يمكن أن تكون قاعدة البيانات هذه Coinbase ، أو Arbitrum ، أو التفاؤل. ثم السؤال هو ، عندما أرغب في سحب أموالي من قاعدة البيانات الأخرى هذه وإعادتها إلى Ethereum ، كيف يمكنني الحصول على إذن وكيف أقنع الجسر بفتح الأموال؟
بالنسبة إلى Coinbase ، يثق المستخدم في Coinbase للإذن بالسحب ، وسوف يتحقق العقد الذكي ويقول ، أوه ، Coinbase مرخص ، يمكنني سحب الأموال. ولكن بالنسبة إلى L2 ، ينصب التركيز على الجسر ، وكيفية جعله يعتقد أن قاعدة البيانات خارج السلسلة هذه آمنة ، ثم السماح بإلغاء تأمين الأموال.
لذا ، عد إلى سؤالك الأصلي. أعتقد أن Coinbase أو هذه التبادلات ، هم أساسًا ما نريد بناءه لـ L2. لكننا نريد أن نبنيها بطريقة تحمي المستخدمين. إذا تعطل Coinbase ، أو إذا فعلوا شيئًا سيئًا وتعرضوا للاختراق ، فسيظل المستخدمون دائمًا آمنين. لا يتعين عليهم الوثوق بمشغلي النظام. ما يركز عليه حقًا هو كيفية قفل الأصول في جسر النظام ثم إخراجها من هذا النظام.
** كيفية تحديد التراكمية الآمنة واللامركزية **
فرانسي: إذن ما يجب أن يفعله التراكمي هو اختيار بعض الحلول الوسط بينها. ما هي الأسلحة التي يستخدمونها للحفاظ على سلامة المستخدمين؟
باتريك: أعتقد أن التركيز الحقيقي ينصب على الجسر نفسه. على سبيل المثال ، جسر Arbitrum ، وهو عبارة عن مجموعة من العقود الذكية المنتشرة على Ethereum. يبلغ سعر الجسر حاليًا حوالي 6 مليارات دولار أو نحو ذلك. إنها في الواقع مجموعة من العقود الذكية على Ethereum التي تمتلك 6 مليارات دولار. أنت بحاجة إلى إقناع الجسر بأن لدي الحق في سحب أموالي من الجسر والعودة إلى Ethereum.
إذن ما هي الأسلحة التي لدينا للحفاظ على سلامة المستخدمين؟ من الأشياء اللطيفة بشأن التواجد في اللغة الثانية أنه يمكننا وضع افتراض جيد حقًا. يمكننا أن نفترض أن هناك L1 بالفعل ، مثل Bitcoin أو Ethereum ، موجود بالفعل ويعمل. يمكننا أن نفترض أن هناك بالفعل هذه المنصة اللامركزية والبناء عليها. وفكر في هذا النظام الأساسي كطرف ثالث موثوق به ، وثق في هذا الطرف الثالث ، واضمن أننا سنفعل الشيء الصحيح دائمًا. إذن هذا هو أساس كل هذه الأنظمة. إذا كان لديك منصة لا مركزية جيدة ، فاستغلها وأعد استخدامها وقم بالبناء عليها.
إذن ، يصبح بيان المشكلة في الواقع ، لدينا الآن قاعدة البيانات خارج السلسلة التي تسجل أرصدة الحسابات وحالات البرنامج. هل يمكننا استخدام طرف ثالث موثوق به للتحقق من صحة وصحة كل تحديث لقاعدة البيانات هذه؟ هذا ما تدور حوله L2 حقًا. لإعطاء مثال ملموس ، لنفترض في قاعدة بيانات Arbitrum أن هناك أرصدة حسابات ، حالات البرنامج ، ومن ثم فإن عقد Arbitrum الذكي هو طرف ثالث موثوق به يضمن أن الجسر سيعمل دائمًا بشكل صحيح. يقوم الأشخاص الذين يديرون شبكة Arbitrum ، والمسؤولون عن الطلب ، والمدققون ، بإرسال نقاط التفتيش أو البراهين بشكل دوري إلى الجسر لإقناعه بأن التحديثات المطبقة على قاعدة البيانات صحيحة وصالحة. إذا اقتنع الجسر ، فسيسمح للمستخدمين بسحب أموالهم من Arbitrum. لذلك هذا هو سلاحنا.
فرانشي: لقد قلت للتو أن Rollup مبني على قمة Ethereum. لذلك يذكرني هذا بقول مفاده أن المجتمع يقول دائمًا أن Rollup يرث أمان Ethereum. فهل هذا يعني أن أمان Rollup يعادل تأمين Ethereum؟
باتريك: أعتقد أن هذه طريقة جيدة للتفكير في الأمر. الجواب هو نعم ولا. أعتقد أن هناك طرقًا مختلفة للتفكير في هذا الأمر. أسهل طريقة هي الأمان والحيوية. فيما يتعلق بالأمان ، فإننا نأخذ هذه المشكلة في الاعتبار فقط في قاعدة البيانات ، مما يعني أن كل تحديث لقاعدة البيانات صالح. من المستحيل أن يكون لديك تحديث غير صالح ، لأنه إذا كان هناك تحديث غير صالح لقاعدة البيانات ، فيمكنك حينئذٍ سرقة الأصول. هذا يكسر الأمان الأساسي. وهذا جزء كبير منه.
الجزء التالي هو الحياة ، مما يعني أنه يمكننا التأكد من أن الأشخاص يمكنهم إجراء تحديثات لقاعدة البيانات؟ في قاعدة البيانات ، من أجل إبقائها على قيد الحياة ، نحتاج إلى ضمان ، هل يمكننا دائمًا تحديثها؟ أم أن هناك جانب صادق؟ يمكنهم اقتراح تحديث تتم معالجته في النهاية. هذا مهم لأنه إذا تعطلت Coinbase أو Kraken أو فعلت شيئًا شريرًا ، فإن أموالك عالقة. هذا هو المكان الذي يختلف قليلاً عن Ethereum لأنه في Ethereum عليك أن تثق في PoS والأغلبية الصادقة لإبقاء النظام على قيد الحياة. بينما في التراكمي ، نفترض بالفعل أنه تم الحصول على هذا النشاط مجانًا من Ethereum. علينا فقط أن نفترض أن هناك حفلة نزيهة هناك. طالما يوجد شخص نزيه على استعداد للقيام بالعمل واقتراح تحديثات لقاعدة البيانات ، فبالتأكيد سيبقى النظام على قيد الحياة. هذا ما نعنيه بوراثة الأمان من Ethereum.
لذلك عندما نفكر في أمان التراكميات ، فإننا لا نفكر حقًا في شبكة لامركزية. قد تكون هناك شبكة تراكمية لامركزية ، لكن هذا لا يهم. يعتمد أمان Rollup حقًا على عقده الذكي كجسر ، ويجب أن يقتنع من ثلاثة جوانب.
الأول هو مشكلة توفر البيانات: يعتقد الجسر أن أي شخص في العالم يمكنه الوصول إلى قاعدة البيانات ، ويمكن لأي شخص إعادة حساب نسخة من قاعدة البيانات وأحدث نسخة. لذلك هذا هو أول شيء عليك أن تقنع الجسر. هل يمكن لأي شخص في العالم الوصول إلى نسخة من قاعدة البيانات التي نهتم بها؟
الخاصية الثانية ، يمكنك تسميتها مشكلة تكامل انتقال الحالة ، وهذا يعود إلى مشكلة الأمان. يحتاج الجسر إلى الوثوق بأن كل تحديث لقاعدة البيانات صحيح وصالح. وهذا لضمان عدم تمكن أي شخص من سرقة أموالك. لذلك يجب على عامل التشغيل أن يقنع الجسر بشكل دوري بأن كل تحديث يقوم به لقاعدة البيانات صحيح. عندها فقط سيطلق الجسر الأموال أو عمليات السحب التي يجب معالجتها.
آخرها هو مكافحة الرقابة ، والتي يمكن أن تُعزى في النهاية إلى سمة النشاط. إذا تعطل النظام بأكمله ، فهل يأتي أي شخص ويقترح تحديثًا لقاعدة البيانات ، والتي يتم التعامل معها بعد ذلك بواسطة الجسر.
باختصار ، عندما نفكر في أمان التراكمي ، فإنه يُنظر إليه حقًا من منظور العقد الذكي على Ethereum ، أي عقد الجسر ، ويجب أن يتأكد الجسر من صحة كل تحديث لقاعدة البيانات. لا يتعلق الأمر حقًا بشبكة لا مركزية. يجب أن يكون شاغلنا الحقيقي هو هذا الطرف الصادق الذي يساعد في سد أمن الأصول المقفلة.
فرانشي: في إحدى مقالاتك ، قدمت استعارة تقارن غاندالف في فيلم "سيد الخواتم" بحفلة صادقة ضد الأشرار. للجانب الصادق من هذا ، هل يمكنك أن تشرح أكثر قليلاً؟
باتريك: غاندالف هو مثال رائع ، لأنه في هذا المشهد ، يقف بالفعل على جسر ويقول ، "لا يمكنك المرور." ثم يدمر الجسر ويسقط الخصم. لقد كان الجانب الصادق ، وتقدم للأمام وقام بحماية زملائه. الوضع بالضبط هو نفسه هنا. عقد الجسر مسؤول في النهاية عن تأمين الأصول المقفلة في هذا النظام خارج السلسلة. الجانب الصادق هو الصاحب ، و Gandalf هو مساعد الفريق للتأكد من إمكانية تدمير الحلبة. والطرف الصادق يساعد في تجسيد العقد. نظرًا لنشر هذه العقود على Ethereum ، لا يمكنهم التفاعل مع العالم الخارجي. لذا فهم بحاجة إلى شخص ما للنظر في النظام خارج السلسلة ، وهذا ما يفعله الطرف الصادق.
فرانسي: كما قلت ، تستخدم Arbitrum نظامًا لمنع الاحتيال ، لذا فهم يفترضون بالفعل أن هناك طرفًا نزيهًا. إذن ماذا عن الأنواع الأخرى من Rollups؟ من هو الطرف الوحيد الصادق في zk-Rollup باستخدام براهين الصلاحية؟
باتريك: كما ذكرنا سابقًا ، فإن عقد الجسر مسؤول عن التحقق من كل تحديث يتم تطبيقه على قاعدة البيانات. حسنًا ، يمكن لأي طرف صادق أو مرحل أو أي شخص إرسال تحديث لقاعدة البيانات إلى الجسر ، ولكن في نفس الوقت يجب عليهم أيضًا تقديم دليل على صحة تحديث قاعدة البيانات هذا. وهذا ما نفعله. نريد فقط أن يؤمن العقد الذكي بأن تحديثات قاعدة البيانات صحيحة وصحيحة ويجب قبولها ومعالجتها.
هناك طريقتان للقيام بذلك ، باستخدام نوعين مختلفين من الأدلة. أحدهما هو إثبات الاحتيال الذي تستخدمه Arbitrum حاليًا: يمكن لأي شخص القدوم وإرسال تحديث محتمل للجسر ، والتحقق منه أيضًا. ثم سيكون هناك حوالي أسبوعين حيث يمكن لأي شخص أن يأتي ويتحدى ذلك. عندما يبدأ شخص ما تحديًا ، سينسق الجسر آلية لعبة مقاومة الاحتيال هذه ، ويتحرك ذهابًا وإيابًا حتى يجد انتقالًا صغيرًا للغاية للحالة لا نتفق عليه. سيقوم الجسر بعد ذلك بالتحقق بشكل مستقل لمعرفة من هو المخطئ. هذه هي الطريقة التي تعمل بها أنظمة الحماية من الاحتيال. عيبه هو أن هناك فترة تحدي مدتها أسبوعان أو أسبوع واحد ، لأنها تحتاج إلى توفير وقت كافٍ للمتنافسين للوقوف وحماية النظام.
بالنسبة لنظام إثبات الصلاحية ، الآلية المستخدمة من قبل zk-Rollup ، مثل Starknet ، و zkSync ، و Polygon Hermez ، و Scroll ، و Taiko ، إلخ. عندما يرسل المستخدمون أو المشغلون تحديثات قاعدة البيانات إلى الجسر ، فإنهم يقدمون أيضًا دليلًا على الصلاحية. هذا دليل رياضي ، بما لا يدع مجالاً للشك ، ويظهر أن تحديث قاعدة البيانات هذا صحيح وصالح. هذه خاصية قوية للغاية لأنه يمكن لأي شخص إرسال تحديث مع إثبات للجسر ، ويمكن للجسر أن يثق على الفور في أن التحديث صحيح وصالح ومعالجته.
هذان نهجان مختلفان ، لكل منهما إيجابيات وسلبيات. لكن مرة أخرى ، فإنهم يعالجون هذا السؤال الوحيد: هل تحديثات قاعدة البيانات صحيحة؟ هذا كل شئ. هناك قضايا أخرى تحتاج إلى معالجة ، مثل قضايا الرقابة ، وقضايا توافر البيانات ، وأكثر من ذلك.
** كيفية تحقيق اللامركزية في التراكمية واعتماد مخطط حوكمة DAO **
فرانشي: لا يزال هناك العديد من الأطراف الموثوقة والمرخصة في نظام التراكمي ، كيف ترى عملية التراكم اللامركزي؟ ما هو برأيك الهدف الأكثر أهمية ، وأي جزء منه نحتاج بشكل عاجل لتحقيق اللامركزية؟
باتريك: دعنا نعود إلى مثال التبادل المركزي المذكور سابقًا للتفكير في هذه المسألة. مثل التبادلات المركزية ، يوجد بالفعل فارز خلفها. على سبيل المثال ، إذا قمت بتسجيل الدخول إلى موقع Coinbase الإلكتروني لإرسال معاملة ، فسيقبل فارزها معاملتي وفرزها. ثم يتم تمرير هذه المعاملات إلى الخادم ، حيث تتم معالجتها وتحديثها بواسطة قاعدة البيانات. هذه هي البنية الحالية لهذه التبادلات ، وهي شديدة المركزية. خلال العملية برمتها ، لا نعرف ما حدث في هذا الصندوق الأسود. علينا أن نثق تمامًا في هذا الكيان لحماية مليارات الدولارات ، والاعتماد بشكل أساسي على العمليات البشرية للقيام بذلك. هذا سيء.
لا نريد الاعتماد على البشر لأن البشر ليسوا جيدين في تطبيق القواعد. لذا من ناحية التجميع ، ما نحاول فعله حقًا هو محاولة تكرار هذه البنية ، ولكن في نفس الوقت اجعلها أكثر شفافية وقابلية للتدقيق. هذا يعني أنه يمكن لكل واحد منا التحقق من أنه يعمل بشكل صحيح. نحن نعتمد على البرمجيات لفرض القواعد وليس على البشر.
بناءً على هذه الخلفية ، نحتاج إلى الاهتمام بجانبين. الأول هو عامل الفرز ، وظيفته الوحيدة هي امتلاك موقع أو واجهة أو واجهة برمجة تطبيقات مواجهة للمستخدم ، وقبول معاملات المستخدم وتحديد ترتيب التنفيذ ، ثم تمرير المعاملات التي تم فرزها إلى الطرف التالي. يمكنهم إرسال المعاملة مباشرة إلى عقد الجسر الذكي على Ethereum ، أو يمكنهم تمرير الكرسي إلى مجموعة من المنفذين. يقبل المنفذ المعاملات ، وينفذها بالترتيب ، وينشئ تحديثًا لقاعدة البيانات ، ويقترح أخيرًا التحديث للجسر.
حسنًا ، مع هؤلاء الممثلين الثلاثة المختلفين ، تأتي الآن المناقشة الحقيقية لماهية اللامركزية. كما ذكرت سابقًا ، بالنسبة لمجموعة التحديثات ، علينا فقط أن نفترض أن هناك شخصًا صادقًا يمكنه تأمين النظام. والسؤال إذن من يتصرف مثل هذا الحزب النزيه؟ هل هو فارز أم منفذ؟
تتمثل إحدى مزايا المجموعة التراكمية في أن مُنشئ الطلب الذي يقبل معاملات المستخدم اختياري. لا تحتاج في الواقع إلى جهاز التسلسل ، إنه مجرد وعد جميل بالحصول على إقرارات فورية لتجربة مستخدم رائعة. والسبب في ذلك هو أن عقد الجسر على Ethereum هو الأمر المسؤول في النهاية عن إنهاء المعاملات. وهذا يعني أن أي مستخدم أو أي عقد ذكي يمكنه إرسال المعاملات التي يرغبون في تنفيذها على النظام أو على النظام خارج السلسلة مباشرة إلى الجسر. بعد أن يتلقى الجسر المعاملة ، سيقوم في النهاية بفرزها وتنفيذها. لذا فالشيء الجميل هو أنه نظرًا لأنه يمكننا الوثوق في عقد الجسر لفعل الشيء الصحيح دائمًا ، فإننا لا نهتم بما يحدث للطلب. لذا ، فإن أدوات الفرز موثوق بها ، لكنها اختيارية. إنها موجودة فقط لتوفير تجربة مستخدم جيدة ، وليس لحماية النظام حقًا. إنهم يقدمون فقط الوعد بالترتيب الذي سيتم فيه تنفيذ المعاملات ، ولكن ليس أي ضمانات.
ومن ثم فإن مهمة الممثل التالي ، الذي يقبل الصفقة وينفذها ، ثم يقترح تحديث الحالة للجسر. لذلك هذا يحتاج إلى الحديث عن ثلاثة مستويات من النهائية. فقط بعد تسلسل المعاملات وتنفيذها بهذا الترتيب ، يتخذ الجسر إجراءات ، على سبيل المثال ، السماح للمستخدمين بسحب أموالهم.
بالعودة إلى السؤال الأصلي ، من هو الطرف الصادق؟ حسب ما قيل من قبل ، لا يجب أن يكون عامل الفرز صادقًا. علاوة على ذلك ، لا تحتاج بالضرورة إلى مجموعة كبيرة من فارزات ، يمكن أن تكون واحدة ، ثلاثة ، خمسة.
المنفذون المسؤولون عن تنفيذ المعاملات هم اللامركزية التي يجب أن نقلق بشأنها. لكن اللامركزية هنا مختلفة تمامًا عن الطريقة التي نفكر بها في الطبقة 1. لا نريد حقًا زيادة عدد المشاركين النشطين في مجموعة التحديثات. هناك 500000 مشارك في طبقة بروتوكول Ethereum. في التراكمي ، لا يُطلب من الكثير من الأشخاص أن يكونوا منفذين ، لأن ما نحتاجه حقًا هو حفلة نزيهة. لذا فإن اللامركزية تقول حقًا ، هل يمكن أن يكون النظام مفتوحًا بما يكفي للسماح لشخص نزيه بتكثيف وحماية النظام؟ دون إهدار الموارد كثيرا.
الجزء الثاني من اللامركزية يدور حول كيفية إدارة الشبكة. كيف يمكننا المشاركة بشكل جماعي في تحديد كيفية ترقية النظام؟ بما في ذلك ترقيات البرامج إلى العقود الذكية والترقيات للمكونات خارج السلسلة. كيف يتوصل المجتمع إلى توافق في الآراء حول هذا؟ هذا مجال مختلف تمامًا للنقاش حول اللامركزية. هذا هو أكثر من مسألة الحكم. كيف ندير هذا النظام؟ ربما هذا هو المكان الذي تريد زيادة المشاركة فيه.
باختصار ، هناك جانبان لللامركزية. لا تتطلب لامركزية أنظمة الوقت الفعلي سوى طرف واحد نزيه أو منفذ واحد نزيه. هذا هو الأساس الأساسي للافتراض الذي نتبعه. ثم لدينا أشياء حول حوكمة النظام وحوكمة ترقيات البرامج ، حيث يمكن استخدام DAOs ، وهنا الجزء الذي يتطلب التدخل البشري. نحتاج في بعض الأحيان إلى البشر لاتخاذ قرار بشأن التصعيد ، وهذا يتطلب DAO أو طريقة ما لتحقيق توافق في الآراء حول هذا الأمر ، وتعظيم المشاركين في الحكم.
فرانشي: فيما يتعلق بالحوكمة ، هل تعتقد أن إزالة مفاتيح الترقية هو الهدف النهائي للحكم اللامركزي؟
باتريك: لنمنح الجمهور القليل من الخلفية أولاً. على سبيل المثال ، عندما نحتاج إلى التفكير في النشر في الوقت الفعلي لنظام معين ، فسنواجه مشكلة: كيفية إجراء الترقية؟ أحدهما هو أنه قد يكون هناك مفتاح مسؤول ، بافتراض وجود مسؤول ، فلديه وصول حصري لترقية العقد الذكي كما يراه مناسبًا. الطريقة الثانية هي أشبه بالتوقيع المتعدد ، فبدلاً من الوثوق بكيان واحد ، يمكننا الوثوق في 5/9 أو 9/12 بالتوقيعات المتعددة. ثم يقدم النهج الثالث ، وهو فريد من نوعه لأنظمة التجميع هذه (يستخدم Arbitrum هذا النهج) ، مكونًا للحوكمة على السلسلة. هل يمكن تقديم DAO لأصحاب الرموز بالكامل ، وربما الآلاف من الأشخاص ، للتوصل إلى توافق في الآراء حول كيفية ترقية النظام؟ بمجرد حصولك على DAO ، يمكن اتخاذ قرارات بشأن الترقيات ، ويمكن اتخاذ القرارات حول أنواع مختلفة من التفويض. على سبيل المثال ، ربما يكون DAO مسؤولًا في النهاية عن ترخيص ترقيات النظام ، ولكن يمكنه أيضًا تعيين لجنة أمنية (multisig في 9/12) يمكنها التدخل في حالة الطوارئ لترقية النظام وتأمينه ، وإصلاح الأخطاء بشكل كبير. بسرعة.
ما هو رائع حقًا في هذه العملية برمتها هو أنها شفافة ، ويمكن لأي شخص أن ينظر إلى طبقات التفويض هذه ، وبالطبع مسؤوليات كل طرف. لذا ، للإجابة على سؤالك ، لا أعتقد أنه يجب علينا إزالة مفتاح المسؤول نفسه. أعتقد أنه من المهم أن تكون العملية شفافة ، وأن DAO الذي يدير الحوكمة أو شكل الحكم الذي ينطبق في النهاية يسمح للمجتمع بالتوصل إلى توافق في الآراء. لأنني أعتقد أنه عندما ننظر إلى التراكمية كمكدس برمجيات ، 99.99999٪ من الوقت ، سيعمل البرنامج بشكل مستقل ، ويفرض القواعد لحماية مستخدمي الشبكة. هذا صحيح في معظم الأوقات. ثم 0.000001٪ من الوقت ، هناك حاجة إلى شكل من أشكال التدخل البشري. يمكنك إما تقديم اقتراح لترقية البرنامج ، أو التدخل وإصلاح الخطأ في الوقت المناسب. هذا في الواقع لا يختلف كثيرًا عن شيء مثل Bitcoin أو Ethereum.
الفرق الوحيد هو أن عملية الإدارة هذه والأطراف المسؤولة واضحة وشفافة للغاية. نحن نعرف بالضبط من يجب أن يتدخل في الوقت المناسب ويفعل الشيء الصحيح. في حين أنهم يعتمدون على Bitcoin و Ethereum أكثر على الإجماع التقريبي. إنهم لا يريدون حقًا تحديد العملية لأنهم يريدون الدفاع ضد هجمات الحوكمة. كان هناك مؤخرًا انهيار جزئي في نقاط البيع على Ethereum. بسبب بعض الأخطاء في عميل Prysm ، تم كسر أداة النهاية. لذلك كان على بريسم أن يخرج ويصلح الخلل ، ويعيد الانتشار. لذلك حتى في هذه الشبكات في الوقت الفعلي والقابلة للطبقات ، فإننا نواجه أحيانًا أماكن تتطلب تدخلًا بشريًا من أجل حماية النظام. أعتقد أن هذا لا يزال مطلوبًا للتجميع أيضًا. لكننا بحاجة إلى بعض الإجراءات الفعالة المعمول بها حتى نعرف من لديه السلطة ونحملها المسؤولية عن نظام التجميع.
تم نسخ نص هذه المقابلة بمساعدة OpenAI Whisper وتم تجميعه على هذا الأساس.
رابط جيثب:
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
محادثة مع الباحث في Arbitrum Patrick McCorry | كيفية تطبيق اللامركزية التراكمية؟
مقدمة
عندما ننظر إلى الرؤية وخريطة الطريق لمختلف حلول Rollup ، سنجد أن جميع Rollups تقريبًا لها هدف نهائي. إذا تم تكثيف هذا الهدف في جملة واحدة: بناء كومة تقنية ، وتقديمها إلى المجتمع ، وحل مشكلة التوسع blockchain ، وفي النهاية اللامركزية في مجموعة التكنولوجيا للعمليات والحوكمة. هذا يؤدي إلى مصطلح التراكمية اللامركزية.
إذن ما هي اللامركزية بالضبط؟ ما هو تقسيم العمل بين مختلف أجزاء نظام التراكمية؟ هل تعني اللامركزية تعظيم المشاركين في تشغيل النظام؟ ما هو تأثير فارز مركزي؟ كيف ينبغي تصميم نظام الطلب المشترك والإجماع المحلي L2؟ ما هي وظيفة المُثبِت الفريد في ZK-Rollup؟ كيف ستبدو شبكة المثقفين اللامركزية المفتوحة؟ لماذا نحتاج تسريع أجهزة zk؟ ما هو الحل لمشكلة توافر البيانات؟ ....
هناك مناقشات لا حصر لها حول التراكمية اللامركزية في المجتمع ، لذلك نظمت شبكة الاتصالات الإلكترونية (ECN) سلسلة من المقابلات الصوتية مع موضوع "اللامركزية التراكمية" ، ودعت المؤسسين والباحثين البارزين في هذا المجال للحديث عن فهمهم للتفاهم اللامركزي.
دعا العدد الأول باتريك ماكوري ، الباحث من مؤسسة Arbitrum Foundation. هذه الحلقة بمثابة ملخص للمسلسل ، وتتحدث بشكل أساسي عن المشكلات التي تريد الطبقة الثانية حلها ، ومعنى التراكمية اللامركزية ، وكيفية فهم سماتها الأمنية ، وكيف حوكمة DAO تعمل في التراكم اللامركزي.
ضيف هذه الحلقة: باتريك ماكوري ، twitter @ stonecoldpat0
المنسق: Franci، twitter @ FrancixDeng
جَرَّار
المرحلة 2: المُسلسل المشترك وإجماع L2
المشكلة 3: شبكة Prover وتسريع أجهزة zk
المشكلة 4: توافر البيانات والتخزين اللامركزي
يستمع
انقر للاشتراك في البودكاست لمعرفة المزيد:
موقع YouTube:
عالم مصغر:
** الطابع الزمني **
01:49 مقدمة شخصية باتريك ماكوري
03:26 لماذا توجد layer2 وما الذي تحاول حله؟
11:56 ما هي الأسلحة التي يستخدمونها للحفاظ على سلامة المستخدمين؟
14:40 ماذا تعني سلامة وحيوية التراكمية
17:47 اشرح أمان التراكم من توافر البيانات وصلاحية انتقال الحالة ومكافحة الرقابة
19:45 دور الكيان الوحيد الصادق ، الذي يعمل ككيان واحد صادق للتجميع؟
28:47 ما رأيك في التراكم اللامركزي؟ ما هو الهدف الأكثر إلحاحًا في الوقت الحالي؟
37:21 أهمية حوكمة DAO في تجميع اللامركزية
** قسم المقابلة **
** مشاكل Layer2 تريد حلها **
فرانشي: ما سنستكشفه في هذه الحلقة هو ، ما الذي يعنيه وجود تراكم لامركزي؟ لماذا هو مهم ما المشكلة التي يحاولون حلها؟ آمل أنه من خلال هذا الحديث ، يمكن للقراء والمستمعين أن يفهموا أخيرًا ما هو التراكم اللامركزي الحقيقي والأهداف التي يجب عليهم تحقيقها. دع ضيفنا ، باتريك ماكوري ، يقدم نفسه.
باتريك: مرحباً بالجميع. أعتقد من التجربة أنني منحاز نحو البحث الأكاديمي. من عام 2013 إلى عام 2016 ، كان اتجاه الدكتوراه الخاص بي مرتبطًا ببيتكوين وإيثريوم. ثم من عام 2016 إلى عام 2019 تقريبًا ، كنت باحثًا في جامعات مثل UCL و King's College London و UIUC. خلال هذا الوقت ، كنت مهتمًا جدًا ببروتوكولات الطبقة الثانية. بما في ذلك Bitcoin Lightning Network والبلازما وبالطبع Rollup. لذلك في عام 2019 ، حاولت بدء تشغيل. ثم تركت الكلية ، أنا وصديقي ، شخصان وكلب. نحاول أن نكون شركة ناشئة تركز على layer2. لكنها كانت سوقًا هابطة ، ثم استحوذت علينا Infura. ثم غادرت Infura وانضممت مؤخرًا إلى مؤسسة Arbitrum. لذلك عدت للتركيز على البحث التراكمي بدوام كامل. خلال هذه الفترة بأكملها ، ركزت بشكل أساسي على التعليم ، وشرح لماذا يجب أن نهتم ببروتوكولات الطبقة الثانية.
فرانسي: لنبدأ بالمواضيع الأساسية. بشكل عام ، ما هو نظام L2؟ ماذا يعني قيام المستخدم بإيداع الأموال في نظام L2 وإجراء معاملة هناك؟
باتريك: بالحديث عن هذه المشكلة ، أعتقد أننا بحاجة إلى التراجع والتفكير ، ما هو الهدف من blockchain؟ ما الهدف من كل هذه الأنظمة التي نحاول بناءها؟ بمجرد أن نفكر في هذا ، يصبح من المنطقي أن نشرح L2. الشيء الحقيقي وراء شبكة blockchain مثل Bitcoin أو Ethereum هو مجرد قاعدة بيانات. هي قاعدة بيانات عامة يمكن لأي شخص قراءتها والكتابة إليها. لذلك ، فهي قاعدة بيانات لأرصدة الحسابات ، وبالطبع ، في Ethereum ، هناك العديد من البرامج إلى جانب أرصدة الحسابات. لذا يمكنني نشر الكود الخاص بي في قاعدة البيانات. يمكن أن يكون لبرنامجي حالة معينة ويمكنني إجراء معاملات عليه ، ويمكن للجميع رؤية التحديثات لقاعدة البيانات. في الأساس ، نحن نتعامل فقط مع قواعد البيانات. يبدو مملا.
وأهمية blockchain نفسها ، إنها في الحقيقة مجرد مسار تدقيق. لذلك يخزن قائمة المعاملات ، وإذا أعطيتك نسخة من blockchain ، يمكنك إعادة حساب قاعدة البيانات هذه بنفسك. في الأساس ، نحن نبني قاعدة بيانات عامة يمكن لأي شخص قراءتها وحسابها والكتابة إليها بشكل مستقل. حسنًا ، هذا هو layer1.
سواء كانت Bitcoin أو Ethereum layer1 ، فإن المشكلة هي أنها تحتاج إلى تعظيم اللامركزية. هناك ثلاث طرق مختلفة للتفكير في اللامركزية. الأول هو المشغل: من يدير الشبكة ، ومن ينتج الكتل ، ومن يؤكد المعاملات. مع العديد من هذه الشبكات ، نرغب دائمًا في تعظيم إمكانية مشاركة أي شخص في العملية. بهذه الطريقة لا توجد نقطة واحدة للفشل. من ناحية أخرى ، تحتاج أيضًا إلى التفكير في من يمكنه التحقق من كل تحديث لقاعدة البيانات ، ومن يمكنه التحقق من أن المشغلين يقومون بعملهم ، وأن قاعدة البيانات صحيحة ، وما إذا كانت هناك مشكلات أخرى. عملهم وقواعد بياناتهم صحيحة وصالحة في جميع الأوقات. في هذه المرحلة ، سيكون لديك هذا الشبك. تريد زيادة عدد الأشخاص المشاركين في التحقق من الشبكة ، وتريد زيادة عدد الأشخاص الذين يقومون بتشغيل الشبكة. لذا ، فهي تشبه نوعًا ما قتال حجم كتلة البيتكوين القديم. قم بتحديث الكتل ويمكنك معالجة المزيد من المعاملات. ولكن بعد ذلك سيكون الأمر أكثر صعوبة ، لأنك بحاجة إلى متطلبات أجهزة أعلى للتحقق من الشبكة في الوقت الفعلي ، وأخيرًا تصبح مشغل شبكة. هذا هو السؤال عن كيفية النظر في اللامركزية على مستوى الطبقة 1. الجانب الثالث هو جعلها في متناول الجميع. إذا دفعنا 200 دولار أمريكي للمعاملات على شبكة ، فهل هي حقًا لا مركزية؟ يبدو أنه ليس كذلك. لذلك ، بمعنى ما ، هذه مشكلة ثلاثية متخلفة من التاريخ.
لقد علقنا لفترة طويلة مع هذه الثلاثية ، لأنه إذا حاولت معالجة المزيد من المعاملات ، فسوف يتضرر أحد الأطراف بطريقة ما ، إما أن ترتفع الرسوم ، أو ترتفع متطلبات الأجهزة ، أو تصبح جاهزة للعمل أكثر صعوبة. هذه مناقشة للامركزية في سياق L1.
فرانسي: كما قلت ، سينظر المستخدمون في تكلفة المعاملات. ثم قد يختارون إيداع أموالهم في بورصة مركزية. بشكل عام ، هل هذا نوع من L2؟
باتريك: أعتقد أنها طريقة جيدة للتفكير في الأمر من منظور التبادلات. التبادل المركزي يشبه قاعدة البيانات. لكن المشكلة هي أنها قاعدة بيانات خاصة. إذن قاعدة بيانات التبادل هي فقط القادرة على القراءة والكتابة. والمستخدمون مثلك ومثلي ، لا يمكننا تدقيق قاعدة البيانات هذه ، ولا يمكننا التحقق من صحتها. لكن ميزة التداول في البورصة هي أنها رخيصة جدًا. الغرض من نظام L1 blockchain هو أن يكون لامركزيًا قدر الإمكان ، لكن التكلفة مرتفعة للغاية.
لذلك عندما نفكر في عالم L2 ، في عالم L2 ، لا نريد حقًا إعادة إنشاء L1. لا نريد حقًا أن نضطر إلى بناء شبكة لامركزية تزيد من عدد المشاركين. لأننا نعلم بالفعل أنه ، تاريخيًا ، كان من الصعب جدًا بناء هذه الأنواع من الأنظمة وجعلها تتوسع كثيرًا من حيث الإنتاجية. لذلك نعتقد ، هل يمكننا بناء نظام يشبه التبادل ، لكنه لا يزال يحتفظ بخصائص نظام blockchain ، حيث تكون قاعدة البيانات عامة؟ يمكن لأي شخص قراءة قاعدة البيانات ، ويمكن لأي شخص الكتابة إليها ، ويمكن لأي شخص حمايتها. هذا هو هدف L2.
عندما تبدأ في مقارنة التبادلات بما قمنا ببنائه في L2 ، فإننا في نهاية اليوم نقارن عناصر هندسة الجسور. الجسر الذي أتحدث عنه هو أنه سيكون هناك عقد ذكي على Ethereum ، وأنا أقفل الأصول في هذا العقد الذكي المسمى "الجسر". بمجرد قفله على الجسر ، سيظهر في قواعد البيانات الأخرى. يمكن أن تكون قاعدة البيانات هذه Coinbase ، أو Arbitrum ، أو التفاؤل. ثم السؤال هو ، عندما أرغب في سحب أموالي من قاعدة البيانات الأخرى هذه وإعادتها إلى Ethereum ، كيف يمكنني الحصول على إذن وكيف أقنع الجسر بفتح الأموال؟
بالنسبة إلى Coinbase ، يثق المستخدم في Coinbase للإذن بالسحب ، وسوف يتحقق العقد الذكي ويقول ، أوه ، Coinbase مرخص ، يمكنني سحب الأموال. ولكن بالنسبة إلى L2 ، ينصب التركيز على الجسر ، وكيفية جعله يعتقد أن قاعدة البيانات خارج السلسلة هذه آمنة ، ثم السماح بإلغاء تأمين الأموال.
لذا ، عد إلى سؤالك الأصلي. أعتقد أن Coinbase أو هذه التبادلات ، هم أساسًا ما نريد بناءه لـ L2. لكننا نريد أن نبنيها بطريقة تحمي المستخدمين. إذا تعطل Coinbase ، أو إذا فعلوا شيئًا سيئًا وتعرضوا للاختراق ، فسيظل المستخدمون دائمًا آمنين. لا يتعين عليهم الوثوق بمشغلي النظام. ما يركز عليه حقًا هو كيفية قفل الأصول في جسر النظام ثم إخراجها من هذا النظام.
** كيفية تحديد التراكمية الآمنة واللامركزية **
فرانسي: إذن ما يجب أن يفعله التراكمي هو اختيار بعض الحلول الوسط بينها. ما هي الأسلحة التي يستخدمونها للحفاظ على سلامة المستخدمين؟
باتريك: أعتقد أن التركيز الحقيقي ينصب على الجسر نفسه. على سبيل المثال ، جسر Arbitrum ، وهو عبارة عن مجموعة من العقود الذكية المنتشرة على Ethereum. يبلغ سعر الجسر حاليًا حوالي 6 مليارات دولار أو نحو ذلك. إنها في الواقع مجموعة من العقود الذكية على Ethereum التي تمتلك 6 مليارات دولار. أنت بحاجة إلى إقناع الجسر بأن لدي الحق في سحب أموالي من الجسر والعودة إلى Ethereum.
إذن ما هي الأسلحة التي لدينا للحفاظ على سلامة المستخدمين؟ من الأشياء اللطيفة بشأن التواجد في اللغة الثانية أنه يمكننا وضع افتراض جيد حقًا. يمكننا أن نفترض أن هناك L1 بالفعل ، مثل Bitcoin أو Ethereum ، موجود بالفعل ويعمل. يمكننا أن نفترض أن هناك بالفعل هذه المنصة اللامركزية والبناء عليها. وفكر في هذا النظام الأساسي كطرف ثالث موثوق به ، وثق في هذا الطرف الثالث ، واضمن أننا سنفعل الشيء الصحيح دائمًا. إذن هذا هو أساس كل هذه الأنظمة. إذا كان لديك منصة لا مركزية جيدة ، فاستغلها وأعد استخدامها وقم بالبناء عليها.
إذن ، يصبح بيان المشكلة في الواقع ، لدينا الآن قاعدة البيانات خارج السلسلة التي تسجل أرصدة الحسابات وحالات البرنامج. هل يمكننا استخدام طرف ثالث موثوق به للتحقق من صحة وصحة كل تحديث لقاعدة البيانات هذه؟ هذا ما تدور حوله L2 حقًا. لإعطاء مثال ملموس ، لنفترض في قاعدة بيانات Arbitrum أن هناك أرصدة حسابات ، حالات البرنامج ، ومن ثم فإن عقد Arbitrum الذكي هو طرف ثالث موثوق به يضمن أن الجسر سيعمل دائمًا بشكل صحيح. يقوم الأشخاص الذين يديرون شبكة Arbitrum ، والمسؤولون عن الطلب ، والمدققون ، بإرسال نقاط التفتيش أو البراهين بشكل دوري إلى الجسر لإقناعه بأن التحديثات المطبقة على قاعدة البيانات صحيحة وصالحة. إذا اقتنع الجسر ، فسيسمح للمستخدمين بسحب أموالهم من Arbitrum. لذلك هذا هو سلاحنا.
فرانشي: لقد قلت للتو أن Rollup مبني على قمة Ethereum. لذلك يذكرني هذا بقول مفاده أن المجتمع يقول دائمًا أن Rollup يرث أمان Ethereum. فهل هذا يعني أن أمان Rollup يعادل تأمين Ethereum؟
باتريك: أعتقد أن هذه طريقة جيدة للتفكير في الأمر. الجواب هو نعم ولا. أعتقد أن هناك طرقًا مختلفة للتفكير في هذا الأمر. أسهل طريقة هي الأمان والحيوية. فيما يتعلق بالأمان ، فإننا نأخذ هذه المشكلة في الاعتبار فقط في قاعدة البيانات ، مما يعني أن كل تحديث لقاعدة البيانات صالح. من المستحيل أن يكون لديك تحديث غير صالح ، لأنه إذا كان هناك تحديث غير صالح لقاعدة البيانات ، فيمكنك حينئذٍ سرقة الأصول. هذا يكسر الأمان الأساسي. وهذا جزء كبير منه.
الجزء التالي هو الحياة ، مما يعني أنه يمكننا التأكد من أن الأشخاص يمكنهم إجراء تحديثات لقاعدة البيانات؟ في قاعدة البيانات ، من أجل إبقائها على قيد الحياة ، نحتاج إلى ضمان ، هل يمكننا دائمًا تحديثها؟ أم أن هناك جانب صادق؟ يمكنهم اقتراح تحديث تتم معالجته في النهاية. هذا مهم لأنه إذا تعطلت Coinbase أو Kraken أو فعلت شيئًا شريرًا ، فإن أموالك عالقة. هذا هو المكان الذي يختلف قليلاً عن Ethereum لأنه في Ethereum عليك أن تثق في PoS والأغلبية الصادقة لإبقاء النظام على قيد الحياة. بينما في التراكمي ، نفترض بالفعل أنه تم الحصول على هذا النشاط مجانًا من Ethereum. علينا فقط أن نفترض أن هناك حفلة نزيهة هناك. طالما يوجد شخص نزيه على استعداد للقيام بالعمل واقتراح تحديثات لقاعدة البيانات ، فبالتأكيد سيبقى النظام على قيد الحياة. هذا ما نعنيه بوراثة الأمان من Ethereum.
لذلك عندما نفكر في أمان التراكميات ، فإننا لا نفكر حقًا في شبكة لامركزية. قد تكون هناك شبكة تراكمية لامركزية ، لكن هذا لا يهم. يعتمد أمان Rollup حقًا على عقده الذكي كجسر ، ويجب أن يقتنع من ثلاثة جوانب.
الأول هو مشكلة توفر البيانات: يعتقد الجسر أن أي شخص في العالم يمكنه الوصول إلى قاعدة البيانات ، ويمكن لأي شخص إعادة حساب نسخة من قاعدة البيانات وأحدث نسخة. لذلك هذا هو أول شيء عليك أن تقنع الجسر. هل يمكن لأي شخص في العالم الوصول إلى نسخة من قاعدة البيانات التي نهتم بها؟
الخاصية الثانية ، يمكنك تسميتها مشكلة تكامل انتقال الحالة ، وهذا يعود إلى مشكلة الأمان. يحتاج الجسر إلى الوثوق بأن كل تحديث لقاعدة البيانات صحيح وصالح. وهذا لضمان عدم تمكن أي شخص من سرقة أموالك. لذلك يجب على عامل التشغيل أن يقنع الجسر بشكل دوري بأن كل تحديث يقوم به لقاعدة البيانات صحيح. عندها فقط سيطلق الجسر الأموال أو عمليات السحب التي يجب معالجتها.
آخرها هو مكافحة الرقابة ، والتي يمكن أن تُعزى في النهاية إلى سمة النشاط. إذا تعطل النظام بأكمله ، فهل يأتي أي شخص ويقترح تحديثًا لقاعدة البيانات ، والتي يتم التعامل معها بعد ذلك بواسطة الجسر.
باختصار ، عندما نفكر في أمان التراكمي ، فإنه يُنظر إليه حقًا من منظور العقد الذكي على Ethereum ، أي عقد الجسر ، ويجب أن يتأكد الجسر من صحة كل تحديث لقاعدة البيانات. لا يتعلق الأمر حقًا بشبكة لا مركزية. يجب أن يكون شاغلنا الحقيقي هو هذا الطرف الصادق الذي يساعد في سد أمن الأصول المقفلة.
فرانشي: في إحدى مقالاتك ، قدمت استعارة تقارن غاندالف في فيلم "سيد الخواتم" بحفلة صادقة ضد الأشرار. للجانب الصادق من هذا ، هل يمكنك أن تشرح أكثر قليلاً؟
باتريك: غاندالف هو مثال رائع ، لأنه في هذا المشهد ، يقف بالفعل على جسر ويقول ، "لا يمكنك المرور." ثم يدمر الجسر ويسقط الخصم. لقد كان الجانب الصادق ، وتقدم للأمام وقام بحماية زملائه. الوضع بالضبط هو نفسه هنا. عقد الجسر مسؤول في النهاية عن تأمين الأصول المقفلة في هذا النظام خارج السلسلة. الجانب الصادق هو الصاحب ، و Gandalf هو مساعد الفريق للتأكد من إمكانية تدمير الحلبة. والطرف الصادق يساعد في تجسيد العقد. نظرًا لنشر هذه العقود على Ethereum ، لا يمكنهم التفاعل مع العالم الخارجي. لذا فهم بحاجة إلى شخص ما للنظر في النظام خارج السلسلة ، وهذا ما يفعله الطرف الصادق.
فرانسي: كما قلت ، تستخدم Arbitrum نظامًا لمنع الاحتيال ، لذا فهم يفترضون بالفعل أن هناك طرفًا نزيهًا. إذن ماذا عن الأنواع الأخرى من Rollups؟ من هو الطرف الوحيد الصادق في zk-Rollup باستخدام براهين الصلاحية؟
باتريك: كما ذكرنا سابقًا ، فإن عقد الجسر مسؤول عن التحقق من كل تحديث يتم تطبيقه على قاعدة البيانات. حسنًا ، يمكن لأي طرف صادق أو مرحل أو أي شخص إرسال تحديث لقاعدة البيانات إلى الجسر ، ولكن في نفس الوقت يجب عليهم أيضًا تقديم دليل على صحة تحديث قاعدة البيانات هذا. وهذا ما نفعله. نريد فقط أن يؤمن العقد الذكي بأن تحديثات قاعدة البيانات صحيحة وصحيحة ويجب قبولها ومعالجتها.
هناك طريقتان للقيام بذلك ، باستخدام نوعين مختلفين من الأدلة. أحدهما هو إثبات الاحتيال الذي تستخدمه Arbitrum حاليًا: يمكن لأي شخص القدوم وإرسال تحديث محتمل للجسر ، والتحقق منه أيضًا. ثم سيكون هناك حوالي أسبوعين حيث يمكن لأي شخص أن يأتي ويتحدى ذلك. عندما يبدأ شخص ما تحديًا ، سينسق الجسر آلية لعبة مقاومة الاحتيال هذه ، ويتحرك ذهابًا وإيابًا حتى يجد انتقالًا صغيرًا للغاية للحالة لا نتفق عليه. سيقوم الجسر بعد ذلك بالتحقق بشكل مستقل لمعرفة من هو المخطئ. هذه هي الطريقة التي تعمل بها أنظمة الحماية من الاحتيال. عيبه هو أن هناك فترة تحدي مدتها أسبوعان أو أسبوع واحد ، لأنها تحتاج إلى توفير وقت كافٍ للمتنافسين للوقوف وحماية النظام.
بالنسبة لنظام إثبات الصلاحية ، الآلية المستخدمة من قبل zk-Rollup ، مثل Starknet ، و zkSync ، و Polygon Hermez ، و Scroll ، و Taiko ، إلخ. عندما يرسل المستخدمون أو المشغلون تحديثات قاعدة البيانات إلى الجسر ، فإنهم يقدمون أيضًا دليلًا على الصلاحية. هذا دليل رياضي ، بما لا يدع مجالاً للشك ، ويظهر أن تحديث قاعدة البيانات هذا صحيح وصالح. هذه خاصية قوية للغاية لأنه يمكن لأي شخص إرسال تحديث مع إثبات للجسر ، ويمكن للجسر أن يثق على الفور في أن التحديث صحيح وصالح ومعالجته.
هذان نهجان مختلفان ، لكل منهما إيجابيات وسلبيات. لكن مرة أخرى ، فإنهم يعالجون هذا السؤال الوحيد: هل تحديثات قاعدة البيانات صحيحة؟ هذا كل شئ. هناك قضايا أخرى تحتاج إلى معالجة ، مثل قضايا الرقابة ، وقضايا توافر البيانات ، وأكثر من ذلك.
** كيفية تحقيق اللامركزية في التراكمية واعتماد مخطط حوكمة DAO **
فرانشي: لا يزال هناك العديد من الأطراف الموثوقة والمرخصة في نظام التراكمي ، كيف ترى عملية التراكم اللامركزي؟ ما هو برأيك الهدف الأكثر أهمية ، وأي جزء منه نحتاج بشكل عاجل لتحقيق اللامركزية؟
باتريك: دعنا نعود إلى مثال التبادل المركزي المذكور سابقًا للتفكير في هذه المسألة. مثل التبادلات المركزية ، يوجد بالفعل فارز خلفها. على سبيل المثال ، إذا قمت بتسجيل الدخول إلى موقع Coinbase الإلكتروني لإرسال معاملة ، فسيقبل فارزها معاملتي وفرزها. ثم يتم تمرير هذه المعاملات إلى الخادم ، حيث تتم معالجتها وتحديثها بواسطة قاعدة البيانات. هذه هي البنية الحالية لهذه التبادلات ، وهي شديدة المركزية. خلال العملية برمتها ، لا نعرف ما حدث في هذا الصندوق الأسود. علينا أن نثق تمامًا في هذا الكيان لحماية مليارات الدولارات ، والاعتماد بشكل أساسي على العمليات البشرية للقيام بذلك. هذا سيء.
لا نريد الاعتماد على البشر لأن البشر ليسوا جيدين في تطبيق القواعد. لذا من ناحية التجميع ، ما نحاول فعله حقًا هو محاولة تكرار هذه البنية ، ولكن في نفس الوقت اجعلها أكثر شفافية وقابلية للتدقيق. هذا يعني أنه يمكن لكل واحد منا التحقق من أنه يعمل بشكل صحيح. نحن نعتمد على البرمجيات لفرض القواعد وليس على البشر.
بناءً على هذه الخلفية ، نحتاج إلى الاهتمام بجانبين. الأول هو عامل الفرز ، وظيفته الوحيدة هي امتلاك موقع أو واجهة أو واجهة برمجة تطبيقات مواجهة للمستخدم ، وقبول معاملات المستخدم وتحديد ترتيب التنفيذ ، ثم تمرير المعاملات التي تم فرزها إلى الطرف التالي. يمكنهم إرسال المعاملة مباشرة إلى عقد الجسر الذكي على Ethereum ، أو يمكنهم تمرير الكرسي إلى مجموعة من المنفذين. يقبل المنفذ المعاملات ، وينفذها بالترتيب ، وينشئ تحديثًا لقاعدة البيانات ، ويقترح أخيرًا التحديث للجسر.
حسنًا ، مع هؤلاء الممثلين الثلاثة المختلفين ، تأتي الآن المناقشة الحقيقية لماهية اللامركزية. كما ذكرت سابقًا ، بالنسبة لمجموعة التحديثات ، علينا فقط أن نفترض أن هناك شخصًا صادقًا يمكنه تأمين النظام. والسؤال إذن من يتصرف مثل هذا الحزب النزيه؟ هل هو فارز أم منفذ؟
تتمثل إحدى مزايا المجموعة التراكمية في أن مُنشئ الطلب الذي يقبل معاملات المستخدم اختياري. لا تحتاج في الواقع إلى جهاز التسلسل ، إنه مجرد وعد جميل بالحصول على إقرارات فورية لتجربة مستخدم رائعة. والسبب في ذلك هو أن عقد الجسر على Ethereum هو الأمر المسؤول في النهاية عن إنهاء المعاملات. وهذا يعني أن أي مستخدم أو أي عقد ذكي يمكنه إرسال المعاملات التي يرغبون في تنفيذها على النظام أو على النظام خارج السلسلة مباشرة إلى الجسر. بعد أن يتلقى الجسر المعاملة ، سيقوم في النهاية بفرزها وتنفيذها. لذا فالشيء الجميل هو أنه نظرًا لأنه يمكننا الوثوق في عقد الجسر لفعل الشيء الصحيح دائمًا ، فإننا لا نهتم بما يحدث للطلب. لذا ، فإن أدوات الفرز موثوق بها ، لكنها اختيارية. إنها موجودة فقط لتوفير تجربة مستخدم جيدة ، وليس لحماية النظام حقًا. إنهم يقدمون فقط الوعد بالترتيب الذي سيتم فيه تنفيذ المعاملات ، ولكن ليس أي ضمانات.
ومن ثم فإن مهمة الممثل التالي ، الذي يقبل الصفقة وينفذها ، ثم يقترح تحديث الحالة للجسر. لذلك هذا يحتاج إلى الحديث عن ثلاثة مستويات من النهائية. فقط بعد تسلسل المعاملات وتنفيذها بهذا الترتيب ، يتخذ الجسر إجراءات ، على سبيل المثال ، السماح للمستخدمين بسحب أموالهم.
بالعودة إلى السؤال الأصلي ، من هو الطرف الصادق؟ حسب ما قيل من قبل ، لا يجب أن يكون عامل الفرز صادقًا. علاوة على ذلك ، لا تحتاج بالضرورة إلى مجموعة كبيرة من فارزات ، يمكن أن تكون واحدة ، ثلاثة ، خمسة.
المنفذون المسؤولون عن تنفيذ المعاملات هم اللامركزية التي يجب أن نقلق بشأنها. لكن اللامركزية هنا مختلفة تمامًا عن الطريقة التي نفكر بها في الطبقة 1. لا نريد حقًا زيادة عدد المشاركين النشطين في مجموعة التحديثات. هناك 500000 مشارك في طبقة بروتوكول Ethereum. في التراكمي ، لا يُطلب من الكثير من الأشخاص أن يكونوا منفذين ، لأن ما نحتاجه حقًا هو حفلة نزيهة. لذا فإن اللامركزية تقول حقًا ، هل يمكن أن يكون النظام مفتوحًا بما يكفي للسماح لشخص نزيه بتكثيف وحماية النظام؟ دون إهدار الموارد كثيرا.
الجزء الثاني من اللامركزية يدور حول كيفية إدارة الشبكة. كيف يمكننا المشاركة بشكل جماعي في تحديد كيفية ترقية النظام؟ بما في ذلك ترقيات البرامج إلى العقود الذكية والترقيات للمكونات خارج السلسلة. كيف يتوصل المجتمع إلى توافق في الآراء حول هذا؟ هذا مجال مختلف تمامًا للنقاش حول اللامركزية. هذا هو أكثر من مسألة الحكم. كيف ندير هذا النظام؟ ربما هذا هو المكان الذي تريد زيادة المشاركة فيه.
باختصار ، هناك جانبان لللامركزية. لا تتطلب لامركزية أنظمة الوقت الفعلي سوى طرف واحد نزيه أو منفذ واحد نزيه. هذا هو الأساس الأساسي للافتراض الذي نتبعه. ثم لدينا أشياء حول حوكمة النظام وحوكمة ترقيات البرامج ، حيث يمكن استخدام DAOs ، وهنا الجزء الذي يتطلب التدخل البشري. نحتاج في بعض الأحيان إلى البشر لاتخاذ قرار بشأن التصعيد ، وهذا يتطلب DAO أو طريقة ما لتحقيق توافق في الآراء حول هذا الأمر ، وتعظيم المشاركين في الحكم.
فرانشي: فيما يتعلق بالحوكمة ، هل تعتقد أن إزالة مفاتيح الترقية هو الهدف النهائي للحكم اللامركزي؟
باتريك: لنمنح الجمهور القليل من الخلفية أولاً. على سبيل المثال ، عندما نحتاج إلى التفكير في النشر في الوقت الفعلي لنظام معين ، فسنواجه مشكلة: كيفية إجراء الترقية؟ أحدهما هو أنه قد يكون هناك مفتاح مسؤول ، بافتراض وجود مسؤول ، فلديه وصول حصري لترقية العقد الذكي كما يراه مناسبًا. الطريقة الثانية هي أشبه بالتوقيع المتعدد ، فبدلاً من الوثوق بكيان واحد ، يمكننا الوثوق في 5/9 أو 9/12 بالتوقيعات المتعددة. ثم يقدم النهج الثالث ، وهو فريد من نوعه لأنظمة التجميع هذه (يستخدم Arbitrum هذا النهج) ، مكونًا للحوكمة على السلسلة. هل يمكن تقديم DAO لأصحاب الرموز بالكامل ، وربما الآلاف من الأشخاص ، للتوصل إلى توافق في الآراء حول كيفية ترقية النظام؟ بمجرد حصولك على DAO ، يمكن اتخاذ قرارات بشأن الترقيات ، ويمكن اتخاذ القرارات حول أنواع مختلفة من التفويض. على سبيل المثال ، ربما يكون DAO مسؤولًا في النهاية عن ترخيص ترقيات النظام ، ولكن يمكنه أيضًا تعيين لجنة أمنية (multisig في 9/12) يمكنها التدخل في حالة الطوارئ لترقية النظام وتأمينه ، وإصلاح الأخطاء بشكل كبير. بسرعة.
ما هو رائع حقًا في هذه العملية برمتها هو أنها شفافة ، ويمكن لأي شخص أن ينظر إلى طبقات التفويض هذه ، وبالطبع مسؤوليات كل طرف. لذا ، للإجابة على سؤالك ، لا أعتقد أنه يجب علينا إزالة مفتاح المسؤول نفسه. أعتقد أنه من المهم أن تكون العملية شفافة ، وأن DAO الذي يدير الحوكمة أو شكل الحكم الذي ينطبق في النهاية يسمح للمجتمع بالتوصل إلى توافق في الآراء. لأنني أعتقد أنه عندما ننظر إلى التراكمية كمكدس برمجيات ، 99.99999٪ من الوقت ، سيعمل البرنامج بشكل مستقل ، ويفرض القواعد لحماية مستخدمي الشبكة. هذا صحيح في معظم الأوقات. ثم 0.000001٪ من الوقت ، هناك حاجة إلى شكل من أشكال التدخل البشري. يمكنك إما تقديم اقتراح لترقية البرنامج ، أو التدخل وإصلاح الخطأ في الوقت المناسب. هذا في الواقع لا يختلف كثيرًا عن شيء مثل Bitcoin أو Ethereum.
الفرق الوحيد هو أن عملية الإدارة هذه والأطراف المسؤولة واضحة وشفافة للغاية. نحن نعرف بالضبط من يجب أن يتدخل في الوقت المناسب ويفعل الشيء الصحيح. في حين أنهم يعتمدون على Bitcoin و Ethereum أكثر على الإجماع التقريبي. إنهم لا يريدون حقًا تحديد العملية لأنهم يريدون الدفاع ضد هجمات الحوكمة. كان هناك مؤخرًا انهيار جزئي في نقاط البيع على Ethereum. بسبب بعض الأخطاء في عميل Prysm ، تم كسر أداة النهاية. لذلك كان على بريسم أن يخرج ويصلح الخلل ، ويعيد الانتشار. لذلك حتى في هذه الشبكات في الوقت الفعلي والقابلة للطبقات ، فإننا نواجه أحيانًا أماكن تتطلب تدخلًا بشريًا من أجل حماية النظام. أعتقد أن هذا لا يزال مطلوبًا للتجميع أيضًا. لكننا بحاجة إلى بعض الإجراءات الفعالة المعمول بها حتى نعرف من لديه السلطة ونحملها المسؤولية عن نظام التجميع.