1. บทนำ

Discreet Log Contract (DLC) เป็นกรอบการปฏิบัติสัญญาที่ใช้ Oracle ที่เสนอโดย Tadge Dryja จากสถาบันเทคโนโลยีมาสซาชูเซ็ตส์ในปี 2018 ทำให้สองฝ่ายสามารถปฏิบัติการชำระเงินตามเงื่อนไขที่กำหนดไว้ ฝ่ายทั้งสองกำหนดผลลัพธ์ที่เป็นไปได้ล่วงหน้า ลงลายมือชื่อไว้ และใช้ลายมือชื่อล่วงหน้าเหล่านี้เพื่อปฏิบัติการชำระเงินเมื่อ Oracle ลงลายอนุมัติผลลัพธ์ ดังนั้น DLC ทำให้สามารถสร้างแอปพลิเคชันการเงินที่ไม่มีกฎหมายใหม่อย่างกระจายในขณะที่รักษาความปลอดภัยของเงินฝากบิตคอยน์

เมื่อเปรียบเทียบกับเครือข่าย Lightning Network DLC มีข้อดีที่สำคัญต่อไปนี้:

• ความเป็นส่วนตัว: DLC มีการป้องกันความเป็นส่วนตัวที่ดีกว่าเครือข่ายไฟแสดง. รายละเอียดของสัญญาจะถูกแบ่งปันเฉพาะระหว่างฝ่ายที่เกี่ยวข้องและไม่ได้เก็บไว้บนบล็อกเชน. ในทางตรงกันข้าม, รายการธุรกรรมในเครือข่ายไฟแสดงจะถูกส่งผ่านช่องทางและโหนดสาธารณะ ทำให้ข้อมูลของพวกเขาเป็นสาธารณะและโปร่งใส
• ความซับซ้อนและความยืดหยุ่นของสัญญาทางการเงิน: DLC สามารถสร้างและดำเนินการสัญญาทางการเงินที่ซับซ้อนได้โดยตรงบนเครือข่าย Bitcoin เช่นเดอริวาทีฟ ประกัน และการพนัน ในขณะที่เครือข่าย Lightning ใช้สำหรับการชำระเงินรวดเร็วมูลค่าเล็ก และไม่สามารถรองรับการใช้งานที่ซับซ้อน
• ลดความเสี่ยงที่เกิดจากฝ่ายตรงข้าม: เงิน DLC ถูกล็อคอยู่ในสัญญาแบบหลายลายมือและจะถูกปล่อยเมื่อเกิดเหตุการณ์ที่กำหนดไว้เท่านั้น ลดความเสี่ยงที่ฝ่ายใดฝ่ายหนึ่งไม่ปฏิบัติตามสัญญา แม้ว่า Lightning Network จะลดความจำเป็นในเรื่องความไว้วางใจ แต่ยังมีความเสี่ยงจากตรงข้ามบางประการในการบริหารแชนเนลและการให้สัมพันธ์
• ไม่จำเป็นต้องจัดการช่องชำระเงิน: การดำเนินการ DLC ไม่ต้องการสร้างหรือบำรุงรักษาช่องชำระเงิน ซึ่งเป็นส่วนสำคัญของเครือข่าย Lightning และเกี่ยวข้องกับการจัดการที่ซับซ้อนและใช้ทรัพยากรมาก
• ความยืดหยุ่นสำหรับกรณีการใช้ที่เฉพาะเจาะจง: ในขณะที่เครือข่าย Lightning Network เพิ่มประสิทธิภาพของการทำธุรกรรมของบิตคอยน์เล็กน้อย แต่ DLC มีความยืดหยุ่นที่ดีกว่าสำหรับสัญญาที่ซับซ้อนบนบิตคอยน์

แม้ว่า DLCs จะมีข้อดีที่สำคัญในระบบ Bitcoin แต่ก็ยังมีความเสี่ยงและปัญหาบางประการ เช่น:

• ความเสี่ยงสำคัญ: มีความเสี่ยงที่จะมีการรั่วไหลหรือสูญเสียคีย์ส่วนตัวของ Oracle และ nonces ที่ถูกสร้างขึ้น ซึ่งอาจทำให้เกิดความสูญเสียของสินทรัพย์ของผู้ใช้
• ความเสี่ยงที่เกิดจากความเชื่อมั่นที่มีความcentralized: การcentralization ใน Oracles อาจทำให้เกิดการโจมตีด้วยการปฏิเสธบริการได้โดยง่าย
• ปัญหาการคุณสมบัติของคีย์ที่มีการกระจาย: หาก Oracle เป็นระบบที่มีการกระจาย โหนด Oracle เท่านั้นที่มีส่วนแบ่งของกุญแจส่วนตัว อย่างไรก็ตาม โหนด Oracle ที่มีการกระจายไม่สามารถใช้ BIP32 สำหรับการคุณสมบัติของคีย์โดยตรงจากส่วนแบ่งของกุญแจส่วนตัวเหล่านี้
• ความเสี่ยงจากการกบดาน: หากโหนด Oracle กบดานระหว่างตนเองหรือกับฝ่ายใดฝ่ายหนึ่ง ปัญหาเชื่อมั่นกับ Oracles ยังคงไม่ได้รับการแก้ไข จำเป็นต้องมีกลไกการตรวจสอบที่เชื่อถือได้เพื่อลดความเชื่อมั่นใน Oracles
• ปัญหาการเปลี่ยนเงินตราคงที่: ลายเซ็นเงื่อนไขต้องการชุดเหตุการณ์ที่กำหนดลำดับก่อนสร้างสัญญาเพื่อสร้างธุรกรรม ดังนั้นการใช้ DLC สำหรับการจัดสรรทรัพย์สินมีข้อจำกัดขั้นต่ำในการเปลี่ยนแปลงของเงินตราคงที่

เพื่อแก้ไขปัญหาเหล่านี้ กระดาษวิจัยนี้ предлагает หลายวิธีการและไอเดียในการปรับปรุงเพื่อลดความเสี่ยงและปัญหาที่เกี่ยวข้องกับ DLCs โดยเช่นนี้มันจะเสริมความปลอดภัยของระบบบิตคอยน์

2. หลักการ DLC

Alice และ Bob เข้าใจข้อตกลงการพนันกันว่าค่าแฮชของบล็อก (n+k) คือเลขคี่หรือคู่ หากเป็นเลขคี่ Alice จะชนะเกมและสามารถถอนสินทรัพยwithin time t แต่ถ้าเป็นเลขคู่ Bob จะชนะเกมและสามารถถอนสินทรัพยwithin time t โดยใช้ DLC ข้อมูลบล็อก (n+k) ถูกส่งผ่าน Oracle เพื่อสร้างลายเซ็นเงื่อนไข ให้แน่ใจว่าผู้ชนะที่ถูกต้องได้รับทรัพย์ทั้งหมด

การเริ่มต้น: โกเดเนอร์ของเส้นโค้งวงกลมคือ G และลำดับของมันคือ q

การสร้างคีย์: Oracle, Alice, และ Bob สร้างคีย์ส่วนตัวและคีย์สาธารณะของตัวเองโดยอิสระ

• คีย์ส่วนตัวของ Oracle คือ z และคีย์สาธารณะของมันคือ Z ที่ทำให้ Z=z⋅G;
• คีย์ส่วนตัวของ Alice คือ x และคีย์สาธารณะของเธอคือ X ที่ทำให้ X=x⋅G;
• คีย์ส่วนตัวของบ็อบคือ y และคีย์สาธารณะของเขาคือ Y ที่ทำให้ Y=y⋅G

ธุรกรรมทุน: Alice และ Bob สร้างธุรกรรมทุนร่วมกันโดยล็อก 1 BTC แต่ละฝ่ายในเอาท์พุต 2 ใน 2 หลายลายเซ็นเจอร์ (คีย์สาธารณะ X คือของ Alice และ Y คือของ Bob)

การดำเนินการสัญญา (CET): แอลิซและบ็อบสร้าง CET สองรายการเพื่อใช้จ่ายธุรกรรมทุน

Oracle คำนวณการมุ่งมั่น

และคำนวณ S และ S′

และกระจาย (R, S, S′).

Alice และ Bob คำนวณคีย์สาธารณะใหม่ที่เกี่ยวข้องแต่ละตัว

การต่อรอง: หลังจากบล็อก (n+k) ครั้งปรากฏขึ้น ออราเคิลจะสร้าง s หรือ s′ ที่สอดคล้องกับค่าแฮชของบล็อกนั้น

• หากค่าแฮชของบล็อก (n+k) เป็นเลขคี่ ออราเคิลจะคำนวณและกระจาย

• หากค่าแฮชของบล็อก (n+k) เป็นเลขคู่ ออราเคิลจะคำนวณและประกาศ

การถอนเงิน: อลิซหรือบ็อบสามารถถอนสินทรัพย์ขึ้นอยู่กับ s หรือ s' ที่ถูกส่งออกโดย Oracle

• หาก Oracle ประกาศ s, Alice สามารถคำนวณคีย์ส่วนตัวใหม่ sk^{Alice} และถอน 2 BTC ที่ถูกล็อค

• หากออราเคิลกระจาย s′, บ็อบสามารถคำนวณคีย์ส่วนตัวใหม่ sk^{Bob} และถอนเงิน 2 BTC ที่ถูกล็อก

การวิเคราะห์: คีย์ส่วนตัวใหม่ sk^{Alice} ที่ถูกคำนวณโดย Alice และคีย์สาธารณะใหม่ PK^{Alice} ทำให้ความสัมพันธ์ของล็อกอาริทึม離散

ดังนั้น การถอนเงินของ Alice จะประสบความสำเร็จ

โดยเช่นเดียวกัน คีย์ส่วนตัวใหม่ sk^{Bob} ที่คำนวณโดย Bob และคีย์สาธารณะใหม่ PK^{Bob} ตรงตามความสัมพันธ์ของลอการิทึมดิสครีต

ดังนั้นการถอนของบ็อบจะประสบความสำเร็จ

นอกจากนี้ หาก Oracle กระจาย s มันมีประโยชน์สำหรับ Alice แต่ไม่สำหรับ Bob เพราะ Bob ไม่สามารถคำนวณหาคีย์ส่วนตัวใหม่ที่สอดคล้องกับ sk^{Bob} ได้ ในทำนองเดียวกัน หาก Oracle กระจาย s′ มันมีประโยชน์สำหรับ Bob แต่ไม่สำหรับ Alice เพราะ Alice ไม่สามารถคำนวณหาคีย์ส่วนตัวใหม่ที่สอดคล้องกับ sk^{Alice} ได้ สุดท้าย คำอธิบายข้างต้นละเว้นการล็อกเวลาไว้ จำเป็นต้องเพิ่มล็อกเวลาเพื่อให้ฝ่ายหนึ่งสามารถคำนวณหาคีย์ส่วนตัวใหม่และถอนได้ภายในเวลา t มิฉะนั้น หากเกินเวลา t อีกฝ่ายสามารถใช้คีย์ส่วนตัวเดิมเพื่อถอนสินทรัพย์

3. ปรับปรุง DLC

3.1 การจัดการคีย์

ในโปรโตคอล DLC คีย์ส่วนตัวของ Oracle และ nonce ที่ถูกต้องเป็นสิ่งสำคัญ การรั่วไหลหรือสูญหายของคีย์ส่วนตัวของ Oracle และ nonce ที่ถูกต้องสามารถนำไปสู่ปัญหาด้านความปลอดภัยสี่ประการต่อไปนี้:

(1) Oracle สูญเสียกุญแจส่วนตัว z

หาก Oracle สูญเสียกุญแจส่วนตัว DLC จะไม่สามารถตัดสินให้เกิดความจำเป็นในการดำเนินการของสัญญาคืนเงิน DLC ดังนั้นโปรโตคอล DLC รวมถึงธุรกรรมการคืนเงินเพื่อป้องกันผลของ Oracle ที่สูญเสียกุญแจส่วนตัว

(2) การรั่วคีย์ส่วนตัวของ Oracle z

หากคีย์ส่วนตัวของ Oracle ถูกหลุด DLC ทั้งหมดที่ขึ้นอยู่กับคีย์ส่วนตัวนั้นจะเผชิญกับความเสี่ยงของการตกลงโบนัสที่ไม่ซื่อสัตย์ ผู้โจมตีที่ขโมยคีย์ส่วนตัวสามารถเซ็นข้อความที่ต้องการได้ทุกข้อ ได้รับการควบคุมสมบูรณ์เหนือผลลัพธ์ของสัญญาทั้งหมดในอนาคต อย่างไรก็ตาม ผู้โจมตีไม่ได้ถูกจำกัดในการออกข้อความที่ได้รับลงเซ็นเพียงข้อความเดียว แต่ยังสามารถเผยแพร่ข้อความที่ขัดแย้งกัน เช่น เซ็นว่าค่าแฮชของบล็อก (n+k) คือคี่และคู่

(3) การรั่วของ Oracle หรือการใช้ซ้ำของ Nonce k

หาก Oracle รั่ว nonce k แล้วในเซ็ตเทิลเม้นต์เฟส โดยไม่ว่า Oracle จะกระจาย s หรือ s′ โจมตีการได้คำนวณคีย์ส่วนตัวของ Oracle z ได้ดังนี้

หาก Oracle ใช้ nonce k อีกครั้ง หลังจากการตกลงกันสองครั้ง ผู้โจมตีสามารถแก้ระบบสมการโดยใช้ลายเซ็นต์การกระจายของ Oracle เพื่อหาค่า z ของกุญแจส่วนตัวของ Oracle ในหนึ่งในสามารถเป็นไปได้

case 1:

กรณี 2:

case 3:

case 4:

(4) Oracle สูญเสีย Nonce k

หาก Oracle สูญเสีย nonce k DLC ที่สอดคล้องกันจะไม่สามารถตรวจสอบการชำระเงิน จึงจำเป็นต้องดำเนินการสัญญาคืนเงิน DLC

ดังนั้น เพื่อเพิ่มความปลอดภัยของคีย์ส่วนตัวของ Oracle ควรใช้ BIP32 เพื่อสืบทอดคีย์ลูกหรือคีย์หลานสำหรับการเซ็นต์ นอกจากนี้ เพื่อเพิ่มความปลอดภัยของ nonce ควรใช้ค่าแฮช k:=hash(z, counter) เป็น nonce k เพื่อป้องกันการทำซ้ำหรือสูญเสียของ nonce

3.2 ออรัคเวย์ที่ไม่มีส่วนรวม

ในปี DLC บทบาทของ Oracle มีความสําคัญเนื่องจากให้ข้อมูลภายนอกที่สําคัญซึ่งกําหนดผลลัพธ์ของสัญญา เพื่อเพิ่มความปลอดภัยของสัญญาเหล่านี้จําเป็นต้องมี Oracles แบบกระจายอํานาจ ซึ่งแตกต่างจาก Oracles แบบรวมศูนย์ Oracles แบบกระจายอํานาจกระจายความรับผิดชอบในการให้ข้อมูลที่ถูกต้องและป้องกันการงัดแงะในโหนดอิสระหลายแห่งลดความเสี่ยงที่เกี่ยวข้องกับความล้มเหลวจุดเดียวและลดโอกาสในการจัดการหรือการโจมตีแบบกําหนดเป้าหมาย ด้วย Oracle แบบกระจายอํานาจ DLC สามารถบรรลุระดับความน่าเชื่อถือและความน่าเชื่อถือที่สูงขึ้นทําให้มั่นใจได้ว่าการดําเนินการตามสัญญาขึ้นอยู่กับความเที่ยงธรรมของเงื่อนไขที่กําหนดไว้ล่วงหน้า

ลายเซ็นเขตความสามารถของ Schnorr สามารถใช้ในการประยุกต์ใช้ตัวเลือกที่แยกออกจากกันได้ Schnorr ลายเซ็นเขตความสามารถมีข้อดีต่อไปนี้:

• ความปลอดภัยที่ปรับปรุง: โดยการกระจายการจัดการของกุญแจ ลายเซ็นเจอร์จำนวนครึ่งลดความเสี่ยงของจุดล้มเหลวเพียงจุดเดียว แม้แต่ถ้ากุญแจของบางผู้เข้าร่วมถูกคัดค้านหรือโจมตี ระบบทั้งหมดยังคงปลอดภัยตลอดไป ตราบเท่าที่การละเมิดไม่เกินค่าที่กำหนดไว้ล่วงหน้า
• การควบคุมแบบกระจาย: ลายเซ็นประทีปช่วยให้การควบคุมแบบกระจายเกี่ยวกับการจัดการกุญแจเป็นไปได้ โดยไม่ต้องมีองค์กรเดียวครอบครองความสามารถในการเซ็นชื่อทั้งหมด ซึ่งจะลดความเสี่ยงที่เกี่ยวข้องกับการหน่วงเหนี่ยว
• ความพร้อมใช้งานที่ดีขึ้น: สามารถเสร็จสิ้นลายเซ็นต์ตามเมื่อมีจำนวนโหนด Oracle ที่เห็นด้วยพอสมควร ซึ่งเพิ่มความยืดหยุ่นและความพร้อมใช้งานของระบบ แม้แต่บางโหนดจะไม่พร้อมใช้งาน ความเชื่อถือของระบบโดยรวมก็จะไม่ได้รับผลกระทบ
• ความยืดหยุ่นและความสามารถในการขยายขนาด: โปรโตคอลลายเซ็นเนเจอร์แบบค่าเริ่มต้นสามารถกำหนดค่าเริ่มต้นที่แตกต่างตามความต้องการเพื่อตอบสนองต่อความปลอดภัยและสถานการณ์ต่าง ๆ อีกทั้งยังเหมาะสำหรับเครือข่ายขนาดใหญ่โดยมีความสามารถในการขยายขนาดที่ดี
• ความรับผิดชอบ: แต่ละโหนดออรัคเคิลสร้างส่วนลงนามตามอิสระของตนเอง และผู้เข้าร่วมคนอื่นสามารถตรวจสอบความถูกต้องของส่วนลงนามนี้โดยใช้ส่วนลงนามสาธารณะที่เกี่ยวข้อง ทำให้มีความรับผิดชอบ หากถูกต้อง ส่วนลงนามเหล่านี้ถูกสะสมเพื่อสร้างลายเซ็นเต็ม

ดังนั้น โปรโตคอลลายเซ็นเนเจอร์ของชนอร์ทรีเชิ้ลมีข้อดีที่สำคัญใน Oracles แบบกระจายที่เกี่ยวกับการปรับปรุงความปลอดภัย ความเชื่อถือได้ ความยืดหยุ่น การขยายขยายและความรับผิดชอบ

3.3 การเชื่อมโยงของการกระจายอำนาจและการจัดการคีย์

ในเทคโนโลยีการจัดการคีย์ ออรัคเคิลครอบครองคีย์ z ทั้งหมดและโดยใช้ BIP32 พร้อมกับการเพิ่มค่า ω สามารถสร้างคีย์ลูก z+ω^{(1)} และคีย์หลาน z+ω^{(1)}+ω^{(2)} จำนวนมาก สำหรับเหตุการณ์ที่แตกต่างกัน ออรัคเคิลสามารถใช้คีย์ส่วนตัวลูกหลานต่าง ๆ z+ω^{(1)}+ω^{(2)} เพื่อสร้างลายเซ็นต์ที่สอดคล้องกับเหตุการณ์ msg ที่เกี่ยวข้อง

ในสถานการณ์ Oracle แบบกระจายอํานาจ มีผู้เข้าร่วม n และลายเซ็นเกณฑ์ต้องใช้ผู้เข้าร่วม t+1 โดยที่ t

อย่างไรก็ตาม ในสถานการณ์ Oracle แบบกระจายแบบนี้ คีย์ส่วนตัว z ทั้งหมดจะไม่ปรากฏ และดังนั้นการสืบทอดคีย์โดยตรงโดยใช้ BIP32 ไม่สามารถทำได้ กล่าวอีกนัยหนึ่ง เทคโนโลยี Oracle แบบกระจายและเทคโนโลยีการจัดการคีย์ไม่สามารถผสมกันโดยตรง

เอกสาร “การสร้างคีย์แบบกระจายสำหรับการบริหารจัดการสินทรัพย์ดิจิทัลบล็อกเชนของหลายฝ่าย” предлагает схему распределенного производства ключей в сценариях подписи по порогу. Основная идея основана на интерполяционных полиномах Лагранжа, где доля закрытого ключа z_i и полный закрытый ключ z удовлетворяют следующему отношению интерполяции:

การเพิ่มการเพิ่ม ω ทั้งสองข้างของสมการจะได้:

สมการนี้แสดงให้เห็นว่าความลับแบ่งปัน z_i ร่วมกับการเพิ่ม ω ยังคงทำให้ความสัมพันธ์การเตรียมตัวกับความลับที่สมบูรณ์ z ร่วมกับ ω ดังนั้น ความลับแบ่งปันลูก z_i+ω และกุญแจลูก z+ω ยังคงทำให้ความสัมพันธ์การเตรียมตัว ดังนั้น แต่ละผู้ร่วมสามารถใช้ความลับแบ่งปัน z_i ร่วมกับการเพิ่ม ω เพื่อได้ความลับแบ่งปันลูก z_i+ω ที่ใช้ในการสร้างแบ่งปันลายเซ็นลูกและตรวจสอบโดยใช้กุญแจสาธารณะลูกที่เกี่ยวข้อง Z+ω⋅G

อย่างไรก็ตามเราต้องพิจารณา BIP32 ที่แข็งและไม่ชุบแข็ง Hardened BIP32 ใช้คีย์ส่วนตัวรหัสโซ่และเส้นทางเป็นอินพุตดําเนินการ SHA512 และส่งออกรหัสที่เพิ่มขึ้นและรหัสโซ่ลูก ในทางกลับกัน BIP32 ที่ไม่ชุบแข็งจะใช้คีย์สาธารณะรหัสโซ่และเส้นทางเป็นอินพุตดําเนินการ SHA512 และส่งออกรหัสที่เพิ่มขึ้นและรหัสลูกโซ่ ในสถานการณ์ลายเซ็นเกณฑ์คีย์ส่วนตัวไม่มีอยู่ดังนั้นจึงสามารถใช้ BIP32 ที่ไม่ชุบแข็งเท่านั้น หรือการใช้ฟังก์ชันแฮชแบบโฮโมมอร์ฟิกสามารถใช้ BIP32 แบบแข็งได้ อย่างไรก็ตาม ฟังก์ชันแฮชโฮโมมอร์ฟิกแตกต่างจาก SHA512 และเข้ากันไม่ได้กับ BIP32 ดั้งเดิม

3.4 OP-DLC: Oracle Trust-minimized

ใน DLC สัญญาระหว่าง Alice และ Bob ถูกดำเนินการตามผลลัพธ์ที่ได้รับลงนามจาก Oracle ซึ่งทำให้จำเป็นต้องมีความไว้วางใจใน Oracle ระดับหนึ่ง ดังนั้น พฤติกรรมที่ถูกต้องของ Oracle เป็นเงื่อนไขหลักสำหรับการดำเนินการของ DLC

เพื่อลดความไว้วางใจใน Oracle ได้มีการทำวิจัยเกี่ยวกับการดำเนินการ DLC โดยใช้ผลลัพธ์จาก Oracles n อัน เพื่อลดความขึ้นอยู่กับ Oracle เดียว

• โมเดล "n-of-n" เกี่ยวข้องกับการใช้ Oracles n ตัวในการลงลายมติและปฏิบัติสัญญาโดยขึ้นอยู่กับผลลัพธ์จาก Oracles ทั้งหมด โมเดลนี้ต้องการให้ Oracles ทุกตัวอยู่ในสถานะออนไลน์เพื่อทำการลงลายมติ หาก Oracles ใดๆ ออฟไลน์หรือมีความไม่เห็นในผลลัพธ์ จะส่งผลต่อการปฏิบัติสัญญา DLC การสมมติในที่นี้คือ Oracles ทุกตัวเป็นซื่อสัตย์
• โมเดล "k-of-n" เกี่ยวข้องกับการใช้ Oracles n ตัวเพื่อลงนามสัญญา ดำเนินการสัญญาขึ้นอยู่กับผลลัพธ์จาก Oracles k ตัวใดก็ตาม หากมี Oracles เกิน k ตัวทำร่วมกัน จะส่งผลกระทบต่อการดำเนินการสุภาพของสัญญา อย่างไรก็ตาม จำนวน CETs ที่จำเป็นในโมเดล "k-of-n" คือ C_n^k เท่ากับ Oracles ตัวเดียวหรือโมเดล "n-of-n" ข้อความนี้สมมติฐานว่าอย่างน้อย k จาก n Oracles เป็นคนซื่อสัตย์

การเพิ่มจำนวนของ Oracles โดยอย่างเดียวไม่สามารถทำให้เราได้เชื่อถือใน Oracles ได้ เพราะหลังจากที่มีการกระทำชั่วร้ายโดย Oracle ฝ่ายที่ได้รับความเดือดเดือดในสัญญาจะไม่สามารถทำการเรียกร้องบนเชนได้

ดังนั้นเราจึงเสนอ OP-DLC ซึ่งรวมกลไกความท้าทายในแง่ดีไว้ใน DLC ก่อนที่จะเข้าร่วมในการตั้งค่า DLC n Oracles จําเป็นต้องจํานําและสร้างเกม OP แบบ on-chain ที่ไม่ได้รับอนุญาตล่วงหน้าโดยมุ่งมั่นที่จะไม่กระทําการที่เป็นอันตราย หาก Oracle คนใดกระทําการโดยประสงค์ร้าย Alice, Bob, Oracle ที่ซื่อสัตย์อื่น ๆ หรือผู้สังเกตการณ์ที่ซื่อสัตย์บุคคลที่สามอื่น ๆ สามารถเริ่มต้นการท้าทายได้ หากผู้ท้าชิงชนะเกมระบบ on-chain จะลงโทษ Oracle ที่เป็นอันตรายโดยการริบเงินฝาก นอกจากนี้ OP-DLC ยังสามารถใช้โมเดล "k-of-n" สําหรับการลงนามโดยที่ค่า k สามารถเป็น 1 ได้ ดังนั้นสมมติฐานความน่าเชื่อถือจึงลดลงเหลือเพียงต้องการผู้เข้าร่วมที่ซื่อสัตย์คนหนึ่งในเครือข่ายเพื่อเริ่มต้นความท้าทาย OP และลงโทษโหนด Oracle ที่เป็นอันตราย

เมื่อตกลง OP-DLC โดยใช้ผลลัพธ์การคำนวณ Layer 2

• หากออรัคเคิลลงนามด้วยผลลัพธ์ที่ไม่ถูกต้อง ทำให้ Alice ประสบความสูญเสีย Alice สามารถใช้ผลลัพธ์การคำนวณ Layer 2 ที่ถูกต้องเพื่อท้าทายการเล่นเกม OP ที่ไม่มีการอนุญาตล่วงหน้าบนเชิงเลขบนชั้นที่ 2 ที่ถูกต้อง. เมื่อชนะเกม Alice สามารถลงโทษออรัคเคิลที่ไม่ดีและชดเชยสำหรับความสูญเสียของเธอ
• โดยเหมือนกัน บ็อบ โหนดออรัคเคิลที่ซื่อสัตย์และผู้สังเกตการณ์บุคคลที่สามที่ซื่อสัตย์ก็สามารถเริ่มทำความท้าทายได้เช่นกัน อย่างไรก็ตาม ในการป้องกันความท้าทายที่มีเจตนาบาป ผู้ท้าทายจะต้องมีการค้ำประกันด้วย

ดังนั้น OP-DLC ส่งเสริมการควบคุมร่วมกันระหว่างโหนดออราเคิล ลดการเชื่อมั่นที่วางไว้ใน Oracles กลไกนี้ต้องการผู้เข้าร่วมที่ซื่อสัตย์อย่างน้อยหนึ่งคนและมีความทนทานของข้อผิดพลาดอยู่ที่ 99% ที่จะทำให้ก้าวร่วมต่อสู้กับความเสี่ยงจากการซุกซ่อนของ Oracle

3.5 OP-DLC + BitVM สะพานคู่

เมื่อใช้ DLC สำหรับสะพาน跨ลูกซอง การกระจายเงินต้องเกิดขึ้นที่การตกลงของสัญญา DLC:

• มันต้องการการตั้งค่าล่วงหน้าผ่าน CETs ซึ่งหมายความว่าความละเอียดในการตกลงเงินทุนของ DLC จะถูกจำกัด เช่น 0.1 BTC ในเครือข่ายของ Bison นี้ สิ่งนี้เพิ่มปัญหาขึ้น: การมิติสารสนเทศของสินทรัพย์ชั้นที่ 2 สำหรับผู้ใช้ไม่ควรถูก จำกัดโดยความละเอียดของเงินทุน CETs ของ DLC
• เมื่อ Alice ต้องการตกลงทุน Layer 2 ของเธอ มันจะบังคับให้การตกลงทุนของผู้ใช้ Bob ใน Layer 2 ไปสู่ Layer 1 ด้วย สิ่งนี้เพิ่มปัญหา: ผู้ใช้ Layer 2 แต่ละคนควรมีเสรีภาพในการเลือกฝากและถอนเงินของตนเอง โดยอิสระจากการกระทำของผู้ใช้คนอื่น
• Alice และ Bob ต่อรองเรื่องการใช้จ่าย ปัญหาที่นี่คือมันต้องการทั้งสองฝ่ายเป็นคนต้องการร่วมมือ

ดังนั้น เพื่อแก้ไขปัญหาที่กล่าวถึง เราขอเสนอสะพานคู่ OP-DLC + BitVM โดยที่ผู้ใช้สามารถฝากเงินและถอนเงินผ่านสะพานที่ไม่มีการอนุญาตของ BitVM และผ่านกลไก OP-DLC โดยที่สามารถทำการเปลี่ยนแปลงในระดับใดก็ได้และเพิ่มความสะดวกสบายในการเคลื่อนไหวเงินทุกประการ

ใน OP-DLC Oracle คือสหพันธ์ BitVM โดยมี Alice เป็นผู้ใช้ปกติและ Bob เป็นสหพันธ์ BitVM เมื่อตั้งค่า OP-DLC CETs ที่สร้างขึ้นช่วยให้สามารถใช้เอาต์พุตของ Alice ได้ทันทีใน Layer 1 ในขณะที่เอาต์พุตของ Bob รวมถึง "เกม DLC Alice can challenge" ด้วยระยะเวลาการล็อกเวลา เมื่ออลิซต้องการถอนตัว

• หากสมาคม BitVM ที่ดำเนินการในฐานะ Oracle ลงลายเซ็นอย่างถูกต้อง แอลิซสามารถถอนได้ในเลเยอร์ 1 อย่างไรก็ตาม บ็อบสามารถถอนได้ในเลเยอร์ 1 หลังจากระยะเวลาล็อค
• หากสหภาพ BitVM ซึ่งเป็น Oracle ทำผิด ทำให้ Alice ขาดทุน เธอสามารถท้าทาย UTXO ของ Bob หากท้าทายสำเร็จ จำนวนเงินของ Bob อาจถูกยึด หมายเหตุ: สมาชิกคนอื่นของสหภาพ BitVM c็อาจเริ่มโจมตีได้เช่นกัน แต่ Alice ซึ่งเป็นฝ่ายเสียหายมีแรงกระตุ้นมากที่สุดในการทำเช่นนั้น
• หากสหภาพ BitVM ที่ดำเนินการเป็น Oracle ทุจริต ทำให้บ๊อบเสียหาย สมาชิกที่ซื่อสัตย์ของสหภาพ BitVM สามารถท้าทาย "เกม BitVM" เพื่อลงโทษโหนด Oracle ที่ทุจริต

นอกจากนี้ หากผู้ใช้ Alice ต้องการถอนเงินจาก Layer 2 แต่จำนวน CETs ที่ถูกตั้งค่าในสัญญา OP-DLC ไม่ตรงกับจำนวน แอลิซ สามารถเลือกวิธีต่อไปนี้:

• ถอนผ่าน BitVM โดยมีผู้ดำเนินการ BitVM ยืนหน้าจำนวนเงินบน Layer 1 สะพาน BitVM สมมติว่ามีผู้ร่วมสมาชิกที่ซื่อสัตย์อย่างน้อยหนึ่งคนในสหภาพ BitVM
• ถอนผ่าน CET ที่ระบุใน OP-DLC, โดยการเปลี่ยนทองที่เหลือนำมาใช้งานโดยผู้ดำเนินการ BitVM บน Layer 1 การถอนผ่าน OP-DLC จะปิดช่อง DLC แต่เงินที่เหลือในช่อง DLC จะย้ายไปยังสระว่ายน้ำ BitVM Layer 1 โดยไม่บังคับผู้ใช้ Layer 2 คนอื่นให้ถอนเงิน สะพาน OP-DLC สมมติว่ามีอย่างน้อยหนึ่งผู้ร่วมกิจกรรมที่ซื่อสัตย์ในช่อง
• Alice และ Bob ต่อรองการใช้จ่ายโดยไม่ต้องมี Oracle เข้ามาเกี่ยวข้อง โดยต้องการความร่วมมือจาก Bob

ดังนั้น สะพานคู่ OP-DLC + BitVM มีข้อดีต่อไปนี้:

• BitVM แก้ไขปัญหาการเปลี่ยนแปลงของช่อง DLC ลดจำนวนของ CET ที่ต้องใช้ และไม่ได้รับผลกระทบจากความละเอียดของกองทุน CET;
• โดยผสานสะพาน OP-DLC กับสะพาน BitVM จะให้ผู้ใช้มีช่องทางหลายรายการสำหรับการฝากเงินและถอนออก เพิ่มประสบการณ์ของผู้ใช้
• การตั้ง Consorium BitVM เป็นทั้งบ็อบและตัว Orcale และใช้กลไก OP เพื่อลดความเชื่อถือในตัว Orcale;
• การรวมถอนเกินจากช่อง DLC เข้าสู่สระสะพาน BitVM เพิ่มประสิทธิภาพการใช้เงินทุน

4. สรุป

DLC ปรากฏก่อนที่เริ่มทำงาน Segwit v1 (Taproot) และได้รับการรวมเข้ากับ Lightning Network แล้วทำให้สามารถขยาย DLC เพื่ออัปเดตและดำเนินการสัญญาต่อเนื่องภายในช่อง DLC เดียวกัน ด้วยเทคโนโลยีอย่าง Taproot และ BitVM สามารถนำมาใช้ในการดำเนินการตรวจสอบและชำระเงินสัญญานอกเชื่อสายได้ซับซ้อนขึ้นใน DLC เพิ่มเติมโดยการรวมกลไกท้าทาย OP จะเป็นไปได้ที่จะลดความเชื่อใน Oracles

คำแถลง:

1. บทความนี้ถูกพิมพ์อีกครั้งจากกลาง, ชื่อเรื่องเดิมคือ “Bitlayer Core Technology: DLC และการพิจารณาในการปรับปรุง” ลิขสิทธิ์เป็นของผู้เขียนเดิม,เบิตเลเยอร์. หากมีข้อความใดๆ ที่คัดค้านการพิมพ์นี้ กรุณาติดต่อ ทีม Gate Learnทีมจะดำเนินการตามขั้นตอนที่เกี่ยวข้องโดยเร็วที่สุด

2. คำปฏิเสธ: มุมมองและความคิดเห็นที่แสดงอยู่ในบทความนี้เป็นเพียงความคิดเห็นส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นที่ปรึกษาด้านการลงทุนใด ๆ

3. เวอร์ชันภาษาอื่นของบทความได้รับการแปลโดยทีม Gate Learn โดยไม่ต้องกล่าวถึงGate.io, บทความที่ถูกแปลอาจไม่สามารถคัดลอก กระจายหรือลอกเลียนได้