ملخص:

شبكة B^2 Network قد أنشأت طبقة توافر البيانات (DA) المعروفة باسم B^2 Hub داخل سلسلة البتكوين، مستلهمة من مفاهيم Celestia. تقوم شبكة طبقة DA هذه بتنفيذ عينات البيانات وترميز المحو اللازم لضمان توزيع سريع للبيانات الجديدة إلى العديد من العقد الخارجية ولمنع احتجاز البيانات. بالإضافة إلى ذلك، يتحمل الشخص الملتزم داخل شبكة B^2 Hub مسؤولية رفع فهرس التخزين وتجزئة البيانات لبيانات DA إلى سلسلة البتكوين للوصول العام.

. للتخفيف من العبء على عقدة طبقة DA، لا يتم الاحتفاظ بالبيانات التاريخية في B^2 Hub بشكل دائم. وبناءً على ذلك، سعت B^2 إلى إعادة بناء شبكة تخزين، باستخدام آلية تحفيز تخزين مشابهة لـ Arweave لتحفيز المزيد من العقد لتخزين مجموعات بيانات تاريخية شاملة مقابل مكافآت التخزين؛

· بالنسبة للتحقق من الحالة، يعتمد B^2 نهج التحقق الهجين لتحقق الأدلة ZK خارج السلسلة ويستغل مفهوم bitVM لتحدي أثار التحقق من الأدلة ZK على السلسلة. يتم ضمان سلامة شبكة B^2 عندما يبدأ العقد الفاحص تحديًا عند اكتشاف خطأ، متماشيًا مع نموذج الثقة لبروتوكول الإثبات ضد الاحتيال. ومع ذلك، نظرًا لاستخدام أدلة ZK، فإن عملية التحقق من الحالة هذه تكون في جوهرها هجينة الطبيعة؛

· وفقًا لخطة B^2 Network المستقبلية، يحتمل أن يكون B^2 Hub المتوافق مع EVM قادرًا على العمل كطبقة تحقق خارج السلسلة وطبقة DA تربط العديد من حلول Bitcoin Layer 2. يهدف إلى التطور إلى طبقة توسع وظيفية خارج السلسلة لبيتكوين شبيهة بـ BTCKB. نظرًا لقيود بيتكوين في دعم سيناريوهات مختلفة، من المتوقع أن يصبح تطوير طبقة توسع وظيفية خارج السلسلة ممارسة شائعة ضمن بيئة Layer 2.

B^2 Hub: طبقة توافر البيانات (DA) العالمية وطبقة التحقق ضمن سلسلة البيتكوين

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

عودًا إلى نقطة الجدل: تبقى تعريف الطبقة 2 نقطة جدل بين الأفراد. هل هو سلسلة جانبية؟ مؤشر؟ هل مصطلح الطبقة 2 يشمل السلاسل التي تنشئ اتصالات؟ هل يمكن لبرنامج إضافي بسيط يعتمد على بيتكوين وإيثيريوم أن يؤهل كطبقة؟ هذه الاستفسارات تشبه المعادلات الغير محلولة بدون حلا نهائيًا.

وفقًا لوجهات نظر مجتمعات إيثيريوم وكيلستيا، يُمثل الطبقة 2 حالة مميزة من سلسلة الكتل القابلة للتعديل. في هذا السياق، توجد ترابط وثيق بين ما يسمى "الطبقة الثانية" و"الطبقة الأولى". يمكن أن تورث الأمان في الطبقة 1 جزئيًا أو بشكل كبير من شبكة الطبقة الثانية. يشمل الأمان نفسه فئات فرعية مختلفة، بما في ذلك DA، التحقق من الحالة، التحقق من السحب، مقاومة الرقابة، ومقاومة إعادة التنظيم.

نظرًا للقيود الجوهرية لشبكة البيتكوين، فإنها ليست بشكل جوهري مواتية لدعم شبكة الطبقة 2 الشاملة. على سبيل المثال، من حيث قدرة معالجة البيانات، تتأخر بشكل كبير قدرة البيتكوين عن تلك للإيثيريوم. بمتوسط زمن تكوين الكتلة يبلغ 10 دقائق، فإن معدل معالجة البيانات القصوى للبيتكوين هو مجرد 6.8KB / ث، أي ما يعادل 1/20 من قدرة الإيثيريوم تقريبًا. ونتيجة لذلك، تؤدي الحاجة المتزايدة في مساحة الكتل إلى ارتفاع تكاليف نشر البيانات.

(تكلفة نشر البيانات في كتلة بيتكوين يمكن أن تصل إلى 5 دولارات لكل كيلوبايت)

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

يتيح هذا لأي شخص التحقق من صحة فرق الحالة وZKP التي تم تنزيلها من شبكة البيتكوين الرئيسية مع الحفاظ على بيانات خفيفة على السلسلة.

(يوضح الورقة البيضاء السابقة لبوليجون هيرميز مبدأ خطة الضغط أعلاه)

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

نتيجة لذلك، يختار العديد من حلول بتكوين الطبقة 2 عدم رفع بيانات DA إلى شبكة بتكوين الرئيسية وبدلاً من ذلك يستخدمون طبقات DA من الطرف الثالث مثل Celestia. على النقيض من ذلك، ينفذ B^2 نهجًا مختلفًا من خلال إنشاء شبكة توافر البيانات (DA) مباشرة تحت السلسلة، المعروفة باسم B^2 Hub. في هذا التصميم، يتم تخزين البيانات الحاسمة مثل بيانات المعاملات أو تغييرات الحالة خارج السلسلة، حيث يتم رفع مؤشرات تخزينها وتجزئة البيانات (المشار إليها ببساطة بالبيانات) فقط إلى شبكة بتكوين الرئيسية.

يتم تسجيل تجزئات البيانات وفهارس التخزين هذه على سلسلة Bitcoin على غرار النقوش. من خلال تشغيل عقدة Bitcoin ، يمكن للأفراد الوصول محليا إلى فهرس تجزئة البيانات وتخزينها. باستخدام قيمة الفهرس ، يمكنهم استرداد البيانات الأصلية من DA خارج السلسلة B ^ 2 أو طبقة التخزين. تسمح تجزئة البيانات بالتحقق من صحة البيانات التي تم الحصول عليها من طبقة DA خارج السلسلة مقابل التجزئة المقابلة على سلسلة Bitcoin. يتيح هذا النهج المباشر لحلول Layer 2 التخفيف من الاعتماد على شبكة Bitcoin الرئيسية لمشكلات DA ، وتقليل تكاليف المعاملات ، وتحقيق إنتاجية عالية.

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

وفقًا لخارطة الطريق الجديدة الرسمية لشبكة B^2 ، تستفيد حلول DA الخاصة بها من Celestia. في التصميم الأخير ، ستقوم مزودات البيانات الطرفية بتوفير البيانات باستمرار إلى شبكة Celestia. سيقوم منتجو كتل Celestia بتنظيم شظايا هذه البيانات في شكل شجرة Merkle ، وإدخالها في كتل TIA ، وبثها إلى الشبكة. محقق/كامل العقد.

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

وفقًا لخريطة الطريق الأخيرة لشبكة B^2 ، تستوحي حلول DA الخاصة بها من Celestia. في إطار هذا التصميم ، يقوم مزودو البيانات الخارجية بتوريد البيانات باستمرار إلى شبكة Celestia. يقوم منتجو الكتل ضمن Celestia بتنظيم شظايا هذه البيانات في هيكل شجرة Merkle ، وتضمينها في كتل TIA ، ونشرها للمحققين والعقد الكاملة في الشبكة. نظرًا لحجم البيانات الكبير وحجم الكتل الكبيرة ، يختار العديد من الأفراد تشغيل العقد الخفيفة بدلاً من العقد الكاملة. تقوم العقد الخفيفة بمزامنة رؤوس الكتل فقط التي تحتوي على جذر شجرة Merkle.

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

(مصدر الصورة: W3 Hitchhiker)

في شبكة Celestia، توجد مجموعة متنوعة من العقد الخفيفة التي تشارك في أخذ عينات عالية التردد من البيانات من مختلف العقد الكاملة. تختار هذه العقد الخفيفة بشكل عشوائي شظايا بيانات محددة من شجرة Merkle وتنشرها لعقد متصلة أخرى بسرعة وكفاءة، بهدف توزيع البيانات على جمهور واسع من الأشخاص والأجهزة. يسهل هذا النهج نشر البيانات بسرعة، مما يضمن أن يتلقى عدد كاف من العقد البيانات الأحدث بسرعة، وبالتالي القضاء على الحاجة إلى الاعتماد على مجموعة محدودة من مزودي البيانات. يظهر هذا الهدف الأساسي جوهر أساسيات توافر البيانات (DA) وتوزيع البيانات.

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

وعلاوة على ذلك، في السيناريوهات التي تظل فيها بيانات المعاملات معينة غير مكشوفة للأطراف الخارجية، يمكن أن يعرقل احتفاظ 1% فقط من شظايا البيانات الأجانب عن إعادة بناء مجموعة البيانات بأكملها - وهو موقف يذكرنا بهجمات احتجاز البيانات.

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

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

من خلال تنفيذ هذا الحل، تقوم سيليستيا بالتخفيف بشكل فعال من امتناع البيانات على منصة توزيع البيانات الخاصة بها. تخطط شبكة B^2 لاستخدام منهجية عينات البيانات لسيليستيا كنقطة مرجعية أساسية في المستقبل، مدمجة بشكل محتمل تقنيات التشفير مثل التزام KZG لتعزيز كفاءة وجدارة عمليات عينات البيانات والتحقق التي تجريها العقد الخفيفة.

من الضروري الاعتراف بأنه بينما تتناول الحلول المذكورة أعلاه الاحتفاظ بالبيانات داخل منصة DA ذاتها، في البنية التحتية Layer 2، تمتلك كل من منصة DA والمُرتّب بيانات Sequencer قدرات احتفاظ بالبيانات. في سياقات مثل B^2 Network، يقوم المُرتّب بيانات بتوليد بيانات جديدة عن طريق تنظيم ومعالجة معاملات المستخدمين والتغييرات في الحالة الناتجة إلى دُفعات قبل نقلها إلى عقد B^2 Hub الذي يعمل كطبقة DA.

في الحالات التي تنشأ فيها شوائب داخل الدفعة التي تم إنشاؤها بواسطة المسلسل، هناك خطر من عدم كشف البيانات أو أنشطة خبيثة أخرى. وبناءً على ذلك، عند استلام الدفعة، يتحقق شبكة DA الخاصة بـ B^2 Hub بدقة من محتوياتها وترفض أي دفعات مشكلة. وبالتالي، لا تعمل B^2 Hub فقط كطبقة DA مشابهة لـ Celestia ولكنها تعمل أيضًا كطبقة تحقق خارج السلسلة مماثلة لـ CKB في بروتوكول RGB++.

(رسم بياني لهيكلية شبكة B^2 Network غير مكتمل)

وفقًا لخريطة طريق تكنولوجيا B^2 Network الأخيرة، بمجرد أن يتلقى B^2 Hub دفعة ويتحقق منها، يحتفظ بها لفترة محددة قبل أن تنتهي صلاحيتها ويتم إزالتها من العقد المحلي. لمعالجة قضايا العمر الزمني للبيانات وفقدانها المماثلة لـ EIP-4844، ينشئ B^2 Network شبكة من عقد التخزين المكلفة بتخزين البيانات الدفعية بشكل دائم لاسترداد البيانات التاريخية بسهولة عند الحاجة.

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

يستخدم Filecoin بروتوكولات الإثبات المعروفة باسم PoRep و PoSt، مما يتيح لعقد تخزين تقديم شهادات تخزين كدليل على أنها حقًا قد قمت بتخزين البيانات بشكل آمن ضمن الإطار الزمني المحدد. ومع ذلك، ينطوي هذا النهج لإثبات التخزين على إنشاء ZK proofs، والتي تتطلب الكثير من الحوسبة وتضع مطالباً أجهزة كبيرة على عقد التخزين، مما قد يجعلها غير اقتصادية.

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

نظام التحقق من الحالة المختلط مع ZK ودليل الاحتيال

سابقًا، قمنا بتوضيح حلاً لتوافر البيانات (DA) لشبكة B^2، والآن سننغمس في آلية التحقق من الحالة الخاصة بها. مصطلح "مخطط التحقق من الحالة" يتعلق بكيفية تأكد Layer 2 من انتقال حالة "غير قابلة للثقة" بشكل كافٍ.

(يقوم موقع L2BEAT بتقييم خمس مؤشرات أمان رئيسية لـ Scroll. يُشير التحقق من الحالة إلى نظام التحقق من الحالة)

كما هو موضح على موقع L2BEAT، الذي يقيم مؤشرات الأمان لـ Scroll، تتناول التحقق من الحالة بشكل خاص نظام التحقق من الحالة. في شبكة B^2 ومعظم عمليات الطبقة 2، يتم إنشاء البيانات الجديدة من قبل المُسلسل. تقوم هذه الكيان بت consolيد ومعالجة المعاملات التي يبدأها المستخدم بالإضافة إلى تغييرات حالتها بعد التنفيذ. يتم تجميع هذه التعديلات في دفعات ونشرها إلى عقد العُقد المختلفة داخل شبكة الطبقة 2، مشملة العُقد الكاملة القياسية للطبقة 2 وعُقد B^2.

عند استلام بيانات الدفعة، يقوم العقد الذكي لعقدة B^2 Hub بتحليل والتحقق بدقة من محتوياتها، بما في ذلك "التحقق من الحالة" المذكور سابقًا. في الأساس، ينطوي التحقق من الحالة على التحقق من دقة "تغييرات الحالة بعد تنفيذ الصفقة" الموثقة في الدفعة التي تم إنشاؤها بواسطة المسلسل. أي حالة خاطئة داخل الدفعة تؤدي إلى رفضها من قبل عقدة B^2 Hub.

وظيفة B^2 Hub كشبكة عامة Proof-of-Stake (POS) تميز بين منتجي الكتل والتحقق. بشكل دوري، يقوم منتجي الكتل في B^2 Hub بتوليد كتل جديدة ونشرها إلى العقد الآخرين (المحققين). تحتوي هذه الكتل على بيانات دفعة (Batch) تم تقديمها بواسطة المتسلسل، محاكاة لعملية مشابهة لـ Celestia. يطلب العقد الخارجي بانتظام شظايا البيانات من عقد B^2 Hub، مما ييسر توزيع بيانات الدفعات إلى أجهزة العقد العديدة، بما في ذلك الشبكة التخزين المذكورة سابقًا.

في B^2 Hub يعمل دور حاسم يعرف بالمُلتزم. هذه الكيان يجزئ بيانات الدُفعة (بشكل خاص جذر ميركل)، يُخزن الفهرس، ويقوم بتقديمه إلى سلسلة البتكوين في شكل نقش. الوصول إلى تجزئة البيانات وفهرس التخزين يمكن من استرجاع البيانات الكاملة من طبقة DA خارج السلسلة / طبقة التخزين. بافتراض أن N عقدًا يخزنون بيانات الدُفعة تحت السلسلة، عندما يكون عقدٌ على استعداد لمشاركة البيانات مع الجهات الخارجية، يمكن لأي طرف مهتم الوصول إلى البيانات المطلوبة. افتراض الثقة في هذ scenariو هو 1/N.

من المؤكد أنه، من الواضح أن في العملية المذكورة أعلاه، B^2 Hub، المكلف بالتحقق من تحولات حالة الطبقة ٢، يعمل بشكل مستقل عن شبكة بيتكوين الرئيسية، مُخدماً فقط كطبقة تحقق خارج السلسلة. وبناءً على ذلك، يفتقر نظام التحقق من الحالة للطبقة ٢ في هذه اللحظة إلى مطابقة موثوقية شبكة بيتكوين الرئيسية.

بشكل عام، يمتلك ZK Rollup القدرة على إرث أمان الطبقة 1 بالكامل. ومع ذلك، نظرًا للقيود الحالية لسلسلة البيتكوين في دعم الحسابات الأساسية فقط ونقص قدرات التحقق المباشرة من دليل ZK، لا يمكن لأي حل من الطبقة 2 على البيتكوين أن ينافس نموذج أمان الإيثيريوم، وخاصة تلك التي تستخدم تقنيات ZK Rollup مثل Citrea و BOB.

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

المراجع:تفسير مبسط لـ BitVM: كيفية التحقق من دليل الاحتيال على سلسلة BTC (تنفيذ رمز العملية لـ EVM أو غيرها من أجهزة الإفتراض الظاهر)

في الحل الفني الخاص بشبكة B^2، بمجرد أن يولد المسلسل دفعة جديدة، يتم نقلها إلى المجمع والمثبت. يقوم المثبت بعد ذلك بتحويل عملية التحقق من البيانات للدفعة إلى ZK، وينتج شهادة ZK، ويرسلها في النهاية إلى عقد B^2 Hub المتوافق مع EVM. يتم المصادقة على البرهان ZK من خلال عقد Solidity، حيث يتم تقسيم جميع العمليات الحسابية إلى دوائر منطقية منخفضة المستوى معقدة. يتم ترميز هذه الدوائر بلغة البرمجة النصية لبيتكوين، وتنسيقها، وإرسالها إلى منصة توافر البيانات الخارجية (DA) ذات النفاذية الكافية.

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

(الرسم البياني للهيكل العام لشبكة B^2، باستثناء عقد عينات البيانات)

فمن يعاقب؟ في الواقع، هو الـ Committer. ضمن إطار شبكة B^2، الـ Committer لا يُذيع فقط هاش البيانات المذكورة سابقًا إلى سلسلة البتكوين ولكنه أيضًا يكشف "التزام" التحقق من شهادة ZK إلى الشبكة الرئيسية للبتكوين. من خلال تكوينات محددة لشجرة البتكوين، يحتفظ الأفراد بالقدرة على رفع استفسارات والاعتراض على "التزام التحقق من دليل ZK" الصادر عن الـ Committer على سلسلة البتكوين في أي وقت محدد.

للتوضيح حول مفهوم "الالتزام"، فإنه يشير إلى أفراد يؤكدون دقة بعض البيانات خارج سلسلة الكتل ونشر بيان مقابل على سلسلة الكتل. يعتبر هذا البيان "الالتزام" حيث يتم ربط قيم الوعد ببيانات خارج سلسلة الكتل محددة. في حل B^2، إذا اعترض أي طرف على الالتزام بالتحقق ZK الصادر عن الجهة الملتزمة، فلديه الخيار لتحديه.

قد يتساءل الشخص لماذا يحتاج B^2 Hub إلى التحقق من شهادة ZK "مرارًا وتكرارًا" إذا كان قد قام بالتحقق بالفعل من الدُفعة عند الاستلام. لماذا لا يكشف عن عملية التحقق من الدُفعة علنًا للتحديات المباشرة بدلاً من إدخال دليل ZK؟ إن إضافة دليل ZK تخدم لضغط آثار الحساب في حجم أكثر قابلية للإدارة قبل الإفراج عنه. كشف العملية الخاصة بالتحقق من المعاملات من الطبقة 2 وتغييرات الحالة في بوابات المنطق ونصوص Bitcoin علنًا سيؤدي إلى حجم بيانات كبير جدًا. يضغط تقنيات ZK هذه البيانات بفعالية قبل نشرها.

هنا خلاصة موجزة لسير عمل B^2:

1. يولد جهاز تسلسل البيانات في B^2 كتل Layer 2 جديدة ويجمع عدة كتل في دفعات بيانات. يتم إرسال هذه الدفعات إلى المجمع وجهاز التحقق في شبكة B^2 Hub.

2. يُرسل المجمع دفعة البيانات إلى عقد البرهان، مما يمكن إنشاء البرهان المتعلق بالمعرفة الصفرية الناتج. بعد ذلك، يتم نقل شهادة ZK إلى شبكة DA والتحقق منها لـ B^2 (محور B^2).

3. يتحقق عقد B^2 Hub node مما إذا كانت دليل ZK من المجمع متماشيًا مع الدفعة من السلسلة الزمنية. يشير التطابق الناجح إلى مرور التحقق. يتم إرسال تجزئة البيانات المتحققة وفهرس التخزين إلى سلسلة البيتكوين عن طريق عقد B^2 Hub المخصص (الملتزم).

4. تم الكشف علنًا عن عملية الحساب بأكملها للتحقق من دليل ZK Proof من قبل B^2 Hub، مع التزام هذه العملية تُقدم إلى سلسلة بيتكوين للتحديات المحتملة. يؤدي التحدي الناجح إلى فرض عقوبات اقتصادية على عقد B^2 Hub (يتم إلغاء قفل UTXO الخاص بهم على سلسلة بيتكوين ونقله إلى الطالب التحدي).

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

وفقًا لرؤى أعضاء مجتمع بيتكوين الغربي، هناك تكهنات حول فork مستقبلي محتمل لشبكة بيتكوين الرئيسية لدعم قدرات الحوسبة المحسنة. يمكن أن يمهد هذا الطريق للتحقق المباشر من ZK proof على سلسلة بيتكوين، مما يعلن عن تغييرات جذرية على منظر بيتكوين Layer 2 بأكمله. بوصفها طبقة DA وطبقة التحقق الأساسية، يعمل B^2 Hub ليس فقط كجزء أساسي من شبكة B^2 ولكنه يمنح قوة لطبقات بيتكوين الثانية الأخرى أيضًا. في مجال الحلول التنافسية لطبقة 2 من بيتكوين، تكتسب طبقات التوسع الوظيفية خارج السلسلة أهمية، حيث يُظهر B^2 Hub و BTCKB فقط لمحة عن هذا المنظر المتطور.

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

1. تم استنساخ هذه المقالة من [المتخصص Web3، مع العنوان الأصلي "تحليل خريطة تقنية B^2 الجديدة: ضرورة طبقة DA والتحقق تحت سلسلة البيتكوين." يُعزى حق النشر إلى الكاتب الأصلي، فاوست من Geek Web3. إذا كانت هناك أي اعتراضات على إعادة النشر، يرجى الاتصال بـفريق تعلم جيتلحل المشكلة بسرعة باتباع الإجراءات ذات الصلة.

2. الآراء والآراء التي تم نقلها في هذه المقالة تعكس بشكل حصري وجهات نظر الكاتب الشخصية ولا تعتبر توصية استثمارية.

3. يتم توفير ترجمات المقالة إلى لغات أخرى من قبل فريق Gate Learn. قد لا يتم نسخ المقالات المترجمة أو نشرها أو نسخها دون ذكر الأصل.Gate.io.