ทำความเข้าใจความสามารถในการโปรแกรมของ CKB จากการเขียนโปรแกรมแอปพลิเคชัน Bitcoin

Odaily资深作者

2023-11-03 14:04 (UTC+8)

บทความนี้มีประมาณ 11786 คำ การอ่านทั้งหมดใช้เวลาประมาณ 17 นาที

บทความนี้เริ่มต้นจากการเขียนโปรแกรมแอปพลิเคชันของ BTC UTXO ซึ่งเป็นโครงสร้างที่ถูกจำกัดมากกว่า CKB Cell และเสนอวิธีการทำความเข้าใจความสามารถในการโปรแกรมของ CKB Cell

สรุปโดย AI

ผู้เขียนต้นฉบับ: อาเจียน

สรุป

การทำความเข้าใจความสามารถในการโปรแกรมของระบบจำเป็นต้องระบุลักษณะโครงสร้างของระบบ การสำรวจการเขียนโปรแกรมแอปพลิเคชันโดยใช้สคริปต์ Bitcoin ช่วยให้เราเข้าใจโครงสร้างพื้นฐานของ CKB Cell และกระบวนทัศน์การเขียนโปรแกรม ไม่เพียงเท่านั้น ยังสามารถแบ่งองค์ประกอบการเขียนโปรแกรมของ CKB ออกเป็นส่วนที่เหมาะสม และช่วยให้เราเข้าใจความสามารถในการตั้งโปรแกรมที่ได้รับจากแต่ละส่วน

I. บทนำ

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

ลักษณะโครงสร้างของระบบสัญญาอัจฉริยะประกอบด้วย:

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

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

ตัวอย่างเช่น ผู้คนมักจะใช้ Ethereum เป็นตัวอย่างของความสามารถในการโปรแกรมที่ดี อย่างไรก็ตาม รูปแบบพื้นฐานของการแสดงออกของรัฐใน Ethereum คือบัญชี และเป็นการยากที่จะตั้งโปรแกรมสัญญาแบบ peer-to-peer (เช่น ช่องทางการชำระเงิน แบบหนึ่งต่อ -หนึ่งสัญญาการเดิมพัน) — — มันไม่ได้เป็นไปไม่ได้เลย มันเป็นเพียงการไม่เห็นคุณค่า ไม่ใช่ว่าระบบนิเวศของ Ethereum ไม่เคยมีโครงการที่พยายามใช้ช่องทางการชำระเงิน/ช่องทางสถานะ และมีการอภิปรายทางทฤษฎีมากมาย แต่โครงการเหล่านี้ดูเหมือนจะไม่ได้ใช้งาน ณ วันนี้ - เห็นได้ชัดว่าสิ่งนี้ไม่สามารถนำมาประกอบกับนักพัฒนาที่ไม่ได้ทำงานหนัก ไม่ใช่เรื่องบังเอิญที่โครงการต่างๆ ที่ใช้งานบน Ethereum ในปัจจุบันทั้งหมดจะอยู่ในรูปแบบของ กลุ่มกองทุน มากกว่า สัญญาแบบจุดต่อจุด ในทำนองเดียวกัน ผู้คนอาจพอใจกับความสามารถในการโปรแกรมของ Ethereum มาก แต่เมื่อพูดถึงการบรรลุ การแยกบัญชี (ซึ่งสามารถเข้าใจได้ว่าเป็นแนวคิดทั่วไปของกระเป๋าเงิน) โมเดลบัญชียังขาดอยู่โดยธรรมชาติ

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

โชคดีที่สัญญาอันชาญฉลาดของ Bitcoin ดูเหมือนจะเป็นรากฐานที่ดีที่สุดสำหรับเราในการทำความเข้าใจความสามารถในการโปรแกรมของ CKB นี่ไม่เพียงเพราะรูปแบบพื้นฐานของการแสดงออกของ Bitcoin ยังเป็นผลลัพธ์ของธุรกรรมด้วย (เรียกว่า UTXO) แต่ยังเป็นเพราะด้วยความช่วยเหลือของแนวคิด พันธสัญญา ที่เสนอโดยชุมชน Bitcoin เราสามารถเข้าใจได้ว่า CKB มีลักษณะโครงสร้างข้างต้น และความสามารถในการโปรแกรมเพิ่มขึ้นโดยการแบ่งเอฟเฟกต์สุดท้ายออกเป็นหลายส่วนอย่างเหมาะสมและระบุทีละส่วน

2. CKB กับ BTC: มีอะไรมากกว่านั้น?

(1) โครงสร้างพื้นฐาน

เนื่องจากเป็นรูปแบบพื้นฐานของการแสดงออกของสถานะของ Bitcoin UTXO ของ Bitcoin (“Unspent Transaction Output”) จึงมีสองช่อง:

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

เมื่อเปรียบเทียบกับระบบสัญญาอัจฉริยะรุ่นหลัง สคริปต์ Bitcoin ค่อนข้างจำกัด:

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

แม้ว่าสคริปต์ประเภทนี้จะมีจำกัด แต่ก็ไม่ได้ขาดความสามารถในการตั้งโปรแกรมแอปพลิเคชันที่น่าทึ่ง และยังเป็นพื้นฐานสำหรับการสำรวจความสามารถในการโปรแกรม CKB ของเราอีกด้วย จะมีส่วนพิเศษในภายหลังเพื่อแนะนำตัวอย่างการเขียนโปรแกรมสคริปต์ Bitcoin สองตัวอย่าง

ในทางตรงกันข้าม หน่วยสถานะของ CKB เรียกว่า เซลล์ และมีสี่ฟิลด์:

ความจุ ซึ่งคล้ายกับจำนวน UTXO จะแสดงขนาดของพื้นที่ที่เซลล์สามารถใช้ได้ในหน่วยไบต์
Lock Script ซึ่งเป็นคีย์สาธารณะของสคริปต์ที่คล้ายกับ UTXO กำหนดความเป็นเจ้าของเซลล์ เฉพาะเมื่อข้อมูลที่ให้ไว้สามารถผ่าน Lock Script ได้เท่านั้น เซลล์จึงสามารถ อัปเดต ได้ (อาจกล่าวได้ว่าจะปล่อยเซลล์และใช้ความสามารถเหล่านี้ เพื่อสร้างเซลล์ใหม่) ;
ข้อมูล ข้อมูล ข้อมูลใดๆ ปริมาณข้อมูลจะถูกจำกัดด้วยความจุ
Type Script ซึ่งเป็นสคริปต์เสริม ใช้เพื่อกำหนดเงื่อนไขสำหรับการอัปเดตข้อมูล

นอกจากนี้ Lock Script และ Type Script สามารถตั้งโปรแกรมการคำนวณได้ตามใจชอบ คุณสามารถตั้งโปรแกรมอัลกอริธึมการตรวจสอบลายเซ็นใดๆ ก็ได้ คุณยังสามารถตั้งโปรแกรมการตรวจสอบภาพล่วงหน้าสำหรับอัลกอริธึมแฮชและอื่นๆ ได้อีกด้วย

ผู้อ่านสามารถเห็นการปรับปรุงความสามารถในการโปรแกรมของ Cell ได้อย่างง่ายดายเมื่อเทียบกับ UTXO:

เซลล์สามารถตั้งโปรแกรมการคำนวณตามอำเภอใจแทนการคำนวณบางอย่างเท่านั้น การตรวจสอบความเป็นเจ้าของจะมีความยืดหยุ่นมากขึ้น
เนื่องจากช่อง Data และ Type Script เซลล์จึงสามารถบันทึกสถานะเพิ่มเติมได้ ซึ่งจะช่วยให้เซลล์พกพาสิ่งที่เรียกว่า UDT (โทเค็นที่ผู้ใช้กำหนด) ได้

เมื่อรวมเข้ากับโครงสร้าง transaction output ของ Cell เอง ประโยชน์ที่ทั้งสองจุดนี้จะได้รับนั้นยิ่งใหญ่มาก อย่างไรก็ตาม จากคำอธิบายข้างต้นเพียงอย่างเดียว เรายังไม่รู้ว่า Cell ใช้งาน สัญญาหนึ่งเข้าถึงสัญญาอื่นตอนรันไทม์อย่างไร “สถานะ” ของ ในการทำเช่นนี้ เราต้องหันไปใช้แนวคิดที่ชุมชน Bitcoin พูดคุยกันมานานแล้ว: “พันธสัญญา”

(2) ข้อจำกัดและการวิปัสสนา

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

Rusty Russell ชี้ให้เห็นอย่างถูกต้องว่าข้อจำกัดสามารถเข้าใจได้ว่าเป็นความสามารถ วิปัสสนา ของธุรกรรม นั่นคือเมื่อ UTXO A ถูกใช้ไปโดยธุรกรรม B ตัวดำเนินการสคริปต์สามารถอ่านบางส่วน (หรือทั้งหมด) ของธุรกรรม B จากนั้นตรวจสอบว่าตรงกับพารามิเตอร์ที่สคริปต์ต้องการล่วงหน้า ตัวอย่างเช่น สคริปต์พับลิกคีย์ของเอาต์พุตแรกของธุรกรรม A สอดคล้องกับพับลิกคีย์สคริปต์ของ UTXO A หรือไม่ (นี่คือความหมายดั้งเดิมของส่วนคำสั่งข้อจำกัด)

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

จากสิ่งนี้ เราสามารถแบ่งความสามารถในการวิปัสสนาโดยสมบูรณ์นี้ออกเป็นสี่สถานการณ์:

Lock Script อ่านสคริปต์ล็อคอื่นๆ (อินพุตและเอาต์พุต)
Lock Script อ่านสคริปต์ประเภทอื่นๆ (อินพุตและเอาต์พุต) (และข้อมูล)
Type Script อ่านสคริปต์ล็อคอื่นๆ (อินพุตและเอาต์พุต)
Type Script อ่านอื่นๆ (อินพุตและเอาต์พุต) Type Script (และข้อมูล)

สิ่งนี้ช่วยให้เราสามารถวิเคราะห์บทบาทของความสามารถในการวิปัสสนาของแต่ละส่วนในสถานการณ์การใช้งานที่แตกต่างกันภายใต้สมมติฐานบางประการ (การแบ่งการทำงานของ Lock Script และ Type Script) นั่นคือเพื่อวิเคราะห์ความสามารถในการโปรแกรมที่เพิ่มขึ้นที่แต่ละส่วนนำมาให้เรา

ในสองบทต่อไปนี้ เราจะดูการเขียนโปรแกรมสคริปต์ Bitcoin ในปัจจุบัน (โดยไม่มีข้อเสนอข้อจำกัด) และฟังก์ชันที่คาดว่าจะใช้ข้อเสนอข้อจำกัด เพื่อทำความเข้าใจโดยเฉพาะว่า CKB Cell ได้รับการตั้งโปรแกรมและทำงานได้ดีขึ้นอย่างไร

3. การเขียนโปรแกรมสคริปต์ Bitcoin

ส่วนนี้จะใช้ Lightning Channel/Lightning Network และ Discreet Log Contract (DLC) เป็นตัวอย่างของการเขียนโปรแกรมแอปพลิเคชันที่ใช้สคริปต์ Bitcoin ก่อนดำเนินการต่อ เราต้องเข้าใจแนวคิดสองประการก่อน

(1) OP_IF และ ธุรกรรมที่ผูกพัน

แนวคิดแรกคือ opcodes ควบคุมกระบวนการในสคริปต์ Bitcoin เช่น: OP_IF, OP_ELSE opcode เหล่านี้ไม่แตกต่างจาก IF ในการเขียนโปรแกรมคอมพิวเตอร์ หน้าที่ของพวกมันคือดำเนินการคำสั่งที่แตกต่างกันตามอินพุตที่ต่างกัน ในบริบทของสคริปต์ Bitcoin หมายความว่าเราสามารถตั้งค่าเส้นทางการปลดล็อคสำหรับกองทุนได้หลายเส้นทาง เมื่อจับคู่กับคุณสมบัติการล็อคเวลา ซึ่งหมายความว่าเราสามารถกำหนดลำดับความสำคัญให้กับการดำเนินการได้

ยกตัวอย่าง Hash Time Lock Contract (HTLC) อันโด่งดัง สคริปต์นี้แปลเป็นภาษาท้องถิ่นดังนี้:

อีกทางหนึ่ง Bob สามารถเปิดเผยภาพต้นฉบับที่อยู่ด้านหลังค่าแฮช H จากนั้นให้ลายเซ็นเพื่อใช้จ่ายเงิน
หรืออีกวิธีหนึ่ง อลิซสามารถใช้จ่ายเงินพร้อมลายเซ็นของเธอได้หลังจากช่วงระยะเวลาหนึ่ง T

เอฟเฟกต์ อย่างใดอย่างหนึ่ง... หรือ... นี้สามารถทำได้ผ่าน opcodes การควบคุมกระบวนการ

ข้อได้เปรียบที่โดดเด่นที่สุดของ HTLC คือสามารถรวมการดำเนินการหลายอย่างเข้าด้วยกันและบรรลุความเป็นอะตอมมิก ตัวอย่างเช่น หาก Alice ต้องการแลกเปลี่ยน BTC เป็น CKB กับ Bob ก่อนอื่น Bob สามารถให้ค่าแฮชและสร้าง HTLC บน Nervos Network จากนั้น Alice จะสร้าง HTLC บน Bitcoin โดยใช้ค่าแฮชเดียวกัน อีกทางหนึ่ง Bob รับ BTC ที่อลิซจ่ายไปเป็น Bitcoin และยังเปิดเผยภาพต้นฉบับด้วย ทำให้อลิซสามารถนำ CKB ไปบน Nervos Network ได้ หรือบ็อบไม่เปิดเผยภาพต้นฉบับ สัญญาทั้งสองจะหมดอายุ และทั้งอลิซและบ็อบจะได้รับเงินคืนที่ลงทุนไป

หลังจากเปิดใช้งาน Taproot soft fork คุณลักษณะของเส้นทางการปลดล็อคหลายเส้นทางได้รับการปรับปรุงให้แข็งแกร่งยิ่งขึ้นด้วยการแนะนำ MAST (Merkle Abstract Syntax Tree) เราสามารถเปลี่ยนเส้นทางการปลดล็อคให้เป็นใบไม้บนต้นไม้ Merkle แต่ละใบมีความเป็นอิสระ ดังนั้นจึงไม่จำเป็นต้องใช้ opcode การควบคุมการไหลดังกล่าว และ เนื่องจากการเปิดเผยเส้นทางหนึ่งไม่จำเป็นต้องเปิดเผยเส้นทางอื่น เราจึงสามารถเพิ่มเส้นทางที่ปลดล็อคจำนวนมากขึ้นให้กับเอาต์พุตโดยไม่ต้องกังวลเกี่ยวกับคำถามทางเศรษฐศาสตร์

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

ตัวอย่างเช่น Alice และ Bob เป็นเจ้าของ UTXO ร่วมกัน และ UTXO นี้กำหนดให้ทั้งคู่ใช้ลายเซ็นของพวกเขา ในเวลานี้ Alice สร้างธุรกรรมเพื่อใช้จ่าย โดยโอน 60% ของมูลค่าให้กับ Bob และมูลค่าที่เหลือให้กับตัวเธอเอง Alice จัดเตรียมลายเซ็นของเธอเองสำหรับธุรกรรมและส่งให้กับ Bob จากนั้น สำหรับ Bob ไม่จำเป็นต้องถ่ายทอดธุรกรรมไปยังเครือข่าย Bitcoin หรือให้ธุรกรรมได้รับการยืนยันโดย Blockchain ผลการชำระเงินของธุรกรรมยังเป็นของจริงและน่าเชื่อถืออีกด้วย เนื่องจาก Alice ไม่สามารถใช้ UTXO นี้ด้วยตัวเองได้ (และดังนั้นจึงไม่สามารถใช้ซ้ำได้) และเนื่องจากลายเซ็นที่ Alice มอบให้นั้นถูกต้อง Bob จึงสามารถเพิ่มลายเซ็นของเขาเองได้ตลอดเวลา จากนั้นจึงออกอากาศธุรกรรมเพื่อถอนการชำระเงิน กล่าวอีกนัยหนึ่ง Alice ให้ ความมุ่งมั่นที่น่าเชื่อถือ แก่ Bob ผ่านธุรกรรมที่ถูกต้อง (ไม่ใช่แบบออนไลน์)

การทำธุรกรรมแบบผูกมัดเป็นแนวคิดหลักในการเขียนโปรแกรมแอปพลิเคชัน Bitcoin ตามที่กล่าวไว้ก่อนหน้านี้ สัญญาของ Bitcoin นั้นขึ้นอยู่กับการตรวจสอบ ไร้สัญชาติ และไม่อนุญาตให้มีการเข้าถึงข้าม อย่างไรก็ตาม หากสัญญาไม่มีสถานะ สถานะเหล่านี้จะถูกเก็บไว้ที่ไหน และสัญญาจะก้าวหน้าไปอย่างปลอดภัยได้อย่างไร (สถานะที่เปลี่ยนแปลง) การทำธุรกรรมแบบผูกมัดให้คำตอบที่ตรงไปตรงมา: สถานะของสัญญาสามารถแสดงในรูปแบบของธุรกรรมเพื่อให้ผู้เข้าร่วมสัญญาสามารถบันทึกรัฐได้ด้วยตนเองโดยไม่ต้องแสดงบน blockchain ปัญหาของการเปลี่ยนแปลงสถานะสัญญายังสามารถแปลงเป็น ปัญหาการอัพเดทธุรกรรมที่ตกลงไว้อย่างปลอดภัย นอกจากนี้ หากเรากังวลถึงอันตรายจากการลงนามในสัญญา (เช่น การลงนามในสัญญาที่ทั้งสองฝ่ายต้องลงนามก่อนใช้จ่ายเราก็จะต้องเผชิญกับความเสี่ยงของอีกฝ่ายที่ไม่ ตอบสนองและติดขัด) จากนั้นเพียงสร้างและลงนามธุรกรรมข้อผูกมัดที่ใช้สัญญาล่วงหน้าช่วยลดความเสี่ยงและกำจัดความไว้วางใจในผู้เข้าร่วมรายอื่น

(2) Lightning Channel และ Lightning Network

ช่อง Lightning เป็นสัญญาแบบหนึ่งต่อหนึ่งซึ่งทั้งสองฝ่ายสามารถชำระเงินให้กันโดยไม่จำกัดจำนวนครั้งโดยไม่ต้องมีการยืนยันการชำระเงินใด ๆ จากบล็อกเชน ตามที่คุณอาจคาดหวัง ระบบจะใช้ธุรกรรมตามสัญญา

ในส่วนที่อธิบาย ธุรกรรมที่มีข้อผูกมัด เราได้แนะนำช่องทางการชำระเงิน อย่างไรก็ตาม สัญญานี้ซึ่งใช้ลายเซ็นหลายฉบับเพียง 2 ใน 2 ฉบับเท่านั้น สามารถชำระเงินแบบทางเดียวเท่านั้น นั่นคือ อลิซจะจ่ายเงินให้ Bob เสมอ หรือ Bob จ่ายให้ Alice จนกว่ายอดเงินในสัญญาจะหมด หากเป็นการชำระเงินแบบสองทาง หมายความว่า หลังจากอัปเดตสถานะแล้ว ยอดคงเหลือของฝ่ายหนึ่งอาจลดลงกว่าเดิม แต่เขามีธุรกรรมที่กระทำครั้งสุดท้ายที่ลงนามโดยอีกฝ่าย - มีวิธีใดที่จะหยุดเขาได้ แล้วเกี่ยวกับ ออกอากาศธุรกรรมข้อผูกพันเก่าเพื่อให้ TA สามารถออกอากาศเฉพาะธุรกรรมข้อผูกพันล่าสุดเท่านั้น

วิธีแก้ปัญหาของ Lightning Channel สำหรับปัญหานี้เรียกว่า LN-Penalty ตอนนี้ สมมติว่า Alice และ Bob ต่างมี 5 BTC ใน Channel ตอนนี้ Alice ต้องการจ่ายเงินให้กับ Bob 1 BTC ดังนั้นเธอจึงลงนามในธุรกรรมข้อผูกมัดเช่นนี้และส่งไปให้ Bob:

ป้อน #0, 10 BTC:
Alie-Bob 2-of-2 เอาต์พุตหลายลายเซ็น (เช่นสัญญาช่องสัญญาณ)

เอาต์พุต #0, 4 BTC:
ลายเซ็นเดียวของอลิซ

เอาต์พุต #1, 6 BTC:
ทั้ง
กุญแจสาธารณะชั่วคราวร่วมของ Alice-Bob #1 ลายเซ็นเดียว
ทั้ง
T ล็อค 1 ครั้ง ลายเซ็น Bob เดี่ยว

Bob ยังลงนามในธุรกรรมข้อผูกมัด (ซึ่งสอดคล้องกับธุรกรรมข้างต้น) และส่งไปที่ Alice:

ป้อน #0, 10 BTC:
Alie-Bob 2-of-2 เอาต์พุตหลายลายเซ็น (เช่นสัญญาช่องสัญญาณ)

เอาต์พุต #0, 6 BTC:
ลายเซ็นเดียวของบ๊อบ

เอาต์พุต #1, 4 BTC:
ทั้ง
กุญแจสาธารณะชั่วคราวร่วม Bob-Alice #1 ลายเซ็นเดียว
ทั้ง
T ล็อค 1 ครั้ง อลิซ ลายเซ็นเดียว

เคล็ดลับที่นี่คือ คีย์สาธารณะชั่วคราวร่วม ซึ่งสร้างขึ้นโดยใช้คีย์สาธารณะของตนเองและคีย์สาธารณะที่อีกฝ่ายมอบให้ ตัวอย่างเช่น คีย์สาธารณะชั่วคราวร่วมของ Alice-Bob คือ Alice โดยใช้คีย์สาธารณะของเธอเอง . และพับลิกคีย์ที่ Bob มอบให้ โดยแต่ละคีย์จะคูณด้วยค่าแฮชแล้วจึงบวกเข้าด้วยกัน เมื่อกุญแจสาธารณะถูกสร้างขึ้น จะไม่มีใครรู้กุญแจส่วนตัวของมัน อย่างไรก็ตาม หาก Bob บอก Alice ถึงกุญแจส่วนตัวของกุญแจสาธารณะที่เขาให้มา Alice ก็สามารถคำนวณกุญแจส่วนตัวของกุญแจสาธารณะชั่วคราวร่วมได้ ——นี่คือกุญแจสำคัญในความสามารถของ Lightning Channel ในการ ยกเลิก สถานะเก่า

ในครั้งถัดไปที่ทั้งสองฝ่ายต้องการอัพเดตสถานะช่อง (เริ่มการชำระเงิน) ทั้งสองฝ่ายจะแลกเปลี่ยนคีย์ส่วนตัวของคีย์สาธารณะชั่วคราวที่มอบให้แก่อีกฝ่ายในรอบที่แล้ว ด้วยวิธีนี้ ผู้เข้าร่วมไม่กล้าออกอากาศธุรกรรม Commitment ล่าสุดที่พวกเขาได้รับอีกต่อไป: ผลลัพธ์ของธุรกรรม Commitment นี้กำหนดมูลค่าให้กับตัวเองมีสองเส้นทาง และคีย์ส่วนตัวของเส้นทางคีย์สาธารณะชั่วคราวเป็นที่รู้จักของอีกฝ่ายแล้ว ดังนั้น เมื่อธุรกรรมข้อผูกพันเก่าถูกออกอากาศ อีกฝ่ายสามารถใช้คีย์ส่วนตัวชั่วคราวร่วมนี้ทันทีเพื่อนำเงินทั้งหมดในเอาต์พุตนี้ออกไป – นี่คือความหมายของ “LN-บทลงโทษ”

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

โดยสรุปการออกแบบที่สำคัญของช่องฟ้าผ่าคือ:

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

สุดท้ายนี้ เนื่องจาก HTLC สามารถฝังอยู่ในธุรกรรมที่ผูกมัดได้ ช่อง Lightning จึงสามารถส่งต่อการชำระเงินได้เช่นกัน สมมติว่าอลิซสามารถค้นหาเส้นทางที่ประกอบด้วยช่องสายฟ้าที่เชื่อมต่อไปมาและไปถึงดาเนียล ดังนั้นการชำระเงินแบบมัลติฮอปที่ไร้ความน่าเชื่อถือสามารถทำได้โดยไม่ต้องเปิดช่องกับดาเนียล นี่คือเครือข่าย Lightning:

Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
อลิซ <-- ภาพต้นฉบับ-- บ๊อบ <-- ภาพต้นฉบับ-- แครอล <-- ภาพต้นฉบับ-- แดเนียล

เมื่ออลิซค้นพบเส้นทางดังกล่าวและต้องการจ่ายเงินให้ Daniel เธอขอค่าแฮชจาก Daniel เพื่อสร้าง HTLC ให้กับ Bob และแจ้งให้ Bob ส่งต่อข้อความไปยัง Carol และจัดเตรียม HTLC เดียวกัน ข้อความดังกล่าวยังแจ้งให้ Carol ส่งต่อข้อความด้วย ให้กับ Daniel และจัดเตรียม HTLC เดียวกัน เมื่อข่าวไปถึง Daniel เขาก็เปิดเผยภาพต้นฉบับให้ Carol ทราบ จึงได้รับมูลค่าของ HTLC และอัปเดตสถานะสัญญา แครอลก็ทำเช่นเดียวกัน รับการชำระเงินของ Bob และอัปเดตสถานะช่อง ในที่สุด Bob ก็เปิดเผยภาพต้นฉบับและอัปเดต สถานะเป็นอลิซ เนื่องจากคุณลักษณะของ HTLC การชำระเงินชุดนี้จึงสำเร็จร่วมกันหรือล้มเหลวร่วมกัน ดังนั้นจึงไม่น่าไว้วางใจ

เครือข่าย Lightning ประกอบด้วยช่องสัญญาณต่อกัน และแต่ละช่อง (สัญญา) มีความเป็นอิสระจากกัน ซึ่งหมายความว่า Alice เพียงแต่ต้องรู้ว่าเกิดอะไรขึ้นในช่องของเธอเองกับ Bob และไม่จำเป็นต้องสนใจว่ามีการโต้ตอบเกิดขึ้นกี่ครั้งในช่องของผู้อื่น หรือการโต้ตอบเหล่านี้ใช้สกุลเงินใด หรือแม้แต่ว่าการโต้ตอบเหล่านั้นเป็นของจริงหรือไม่ โดยใช้ช่องทาง) .

ความสามารถในการปรับขนาดของ Lightning Network ไม่เพียงสะท้อนให้เห็นในความจริงที่ว่าความเร็วการชำระเงินภายในช่องทาง Lightning นั้นถูกจำกัดโดยการลงทุนทรัพยากรฮาร์ดแวร์ของทั้งสองฝ่ายเท่านั้น แต่ยังรวมถึงการจัดเก็บข้อมูลแบบกระจายอำนาจของรัฐ โหนดเดียวจึงสามารถใช้ประโยชน์ได้ เลเวอเรจที่ยิ่งใหญ่ที่สุดในราคาที่ถูกที่สุด

(3) สัญญาไม้ซุงที่รอบคอบ

Discreet Log Contracts (DLC) ใช้เทคนิคการเข้ารหัสที่เรียกว่า ลายเซ็นอะแดปเตอร์ เพื่ออนุญาตให้สคริปต์ Bitcoin เขียนโปรแกรมสัญญาทางการเงินที่ขึ้นอยู่กับเหตุการณ์ภายนอก

ลายเซ็นอะแดปเตอร์อนุญาตให้ลายเซ็นใช้งานได้หลังจากเพิ่มคีย์ส่วนตัวเท่านั้น ยกตัวอย่างลายเซ็น Schnorr รูปแบบมาตรฐานของลายเซ็น Schnorr คือ (R, s) โดยที่:

R = r.G
# ค่า nonce r ที่ใช้ในลายเซ็นจะถูกคูณด้วยจุดสร้างเส้นโค้งวงรี ซึ่งอาจกล่าวได้ว่าเป็นกุญแจสาธารณะของ r
s = r + Hash(R || m || P) * p
# p คือคีย์ส่วนตัวของลายเซ็น P คือคีย์สาธารณะ
การตรวจสอบลายเซ็นหมายถึงการตรวจสอบ sG = rG + Hash(R -- m -- P) * pG = R + Hash(R -- m -- P) * PK

สมมติว่าฉันได้รับข้อมูลคู่หนึ่ง (R, s) โดยที่:

R = R 1 + R 2 = r 1.G + r 2.G
s' = r 1 + Hash(R || m || P) * p

แน่นอนว่านี่ไม่ใช่ลายเซ็น Schnorr ที่ถูกต้อง และไม่สามารถผ่านสูตรการตรวจสอบลายเซ็นได้ อย่างไรก็ตาม ฉันสามารถพิสูจน์ให้ผู้ตรวจสอบทราบว่าตราบใดที่ TA รู้คีย์ส่วนตัว r 2 ของ R 2 ก็สามารถเปลี่ยนให้เป็นลายเซ็นที่ถูกต้องได้ . :

s'.G + R 2 = R 1 + Hash(R || m || P) * P + R 2 = R + Hash(R || m || P) * P

ลายเซ็นอะแดปเตอร์ช่วยให้ความถูกต้องของลายเซ็นขึ้นอยู่กับข้อมูลที่เป็นความลับและสามารถตรวจสอบได้ แต่สิ่งนี้เกี่ยวข้องกับสัญญาทางการเงินอย่างไร?

สมมติว่าอลิซและบ็อบต้องการเดิมพันผลการแข่งขันฟุตบอล อลิซและบ็อบเดิมพันกรีนก็อบลินและอลีนาตามลำดับด้วยการเดิมพัน 1 BTC นอกจากนี้ เว็บไซต์วิจารณ์ฟุตบอล Carol สัญญาว่าจะใช้ nonce R_c เพื่อเผยแพร่ลายเซ็น s_c_i ของผลลัพธ์เมื่อมีการประกาศผลการแข่งขันฟุตบอล

ดังที่เห็น มีผลลัพธ์ที่เป็นไปได้สามแบบ (ดังนั้นลายเซ็นของแครอลจึงมีความเป็นไปได้ 3 แบบ):

- กรีนก็อบลินชนะ และอลิซชนะ 1 BTC

- อลีนาชนะ และบ็อบชนะ 1 BTC

- ในกรณีที่เสมอกัน เงินของทั้งสองคนจะถูกคืนไปตามเส้นทางเดิม

เมื่อต้องการทำเช่นนี้ ทั้งสองสร้างธุรกรรมข้อผูกพันสำหรับแต่ละผลลัพธ์ ตัวอย่างเช่น ธุรกรรมตามสัญญาที่พวกเขาสร้างขึ้นสำหรับผลลัพธ์แรกจะมีลักษณะดังนี้:

ป้อน #0, 2 BTC:
Alie-Bob 2-of-2 multi-signature output (เช่น สัญญาการเดิมพัน)

เอาต์พุต #0, 2 BTC:
ลายเซ็นเดียวของอลิซ

อย่างไรก็ตาม ลายเซ็นที่สร้างโดย Alice และ Bob สำหรับธุรกรรมนี้ไม่ใช่ (R, s) แต่เป็นลายเซ็นของอะแดปเตอร์ (R, s) นั่นคือ ลายเซ็นที่ทั้งสองฝ่ายมอบให้กันไม่สามารถใช้โดยตรงเพื่อปลดล็อก สัญญา และจะต้องเปิดเผยค่าลับ ค่าลับนี้เป็นภาพต้นฉบับของ s_c_ 1.G ซึ่งเป็นลายเซ็นต์ของ Carol ทุกประการ! เนื่องจากค่า nonce ของลายเซ็นของ Carol ถูกกำหนดแล้ว (คือ R_c) จึงสามารถสร้าง s_c_ 1.G ได้ (s_c_ 1.G = R_c + Hash(R_c -- The Green Goblin wins -- PK_c) * PK_c)

เมื่อมีการประกาศผลโดยสมมติว่า Green Goblin ชนะ Carol จะออกลายเซ็น (R_c, s_c_ 1) จากนั้นทั้ง Alice และ Bob ก็สามารถกรอกลายเซ็นอะแดปเตอร์ของฝ่ายตรงข้ามให้สมบูรณ์และเพิ่มลายเซ็นของตนเองเพื่อทำธุรกรรมข้างต้นเป็นธุรกรรมที่ถูกต้องคือ ออกอากาศไปยังเครือข่ายและก่อให้เกิดผลการชำระบัญชี แต่ถ้า Goblin ไม่ชนะ Carol ก็คงไม่ปล่อย s_c_ 1 และข้อตกลงที่ตกลงไว้ก็ไม่ใช่ข้อตกลงที่ถูกต้อง

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

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

4. ความรู้เบื้องต้นเกี่ยวกับการใช้ข้อกำหนดที่เข้มงวด

(1) OP_CTV และการควบคุมความแออัด

นักพัฒนาในชุมชน Bitcoin ได้ทำข้อเสนอต่าง ๆ ที่อาจจัดเป็นข้อจำกัดได้ จากมุมมองปัจจุบัน ข้อเสนอที่โด่งดังที่สุดคือ OP_CHECKTEMPLATEVERIFY (OP_CTV) แนวคิดนี้ค่อนข้างเรียบง่ายแต่ยังคงความยืดหยุ่นไว้ได้มาก ดังนั้นจึงได้รับการต้อนรับจากชุมชน Bitcoin ที่สนับสนุนความเรียบง่าย แนวคิดของ OP_CTV คือการมอบค่าแฮชในสคริปต์เพื่อจำกัดว่าเงินทุนจะสามารถใช้ได้เฉพาะกับธุรกรรมที่แสดงด้วยค่าแฮชเท่านั้น ค่าแฮชนี้คอมมิตเอาต์พุตของธุรกรรมและฟิลด์ส่วนใหญ่ แต่ไม่ได้คอมมิต ข้อมูลเข้าของธุรกรรมจะกระทำกับปริมาณข้อมูลเข้าเท่านั้น

การควบคุมความแออัด เป็นตัวอย่างที่ดีของคุณลักษณะของ OP_CTV สถานการณ์การใช้งานพื้นฐานของมันคือการช่วยให้ผู้ใช้จำนวนมากถอนตัวจากการแลกเปลี่ยน (สภาพแวดล้อมที่ต้องการความไว้วางใจ) เข้าสู่แหล่งเงินทุน เนื่องจากแหล่งเงินทุนนี้ใช้ OP_CTV เพื่อวางแผนวิธีการใช้จ่ายในอนาคต จึงสามารถมั่นใจได้ว่าผู้ใช้สามารถออกจากความไว้วางใจนี้ได้ สภาพแวดล้อมที่เสรี Fund Pool ไม่ต้องการความช่วยเหลือจากใคร และเนื่องจาก Fund Pool นี้ปรากฏเป็น UTXO เท่านั้น จึงหลีกเลี่ยงการจ่ายค่าธรรมเนียมการจัดการจำนวนมากเมื่อมีความต้องการธุรกรรมออนไลน์สูง (ลดลงจาก n เอาต์พุตเหลือ 1 เอาต์พุต ; จาก n รายการธุรกรรม ลดลงเหลือ 1 รายการ) ผู้ใช้ในกลุ่มสามารถรอโอกาสแล้วจึงถอนตัวออกจากกลุ่ม

สมมติว่า Alice, Bob และ Carol ต้องการถอน 5 BTC, 3 BTC และ 2 BTC จากการแลกเปลี่ยนตามลำดับ จากนั้นการแลกเปลี่ยนสามารถสร้างเอาต์พุตด้วย 3 สาขา OP_CTV ในจำนวน 10 BTC สมมติว่า Alice ต้องการถอนเงิน เธอสามารถใช้สาขา 1 ได้ ธุรกรรมที่แสดงโดยค่าแฮชที่ใช้โดย OP_CTV ของสาขานี้จะทำให้เกิดเอาต์พุตสองเอาต์พุต เอาต์พุตหนึ่งคือการจัดสรร 5 BTC ให้กับ Alice เอาต์พุตอื่น ๆ คือกองทุนรวม ใช้ OP_CTV เพื่อกระทำธุรกรรมที่อนุญาตให้ Bob ถอนเงิน 3 BTC และส่ง 2 BTC ที่เหลือไปให้ Carol เท่านั้น

เช่นเดียวกับในกรณีที่ Bob หรือ Carol ต้องการถอนเงิน เมื่อพวกเขาถอนเงินพวกเขาจะสามารถใช้ธุรกรรมที่สามารถผ่านการตรวจสอบ OP_CTV ที่เกี่ยวข้องเท่านั้นนั่นคือพวกเขาสามารถจ่ายเงินเองตามจำนวนที่สอดคล้องกันเท่านั้นและไม่สามารถถอนเงินได้ตามต้องการ เงินที่เหลือจะเข้าสู่กลุ่มกองทุนที่ถูกล็อคโดยใช้ OP_CTV จึงมั่นใจได้ว่าไม่ว่าผู้ใช้จะถอนเงินในลำดับใดก็ตาม ผู้ใช้ที่เหลือก็สามารถถอนออกจากพูลได้อย่างน่าเชื่อถือ

พูดโดยสรุป บทบาทของ OP_CTV ในที่นี้คือการวางแผนเส้นทางสำหรับสัญญาจนสิ้นสุดอายุการใช้งาน เพื่อให้สัญญา Capital Pool ที่นี่สามารถรักษาคุณลักษณะของทางออกที่ปราศจากความไว้วางใจได้ไม่ว่าจะใช้เส้นทางใดก็ตามหรือไปถึงสถานะใด .

OP_CTV ประเภทนี้มีการใช้งานที่น่าสนใจมากเช่นกัน: ช่องทางการชำระเงินแบบซ่อนเร้น สมมติว่า Alice สร้างกลุ่มกองทุนและตรวจสอบให้แน่ใจว่าสามารถถอนเงินออกไปยังเอาต์พุตได้อย่างไม่น่าเชื่อถือด้วยสคริปต์ต่อไปนี้:

อีกทางหนึ่ง อลิซและบ็อบใช้เวลาร่วมกัน
หรือหลังจากผ่านไประยะหนึ่ง อลิซก็สามารถใช้เวลาอยู่คนเดียวได้

หาก Alice ไม่เปิดเผยข้อมูลดังกล่าวให้ Bob ทราบ Bob จะไม่ทราบว่ามีผลลัพธ์ดังกล่าวอยู่ เมื่อ Alice เผยข้อมูลดังกล่าวให้ Bob ทราบ Bob สามารถใช้เอาต์พุตนี้เป็นช่องทางการชำระเงินทางเดียวตามเวลา และ Alice สามารถใช้เงินได้ทันทีเพื่อ Bob Pay โดยไม่ต้องรอการยืนยันบนบล็อคเชน Bob เพียงต้องปล่อยให้ Alice ได้รับธุรกรรมผูกมัดออนไลน์ก่อนที่ Alice จะใช้จ่ายด้วยตัวเธอเอง

(2) OP_Vault และปลอดภัย

OP_VAULT เป็นข้อเสนอข้อจำกัดที่ออกแบบมาโดยเฉพาะสำหรับการสร้าง ห้องนิรภัย

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

ตามทฤษฎีแล้ว OP_CTV ยังสามารถตั้งโปรแกรมสัญญาดังกล่าวได้ แต่มีความไม่สะดวกมากมาย หนึ่งในนั้นคือค่าธรรมเนียมการจัดการ: ในขณะที่ทำธุรกรรม จะต้องชำระค่าธรรมเนียมการจัดการที่จะจ่ายสำหรับธุรกรรมด้วย เมื่อพิจารณาถึงวัตถุประสงค์ของสัญญาดังกล่าว ระยะเวลาระหว่างการจัดทำสัญญาและการถอนเงินต้องใช้เวลานานมาก ทำให้แทบจะเป็นไปไม่ได้เลยที่จะคาดการณ์ค่าธรรมเนียมที่เหมาะสมได้ แม้ว่า OP_CTV จะไม่จำกัดอินพุต ดังนั้นคุณสามารถเพิ่มค่าธรรมเนียมการจัดการได้โดยการเพิ่มอินพุต แต่อินพุตทั้งหมดที่ให้ไว้จะกลายเป็นค่าธรรมเนียมการจัดการ ดังนั้นจึงไม่สมจริง อีกวิธีหนึ่งคือ CPFP นั่นคือโดยการใช้จ่ายเงินที่ถอนออก มีค่าธรรมเนียมสำหรับการทำธุรกรรมใหม่ นอกจากนี้ การใช้ OP_CTV ยังหมายความว่าสัญญาที่ปลอดภัยดังกล่าวไม่สามารถถอนเงินเป็นชุดได้ (และแน่นอนว่าไม่สามารถกู้คืนเป็นชุดได้)

ข้อเสนอ OP_VAULT พยายามแก้ไขปัญหาเหล่านี้โดยการเสนอ opcodes ใหม่ (OP_VAULT และ OP_UNVAULT) OP_UNVAULT ได้รับการออกแบบมาเพื่อการกู้คืนแบบแบตช์ ดังนั้นเราจะไม่พูดถึงมันในตอนนี้ การกระทำของ OP_VAULT เป็นดังนี้: เมื่อเราวางไว้บนสาขาของแผนผังสคริปต์ สามารถใช้เพื่อรับประกัน opcode ที่ดำเนินการได้ (เช่น OP_CTV) โดยไม่มีพารามิเตอร์เฉพาะ เมื่อใช้สาขานี้ ธุรกรรมสามารถส่งผ่านพารามิเตอร์เฉพาะได้ แต่สาขาอื่นไม่สามารถเปลี่ยนแปลงได้ จึงไม่จำเป็นต้องกำหนดค่าธรรมเนียมการจัดการและสามารถกำหนดค่าธรรมเนียมการจัดการเมื่อใช้จ่ายสาขานี้ได้สมมติว่าสาขานี้มีล็อคเวลาด้วยก็จะบังคับล็อคเวลาในที่สุดเพราะสามารถเปลี่ยนสถานที่ได้เท่านั้น ในตำแหน่งที่สาขานั้น สาขาอื่นๆ บนแผนผังสคริปต์ใหม่ (รวมถึงสาขาการกู้คืนฉุกเฉิน) จะไม่มีการเปลี่ยนแปลง จึงทำให้เราสามารถขัดขวางการดำเนินการถอนเงินดังกล่าวได้

นอกจากนี้ มีสองประเด็นที่ควรกล่าวถึง: (1) opcode OP_VAULT ทำงานคล้ายกับข้อเสนอข้อจำกัดอื่น: OP_TLUV; Jeremy Rubin ชี้ให้เห็นอย่างถูกต้องว่าสิ่งนี้ได้ก่อให้เกิดแนวคิดเรื่อง การคำนวณ ขึ้นแล้วในระดับหนึ่ง: OP_TLUV/ OP_VAULT สัญญา opcode ก่อนเพื่อให้ผู้ใช้สามารถส่งพารามิเตอร์ไปยัง opcode ผ่านธุรกรรมใหม่ ดังนั้นจะอัปเดตแผนผังแผนผังสคริปต์ทั้งหมด นี่ไม่ใช่ การตรวจสอบข้อมูลขาเข้าตามเงื่อนไขบางประการ อีกต่อไป แต่ สร้างข้อมูลใหม่ ข้อมูลที่มีความหมายตามข้อมูลที่เข้ามา แม้ว่าการคำนวณที่สามารถเปิดใช้งานได้นั้นค่อนข้างจำกัดก็ตาม

(2) ข้อเสนอ OP_VAULT ที่สมบูรณ์ยังใช้ข้อเสนอบางอย่างเกี่ยวกับนโยบายกลุ่มธุรกรรม (นโยบาย mempool) (เช่น ธุรกรรมรูปแบบ v3) เพื่อให้ได้ผลลัพธ์ที่ดีขึ้น สิ่งนี้เตือนเราว่า การเขียนโปรแกรม อาจมีความหมายกว้างกว่าที่เราคิด (ตัวอย่างที่คล้ายกันคือ เปิดธุรกรรมใน Nervos Network)

5. ทำความเข้าใจกับ CKB

ในสองบทข้างต้น เราได้แนะนำวิธีที่เราสามารถใช้สคริปต์เพื่อตั้งโปรแกรมแอปพลิเคชันที่น่าสนใจบนโครงสร้างที่มีข้อจำกัดมากขึ้น (Bitcoin UTXO) เรายังแนะนำข้อเสนอเพื่อพยายามเพิ่มความสามารถในการวิปัสสนาให้กับโครงสร้างนี้

แม้ว่า UTXO จะมีความสามารถในการตั้งโปรแกรมแอปพลิเคชันเหล่านี้ แต่ผู้อ่านสามารถตรวจจับข้อบกพร่องหรือส่วนที่สามารถปรับให้เหมาะสมได้อย่างง่ายดาย เช่น:

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

ในความเป็นจริง ชุมชน Bitcoin ได้พบกับคำตอบสำหรับคำถามเหล่านี้ โดยพื้นฐานแล้วเกี่ยวข้องกับข้อเสนอ Sighash (BIP-118 AnyPrevOut)

อย่างไรก็ตาม หากเรากำลังเขียนโปรแกรมบน CKB BIP-118 ก็สามารถใช้งานได้แล้ว (แท็ก Sighash สามารถจำลองได้ด้วยความสามารถในการใคร่ครวญและตรวจสอบลายเซ็นโดยเฉพาะ)

ด้วยการเรียนรู้การเขียนโปรแกรม Bitcoin เราไม่เพียงแต่รู้วิธีการเขียนโปรแกรมรูปแบบ เอาท์พุทธุรกรรม (สิ่งที่ CKB สามารถเขียนโปรแกรมได้) แต่ยังรู้วิธีปรับปรุงแอปพลิเคชันเหล่านี้ด้วย (หากเราตั้งโปรแกรมแอปพลิเคชันเหล่านี้บน CKB เราจะใช้ความสามารถของ CKB เพื่อปรับปรุงได้อย่างไร พวกเขา). สำหรับนักพัฒนา CKB การเขียนโปรแกรมโดยใช้สคริปต์ Bitcoin ถือได้ว่าเป็นตำราการเรียนรู้หรือแม้แต่ทางลัด

ด้านล่างนี้ เราจะวิเคราะห์ความสามารถในการโปรแกรมของแต่ละโมดูลของการเขียนโปรแกรม CKB ทีละโมดูล เราอย่าพิจารณาความสามารถครุ่นคิดในตอนนี้

(1) สคริปต์ล็อคที่ตั้งโปรแกรมได้สำหรับการคำนวณตามอำเภอใจ

ตามที่กล่าวไว้ข้างต้น ไม่สามารถตั้งโปรแกรม UTXO ด้วยการคำนวณตามอำเภอใจได้ Lock Script สามารถเขียนโปรแกรมได้ ซึ่งหมายความว่า Lock Script สามารถตั้งโปรแกรมได้ทุกอย่าง (ก่อนใช้งานข้อจำกัด) โดยอิงตามการเขียนโปรแกรม UTXO รวมถึงแต่ไม่จำกัดเพียง Lightning Channel และ DLC ที่กล่าวถึงข้างต้น

นอกจากนี้ ความสามารถในการตรวจสอบการคำนวณใดๆ ยังช่วยให้ Lock Script ใช้วิธีการตรวจสอบสิทธิ์ได้มากขึ้น และมีความยืดหยุ่นมากกว่า UTXO ตัวอย่างเช่น เราสามารถใช้ Lightning Channel บน CKB โดยที่ฝ่ายหนึ่งใช้ลายเซ็น ECDSA และอีกฝ่ายใช้ลายเซ็น RSA

ในความเป็นจริง นี่เป็นหนึ่งในพื้นที่แรกๆ ที่ผู้คนเริ่มสำรวจบน CKB: การใช้ความสามารถในการยืนยันตัวตนที่ยืดหยุ่นนี้ในการดูแลตนเองของผู้ใช้เพื่อให้บรรลุสิ่งที่เรียกว่า การลบบัญชี - การอนุญาตและความถูกต้องของธุรกรรม การฟื้นฟูการควบคุมมีความยืดหยุ่นมาก และเกือบจะไม่จำกัด โดยหลักการแล้ว นี่คือการผสมผสานระหว่าง สาขาการใช้จ่ายหลายสาขา และ วิธีการตรวจสอบสิทธิ์ใดๆ ตัวอย่างของการใช้งาน ได้แก่: กระเป๋าเงิน joyid, UniPass

นอกจากนี้ Lock Script ยังสามารถดำเนินการตามข้อเสนอ eltoo ได้ด้วย ช่วยให้ช่องสัญญาณ lightning จำเป็นต้องรักษาธุรกรรมที่ผูกพันไว้ล่าสุดเท่านั้น (อันที่จริง eltoo สามารถทำให้สัญญาแบบจุดต่อจุดทั้งหมดง่ายขึ้น)

(2) พิมพ์สคริปต์ที่สามารถโปรแกรมการคำนวณใดๆ ได้

ตามที่กล่าวไว้ข้างต้น หนึ่งในการใช้งานที่ยอดเยี่ยมของ Type Script คือการเขียนโปรแกรม UDT เมื่อรวมกับ Lock Script หมายความว่าเราสามารถใช้ช่องทาง Lightning ที่ใช้ UDT ได้ (รวมถึงสัญญาประเภทอื่น ๆ )

ในความเป็นจริง การแยก Lock Script และ Type Script ถือได้ว่าเป็นการอัพเกรดความปลอดภัย: Lock Script มุ่งเน้นไปที่การนำวิธีการดูแลหรือโปรโตคอลตามสัญญาไปใช้ ในขณะที่ Type Script มุ่งเน้นไปที่คำจำกัดความของ UDT

นอกจากนี้ ความสามารถในการเริ่มการตรวจสอบตามคำจำกัดความของ UDT ยังทำให้ UDT สามารถมีส่วนร่วมในสัญญาในลักษณะที่คล้ายกับ CKB (UDT เป็นพลเมืองชั้นหนึ่ง)

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

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

การแก้ไข: สมมติว่า NFT ที่ใช้เป็นหลักประกันและโทเค็นที่ใช้สำหรับการชำระคืนนั้นออกโดยใช้โปรโตคอลเดียวกัน (เช่น RGB) ดังนั้นปัญหาที่นี่สามารถแก้ไขได้ เราสามารถสร้างธุรกรรมข้อผูกมัดตามโปรโตคอล RGB เพื่อให้ NFT การเปลี่ยนสถานะและการชำระคืนสามารถเกิดขึ้นได้พร้อมกัน (ธุรกรรมใช้เพื่อผูกการเปลี่ยนสถานะสองสถานะภายในโปรโตคอล RGB) อย่างไรก็ตาม เนื่องจากธุรกรรม RGB ยังอาศัยธุรกรรม Bitcoin การสร้างธุรกรรมข้อผูกมัดที่นี่จึงค่อนข้างยาก โดยรวมแล้ว แม้ว่าปัญหาจะสามารถแก้ไขได้ แต่โทเค็นถือเป็นพลเมืองชั้นหนึ่ง

ต่อไปเราจะพิจารณาความสามารถในการวิปัสสนา

(3) Lock Script อ่านสคริปต์ล็อคอื่น ๆ

นี่หมายถึงความเป็นไปได้ในการเขียนโปรแกรมอย่างเต็มรูปแบบบน Bitcoin UTXO หลังจากนำข้อจำกัดที่เสนอไปใช้แล้ว รวมถึงสัญญาที่ปลอดภัยที่กล่าวถึงข้างต้น และแอปพลิเคชันที่อิงตาม OP_CTV (เช่น การควบคุมความแออัด)

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

(4) Lock Script อ่านสคริปต์ประเภทอื่น (และข้อมูล)

การใช้งานที่น่าสนใจของความสามารถนี้คือโทเค็นหุ้น Lock Script จะกำหนดว่าสามารถใช้ความจุของตัวเองได้หรือไม่ โดยพิจารณาจากจำนวนโทเค็นในอินพุตอื่นๆ และตำแหน่งที่สามารถใช้ความจุได้ (ต้องมีความสามารถในการวิปัสสนาสคริปต์ Lock)

(5) Type Script อ่านสคริปต์ล็อคอื่น ๆ

ไม่แน่ใจ แต่ถือว่ามีประโยชน์นะครับ ตัวอย่างเช่น Lock Scripts ที่สามารถตรวจสอบอินพุตและเอาต์พุตของธุรกรรมยังคงไม่เปลี่ยนแปลงใน Type Script

(6) Type Script อ่านสคริปต์ประเภทอื่น (และข้อมูล)

เทรดดิ้งการ์ด? การสะสมโทเค็นสามารถแลกเปลี่ยนเป็นโทเค็นที่ใหญ่กว่าได้ :)

6. บทสรุป

เมื่อเปรียบเทียบกับระบบสัญญาอัจฉริยะแบบตั้งโปรแกรมได้ก่อนหน้านี้สำหรับการคำนวณตามอำเภอใจ (เช่น Ethereum) Nervos Network จะใช้โครงสร้างที่แตกต่างกัน ดังนั้น การทำความเข้าใจระบบสัญญาอัจฉริยะก่อนหน้านี้จึงมักจะสร้างพื้นฐานสำหรับการทำความเข้าใจ Nervos Network ได้ยาก บทความนี้เริ่มต้นจากการเขียนโปรแกรมแอปพลิเคชันของโครงสร้างที่ถูกจำกัดมากกว่า CKB Cell - BTC UTXO และเสนอวิธีการทำความเข้าใจความสามารถในการโปรแกรมของ CKB Cell นอกจากนี้ ด้วยการใช้แนวคิดเรื่อง การวิปัสสนา เพื่อทำความเข้าใจความสามารถ การเข้าถึงสัญญาข้าม ของ Cell เราสามารถแบ่งสถานการณ์ที่ใช้ความสามารถในการวิปัสสนาและกำหนดการใช้งานเฉพาะสำหรับสิ่งเหล่านั้นได้

การแก้ไข:

ไม่ว่าความสามารถในการเข้าถึงข้ามของ Cell จะเป็นอย่างไร (เช่น ความสามารถในการวิปัสสนา) สคริปต์ล็อคก็ถือเป็นสคริปต์ Bitcoin ที่มีความสามารถในการเขียนโปรแกรมแบบรัฐและขั้นสูง ดังนั้น แอปพลิเคชันทั้งหมดที่ใช้ Bitcoin Script จึงสามารถตั้งโปรแกรมตามสิ่งนี้เพียงอย่างเดียวได้
โดยไม่คำนึงถึงความสามารถในการเข้าถึงข้ามของ Cell (นั่นคือความสามารถในการวิปัสสนา) ความแตกต่างระหว่างสคริปต์ล็อคและสคริปต์ประเภทถือได้ว่าเป็นการอัพเกรดความปลอดภัย: แยกคำจำกัดความสินทรัพย์และวิธีการจัดเก็บของ UDT ออก นอกจากนี้ พิมพ์สคริปต์ที่สามารถเปิดเผยสถานะ (และ Data) บรรลุผลว่า UDT เป็นพลเมืองชั้นหนึ่ง

สองประเด็นข้างต้นหมายถึงบางสิ่งที่มีกระบวนทัศน์เดียวกันกับ “BTC + RGB” แต่มีความสามารถในการเขียนโปรแกรมที่แข็งแกร่งกว่า

เมื่อพิจารณาถึงความสามารถในการวิปัสสนาของ Cell Cell สามารถรับความสามารถในการเขียนโปรแกรมที่แข็งแกร่งกว่า BTC UTXO หลังข้อตกลง และบรรลุสิ่งที่ทำได้ยากด้วย BTC + RGB (เนื่องจาก BTC ไม่สามารถอ่านสถานะของ RGB ได้)

ในการใช้งานเหล่านี้ บทความนี้ไม่สามารถยกตัวอย่างที่เจาะจงได้มากนัก แต่เป็นเพราะผู้เขียนขาดความเข้าใจในระบบนิเวศของ CKB เมื่อเวลาผ่านไป ฉันเชื่อว่าผู้คนจะใช้จินตนาการมากขึ้นเรื่อยๆ และผสมผสานแอปพลิเคชันที่ไม่สามารถจินตนาการได้ในปัจจุบัน