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

tl;dr

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

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

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

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

خلفية حول DA والاشتقاق

عمليةالاشتقاقمهم جداً بالنسبة للتوسعات من الطبقة الثانية: يجب بناء الحالة الكاملة للطبقة الثانية لـ BOB من الطبقة الأولى وطبقة DA. يتيح للتوسعات من الطبقة الثانية الاستمتاع بنفس مقاومة المراقبة كطبقة DA، في حالتنا، Ethereum.

مبسط, في اللفات (بالضبط سلاسل OP Stack)، لدينا نوعين من البيانات على L1:

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

بيتكوين كطبقة DA

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

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

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

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

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

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

تحويلات السحب الإجباري لبيتكوين

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

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

1. قم ببناء عملية السحب القسري

مكدس OPعملية الإيداعلديها الهيكل التالي:

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

يتطلب إجراء السحب القسري تضمين العملية المشفرة للسحب في حقل البيانات لعملية الإيداع. يتم ذلك عن طريق إنشاء العملية على بوب التي تُشغّل السحب من بوب إلى بيتكوين وستعمل بالضبط كما لو تم إرسال العملية من إيثيريوم.

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

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

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

على الرغم من أنه من السهل تحديد عملية إيداع (التي قد تتضمن سحبًا) على Ethereum لأنها ترسل إلى عقد OptimismPortal لـ BOB ، إلا أنه ليس من السهل تحديد عملية سحب مجبرة على Bitcoin.

تسلسل البيانات: يتم تسلسل معاملة الانسحاب الإجباري باستخدام نصوص Taproot داخل هيكل "ظرفي". هذه تعمل على شكل noops على شبكة Bitcoin وتستخدم على سبيل المثال للأعداد الترتيبية أيضًا. نحن نعدل الهيكل ليتناسب مع احتياجاتنا.

غير محدد
OP_FALSE OP_IF
OP_PUSH "بوب"
OP_1
OP_PUSH 'transaction'
OP_0
OP_PUSH $WITHDRAWAL_TRANSACTION_DATA
OP_ENDIF
نظام الالتزام / الكشف المرحلي:
كما هو الحال مع الترتيبات، سيتعين على المستخدمين تقديم صفقتين إلى بيتكوين:

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

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

هذه هي أكثر المشكلة مفتوحة حتى الآن، مع خيارين تحت النظر حاليا:

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

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

وضعها جميعًا معًا

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

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

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

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

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

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

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

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

تنصل:

1. تم نشر هذه المقالة من [BOB]. جميع حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [دومينيك هارز]. إذا كان هناك اعتراضات على هذه الإعادة النشر ، يرجى الاتصال بـبوابة تعلمالفريق، وسوف يتعاملون معها بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك المؤلف ولا تشكل نصيحة استثمارية.
3. فريق تعلم جيت قام بترجمة المقالة إلى لغات أخرى. يُحظر نسخ أو توزيع أو نسب المقالات المترجمة ما لم يذكر.