كممثل لمسار توسيع Rollup في L2 ، بعد Arbitrum airdrop ، سيتم إطلاق zkSync Era. خلف التصميمات وخرائط الطريق الجديدة التي لا نهاية لها ، ما هو الخط الرئيسي للعرض التراكمي وما هو التفكير التطوري؟ دعنا نلقي نظرة اليوم.
النقاط الرئيسية في هذا المقال:
فكرة توسيع L1 مكتوبة للصف الثالث
تصميم حل تراكمي من الصفر
كيفية استخدام إثبات عدم المعرفة لجعل Rollup يتطور مرة أخرى
البدء بالقياس
بالنسبة إلى Bitcoin و Ethereum ، منذ ولادتهما ، هناك نوعان من الانتقادات من المستخدمين العاديين:
بطيء: الممر ضيق في الأصل ، وإذا كان هناك عدد كبير جدًا من السيارات ، فسيتم حظره.
باهظة الثمن: الرسوم على القمم المسطحة ليست رخيصة. إذا كنت تريد المرور بسرعة خلال فترة الذروة ، فأنت بحاجة إلى استخدام "القدرة المالية" لإضافة الأموال والسماح لعمال المناجم بالطيران بطائرات هليكوبتر للحصول عليك.
ينبع هذان الانتقادان من عاملين في تصميم blockchain:
سعة الكتلة: مماثلة للحارة ، فكلما زادت سعة الكتلة ، زاد عدد السيارات التي يمكن أن تستوعبها ، وقل احتمال انسدادها.
آلية التحفيز: بغض النظر عن حجم الممر ، فهناك احتمال أن يتم حظره. في هذه الحالة ، من يُسمح له بالمرور أولاً؟ يعتمد ذلك على من هو في عجلة من أمره ، ولكن لا يمكنك الاستماع فقط إلى كلمات الناس ، يعتمد ذلك على مدى استعدادك للدفع ، مثل استدعاء سيارة إسعاف ، وستكون عدة مئات.
إذا كان من الممكن أن تكون blockchain حقًا مثل الممر ، فإن الحل الأساسي هو بطبيعة الحال توسيع الممر ، وفي نفس الوقت التعاون مع وسائل السعر لتوجيه الوقت للخروج ، ولا تخرج إذا لم تكن في عجل.
ومع ذلك ، على الرغم من أن توسيع الممرات وزيادة سعة الكتلة يعد حلاً جذابًا لكفاءة حركة المرور ، إلا أنه يعد الملاذ الأخير في تصميم blockchain. نظرًا لأنه كلما زاد حجم الكتلة ، زادت متطلبات الأجهزة لعمال المناجم ، وقل عدد عمال المناجم الذين يمكنهم تلبية المتطلبات ؛ وفقًا لهذه الفكرة ، إذا كنت ترغب في معالجة آلاف المعاملات في الثانية مثل Visa ، فسوف ينتهي بك الأمر إلى إجراء عملية أخرى تتعارض Visa المركزية مع الغرض الأساسي المتمثل في عدم الثقة في blockchain.
هل هناك أي حل آخر؟ نعم ، بالإضافة إلى إرشادات الوقت ، يمكننا أيضًا تحسين المساحة ، بما في ذلك على سبيل المثال لا الحصر:
فتح ممرات مختلفة ، أحدهما للشاحنات الكبيرة والآخر للسيارات والآخر للحافلات ، دون التدخل مع بعضنا البعض - بناءً على هذه الفكرة ، يمكننا الوصول إلى بعض السلاسل الرئيسية أو السلاسل الجانبية أو البلازما بقوتها الخاصة.
قم بتحسين تصميم المسار ، وتحويل حركة المرور بشكل مناسب ، ولا تذهب إلى المدينة لفعل أي شيء ، عليك أن تسلك هذا الطريق الرئيسي ، عليك المرور عبر نقطة التفتيش هنا - - بناءً على هذه الفكرة ، يمكننا تقسيمها.
لماذا عليك الخروج؟ لم يفت الأوان بعد على عقد اجتماع عن بعد والتوصل إلى اتفاق ، ولم يفت الأوان بعد لتوقيع اتفاقية دون اتصال بالإنترنت - - بناءً على هذه الفكرة ، يمكن أن يكون لدينا قناة حكومية (قناة الدولة).
لست مضطرًا بالضرورة إلى القيادة بمفردك عند الخروج ، يمكنك أيضًا استخدام سيارة مشتركة ، أو استخدام وسائل النقل العام - - بناءً على هذه الفكرة ، لدينا بطل هذه المقالة ، Rollup.
كحافلة على blockchain ، فإن مفتاح Rollup هو توفير المساحة والبنزين (الغاز ، التورية المقصودة):
وفر مساحة ، لذلك ليس من السهل أن تتعثر ، والتكلفة التي يتقاسمها كل شخص أقل بكثير من القيادة بمفردك ؛
يتم توفير البنزين وبالتالي فإن سعر التذكرة قريب من الناس ويمكن للجميع تحمله.
وبهذه الطريقة ، يتم حل فتحات "بطيء" و "باهظ الثمن" بواسطة Rollup.
دعنا نعود إلى blockchain ونرى الخطة المحددة لـ Rollup.
تصميم مجموعة من الصفر ؛
بدلاً من إلقاء نظرة خاطفة على الإجابة القياسية (ناهيك عن عدم وجود) ، من الأفضل أن يكون لديك بعض التشويق وتخيل ما ستفعله عندما يتم تكليفك بتصميم Rollup for Ethereum.
قد نبدأ أيضًا من منظورين لتقليل تكاليف الحوسبة (توفير البنزين) وتقليل تكاليف التخزين (توفير مساحة) ، ونقترح أولاً حلًا أكثر جذرية يسمى Rollup 1.0 ؛.
تراكم 1.0 ؛
يتكون Rollup 1.0 من 3 نقاط رئيسية:
هناك مقدم خدمة (مشغل) يقوم بتجميع معاملات "مشاركة السيارات" (المعاملة) لكل شخص ، و "إرسال الطلبات" عندما يكون مرافقي السيارات ممتلئًا أم لا ولكن الوقت المتفق عليه قد انتهى ، مع مراعاة السعر والتوقيت ؛
يتم تنفيذ جميع العمليات الحسابية المتضمنة في المعاملات المقدمة من قبل الجميع خارج السلسلة بواسطة مزود الخدمة هذا ، لأن العمليات الحسابية خارج السلسلة تكون أسرع من الحسابات على السلسلة ، وغالبًا ما تكون العمليات الحسابية الجزء الأكبر من تكاليف السلسلة ، والتي يمكن أن توفر الكثير من مال؛
بعد الحساب ، احصل على الحالة المحدثة (مثل آخر رصيد في حسابك) ، وقم بتخزينها في السلسلة ، بحيث تكون تكلفة التخزين أقل بكثير.
وببساطة ، فإن الأمر يتعلق بجمع طلبات المعاملات الخاصة بكل فرد بشكل منتظم وكمي ، وبعد إجراء الحسابات خارج السلسلة ، يتم فقط تقوية نتائج الحساب في السلسلة.
هذا الحل يحل بشكل مثالي نقطتي الألم الرئيسيتين وهما "البطيء" و "المكلف" ، ولكن يبدو أنه يولد مشاكل جديدة:
الحافز: من سيقدم خدمة "مشاركة السيارات" وما هي الفوائد.
مشكلة المراجعة (الرقابة): مقدم الخدمة لا يعالج طلبي عن عمد (أو ينهي أو يستقيل) ، فماذا أفعل ؛
مشكلة الاحتيال (الاحتيال): ماذا أفعل إذا قام مزود الخدمة بالغش والتلاعب بنتائج الحساب ، مما تسبب في تحويل الأموال إلى الغير ، واختلس المال منه.
لهذه المشاكل الثلاث الجديدة ، يمكننا تكرار نسخة من الخطة.
تراكم 2.0 ؛
أفضل حل لمشكلة التحفيز ، والمشكلات التي يمكن حلها بالمال ليست مشاكل. يمكن لمزود الخدمة أن يتقاسم تكلفة "استخدام السيارات" بشكل متساوٍ ، وأن يتقاضى "إكرامية" إضافية قليلاً. ومع ذلك ، لا يزال الوضع مربحًا للطرفين مع "استخدام السيارات المشتركة".
تعد مشكلة المراجعة أكثر إزعاجًا ، لكن الحل شائع جدًا في مجال blockchain ، وهذا هو اللامركزية. مجموعة من الأشخاص هم مقدمو خدمة ، وهذا أفضل من مقدم خدمة واحد فقط ؛ يمكن لأي شخص أن يكون مقدم خدمة ، وهو أفضل من مجموعة ثابتة من الأشخاص. في طريقة اللعب الأخيرة ، إذا لم يكن جميع مقدمي الخدمة جيدين ، يمكنك أيضًا أن تكون مقدم خدمة بنفسك ، أو انتقل مباشرة إلى L1 لبدء التحكيم.
الاحتيال أصعب قليلاً. يمكن تقسيمها إلى سؤالين - أحدهما هو كيفية تحديد الاحتيال ، والآخر هو كيفية منعه.
بادئ ذي بدء ، لتحديد الاحتيال ، نحتاج إلى معرفة بيانات المعاملة (المعاملة) الخاصة بكل شخص ، الحالة قبل المعاملة (الدولة) ، وذلك لحساب الحالة الجديدة (الدولة ') بعد المعاملة ، ومقارنتها بالحالة الجديدة مخزنة في سلسلة مقدم الخدمة ، فإذا كانت هي نفسها ، فهذا يعني أن مقدم الخدمة صادق ، وإلا فهذا يعني أنه كذب. ومع ذلك ، لا نعرف بيانات المعاملات لأنها ليست متصلة بالسلسلة. نتيجة لذلك ، لا يمكننا إلا أن نكون متشككين وغير قادرين على الحكم على ما إذا كان مزود الخدمة صادقًا أم لا.
بعد ذلك ، فإن أفضل طريقة لمنع الاحتيال هي جعل حدوث الاحتيال أمرًا مستحيلًا. وهذا أمر صعب نسبيًا ، ما لم يتم التحقق من حساب مقدم الخدمة في كل مرة على السلسلة ، ولكن بهذه الطريقة ، لن تكون هناك ميزة لـ " استخدام السيارات". لذلك لا يمكننا إلا أن نتراجع خطوة إلى الوراء ونجعل تكلفة الاحتيال عالية جدًا ، بحيث يكون لمقدمي الخدمة ميزة في اللعبة ، مثل دفع وديعة (Stake) ، والتي ستتم مصادرتها في حالة اكتشاف الاحتيال. (تسمى هذه الطريقة بالإجماع الاجتماعي ، والتي تنتمي إلى الأمان المستند إلى اللعبة ، وهي مذكورة أيضًا في "Weekly # 3 ؛".)
تراكم 3.0 ؛
Rollup 2.0 ليس سيئًا ، لكن مشكلة تحديد الاحتيال لم تحل.
وفقًا للاستدلال السابق ، لتحديد الاحتيال ، يجب أن نعرف بيانات المعاملة ، لذلك يجب أن يكون هذا الجزء من البيانات على نفس سلسلة بيانات الحالة.
من الذي سيكتشف أنهم محتالون؟ من الواضح أنه من غير المحتمل أن يكون هذا مستخدمًا عاديًا ، لأنه من المستحيل على الجميع مراقبة كل خطوة لمقدم الخدمة 7 ؛ × ؛ 24 ساعة ، لذلك لا يمكن أن يكون سوى "صائد جوائز" محترف (Validator). إذا أبلغ "صائد المكافآت" عن احتيال في غضون 7 أيام بعد "إرسال مقدم الخدمة" للطلب وتحقق من صحته ، فسيتم إلغاء المعاملة ومعاقبة مزود الخدمة. بالطبع ، بالطريقة نفسها ، يحتاج "صائدو المكافآت" أيضًا إلى حوافز. على سبيل المثال ، بعد اكتشاف الاحتيال ، سيتم منح جزء من وديعة مقدم الخدمة إلى "صائد الجوائز" (جزء فقط ، لتجنب التواطؤ بين مقدم الخدمة وصائد الجوائز).
تراكم 4.0 ؛
بحلول مرحلة Rollup 3.0 ، كان الحل بأكمله قادرًا على العمل بسلاسة ، ولكن تم تقديم تكاليف جديدة. تشمل التكاليف حتى الآن ما يلي:
الرسوم لمقدمي الخدمات (بما في ذلك التكاليف و "الإكراميات") ؛
تكلفة التخزين على السلسلة للمعاملات وبيانات الحالة ؛
عندما يعتقد "Bounty Hunter" أن مقدم الخدمة احتيالي ، فإن التكلفة الحسابية للتحقق مما قاله صحيحة على السلسلة.
دعونا نلقي نظرة على التكاليف التي يمكن تحسينها.
بيانات المعاملات
بطريقة معينة ، يتم تجميع المعاملات المتعددة معًا ، ويمكن أن تكون المساحة المشغولة أصغر من مجموع المساحة التي تشغلها كل معاملة.
بأخذ أبسط معاملة تحويل ETH كمثال ، نقوم بتفكيك تركيبة المحتوى لكل معاملة ، ويمكننا أن نرى أن مساحة التوقيع تمثل النسبة الأكبر. يمكننا دمج توقيعات جميع المعاملات في واحد (Key Aggregation) ، مما يوفر الكثير من مساحة التخزين (على غرار Schnorr في Bitcoin). بالإضافة إلى ذلك ، يمكننا أيضًا تحسين الأجزاء الأخرى ، مثل التخلص من Nonce ، واختيار "سمين ونحيف" قدر الإمكان عند "استخدام السيارة" ، و "شخص مشترك في السيارة" يناسب تمامًا لتحقيق أقصى استفادة من "السيارة " فضاء.
! [تستكشف هذه المقالة أفكار التطور وأسباب التصميم لحل توسعة Rollup] (https://img.gateio.im/social/moments-7f230462a9-13f6e74b0f-dd1a6f-e5a980)
مصدر:
ثلاث مرات أو مرتين فقط ، تم تقليل حجم كل معاملة تحويل ETH من 112 بايت إلى 12 بايت ، وهو ما يقرب من عُشر المعاملة السابقة ؛ بالطبع ، هناك وسائل أخرى لزيادة ضغط بيانات المعاملة.
في التشغيل الفعلي ، يمكننا تثبيت مثل هذه الطريقة في العقد المنشور على السلسلة:
function storeTxData (بايت بيانات calldata) خارجي {؛ // لا تفعل شيئًا}
ثم في كل مرة تنجح فيها "مشاركة السيارات" ، يتم تمرير بيانات المعاملة المدمجة والمضغوطة إلى هذه الطريقة كبيانات اتصال. لا يلزم تخزين Calldata بشكل دائم ، وبعد فترة تحدي الدعاية للإجماع الاجتماعي (فترة التحدي) ، لن يكون الأمر مهمًا إذا تم تقليمه (تقليم) ؛ السعر نفسه منخفض جدًا ، وسيكون أرخص مع تنفيذ EIPs مثل Danksharding و Data Blob ، هذا الشكل من تطبيق L1 لتوزيع تخزين البيانات (توفر البيانات) سيكون أيضًا أكثر رسمية.
بيانات الحالة
الآن بعد أن تم تحميل بيانات المعاملة إلى السلسلة ، يمكن لأي شخص حساب الحالة المحدثة من خلال بيانات المعاملة ، وبيانات الحالة ليست ضرورية للغاية. يمكننا فقط الاحتفاظ بجذر ميركل لبيانات الولاية ، والذي يتم استخدامه للسماح للمستخدمين العاديين ("مستخدمو السيارات") بتقديم طلبات سحب مباشرة إلى L1 عندما لا يتعاون مزود الخدمة ، والاعتماد على Merkel Proof لإثبات امتلاكهم المال في حساباتهم.
تكاليف التحكيم في الاحتيال
عندما يقوم "صائد المكافآت" بالإبلاغ عن عملية احتيال لمزود الخدمة ، يتم إجراء حساب العقد على السلسلة (إعادة التشغيل) مرة واحدة ومقارنة نتائج الحالة ، وهذا ممكن من الناحية النظرية. ومع ذلك ، فإن تكلفة القيام بذلك ليست منخفضة (على الرغم من أنها جيدة بالفعل) ، والثاني هو أن مجموع الغاز من المعاملات المدرجة في "قائمة مشاركة السيارات" التراكمية قد يتجاوز حد الغاز الخاص بـ Ethereum ، مما يجعل ذلك مستحيلًا للتحقق.
لذلك ، يحتاج التحكيم إلى تقليل العبء ، وطريقة تقليل العبء هي بطبيعة الحال وضع العمليات الحسابية غير الضرورية خارج السلسلة. أحد الحلول يسمى الإثبات التفاعلي. العملية العامة هي كما يلي:
يقوم "Bounty Hunter" بدفع وديعة ، ثم يقوم بالإبلاغ ، ويقسم عملية الحساب بأكملها إلى n شرائح بالترتيب ، مشيرًا إلى أن مزود الخدمة لديه احتيال في المقطع k (1 ؛ ≤k≤n) ؛
قام مزود الخدمة بالتنقيب في الجزء k وتفكيكه في المقطع k ، وأشار إلى أي جزء من "صائد الجوائز" غير صحيح ؛
ذهابًا وإيابًا ، مع العلم أنه لم يعد من الممكن حفر أو تفكيك عملية الحساب ، على سبيل المثال ، عندما يفكر "صائد الجوائز" 1+ ؛ 1 ؛ = ؛ 2 ؛ يعتقد مقدم الخدمة 1+ ؛ 1 ؛ = ؛ 3 ؛ ؛
في هذا الوقت ، يتدخل العقد على السلسلة ، ويحسب 1+ ؛ 1 ؛ ويحصل على 2 ؛ وبالتالي تحديد أن مزود الخدمة احتيالي ، ومصادرة وديعته ، ومكافأة جزء منه إلى "صائد الجوائز".
(أثناء العملية برمتها ، إذا فشل أحد الأطراف في الرد خلال مهلة زمنية محددة ، يفشل الحزب.)
بهذه الطريقة ، تكون تكلفة التحكيم في السلسلة بأكملها منخفضة جدًا جدًا.
بعد قولي هذا ، قمنا ببناء حل تراكمي بالكامل. نظرًا لأن هذا المخطط يفترض أن مقدم الخدمة صادق بشكل افتراضي ، ما لم يكن هناك تقرير "صائد المكافآت" ، فإن هذا الفصيل يسمى تراكم المتفائل ، ما يسمى بالتجميع المتفائل.
إذن ، هل Rollup 4.0 هو الحل الأفضل؟
إعادة تطوير التراكمية
بعد التكرارات المتعددة ، لا يزال لدى Rollup 4.0 بعض العيوب:
يجب اكتشاف الاحتيال بواسطة "صائدي المكافآت" ، ولكن إذا لم يكن هناك احتيال لفترة طويلة ، فقد يتوقف "صائدو المكافآت" عن العمل لأنهم غير مربحين ، لذلك ستكون هناك فجوة (على الرغم من احتمال حدوث ذلك ، بسبب من المرجح أن يعمل أصحاب المصلحة في سلسلة التدوير مثل بائعي التطبيقات كـ "صائدي الجوائز") ؛
للتأكد من عدم وجود احتيال ، بناءً على الإجماع الاجتماعي ، عليك الانتظار لعدة أيام ، مما سيؤثر على عمليات مثل عمليات السحب ؛
هناك الكثير من البيانات عن السلسلة ، والتكلفة لا تزال موجودة ؛
بالاعتماد حاليًا على طبقة توسيع التراكمية ، يمكن زيادة الإنتاجية بمقدار 10 أضعاف ، فهل من الممكن أن تكون أعلى؟
هل هناك حل يمكن أن يجعل الاحتيال مستحيلًا على الإطلاق ، ويجعل النهاية (النهائية) أسرع ، ويقلل من الحاجة إلى تحميل البيانات إلى السلسلة ، ويجعل التوسيع أمرًا من حيث الحجم أكثر؟ أنت لا تريد الكثير ، ولكن يوجد مثل هذا النوع من الحلول التي يمكن أن ترضي جميع التخيلات تقريبًا - Zero Knowledge Rollup (ZK-Rollup للاختصار).
ZK-Rollup هي فكرة تراكمية تستخدم إثبات المعرفة الصفرية (ZKP). يشير ما يسمى بـ ZKP إلى التكنولوجيا التي تقنع الطرف الآخر أنك تعرف هذه المعلومات دون الكشف عن أي معلومات حساسة. لشرح ZKP ، هناك اثنان من الأمثلة المفضلة لدي:
تخيل مدينة أوروبية من العصور الوسطى ولدي خريطة كنز عليها كنز. لكي أثبت لك أن لدي خريطة كنز ، لكن دون أن أخبرك بالموقع الدقيق للكنز ، أضع عصابة على عينيك ، وأجرك إلى عربة ، وقمت بالقيادة في المدينة لمدة نصف ساعة للتأكد من أنك تفقد إحساسك بالاتجاه ، وصل أخيرًا إلى الوجهة ، واخرج من السيارة وأظهر لك الكنز ، ثم اصطحبك مرة أخرى. هذا شكل ساذج من ZKP.
تشبيه آخر أكثر شيوعًا. لنفترض أن هناك أحجية سودوكو ، فأنا أعرف الإجابة ولكنك لا تعرفها ، لكنك لا تصدق أنني أعرف ؛ أريد أن أثبت لك أنني أعرف ، لكني لا أريدك أن تعرف الإجابة. ما يجب القيام به؟ يمكنني وضع سودوكو على الطاولة بالبطاقات ، ثم أضع الأرقام المفتوحة والأرقام التي يجب ملؤها لأسفل ، وأسمح لك باختيار التحقق من إجابتي حسب الصف أو العمود. إذا كان بالصف ، فسأجمع الأرقام في كل صف معًا ، وأقسمها ، وأظهر لك أن كل صف هو من 1 إلى 9 ؛. لا بأس في تكراره عدة مرات ، لذلك يمكنك أن تصدق أنني أعرف الإجابة حقًا باحتمالية عالية. هذه إحدى طرق الإثبات التفاعلية لـ ZKP (لأنه من الصعب تحقيق تفاعل على السلسلة في الوقت الفعلي في blockchain ، يتم استخدام الدليل غير التفاعلي بشكل عام ، ويتم إنشاء تحديات عشوائية بواسطة وظيفة Hash).
بعبارات أقل صرامة ، فإن الفكرة الأساسية لـ ZKP هي أن المُثبِت (Prover) يخفي أولاً المعرفة السرية ، "يلتزم" (الالتزام) ، ثم يبدأ المدقق (المدقق) في تحدي عشوائي (التحدي). فقط إذا نجح في اجتياز التحدي ، فهناك احتمال كبير أن يكون لديه المعرفة السرية المقابلة.
يجب أن يفي ZKP بثلاثة متطلبات:
إذا كان المُثبِّت ، فهناك احتمال كبير بالفشل في التحدي (الصحة) ؛
إذا كان لدى المُثقف معرفة ، فسيكون قادرًا على اجتياز التحدي (الاكتمال) ؛
أثناء التفاعل بين الطرفين ، لن يقوم المُثبِّت بالإفصاح عن أي معلومات مفيدة (عدم المعرفة).
من أجل تلبية هذه المتطلبات الثلاثة ، يستخدم ZKP مجموعة متنوعة من مشكلات NP ، بما في ذلك أبسط تحلل للأرقام الأولية واللوغاريتمات المنفصلة (مثل Schnorr is) وما إلى ذلك.
ZKP ليست تقنية ولدت من أجل blockchain ، ولكن يمكن استخدامها لتوسيع L2 ، ويرجع ذلك أساسًا إلى أن ZKP الجيد له الخصائص المفيدة التالية:
يمكن للمثقف (مقدم الخدمة) أن يقدم إثباتًا سريعًا ، وذلك للتأكد من أن كفاءة الحساب تحت السلسلة عالية جدًا ولن تصبح عنق الزجاجة ؛
حجم الإثبات صغير ، أو يتناسب على الأقل مع مقدار الحساب المراد إثباته ، وتأثير كمية البيانات ضئيل قدر الإمكان ، بحيث تكون تكلفة التخزين على السلسلة منخفضة ؛
يمكن للمدقق (عقد L1) التحقق بسرعة من صحة الإثبات ، وبالتالي فإن تكلفة الحساب في السلسلة منخفضة.
باستخدام هذه الميزات ، يمكن أن يقوم حل Rollup الخاص بنا بما يلي:
ليست هناك حاجة إلى "صائد الجوائز" ، يمكن لعقد L1 الكشف عن الاحتيال على الفور من تلقاء نفسه ؛
طالما أن التحقق من ZKP صالح ، يمكن إجراء عمليات السحب على الفور ، ويتم تقصير المدة النهائية من أيام إلى دقائق ؛
مطلوب فقط الاختلافات بين الدول في السلسلة ، والمساحة صغيرة جدًا ، وتكلفة التخزين منخفضة جدًا (مكافأة إضافية - تم تحسين الخصوصية أيضًا) ؛
من خلال تحسين البرامج والأجهزة المخصصة لعملية الإثبات والتحقق ، يمكن زيادة سعة التوسيع بترتيب آخر من حيث الحجم.
بالطبع ، أي آلية أمنية سيكون لها متطلبات مسبقة محتملة ، و ZKP ليس حلاً سحريًا لـ blockchain. لا يزال ZKP يعاني من العديد من القيود في الوقت الحالي ، والتي يجب التغلب عليها خطوة بخطوة ، مثل:
خذ zk-SNARK الأكثر استخدامًا على blockchain كمثال. تحتاج العديد من المخططات إلى تقديم أكبر عدد ممكن من الأشخاص أو الشركات المرموقة في البداية ، وإجراء إعداد موثوق به لإنشاء رقم عشوائي حقيقي وضمان عملية التوليد هي يمكن التحقق منه ولكن ليس علنيًا بالكامل (كما هو الحال في حفل Power of Tau ، طالما يمكن الوثوق بطرف واحد ، لكنه لا يزال يعتبر عيبًا). بالطبع ، يمكن لبعض مخططات zk-SNARK الجديدة و zk-STARKs المحسنة لاحقًا حل هذه المشكلة ، ولكن في بعض الأحيان يتم تقديم مشاكل جديدة.
يصعب تلخيص العديد من المشكلات على أنها مشاكل ZKP ، مما أدى إلى حقيقة أن قابلية البرمجة لم يتم حلها بشكل جيد لفترة طويلة. من الصعب إدراك أن ZKP متوافق تمامًا مع EVM على Ethereum ، أو حتى إذا كان من الممكن أن يكون كذلك تم تحقيقه ، ولكن ستتأثر جوانب أخرى (مثل كفاءة التحقق).
! [تستكشف هذه المقالة أفكار التطور وأسباب تصميم حل توسيع Rollup] (https://img.gateio.im/social/moments-7f230462a9-7183a49f36-dd1a6f-e5a980)
مصدر:
لهذا السبب ، في ZK-Rollup ، وهو مجال توسع موجه نحو المستقبل ، كل تقدم يستحق الثناء ومرضٍ.
! [تستكشف هذه المقالة أفكار التطور وأسباب التصميم لحل توسعة Rollup] (https://img.gateio.im/social/moments-7f230462a9-0a59b6b5b2-dd1a6f-e5a980)
مصدر:
اكتب في النهاية
بقدر ما يتعلق الأمر بمستقبل توسيع السعة ، يعتقد المؤلف أنه بالمقارنة مع توسيع السعة الأصلية لـ L1 ، فإن التصميم متعدد الطبقات بما في ذلك Rollup هو فكرة أكثر موثوقية. Modularization ، تحل كل طبقة مخاوف كل طبقة ، والتي تكون أقل خطورة من التكديس المستمر على L1 "المتجانسة" بالفعل ؛ علاوة على ذلك ، من غير المحتمل نظريًا أن تكون اللامركزية للطبقة L1 الأساسية بسبب توسيع السعة هي الطبقة العليا تجدها وتجعلها عليه. علاوة على ذلك ، يبدو أن فكرة التصميم متعدد الطبقات هذه لها تطبيقات ناجحة في مجالات أخرى غير blockchain. وجهة النظر ليست صحيحة بالضرورة ، ولكن هذا هو الإدراك الحالي للمؤلف.
تحاول هذه المقالة فرز أسباب التفكير والتصميم الخاصة بحل توسيع التراكمية بنبرة حيادية للمشروع. نظرًا للمستوى المحدود ، لا تزال بعض الأماكن غير حادة بعض الشيء ، الأمر الذي قد لا يفسر الأمر في مكانه فحسب ، بل يزيد أيضًا من صعوبة الفهم ؛ كحقل عمودي يتغير مع مرور كل يوم ، قد لا يكون المؤلف على دراية وتأخذ في الاعتبار العديد من التطورات الجديدة في الوقت المناسب. بصدق نرحب بالأصدقاء للتصحيح والتواصل.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
تناقش هذه المقالة أفكار التطور وأسباب التصميم لحل توسعة Rollup
المؤلف الأصلي: ORFEO
المصدر الأصلي: The SeeDAO
عاد مشروع L2 إلى دائرة الضوء مرة أخرى.
كممثل لمسار توسيع Rollup في L2 ، بعد Arbitrum airdrop ، سيتم إطلاق zkSync Era. خلف التصميمات وخرائط الطريق الجديدة التي لا نهاية لها ، ما هو الخط الرئيسي للعرض التراكمي وما هو التفكير التطوري؟ دعنا نلقي نظرة اليوم.
النقاط الرئيسية في هذا المقال:
البدء بالقياس
بالنسبة إلى Bitcoin و Ethereum ، منذ ولادتهما ، هناك نوعان من الانتقادات من المستخدمين العاديين:
ينبع هذان الانتقادان من عاملين في تصميم blockchain:
إذا كان من الممكن أن تكون blockchain حقًا مثل الممر ، فإن الحل الأساسي هو بطبيعة الحال توسيع الممر ، وفي نفس الوقت التعاون مع وسائل السعر لتوجيه الوقت للخروج ، ولا تخرج إذا لم تكن في عجل.
ومع ذلك ، على الرغم من أن توسيع الممرات وزيادة سعة الكتلة يعد حلاً جذابًا لكفاءة حركة المرور ، إلا أنه يعد الملاذ الأخير في تصميم blockchain. نظرًا لأنه كلما زاد حجم الكتلة ، زادت متطلبات الأجهزة لعمال المناجم ، وقل عدد عمال المناجم الذين يمكنهم تلبية المتطلبات ؛ وفقًا لهذه الفكرة ، إذا كنت ترغب في معالجة آلاف المعاملات في الثانية مثل Visa ، فسوف ينتهي بك الأمر إلى إجراء عملية أخرى تتعارض Visa المركزية مع الغرض الأساسي المتمثل في عدم الثقة في blockchain.
هل هناك أي حل آخر؟ نعم ، بالإضافة إلى إرشادات الوقت ، يمكننا أيضًا تحسين المساحة ، بما في ذلك على سبيل المثال لا الحصر:
كحافلة على blockchain ، فإن مفتاح Rollup هو توفير المساحة والبنزين (الغاز ، التورية المقصودة):
وبهذه الطريقة ، يتم حل فتحات "بطيء" و "باهظ الثمن" بواسطة Rollup.
دعنا نعود إلى blockchain ونرى الخطة المحددة لـ Rollup.
تصميم مجموعة من الصفر ؛
بدلاً من إلقاء نظرة خاطفة على الإجابة القياسية (ناهيك عن عدم وجود) ، من الأفضل أن يكون لديك بعض التشويق وتخيل ما ستفعله عندما يتم تكليفك بتصميم Rollup for Ethereum.
قد نبدأ أيضًا من منظورين لتقليل تكاليف الحوسبة (توفير البنزين) وتقليل تكاليف التخزين (توفير مساحة) ، ونقترح أولاً حلًا أكثر جذرية يسمى Rollup 1.0 ؛.
تراكم 1.0 ؛
يتكون Rollup 1.0 من 3 نقاط رئيسية:
وببساطة ، فإن الأمر يتعلق بجمع طلبات المعاملات الخاصة بكل فرد بشكل منتظم وكمي ، وبعد إجراء الحسابات خارج السلسلة ، يتم فقط تقوية نتائج الحساب في السلسلة.
هذا الحل يحل بشكل مثالي نقطتي الألم الرئيسيتين وهما "البطيء" و "المكلف" ، ولكن يبدو أنه يولد مشاكل جديدة:
لهذه المشاكل الثلاث الجديدة ، يمكننا تكرار نسخة من الخطة.
تراكم 2.0 ؛
أفضل حل لمشكلة التحفيز ، والمشكلات التي يمكن حلها بالمال ليست مشاكل. يمكن لمزود الخدمة أن يتقاسم تكلفة "استخدام السيارات" بشكل متساوٍ ، وأن يتقاضى "إكرامية" إضافية قليلاً. ومع ذلك ، لا يزال الوضع مربحًا للطرفين مع "استخدام السيارات المشتركة".
تعد مشكلة المراجعة أكثر إزعاجًا ، لكن الحل شائع جدًا في مجال blockchain ، وهذا هو اللامركزية. مجموعة من الأشخاص هم مقدمو خدمة ، وهذا أفضل من مقدم خدمة واحد فقط ؛ يمكن لأي شخص أن يكون مقدم خدمة ، وهو أفضل من مجموعة ثابتة من الأشخاص. في طريقة اللعب الأخيرة ، إذا لم يكن جميع مقدمي الخدمة جيدين ، يمكنك أيضًا أن تكون مقدم خدمة بنفسك ، أو انتقل مباشرة إلى L1 لبدء التحكيم.
الاحتيال أصعب قليلاً. يمكن تقسيمها إلى سؤالين - أحدهما هو كيفية تحديد الاحتيال ، والآخر هو كيفية منعه.
بادئ ذي بدء ، لتحديد الاحتيال ، نحتاج إلى معرفة بيانات المعاملة (المعاملة) الخاصة بكل شخص ، الحالة قبل المعاملة (الدولة) ، وذلك لحساب الحالة الجديدة (الدولة ') بعد المعاملة ، ومقارنتها بالحالة الجديدة مخزنة في سلسلة مقدم الخدمة ، فإذا كانت هي نفسها ، فهذا يعني أن مقدم الخدمة صادق ، وإلا فهذا يعني أنه كذب. ومع ذلك ، لا نعرف بيانات المعاملات لأنها ليست متصلة بالسلسلة. نتيجة لذلك ، لا يمكننا إلا أن نكون متشككين وغير قادرين على الحكم على ما إذا كان مزود الخدمة صادقًا أم لا.
بعد ذلك ، فإن أفضل طريقة لمنع الاحتيال هي جعل حدوث الاحتيال أمرًا مستحيلًا. وهذا أمر صعب نسبيًا ، ما لم يتم التحقق من حساب مقدم الخدمة في كل مرة على السلسلة ، ولكن بهذه الطريقة ، لن تكون هناك ميزة لـ " استخدام السيارات". لذلك لا يمكننا إلا أن نتراجع خطوة إلى الوراء ونجعل تكلفة الاحتيال عالية جدًا ، بحيث يكون لمقدمي الخدمة ميزة في اللعبة ، مثل دفع وديعة (Stake) ، والتي ستتم مصادرتها في حالة اكتشاف الاحتيال. (تسمى هذه الطريقة بالإجماع الاجتماعي ، والتي تنتمي إلى الأمان المستند إلى اللعبة ، وهي مذكورة أيضًا في "Weekly # 3 ؛".)
تراكم 3.0 ؛
Rollup 2.0 ليس سيئًا ، لكن مشكلة تحديد الاحتيال لم تحل.
وفقًا للاستدلال السابق ، لتحديد الاحتيال ، يجب أن نعرف بيانات المعاملة ، لذلك يجب أن يكون هذا الجزء من البيانات على نفس سلسلة بيانات الحالة.
من الذي سيكتشف أنهم محتالون؟ من الواضح أنه من غير المحتمل أن يكون هذا مستخدمًا عاديًا ، لأنه من المستحيل على الجميع مراقبة كل خطوة لمقدم الخدمة 7 ؛ × ؛ 24 ساعة ، لذلك لا يمكن أن يكون سوى "صائد جوائز" محترف (Validator). إذا أبلغ "صائد المكافآت" عن احتيال في غضون 7 أيام بعد "إرسال مقدم الخدمة" للطلب وتحقق من صحته ، فسيتم إلغاء المعاملة ومعاقبة مزود الخدمة. بالطبع ، بالطريقة نفسها ، يحتاج "صائدو المكافآت" أيضًا إلى حوافز. على سبيل المثال ، بعد اكتشاف الاحتيال ، سيتم منح جزء من وديعة مقدم الخدمة إلى "صائد الجوائز" (جزء فقط ، لتجنب التواطؤ بين مقدم الخدمة وصائد الجوائز).
تراكم 4.0 ؛
بحلول مرحلة Rollup 3.0 ، كان الحل بأكمله قادرًا على العمل بسلاسة ، ولكن تم تقديم تكاليف جديدة. تشمل التكاليف حتى الآن ما يلي:
دعونا نلقي نظرة على التكاليف التي يمكن تحسينها.
بيانات المعاملات
بطريقة معينة ، يتم تجميع المعاملات المتعددة معًا ، ويمكن أن تكون المساحة المشغولة أصغر من مجموع المساحة التي تشغلها كل معاملة.
بأخذ أبسط معاملة تحويل ETH كمثال ، نقوم بتفكيك تركيبة المحتوى لكل معاملة ، ويمكننا أن نرى أن مساحة التوقيع تمثل النسبة الأكبر. يمكننا دمج توقيعات جميع المعاملات في واحد (Key Aggregation) ، مما يوفر الكثير من مساحة التخزين (على غرار Schnorr في Bitcoin). بالإضافة إلى ذلك ، يمكننا أيضًا تحسين الأجزاء الأخرى ، مثل التخلص من Nonce ، واختيار "سمين ونحيف" قدر الإمكان عند "استخدام السيارة" ، و "شخص مشترك في السيارة" يناسب تمامًا لتحقيق أقصى استفادة من "السيارة " فضاء.
! [تستكشف هذه المقالة أفكار التطور وأسباب التصميم لحل توسعة Rollup] (https://img.gateio.im/social/moments-7f230462a9-13f6e74b0f-dd1a6f-e5a980)
مصدر:
ثلاث مرات أو مرتين فقط ، تم تقليل حجم كل معاملة تحويل ETH من 112 بايت إلى 12 بايت ، وهو ما يقرب من عُشر المعاملة السابقة ؛ بالطبع ، هناك وسائل أخرى لزيادة ضغط بيانات المعاملة.
في التشغيل الفعلي ، يمكننا تثبيت مثل هذه الطريقة في العقد المنشور على السلسلة:
function storeTxData (بايت بيانات calldata) خارجي {؛ // لا تفعل شيئًا}
ثم في كل مرة تنجح فيها "مشاركة السيارات" ، يتم تمرير بيانات المعاملة المدمجة والمضغوطة إلى هذه الطريقة كبيانات اتصال. لا يلزم تخزين Calldata بشكل دائم ، وبعد فترة تحدي الدعاية للإجماع الاجتماعي (فترة التحدي) ، لن يكون الأمر مهمًا إذا تم تقليمه (تقليم) ؛ السعر نفسه منخفض جدًا ، وسيكون أرخص مع تنفيذ EIPs مثل Danksharding و Data Blob ، هذا الشكل من تطبيق L1 لتوزيع تخزين البيانات (توفر البيانات) سيكون أيضًا أكثر رسمية.
بيانات الحالة
الآن بعد أن تم تحميل بيانات المعاملة إلى السلسلة ، يمكن لأي شخص حساب الحالة المحدثة من خلال بيانات المعاملة ، وبيانات الحالة ليست ضرورية للغاية. يمكننا فقط الاحتفاظ بجذر ميركل لبيانات الولاية ، والذي يتم استخدامه للسماح للمستخدمين العاديين ("مستخدمو السيارات") بتقديم طلبات سحب مباشرة إلى L1 عندما لا يتعاون مزود الخدمة ، والاعتماد على Merkel Proof لإثبات امتلاكهم المال في حساباتهم.
تكاليف التحكيم في الاحتيال
عندما يقوم "صائد المكافآت" بالإبلاغ عن عملية احتيال لمزود الخدمة ، يتم إجراء حساب العقد على السلسلة (إعادة التشغيل) مرة واحدة ومقارنة نتائج الحالة ، وهذا ممكن من الناحية النظرية. ومع ذلك ، فإن تكلفة القيام بذلك ليست منخفضة (على الرغم من أنها جيدة بالفعل) ، والثاني هو أن مجموع الغاز من المعاملات المدرجة في "قائمة مشاركة السيارات" التراكمية قد يتجاوز حد الغاز الخاص بـ Ethereum ، مما يجعل ذلك مستحيلًا للتحقق.
لذلك ، يحتاج التحكيم إلى تقليل العبء ، وطريقة تقليل العبء هي بطبيعة الحال وضع العمليات الحسابية غير الضرورية خارج السلسلة. أحد الحلول يسمى الإثبات التفاعلي. العملية العامة هي كما يلي:
(أثناء العملية برمتها ، إذا فشل أحد الأطراف في الرد خلال مهلة زمنية محددة ، يفشل الحزب.)
بهذه الطريقة ، تكون تكلفة التحكيم في السلسلة بأكملها منخفضة جدًا جدًا.
بعد قولي هذا ، قمنا ببناء حل تراكمي بالكامل. نظرًا لأن هذا المخطط يفترض أن مقدم الخدمة صادق بشكل افتراضي ، ما لم يكن هناك تقرير "صائد المكافآت" ، فإن هذا الفصيل يسمى تراكم المتفائل ، ما يسمى بالتجميع المتفائل.
إذن ، هل Rollup 4.0 هو الحل الأفضل؟
إعادة تطوير التراكمية
بعد التكرارات المتعددة ، لا يزال لدى Rollup 4.0 بعض العيوب:
هل هناك حل يمكن أن يجعل الاحتيال مستحيلًا على الإطلاق ، ويجعل النهاية (النهائية) أسرع ، ويقلل من الحاجة إلى تحميل البيانات إلى السلسلة ، ويجعل التوسيع أمرًا من حيث الحجم أكثر؟ أنت لا تريد الكثير ، ولكن يوجد مثل هذا النوع من الحلول التي يمكن أن ترضي جميع التخيلات تقريبًا - Zero Knowledge Rollup (ZK-Rollup للاختصار).
ZK-Rollup هي فكرة تراكمية تستخدم إثبات المعرفة الصفرية (ZKP). يشير ما يسمى بـ ZKP إلى التكنولوجيا التي تقنع الطرف الآخر أنك تعرف هذه المعلومات دون الكشف عن أي معلومات حساسة. لشرح ZKP ، هناك اثنان من الأمثلة المفضلة لدي:
بعبارات أقل صرامة ، فإن الفكرة الأساسية لـ ZKP هي أن المُثبِت (Prover) يخفي أولاً المعرفة السرية ، "يلتزم" (الالتزام) ، ثم يبدأ المدقق (المدقق) في تحدي عشوائي (التحدي). فقط إذا نجح في اجتياز التحدي ، فهناك احتمال كبير أن يكون لديه المعرفة السرية المقابلة.
يجب أن يفي ZKP بثلاثة متطلبات:
من أجل تلبية هذه المتطلبات الثلاثة ، يستخدم ZKP مجموعة متنوعة من مشكلات NP ، بما في ذلك أبسط تحلل للأرقام الأولية واللوغاريتمات المنفصلة (مثل Schnorr is) وما إلى ذلك.
ZKP ليست تقنية ولدت من أجل blockchain ، ولكن يمكن استخدامها لتوسيع L2 ، ويرجع ذلك أساسًا إلى أن ZKP الجيد له الخصائص المفيدة التالية:
باستخدام هذه الميزات ، يمكن أن يقوم حل Rollup الخاص بنا بما يلي:
بالطبع ، أي آلية أمنية سيكون لها متطلبات مسبقة محتملة ، و ZKP ليس حلاً سحريًا لـ blockchain. لا يزال ZKP يعاني من العديد من القيود في الوقت الحالي ، والتي يجب التغلب عليها خطوة بخطوة ، مثل:
! [تستكشف هذه المقالة أفكار التطور وأسباب تصميم حل توسيع Rollup] (https://img.gateio.im/social/moments-7f230462a9-7183a49f36-dd1a6f-e5a980)
مصدر:
لهذا السبب ، في ZK-Rollup ، وهو مجال توسع موجه نحو المستقبل ، كل تقدم يستحق الثناء ومرضٍ.
! [تستكشف هذه المقالة أفكار التطور وأسباب التصميم لحل توسعة Rollup] (https://img.gateio.im/social/moments-7f230462a9-0a59b6b5b2-dd1a6f-e5a980)
مصدر:
اكتب في النهاية
بقدر ما يتعلق الأمر بمستقبل توسيع السعة ، يعتقد المؤلف أنه بالمقارنة مع توسيع السعة الأصلية لـ L1 ، فإن التصميم متعدد الطبقات بما في ذلك Rollup هو فكرة أكثر موثوقية. Modularization ، تحل كل طبقة مخاوف كل طبقة ، والتي تكون أقل خطورة من التكديس المستمر على L1 "المتجانسة" بالفعل ؛ علاوة على ذلك ، من غير المحتمل نظريًا أن تكون اللامركزية للطبقة L1 الأساسية بسبب توسيع السعة هي الطبقة العليا تجدها وتجعلها عليه. علاوة على ذلك ، يبدو أن فكرة التصميم متعدد الطبقات هذه لها تطبيقات ناجحة في مجالات أخرى غير blockchain. وجهة النظر ليست صحيحة بالضرورة ، ولكن هذا هو الإدراك الحالي للمؤلف.
تحاول هذه المقالة فرز أسباب التفكير والتصميم الخاصة بحل توسيع التراكمية بنبرة حيادية للمشروع. نظرًا للمستوى المحدود ، لا تزال بعض الأماكن غير حادة بعض الشيء ، الأمر الذي قد لا يفسر الأمر في مكانه فحسب ، بل يزيد أيضًا من صعوبة الفهم ؛ كحقل عمودي يتغير مع مرور كل يوم ، قد لا يكون المؤلف على دراية وتأخذ في الاعتبار العديد من التطورات الجديدة في الوقت المناسب. بصدق نرحب بالأصدقاء للتصحيح والتواصل.