تحليل مبدأ DLC واعتبارات التحسين

العنوان الأصلي: "تقنية Bitlayer الأساسية: المحتوى القابل للتنزيل (DLC) واعتبارات التحسين الخاصة به"

المؤلف: lynndell & Mutourend، مجموعة أبحاث Bitlayer

1. مقدمة

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

بالمقارنة مع Lightning Network، يتمتع المحتوى القابل للتنزيل (DLC) بالمزايا الهامة التالية:

• الخصوصية:

  • الخصوصية:

    strong >يتفوق المحتوى القابل للتنزيل (DLC) على شبكة Lightning Network من حيث حماية الخصوصية. تتم مشاركة تفاصيل العقد فقط بين المشاركين و لن يتم تخزينها على blockchain. وفي المقابل، يتم توجيه معاملات الشبكة المسرّعة عبر القنوات والعقد العامة، وتكون معلوماتها مفتوحة وشفافة؛

  • تعقيد ومرونة العقود المالية:

  • strong>يمكن للمحتوى القابل للتنزيل (DLC) إنشاء وتنفيذ عقود مالية معقدة مباشرة على شبكة Bitcoin، مثل عقود المشتقات والتأمين والمقامرة، بينما تُستخدم الشبكة المسرّعة بشكل أساسي في المعاملات الصغيرة السريعة المدفوعات ولا يمكنها دعم التطبيقات المعقدة؛

    < /li>

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

  • لا حاجة لإدارة قنوات الدفع:< /strong >لا تتطلب عمليات المحتوى القابل للتنزيل (DLC) إنشاء قنوات دفع أو صيانتها، والتي تعد مكونًا أساسيًا في شبكة Lightning Network. إن إدارة القنوات معقدة وتستهلك الموارد.

  • < قوي>قابل للتطوير لحالات استخدام محددة الأداء: تعمل الشبكة المسرّعة على تحسين إنتاجية معاملات Bitcoin إلى حد ما، بينما يوفر المحتوى القابل للتنزيل (DLC) قابلية توسع أفضل فيما يتعلق بالعقود المعقدة على Bitcoin.

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

  • الخطر الرئيسي:المفتاح الخاص لـ Oracle والرقم العشوائي الموعود معرضان لخطر التسريب أو الضياع، مما يؤدي إلى فقدان أصول المستخدم؛

  < li>

  مخاطر الثقة المركزية:يمكن أن تؤدي مشكلة المركزية لأجهزة Oracle بسهولة إلى هجمات رفض الخدمة؛

  • لا يمكن للامركزية اشتقاق المفتاح:إذا كانت أوراكل لا مركزية، فإن عقدة أوراكل تمتلك فقط جزء المفتاح الخاص. ومع ذلك، لا يمكن لعقد أوراكل اللامركزية استخدام BIP32 مباشرة لاشتقاق المفتاح استنادًا إلى مشاركة المفتاح الخاص؛

  • خطر التواطؤ:إذا كان تواطؤ أوراكل بين عقد الجهاز أو التواطؤ مع الأطراف المشاركة لا يزال لا يحل مشكلة الثقة في آلة أوراكل. هناك حاجة إلى آلية إشراف موثوقة لتقليل ثقة أوراكل؛

  • مشكلة تغيير التسمية الثابتة:يجب تحديد التوقيعات المشروطة قبل بناء العقد. مجموعة من أحداث لا حصر لها لبناء المعاملات. ولذلك، سيكون هناك حد أدنى لمبلغ المحتوى القابل للتنزيل (DLC) الذي سيتم استخدامه لإعادة توزيع الأصول، مما يؤدي إلى مشكلة تغيير القيمة الثابتة.

  ولتحقيق هذه الغاية، تقترح هذه المقالة بعض الحلول وأفكار التحسين لحل مخاطر ومشاكل DLC وتحسين أمان نظام Bitcoin البيئي.

  2. مبدأ المحتوى القابل للتنزيل

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

  التهيئة: مولد المنحنى الإهليلجي هو G والترتيب هو q.

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

  • المفتاح الخاص لأوراكل هو z، والمفتاح العام هو Z، والعلاقة Z=z⋅G مستوفاة؛

    p>

  • مفتاح أليس الخاص هو x والمفتاح العام هو X، مما يحقق العلاقة X=x⋅G;

  • مفتاح بوب الخاص هو y والمفتاح العام هو Y، مما يلبي العلاقة Y=y⋅G.

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

  معاملة تنفيذ العقد: تقوم أليس وبوب بإنشاء معاملتي تنفيذ العقد (CET) لإنفاق معاملات ضخ رأس المال.

  تحسب أوراكل الالتزام

  $R:=k ⋅ G$

  ثم تحسب S وS'

  $S:=R-hash(OddNumber,R) ⋅  Z,$

  $S':=R-hash(EvenNumber,R) ⋅  Z$البث (R,S,S').

  يحسب كل من أليس وبوب المفتاح العام الجديد المقابل

  $PK^{Alice}:=X+ S,$

  $PK^{Bob}: =Y+ S'.$

  التسوية: عندما تظهر الكتلة n+k، تقوم آلة أوراكل بإنشاء s أو s المقابلة بناءً على قيمة التجزئة للكتلة '.

  • إذا كانت قيمة التجزئة للكتلة n+kth رقمًا فرديًا، تقوم أوراكل بحساب وبث s

    $s:=k-hash(OddNumber,R) ⋅ z$

    • إذا n+k إذا قيمة التجزئة للكتلة هي رقم زوجي، وتقوم أوراكل بحساب وبث s'

    $s':=k-hash(EvenNumber,R) ⋅ z$ < /p>

    السحب:يمكن لأحد المشاركين، أليس أو بوب، سحب الأصول بناءً على البث الذي يتم بواسطة آلة أوراكل.

    • إذا قامت أوراكل ببث s، فيمكن لأليس حساب المفتاح الخاص الجديد sk^{Alice} واستخراج 2 بيتكوين المقفلة< /p>

    $sk^{Alice}:= x + s.$

    • إذا بثت أوراكل s'، فيمكن لـ Bob حساب المفتاح الخاص الجديد sk^{Bob} واستخراج 2 BTC المقفلة

    $sk^{Bob}:= y + s'. $

    التحليل:المفتاح الخاص الجديد sk^{Alice} المحسوب بواسطة Alice والمفتاح العام الجديد PK^{Alice} يفي بالعلاقة اللوغاريتمية المنفصلة

    $sk^{Alice} ⋅ G= (x+s) ⋅ G=X+S=PK^{Alice}$

    في هذه الحالة، سينجح انسحاب أليس.

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

    $sk^{Bob} ⋅ G = (y+s') ⋅ G=Y+S'=PK^{Bob}$

    في هذه الحالة، سيكون سحب عملة Bob ناجحًا.

    بالإضافة إلى ذلك، إذا بثت أوراكل s، فهذا مفيد لأليس، ولكن ليس لبوب. لأنه لا يمكن استخدام Bob لحساب المفتاح الخاص الجديد المقابل sk^{Bob}. وبنفس الطريقة، إذا بثت أوراكل s، فهذا مفيد لبوب، ولكن ليس لأليس. لأنه لا يمكن استخدام Alice لحساب المفتاح الخاص الجديد المقابل sk^{Alice}.

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

    3. تحسين DLC

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

    في بروتوكول DLC، يعد المفتاح الخاص لـ Oracle والرقم العشوائي المخصص أمرًا بالغ الأهمية. إذا تم تسريب أو فقدان المفتاح الخاص لجهاز أوراكل والرقم العشوائي الموعود، فسيؤدي ذلك بسهولة إلى المشاكل الأمنية الأربعة التالية:

    (1) تفقد آلة أوراكل المفتاح الخاص z

    إذا فقدت Oracle المفتاح الخاص، فلا يمكن تسوية DLC، مما يؤدي إلى الحاجة إلى تنفيذ عقد استرداد DLC. ولذلك، يتم إعداد معاملة استرداد في بروتوكول DLC لمنع Oracle من فقدان مفتاحها الخاص.

    (2) يقوم جهاز أوراكل بتسريب المفتاح الخاص z

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

    (3) تقوم آلة أوراكل بتسريب أو إعادة استخدام الرقم العشوائي k

    إذا قامت آلة أوراكل بتسريب الرقم العشوائي k، ففي مرحلة التسوية، بغض النظر عن عمليات بث جهاز أوراكل أو s، يمكن للمهاجم حساب المفتاح الخاص z لجهاز أوراكل على النحو التالي

    $z:=(k-s)/hash(OddNumber, R)$

    $z:= (k-s')/hash(EvenNumber, R)$

    إذا أعادت Oracle استخدام الرقم العشوائي k، فبعد مستوطنتين، يمكن للمهاجم استخدام بث التوقيع بواسطة أوراكل، وفقًا للمواقف الأربع التالية، قم بحل نظام المعادلات للعثور على المفتاح الخاص z لجهاز أوراكل،

    الحالة 1:

    $s_1=k-hash( OddNumber_1, R) ⋅ z$

    $s_2=k-hash(OddNumber_2, R) ⋅ z$

    الحالة 2:

    $s_1'=k -hash(EvenNumber_1, R) ⋅ z$< /p>

    $s_2'=k-hash(EvenNumber_2, R) ⋅ z$

    الحالة 3:

    $ s_1=k-hash(OddNumber_1, R) ⋅ z$

    $s_2'=k-hash(EvenNumber_2, R) ⋅ z$

    الحالة 4:

    < p>$s_1'=k-hash(EvenNumber_1 , R) ⋅ z$

    $s_2=k-hash(OddNumber_2, R) ⋅ z$

    (4 ) تفقد آلة أوراكل الرقم العشوائي k

    إذا فقدت أوراكل الرقم العشوائي k، فلا يمكن تسوية المحتوى القابل للتنزيل (DLC) المقابل، ويجب تنفيذ عقد استرداد المحتوى القابل للتنزيل (DLC).

    لذلك، من أجل تحسين أمان مفتاح أوراكل الخاص، يجب استخدام BIP32 لاشتقاق المفتاح الفرعي أو مفتاح الحفيد للتوقيع. بالإضافة إلى ذلك، لتحسين أمان الرقم العشوائي، يجب استخدام قيمة التجزئة k:=hash(z, counter) للمفتاح الخاص والعداد كرقم عشوائي k لمنع تكرار الرقم العشوائي أو فقدانه.

    3.2 Oracle اللامركزية

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

    يمكن لتوقيع عتبة شنور تحقيق أوراكل لا مركزي. تتمتع توقيعات عتبة شنور بالمزايا التالية:

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

    • التحكم الموزع: يحقق توقيع العتبة التحكم الموزع في الإدارة الرئيسية. لا يوجد كيان واحد لديه كل صلاحية التوقيع، وبالتالي تقليل مخاطر القوة من أكثر من اللازم تركيز.

    • تحسين الإتاحة: يحتاج عدد معين فقط من عقد Oracle إلى الموافقة على إكمال التوقيع، مما يؤدي إلى تحسين مرونة النظام وإتاحته. حتى لو كانت بعض العقد غير متوفرة، فلن يؤثر ذلك على التشغيل الموثوق للنظام ككل.

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

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

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

    3.3 اللامركزية واقتران إدارة المفاتيح

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

    في سيناريو تطبيق Oracle اللامركزي، يوجد n من المشاركين، ويلزم أن يقوم المشاركون t+1 بتنفيذ توقيعات العتبة. من بينها، ر. تحتوي كل عقدة من عقد أوراكل n على جزء مفتاح خاص z_i, i=1,...,n. تتوافق أجزاء المفتاح الخاص n هذه z_i مع المفتاح الخاص الكامل z، لكن المفتاح الخاص الكامل z لا يظهر من البداية إلى النهاية. تحت فرضية عدم ظهور المفتاح الخاص الكامل z، تستخدم عقد أوراكل t+1 أجزاء المفتاح الخاص z_i, i=1,...,t+1 لإنشاء أجزاء التوقيع σ_i' لرسالة msg'، وأجزاء التوقيع تم دمج σ_i' في التوقيع الكامل σ '. يمكن للمدقق التحقق من صحة زوج توقيع الرسالة (msg',σ') باستخدام المفتاح العام الكامل Z. نظرًا لأن عقد أوراكل t+1 مطلوبة لإنشاء توقيع عتبة بشكل مشترك، فهي تتمتع بأمان عالٍ.

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

    تقترح الورقة اشتقاق المفتاح الموزع للإدارة متعددة الأطراف للأصول الرقمية لسلسلة الكتل طريقة اشتقاق المفتاح الموزع في سيناريو توقيع العتبة. الفكرة الأساسية لهذه الورقة هي أنه وفقًا لاستيفاء لاغرانج متعدد الحدود، فإن جزء المفتاح الخاص z_i والمفتاح الخاص الكامل z يحققان علاقة الاستيفاء التالية

    

    بإضافة الزيادة ω إلى طرفي المعادلة أعلاه، يتم الحصول على المعادلة التالية

    

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

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

    3.4 OP-DLC: تقليل ثقة Oracle

    في DLC، يتم تنفيذ العقد بين Alice وBob بناءً على نتيجة توقيع Oracle، لذا يجب أن يتم ذلك إلى حد ما.ثق في أوراكل. لذلك، يعد السلوك الصحيح لجهاز أوراكل شرطًا أساسيًا لتشغيل المحتوى القابل للتنزيل (DLC).

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

    • يعني نموذج "n-of-n" استخدام n oracles لتوقيع العقد وتنفيذ العقد بناءً على نتائج n أوراكل. يتطلب هذا النموذج عددًا من أوراكل للتوقيع عبر الإنترنت. إذا أصبح أوراكل غير متصل بالإنترنت أو كان لديه خلافات حول النتائج، فسيؤثر ذلك على تنفيذ عقد المحتوى القابل للتنزيل (DLC). افتراض الثقة هو أن جميع الكهنة صادقون.

    • يعني نموذج "k-of-n" استخدام n oracles لتوقيع العقد، وفقًا لـ ك. يتم تنفيذ العقد بناءً على نتائج آلة الأوراكل. إذا تواطأ أكثر من عدد من العرافين، فسيؤثر ذلك على التنفيذ العادل للعقد. بالإضافة إلى ذلك، عند استخدام نموذج "k-of-n"، فإن عدد CETs التي يجب إعدادها هو C_n^k أضعاف عدد أوراكل واحد أو نموذج "n-of-n". افتراض الثقة هو أن على الأقل k oracles من بين n oracles صادقون.

    زيادة عدد آلات أوراكل لا يؤدي إلى عدم الثقة في آلات أوراكل. لأنه عندما يفعل أوراكل شيئا شريرا، فإن الطرف المتضرر في العقد ليس لديه قناة استئناف على السلسلة.

    لذلك، يقترح هذا القسم OP-DLC، الذي يقدم آلية تحدي متفائلة في DLC. قبل أن تشارك n oracles في إعداد المحتوى القابل للتنزيل (DLC)، يتعين عليهم التعهد مقدمًا ببناء لعبة OP غير مسموح بها على السلسلة والوعد بعدم فعل الشر. إذا قام أي أوراكل بالشر، فيمكن لأليس أو بوب، أو أي أوراكل صادق آخر أو مراقب صادق آخر من طرف ثالث، بدء التحدي. إذا فاز المنافس باللعبة، فسيتم معاقبة الوحي الشرير بالسلسلة وسيتم مصادرة وديعته. بالإضافة إلى ذلك، يمكن أيضًا توقيع OP-DLC باستخدام نموذج "k-of-n". من بينها، يمكن أن تكون قيمة k 1. لذلك، يتم تقليل افتراض الثقة إلى أنه طالما كان هناك مشارك صادق في الشبكة، فيمكن إطلاق تحدي OP لمعاقبة عقدة أوراكل الشريرة.

    عند تسوية OP-DLC استنادًا إلى نتائج حساب Layer2:

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

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

    لذلك، يتيح OP-DLC لعقد Oracle الإشراف على بعضها البعض، مما يقلل من ثقة Oracle. تتطلب هذه الآلية مشاركًا نزيهًا واحدًا فقط ولديها معدل تحمل للخطأ يصل إلى 99%، وهو ما يحل بشكل أفضل مخاطر تواطؤ أوراكل.

    3.5 OP-DLC + جسر BitVM المزدوج

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

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

    • عندما تريد Alice تسوية أصول Layer2 الخاصة بها، سيتم فرض تسوية أصول Layer2 الخاصة بالمستخدم Bob على Layer1. هناك مشكلة: يجب أن يكون كل مستخدم من الطبقة الثانية قادرًا على اختيار إيداع وسحب الأموال بحرية دون أن يتأثر بعمليات إيداع وسحب المستخدمين الآخرين.

    • تتفاوض أليس وبوب على التكلفة. هناك مشكلة: يتعين على كلا الطرفين أن يكونا على استعداد للتعاون.

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

    في OP-DLC، أوراكل هو تحالف BitVM، وأليس مستخدم عادي، وبوب هو تحالف BitVM. عند إعداد OP-DLC، في CET التي تم إنشاؤها، يمكن إنفاق الإخراج المعطى للمستخدم Alice على الفور على Layer1، وفي الإخراج المعطى لبوب، يتم إنشاء "لعبة DLC يمكن لـ Alice المشاركة في التحدي" وقفل زمني تم تعيين فترة القفل. عندما تريد Alice سحب أموال:

    • إذا كان تحالف BitVM يعمل بمثابة أوراكل ووقع بشكل صحيح، فيمكن لـ Alice سحب الأموال في Layer1. ومع ذلك، يمكن لـ Bob سحب الأموال من الطبقة الأولى بعد انتهاء فترة القفل.

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

    • إذا كان تحالف BitVM بمثابة الوحي والغش، فسوف تتضرر مصالح بوب. ومع ذلك، يمكن لعضو صادق في تحالف BitVM أن يتحدى "لعبة BitVM" ويعاقب عقد أوراكل الغش.

    بالإضافة إلى ذلك، عندما يريد المستخدم Alice سحب الأموال من الطبقة الثانية، ولكن CET المعينة مسبقًا في عقد OP-DLC لا تتطابق مع المبلغ، يمكن لـ Alice اختيار ما يلي الطريقة:

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

    • اسحب الأموال من خلال CET معينة في OP-DLC، وسيتم تقديم التغيير المتبقي بواسطة مشغل BitVM في Layer1. ستؤدي عمليات سحب OP-DLC إلى إغلاق قناة DLC، ولكن سيتم تحويل الأموال المتبقية في قناة DLC إلى مجمع أموال BitVM Layer1 دون إجبار مستخدمي Layer2 الآخرين على سحب الأموال. تفترض ثقة جسر OP-DLC وجود مشارك صادق في القناة.

    • تتفاوض أليس وبوب على التكلفة دون مشاركة آلة أوراكل، مما يتطلب من بوب التعاون.

    لذلك، يتمتع الجسر المزدوج OP-DLC + BitVM بالمزايا التالية:

    • يؤدي استخدام BitVM إلى حل مشكلة تغيير أموال قناة DLC، ويقلل عدد إعدادات CET، ولا يتأثر بتفاصيل أموال CET؛

    • الجمع بين جسر OP-DLC و جسر BitVM، يتم تزويد المستخدمين بمجموعة متنوعة من قنوات السحب والإيداع، ويمكن إجراء التغيير بأي تفاصيل؛

    • قم بتعيين تحالف BitVM على Bob وOracle، واستخدمه آلية OP لتقليل الثقة في Oracle؛< /p>

    • تقديم رصيد السحب لقناة DLC إلى مجمع أموال جسر BitVM لتحسين استخدام الأموال.

    4. الخلاصة

    ظهر المحتوى القابل للتنزيل (DLC) قبل تفعيل Segwit v1 (Taproot)، وتم تنفيذ دمج قناة المحتوى القابل للتنزيل (DLC) مع شبكة Lightning Network، وDLC تم تمديده للسماح بتحديث العقود المستمرة وتنفيذها ضمن نفس قناة DLC. وبمساعدة تقنيات مثل Taproot وBitVM، يمكن تحقيق التحقق من العقود والتسوية الأكثر تعقيدًا خارج السلسلة ضمن المحتوى القابل للتنزيل (DLC)، بينما يمكن تحقيق الحد الأدنى من ثقة Oracle، مع آلية تحدي OP.

    المراجع

    1. مواصفات عقود السجل السرية

    2. عقود السجل السرية< / p>

    3. تحجيم المحتوى القابل للتنزيل (DLC) الجزء الأول: عقود السجل السرية خارج السلسلة

    4. تحجيم المحتوى القابل للتنزيل الجزء الثاني: مشكلة الخيار المجاني مع المحتوى القابل للتنزيل

    5. Scaling DLC ​​​​Part3: كيفية تجنب مشكلة الخيار المجاني مع DLC

    6. البرق الشبكة

    a>

    7. محتوى قابل للتنزيل على Lightning < /p>

    8. جزء إدارة المفاتيح الخاصة في المحتوى القابل للتنزيل (DLC) 1

    9. إدارة المفاتيح الخاصة لمحتوى DLC الجزء الثاني: مفاتيح Oracle الخاصة

    10. DLC Key Management Pt 3: Oracle Public Key Distribution

    11. BitVM: حساب أي شيء على Bitcoin

    12. BitVM 2: التحقق بدون إذن على البيتكوين

    13. عقود Bitcoin خارج السلسلة لـ BitVM

    14. BIP32BIP44

    15. توقيع شنور

    < li>

    FROST: تواقيع عتبة شنور المرنة والمحسّنة

    16. استطلاع حول التوقيع على عتبة ECDSA

    17. الاشتقاق الرئيسي الموزع للإدارة متعددة الأطراف للأصول الرقمية لسلسلة الكتل

    18. شاهد منفصل

    19. التقرير المتفائل

    20. الجذر الرئيسي

    الرابط الأصلي