خلاصة القول؛د.د

  • يجب أن تتمتع L2 بنفس مقاومة الرقابة التي تتمتع بها L1 التي تستند إليها L1
  • على BOB، يمكن للمستخدمين بالفعل فرض سحب أصولهم من BOB إلى الإيثيريوم عبر معاملة إيثيريوم
  • بالنسبة لجسر BitVM الخاص به، يعمل BOB على دمج البيتكوين كوسيلة للمستخدمين لفرض المعاملات على BOB
  • سيتمكن مستخدمو البيتكوين من سحب البيتكوين من بنك BTC دون الحاجة إلى إرسال معاملة إلى بنك BB

‍

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

بالنسبة لجسر BitVM الخاص ب BOB، يطرح هذا مشكلة مثيرة للاهتمام. تستخدم BOB حاليًا نقاط Ethereum EIP-4844 كطبقة DA الخاصة بها. يمكن للمستخدمين على الإيثيريوم تشغيل عمليات السحب بسهولة إلى البيتكوين عبر جسر BitVM. ومع ذلك، يتطلب الأمر أن يكون لدى المستخدمين ETH على الإيثيريوم.

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

‍

خلفية عن DA والاشتقاق

تُعد عملية الاشتقاق مهمة للغاية بالنسبة لطبقات L2: يجب بناء حالة L2 الكاملة لـ BOB من طبقة L1 وطبقة DA. فهي تسمح لطبقات L2 بالتمتع بنفس مقاومة الرقابة التي تتمتع بها طبقة DA، وفي حالتنا هذه، الإيثيريوم.

بشكل مبسّط، في القوائم المتتالية (على وجه التحديد سلاسل المكدس OP Stack)، لدينا نوعان من البيانات على L1:

  • معاملات الإيداع التي أُجريت على عقد "OptimismPortal". هذه هي المعاملات التي يجريها المستخدمون على الإيثيريوم عادةً لإيداع أصولهم في بنك البحرين الوطني. يمكن أيضًا استخدام معاملات الإيداع هذه لتنفيذ معاملات أخرى على BOB.
  • الدفعات التي يرسلها المتسلسل (أو ضارب العمليات لنكون أكثر دقة) من معاملات L2. تتضمن هذه جميع المعاملات التي أجراها المستخدمون مباشرةً على BOB ويتم تضمينها في النهاية في نقاط الإيثيريوم.

‍

البيتكوين كطبقة DA Layer

إذا كنا نريد البيتكوين كطبقة DA، فلماذا لا نتحول بالكامل إلى استخدام البيتكوين بالكامل كطبقة DA؟ الإجابة في الغالب هي التكلفة. لا يتوفر للبيتكوين سوى مساحة تخزين قليلة جداً (حوالي 4 ميجابايت كل 10 دقائق تقريباً)، وبالتالي فإن تكلفة التخزين مرتفعة.

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

‍

خط أنابيب الاشتقاق الهجين

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

  1. معاملات السحب الإجباري للبيتكوين (تمت إضافتها حديثًا خصيصًا لبنك البحرين والكويت)
  2. إيداعات الإيثيريوم في عقد OptimismPortal من BOB (معيار OP Stack)
  3. دفعات الإيثيريوم من معيار Op-batcher (معيار OP Stack)

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

‍

معاملات السحب القسري للبيتكوين

سنحتاج إلى ثلاثة أجزاء لإنشاء معاملة سحب إجباري:

  1. إنشاء معاملة السحب الإجباري على البيتكوين.
  2. قم بتخزين معاملة السحب الإجباري على البيتكوين في حدود حجم البيتكوين.
  3. التعامل مع تكاليف الغاز الخاصة بمعاملة السحب الإجباري على البيتكوين.

‍

1. إنشاء معاملة السحب الإجباري

تحتوي معاملة إيداع كومة العمليات التشغيلية على الهيكل التالي:

  • بايت32 تجزئة المصدر: تجزئة المصدر، تحدد بشكل فريد مصدر الإيداع.
  • العنوان من: عنوان حساب المرسل.
  • العنوان إلى: عنوان حساب المستلم، أو العنوان الفارغ (صفر الطول) إذا كانت المعاملة المودعة عبارة عن إنشاء عقد.
  • uint256 mint: قيمة ETH المراد سكها على L2.
  • قيمة uint256: قيمة ETH المراد إرسالها إلى حساب المستلم.
  • uint64 الغاز: حد الغاز لمعاملة L2.
  • bool isSystemTx: إذا كان صوابًا، فإن المعاملة لا تتفاعل مع تجمع غاز الكتلة L2.
  • بيانات البايت: بيانات الكالداتا

تتطلب معاملة السحب الإجباري تضمين معاملة السحب المشفرة في حقل بيانات معاملة الإيداع. يتم ذلك عن طريق إنشاء المعاملة على BOB التي تؤدي إلى السحب من BOB إلى Bitcoin وستعمل تمامًا كما لو تم إرسال المعاملة من Ethereum.

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

‍

2. قم بتخزين معاملة السحب القسري على البيتكوين

نظرًا لأن البيانات الخاصة بمعاملة السحب القسري أكبر مما يجب تخزينه عادةً في مخرج OP_RETURN، فمن المحتمل أن نستخدم مخرج Taproot لتخزين البيانات.

في حين أنه من السهل تحديد معاملة الإيداع (التي قد تتضمن سحبًا) على الإيثيريوم نظرًا لإرسالها إلى عقد OptimismPortal الخاص ب BOB، إلا أنه ليس من السهل تحديد معاملة السحب الإجباري على البيتكوين.

تسلسل البيانات: يتم تسلسل معاملة السحب القسري باستخدام نصوص Taproot داخل بنية "مغلف". هذه هي نوبس على شبكة البيتكوين وتستخدم، على سبيل المثال، في Ordinals أيضًا. نقوم بتعديل البنية لتناسب احتياجاتنا.

إلغاء التعيين

OP_FALSE OP_IF

 OP_PUSH "بوب"

 OP_1

 OP_PUSH "معاملة"

 OP_0

 op_push $withdrawal_transaction_data

OP_ENDIF

مخطط الالتزام/الإحالة على مرحلتين:

كما هو الحال مع Ordinals، سيتعين على المستخدمين إرسال معاملتين إلى البيتكوين:

  • التزام المعاملة: ينشئ مخرجات Taproot تلتزم بالنص البرمجي الذي يحتوي على محتوى النقش. لا تكشف هذه المعاملة عن البيانات بعد وسنحتاج إلى المعاملة الثانية للعقد الكاملة لـ BOB والمسلسلات لتضمين معاملة السحب.
  • كشف المعاملة: ينفق الإخراج من معاملة الالتزام، ويكشف عن النقش على السلسلة، أي يكشف عن معاملة السحب الخاصة بالمستخدم لإدراجها في BOB.

‍

3. التعامل مع تكاليف الغاز في صفقة السحب القسري

هذه هي المشكلة الأكثر انفتاحًا حتى الآن، مع وجود خيارين قيد الدراسة حاليًا:

  • اضبط الغاز على 0 لمعاملة السحب الإجباري على البيتكوين واخصم تكاليف الغاز من رصيد ETH الخاص بالمستخدم على BOB. بهذه الطريقة، يمكن فقط للمستخدمين الذين لديهم ETH على BOB فرض عمليات السحب. ومع ذلك، هذا ليس خيارًا جيدًا لأنه سيتطلب من المستخدمين أن يكون لديهم ETH على BOB لفرض عمليات السحب، أي أن المستخدمين الذين لديهم BTC على Bitcoin لا يمكنهم فرض عمليات السحب.
  • يدفع المستخدمون الغاز بعملة البيتكوين على البيتكوين. يجب أن يكون لشبكة BOB عنوان على Bitcoin يمكنه تلقي BTC، وسيحتاج إلى أن يكون لدى شبكة BOB عنوان على Bitcoin يمكنه تلقي BTC، وسيقوم فعليًا بتبديل BTC التي يتلقاها المستخدم إلى ETH على BOB لدفع الجزء L1 من تكاليف الغاز بالإضافة إلى تكاليف التنفيذ. من المحتمل أن يكون هذا الخيار باستخدام BOB Gateway وتعيين عنوان EVM الخاص بـ BOB DAO على شبكة BOB DAO كمستلم BTC.

نحن نجرب أيضاً المزيد من الأفكار، لذا ترقبوا المزيد من التحديثات!

‍

تجميع كل شيء معًا

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

  1. اقرأ جميع معاملات السحب من البيتكوين. يتم ترميزها على شكل معاملتين لكل عملية سحب، أي التزام واحد ومعاملة كشف واحدة. هذه هي الإضافة التي نقوم بها إلى مكدس OP Stack وحيث نقوم بتعزيز خط أنابيب الاشتقاق.
  2. اقرأ جميع المعاملات التي أُجريت على عقد OptimismPortal الخاص بـ BOB على الإيثيريوم. هذا بالفعل جزء من خط أنابيب اشتقاق OP Stack القياسي.
  3. قراءة جميع المعاملات التي تتم مباشرةً على BOB ودمجها كجزء من الدفعات على Ethereum. والأهم من ذلك، لا تقرأ العقد الكاملة مباشرةً من جهاز التسلسل لتلقي المعاملات المؤكدة ولكنها تقرأ من نقاط الإيثيريوم. هذا بالفعل جزء من خط أنابيب اشتقاق OP Stack القياسي.

‍

التحديات التقنية

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

إثباتات الاحتيال والصلاحية: يجب تحسين نظام إثبات الاحتيال لكل من BitVM والإيثيريوم للتعامل مع البيانات من كلا السلسلتين، مما قد يجعل تسوية المنازعات أكثر تعقيداً. ولمعالجة ذلك، نحتاج إلى حساب المعاملات المحتملة من البيتكوين والإيثريوم بدقة كجزء من جسر BitVM وتسوية BOB على الإيثريوم.

زيادة التخزين: بالإضافة إلى ذلك، تواجه عُقد BOB في الشبكة زيادة في متطلبات التخزين وعرض النطاق الترددي لأنها تحتاج إلى معالجة وتخزين البيانات من البيتكوين والإيثيريوم. ومع ذلك، يمكننا التخفيف من ذلك من خلال اشتراط أن يتم تضمين معاملات BOB التي تتم على البيتكوين في نقاط الإيثيريوم مع الإشارة إلى أحدث كتل البيتكوين. بهذه الطريقة، تحتاج العقد إلى مزامنة كتل البيتكوين الحديثة فقط.

‍

الخطوات التالية

نحن متحمسون لدفع حدود اللفائف الهجينة التي تجمع بين أمان البيتكوين وابتكار الإيثيريوم. في هذه المشكلة الملموسة، نحن مهتمون بالحصول على مقاومة البيتكوين للرقابة على المعاملات مع مكدس تجميع BOB. سنقوم بتحديث منشور المدونة هذا بمزيد من المعلومات كلما أحرزنا تقدماً.

‍