ZK-Rollup من Citrea: عمل Bitcoin غير المكتمل

في الآونة الأخيرة، تلقى Citrea، وهو أول مشروع Bitcoin Layer-2 يدعي اعتماد حل ZK-Rollup، أسئلة من المجتمع لأنه على وشك الاتصال بالإنترنت على شبكة الاختبار. للترويج لـ Citrea، استخدموا بعض الكلمات الخادعة لتضخيم مشاريعهم. على أعتاب هذه الأزمة، ليس هناك شك في أن هذا هو أفضل وقت لدراسة Citrea وBitVM.

السبب في كل شيء هو: أظهرت ZKP مواهبها على الطبقة الثانية استنادًا إلى Ethereum، مما جعل العديد من المشاريع تعلق آمالها على ما إذا كان من الممكن استخدام ZKP أيضًا في Bitcoin طبقة-2 على. من الواضح أن عددًا كبيرًا من المطورين (خاصة المطورين الأكثر إرضاءً) غير مؤيدين جدًا لتطوير Bitcoin Layer 2، ومخاوفهم معقولة جدًا. تقوم الطبقة الثانية التقليدية، مثل Optimisic وZkrollup المستندة إلى Ethereum، بضغط بيانات شبكة الطبقة الأولى وتوسيع موارد الحوسبة من خلال الحساب خارج السلسلة والتحقق عبر السلسلة. ببساطة لأن شبكة البيتكوين لا تدعم التحقق المنطقي المعقد، فمن الصعب تنفيذ هذا الحل. لذلك، فإن معظم مشاريع Bitcoin Layer-2 التي تدعي أنها تستخدم تقنية إثبات المعرفة الصفرية تستخدم حلاً يسمى Sovereign Rollup.

التقرير السيادي

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

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

مبدأ التراكم السيادي: تخزين الأدلة في السلسلة والتحقق من السلسلة

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

BitVM

حول ماهية BitVM وللمجتمع إنه أمر غامض بالنسبة لمعظم الناس: يبدو أن BitVM قد اقترحت حلاً يمكنه إجراء التحقق من ZKP في طبقة واحدة، ولكن هذا الحل يحتاج في النهاية إلى التنفيذ باستخدام طريقة تراكمية متفائلة. اقترحت BitVM المبكرة أيضًا محاكاة وحدة المعالجة المركزية على Bitcoin لتمكين جميع الحسابات الممكنة - وهو ما يبدو مثل استخدام Redstone لبناء جهاز كمبيوتر في Minecraft. هذه الادعاءات الغريبة تجعل معظم الناس يحتقرونها ويتبنون طرقًا أكثر عملية مثل المحتوى القابل للتنزيل (DLC) أو حفظ الحساب لحماية أمان أصول الطبقة الثانية. ومع ذلك، هناك أيضًا بعض المشاريع التي تعتقد أن BitVM هو مستقبل Layer-2 وقد استثمرت الكثير من الأبحاث، مثل بطل الرواية الحاليCitrea. من الواضح أنه من المهم أن نفهم ما هو BitVM.

من أجل معرفة الحقيقة حول BitVM، سنستخدم الطريقة الأكثر مباشرة: تحليل مستودع Github الخاص بـ BitVM. بشكل عام، يتضمن جوهر مستودع BitVM ما يلي:

• بيئة تشغيل Bitcoin Script افتراضية.

• وظيفة مساعدة لربط نصوص Bitcoin النصية.

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

BitVM في الواقع يشبه إلى حد كبير الكتل البرمجية الإنشائية: تم ربطها معًا من OP_CODE الأساسي

في هذا المثال، يمكننا تم اكتشاف عناصر مختلفة: كود التشغيل، وسلسلة من أكواد التشغيل الجديدة التي تم تغليفها. من بينها، تلك التي تحتوي على البادئة OP_ هي أكواد التشغيل الأصلية لـ Bitcoin Script، بينما تمثل الوظائف مثل u8_add_carry أكواد التشغيل الجديدة التي تم تغليفها وتخصيصها بواسطة BitVM. من الواضح أن هذه الوظيفة u32_add نفسها سيتم استخدامها أيضًا في إنشاءات Opcode أخرى.

يبدو هذا طفوليًا بعض الشيء، لكن لا تقلل من شأن هذه الوظائف، فهي في الواقع الأساس لمزيد من بناء ZKP من خلال حساب u32، وbigint يتم بناؤها تدريجيا، وحتى حساب bn256، أثبت أخيرا لبناء النظام. ومن مظهر المستودع، فقد حققوا الكثير مما يستحق الذكر: لقد تمكنوا من بناء وظائف التحقق المستندة إلى Groth16! يبدو أنهم ليسوا بعيدين عن بناء ZKP صالح للاستخدام أخيرًا.

Citrea وBitVM

بعد التعرف على الوضع الحالي بعد ذلك، يسعدنا بالطبع رؤية النتائج، والتي سيكون لها أهمية إيجابية للغاية لبيئة Bitcoin Layer-2 بأكملها. ومع ذلك، لاحظنا أيضًا وجود عدم تزامن معين بين اندلاع Bitcoin Layer-2 ووتيرة تطوير BitVM. ففي نهاية المطاف، لا ينتظر الوقت أحدًا، فالمشاريع التي تدعي أنها اعتمدت BitVM يجب أن تُفهم في الواقع على أنها "سوف تتبنى BitVM". وعلى الرغم من النتائج الواعدة، إلا أنها ليست متاحة تجاريًا بعد. من وجهة النظر هذه، فإن ادعاء Citrea بأنها أول مجموعة ZK على Bitcoin سوف يسبب الجدل حتمًا.  

قبل اكتمال BitVM رسميًا، كانت Citrea عبارة عن مجموعة مجمعة مستقلة

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

(1) مجموعة السيادة

Citrea لا تزال عبارة عن مجموعة تراكمية سيادية نموذجية، ولكنها لا تنفذ zk-rollup المكافئ حقًا لـ Ethereum Layer-2. فيما يتعلق بهذه النقطة، في الواقع، ذكرت Citrea أيضًا في إعلان Testnet أن BitVM حاليًا ومكونها الأساسي، Clamentiane (https://www.blog.citrea.xyz/unveiling-clementine/)، ليس بعد مكتمل. الوضع الحالي هو أنهم سيحفظون حالة الحساب في شبكة Citrea كجذر شجرة Merkle، وعلى Bitcoin، من خلال Inscription، سيقومون في نفس الوقت بتسجيل التغييرات في جذر شجرة Merkle وZKPs المقابلة لها. من الواضح أنه لا توجد قيود على النقش على البيتكوين؛ لذلك، يجب التحقق من جذور ZKP وMerkle بشكل نشط بواسطة عقد Citrea. وفي الوقت نفسه، تكون عملة البيتكوين مسؤولة فقط عن وضع اللمسات النهائية على حالتها، ولكن ليس عن ضمان صحتها. لذلك، من المؤسف أن Citrea لا تزال عبارة عن مجموعة سيادية نموذجية؛ فمشاركتها في BitVM تكون فقط في التحقق النشط من ZKPs بواسطة العقد.

قيود التحقق الذاتي: عدم القدرة على ضمان صحة الأدلة الموجودة في السلسلة

(2) RISC0< /strong

تستخدم Citrea حزمة SDK المقدمة من RISC0 كأساس لأجزاء ZKPs وzkEVM الخاصة بها. RISC0 هو حل ZKPs جديد نسبيًا ولد في عام 2022. لدى RISC0 وCairo رؤية متشابهة جدًا - من خلال بناء zkVM، يمكن لـ ZKP إجراء أي عملية حسابية عامة؛ ولكن بالمقارنة مع القاهرة، فإن RISC0 نفسها ليست لغة، ويمكن بناؤها مباشرة من خلال SDK المتوفرة في Rust. بعد ذلك، يتم إجراء الحساب من خلال zkVM المخصص له. بالإضافة إلى RISC0، فإن جهاز كايرو VM المعتمد على zk-STARK مفضل أيضًا بواسطة Bitcoin Layer-2. لقد لاحظنا أن العديد من المشاريع تعتمد هذا النموذج العام للحوسبة + zkVM ليحل محل نموذج zk language + zk Prover + zk Verifier. وذلك لأن zk Verifier غير متاح مؤقتًا في Bitcoin، لذا بالنسبة لـ Sovereign Rollup، فإن استخدام zkVM مباشرة هو بلا شك طريقة أكثر اقتصادا وكفاءة.

الاستنتاج

بادئ ذي بدء، فيما يتعلق بالجدل الأخير في Citrea لقد أشار الفريق بوضوح إلى أن توافقه مع BitVM لم يكتمل بعد، وهذا الاستنتاج يعني أن مجموعة التحديثات التي يمكنها أن ترث أمان Bitcoin بالكامل لم تظهر بعد؛ ولكن في عملية مراقبة المشروع بأكمله، رأينا أيضًا أن هناك ابتكارات مستمرة تعتمد على Bitcoin Layer-2، وفي الوقت نفسه، هناك عدد كبير من المشاريع التي تتحدى مجموعة ZK-rollup الخاصة بـ Bitcoin، مثل Bitlayer؛ Alpenlabs، وشبكة BVM، وما إلى ذلك، كلها تدفعنا إلى مواصلة تتبع وتحليل تقدم عملية Rollup in Bitcoin.