ชื่อเดิม: Bitlayer Core Technology: DLC and Its Optimization Considerations》
ผู้เขียนต้นฉบับ: lynndell mutourend, Bitlayer Research Group
1. บทนำ
Discreet Log Contract (DLC) คือชุดโซลูชันการดำเนินการตามสัญญาตาม Oracle ที่เสนอโดย Tadge Dryja จาก MIT ในปี 2018 DLC อนุญาตให้ทั้งสองฝ่ายชำระเงินแบบมีเงื่อนไขตามเงื่อนไขที่กำหนดไว้ล่วงหน้า แต่ละฝ่ายจะกำหนดและลงนามล่วงหน้าผลลัพธ์ที่เป็นไปได้ และใช้การลงนามล่วงหน้าเหล่านี้เพื่อดำเนินการชำระเงินเมื่อ Oracle ลงนามในผลลัพธ์ ด้วยเหตุนี้ DLC จึงเปิดใช้งานแอปพลิเคชันทางการเงินแบบกระจายอำนาจใหม่ในขณะที่รักษาเงินฝาก Bitcoin ให้ปลอดภัย
เมื่อเปรียบเทียบกับ Lightning Network แล้ว DLC มีข้อได้เปรียบที่สำคัญดังต่อไปนี้:
ความเป็นส่วนตัว:DLC นั้นเหนือกว่า Lightning Network ในแง่ของการปกป้องความเป็นส่วนตัว เนื่องจากรายละเอียดสัญญาจะถูกแชร์ระหว่างผู้เข้าร่วมเท่านั้น และไม่ได้จัดเก็บไว้ในบล็อกเชน ในทางตรงกันข้าม ธุรกรรมของ Lightning Network จะถูกส่งผ่านช่องทางและโหนดสาธารณะ และข้อมูลของรายการดังกล่าวจะเป็นข้อมูลสาธารณะและโปร่งใส
ความซับซ้อนและความยืดหยุ่นของสัญญาทางการเงิน:DLC สามารถสร้างและดำเนินการสัญญาทางการเงินที่ซับซ้อนได้โดยตรงบนเครือข่าย Bitcoin เช่น อนุพันธ์ การประกันภัย และสัญญาการพนัน ในขณะที่เครือข่าย Lightning ส่วนใหญ่จะใช้สำหรับการชำระเงินจำนวนเล็กน้อยที่รวดเร็วและไม่สามารถรองรับแอปพลิเคชันที่ซับซ้อนได้
ลดความเสี่ยงของคู่สัญญา:เงิน DLC จะถูกล็อคไว้ในสัญญาที่มีลายเซ็นหลายฉบับ และจะถูกปล่อยออกมาเมื่อผลลัพธ์ของเหตุการณ์ที่กำหนดไว้ล่วงหน้าเกิดขึ้นเท่านั้น ซึ่งจะช่วยลดความเสี่ยงที่ฝ่ายใดฝ่ายหนึ่งไม่ปฏิบัติตามสัญญา แม้ว่า Lightning Network จะช่วยลดความจำเป็นในการไว้วางใจ แต่ก็ยังมีความเสี่ยงจากคู่ค้าในแง่ของการจัดการช่องทางและการจัดหาสภาพคล่อง
ไม่ต้องจัดการช่องทางการชำระเงิน:การดำเนินการ DLC ไม่จำเป็นต้องสร้างหรือบำรุงรักษาช่องทางการชำระเงินซึ่งเป็นองค์ประกอบหลักของ Lightning Network การจัดการช่องทางมีความซับซ้อนและใช้ทรัพยากรมาก
ความสามารถในการปรับขนาดสำหรับกรณีการใช้งานเฉพาะ:Lightning Network ปรับปรุงปริมาณธุรกรรมของ Bitcoin ในระดับหนึ่ง ในขณะที่ DLC ให้ความสามารถในการปรับขนาดที่ดีขึ้นสำหรับสัญญาที่ซับซ้อนใน Bitcoin
แม้ว่า DLC จะมีข้อได้เปรียบอย่างมากในการใช้งานเชิงนิเวศน์ของ Bitcoin แต่ก็ยังมีความเสี่ยงและปัญหาอยู่บ้าง เช่น:
ความเสี่ยงที่สำคัญ:คีย์ส่วนตัวของเครื่อง Oracle และหมายเลขสุ่มที่สัญญาไว้มีความเสี่ยงที่จะรั่วไหลหรือสูญหาย ส่งผลให้ทรัพย์สินของผู้ใช้สูญหาย
ความเสี่ยงจากความไว้วางใจแบบรวมศูนย์:ปัญหาของการรวมศูนย์ของ Oracle สามารถนำไปสู่การปฏิเสธการโจมตีบริการได้อย่างง่ายดาย
การสืบทอดคีย์แบบกระจายอำนาจเป็นไปไม่ได้:หาก oracle มีการกระจายอำนาจ โหนด oracle จะเป็นเจ้าของชาร์ดคีย์ส่วนตัวเท่านั้น อย่างไรก็ตาม โหนด oracle แบบกระจายอำนาจไม่สามารถใช้ BIP 32 โดยตรงสำหรับการได้รับคีย์ตามการแบ่งส่วนคีย์ส่วนตัว
ความเสี่ยงจากการสมรู้ร่วมคิด:หากโหนด oracle สมรู้ร่วมคิดกันหรือกับฝ่ายที่เข้าร่วม ปัญหาความน่าเชื่อถือของเครื่อง oracle ก็ยังไม่ได้รับการแก้ไข จำเป็นต้องมีกลไกการกำกับดูแลที่เชื่อถือได้เพื่อลดความไว้วางใจใน Oracles
แก้ไขปัญหาการเปลี่ยนนิกาย:ลายเซ็นแบบมีเงื่อนไขจำเป็นต้องมีชุดเหตุการณ์ที่นับได้ที่กำหนดไว้ก่อนที่จะสร้างสัญญาเพื่อสร้างธุรกรรม ดังนั้น DLC จะมีขีดจำกัดจำนวนเงินขั้นต่ำสำหรับการแจกจ่ายสินทรัพย์ ส่งผลให้เกิดปัญหาการเปลี่ยนแปลงสกุลเงินคงที่
ด้วยเหตุนี้ บทความนี้จึงเสนอวิธีแก้ปัญหาและแนวคิดในการเพิ่มประสิทธิภาพเพื่อแก้ไขความเสี่ยงและปัญหาของ DLC และปรับปรุงความปลอดภัยของระบบนิเวศ Bitcoin
หลักการ 2.DLC
อลิซและบ็อบลงนามในข้อตกลงการเดิมพัน: เดิมพันว่าค่าแฮชของบล็อก n+kth เป็นเลขคี่หรือเลขคู่ หากเป็นเลขคี่ อลิซจะชนะเกมและสามารถถอนสินทรัพย์ได้ในเวลา t ถ้าเป็นเลขคู่ Bob จะชนะเกมและสามารถถอนสินทรัพย์ได้ในเวลา t เมื่อใช้ DLC ข้อมูลบล็อก n+kth จะถูกส่งผ่าน Oracle เพื่อสร้างลายเซ็นแบบมีเงื่อนไข เพื่อให้ผู้ชนะที่ถูกต้องชนะเนื้อหาทั้งหมด
การเริ่มต้น:เครื่องกำเนิดเส้นโค้งวงรีคือ G และลำดับคือ q
การสร้างคีย์:Oracle, Alice และ Bob สร้างคีย์ส่วนตัวและคีย์สาธารณะของตนเองอย่างเป็นอิสระ
ไพรเวตคีย์ของ oracle คือ z และพับลิกคีย์คือ Z ซึ่งเป็นไปตามความสัมพันธ์ Z=z⋅G;
รหัสส่วนตัวของอลิซคือ x และรหัสสาธารณะของเธอคือ X ซึ่งเป็นไปตามความสัมพันธ์ X=x⋅G;
รหัสส่วนตัวของ Bob คือ y และรหัสสาธารณะของเขาคือ Y ซึ่งเป็นไปตามความสัมพันธ์ Y=y⋅G
ธุรกรรมการเพิ่มทุน:อลิซและบ็อบสร้างธุรกรรมการระดมทุนร่วมกัน โดยแต่ละรายการจะล็อค 1 BTC ในเอาต์พุตหลายลายเซ็น 2 ใน 2 รายการ (คีย์สาธารณะ X หนึ่งอันเป็นของอลิซ และคีย์สาธารณะหนึ่งอัน Y เป็นของ Bob)
ธุรกรรมการดำเนินการตามสัญญา:อลิซและบ็อบสร้างธุรกรรมการดำเนินการตามสัญญา (CET) สองรายการสำหรับธุรกรรมการเพิ่มทุน
ข้อผูกพันของ Oracle Computes
จากนั้นคำนวณ S และ S
ออกอากาศ (R, S, S)
อลิซและบ็อบต่างก็คำนวณคีย์สาธารณะใหม่ที่สอดคล้องกัน
การตั้งถิ่นฐาน:เมื่อบล็อก n+kth ปรากฏขึ้น oracle จะสร้าง s หรือ s ที่สอดคล้องกันตามค่าแฮชของบล็อก
หากแฮชของบล็อก n+k เป็นเลขคี่ oracle จะคำนวณและออกอากาศ s
หากค่าแฮชของบล็อก n+k เป็นเลขคู่ oracle จะคำนวณและออกอากาศ s
ถอนเหรียญ:ผู้เข้าร่วมคนหนึ่ง อลิซหรือบ็อบ สามารถถอนสินทรัพย์ตามการออกอากาศของ oracle
หาก oracle ออกอากาศ อลิซสามารถคำนวณคีย์ส่วนตัวใหม่ sk^{Alice} และถอน 2 BTC ที่ถูกล็อค
หาก oracle ออกอากาศ s Bob สามารถคำนวณคีย์ส่วนตัวใหม่ sk^{Bob} และถอน 2 BTC ที่ล็อคไว้
การวิเคราะห์: คีย์ส่วนตัวใหม่ sk^{Alice} ที่คำนวณโดย Alice และคีย์สาธารณะใหม่ PK^{Alice} เป็นไปตามความสัมพันธ์ลอการิทึมแบบไม่ต่อเนื่อง
ในกรณีนี้ การถอนเงินของอลิซจะสำเร็จ
ในทำนองเดียวกัน คีย์ส่วนตัวใหม่ sk^{Bob} ที่คำนวณโดย Bob และคีย์สาธารณะใหม่ PK^{Bob} เป็นไปตามความสัมพันธ์ลอการิทึมแบบไม่ต่อเนื่อง
ในกรณีนี้การถอนเงินของ Bob จะสำเร็จ
นอกจากนี้ หาก oracle ออกอากาศ มันจะมีประโยชน์สำหรับ Alice แต่ไม่ใช่สำหรับ Bob เนื่องจาก Bob ไม่สามารถใช้คำนวณคีย์ส่วนตัวใหม่ที่สอดคล้องกัน sk^{Bob} ในทำนองเดียวกัน ถ้า oracle ออกอากาศ s มันจะมีประโยชน์สำหรับ Bob แต่ไม่ใช่สำหรับ Alice เนื่องจากอลิซไม่สามารถใช้ในการคำนวณคีย์ส่วนตัวใหม่ที่เกี่ยวข้อง sk^{Alice}
ในที่สุด คำอธิบายข้างต้นจะละเว้นการล็อคเวลา จำเป็นต้องเพิ่มการล็อคเวลาเพื่อให้ฝ่ายหนึ่งสามารถคำนวณคีย์ส่วนตัวใหม่และถอนเหรียญได้ภายในเวลา t มิฉะนั้น หากเกินเวลา t อีกฝ่ายสามารถถอนทรัพย์สินได้โดยใช้รหัสส่วนตัวดั้งเดิม
3.การเพิ่มประสิทธิภาพ DLC
3.1 การจัดการคีย์
ในโปรโตคอล DLC คีย์ส่วนตัวของ oracle และหมายเลขสุ่มที่สัญญาไว้มีความสำคัญ หากคีย์ส่วนตัวของ oracle และหมายเลขสุ่มที่สัญญาไว้รั่วไหลหรือสูญหาย จะนำไปสู่ปัญหาด้านความปลอดภัย 4 ประการดังต่อไปนี้:
(1) เครื่อง Oracle สูญเสียคีย์ส่วนตัว z
หาก oracle สูญเสียคีย์ส่วนตัว คุณจะไม่สามารถชำระ DLC ได้ ส่งผลให้จำเป็นต้องดำเนินการตามสัญญาคืนเงิน DLC ดังนั้น ธุรกรรมการคืนเงินจึงได้รับการตั้งค่าในโปรโตคอล DLC เพื่อป้องกันไม่ให้ oracle สูญเสียคีย์ส่วนตัว
(2) เครื่อง Oracle ทำให้คีย์ส่วนตัว z รั่วไหล
หากคีย์ส่วนตัวของ oracle รั่วไหล DLC ทั้งหมดที่ใช้คีย์ส่วนตัวจะเสี่ยงต่อการถูกระงับคดีด้วยการฉ้อโกง ผู้โจมตีที่ขโมยคีย์ส่วนตัวสามารถลงนามในข้อความใดก็ได้ที่พวกเขาต้องการ และสามารถควบคุมผลลัพธ์ของสัญญาในอนาคตทั้งหมดได้อย่างสมบูรณ์ นอกจากนี้ ผู้โจมตีไม่ได้จำกัดอยู่เพียงการเผยแพร่ข้อความที่ลงนามเพียงข้อความเดียว แต่ยังสามารถเผยแพร่ข้อความที่ขัดแย้งกัน เช่น การลงนามในบล็อก n+kth ด้วยแฮชคี่และคู่ในเวลาเดียวกัน
(3) เครื่องออราเคิลรั่วหรือใช้หมายเลขสุ่ม k ซ้ำ
หาก oracle รั่วไหลตัวเลขสุ่ม k ดังนั้นในระหว่างขั้นตอนการชำระบัญชี ไม่ว่าออราเคิลจะออกอากาศ s หรือ s ผู้โจมตีสามารถคำนวณคีย์ส่วนตัว z ของ oracle ได้ดังต่อไปนี้
หากเครื่อง Oracle นำตัวเลขสุ่ม k กลับมาใช้ใหม่ หลังจากการชำระหนี้ 2 ครั้ง ผู้โจมตีสามารถแก้ระบบสมการตามลายเซ็นที่ออกอากาศโดยเครื่อง Oracle และคำนวณคีย์ส่วนตัว z ของเครื่อง Oracle ตามหนึ่งในสี่สถานการณ์ต่อไปนี้ : :
กรณีที่ 1:
กรณีที่ 2:
กรณีที่ 3:
กรณีที่ 4:
(4) เครื่องออราเคิลสูญเสียตัวเลขสุ่ม k
หาก oracle สูญเสียหมายเลขสุ่ม k จะไม่สามารถชำระ DLC ที่เกี่ยวข้องได้ และจำเป็นต้องดำเนินการตามสัญญาการคืนเงิน DLC
ดังนั้น เพื่อปรับปรุงความปลอดภัยของคีย์ส่วนตัวของ Oracle จึงควรใช้ BIP 32 เพื่อรับคีย์ลูกหรือหลานสำหรับลายเซ็น นอกจากนี้ เพื่อปรับปรุงความปลอดภัยของตัวเลขสุ่ม ค่าแฮช k:=hash(z, ตัวนับ) ของคีย์ส่วนตัวและตัวนับควรใช้เป็นตัวเลขสุ่ม k เพื่อป้องกันไม่ให้ตัวเลขสุ่มซ้ำหรือสูญหาย
3.2 ออราเคิลแบบกระจายอำนาจ
ใน DLC ออราเคิลมีบทบาทสำคัญในการให้ข้อมูลภายนอกที่สำคัญซึ่งกำหนดผลลัพธ์ของสัญญา เพื่อปรับปรุงความปลอดภัยของสัญญาเหล่านี้ จำเป็นต้องมีออราเคิลแบบกระจายอำนาจ ออราเคิลแบบกระจายอำนาจแตกต่างจากออราเคิลแบบรวมศูนย์ กระจายความรับผิดชอบในการให้ข้อมูลที่ถูกต้องและป้องกันการงัดแงะผ่านโหนดอิสระหลายโหนด ซึ่งสามารถลดความเสี่ยงในการพึ่งพาจุดล้มเหลวเพียงจุดเดียว และลดความเป็นไปได้ของการยักย้ายหรือการโจมตีแบบกำหนดเป้าหมาย ด้วยออราเคิลแบบกระจายอำนาจ DLC สามารถบรรลุระดับความน่าเชื่อถือและความน่าเชื่อถือที่สูงขึ้น ทำให้มั่นใจได้ว่าการดำเนินการตามสัญญาจะขึ้นอยู่กับความเป็นกลางของเงื่อนไขที่กำหนดไว้ล่วงหน้าทั้งหมด
ลายเซ็นเกณฑ์ Schnorr เปิดใช้งาน Oracle แบบกระจายอำนาจ ลายเซ็นเกณฑ์ Schnorr มีข้อดีดังต่อไปนี้:
การรักษาความปลอดภัยขั้นสูง:ด้วยการจัดการคีย์แบบกระจายอำนาจ ลายเซ็นเกณฑ์จะช่วยลดความเสี่ยงของความล้มเหลวเพียงจุดเดียว แม้ว่ากุญแจของผู้เข้าร่วมบางคนจะรั่วไหลหรือถูกโจมตี ระบบทั้งหมดยังคงปลอดภัยตราบใดที่ไม่เกินเกณฑ์ที่ตั้งไว้
การควบคุมแบบกระจาย:ลายเซ็นเกณฑ์ทำให้เกิดการควบคุมแบบกระจายของการจัดการคีย์ และไม่มีหน่วยงานใดมีอำนาจในการลงนามทั้งหมด ซึ่งจะช่วยลดความเสี่ยงที่เกิดจากการรวมตัวของอำนาจที่มากเกินไป
ปรับปรุงการใช้งาน:ลายเซ็นจะต้องได้รับการตกลงโดยโหนด Oracle จำนวนหนึ่งเท่านั้น ซึ่งช่วยเพิ่มความยืดหยุ่นและความพร้อมใช้งานของระบบ แม้ว่าบางโหนดจะไม่พร้อมใช้งาน แต่ก็จะไม่ส่งผลกระทบต่อการทำงานที่เชื่อถือได้ของระบบโดยรวม
ความยืดหยุ่นและความสามารถในการปรับขนาด:โปรโตคอลลายเซ็นขีดจำกัดสามารถกำหนดเกณฑ์ที่แตกต่างกันตามความจำเป็นเพื่อปรับให้เข้ากับข้อกำหนดและสถานการณ์ด้านความปลอดภัยต่างๆ นอกจากนี้ยังเหมาะสำหรับเครือข่ายขนาดใหญ่และมีความสามารถในการขยายขนาดที่ดี
ความรับผิดชอบ:โหนด Oracle แต่ละโหนดสร้างแฟรกเมนต์ลายเซ็นสำหรับข้อความโดยอิงตามแฟรกเมนต์คีย์ส่วนตัว และผู้เข้าร่วมรายอื่นสามารถใช้แฟรกเมนต์คีย์สาธารณะที่เกี่ยวข้องเพื่อตรวจสอบความถูกต้องของแฟรกเมนต์ลายเซ็นเพื่อให้บรรลุความรับผิดชอบ หากถูกต้อง ส่วนของลายเซ็นจะถูกสะสมเพื่อสร้างลายเซ็นที่สมบูรณ์
ดังนั้น โปรโตคอลลายเซ็นเกณฑ์ Schnorr จึงมีข้อได้เปรียบที่สำคัญใน Oracle แบบกระจายอำนาจ ซึ่งปรับปรุงความปลอดภัย ความน่าเชื่อถือ ความยืดหยุ่น ความสามารถในการปรับขนาด และความรับผิดชอบ
3.3 การกระจายอำนาจการเชื่อมต่อและการจัดการที่สำคัญ
ในเทคโนโลยีการจัดการคีย์ เครื่อง Oracle มีคีย์ z ที่สมบูรณ์ โดยขึ้นอยู่กับคีย์ z ที่สมบูรณ์และการเพิ่มขึ้น ω โดยใช้ BIP 32 จะสามารถส่งคีย์ย่อยจำนวนมาก z+{ω }^{(1) } และความลับของดวงอาทิตย์ คีย์ z+ω ^{( 1)}+ω ^{( 2)} สำหรับเหตุการณ์ที่แตกต่างกัน ออราเคิลสามารถใช้แกรนด์คีย์ส่วนตัวที่แตกต่างกัน z+ω ^{(1)}+ω ^{(2)} เพื่อสร้างลายเซ็นที่สอดคล้องกัน σ สำหรับข้อความเหตุการณ์ที่เกี่ยวข้อง
ในสถานการณ์แอปพลิเคชัน Oracle แบบกระจายอำนาจ มีผู้เข้าร่วม n คน และผู้เข้าร่วม t+1 จะต้องดำเนินการลงนามตามเกณฑ์ ในหมู่พวกเขาที. โหนด oracle แต่ละโหนดมีส่วนแบ่งคีย์ส่วนตัว z_i, i= 1,..., n แฟรกเมนต์คีย์ส่วนตัว n z_i เหล่านี้สอดคล้องกับคีย์ส่วนตัว z ที่สมบูรณ์ แต่คีย์ส่วนตัว z ที่สมบูรณ์ไม่ปรากฏตั้งแต่ต้นจนจบ ภายใต้สมมติฐานที่ว่าไพรเวตคีย์ z ที่สมบูรณ์ไม่ปรากฏ โหนด oracle t+ 1 ใช้แฟรกเมนต์คีย์ส่วนตัว z_i, i= 1,..., t+ 1 เพื่อสร้างแฟรกเมนต์ลายเซ็น σ_i และแฟรกเมนต์ลายเซ็น σ_i สำหรับข้อความ msg ที่ผสานเข้าด้วยกัน ลายเซ็นที่สมบูรณ์ σ ผู้ตรวจสอบใช้คีย์สาธารณะ Z ที่สมบูรณ์เพื่อตรวจสอบความถูกต้องของคู่ลายเซ็นข้อความ (msg,σ ) เนื่องจากต้องใช้โหนด oracle t+ 1 เพื่อร่วมกันสร้างเกณฑ์ลายเซ็น จึงมีความปลอดภัยสูง
อย่างไรก็ตาม ในสถานการณ์แอปพลิเคชัน Oracle แบบกระจายอำนาจ คีย์ส่วนตัว z ที่สมบูรณ์จะไม่ปรากฏขึ้น และไม่สามารถใช้ BIP 32 สำหรับการรับคีย์โดยตรง กล่าวอีกนัยหนึ่ง เทคโนโลยีการกระจายอำนาจของ Oracle และเทคโนโลยีการจัดการคีย์ไม่สามารถเชื่อมโยงโดยตรงได้
กระดาษDistributed Key Derivation for Multi-Party Management of Blockchain Digital Assetsมีการเสนอวิธีการสืบทอดคีย์แบบกระจายในสถานการณ์จำลองลายเซ็นขีดจำกัดแนวคิดหลักของบทความนี้คือตามพหุนามการแก้ไขลากรองจ์ แฟรกเมนต์คีย์ส่วนตัว z_i และคีย์ส่วนตัว z ที่สมบูรณ์เป็นไปตามความสัมพันธ์ของการประมาณค่าต่อไปนี้
เมื่อบวกส่วนเพิ่ม ω ทั้งสองข้างของสมการข้างต้น เราจะได้สมการต่อไปนี้
สมการนี้แสดงให้เห็นว่า: ส่วนของคีย์ส่วนตัว z_i บวกส่วนเพิ่ม ω ยังคงเป็นไปตามความสัมพันธ์ของการประมาณค่าด้วยคีย์ส่วนตัว z ที่สมบูรณ์ บวกส่วนเพิ่ม ω กล่าวอีกนัยหนึ่ง แฟรกเมนต์คีย์ย่อยไพรเวต z_i+ω และคีย์ย่อย z+ω เป็นไปตามความสัมพันธ์ของการประมาณค่า ดังนั้น ผู้เข้าร่วมแต่ละคนสามารถใช้แฟรกเมนต์คีย์ส่วนตัว z_i บวกส่วนเพิ่ม ω เพื่อรับแฟรกเมนต์คีย์ส่วนตัวย่อย z_i+ω สำหรับการสร้างแฟรกเมนต์ย่อยของลายเซ็น และใช้คีย์สาธารณะย่อยที่สอดคล้องกัน Z+ω ⋅ G เพื่อทำการตรวจสอบความถูกต้อง .
อย่างไรก็ตาม BIP ที่ปรับปรุงแล้วและที่ไม่ได้รับการปรับปรุงจะต้องได้รับการพิจารณา 32 BIP 32 ที่ปรับปรุงแล้วรับคีย์ส่วนตัว รหัสลูกโซ่ และเส้นทางเป็นอินพุต คำนวณ SHA 512 และส่งออกเดลต้าและรหัสลูกโซ่ย่อย BIP 32 ที่ไม่ได้รับการปรับปรุงจะใช้คีย์สาธารณะ รหัสลูกโซ่ และเส้นทางเป็นอินพุต คำนวณ SHA 512 และส่งออกเดลต้าและรหัสลูกโซ่ย่อย ในกรณีของลายเซ็นขีดจำกัด จะไม่มีคีย์ส่วนตัว ดังนั้นจึงสามารถใช้ได้เฉพาะ BIP 32 ที่ไม่ได้รับการปรับปรุงเท่านั้น หรือใช้ฟังก์ชันแฮชโฮโมมอร์ฟิกก็มี BIP 32 ที่ปรับปรุงแล้ว อย่างไรก็ตาม ฟังก์ชันแฮชแบบโฮโมมอร์ฟิกแตกต่างจาก SHA 512 และเข้ากันไม่ได้กับ BIP 32 ดั้งเดิม
3.4 OP-DLC: การลดความน่าเชื่อถือของ Oracle
ใน DLC สัญญาระหว่างอลิซและบ็อบจะดำเนินการตามผลลัพธ์ของลายเซ็นของ Oracle ดังนั้น Oracle จึงต้องได้รับความเชื่อถือในระดับหนึ่ง ดังนั้น ลักษณะการทำงานที่ถูกต้องของเครื่อง Oracle จึงเป็นข้อกำหนดเบื้องต้นที่สำคัญสำหรับการทำงานของ DLC
เพื่อไม่ให้เชื่อใจ oracles จึงมีการวิจัยเกี่ยวกับการแสดง DLC โดยอิงจากผลลัพธ์ของ n oracles เพื่อลดการพึ่งพา oracle ตัวเดียว
"n-of-n"แบบจำลองนี้แสดงถึงการใช้ n oracles เพื่อลงนามในสัญญาและดำเนินการตามสัญญาตามผลลัพธ์ของ n oracles โมเดลนี้ต้องใช้ oracles ทั้งหมดในการลงชื่อออนไลน์ หาก oracle ออฟไลน์หรือมีความขัดแย้งเกี่ยวกับผลลัพธ์ จะส่งผลต่อการดำเนินการตามสัญญา DLC ข้อสันนิษฐานของความไว้วางใจก็คือว่านักพยากรณ์ทุกคนมีความซื่อสัตย์
"k-of-n"แบบจำลองบ่งชี้ว่ามีการใช้ oracles n อันเพื่อลงนามในสัญญา และสัญญาได้รับการดำเนินการตามผลลัพธ์ของ k oracles หากมีการสมรู้ร่วมคิดมากกว่า k oracles จะส่งผลต่อการดำเนินการตามสัญญาอย่างยุติธรรม นอกจากนี้ให้ใช้"k-of-n"โมเดลจำนวน CET ที่ต้องเตรียมคือ oracle เดียวหรือ"n-of-n"C_n^k เท่าของโมเดล ข้อสันนิษฐานของความไว้วางใจก็คือ อย่างน้อย k oracles จาก n oracles มีความซื่อสัตย์
การเพิ่มจำนวนเครื่อง Oracle ไม่ได้ทำให้เกิดความไม่ไว้วางใจจากเครื่อง Oracle เพราะเมื่อออราเคิลทำสิ่งชั่วร้าย ผู้เสียหายในสัญญาไม่มีช่องทางอุทธรณ์ในห่วงโซ่
ดังนั้นในส่วนนี้จึงเสนอ OP-DLC ซึ่งแนะนำกลไกความท้าทายในแง่ดีใน DLCก่อนที่จะเข้าร่วมในการตั้งค่า DLC นั้น n oracles จำเป็นต้องให้คำมั่นสัญญาล่วงหน้าเพื่อสร้างเกม OP บนเครือข่ายที่ไม่ได้รับอนุญาต และสัญญาว่าจะไม่ทำสิ่งชั่วร้าย หากออราเคิลตัวใดกระทำการชั่วร้าย อลิซหรือบ็อบ หรือออราเคิลที่ซื่อสัตย์อื่นๆ หรือผู้สังเกตการณ์ที่ซื่อสัตย์บุคคลที่สามอื่นๆ ก็สามารถเริ่มต้นการท้าทายได้ หากผู้ท้าชิงชนะเกม Oracle ชั่วร้ายจะถูกลงโทษบนโซ่และเงินมัดจำจะถูกริบ นอกจากนี้ยังสามารถใช้ OP-DLC ได้อีกด้วย"k-of-n"รุ่นที่จะลงนาม โดยที่ k สามารถเป็น 1 ได้ ดังนั้นสมมติฐานด้านความไว้วางใจจึงลดลงเหลือเพียงตราบใดที่มีผู้เข้าร่วมที่ซื่อสัตย์ในเครือข่าย ความท้าทาย OP ก็สามารถเกิดขึ้นได้เพื่อลงโทษโหนด oracle ที่ชั่วร้าย
เมื่อตั้งค่า OP-DLC ตามผลการคำนวณเลเยอร์ 2:
หาก oracle ใช้ลายเซ็นผลลัพธ์ที่ไม่ถูกต้อง ทำให้ผลประโยชน์ของ Alice เสียหาย Alice สามารถใช้เลเยอร์ 2 เพื่อคำนวณผลลัพธ์ได้อย่างถูกต้องและท้าทายเกม OP บนห่วงโซ่ที่ไม่ได้รับอนุญาตซึ่ง oracle ได้ให้คำมั่นไว้ล่วงหน้า อลิซชนะเกมนี้ ลงโทษผู้พยากรณ์ที่ชั่วร้าย และชดเชยความสูญเสีย
ในทำนองเดียวกัน Bob, Oracle Node ที่ซื่อสัตย์อื่นๆ และผู้สังเกตการณ์ที่ซื่อสัตย์บุคคลที่สาม ล้วนสามารถเริ่มต้นความท้าทายได้ อย่างไรก็ตาม เพื่อป้องกันความท้าทายที่เป็นอันตราย ผู้ท้าชิงยังต้องเดิมพันด้วย
ดังนั้น OP-DLC จึงทำให้โหนดของ Oracle สามารถดูแลซึ่งกันและกัน และลดความน่าเชื่อถือของ Oracle ให้เหลือน้อยที่สุด กลไกนี้ต้องการผู้เข้าร่วมที่ซื่อสัตย์เพียงคนเดียวและมีอัตราการยอมรับข้อผิดพลาดที่ 99% ซึ่งจะช่วยแก้ปัญหาความเสี่ยงของการสมรู้ร่วมคิดของ Oracle ได้ดีกว่า
3.5 OP-DLC + BitVM ดูอัลบริดจ์
เมื่อใช้ DLC เป็นสะพานข้ามสายโซ่ จำเป็นต้องมีการจัดสรรเงินทุนเมื่อสัญญา DLC ได้รับการชำระ:
ต้องตั้งค่าล่วงหน้าผ่าน CET ซึ่งหมายความว่ารายละเอียดการชำระหนี้ของ DLC นั้นมีจำกัด เช่น รายละเอียด 0.1 BTC ของเครือข่าย Bison มีปัญหา: การโต้ตอบสินทรัพย์ของผู้ใช้ในเลเยอร์ 2 ไม่ควรจำกัดอยู่เพียงรายละเอียดการระดมทุนของ DLC CET
เมื่อ Alice ต้องการชำระทรัพย์สินในเลเยอร์ 2 ของเธอ ทรัพย์สินในเลเยอร์ 2 ของผู้ใช้ Bob จะถูกบังคับให้ชำระไปยังเลเยอร์ 1 ด้วย มีปัญหา: ผู้ใช้ Layer 2 แต่ละคนควรสามารถเลือกฝากและถอนเงินได้อย่างอิสระโดยไม่ได้รับผลกระทบจากการฝากและถอนเงินของผู้ใช้รายอื่น
อลิซและบ็อบเจรจาเรื่องค่าใช้จ่าย มีปัญหาคือทั้งสองฝ่ายจะต้องเต็มใจที่จะร่วมมือ
ดังนั้นเพื่อแก้ไขปัญหาข้างต้น ส่วนนี้ขอเสนอบริดจ์คู่ OP-DLC + BitVM โซลูชันนี้ช่วยให้ผู้ใช้ฝากและถอนเงินผ่านสะพานที่ไม่ได้รับอนุญาตของ BitVM และยังฝากและถอนเงินผ่านกลไก OP-DLC ทำให้เกิดการเปลี่ยนแปลงในทุกรายละเอียดและปรับปรุงสภาพคล่องของเงินทุน
ใน OP-DLC นั้น oracle คือ BitVM Alliance, Alice เป็นผู้ใช้ทั่วไป และ Bob คือ BitVM Alliance เมื่อตั้งค่า OP-DLC ใน CET ที่สร้างขึ้น ผลลัพธ์ไปยังผู้ใช้ Alice สามารถใช้ได้ทันทีบนเลเยอร์ 1 และในเอาต์พุตไปยัง Bob จะมีการสร้าง เกม DLC ที่ Alice สามารถเข้าร่วมในการท้าทายได้ และมีการล็อคการล็อกเวลา กำหนดระยะเวลาแล้ว เมื่ออลิซต้องการถอนเงิน:
หาก BitVM Alliance ทำหน้าที่เป็นออราเคิลและลงนามอย่างถูกต้อง Alice ก็สามารถถอนเงินในเลเยอร์ 1 ได้ อย่างไรก็ตาม Bob รอให้ระยะเวลาล็อคอินสิ้นสุดลงก่อนที่เขาจะสามารถถอนเงินในเลเยอร์ 1 ได้
หาก BitVM Alliance ทำหน้าที่เป็นออราเคิลและโปรแกรมโกง ผลประโยชน์ของ Alice จะเสียหาย อย่างไรก็ตาม อลิซสามารถท้าทาย UTXO ของบ็อบได้ หากการท้าทายสำเร็จ จำนวนเงินของ Bob จะถูกยกเลิก หมายเหตุ: หนึ่งในสมาชิก BitVM Alliance อื่นๆ ก็สามารถเริ่มต้นการท้าทายได้เช่นกัน แต่ Alice มีแรงจูงใจมากที่สุดที่จะเริ่มการท้าทายเนื่องจากผลประโยชน์ของเธอได้รับอันตราย
หาก BitVM Alliance ทำหน้าที่เป็นออราเคิลและกลโกง ผลประโยชน์ของ Bob จะเสียหาย อย่างไรก็ตาม สมาชิกที่ซื่อสัตย์ของ BitVM Alliance สามารถท้าทาย เกม BitVM และลงโทษการโกงโหนด oracle ได้
นอกจากนี้ เมื่อผู้ใช้ Alice ต้องการถอนเงินจากเลเยอร์ 2 แต่ CET ที่กำหนดไว้ล่วงหน้าในสัญญา OP-DLC ไม่ตรงกับจำนวนเงิน Alice สามารถเลือกวิธีการต่อไปนี้:
การถอนผ่าน BitVM นั้นขั้นสูงโดยตัวดำเนินการ BitVM บนเลเยอร์ 1 บริดจ์ BitVM ถือว่าผู้เข้าร่วมที่ซื่อสัตย์ในกลุ่ม BitVM
ถอนเงินผ่าน CET ที่กำหนดใน OP-DLC และการเปลี่ยนแปลงที่เหลือจะดำเนินการขั้นสูงโดยตัวดำเนินการ BitVM ในเลเยอร์ 1 การถอน OP-DLC จะปิดช่องทาง DLC แต่เงินทุนที่เหลืออยู่ในช่อง DLC จะถูกโอนไปยังกลุ่มกองทุน BitVM Layer 1 โดยไม่บังคับให้ผู้ใช้ Layer 2 รายอื่นถอนเงิน ความน่าเชื่อถือของบริดจ์ OP-DLC จะถือว่ามีผู้เข้าร่วมที่ซื่อสัตย์ในช่อง
อลิซและบ็อบเจรจาเรื่องต้นทุนโดยไม่ต้องมีส่วนร่วมของออราเคิลแมชชีน โดยต้องได้รับความร่วมมือจากบ็อบ
ดังนั้น dual-bridge OP-DLC + BitVM จึงมีข้อดีดังต่อไปนี้:
การใช้ BitVM แก้ปัญหาการเปลี่ยนแปลงกองทุนช่อง DLC ลดจำนวนการตั้งค่า CET และไม่ได้รับผลกระทบจากรายละเอียดกองทุน CET
การรวมสะพาน OP-DLC และสะพาน BitVM ช่วยให้ผู้ใช้มีช่องทางการถอนและฝากเงินหลายช่องทาง และเปลี่ยนแปลงได้ทุกรายละเอียด
ตั้งค่าการเชื่อมโยง BitVM ให้เป็น Bob และ oracle และลดความน่าเชื่อถือของ oracle ผ่านกลไก OP
แนะนำยอดการถอนของช่อง DLC ลงในกลุ่มกองทุน BitVM Bridge เพื่อปรับปรุงการใช้เงินทุน
4 บทสรุป
DLC ปรากฏขึ้นก่อนการเปิดใช้งาน Segwit v1 (Taproot) และมีการใช้การผสานรวมช่อง DLC กับ Lightning Network และ DLC ได้รับการขยายเพื่ออัปเดตและดำเนินการสัญญาอย่างต่อเนื่องภายในช่อง DLC เดียวกัน ด้วยความช่วยเหลือของเทคโนโลยี เช่น Taproot และ BitVM การยืนยันสัญญาแบบออฟไลน์ที่ซับซ้อนยิ่งขึ้นและการชำระหนี้สามารถทำได้ภายใน DLC ในขณะที่เมื่อรวมกับกลไกการท้าทาย OP ก็สามารถลดความไว้วางใจของ oracle ให้เหลือน้อยที่สุดได้
การอ้างอิง
IOS
Android