1. مقدمة

عقد السجل الخفي (DLC) هو إطار تنفيذ عقد مبني على أوراقل، اقترحه تادج درايجا من معهد ماساتشوستس للتكنولوجيا في عام 2018. يسمح DLC لطرفين بتنفيذ مدفوعات شرطية استنادًا إلى شروط محددة مسبقًا. يحدد الطرفان النتائج المحتملة، ويوقعانها مسبقًا، ويستخدمان هذه التوقيعات المسبقة لتنفيذ المدفوعات عندما يوافق أوراقل على النتيجة. وبالتالي، يمكن لـ DLC تمكين تطبيقات مالية لامركزية جديدة مع ضمان أمان إيداعات البيتكوين.

بالمقارنة مع شبكة البرق، لدى DLC مزايا هامة التالية:

• الخصوصية: يوفر DLC حماية خصوصية أفضل من شبكة البرق. تفاصيل العقود لا تُشترك إلا بين الأطراف المعنية ولا تُخزن على سلسلة الكتل. على العكس من ذلك، يتم توجيه معاملات شبكة البرق من خلال قنوات وعقد عامة، مما يجعل معلوماتها عامة وشفافة.
• تعقيد ومرونة العقود المالية: يمكن لـ DLC إنشاء وتنفيذ عقود مالية معقدة مباشرة على شبكة البيتكوين، مثل المشتقات والتأمين والمراهنة، في حين أن شبكة البرق تُستخدم أساسًا للدفعات سريعة ذات قيمة صغيرة ولا يمكنها دعم التطبيقات المعقدة.
• تقليل مخاطر الطرف العكسي: تُقفل أموال الـDLC في عقود توقيع متعددة ولا تُطلق إلا عند حدوث نتيجة لحدث محدد مُسبقًا، مما يُقلل من خطر عدم التزام أي طرف بالعقد. على الرغم من أن شبكة Lightning تُقلل من الحاجة إلى الثقة، إلا أنها تحمل مخاطر الطرف العكسي معينة في إدارة القناة وتوفير السيولة.
• لا حاجة لإدارة قنوات الدفع: لا تتطلب عمليات DLC إنشاء أو صيانة قنوات الدفع، التي تعتبر مركزية في شبكة البرق وتنطوي على إدارة معقدة ومكلفة من حيث الموارد.
• قابلية التوسع لحالات الاستخدام المحددة: بينما يزيد شبكة البرق إلى حد ما من قدرة عمليات بيتكوين، تقدم بيت تداول الآلي قابلية توسع أفضل للعقود المعقدة على بيتكوين.

على الرغم من أن DLCs تحمل مزايا كبيرة في نظام البيتكوين، إلا أن هناك بعض المخاطر والمشاكل لا تزال قائمة، مثل:

• مفتاح المخاطرة: هناك خطر تسرب أو فقدان مفاتيح Oracle الخاصة والأرقام غير القابلة للتكرار الملتزمة، مما قد يؤدي إلى فقدان أصول المستخدم.
• مخاطر الثقة المركزية: الاحتكار في البوابات يمكن أن يؤدي بسهولة إلى هجمات رفض الخدمة.
• مسألة استخراج المفتاح اللامركزي: إذا كان المورد لديه لامركزية، فإن عقد المورد يمتلك فقط حصصًا من المفتاح الخاص. ومع ذلك، فإن عقد المورد ذو اللامركزية لا يمكنه استخدام BIP32 مباشرة لاستخراج المفتاح بناءً على هذه الحصص من المفتاح الخاص.
• مخاطر التواطؤ: إذا تواطأت عقد الأوراق المالية بين أنفسها أو مع طرف واحد، فإن مشكلة الثقة بالعقود تبقى دون حل. إن آلية مراقبة موثوقة مطلوبة لتقليل الثقة في العقود.
• مشكلة تغيير الصيغة الثابتة: تتطلب التواقيع الشرطية مجموعة محددة وقابلة للتعداد من الأحداث قبل بناء العقد لبناء المعاملة. وبالتالي، استخدام بِت لإعادة توزيع الأصول يفرض قيودًا على الحد الأدنى من المبلغ، مما يؤدي إلى مشكلة تغيير الصيغة الثابتة.

لمعالجة هذه المسائل، يقترح هذا الورق العديد من الحلول والأفكار للتحسين للتخفيف من المخاطر والقضايا المرتبطة بـ DLCs، مما يعزز أمان نظام البيتكوين.

2. مبدأ DLC

عليس وبوب يدخلان في اتفاق رهان على ما إذا كانت قيمة الهاش للكتلة (n+k) فردية أم زوجية. إذا كانت فردية، تفوز عليس باللعبة ويمكنها سحب الأصول خلال الوقت t؛ إذا كانت زوجية، يفوز بوب باللعبة ويمكنه سحب الأصول خلال الوقت t. باستخدام DLC، يتم نقل معلومات الكتلة (n+k) عبر أوراق العمل لبناء توقيع مشروط، مضمناً أن الفائز الصحيح يحصل على جميع الأصول.

البدء: مُولِّد المنحنى الناحي هو G، وترتيبه هو q.

إنشاء مفتاح: يقوم المُورِّد، أليس، وبوب بتكوين مفاتيحهم الخاصة والعامة بشكل مستقل.

• مفتاح الأوراق المالية الخاص بالأوراق المالية هو z، ومفتاحها العام هو Z، مع الأخذ بعين الاعتبار أن Z=z⋅G;
• مفتاح أليس الخاص هو x، ومفتاحها العام هو X، مع الشرط X=x⋅G؛
• المفتاح الخاص لبوب هو y، ومفتاحه العام هو Y، مما يفي بالشرط Y=y⋅G.

صفقة التمويل: يقوم أليس وبوب بإنشاء صفقة تمويل معًا، وتأمين 1 بيتكوين لكل منهما في مخرج متعدد التوقيع 2 من 2 (مفتاح عام X ينتمي إلى أليس، والآخر Y إلى بوب).

صفقات تنفيذ العقود (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، يمكن للطرف الآخر استخدام المفتاح الخاص الأصلي لسحب الأصول.

تحسينات DLC 3.

3.1 إدارة المفاتيح

في بروتوكول DLC ، مفتاح الأوراق المالية للأوراق المالية والرقم العشوائي الملتزم أمران حاسمان. قد يؤدي تسرب أو فقدان مفتاح الأوراق المالية للأوراق المالية والرقم العشوائي الملتزم إلى القضايا الأمنية الأربعة التالية:

(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، لمنع التكرار أو فقدان العدم.

3.2 بوابة البيانات المُرْكزة

في DLC، يلعب دور الأوراق المالية دورًا حاسمًا حيث يوفر بيانات خارجية رئيسية تحدد نتيجة العقد. لتعزيز أمان هذه العقود، تتطلب الأوراق المالية اللامركزية. على عكس الأوراق المالية المركزية، توزع الأوراق المالية اللامركزية المسؤولية عن توفير البيانات الدقيقة والمضادة للتلاعب عبر عدة عقد مستقلة، مما يقلل من المخاطر المرتبطة بنقطة فشل واحدة ويقلل من احتمالية التلاعب أو الهجمات المستهدفة. مع الأوراق المالية اللامركزية، يمكن للعقود ذات العملات الرقمية تحقيق درجة أعلى من عدم الثقة والموثوقية، مما يضمن أن تعتمد تنفيذ العقد تمامًا على الحيادية للظروف المحددة مسبقًا.

يمكن استخدام تواقيع Schworr عتبة لتنفيذ Oracles متموقعة. تقدم تواقيع Schworr عتبة المزايا التالية:

• الأمان المحسّن: من خلال توزيع إدارة المفاتيح، تقلل التواقيع العتبية من مخاطر نقاط الفشل الفردية. حتى إذا تم التسلل إلى مفاتيح بعض المشاركين أو تعرضها للهجوم، يظل النظام بأكمله آمناً طالما أن الانتهاك لا يتجاوز الحد المحدد مسبقاً.
• التحكم الموزع: تمكّن تواقيع الحد الحدّيّة من التحكم الموزع في إدارة المفاتيح، ما يقضي على وجود كيان واحد لامساومة على جميع صلاحيات التوقيع، وبالتالي يقلل من المخاطر المرتبطة بتركيز السلطة.
• توفير محسن: يمكن إكمال التواقيع طالما أن عددًا معينًا من عقداء الأوراق المالية يتفقون، مما يزيد من مرونة النظام وتوافره. حتى إذا كان بعض العقداء غير متاحين، فإن موثوقية النظام العام لا تتأثر.
• المرونة والتوسع: يمكن لبروتوكول التوقيع العتبي تعيين عتبات مختلفة حسب الحاجة لتلبية متطلبات الأمان والسيناريوهات المختلفة. بالإضافة إلى ذلك، فهو مناسب للشبكات ذات المقياس الكبير، مما يوفر توسعًا جيدًا.
• المساءلة: يولد كل عقد أوراكل حصة توقيع بناءً على حصة مفتاحه الخاص، ويمكن للمشاركين الآخرين التحقق من صحة هذه الحصة التوقيع باستخدام حصة المفتاح العام المقابلة، مما يمكن من المساءلة. إذا كانت صحيحة، يتم تجميع هذه الحصص التوقيع لإنتاج توقيع كامل.

لذلك، يتمتع بروتوكول توقيع الحد الأقصى Schnorr بمزايا كبيرة في Oracles اللامركزية من حيث تحسين الأمان والموثوقية والمرونة والقابلية للتوسع والمساءلة.

3.3 ربط اللامركزية وإدارة المفاتيح

في تقنية إدارة المفاتيح، يمتلك الأوراقل مفتاحًا كاملاً z، ويمكنه، باستخدام BIP32 جنبا إلى جنب مع الزيادات ω، استنتاج عدد من المفاتيح الابنة z+ω^{(1)} والمفاتيح الحفيدة z+ω^{(1)}+ω^{(2)}. بالنسبة لأحداث مختلفة، يمكن للأوراقل استخدام مفاتيح خاصة حفيدة مختلفة z+ω^{(1)}+ω^{(2)} لتوليد توقيعات مقابلة σ لأحداث الرسالة المعنية.

في سيناريو Oracle اللامركزي ، يوجد n مشاركين ، ويتطلب توقيع العتبة مشاركين t + 1 ، حيث t

ومع ذلك، في سيناريو أوراق الرؤية اللامركزية، لا يظهر المفتاح الخاص الكامل z، وبالتالي لا يمكن استخدام تشتق المفتاح المباشر باستخدام BIP32. بمعنى آخر، لا يمكن دمج تكنولوجيا أوراق الرؤية اللامركزية وتكنولوجيا إدارة المفاتيح مباشرة.

الورقة “المشتقة المفتوحة للمفتاح لإدارة الأصول الرقمية للبلوكشين متعددة الأطرافيقترح نظام توزيع المفتاح الموزع في سيناريوهات التوقيع العتبي. الفكرة الأساسية مبنية على متعددات لاجرانج للتداول، حيث يربط حصة المفتاح الخاص z_i والمفتاح الخاص الكامل z علاقة التداول التالية:

إضافة الزيادة ω إلى كلا الجانبين من المعادلة ينتج عنها:

توضح هذه المعادلة أن مشاركة المفتاح الخاص z_i زائد الزيادة ω لا تزال تفي بعلاقة الاستيفاء مع المفتاح الخاص الكامل z plus ω. بمعنى آخر ، يفي المفتاح الخاص التابع z_i + ω والمفتاح الفرعي z + ω بعلاقة الاستيفاء. لذلك ، يمكن لكل مشارك استخدام مشاركة المفتاح الخاص z_i بالإضافة إلى الزيادة ω لاشتقاق مشاركة المفتاح الخاص التابع z_i + ω ، المستخدم لإنشاء مشاركات توقيع الطفل ، والتحقق من صحتها باستخدام المفتاح العام الفرعي المقابل Z + ω⋅G.

ومع ذلك، يجب أن ينظر المرء إلى BIP32 المقسّى وغير المقسّى. يأخذ BIP32 المقسّى المفتاح الخاصّ، ورمز السلسلة، والمسار كإدخال، ويقوم بتنفيذ SHA512، ويخرج بالزيادة ورمز سلسلة الطفل. بالمقابل، يأخذ BIP32 غير المقسّى المفتاح العامّ، ورمز السلسلة، والمسار كإدخال، وينفّذ SHA512، ويخرج بالزيادة ورمز سلسلة الطفل. في سيناريو التوقيع العتبي، لا يوجد المفتاح الخاص، لذلك يمكن استخدام BIP32 غير المقسّى فقط. أو، يمكن تطبيق BIP32 المقسّى بواسطة استخدام وظيفة تحويلية هومومورفية. ومع ذلك، تختلف وظيفة التحويلية الهومومورفية عن SHA512 وليست متوافقة مع BIP32 الأصلي.

3.4 OP-DLC: ثقة أوراق الاعتماد المصغرة لأوراكل

في دي إل سي، يتم تنفيذ العقد بين أليس وبوب بناءً على نتيجة توقيع الأوراق المالية، مما يتطلب مستوى معين من الثقة في الأوراق المالية. وبالتالي، يعتبر سلوك الأوراق المالية الصحيح أحد الافتراضات الرئيسية لعملية دي إل سي.

للحد من الثقة في الأوراق المالية، تم إجراء بحوث حول تنفيذ DLC استنادًا إلى نتائج n من الأوراق المالية، مما يقلل من الاعتماد على أوراق مالية واحدة.

• يتضمن النموذج "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:

• إذا قامت أوراقل بتوقيع النتائج بشكل غير صحيح، مما تسبب في تكبد أليس خسارة، يمكن لأليس استخدام نتائج الحساب الطبقي 2 الصحيحة لتحدي إذن أوراقل المسبق المتعهد في لعبة OP على السلسلة الأساسية بدون إذن. من خلال الفوز في اللعبة، يمكن لأليس تغليب العقوبة على أوراقل الخبيثة وتعويض خسارتها.
• بالمثل، يمكن لبوب وغيره من عقد الأوراق المالية الصادقة والمراقبين الصادقين من الطرف الثالث أيضًا تحدي المبادرة. ومع ذلك، لمنع التحديات الخبيثة، يجب على المتحدث أيضًا التعهد.

وبالتالي، يُيسَّر OP-DLC الرقابة المتبادلة بين عقد الأوراق، مما يقلل من الثقة الموضوعة في الآلهة. هذا الآلية تتطلب فقط مشارك واحد صادق ولديه تحمل للأخطاء بنسبة 99%، مما يعالج بشكل فعال مخاطر التواطؤ بين الآلهة.

3.5 أوبي-دلك + بِت في إم جسر مزدوج

عند استخدام DLC للجسور العابرة للسلاسل، يجب أن يحدث توزيع الأموال عند تسوية عقد DLC:

• يتطلب الإعداد المسبق من خلال CETs، مما يعني أن تفصيل تسوية الصندوق لـ DLC محدود، مثل 0.1 BTC في شبكة Bison. وهذا يثير قضية: يجب ألا تقتصر تفاعلات الأصول من الطبقة 2 على المستخدمين بتفاصيل الصندوق لـ DLC CETs.
• عندما تريد أليس تسوية أصولها في الطبقة 2، فإنه يُجبر على تسوية أصول المستخدم بوب في الطبقة 2 إلى الطبقة 1 أيضًا. وهذا يثير مشكلة: يجب أن يكون لكل مستخدم في الطبقة 2 حرية اختيار إيداعاتهم وسحوباتهم بشكل مستقل عن أفعال المستخدمين الآخرين.
• عليس وبوب يتفاوضان على الإنفاق. المشكلة هنا هي أنها تتطلب من الطرفين أن يكونا على استعداد للتعاون.

لذلك، لمعالجة المشكلة المذكورة، نقترح جسر OP-DLC + BitVM المزدوج. تتيح هذه الحلول للمستخدمين إيداع وسحب الأموال من خلال جسر BitVM غير المرخص له وكذلك من خلال آلية OP-DLC، مما يحقق التغيير بأي تفاصيل ويعزز السيولة.

في 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.

بيان:

1. تم نقل هذه المقالة من متوسط, بعنوان “تقنية بوابة: DLC واعتبارات تحسينها”. حقوق النسخ ملك للمؤلف الأصلي، بِتلَير. إذا كان هناك أي اعتراضات على هذه الإعادة طباعتها، يرجى الاتصال بالفريق بوابة التعلم. سيتولى الفريق ذلك وفقا للاجراءات ذات الصلة بأسرع ما يمكن.

2. تنويه: تعبر وجهات النظر والآراء المعبّر عنها في هذا المقال فقط عن وجهات النظر الشخصية للكاتب ولا تشكل أي نصيحة استثمارية.

3. تمت ترجمة النسخ الأخرى من المقال بفريق Gate Learn. بدون ذكرGate.io, الأبحاث المترجمة قد لا تُنسخ أو تُنشر أو تُسرق.