الشيء المتعلق بحد OP_RETURN الذي يتسبب في تغييره والذي لم يتم توضيحه بوضوح: لقد كان هناك إجماع لأطول وقت على أنه نادرا ما يكون هناك سبب لتخزين أكثر بكثير من سلسلة تجزئة 40 بايت لأي بروتوكول L2 يعمل فوق Bitcoin ، وبالتالي كان حد الترحيل 80 بايت في حين أنه كان صحيحا أن البروتوكولات الوصفية استفادت دائما من تخزين المزيد من البيانات داخل Bitcoin نفسها ، فقد تم تجاهل حالات الاستخدام هذه إلى حد كبير لأنها ليست حالات استخدام نقدي لأصل BTC: بشكل عام ، تستفيد البروتوكولات الوصفية مثل هذه من Bitcoin * blockchain * ، لكن قواعدها / منطقها لا يمكن أن تتفاعل مع أصل BTC مباشرة. لذا فهي ليست "مهمة" لاستيعاب blockchain Bitcoin تغير هذا مع عمل BitVM منذ عامين. الآن ، ولأول مرة ، من الممكن بناء بروتوكولات L2 التي تتفاعل مع أصل البيتكوين مباشرة مع الاستفادة من تقنيات أكثر غرابة (مثل براهين ZK و DA) هذا هو السبب في أن حالة استخدام Citrea تمكنت من الحصول على جمهور مع Core. إذا كانت Citrea تقوم فقط ببناء سلسلة جانبية من Ethereum تتفاعل مع الأصول غير ذات الصلة بالبيتكوين ، فلن يكون لها تأثير في كيفية تعيين Core لحدود الترحيل الافتراضية ولكن نظرا لوجود BitVM ، وبالتالي فإن براهين ZK و DA لها تأثير مباشر على القواعد التي تنتقل من خلالها عملات البيتكوين الفعلية عبر منطق blockchain ، فإن هذه الفئة من L2 يتم النظر فيها الآن لأول مرة عندما يراجع Core حدود الترحيل الخاصة بهم ، بدلا من مجرد تلبية احتياجات Lightning بعد 9 سنوات من اتجاهات الحراسة التي تهيمن على Lightning ، هل يمكنك حقا إلقاء اللوم عليهم للتأكد من أن L2s الخالية من القنوات يتم الاعتناء بها في معادلة إعدادات الترحيل الافتراضية؟ واجبات منزلية إضافية: لا يتعلق الأمر حتى ب "رعاية Citrea" ، يمكن ل Citrea بالفعل تضمين البيانات التي يحتاجونها في Bitcoin باستخدام مخرجات غير قابلة للإنفاق ، ولا يكلف Citrea شيئا للقيام بذلك ، Core يتكيف فقط بحيث لا يتضرر * Bitcoin * من خلال تضخم UTXO غير الضروري من خلال نمو بروتوكولات شبيهة ب Citrea فوق Bitcoin ، في نهاية اليوم تهتم ب * Bitcoin * ، لكنني رأيت أشخاصا يحاولون شرح ذلك لأشخاص Knots مليون مرة دون نجاح ، لذا فأنا أقدم زاوية بديلة