التفسير الفني لـ Chainway: كيف ظهر مشروع Bitcoin Layer 2

المؤلف: Shew & Faust، مهووس web3، المستشار: Kevin He، مؤسس مجتمع BitVM الصيني، رئيس Web3 Tech @Huobi سابقًا

يمكن القول أن مسار Bitcoin Layer 2 الحالي في حالة ازدهار كامل، مع مجموعة متنوعة من الحلول التقنية المجمعة في بوتقة الانصهار في نظام BTC البيئي. نظرًا لسرعة التكرار السريعة في مجال blockchain، تتغير المفردات أو المعايير المهنية باستمرار في عملية البحث والابتكار والتنفيذ الهندسي. وفي هذا السياق، ستتبنى العديد من المشاريع أسلوب "إنشاء المفاهيم"/"إنشاء المفاهيم" لكسب التمايز والاهتمام، والذي أصبح قاعدة غير معلنة في الصناعة.

على سبيل المثال، استفادت العديد من مشاريع blockchain المعيارية التي كانت نشطة في الأصل في النظام البيئي Ethereum/Celestia من الرياح الشرقية للحاق بالقطار السريع "Bitcoin Layer 2" وأطلقوا على أنفسهم اسم "Rollup"، ولكن غالبًا ما لا تفي حلولها التقنية بمعايير Rollup.

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

ولكن إذا قمت بإزالة غلاف "XX Rollup"، يمكنك أن ترى أن مبدأ العمل للعديد من المشاريع لا يزال بسيطًا "التحقق من العميل" أو "السلسلة الجانبية"، ويعتمد فقط على الترويج لـ " XX Rollup" الشعار مخصص لراحتك. وعلى الرغم من أن طريقة الدعاية هذه شائعة نسبيًا، إلا أنها غالبًا ما تكون مضللة وتضر الجماهير التي تسعى إلى الحقيقة أكثر من نفعها.

(ملخص وزير الدعاية النازي غوبلز عن "الدعاية الكاذبة"، هذه الممارسة شائعة بين العديد من أطراف المشروع)

كيف يجب أن نحدد هذا وماذا عن السلوك المشابه لـ "مفهوم التراكمي"؟

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

بعد ذلك، نخطط لاستخدام Chainway، وهو أجنبي، للقيام بذلك، يتم استخدام Bitcoin Layer 2 كحالة لتحليل جوهر "التحقق من العميل" المخفي خلف شعار "Rollup" لبعض المشاريع. يمكننا أن نرى بوضوح أكبر الاختلافات الواضحة بين "التراكم السيادي" و"التحقق من العميل" وZK Rollup السائد في الصناعة، أو OP Rollup وحلول التجميع الأخرى التي تعتمد على تنفيذ العقود الذكية.

بالطبع، هذا لا يعني أن مجموعة التحديثات السيادية أو التحقق من جانب العميل ليست آمنة وموثوقة مثل مجموعة ZK Rollup. كل شيء يعتمد على تفاصيل التنفيذ المحددة الخاصة بها. على الرغم من أن Chainway عبارة عن طبقة 2 نموذجية تم التحقق منها من قبل العميل، إلا أنها تقترح مخطط معاملات مضاد للرقابة "يتم تشغيله في BTC + التحقق خارج السلسلة" وتتبنى ZK Proof المتكرر المشابه لسلسلة MINA العامة، والتي تتفوق على معظم طبقات Bitcoin 2 ثانية . .

نعتقد أن البحث الفني حول Chainway ذو قيمة كبيرة وله أهمية مرجعية مهمة بالنسبة لغالبية مراقبي Bitcoin Layer 2.

(الصورة الترويجية لـ Chainway تصف نفسها بأنها ZK Rollup، لكن حلها الحقيقي هو التحقق من العميل. في الوقت الحاضر، لم تحقق بعد إجماعًا بين العملاء خارج السلسلة أو تبادلًا موثوقًا للرسائل)

النص: يعد Chainway أحد مشاريع Bitcoin Layer 2 المعروفة في المجتمع الغربي. ويطلق عليه العديد من KOLs مباشرةً اسم "ZK Rollup" عند الترويج له، و< strong>في وثائقه الفنية ، تضع Chainway نفسها على أنها "مجموعة تراكمية سيادية". كما أعلنت Chainway مؤخرًا عن مشروعها الجديد Citrea، والذي يدعي أنه ZK Rollup استنادًا إلى BitVM. نظرًا لأن Citrea لم تشرح بعد بالتفصيل كيفية تنفيذ حل التحقق ZK القائم على BitVM،سوف تركز هذه المقالة على التفسير الفني لحل Chainway الحالي.

يمكننا تلخيصالحل التقني العام الآن لشركة Chainway في جملة واحدة: نشر بيانات DA من خلال بروتوكول Ordinals، باستخدام BTC كطبقة DA الخاصة بها،< /strong>نشر تفاصيل تغيير الحالة State diff + ZK Proof لإثبات صحة تغييرات الحالة في Layer1. التأثير يعادل نشر بيانات المعاملات الكاملة والقابلة للتحقق.

(State diff هو التغيير في حالة الحساب)

ومع ذلك، نظرًا لأن Layer1 لا تتحقق مباشرة من ZK Proof، فإن عمل التحقق هو تم إجراؤها بواسطة عملاء/عقد مستقلة خارج السلسلة، ولا تحقق قاعدة التعليمات البرمجية الحالية لـ Chainway إجماعًا بين العملاء المستقلين خارج السلسلة، ولم يزعم المسؤول أنه حل هذه المشكلة على وسائل التواصل الاجتماعي. لذا، فإن الحل الفني الذي أعلنته Chainway حاليًا هو في الأساس من نوع "التحقق من جانب العميل"، وهو أشبه ببروتوكول فهرس النقش الذي يدعم سد الأصول.

سيقدم ما يلي بشكل أساسي التنفيذ الفني المحدد لـ Chainway وتحليل نموذج الأمان الخاص به.

ما هو التراكم السيادي: تُصدر طبقة DA البيانات + التحقق خارج السلسلة

في التوثيق الفني لـ Chainway، يتم استخدام مفهوم التراكم السيادي لـ Celestia (التراكم السيادي) . و يختلف التراكم السيادي في الواقع كثيرًا عن مفهوم التراكم السائد (العقد الذكي التراكمي) في مجتمع إيثريوم وحتى الصناعة. إذًا ما هو الهيكل المحدد للتراكم السيادي؟

في الواقع، تشبه مجموعة Sovereign Rollup المستندة إلى Bitcoin إلى حد ما - "مجموعة/سلسلة جانبية من العملاء خارج السلسلة تنشر بيانات DA على سلسلة BTC". أكبر ميزة لها هو أنه ليست هناك حاجة لعقود ذكية على الطبقة الأولى للتحقق من سلوك انتقال الحالة/السلسلة المتقاطعة للطبقة الثانية. بشكل أساسي، فهي تستخدم فقط BTC كطبقة DA، ونموذج الأمان قريب جدًا من "التحقق من جانب العميل" ".

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

من أجل فهم "مجموعة السيادة" بشكل أفضل باستخدام هذا المفهوم الفريد،يمكننا مقارنة مجموعات السيادة السيادية مع مجموعات العقود الذكية المقابلة لها. الطبقة الثانية على Ethereum هي في الأساس عبارة عن مجموعة عقود ذكية، مثل Arbitrum وStarkNet. يمكن أن يشير هيكل مجموعة العقود الذكية إلى الشكل التالي:

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

طبقة تنفيذ التنفيذ: تنفيذ معاملات المستخدم، وتحديث حالة blockchain، والإبلاغ إلى طبقة DA والتسوية بيانات إرسال الطبقة

طبقة تسوية التسوية: التحقق من انتقالات الحالة لطبقة التنفيذ، وحل النزاعات (مثل إثبات الاحتيال)، وتوفير وحدات الجسر للتعامل مع أصول جسر L1-L2< /p>

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

إجماع الإجماع الطبقة: يبدو أن ضمان نهائية طلب المعاملات قريب نسبيًا من وظائف طبقة DA (لا يتضمن النهج متعدد الطبقات الذي يتبعه مجتمع Ethereum تجاه سلاسل الكتل المعيارية طبقة الإجماع)

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

سيتلقى العقد المجمع على Ethereum إثبات صلاحية (إثبات صحة) أو إثبات احتيال (إثبات الاحتيال) للتحقق من صحة انتقال حالة Layer2. من الجدير بالذكر أن العقد الذكي المجمع هنا هو في الواقع كيان طبقة التسوية في blockchain المعياري. غالبًا ما يحتوي عقد طبقة التسوية على وحدة تجسير، تُستخدم للتعامل مع الأصول التي تم ربطها من Ethereum إلى الطبقة الثانية.

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

(يمكن لـ ZK Rollup أو OP Rollup فرض تحميل بيانات DA إلى السلسلة. وبدونها، لا يمكن تحديث حالة سجل طبقة التسوية)

يمكن ملاحظة أن تعتمد مجموعة العقود الذكية بشكل كبير على العقد الذكي الموجود على الطبقة 1. بالنسبة للطبقة 1 مثل BTC، والتي يصعب دعم منطق الأعمال المعقد، فمن المستحيل في الأساس إنشاء طبقة 2 الذي "يتماشى" مع Ethereum Rollup.

لا يتطلب حل Sovereign Rollup التعاقد على Layer1 لإجراء التحقق من الحالة/معالجة التجسير. الهيكل كما هو موضح أدناه:

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

طبقة تنفيذ السيادة عقد التجميع، ترسل بيانات المعاملة/تفاصيل تغيير الحالة إلى طبقة DA، بينما تتمكن طبقة التسوية/العميل من الحصول على البيانات وتنفيذ أعمال التحقق. تجدر الإشارة إلى أنه نظرًا لأن وحدة طبقة التسوية غير موجودة في الطبقة الأولى، فإن التراكم السيادي لا يمكنه نظريًا تنفيذ جسر بنفس الأمان مثل الطبقة الأولى. وغالبًا ما يعتمد على جسر كاتب عدل أو جسر ثالث. party Bridge.plan.

في الوقت الحالي، يبدو أن تنفيذ حل التحقق من العميل/التراكم السيادي منخفض نسبيًا، فهو يحتاج فقط إلى تنفيذ إصدار البيانات على سلسلة BTC، باستخدام نموذج مشابه لبروتوكول Ordinals. أما بالنسبة للتحقق خارج السلسلة والإجماع خارج السلسلة، فهناك مجال كبير للعب الحر.حتى العديد من السلاسل الجانبية تصبح في الأساس "مجموعة سيادية قائمة على BTC" طالما أنها تنشر بيانات DA إلى BTC، ولكن فقط الأمن المحدد مشكوك فيه.

لكن المشكلة هي أن معدل نقل بيانات البيتكوين منخفض للغاية. يبلغ الحد الأقصى لكل كتلة 4 ميجابايت، ويبلغ متوسط ​​وقت إنشاء الكتلة 10 دقائق. وهذا يتم تحويلها إلى سرعة نقل بيانات 6 كيلو بايت/ثانية فقط. قد لا يتمكن حل الطبقة الثانية الحالي الذي يطلق على نفسه اسم التراكمي السيادي من نشر جميع بيانات DA على سلسلة BTC، وسوف يتبنى طرق تسوية أخرى: مثل نشر بيانات DA خارج السلسلة وتخزين datahash في سلسلة BTC باعتباره "التزامًا". أو ابحث عن طريقة لضغط بيانات DA بشكل كبير (مثل State diff+ZK Proof الذي تدعي Chainway استخدامه).

ولكن من الواضح أن هذا النموذج لا يفي بتعريف "التراكم السيادي" أو التراكم الخطير. فهو متغير وأمانه موضع تساؤل. نتوقع أنه في المستقبل، لن تقوم معظم مشاريع الطبقة الثانية تحت شعار "إظهار البيانات المجمعة" بإصدار بيانات DA الكاملة إلى سلسلة BTC.لذا فإن خططهم العملية لن تكون على الأرجح متسقة مع المستند التقني. الشعارات "ZK Rollup" و"OP Rollup" الموجودة على موقع الويب غير متسقة.

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

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

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

هيكل BTC DA

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

يمكننا ملاحظة إرسال بيانات DA من مُسلسِل Chainway، وتجزئة المعاملة الخاصة به هي:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000، الرسم التخطيطي كما يلي:

يعتمد كود البرنامج النصي لهذه المعاملة على استخدام OP_0 OP_IF في الترتيبيات بروتوكول تنفيذ البيانات تكتب خطة الكتابة بيانات DA الخاصة بـ Rollup في سلسلة BTC (تغييرات حالة النشر + ZK Proof يعادل نشر بيانات المعاملات الأصلية من حيث الأمان، ولكن يمكن ضغط حجم البيانات بشكل كبير).

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

نحتاج أيضًا إلى ملاحظة أنه لأي معاملة تتضمن إرسال بيانات DA، هناك 16 صفرًا ثنائيًا في نهاية تجزئة المعاملة (أي أن البايتتين المتتاليتين كلها 0). داخل الكود يمكننا رؤية هذا القيد:

السابق الرقم العشوائي b715 في مثال مخطط المعاملة هو ضبط القيمة المجزأة لهذه المعاملة بحيث يحمل ذيلها 16 صفراً محدداً، والمبدأ مشابه للحاجة إلى إضافة رقم عشوائي nonce عند تعدين البيتكوين، بحيث يكون التجزئة الأول البتات N كلها 0، وتفي بقيود محددة.

يهدف هذا التصميم إلى تبسيط صعوبة الحصول على بيانات DA. عندما ترغب أي عقدة في الطبقة الثانية في الحصول على بيانات DA، فإنها تحتاج فقط إلى مسح كتلة BTC، وجميع البيانات يتم تعيين النهايات على 16 0 معاملةتعادل المعاملات التي تبدأ عندما يرسل جهاز تسلسل Chainway البيانات، مما يميزها بوضوح عن المعاملات الأخرى في سلسلة Bitcoin. في ما يلي، يسمى هذا النوع من المعاملات التي تحتوي على بيانات DA وتلبي 16 صفرًا في النهاية "معاملة Chainway القياسية".

ثم تأتي النقطة المذكورة في عنوان هذا المقال: كيف تحقق شركة تشينواي مقاومة الرقابة؟ نظرًا لأن مُسلسِل الطبقة الثانية قد يرفض عمدًا طلب معاملة المستخدم، يجب علينا استخدام حل خاص للسماح للمستخدمين ببدء معاملات مقاومة للرقابة.

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

بنية معلمات المعاملة القسرية هي كما يلي:

سيتم تقديم هذه المعاملة إلى سلسلة Bitcoin باعتبارها "معاملة مواصفات Chainway"، مع 16 صفرًا في نهاية تجزئة المعاملة. عندما يقوم مُسلسِل ChainWay بإنشاء كتلة L2، يجب أن يتضمن "معاملات Layer2 القياسية" التي تم الكشف عنها في سلسلة BTC ولكن لم يتم تضمينها في دفتر الأستاذ L2، وتلخيصها في شجرة Merkle، مع جذر Merkle الخاص بهم يكتب رأس كتلة L2.

بمجرد أن يبدأ المستخدم معاملة قسرية مباشرة على سلسلة BTC، يجب على جهاز التسلسل معالجتها، وإلا فلن يمكن إنشاء الكتلة الصالحة التالية. يمكن لعميل Chainway ضمن سلسلة BTC أولاً التحقق من شهادة ZK، وتحديد صلاحية كتلة L2 المقدمة من جهاز التسلسل، والتحقق من جذر Merkle لرأس كتلة L2، وتحديد ما إذا كان جهاز التسلسل يحتوي بشكل صحيح على المعاملة القسرية طلب.

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