بالمقارنة مع شبكة البرق، لدى DLC مزايا هامة التالية:
الخصوصية: يوفر DLC حماية خصوصية أفضل من شبكة البرق. تفاصيل العقود لا تُشترك إلا بين الأطراف المعنية ولا تُخزن على سلسلة الكتل. على العكس من ذلك، يتم توجيه معاملات شبكة البرق من خلال قنوات وعقد عامة، مما يجعل معلوماتها عامة وشفافة.- تعقيد ومرونة العقود المالية: يمكن لـ DLC إنشاء وتنفيذ عقود مالية معقدة مباشرة على شبكة البيتكوين، مثل المشتقات والتأمين والمراهنة، في حين أن شبكة البرق تُستخدم أساسًا للدفعات سريعة ذات قيمة صغيرة ولا يمكنها دعم التطبيقات المعقدة.- تقليل مخاطر الطرف العكسي: تُقفل أموال الـDLC في عقود توقيع متعددة ولا تُطلق إلا عند حدوث نتيجة لحدث محدد مُسبقًا، مما يُقلل من خطر عدم التزام أي طرف بالعقد. على الرغم من أن شبكة Lightning تُقلل من الحاجة إلى الثقة، إلا أنها تحمل مخاطر الطرف العكسي معينة في إدارة القناة وتوفير السيولة.- لا حاجة لإدارة قنوات الدفع: لا تتطلب عمليات DLC إنشاء أو صيانة قنوات الدفع، التي تعتبر مركزية في شبكة البرق وتنطوي على إدارة معقدة ومكلفة من حيث الموارد.- قابلية التوسع لحالات الاستخدام المحددة: بينما يزيد شبكة البرق إلى حد ما من قدرة عمليات بيتكوين، تقدم بيت تداول الآلي قابلية توسع أفضل للعقود المعقدة على بيتكوين.على الرغم من أن DLCs تحمل مزايا كبيرة في نظام البيتكوين، إلا أن هناك بعض المخاطر والمشاكل لا تزال قائمة، مثل:
مفتاح المخاطرة: هناك خطر تسرب أو فقدان مفاتيح Oracle الخاصة والأرقام غير القابلة للتكرار الملتزمة، مما قد يؤدي إلى فقدان أصول المستخدم.- مخاطر الثقة المركزية: الاحتكار في البوابات يمكن أن يؤدي بسهولة إلى هجمات رفض الخدمة.- مسألة استخراج المفتاح اللامركزي: إذا كان المورد لديه لامركزية، فإن عقد المورد يمتلك فقط حصصًا من المفتاح الخاص. ومع ذلك، فإن عقد المورد ذو اللامركزية لا يمكنه استخدام BIP32 مباشرة لاستخراج المفتاح بناءً على هذه الحصص من المفتاح الخاص.- مخاطر التواطؤ: إذا تواطأت عقد الأوراق المالية بين أنفسها أو مع طرف واحد، فإن مشكلة الثقة بالعقود تبقى دون حل. إن آلية مراقبة موثوقة مطلوبة لتقليل الثقة في العقود.- مشكلة تغيير الصيغة الثابتة: تتطلب التواقيع الشرطية مجموعة محددة وقابلة للتعداد من الأحداث قبل بناء العقد لبناء المعاملة. وبالتالي، استخدام بِت لإعادة توزيع الأصول يفرض قيودًا على الحد الأدنى من المبلغ، مما يؤدي إلى مشكلة تغيير الصيغة الثابتة.لمعالجة هذه المسائل، يقترح هذا الورق العديد من الحلول والأفكار للتحسين للتخفيف من المخاطر والقضايا المرتبطة بـ DLCs، مما يعزز أمان نظام البيتكوين.
البدء: مُولِّد المنحنى الناحي هو G، وترتيبه هو q.
إنشاء مفتاح: يقوم المُورِّد، أليس، وبوب بتكوين مفاتيحهم الخاصة والعامة بشكل مستقل.
صفقات تنفيذ العقود (CET): يقوم أليس وبوب بإنشاء اثنين من CETs لإنفاق صفقة التمويل.
يُحسب الأوراقل الالتزام

ثم يقوم بحساب S و S′

ويبث (R، S، S′).
قام كل من أليس وبوب بحساب المفتاح العام الجديد المقابل له

التسوية: بعد ظهور الكتلة (n+k)-th، يولّد المُعرف النبيذي المجابهة s أو s′ بناءً على قيمة التجزئة لتلك الكتلة.
إذا كانت قيمة التجزئة للكتلة (n+k) عدد فردي، تقوم أوراقل بحسابه وبثه
إذا كانت قيمة التجزئة الهاش للكتلة (n+k) زوجية، يقوم المُعلن بحسابها وبثها
سحب: يمكن لأليس أو بوب سحب الأصول بناءً على s أو s′ المذاعة من الأوراقل.
إذا بثت Oracle s ، يمكن لأليس حساب المفتاح الخاص الجديد sk^{Alice} وسحب 2 بتكوين المقفلة
إذا بثت الأوراق s′، يمكن لبوب حساب المفتاح الخاص الجديد sk^{Bob} وسحب 2 BTC المقفلة
التحليل: تفي مفتاح التشفير الخاص الجديد sk^{Alice} الذي تم حسابه بواسطة آليس والمفتاح العام الجديد PK^{Alice} بعلاقة اللوغاريتم ال diskreet

وبالتالي، ستكون عملية سحب أليس ناجحة.
بالمثل، المفتاح الخاص الجديد sk^{Bob} الذي تم حسابه بواسطة بوب والمفتاح العام الجديد PK^{Bob} يحقق العلاقة اللوغاريتمية المتقطعة

وبالتالي، سيكون سحب بوب ناجحاً.
وَعلاوَةً على ذلك، إذا قامت الأوراقيل ببث s، فهو مفيد لأليس، ولكن ليس لبوب لأن بوب لا يمكنه حساب المفتاح الخاص الجديد المقابل sk^{Bob}. وبالمثل، إذا قامت الأوراقيل ببث s′، فهو مفيد لبوب، ولكن ليس لأليس، لأن أليس لا يمكنها حساب المفتاح الخاص الجديد المقابل sk^{Alice}. وأخيرًا، يغفل الوصف أعلاه عن القفل الزمني. يجب إضافة قفل زمني للسماح لطرف واحد بحساب المفتاح الخاص الجديد وسحبه في زمن t. وإلا، إذا تجاوز الزمن t، يمكن للطرف الآخر استخدام المفتاح الخاص الأصلي لسحب الأصول.
(1) فقد أوراق العمل z
إذا فقدت الأوراق المالية مفتاحها الخاص، فإن DLC لا يمكن أن تستوفي، مما يستلزم تنفيذ عقد استرداد DLC. لذلك، يتضمن بروتوكول DLC صفقة استرداد لمنع عواقب فقدان الأوراق المالية مفتاحها الخاص.
(2) تسرب مفتاح Oracle الخاص z
إذا تم تسرب مفتاح Oracle الخاص، فإن جميع عقود البت الخفية القائمة على هذا المفتاح الخاص تواجه خطر التسوية الاحتيالية. يمكن للمهاجم الذي يسرق المفتاح الخاص توقيع أي رسالة مرغوبة، مكتسبًا السيطرة الكاملة على نتائج جميع العقود المستقبلية. علاوة على ذلك، لا يتم تقييد المهاجم بإصدار رسالة واحدة موقعة فحسب بل يمكنه أيضًا نشر رسائل متعارضة، مثل توقيع قيمة التجزءة للكتلة (n+k) على أنها فردية وزوجية.
(3) تسرب أوراكل أو إعادة استخدام nonce k
إذا تسرب الأوراقي القيمة k، فإنه في مرحلة التسوية، بغض النظر عما إذا كان الأوراقي يبث s أو s′، يمكن للمهاجم حساب مفتاح الأوراقي الخاص z على النحو التالي:

إذا قامت الأوراق المالية بإعادة استخدام nonce k، فإنه بعد تسوية اثنين، يمكن للمهاجم حل نظام المعادلات استنادًا إلى تواقيع البث الخاصة بالأوراق المالية لاستنتاج مفتاح الأوراق المالية الخاص z في أحد السيناريوهات الأربعة المحتملة،
الحالة 1:

الحالة 2:

الحالة 3:

الحالة 4:

(4) أوراكل يفقد الرقم الترتيبي k
إذا فقدت الأوراق المالية الإلكترونية nonce k، فإن الـ DLC المقابل لا يمكن أن يُسوَّى، مما يستدعي تنفيذ عقد استرداد DLC.
لذلك، لتعزيز أمان مفتاح الخاص للأوراق المالية، من المستحسن استخدام BIP32 لاشتقاق مفاتيح الأطفال أو الأحفاد للتوقيع. بالإضافة إلى ذلك، لزيادة أمان العدم، يجب استخدام قيمة التجزئة k:=hash(z, counter) كعدم k، لمنع التكرار أو فقدان العدم.
يمكن استخدام تواقيع Schworr عتبة لتنفيذ Oracles متموقعة. تقدم تواقيع Schworr عتبة المزايا التالية:
في سيناريو Oracle اللامركزي ، يوجد n مشاركين ، ويتطلب توقيع العتبة مشاركين t + 1 ، حيث t- يتضمن النموذج "n-of-n" استخدام n من المهتمين لتوقيع العقد وتنفيذ العقد بناءً على نتائج جميع المهتمين. يتطلب هذا النموذج أن تكون جميع المهتمين متصلين بالإنترنت للتوقيع. إذا خرج أي مهتم عن الخدمة أو حدث اختلاف في النتائج، فإن ذلك يؤثر على تنفيذ عقد DLC. افتراض الثقة هنا هو أن جميع المهتمين صادقون.- يتضمن نموذج "k-of-n" استخدام n آلهة لتوقيع العقد، وتنفيذ العقد استنادًا إلى نتائج أي k من الآلهة. إذا تآمرت مزيد من k من الآلهة، فإن ذلك يؤثر على التنفيذ العادل للعقد. علاوة على ذلك، يُطلب عدد CETs المطلوبة في نموذج "k-of-n" هو C_n^k مرات ذلك لآلهة واحدة أو نموذج "n-of-n". الافتراض المتعلق بالثقة في هذا النموذج هو أنه على الأقل k من بين n من الآلهة صادقين.زيادة عدد الأوراق المعتمدين لا تحقق فحص الثقة في الأوراق لأنه بعد الإجراءات الخبيثة من قبل أوراق، الطرف المتأذي في العقد ليس لديه سبيل مفعل على السلسلة.
لذلك، نقترح OP-DLC، الذي يدمج آلية تحدي متفائلة في DLC. قبل المشاركة في إعداد DLC، يحتاج n مُعرفون إلى التعهد وبناء لعبة OP على السلسلة بدون إذن مسبقًا، ملتزمين بعدم القيام بأعمال خبيثة. إذا قام أي مُعرف بأعمال خبيثة، يمكن لأليس، بوب، أي مُعرف آخر صادق، أو أي مراقب صادق آخر تحدي. إذا فاز المتحدي في اللعبة، يعاقب النظام على السلسلة الخبيثة بمصادرة إيداعها. بالإضافة إلى ذلك، يمكن لـ OP-DLC أيضًا اعتماد نموذج "k-of-n" للتوقيع، حيث يمكن أن يكون قيمة k حتى 1. لذلك، يتم تقليل افتراض الثقة إلى الحاجة فقط إلى مشارك صادق واحد في الشبكة لبدء تحدي OP ومعاقبة نود خبيثة.
عند تسوية OP-DLC استنادا إلى نتائج الحساب من الطبقة 2:
في OP-DLC، يكون Oracle هو اتحاد BitVM، مع Alice كمستخدم عادي و Bob كاتحاد BitVM. عند إعداد OP-DLC، يسمح CETs المبنية بالإنفاق الفوري لإخراج Alice على الطبقة 1، بينما يتضمن إخراج Bob "لعبة DLC يمكن لـ Alice تحديها" مع فترة تأمين زمنية. عندما ترغب Alice في السحب:
إذا قام تحالف BitVM، الذي يعمل كمهيمن، بالتوقيع بشكل صحيح، يمكن لأليس سحب الأموال على الطبقة 1. ومع ذلك، يمكن لبوب سحب الأموال على الطبقة 1 بعد فترة القفل الزمني.- إذا قام تحالف BitVM، الذي يعمل كما الأوراق المالية، بالغش، مما يتسبب في خسارة لأليس، يمكنها تحدي UTXO لبوب. إذا كان التحدي ناجحًا، يمكن ضبط مبلغ بوب. ملاحظة: يمكن أيضًا لعضو آخر في تحالف BitVM بدء التحدي، ولكن أليس، كونها الطرف المتضرر، هي الأكثر دوافعًا للقيام بذلك.- إذا قام تحالف BitVM، الذي يعمل كمُمثل للمورد، بالغش، مما يتسبب في خسارة لـ بوب، يمكن لعضو نزيه في تحالف BitVM تحدي "لعبة BitVM" لتعاقب عقد Oracle الغشاش.وعلاوة على ذلك، إذا كان المستخدم أليس يرغب في سحب من الطبقة 2 ولكن الـ CETs المُعدة مسبقًا في عقد OP-DLC لا تُطابق المبلغ، يمكن لأليس اختيار الطرق التالية:
سحب من خلال BitVM، مع مشغل BitVM يتحمل المبلغ على الطبقة 1. يفترض جسر BitVM وجود مشارك واحد على الأقل صادق في اتحاد BitVM.- سحب من خلال CET محدد في OP-DLC، مع الباقي يتم تمويله من قبل مشغل BitVM على الطبقة 1. سحب من خلال OP-DLC سيغلق قناة الـ DLC، ولكن الأموال المتبقية في قناة الـ DLC ستنتقل إلى بركة طبقة BitVM 1، دون إجبار مستخدمي الطبقة 2 الآخرين على السحب. يفترض جسر OP-DLC وجود مشارك واحد على الأقل صادق في القناة.- يتفاوض أليس وبوب على الإنفاق دون تدخل مورد المعلومات، مما يتطلب التعاون من بوب.لذلك، يوفر جسر الأوبي-دي إل سي + بِت في إم المزايا التالية:
تحل BitVM مشكلة تغيير قناة DLC، وتقلل من عدد CETs المطلوبة، ولا تتأثر بحبيبات صندوق CET؛- من خلال دمج جسر OP-DLC مع جسر BitVM، يوفر للمستخدمين قنوات متعددة للإيداع والسحب، مما يعزز تجربة المستخدم؛- ضبط تحالف BitVM كل من بوب والمورد، واستخدام آلية OP، يقلل من الثقة في المورد؛- دمج السحب الزائد من قناة DLC في بركة جسر BitVM يعزز استخدام الأموال.## 4. الاستنتاجظهرت DLC قبل تنشيط Segwit v1 (Taproot) وتم دمجها بالفعل مع الشبكة البرقية، مما يسمح بتمديد DLC لتحديث وتنفيذ عقود مستمرة داخل نفس قناة DLC. باستخدام تقنيات مثل Taproot وBitVM، يمكن تنفيذ المزيد من التحققات والتسويات اللاحقة للعقود خارج السلسلة داخل DLC. بالإضافة إلى ذلك، من خلال دمج آلية التحدي OP، يمكن تقليل الثقة في Oracles.
تنويه: تعبر وجهات النظر والآراء المعبّر عنها في هذا المقال فقط عن وجهات النظر الشخصية للكاتب ولا تشكل أي نصيحة استثمارية.
تمت ترجمة النسخ الأخرى من المقال بفريق Gate Learn. بدون ذكرGate.com, الأبحاث المترجمة قد لا تُنسخ أو تُنشر أو تُسرق.





