مقترح MATT يستهدف العقود الحالة على Bitcoin (BTC) عبر OP_CCV في الطلب المدمج 32080

أوبكود يحمل الحالة إلى سكربت البيتكوين

طلب مدمج مفتوح حاليًا في مستودع Bitcoin (BTC) Core يمنح سكربتات الشبكة ما لم تملكه قط: ذاكرة. إطار MATT (Merkleize All The Things) يتيح العقود الحالة وأدلة الاحتيال القابلة للتوسع على الطبقة الأساسية للـالبلوكتشين، وأكثر تنفيذاته مباشرةً يمر عبر OP_CHECKCONTRACTVERIFY، أي OP_CCV، وهو أوبكود يحمله الطلب المدمج رقم 32080. والعهود هي قواعد سكربتية تقيّد الوجهات التي يمكن صرف العملات إليها في معاملات مستقبلية. السكربتات القياسية للبيتكوين تقيّم كل معاملة بمعزل عن غيرها، دون أي سجل لما فعلته الصرف السابقة، لذا لا يستطيع العقد حمل معلومات إلى الأمام وتحديثها مع تطور العقد. كل مقترح عهد يسمح، بدرجة ما، بـUTXOs تحمل الحالة. ولغات السكربت مثل Sapio، المبنية على OP_CTV، تدير ذلك بمعالجة العناوين كآلة حالات محدودة تُعدّ كل معاملة فيها انتقالًا من حالة إلى أخرى. ظل العهود سنوات ضمن مقترحات بروتوكول البيتكوين النشطة لأن لغة Script البسيطة تقصر عن ضمان ذلك. وهذه الآلة الحالات لا تترك وسيلة نظيفة للتعبير عن المنطق العددي، وهذه هي الفجوة التي يسدّها MATT. فالإطار يتيح حساب البيانات المُلزَمة وقت الصرف وإعادة تضمينها في المخرج التالي، فيستنتج كل صرف حالة جديدة ديناميكيًا بدل الاختيار من مجموعة حالات محددة سلفًا. صُمم الأوبكود لمخرجات Taproot، حيث ترتكيب الالتزامات على المفتاح العام نفسه لا على بيانات سكربت إضافية. وهذا الفرق يقرر ما إذا كان العقد قادرًا على التكيف مع الأرصدة المتغيرة أم لا سوى مع شجرة ثابتة من النتائج المتفق عليها مسبقًا. المقترح يخص طبقة السكربت الواقعة تحت سعر البيتكوين (BTC) لا أي شيء يظهر على الشارت، لكنه يحدد ما يستطيع الأصل فعله خارج التسوية البسيطة، من خزائن تعيد حساب شروط السحب وقت الصرف إلى أنظمة أدلة احتيال تتحقق من خطوة واحدة متنازع عليها فقط.

مفاتيح معدّلة وثلاثة أنماط تحقق

يحتوي كل مخرج Taproot على مفتاح عام أساسي يُسمى المفتاح الداخلي، ويمكن تعديله تشفيريًا، أي "tweaking"، ليلتزم بمعلومات إضافية. يأخذ المفتاح المعدّل الصيغة Q = P + t·G، حيث P هو المفتاح الداخلي وG مولّد منحنى secp256k1 الإهليلجي وt قيمة hash موسومة لـP وللبيانات الملتزمة. في مخرج Taproot الاعتيادي، يرمّز هذا الالتزام عادةً جذر Merkle لـtaptree يحمل مسارات صرف خفية. MATT يبنى على الآلية نفسها ويتضمّن حالة العقد في المفتاح كذلك، فتتحقق السلسلة فقط من صلاحية كل انتقال حالة دون تنفيذ منطق العقد. يأخذ الأوبكود بيانات الحالة، ومؤشر مخرج، ومفتاحًا عامًا، وtaptree اختيارية، ونمطًا. ثلاثة أنماط تفحص مخرجًا، ونمط منفصل يفحص مدخلًا. النمط الافتراضي يخصص كامل قيمة UTXO المدخل للمخرج المحدد. نمط الخصم يخصص جزءًا فقط يوازي مبلغ المخرج ويترك الباقي حرًا لمخرجات إضافية. نمط التجاهل يتحقق من السكربت والتزام البيانات دون تقييد المبلغ. ولأن النمطين الافتراضي والخصم يحفظان القيمة عبر المخرجات المفحوصة، يجب دفع رسوم المعاملة عبر مدخلات منفصلة تخصص لذلك؛ ويمكن أن يرافق العقد مدخل رسوم مخصص ومخرج فائض دون تعارض مع قيود العهد. هذا يمنع الحرق العرضي للأموال الممكن تحت مخططات عهد بدائية مثل OP_CTV أو SIGHASH_ANYPREVOUT، ويعالج قيدًا في عهود المعاملات الموقعة مسبقًا التي تحدد المبالغ سلفًا ولا تستوعب تعديلات رسوم ديناميكية أو سحبًا جزئيًا من الخزنة. وتتسع القدرة التعبيرية مجددًا عندما يقترن OP_CCV بـOP_CAT الذي يتيح تسلسل البايتات في Script. فالثنائي يمكنه بناء إثباتات Merkle والتحقق منها على السلسلة مقابل شجرة ثانية تحمل بيانات العقد لا سكربتات صرفه، ثم يُلزم المخرج التالي بالالتزام بالجذر المحدّث. وتتبع ذلك أنظمة أدلة الاحتيال: تُنفَّذ عملية حسابية طويلة خارج السلسلة، ولا تُكشف على السلسلة وتُتحقق منها إلا الخطوة المتنازع عليها مع مسارها عبر الشجرة الثنائية. ينبغي أولًا تجميع تلك العملية في تمثيل ثنائي خطوة بخطوة، وهي المشكلة التي يعمل عليها أداة الدوائر الثنائية elftrace. البناء يحاكي الـrollups المتفائلة على Ethereum، ونموذج أدلة الاحتيال نفسه يدعم كثيرًا من الجسور عبر السلاسل. كما أن التصميم يغني عن توقيعات Lamport لمرة واحدة وعن رسوم المعاملات الموقعة مسبقًا التي يعتمد عليها BitVM لفرض اتساق الحالة، ويمكنه إعادة إنتاج وظيفة الخزنة التي اقترحها OP_VAULT، وقد وصف مؤلفه James O'Beirne تصميم OP_CCV بأنه أكثر عمومية ومتانة ويتجاوز عمليًا مقترحه السابق.

طريق المراجعة المقبل

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