منذ أسبوعين، أطلق جيريمي روبين اقتراحًا بعنوان اتفاقيات مشفرة غير مكلفة (FE = التشفير الوظيفي). بالنظر إلى النقاش المستمر حول مقترحات الاتفاقيات لبيتكوين خلال العامين الماضيين، يعتبر اقتراحه خيارًا عمليًا جديدًا. تتطلب جميع مقترحات الاتفاقيات حتى الآن عملية تفرع ناعم (أكواد فعلية)، أو تطوير وتطبيق التشفير غير المثبت (التشفير الوظيفي)، أو تكلفة مالية مرتفعة بشكل غير معقول للاستخدام (كوليدر سكريبت).
نظام العمل بالاتفاقيات عبر الأوراكل
لا يحتاج اقتراح جيريمي إلى تفريع ناعم، ولا يفرض تكلفة مرهقة وغير عملية على المستخدمين. التنازل لمثل هذه القدرة هو نموذج أمني مختلف جذريًا. باستخدام نظام من الأوراكل، وروابط BitVM القادرة على الاستقطاب، يمكن محاكاة الاتفاقيات على بيتكوين في الوقت الحالي.
الأوراكل
الجزء الأول من النظام هو بالطبع الأوراكل التي تفرض شروط الاتفاقيات المختلفة. هذا إعداد بسيط نسبيًا، وهو حجر البناء الأول الضروري لاقتراح جيريمي. يتحكم الأوراكل في الصناديق في هذا النظام، ويؤتمن على تنفيذ شروط الاتفاقية. تحتاج إلى أن لا يكون الأوراكل مضطرًا لمتابعة شروط الاتفاقية محليًا لكل عملة يحتفظ بها. هذا يثير مخاطرة الحالة حيث إذا تم تلف قاعدة بيانات الأوراكل أو فقدها فإنه لا يعرف كيفية التعامل مع التنفيذ الصحيح لعملات الجميع. لتفادي هذه المشكلة، يستخدم جيريمي Taproot.
يمكن تعديل المفاتيح القائمة على Schnorr باستخدام تجزئة البيانات لتعديل مفتاح عام. يتيح ذلك تعديل المفتاح الخاص المقابل ليكون قادرًا على التوقيع للمفتاح المعدل، وكذلك إثبات أن أي بيانات استخدمت لتعديل المفتاح العام ملتزمة بذلك المفتاح. يسمح للأوراكل بتوليد مفتاح، ثم يتيح للمستخدم تعديل هذا المفتاح ببرنامجه الخاص بالاتفاقية لتسهيل الالتزام بما يُفترض أن ينفذه الأوراكل مع إبقاء عبء تخزين تلك المعلومات على المستخدم.
يمكن أيضًا تخصيص الأوراكل بشكل اتحادي من أجل تقليل الثقة المطلوبة في جهة واحدة لتنفيذ الأمور. من هنا، يمكن للمستخدمين ببساطة تحميل العنوان الناتج، وكلما أرادوا تنفيذ الشرط، التوجه إلى الأوراكل (أو الأوراكل) مع معاملة الصرف، برنامج الأوراكل، وبيانات الشاهد الضرورية لإثبات أن المعاملة المقدمة إلى الأوراكل تفي بشروط الاتفاقية. إذا كانت المعاملة صالحة وفقًا لقواعد الاتفاقية، يوقع الأوراكل عليها.
بالنسبة لأي اتفاقية بسيطة حيث تكون النتائج معروفة مسبقًا، مثل CHECKTEMPLATEVERIFY (CTV)، يمكن للمستخدمين على الفور جعل الأوراكل يوقع على المعاملات التي تفرض الاتفاقية وتأخير استخدامها حتى الضرورة.
سيناريو مهم يجب مراعاته وهو الاتفاقيات المرتكزة على الحالة، مثل الروابط، التي تتقدم بانتظام وتحتوي على حالة فعلية (الرصيد الحالي للمستخدمين) يجب تتبعها. في حالة هذه الاتفاقيات، يجب أن تلتزم المعاملات التي يوقع عليها الأوراكل بالحالة الحالية للاتفاقية باستخدام OP_RETURN حتى يتمكن الأوراكل من التحقق بكفاءة من كل عملية تحديث للروابط أو للأنظمة الأخرى من دون الحاجة إلى تحميل بيانات الشاهد للتاريخ الكامل. هذا لتجنب أن يضطر الأوراكل إلى تخزين الحالة محليًا بنفسهم، مما يخلق مخاطر.
على المدى الطويل، يمكن تحسين متطلبات البيانات للأوراكل باستخدام إثباتات المعرفة الصفرية، حتى يتمكن الأوراكل ببساطة من التحقق من إثبات أن المعاملة التي يُطلب منهم التوقيع عليها تتبع قواعد الاتفاقية من دون الحاجة إلى التحقق من بيانات الشاهد الخام للاتفاقيات الأكبر والأكثر تعقيدًا. رغم ذلك، في حالة الأنظمة مثل الروابط، يجب توخي الحذر عند تصميمها لضمان أن البيانات المطلوبة لمغادرة النظام متاحة للمستخدمين حتى تكون بحوزتهم إذا احتاجوا إلى الاتصال بالأوراكل مباشرة لاستعادة أموالهم.
الرابط BitVM
حتى الآن، النظام بالكامل يعتمد على الثقة. أنت بشكل أساسي تعطي أموالك لشخص آخر وتأمل أن يكون موثوقًا في تنفيذ شروط الاتفاقيات العشوائية. من خلال تعديل النظام أعلاه قليلًا، يمكن تأمينه بحافز اقتصادي للعملة الرقمية بدلاً من الثقة الصافية.
تم وصف كيف يجب استخدام OP_RETURN لتتبع الحالة للاتفاقيات الحالة. يمكن أيضًا استخدام OP_RETURN لنشر بيانات الشاهد لأي معاملة اتفاقية لإثبات أن الشروط تم الوفاء بها بشكل صحيح.
يمكن بناء دائرة BitVM للتحقق مما إذا كانت معاملة موقعة من قبل الأوراكل تتطابق بنجاح مع شروط الاتفاقية التي يفرضها. تذكر أن المفتاح نفسه الذي تم إنتاجه والأموال المرسلة إليه يلتزم بالشروط لأي اتفاقية يتم تنفيذها. أي أن البيانات، بالإضافة إلى معاملة يتم إنفاقها من العنوان، يمكن إدخالها في مثيل BitVM.
يمكن بعد ذلك أن يُطلب من الأوراكل تقديم رابطة ضمان مع مشغل BitVM (الذي يجب عليه أيضًا تقديم رابطة ليطالب بها الأوراكل إذا تم اتهامهم بشكل خاطئ). بهذه الطريقة، طالما أن قيمة الضمان أكبر من القيمة المأمنة في الاتفاقيات من قبل الأوراكل، يمكن استخدام النظام بأمان. لن يكون هناك طريق للأوراكل لانتهاك شروط اتفاقية يطبقها من دون فقدان الأموال بشكل إجمالي.
المقايضات
هناك مقايضات واضحة هنا أسوأ ماديًا من مجرد تنفيذ الاتفاقيات في قواعد التوافق. أولًا، يجب أن يكون الأوراكل متصلاً وقابلاً للوصول للاستفادة من الاتفاقيات التي يفرضها الأوراكل. باستثناء الاتفاقيات الموقع عليها مسبقًا مثل CTV، إذا كان الأوراكل غير متصل عندما يحتاج المستخدمون إلى فرض اتفاقية، فلن يتمكنوا من فعل ذلك. يجب أن يكون الأوراكل حاضرًا للتوقيع.
ثانيًا، يمكن أن تصبح متطلبات السيولة للضمانات الأوراكل ضخمة إذا تم اعتماد النظام على نطاق واسع. يجعل ذلك غير فعال بشكل لا يصدق مقارنة بالتطبيق الأصلي للاتفاقيات على مستوى التوافق.
أخيرًا، البيانات الإضافية التي يجب نشرها على السلسلة من أجل عمل نظام الضمان BitVM أقل كفاءة في استخدام مساحة الكتل مقارنة بتطبيقات الاتفاقيات الأصلية.
بشكل عام، الاقتراح ليس بالكفاءة والأمن للاتفاقيات الأصلية. من ناحية أخرى، إذا انتهى بنا الأمر في أسوأ السيناريوهات بتكوين مبكر، فإن هذه طريقة فعالة لإدخال الاتفاقيات في بيتكوين دون الاعتماد على التشفير غير المثبت أو التكاليف غير العملية المفروضة على المستخدمين النهائيين.
لقد أعطانا جيريمي خيار أسوأ السيناريوهات لتوسيع مساحة التصميم لما يمكن بناؤه على البيتكوين.
الأسئلة الشائعة
- ما هو الجديد في اقتراح جيريمي روبين للاتفاقيات في بيتكوين؟
اقتراح جيريمي لا يتطلب تفريعات ناعمة ولا يفرض تكلفة مرهقة على المستخدمين. يستخدم نظام الأوراكل وروابط BitVM لمحاكاة الاتفاقيات بطرق جديدة مع نموذج أمني مختلف.
- ما هي دور الأوراكل في النظام المقترح؟
الأوراكل تتولي مسؤولية تنفيذ شروط الاتفاقيات وتمتلك القدرة على تجميل التواقيع للتأكد من أن المعاملات تتطابق مع شروط الاتفاقية، مما يقلل من حاجتها لتخزين حالة البيانات محليًا.
- ما هي تحديات المقترح مقارنة بالاتفاقيات الأصلية في بيتكوين؟
تشمل التحديات الحاجة للأوراكل أن تكون متصلة للوصول إليها، متطلبات عالية للسيولة لروابط الأوراكل، واستخدام أقل كفاءة لمساحة الكتل مقارنة بتطبيقات الاتفاقيات الأصلية.
