عقود البيتكوين: شرح تفصيلي لمقترح OP_VAULT (BIP 345)
تستمر رحلتنا في استكشاف عالم عقود البيتكوين المعقد والمبتكر. هذا هو المقال الرابع ضمن سلسلتنا المخصصة للغوص العميق في مقترحات العقود الفردية التي بلغت درجة من النضج تستدعي تحليلاً مفصلاً. اليوم، نسلط الضوء على مقترح OP_VAULT، الذي قدمه جيمس أوبيرن في مقترح تحسين البيتكوين رقم 345 (BIP 345)، وانضم إليه لاحقًا جريج ساندرز كمؤلف مشارك. يهدف هذا المقترح بشكل أساسي إلى تطبيق مفهوم “الخزائن” (Vaults) في شبكة البيتكوين، معتمدًا على وظائف إضافية مثل CTV (CheckTemplateVerify) أو ما يماثلها لإكمال بناء الخزينة بشكل فعال.
ما هي خزينة البيتكوين (Bitcoin Vault) وما الغرض منها؟
قبل الخوض في تفاصيل كيفية عمل مقترح OP_VAULT، من الضروري فهم الهدف الأساسي من بناء الخزائن في سياق البيتكوين. الغرض الجوهري من الخزينة هو تعزيز أمان تخزين عملات البيتكوين الخاصة بك بشكل كبير. يتم تحقيق ذلك من خلال إدخال عنصر “فترة التأخير” (Delay Period) عند أي محاولة لإنفاق الأموال من الخزينة.
بدلاً من القدرة على إرسال عملات البيتكوين الخاصة بك مباشرة من الخزينة إلى أي وجهة، تفرض الخزينة قيودًا بحيث لا يمكن إرسال الأموال إلا إلى عنوان “مرحلي” أو “منطقة وسطى” (Middle Ground Address). عندما تكون العملات المسحوبة من الخزينة في هذه الحالة الوسطى، يمكن إنفاقها في أي وقت ولكن فقط باتجاه واحد: إلى محفظة تخزين بارد عميق (Deep Cold Storage) تحت سيطرتك الكاملة. من الناحية المثالية، يكون هذا التخزين البارد عبارة عن نظام توقيع متعدد (Multisig) موزع جغرافيًا لزيادة الأمان. بعد انقضاء فترة قفل زمني محددة مسبقًا (Timelock)، يمكن بعد ذلك إنفاق العملات من العنوان المرحلي إلى الوجهة النهائية المقصودة.
تخيل هذا السيناريو: إذا تمكن مهاجم من الوصول إلى المفتاح الذي يسمح ببدء عملية السحب من الخزينة، فلن يتمكن من سرقة الأموال على الفور. بدلاً من ذلك، سيتم نقل الأموال إلى العنوان المرحلي، مما يمنحك (المالك الحقيقي) نافذة زمنية (فترة التأخير) لاكتشاف محاولة السرقة. خلال هذه الفترة، يمكنك استخدام مفتاح “الاسترداد” الخاص بك لإرسال الأموال من العنوان المرحلي إلى محفظة التخزين البارد الآمنة الخاصة بك، وبالتالي إحباط محاولة السرقة.
القيود والتحديات في الحلول الحالية (المعاملات الموقعة مسبقًا)
من الممكن تقنيًا تحقيق شيء مشابه للخزائن باستخدام “المعاملات الموقعة مسبقًا” (Pre-signed Transactions)، لكن هذا النهج يأتي مع درجة عالية جدًا من التعقيد وعدم الكفاءة ونقص المرونة، بالإضافة إلى مخاطر فقدان الأموال.
يتطلب استخدام المعاملات الموقعة مسبقًا اتخاذ قرارات حاسمة مسبقًا، مثل:
- تحديد المبلغ الدقيق الذي سيتم سحبه في كل مرة.
- تحديد رسوم المعاملات (Feerate) التي ستدفعها معاملات السحب من الخزينة.
- تحديد العنوان المرحلي الذي ستذهب إليه الأموال قبل السحب الكامل.
بعد ذلك، يجب عليك حذف المفاتيح الخاصة المستخدمة للتوقيع المسبق على كل هذه المعاملات بشكل آمن، وهي عملية حساسة للغاية بحد ذاتها.
المشكلة الكبيرة في هذه البنية، بصرف النظر عن القيود الشاملة للمبالغ والرسوم المحددة مسبقًا، هي أن إعادة استخدام العناوين (Address Reuse) ليست آمنة. في مخطط خزينة المعاملات الموقعة مسبقًا، يتم إرسال الودائع إلى نفس العنوان المستخدم للتوقيع المسبق على معاملة الخزينة الأولية. ونظرًا لأن المفاتيح المرتبطة بهذا العنوان وجميع المفاتيح الأخرى المعنية يتم حذفها بعد توقيع معاملات الخزينة، فإن أي أموال يتم إيداعها لاحقًا في نفس العنوان ستُفقد إلى الأبد. إعادة استخدام العناوين ممارسة سيئة بشكل عام، ولكن لا يمكنك منع شخص آخر من إرسال أموال إلى عنوان استخدمته سابقًا.
بالإضافة إلى ذلك، يستلزم كل إيداع جديد في خزينة قائمة على المعاملات الموقعة مسبقًا إعدادًا جديدًا بالكامل: إنشاء مفاتيح جديدة، وإجراء مراسم التوقيع المسبق مرة أخرى لمجموعة جديدة من المعاملات، والتأكد من حذف مجموعة المفاتيح الجديدة بشكل آمن، وإدارة التخزين المناسب لكل هذه المعلومات بما في ذلك النسخ الاحتياطية المتكررة. كل إيداع منفرد يخلق فرصة لحدوث خطأ ما أثناء إعداد الخزينة، وكل إيداع يوفر فرصة لشخص قد اخترق نظامًا أو جهازًا منذ الإيداع الأخير لمحاولة سرقة أموالك.
تعتبر خزائن المعاملات الموقعة مسبقًا بناءً مرهقًا ومعقدًا، وتمثل درجة من التعقيد تجعل كل استخدام لها ينطوي على مخاطر غير ضئيلة لحدوث خطأ يؤدي إلى فقدان الأموال.
يمكن إجراء بعض التحسينات باستخدام عقود مثل CTV، مثل التخلص من الحاجة إلى حذف المفاتيح بشكل آمن، ولكن بقية التعقيدات والمخاطر لا تزال قائمة. يجب أن تظل المبالغ والرسوم محددة مسبقًا. ولا تزال إعادة استخدام العناوين يمكن أن تؤدي إلى فقدان الأموال.
كيف يعمل مقترح OP_VAULT؟
يعتمد مقترح OP_VAULT بشكل أساسي على تقنية Taproot. هذا يعني أن التصميم بأكمله يستخدم Tapscript ويعتمد على وجود هياكل Taptrees ومسار إنفاق السكربت (Script Spending Path). كما يعتمد أيضًا على استخدام CTV (أو وظائف مشابهة مثل TXHASH) لبناء خزينة كاملة الوظائف.
المقترح في الواقع يتكون من رمزين تشغيليين (Opcodes) جديدين:
OP_VAULT: يستخدم لبدء عمليات السحب من الخزينة.OP_VAULT_RECOVER: يستخدم لسحب الأموال التي تم بدء سحبها (في الحالة المرحلية) إلى محفظة الاسترداد العميقة.
تكمن الفكرة في بناء شجرة Taproot (Taptree) تحتوي على مسارات تستخدم OP_VAULT لعمليات السحب، ومسارات أخرى تستخدم OP_VAULT_RECOVER لسحب أي أموال في منتصف عملية السحب إلى محفظة باردة آمنة. هذه الـ Taptree هي خزانتك.
آلية عمل OP_VAULT
يعمل OP_VAULT عن طريق فرض قيود صارمة على شكل المخرجات (Outputs) في المعاملة التي تنفق عملة مقيدة بـ OP_VAULT. يتوقع هذا الرمز التشغيلي وجود العناصر التالية في بيانات الشاهد (Witness):
- جسم سكربت الورقة (Tapleaf script body) المراد تحديثه.
- عدد قطع البيانات اللازمة لتحديث السكربت.
- مؤشر المخرج (Output index) المخصص للسحب.
- مؤشر المخرج الخاص بأي أموال تعود مرة أخرى إلى الخزينة.
- مبلغ الساتوشي (Amount of satoshis) الذي يعود إلى الخزينة.
يضمن OP_VAULT أن المبلغ الصحيح من الأموال المرسلة مرة أخرى إلى الخزينة يتطابق مع ما هو متوقع، وأن سكربت المخرج لهذا المخرج (الذي يعيد الأموال للخزينة) مطابق تمامًا لسكربت الـ Taptree الذي يتم الإنفاق منه. بالإضافة إلى ذلك، يأخذ OP_VAULT جسم سكربت الورقة ومتغيرات البيانات المقدمة في الشاهد، ويجمعها لتكوين سكربت ورقة Tapleaf كامل جديد. ثم يتأكد من أن المخرج المحدد للسحب يحتوي على سكربت مطابق لـ Taptree المدخل الذي يتم إنفاقه، باستثناء أن ورقة Tapleaf التي يتم الإنفاق منها يتم استبدالها بسكربت الورقة الجديد الذي تم تجميعه من بيانات الشاهد.
هذه الخدعة الأخيرة ممكنة لأنه للتحقق من أن ورقة Tapleaf هي جزء من الـ Taptree في المقام الأول، يجب أن تكون العقد الداخلية لشجرة Merkle موجودة للتحقق. يضمن تجزئة (Hashing) السكربت الجديد مع الأوراق الداخلية المعروفة لبقية الشجرة أنه تم تغيير ورقة الشجرة تلك فقط. يتم تحديد قالب السكربت (Script Template) الذي يمكن ملؤه ديناميكيًا في وقت إنشاء الخزينة. بالنسبة لحالة استخدام الخزينة النموذجية، سيكون قالب السكربت ببساطة مسار إنفاق CTV مقيد بوقت (Timelocked) مع توفير الهاش عند بدء السحب.
آلية عمل OP_VAULT_RECOVER
يعتبر OP_VAULT_RECOVER أبسط بكثير. يأخذ هذا الرمز التشغيلي هاش (Hash) لسكربت الاسترداد، ومؤشر مخرج لمعاملة الاسترداد. يجب أن يحتوي هذا المخرج على سكربت يتطابق تمامًا مع الهاش المحدد مسبقًا، ويجب أن يذهب كامل مبلغ الأموال الموجود في المدخل الذي يتم استرداده إلى هذا المخرج المحدد.
بوابات التفويض (Authorization Gates)
يمكن “حماية” كلا السكربتين (OP_VAULT و OP_VAULT_RECOVER) بسكربت تفويض إضافي. على سبيل المثال، قد يتطلب الأمر توفير توقيع من مفتاح معين لبدء عملية سحب أو استرداد. هذا له بعض المقايضات. إذا فقدت مفتاح تفويض الاسترداد، فلن تتمكن بعد الآن من بدء معاملة استرداد في حالة سرقة مفتاح بدء السحب الخاص بك. ومع ذلك، فإنه يسمح لك ببدء الاسترداد من عدة UTXOs (مخرجات معاملات غير منفقة) للخزينة في نفس المعاملة بسبب تحديد المخرجات المقابلة لكل مدخل يدويًا.
ما هي فوائد واستخدامات OP_VAULT؟
الاستخدام الأكثر وضوحًا هو بناء “الخزائن”. يعالج OP_VAULT بشكل نظيف وفعال جميع القيود الرئيسية لخزائن المعاملات الموقعة مسبقًا أو حتى الخزائن القائمة على CTV. فهو يزيل الحاجة إلى:
- تحديد فئات مبالغ مقيدة مسبقًا.
- تحديد رسوم المعاملات مسبقًا.
- القلق بشأن مخاطر إعادة استخدام العناوين.
- التعامل مع مشكلة أمنية حساسة مثل حذف المفاتيح في كل مرة تقوم فيها بالإيداع.
ومع ذلك، فإن مرونة OP_VAULT تتجاوز مجرد بناء الخزائن. على الرغم من أن الخزائن كانت حالة الاستخدام المقصودة عند تصميم المقترح، إلا أنه يقدم مجموعة وظائف أعم وأكثر عمومية. فهو يضمن بشكل أساسي أن هيكل الـ Taptree ينتقل فعليًا إلى الـ UTXO التالي عندما ترغب في ذلك، مع شروط خروج محددة مسبقًا تتمتع بدرجة معينة من المرونة.
تطبيقات محتملة أخرى: Drivechains
يمكنك بناء شيء قريب جدًا من مفهوم “Drivechain” باستخدام OP_VAULT. تخيل إنشاء قالب خزينة يتضمن قفلًا زمنيًا طويلاً جدًا، ربما يتراوح بين 3 إلى 6 أشهر (مماثل لفترات السحب في Drivechains). لا تضع أي بوابة تفويض لأي سكربت واجعل القالب عامًا ومتاحًا للجميع.
الآن يمكن للأشخاص ببساطة إيداع الأموال في هذه “السلسلة الجانبية” (Drivechain) عن طريق إرسال الأموال إلى سكربت الخزينة هذا. يمكن لأي شخص اقتراح عملية سحب ببساطة عن طريق الإنفاق من مسار OP_VAULT وتضمين هاش CTV لمعاملة السحب الخاصة به. يمكن للمُعدّنين (Miners) فرض قواعد هذه السلسلة الجانبية ببساطة عن طريق رفض تعدين أي معاملات سحب غير صالحة. وإذا قام مُعدِّن خبيث بتعدين معاملة بدء سحب ضارة، يمكن للمُعدِّن النزيه التالي ببساطة إعادة الأموال إلى الخزينة باستخدام مسار الاسترداد.
هذا ما يمكن فعله فقط باستخدام قالب سكربت مطابق تمامًا لما هو موصى به في BIP. لكن قالب السكربت المحدد لعمليات السحب يمكن أن يكون تعسفيًا، وبالتالي فهو يحتمل أن يكون عامًا جدًا من حيث أنواع العقود الذاتية الدائمة (Perpetuating Self Contracts) التي يمكن لـ OP_VAULT تمكينها.
مخاوف وأفكار ختامية
من الواضح أن OP_VAULT يحقق هدف تمكين خزائن بيتكوين قوية وآمنة لا تأتي مع القيود والتعقيدات والمخاطر المصاحبة لخزائن المعاملات الموقعة مسبقًا (أو حتى خزائن العقود الأبسط مثل تلك القائمة على CTV). ومع ذلك، في سياق تحقيق هذا الهدف الأصلي، انتهى الأمر بالمقترح إلى تقديم مجموعة واسعة ومعممة إلى حد ما من الوظائف.
سيؤدي المقترح بالتأكيد إلى تمكين وظيفة خزينة سلسة وآمنة نسبيًا، ولكنه يفتح أيضًا العديد من الأبواب الأخرى لتطبيقات قد تكون مثيرة للجدل. مفهوم Drivechains، على سبيل المثال، هو شيء يأتي بدرجة كبيرة من المخاطر التي تتمحور حول القيمة القابلة للاستخراج بواسطة المُعدّنين (Miner Extractible Value – MEV). يجب موازنة الجوانب السلبية لتمكين مثل هذه الوظائف، وقضايا الحوافز والعواقب المحتملة التي يمكن أن تترتب عليها، مقابل الجانب الإيجابي المتمثل في تمكين بناء خزينة جيدة التصميم وآمنة للمستخدمين.
يعتبر OP_VAULT مقترحًا ناضجًا نسبيًا، وقد خضع للكثير من التدقيق والمراجعة. ومع ذلك، لا ينبغي التعامل باستخفاف مع درجة الوظائف التي يمكّنها. يتطلب أي تغيير في بروتوكول البيتكوين، خاصة التغييرات التي توسع من قدراته التعبيرية بشكل كبير، نقاشًا مجتمعيًا واسعًا وتوافقًا دقيقًا لضمان فهم جميع الآثار المترتبة، الإيجابية والسلبية، قبل التفكير في التنشيط.
في الختام، يمثل OP_VAULT خطوة هامة إلى الأمام في تصميم حلول تخزين أكثر أمانًا ومرونة للبيتكوين، لكنه يطرح أيضًا أسئلة مهمة حول مستقبل قدرات العقود الذكية على الشبكة والمخاطر المحتملة المرتبطة بها. إن فهم هذه المقايضات أمر بالغ الأهمية لمجتمع البيتكوين أثناء تقييمه لمثل هذه المقترحات.
نُشر هذا المقال بعنوان “Bitcoin Covenants: OP_VAULT (BIP 345)” لأول مرة على Bitcoin Magazine وكتبه Shinobi.
