مقدمة:

يعج مشهد Bitcoin Layer2 الحالي بالحلول التكنولوجية المتنوعة التي تتلاقى في بوتقة انصهار النظام البيئي BTC. نظرا للوتيرة السريعة للتكرار في مجال blockchain ، حيث تتطور المفردات والمعايير المهنية باستمرار من خلال البحث والابتكار والتنفيذ الهندسي ، تلجأ العديد من المشاريع إلى "إنشاء المفاهيم" أو "نقل المفاهيم" للتمايز والاهتمام ، لتصبح قاعدة غير معلنة داخل الصناعة. على سبيل المثال ، قفزت العديد من مشاريع blockchain المعيارية النشطة في البداية داخل النظام البيئي Ethereum / Celestia إلى عربة "Bitcoin Layer2" ، وأطلقت على نفسها اسم "Rollups" ، على الرغم من أن حلولها التقنية غالبا لا تفي بمعايير Rollup. ومع ذلك ، فإن مصطلح "Rollup" يحمل اعترافا كبيرا ، مما يجعله مفيدا للأغراض الترويجية. يقوم العديد من مشغلي المشاريع إما بتسمية أنفسهم بقوة على أنهم Rollups أو يتفرعون عن مفهوم Rollup السائد بمؤهلات غامضة ، مثل "Sovereign Rollup". من خلال تقشير طبقات "XX Rollups" هذه ، تعتمد العديد من المشاريع بشكل أساسي على "التحقق من جانب العميل" أو "السلاسل الجانبية" ، فقط باستخدام شعار "XX Rollup" للراحة. على الرغم من أن هذه الاستراتيجية الترويجية شائعة ، إلا أنها تميل إلى أن تكون مضللة ، مما يتسبب في ضرر أكثر مما ينفع لأولئك الذين يبحثون عن الحقيقة.

(هذا النهج، الملخص من قبل وزير الدعاية النازي جوبلز باسم "الدعاية المبنية على الكذب"، يُلاحَظ بشكل متكرر بين مشغلي المشاريع.) كيف يمكننا بعد ذلك التمييز عن هذا السلوك "ركوب مفهوم Rollup"؟ ربما، بدءًا من المبادئ الأولى، تحديد فئات مشاريع Layer2 المختلفة ومستويات أمانها ووظائفها بناءً على المعايير المعتمدة على نطاق واسع في الغرب وعبر الصناعة، يمكن أن يقدم وضوحًا. لا يتعلق الأمر بالضرورة بالحل الذي تم اختياره؛ النواة تكمن في ما إذا كان تصميم آلية المشروع يضمن أمان وموثوقية شبكة Layer2 ويمنح بالفعل قوة لشبكة BTC الرئيسية.

ستستخدم هذه المقالة Chainway ، وهو مشروع Bitcoin Layer2 ، كدراسة حالة لتشريح طبيعة "التحقق من جانب العميل" المخبأة وراء شعارات "Rollup" لبعض المشاريع. نهدف إلى التمييز بوضوح بين "Sovereign Rollup" و "التحقق من جانب العميل" ، والاختلافات الكبيرة عن ZKRollups أو OPRollups المتوافقة مع معايير الصناعة والتي تعتمد على العقود الذكية. هذا لا يعني أن التراكمات السيادية أو عمليات التحقق من جانب العميل أدنى من ZK Rollups في الأمان والموثوقية. كل هذا يتوقف على تفاصيل التنفيذ المحددة. اقترحت Chainway ، التي عادة ما تكون عملية تحقق من جانب العميل Layer2 ، مخطط معاملات لمكافحة الرقابة يتم تشغيله على BTC مع التحقق من الصحة خارج السلسلة ، باستخدام أدلة ZK المتكررة المشابهة لتلك المستخدمة من قبل السلسلة العامة MINA ، مما يجعلها متقدمة على العديد من مشاريع Bitcoin Layer2. نعتقد أن البحث في تقنية Chainway أمر قيم ، حيث يقدم رؤى مهمة لمراقبي Bitcoin Layer2. (الصور الترويجية ل Chainway تصنفها على أنها ZK Rollup ، لكن حلها القديم كان التحقق من جانب العميل ، مع كون ZKR مشروعا آخر لهم. حاليا ، لم يحقق إجماع العميل خارج السلسلة أو تبادل الرسائل الموثوق.)

النص الرئيسي: Chainway هو مشروع Bitcoin Layer2 معروف في المجتمع الغربي ، وغالبا ما يشار إليه باسم "ZK Rollup" من قبل العديد من KOLs ، في حين أن وثائقه الفنية تضعه على أنه "Sovereign Rollup". في الآونة الأخيرة ، أعلنت Chainway أيضا عن مشروعها الجديد ، Citrea ، مدعيا أنه ZK Rollup استنادا إلى BitVM. ومع ذلك ، نظرا لأن Citrea لم تفصل بعد حل التحقق من ZK الخاص بها استنادا إلى BitVM ، فستركز هذه المقالة على التفسير الفني لحلول Chainway السابقة. باختصار ، يتضمن الحل التقني الذي تم الكشف عنه علنا من Chainway نشر بيانات DA من خلال بروتوكول Ordinals ، واستخدام BTC كطبقة DA الخاصة بها ، ونشر تفاصيل تغيير الحالة (فرق الحالة) + ZK Proof للتحقق من صحة تغييرات الحالة على Layer1 ، أي ما يعادل نشر بيانات معاملات كاملة يمكن التحقق منها. ومع ذلك ، نظرا لأن Layer1 لا تتحقق مباشرة من ZK Proofs ، مع التحقق الذي يتم إجراؤه بواسطة عملاء / عقد مستقلة خارج السلسلة ، ولم تحقق قاعدة التعليمات البرمجية الحالية ل Chainway إجماعا بين العملاء خارج السلسلة ، ولم تدعي حل هذه المشكلة على وسائل التواصل الاجتماعي ، ينتمي الحل التقني الذي تم الكشف عنه علنا من Chainway بشكل أساسي إلى فئة "التحقق من جانب العميل" ، حتى أنه يشبه بروتوكولا مفهرسا مشفرا يدعم سد الأصول. ستقدم الأقسام التالية التنفيذ الفني المحدد ل Chainway وتحلل نموذجها الأمني.

ما هو اللف السيادي: نشر طبقة توفر البيانات (DA) + التحقق خارج السلسلة

في الوثائق الفنية لـ Chainway، يُستخدم مفهوم الـ Sovereign Rollup من Celestia. الـ Sovereign Rollup مختلف تمامًا عن مفهوم الـ Rollup الرئيسي داخل مجتمع Ethereum والصناعة الأوسع (Rollup العقد الذكي). إذًا، ما هي بالضبط هيكلة الـ Sovereign Rollup؟

في جوهرها ، فإن مجموعة التحديثات السيادية القائمة على Bitcoin تشبه إلى حد ما "مجموعة عملاء خارج السلسلة / سلسلة جانبية تنشر بيانات DA على BTC blockchain". السمة الرئيسية لها هي أنها لا تتطلب عقودا ذكية على الطبقة 1 للتحقق من انتقالات الحالة / الإجراءات عبر السلسلة للطبقة 2. بشكل أساسي ، يستخدم BTC كطبقة DA ، ونموذج الأمان الخاص به يشبه إلى حد كبير "التحقق من جانب العميل". بالطبع ، تعتمد بعض حلول Sovereign Rollup الأكثر أمانا على طبقة تسوية تابعة لجهة خارجية خارج سلسلة Bitcoin (على غرار السلسلة الجانبية) لإجراء عمليات التحقق من انتقال الحالة. بالإضافة إلى ذلك ، بين مختلف العملاء المستقلين / العقد الكاملة ، يوجد مستوى من الإجماع أو رسالة موثوقة تمر للتوصل إلى "اتفاق" بشأن بعض الإجراءات المثيرة للجدل. ومع ذلك ، فإن بعض مشاريع Sovereign Rollup تعتمد فقط على "التحقق من جانب العميل" ، وتفتقر إلى أي رسالة موثوقة تمر بين العملاء / العقد المستقلة.

لفهم مفهوم "Sovereign Rollup" الفريد بشكل أفضل، من المفيد مقارنته مع نظيره، Rollup العقد الذكي. على Ethereum، تعتمد حلول الطبقة 2 بشكل أساسي على Rollups العقد الذكي، مثل Arbitrum و StarkNet. يمكن تصور هيكل Rollup العقد الذكي في الرسم البياني التالي:

(تخيل رسم بياني هنا)

في الرسم البياني، يمكننا رؤية العديد من المصطلحات المتعلقة بالسرد اللامركزي للبلوكشين، والتي يتم شرحها على النحو التالي:

• طبقة التنفيذ: ينفذ معاملات المستخدمين، ويحدث حالة البلوكشين، ويقدم البيانات إلى طبقة DA وطبقة التسوية.

• طبقة التسوية: يتحقق من تحولات الحالة من طبقة التنفيذ، ويحل النزاعات (مثل دلائل الاحتيال)، ويوفر وحدة جسر للتعامل مع الأصول الجسرية بين L1 و L2.

• طبقة توفر البيانات (DA): يعمل كلوحة إعلانات كبيرة، يستقبل بيانات انتقال الحالة المقدمة من طبقة التنفيذ ويوفر هذه البيانات بطريقة غير قابلة للثقة لأي شخص.

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

تتلقى عقود Rollup على Ethereum إما دلائل صحة أو دلائل احتيال للتحقق من صحة تحولات حالة الطبقة 2. يجدر بالذكر أن عقود Rollup الذكية تعمل ككيانات طبقة التسوية في الهندسة المعمارية للبلوكشين النموذجية. تتضمن عقود طبقة التسوية في كثير من الأحيان وحدات توجيه للتعامل مع الأصول الموجهة من Ethereum إلى الطبقة 2. بالنسبة لتوفير البيانات (DA) ، يمكن لعقود طبقة التسوية أن تفرض على السيكونسر نشر أحدث بيانات المعاملة / تفاصيل تغيير الحالة على السلسلة. بدون نشر DA على السلسلة ، من غير الممكن تحديث حالة L2 المسجلة في عقود Rollup بنجاح.

(يمكن ل ZK Rollup أو Optimistic Rollup فرض بيانات DA ليتم نشرها على السلسلة ؛ بدونها ، لا يمكن تحديث الحالة المسجلة في طبقة التسوية.) من تحليل نموذج الأمان ومؤشرات المخاطر لحلول Bitcoin / Ethereum Layer 2 مع نظرية البرميل ، من الواضح أن مجموعات العقود الذكية تعتمد بشكل كبير على العقود الذكية من الطبقة 1. بالنسبة للطبقة 1 مثل BTC ، التي تكافح لدعم منطق الأعمال المعقدة ، فإن إنشاء طبقة 2 تتوافق مع Ethereum Rollups أمر مستحيل بشكل أساسي. من ناحية أخرى ، لا تتطلب حلول Sovereign Rollup عقودا على الطبقة 1 للتحقق من الحالة / التجسير. هندستها المعمارية هي كما يلي: (هنا ، وصف البنية مفقود ، مما يعني أنه كان من المفترض تضمين رسم توضيحي أو مزيد من التفاصيل ولكن لم يتم توفيرها في النص.)

في Rollups السيادية، تعمل العقد خارج طبقة توافر البيانات (DA) ككيانات لتنفيذ المعاملات وعمليات تسوية، مما يوفر درجة أعلى من الحرية. سير العمل هو كما يلي:

ترسل العقد في طبقة التنفيذ الخاصة بالتجميع السيادي بيانات المعاملة / تفاصيل تغيير الحالة إلى طبقة DA ، بينما تسعى طبقة التسوية / العملاء للحصول على البيانات والتحقق منها. من المهم ملاحظة أنه نظرا لأن وحدة طبقة التسوية غير موجودة على الطبقة 1 ، فإن التراكمات السيادية ، من الناحية النظرية ، لا يمكنها تحقيق جسور بأمان مكافئ للطبقة 1. غالبا ما يعتمدون على جسور كاتب العدل أو حلول التجسير من طرف ثالث. في الوقت الحالي ، يعد تنفيذ مخططات التحقق السيادية / العميل أمرا بسيطا نسبيا ، ولا يتطلب سوى نشر البيانات على سلسلة Bitcoin (BTC) باستخدام بروتوكول مشابه ل Ordinals. أما بالنسبة للتحقق خارج السلسلة وتوافق الآراء ، فهناك قدر كبير من المرونة. في الواقع ، تقوم العديد من السلاسل الجانبية ببساطة بنشر بيانات DA على سلسلة BTC ، لتصبح بشكل أساسي "مجموعات سيادية قائمة على BTC" ، على الرغم من أن الأمان المحدد مشكوك فيه. ومع ذلك ، فإن المشكلة تكمن في أن معدل نقل بيانات Bitcoin منخفض للغاية ، بحد أقصى 4 ميجابايت لكل كتلة ومتوسط وقت كتلة يبلغ 10 دقائق ، مما يترجم إلى معدل نقل بيانات يبلغ 6 كيلوبايت / ثانية فقط. قد لا تتمكن حلول الطبقة 2 التي تدعي أنها ذات سيادة من نشر جميع بيانات DA على سلسلة BTC ، وبالتالي قد تختار طرقا بديلة ، مثل نشر بيانات DA خارج السلسلة وتخزين datahash على سلسلة BTC كشكل من أشكال "الالتزام" ، أو إيجاد طريقة لضغط بيانات DA بشكل كبير (على سبيل المثال ، باستخدام فرق الدولة + إثبات ZK كما ادعى Chainway). من الواضح أن هذا الوضع لا يتوافق مع تعريف "التجميع السيادي" أو مجموعة التحديثات المناسبة ، والتي تمثل متغيرا مشكوك في أمانه. نتوقع أن معظم مشاريع الطبقة 2 التي تحمل شعار "Rollup" لن تنشر في النهاية جميع بيانات DA على سلسلة BTC ، لذلك من المحتمل ألا تتطابق حلولها العملية مع مطالبات "ZK Rollup" أو "OP Rollup" الواردة في أوراقها البيضاء.

أخيرًا، دعونا نلخص بإيجاز الفروقات بين الـ Rollups السيادية والـ Rollups الذكية:

1. القابلية للتطوير:تشمل التحديثات الدورية للعقود الذكية Rollups تحديث العقود الذكية، مما يتطلب من فريق التطوير استخدام عقود قابلة للترقية. هذا النوع من سلطة ترقية العقد الذكي عادة ما يتم التحكم فيه بواسطة فريق تطوير Rollup من خلال التوقيع المتعدد. على النقيض، فإن قواعد الترقية لـ sovereign Rollups مشابهة لشوكات البلوكشين الناعمة والصعبة التقليدية، حيث يمكن للعقد تحديث الإصدارات بشكل مستقل، ويمكن للعملاء المختلفين اختيار ما إذا كانوا سيقبلون الترقية. من هذه الناحية، تعتبر sovereign Rollups أفضل من Rollups العقود الذكية من حيث القابلية للترقية.

2. الجسور:في الظروف المثالية، تتماشى الجسور للتكديس الذكي للعقود مع الثقة الدنيا، ولكن يمكن أن تؤثر قابلية تحديث العقود على أمانها. في إطار نظام التكديس السيادي، يحتاج المطورون إلى بناء مكونات الجسور تحت سلسلة الطبقة 1 بأنفسهم، ومن المحتمل أن تكون الجسور المبنية تثق فيها أقل من جسور العقود الذكية.

هيكل DA لـ BTC

في النص أعلاه، ذكرنا أن تنفيذ Rollup ذو سيادة معتمد على BTC، يكمن الأساس في استخدام بروتوكول Ordinals لجعل BTC يعمل كطبقة توافر البيانات (DA). قامت Chainway باعتماد هذا الحل.

يمكننا فحص تقديم بيانات DA من جهاز التسلسل Chainway، مع هاش الصفقة يكون:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000، كما هو موضح فيما يلي:

يستعير هذا البرنامج النصي للمعاملات من نهج بروتوكول Ordinals في استخدام OP_0 OP_IF لكتابة البيانات لكتابة بيانات Rollup's DA (Data Availability) على سلسلة BTC. يشتمل ذلك على نشر تغييرات الحالة و ZK Proofs، وهو ما يعادل من الناحية الأمنية نشر بيانات المعاملة الأصلية ولكنه يسمح بتقليل حجم البيانات بشكل كبير. بالإضافة إلى بيانات DA، يقوم المتسلسل أيضًا بكتابة بعض البيانات للمصادقة في المعاملة، مع الأكثر أهمية يكون توقيع متسلسل Rollup على بيانات DA بمفتاحه الخاص لضمان أن يأتي الإرسال من المتسلسل. من المهم أن نلاحظ أن أي معاملة تشمل إرسال بيانات DA تحتوي على 16 صفرًا ثنائيًا في نهاية تجزئة المعاملة (أي، يتم ضبط بايتين متتاليين على الصفر). يمكن رؤية هذا القيد في الكود:

في مثال الرسم البياني للمعاملة المذكور سابقا ، يتم استخدام الرقم العشوائي "b715" لضبط قيمة التجزئة للمعاملة بحيث يحمل ذيلها 16 صفرا محددا. يشبه هذا المبدأ تعدين البيتكوين ، حيث تتم إضافة رقم عشوائي nonce لجعل N بت الرائدة في التجزئة جميع الأصفار ، وتفي بشروط قيد محددة. يهدف هذا التصميم إلى تبسيط صعوبة الحصول على بيانات DA (توافر البيانات). عندما تريد أي عقدة Layer2 الوصول إلى بيانات DA ، فإنها تحتاج فقط إلى مسح كتلة BTC (Bitcoin) لجميع المعاملات التي تم تعيينها لتنتهي ب 16 صفرا ، مما يميز بشكل فعال المعاملات التي بدأها فارز Chainway عند إرسال البيانات من المعاملات الأخرى على blockchain Bitcoin. في النص التالي ، يشار إلى هذه المعاملات التي تحتوي على بيانات DA وتفي بشرط الانتهاء ب 16 صفرا باسم "المعاملات القياسية Chainway". ينصب تركيز هذه المقالة على كيفية تحقيق Chainway لمقاومة الرقابة. نظرا لأن فارز Layer2 قد يرفض عمدا طلب معاملة من مستخدم معين ، يجب استخدام مخطط خاص للسماح للمستخدمين ببدء المعاملات التي تقاوم الرقابة. استجابة لهذه المشكلة ، يسمح Chainway للمستخدمين بإطلاق "المعاملات القسرية". بمجرد أن يرسل المستخدم إعلان المعاملة هذا داخل كتلة BTC ، يجب على فارز Chainway معالجة طلب المعاملة هذا على Layer2 ؛ خلاف ذلك ، لن تكون قادرة على إنتاج كتلة بشكل طبيعي ، أو لن يتم التعرف على الكتلة المنتجة من قبل العملاء خارج السلسلة. هيكل المعلمة للمعاملة القسرية هو كما يلي:

سيتم تقديم هذه المعاملة إلى Bitcoin blockchain ك "معاملة مواصفات Chainway" ، مع انتهاء تجزئة المعاملة ب 16 صفرا. يجب أن يتضمن فارز ChainWay ، عند إنشاء كتل L2 ، "معاملات مواصفات Layer2" التي تم الكشف عنها على blockchain BTC ولكن لم يتم تسجيلها بعد في دفتر الأستاذ L2 ، وتجميعها في شجرة Merkle ، وكتابة جذر Merkle في رأس كتلة L2. بمجرد أن يبدأ المستخدم معاملة قوية مباشرة على blockchain BTC ، يجب على الفارز معالجتها ؛ خلاف ذلك ، لا يمكن إنشاء الكتلة الصالحة التالية. يمكن لعميل Chainway خارج سلسلة BTC أولا التحقق من إثبات ZK لتحديد صحة كتلة L2 المقدمة من الفارز ، والتحقق من جذر Merkle لرأس كتلة L2 ، والحكم على ما إذا كان الفارز قد أدرج بصدق طلب المعاملة القوي. يمكن إحالة سير العمل إلى المخطط الانسيابي التالي. لاحظ أنه نظرا لقيود المساحة ، فإن الرسم البياني أدناه يفتقد إلى حكم شرط في verify_relevant_tx_list:

باختصار ، يتزامن عميل / عقدة Chainway مع كتل الشبكة الرئيسية BTC ويفحص "بيانات DA" التي ينشرها فارز Chainway منها. يتحقق من أن هذه البيانات يتم نشرها بواسطة الفارز المعين وتحتوي بالفعل على جميع "معاملات Chainway القياسية" المقدمة إلى سلسلة BTC. من الواضح أنه طالما يمكن للمستخدمين إنشاء معاملة تفي بالمعايير المحددة ك "معاملة قياسية" وإرسالها إلى سلسلة BTC ، تضمين هذه المعاملة في النهاية في دفتر الأستاذ المحلي L2 لعميل Chainway. خلاف ذلك ، سيتم رفض كتلة L2 التي تم إصدارها بواسطة فارز Chainway من قبل العميل. إذا تم دمجه مع إجماع موثوق به خارج السلسلة / نقل رسائل تنبيه ، فإن مخطط معاملات مكافحة الرقابة في Chainway يقترب من الطريقة المثالية لمكافحة الرقابة في Rollups السيادية. على سبيل المثال ، ذكرت بعض حلول Rollup السيادية صراحة أنه في حالة وجود حظر غير صالح ، سيتم بث رسائل تحذير التنبيه بين العملاء خارج السلسلة لتعزيز الأمان ، خاصة السماح للعملاء الخفيفين الذين لا يمكنهم مزامنة بيانات DA الكاملة بمعرفة الحالات الشاذة في الشبكة. إذا كانت الكتلة لا تتضمن بصدق "المعاملات الإلزامية" ، فمن الواضح أنها ستؤدي إلى بث تنبيه خارج السلسلة. ومع ذلك ، لم تنفذ Chainway هذا الجانب بعد (على الأقل تظهر المواد المنشورة حاليا ومستودعات الشفرات أنها لم تتعهد بالتنفيذ الفني لهذا الجزء).

المواد المرجعية: يقوم باحثو Celestia بتحليل 6 أنواع من متغيرات Rollup: Sequencer = Aggregator + Header Generator. حتى مع الإجماع الذي تم التوصل إليه بين العملاء / العقد خارج السلسلة ، فإن فعالية مكافحة الرقابة ل "المعاملات القسرية" في Chainway ليست قوية مثل تلك الخاصة بالعقود الذكية مثل Arbitrum ، لأن Arbitrum One سيضمن في النهاية تضمين "المعاملات القسرية" في دفتر الأستاذ Layer2 من خلال العقود على Layer1 ، وترث بالكامل خصائص مكافحة الرقابة في Layer1. من الواضح أن التراكمات السيادية لا يمكن أن تتطابق مع مجموعات العقود الذكية في هذا الجانب ، حيث تعتمد فعاليتها في مكافحة الرقابة في النهاية على المكونات خارج السلسلة. يحدد هذا أيضا أن نهج "التراكمات السيادية" ومخططات "التحقق من العميل" لا يمكن أن يرث بشكل أساسي خصائص مكافحة الرقابة في Layer1 بالكامل ، مثل Arbitrum One و Loopring و dydx و Degate ، لأن ما إذا كان يمكن تضمين المعاملات القسرية بسلاسة في دفتر الأستاذ Layer2 يعتمد على قرارات كيانات Layer2 خارج السلسلة ، لا علاقة لها ب Layer1 نفسها. من الواضح أن نهج Chainway ، الذي يعتمد فقط على تقدير العملاء خارج السلسلة ، يرث فقط موثوقية DA ل Layer1 ، وليس خصائصه الكاملة لمكافحة الرقابة. على غرار براهين ZK العودية ل MINA.

في هذا القسم، سنقدم مزيدًا من مكونات Chainway الأخرى، التي، بالإضافة إلى استخدام BTC كطبقة DA، نفذت أيضًا دلائل ZK التكرارية مشابهة ل MINA. يتم توضيح هيكلها العام في الرسم البياني التالي:

يقوم الفارز في شبكة Chainway ، بعد معالجة معاملات المستخدم ، بإنشاء دليل ZK (صفر المعرفة) النهائي جنبا إلى جنب مع تفاصيل تغييرات الحالة (فرق الحالة) لحسابات مختلفة وينشرها على blockchain Bitcoin (BTC). ستقوم العقد الكاملة بمزامنة جميع البيانات التاريخية ل Chainway المنشورة على blockchain BTC. لا يتعين على كل دليل ZK إثبات عملية انتقال الحالة للكتلة الحالية فحسب ، بل يجب أيضا ضمان صحة إثبات ZK للكتلة السابقة. بناء على هذا المخطط ، يمكننا أن نرى أنه في كل مرة يتم فيها إنشاء دليل جديد ، فإنه يؤكد بشكل أساسي الدليل السابق بطريقة متكررة ، ويمكن أن يضمن أحدث دليل ZK صحة جميع براهين ZK بدءا من كتلة التكوين. هذا التصميم مشابه لتصميم مينا. عندما ينضم "عميل خفيف" يقوم فقط بمزامنة رؤوس الكتلة ، والمعروف أيضا باسم العقدة الخفيفة ، إلى الشبكة ، فإنه يحتاج فقط إلى التحقق من صحة أحدث دليل ZK تم الكشف عنه على BTC blockchain لتأكيد أن البيانات التاريخية للسلسلة بأكملها وجميع انتقالات الحالة صالحة. إذا كان الفارز يتصرف بشكل ضار ، أو يرفض عمدا قبول المعاملات الإلزامية أو يفشل في استخدام دليل ZK السابق للإثبات المتكرر ، فلا يمكن للعميل قبول دليل ZK الذي تم إنشاؤه حديثا (حتى لو تم إنشاؤه ، فلن يتم التعرف عليه) ، كما هو موضح في الرسم البياني أدناه:

ملخص

كما تم تلخيصه في بداية هذه المقالة، يعد Chainway في الأساس نظام تحقق سيادي Rollup/client يستخدم BTC كطبقة توافر البيانات (DA) الخاصة به. ولتعزيز مقاومة الرقابة على Rollup، يقدم Chainway مفهوم المعاملات الإجبارية. من ناحية أخرى، يستخدم Chainway تقنية recursive ZK-proof، مما يتيح للعقد الجديدة الثقة بإخراج المُتسلسل أكثر والتحقق من دقة بيانات سلسلة البلوك بأكملها في أي وقت. المشكلة الحالية مع Chainway تكمن في آلية الثقة لجسره العابر للسلاسل. نظرًا لأنه يعتمد على نهج تحقق سيادي Rollup دون تفاصيل حول كيفية خططه لعناصر تقنية محددة في حل جسره العابر للسلاسل، فمن الصعب تقييم أمانه النهائي.

اليوم، من خلال الغوص في الحل الفني لـ Chainway، اكتشفنا أن نوع التكنولوجيا التي يروج لها مجتمع المشروع ليس Rollup بالمعنى الرئيسي. نظرًا لوجود العديد من مشاريع Bitcoin Layer2 بالفعل (التي يمكن أن تصل إلى المئات في نصف عام)، لتقليل التكلفة المعرفية لمصطلحات التقنية، سنواصل إجراء بحوث عميقة حول تصنيف حلول Layer2 ومعايير الأمان واكتمال الوظائف والتقييم. ترقبوا التحديثات!

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

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