حول تقليل الثقة والتحجيم الأفقي

إيثريوم هو كمبيوتر عالمي بدون إذن يمتلك (يمكن القول) أعلى قدر من الأمان الاقتصادي في وقت كتابة هذا التقرير، ويعمل بمثابة دفتر التسوية لعدد كبير من الأصول والتطبيقات والخدمات. لدى إيثريوم قيودها - بلوك سبيس هي مورد نادر ومكلف في الطبقة الأولى من إيثريوم (L1). يُنظر إلى تحجيم الطبقة الثانية (L2) على أنه الحل لهذه المشكلة، مع طرح العديد من المشاريع في السوق في السنوات الأخيرة، معظمها في شكل مجموعات. ومع ذلك، فإن عمليات التجميع، بالمعنى الدقيق للمصطلح (بمعنى أن بيانات التجميع موجودة على Ethereum L1)، لا تسمح لإيثيريوم بالتوسع إلى أجل غير مسمى، مما يسمح فقط بما يصل إلى بضعة آلاف من المعاملات في الثانية.

تقليل الثقة - (إحدى ميزات) نظام L2 يتم تقليل الثقة إلى الحد الأدنى إذا كان يعمل دون الحاجة إلى ثقة خارجية عن L1 الأساسي.

التحجيم الأفقي - يكون النظام قابلاً للتطوير أفقيًا إذا كان من الممكن إضافة مثيلات دون فرض اختناقات عالمية.

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

1. لماذا يجب تقليل الثقة في التطبيقات؟
2. لماذا نبني أنظمة قابلة للتطوير أفقيًا؟
3. كيف يمكننا تعظيم كل من تقليل الثقة وقابلية التوسع أفقيًا؟

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

لماذا يجب تقليل الثقة في التطبيقات؟

يمكن توصيل التطبيقات بـ Ethereum بطريقة موثوقة - يمكنها الكتابة والقراءة من Ethereum blockchain ولكن يتم وضع الثقة على المشغلين لتنفيذ منطق الأعمال بشكل صحيح. تعد التبادلات المركزية مثل Binance و Coinbase أمثلة رائعة للتطبيقات الموثوقة. إن الاتصال بـ Ethereum يعني أن التطبيقات يمكنها الاستفادة من شبكة تسوية عالمية بمجموعة متنوعة من الأصول.

هناك مخاطر كبيرة مرتبطة بخدمات موثوقة خارج السلسلة. يعد انهيار البورصات والخدمات الرئيسية في عام 2022، مثل FTX و Celsius ، قصة تحذيرية رائعة لما يحدث عندما تسيء الخدمات الموثوقة التصرف وتفشل.

من ناحية أخرى، يمكن للتطبيقات ذات الحد الأدنى من الثقة الكتابة إلى Ethereum والقراءة منها بشكل يمكن التحقق منه. تشمل الأمثلة تطبيقات العقود الذكية مثل Uniswap والمجموعات مثل Arbitrum أو ZKSync والمعالجات المشتركة مثل Lagrange و Axiom. بشكل عام، تتم إزالة الثقة عندما تصبح التطبيقات مؤمنة بواسطة شبكة Ethereum، حيث يتم الاستعانة بمصادر خارجية لمزيد من الوظائف (انظر أدناه) إلى L1. ونتيجة لذلك، يمكن تقديم الخدمات المالية بأقل قدر من الثقة دون مخاطر الطرف المقابل أو الوصي.

هناك ثلاث خصائص رئيسية يمكن أن تمتلكها التطبيقات والخدمات، والتي يمكن الاستعانة بمصادر خارجية لـ L1:

1. الحيوية (والطلب): يجب تضمين المعاملات المقدمة من المستخدم (تنفيذها وتسويتها) في الوقت المناسب.
2. الصلاحية: تتم معالجة المعاملات وفقًا لقواعد محددة مسبقًا.
3. توفر البيانات (والحالة): البيانات التاريخية، بالإضافة إلى حالة التطبيق الحالية، متاحة للمستخدم.

بالنسبة لكل من الخصائص المذكورة أعلاه، يمكننا التفكير في افتراض الثقة المطلوب؛ على وجه الخصوص، هل توفر Eth L1 العقار أم أن الثقة الخارجية مطلوبة. يصنف الجدول أدناه هذا لنماذج معمارية مختلفة.

لماذا نبني أنظمة قابلة للتطوير أفقيًا؟

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

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

المطالبة 1: لا يمكن توسيع مجموعات البيانات (بيانات المعاملات) أفقيًا لأنها يمكن أن تتعرض للاختناق بسبب توفر البيانات (DA). يتطلب التوسع الرأسي لحلول DA تقديم تنازلات بشأن اللامركزية.

يظل توفر البيانات (DA) عقبة أمام عمليات تجميع البيانات. حاليًا، لكل كتلة L1 هدف أقصى للحجم يبلغ ~ 1 ميغابايت (85 كيلو بايت/ثانية). مع EIP-4844، ستكون هناك مساحة إضافية تبلغ حوالي 2 ميجابايت (171 كيلو بايت/ثانية) متاحة (على المدى الطويل). مع Danksharding، قد تدعم Eth L1 في النهاية ما يصل إلى 1.3 ميجابايت/ثانية من عرض النطاق الترددي DA. Eth L1 DA هو مورد مشترك تتنافس عليه العديد من خدمات التطبيقات &. لذلك، على الرغم من أن استخدام L1 لـ DA يوفر أفضل أمان، إلا أنه يحد من قابلية التوسع المحتملة لهذه الأنظمة. الأنظمة التي تستخدم L1 لـ DA لن تكون (عادةً) قادرة على التوسع أفقيًا ولديها وفورات الحجم. تحتوي طبقات DA البديلة، مثل Celestia أو eiGenda، أيضًا على حدود النطاق الترددي (على الرغم من أنها أكبر، عند 6.67 ميجابايت/ثانية و 15 ميجابايت/ثانية، على التوالي). ولكن ذلك يأتي على حساب تحويل افتراض الثقة من إيثريوم إلى شبكة أخرى (غالبًا ما تكون أقل لامركزية)، مما يؤثر على الأمن (الاقتصادي).

المطالبة 2: الطريقة الوحيدة لتوسيع نطاق الخدمات المصغرة من الثقة أفقيًا هي الحصول على (بالقرب من) بيانات L1 الهامشية الصفرية لكل معاملة. النهجان المعروفان هما مجموعات فرق الحالة (SDR) والفاليديوم.

مجموعات فروق الحالة (SDRs) عبارة عن مجموعات تنشر اختلافات الحالة عبر مجموعة مجمعة من المعاملات إلى Ethereum L1. بالنسبة إلى EVM، مع نمو دفعات المعاملات بشكل أكبر، تتضاءل بيانات كل معاملة المنشورة على L1 إلى ثابت أصغر بكثير من تلك الخاصة بتجميع بيانات المعاملات.

على سبيل المثال، أثناء حدث اختبار الإجهاد المتمثل في تدفق أعداد كبيرة من التسجيلات، شهدت ZKSync انخفاضًا في بيانات المكالمات لكل معاملة إلى ما يصل إلى 10 بايت لكل معاملة. في المقابل، عادةً ما ترى مجموعات بيانات المعاملات مثل Arbitrum و Optimism و Polygon zKevm حوالي 100 بايت لكل معاملة لحركة المرور العادية.

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

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

ماذا عن أجهزة التسلسل المركزية مقابل أجهزة التسلسل اللامركزية؟ للحفاظ على الأنظمة قابلة للتطوير أفقيًا، من الضروري إنشاء أجهزة التسلسل المستقلة، سواء المركزية أو اللامركزية. والجدير بالذكر أنه على الرغم من أن الأنظمة التي تستخدم أجهزة التسلسل المشتركة تتمتع بقابلية التركيب الذري < a href= " https://hackmd.io/@EspressoSystems/sharedSequencing " >، إلا أنها لا تستطيع التوسع أفقيًا، حيث يمكن أن يصبح جهاز التسلسل عقبة مع إضافة المزيد من الأنظمة.

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

تقليل الثقة للأنظمة القابلة للتطوير أفقيًا

هل يمكننا تقليل متطلبات الثقة بشكل أكبر فيما يتعلق بالحيوية والترتيب وتوافر البيانات في الأنظمة القابلة للتطوير أفقيًا؟

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

الحل الآخر هو ببساطة اللامركزية (ولكن لا تعتمد على L1). بدلاً من جهاز التسلسل الفردي، يمكن أن تصبح الأنظمة أكثر لامركزية من خلال استخدام أجهزة التسلسل اللامركزية (مثل Espresso Systems أو Astria)، وبالتالي تقليل الثقة المطلوبة للحياة والترتيب وتوافر البيانات. يؤدي القيام بذلك إلى وضع قيود مقارنة بحلول المشغل الفردي: (1) قد يكون الأداء مقيدًا بأداء النظام الموزع، و (2) بالنسبة للصلاحيات ذات DA الخاص، يتم فقدان ضمان الخصوصية الافتراضي إذا كانت شبكة التسلسل اللامركزي غير مصرح بها.

ما مقدار الثقة التي يمكننا تقليلها أيضًا في عمليات التحقق من صحة المشغل الفردي أو حقوق السحب الخاصة؟ هناك بعض الاتجاهات المفتوحة هنا.

الاتجاه المفتوح 1: توفر البيانات بأقل قدر من الثقة في فترات الصلاحية. تعمل البلازما على حل مشكلة توفر الحالة إلى حد معين - فهي تحل المشكلة إما لعمليات السحب فقط لنماذج حالة معينة (والتي تتضمن نموذج حالة UTXO)، أو تتطلب من المستخدمين الاتصال بالإنترنت بشكل دوري (Plasma Free).

الاتجاه المفتوح 2: التأكيدات المسبقة المسؤولة في حقوق السحب الخاصة والصلاحيات. الهدف هنا هو تزويد المستخدمين بتأكيد مسبق سريع لإدراج المعاملة من المنظم، ويجب أن يسمح التأكيد للمستخدم بتحدي وخفض الحصة الاقتصادية للمُسلسل إذا لم يتم الوفاء بوعد التضمين. يتمثل التحدي هنا في أن إثبات عدم التضمين (ضروري للقطع) يتطلب على الأرجح بيانات إضافية للمستخدم، والتي يمكن للمتسلسل حجبها ببساطة. لذلك، من المعقول أن نفترض أننا نطلب على الأقل من SDR أو validium توظيف لجنة توفر البيانات (التي يحتمل أن تكون مرخصة) لبيانات المكالمات الكاملة أو سجل المعاملات، مما يمكّن نفس اللجنة من تقديم دليل على عدم الإدراج (للمعاملات المؤكدة مسبقًا) بناءً على طلب المستخدم.

الاتجاه المفتوح 3: التعافي السريع من حالات فشل الحياة. يمكن أن تعاني أنظمة المشغل الفردي من فشل التشغيل (على سبيل المثال. تم إيقاف تشغيل Arbitrum أثناء حدث التسجيل). هل يمكننا تصميم أنظمة توفر الحد الأدنى من انقطاع الخدمة في هذا السيناريو؟ بمعنى ما، توفر L2s التي تسمح بالتسلسل الذاتي ومقترحات الدولة ضمانات ضد فشل الحياة لفترات طويلة. لا يزال تصميم أنظمة المشغل الفردي الأكثر مرونة ضد حالات فشل التشغيل الأقصر غير مستكشفة حاليًا. أحد الحلول المحتملة هنا هو جعل الفشل في الحياة مسؤولاً، من خلال توفير الحد من حالات فشل الحياة. الحل المحتمل الآخر هو ببساطة تقصير فترة التأخير (التي من المقرر حاليًا أن تكون حوالي أسبوع) قبل أن يحدث الاستحواذ.

الخاتمة

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

شكر وتقدير

شكراً جزيلاً لفيتاليك بوترين وتيري تشونغ على التعليقات والمناقشة، وكذلك ديانا بيغز على تعليقاتها التحريرية.

：

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [Mirror]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [1kx]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.