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

أفكك العملية وفق مسار BABE عند @BabylonLabs_io خطوة بخطوة، فأجد أنها لا تهدف إلى تشغيل مُتحقق ZK كامل على نظام Bitcoin، بل تحوّل التحقق من صحة البرهان إلى لعبة تحدٍ مُعدة سلفًا.

عند الاسترداد، تؤكد سلسلة المعالجة أولاً أن كتلة إشارة Ethereum قد تم نهائيًا، ثم تربط كتلة التنفيذ بإيصال الاسترداد، وأخيرًا يقوم SP1 بتوليد البرهان وضغطه إلى Groth16. يقوم المستلم ببث Claim وAssert، ثم يستخدم WOTS لكتابة الالتزام بالبرهان داخل معاملة Bitcoin؛ وبعد ذلك تدخل نافذة تحدٍ عامة على testnet لقرابة 432 كتلة من البيتكوين، تمتد قرابة ثلاثة أيام.

العنصر الحاسم هو Peg-in. وبحسب الإعدادات الحالية، يُطلب من كل مجموعة من المستلمين والتحدي أن تولد 307 نسخة مرشحة من دوائر التمويه، وأن تُنشر 301 نسخة للتحقق من محاولات الغش، ولا يبقى إلا 6 دوائر يتم اختيارها عشوائيًا لمعالجة النزاعات المستقبلية. كأنك تفك معظم أوراق الامتحانات المختومة للتأكد من صلاحيتها، ولا تستخدم المتبقي إلا للاختبار الرسمي.

إذا قدّم المستلم برهانًا مزيفًا، يعيد الموقِع (المتحدّي) تشغيل عملية التحقق ويطلق Challenge؛ ولا يستطيع البرهان المزيف استعادة الوسوم الصحيحة. بعد حوالي 108 كتل، يمكن للمتحدّي اتباع مسار No-Payout، مما يمنع إطلاق BTC ويصادر وديعته/ضمانه. أما إذا تعرض برهانٌ صحيح لتحدٍ خبيث، فيستطيع المستلم استخراج الوسوم الصحيحة وبث WronglyChallenged لمواصلة Payout، بينما يخسر المتحدّي وديعته.

لذلك ليست BABE مُصممة لجعل البيتكوين يفهم إيثيريوم مباشرة، بل لجعل الكاذبين غير قادرين على إتمام الخطوة التالية. لكن دوائر التمويه، وسلسلة توليد/تحضير البرهان، ونسبة تواجد المتحدّين (الـonline)، أي خلل في أي حلقة سيؤثر في إمكانية الخروج/النجاة. قبل إطلاق mainnet، أكثر شيء أريده أن أراه هو ما إذا كان نزاع حقيقي يمكن أن يمر كاملًا دون الاقتصار على مسار Happy Path دون تحديات.
#baby $BABY