จากการเขียนโปรแกรมแอปพลิเคชัน Bitcoin ไปยังความเข้าใจอย่างละเอียดของ CKB

ต่อไปนี้เป็นเนื้อหาที่ถูกนำมาจากเว็บบอร์ด Nervos Talk โดยผู้เขียนคือ Ajian (บรรณาธิการหลักของแพลตฟอร์มเนื้อหาบิทคอยน์ BTC Study)

สรุป

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

หนึ่ง. บทนำ

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

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

• รูปแบบพื้นฐานของการแสดงสถานะ (บัญชี vs ผลลัพธ์การทำธุรกรรม)
• ท่านสามารถคำนวณโปรแกรมได้โดยอิสระหรือไม่ (“ทัวริงเสร็จสมบูรณ์” มีความหมายเกี่ยวข้องกับด้านนี้)
• การดำเนินการสามารถสร้างข้อมูลใหม่หรือเพียงแค่ส่งค่าความจริงออกมาได้หรือไม่? (การคำนวณ vs. การตรวจสอบ)
• ยินดีให้บันทึกสถานะเพิ่มเติมในสัญญาหรือไม่
• 01928374656574839201 01928374656574839201019283746565748392010192837465657483920101928374656574839201019283746565748392010192837465657483920101928374656574839201019283746565748392010192837465657483920101928374656574839201

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

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

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

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

สอง. CKB กับ BTC: มีอะไรเพิ่มเติม?

โครงสร้างพื้นฐาน

作为BTC状态表示的基本形式，BTC的UTXO（“เอาต์พุตธุรกรรมที่ไม่ใช้จ่าย”）有两个字段：

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

กับระบบสัญญาอัจฉริยะที่เกิดขึ้นในภายหลัง สคริปต์บิตคอยน์มีข้อจำกัดที่สูงกว่านั้น:

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

นอกจากนี้ยังมีความสามารถในการเขียนโปรแกรมที่ทำให้ผู้คนประทับใจ และเป็นพื้นฐานในการสำรวจความสามารถในการเขียนโปรแกรมของ CKB มีสองตัวอย่างในการเขียนสคริปต์ของบิทคอยน์ที่จะถูกนำเสนอในส่วนถัดไปที่เป็นเนื้อหาเฉพาะเรื่อง 01928374656574839201

กลับไปที่ CKB สถานะหน่วยเรียกว่า "Cell" มีฟิลด์สี่ตัว

• Capacity, คล้ายกับจำนวน UTXO, แสดงถึงขนาดพื้นที่ที่เซลล์นี้สามารถใช้งานได้, ในหน่วยไบต์ (Bytes)
• Lock , คล้ายกับสคริปต์กุญแจสาธารณะของ UTXO ที่กำหนดสิทธิ์ในการเป็นเจ้าของของ Cell นี้; เมื่อมีข้อมูลที่ให้มาสามารถผ่าน Lock ได้เท่านั้น จึงสามารถ "อัปเดต" Cell นี้ได้ (หรือสามารถเปิดใช้ Cell นี้และสร้าง Cell ใหม่โดยใช้ Capacity เหล่านี้) ;
• 数据，数据，01928374656574839201，其体积受 Capacity 的限制；
• Type, สคริปต์ที่เลือกได้เพื่อตั้งเงื่อนไขสำหรับการอัปเดตข้อมูล 01928374656574839201

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

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

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

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

ข้อจำกัดและการตรวจสอบตนเอง

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

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

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

โดยอ้างอิงจากนี้ เราสามารถแบ่งความสามารถในการทำความเข้าใจตนเองออกเป็นสี่แบบ:

• ล็อก 01928374656574839201 读取其它（输入和输出）的 01928374656574839201
• ล็อก อ่านชนิดอื่น (อินพุตและเอาต์พุต) (รวมถึงข้อมูล)
• Type 01928374656574839201的锁（输入和输出）
• ประเภท อ่านอื่น ๆ (การนำเข้าและการส่งออก) ประเภท (รวมถึงข้อมูล)

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

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

สาม. บทความเกี่ยวกับการเขียนสคริปต์บิตคอยน์

หัวข้อนี้จะใช้ "Lighting Network" และ "DLC" เป็นตัวอย่างของการเขียนโปรแกรมแอปพลิเคชันที่ใช้สคริปต์ของ Bitcoin ก่อนที่เราจะเข้าสู่รายละเอียด ให้เราทำความเข้าใจความหมายของสองคำศัพท์นี้ก่อน

OP_IF และ "การธุรกิจสัญญา"

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

ในตัวอย่างของ "สัญญา Hashed TimeLock Contract (HTLC)" ที่มีชื่อเสียง สคริปต์ชนิดนี้ถูกแปลเป็นภาษาทั่วไปว่า:

要么，Bob สามารถเปิดเผยภาพหลักของค่าแฮช H และให้ลายเซ็นต์ของตัวเองเพื่อใช้จ่ายเงินนี้;

หรือ Alice สามารถใช้ลายมือชื่อของตนเองเพื่อใช้จ่ายเงินนี้หลังจากเวลา T ผ่านไป 01928374656574839201

ผลลัพธ์ของ "01928374656574839201" คงต้องเหมือนเดิม

ผลลัพธ์: ประเภท "หรือ ... หรือ ..." นี้ถูกสร้างขึ้นโดยใช้โค้ดควบคุมกระบวนการ

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

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

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

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

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

Lighting Network 与闪电网络

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

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

วิธีการแก้ปัญหานี้ของทางช่องทางระหว่างการเงินครั้งนี้เรียกว่า "LN-Penalty" ตอนนี้ สมมติว่า Alice และ Bob มี 5 BTC ในช่องทางหนึ่ง ๆ; ตอนนี้ Alice ต้องการจ่ายเงินให้กับ Bob 1 BTC ดังนั้นเซ็นสัญญาการซื้อขายแบบนี้และส่งไปยัง Bob:

ป้อน #0, 10 BTC: อลี-บ็อบ 2-of-2 การแสดงผลหลายลายเซ็น (หรือสัญญาช่องทาง)

แปลเป็นภาษาไทย: ส่งออก #0, 4 BTC: Alice เซ็นเอกสารเดี่ยว

การส่งออก #1, 6 BTC: ทั้ง Alice-Bob พร้อมกันกับกุญแจสาธารณะชั่วคราว #1 หรือลายเวลา T1, Bob แบบเดี่ยวสามารถทำเครื่องหมายได้

"Bob 也签名一笔（跟上述交易恰成对应的）承诺交易，并发送给 Alice：" -> "บ็อบก็เซ็นชื่อในการทำธุรกรรมสัญญา (ที่สอดคล้องกับการซื้อขายด้านบน) และส่งให้แอลิซ:"

ป้อน #0, 10 BTC: Alie-Bob 2-of-2 การแสดงผลที่มีลายเซ็นหลายรูปแบบ (หรือที่เรียกว่าสัญญาช่องทาง)

ส่งออก #0,6 BTC: Bob เซ็นเดียว

การแปลเนื้อหาจากภาษาจีนตัวย่อไปเป็นภาษาไทยคือ "ผลลัพธ์ #1, 4 BTC: อย่างใดอย่างหนึ่งคือการลงลายมือร่วมกันของ Bob-Alice ด้วยกุญแจสาธารณะชั่วคราว #1 หรือล็อคเวลา T1, อย่างเดี่ยวของ Alice"

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

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

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

เนื่องจากข้างต้น การออกแบบทางสายรัศมีนั้นมีความสำคัญ:

สองฝ่ายมักจะใช้การซื้อขายสัญญาเพื่อแสดงสถานะภายในสัญญาและแสดงการชำระเงินในรูปแบบของจำนวนที่เปลี่ยนแปลง;

คำสัญญาการซื้อขายมักจะใช้เงินที่เดียวกันเป็นอินพุต (ต้องมีลายมือจากทั้งสองฝ่าย) ดังนั้นการซื้อขายที่เป็นคำสัญญาจะแข่งขันกันและมีเพียงแค่รายการเดียวที่จะได้รับการยืนยันในบล็อกเชนได้เท่านั้น;

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

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

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

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

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

Alice -- HTLC --\u003e Bob -- HTLC --\u003e Carol -- HTLC --\u003e Daniel

Alice <-- 原像 -- Bob <-- 原像 -- Carol <-- 原像 -- Daniel

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

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

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

สัญญาบันทึกอย่างระมัดระวัง

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

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

R = r.G # ค่า nonce ที่ใช้ในการเซ็นต์ r คูณกับจุดที่สร้างขึ้นจากเส้นโค้งเท่ากับกุญแจสาธารณะของ r

s = r + Hash(R || m || P) \* p # p คือ รหัสส่วนตัวของลายเซ็น, P คือ กุญแจสาธารณะ

การตรวจสอบลายเซ็นคือการตรวจสอบ s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK

假设我给出了一对数据(R, s')，其中：

R = R1 + R2 = r1.G + r2.G

s' = r1 + Hash(R || m || P) \* p

显然，นี่ไม่ใช่ลายเซ็นต์ Schnorr ที่ถูกต้อง ซึ่งไม่สามารถผ่านสูตรการตรวจสอบ แต่ฉันสามารถพิสูจน์ต่อผู้ตรวจสอบว่าเพียงแค่ TA ทราบคีย์ส่วนตัว r2 ของ R2 ก็สามารถทำให้มันกลายเป็นลายเซ็นต์ที่ถูกต้อง:

s'.G + R2 = R1 + Hash(R || m || P) \* P + R2 = R + Hash(R || m || P) \* P

สัญญานั้นเกี่ยวข้องอย่างไรกับการเซ็นต์สัญญาณที่อาจเกิดขึ้นสำหรับข้อมูลลับใดๆที่สามารถตรวจสอบได้ 01928374656574839201

假设 Alice และ Bob ต้องการเดิมพันผลการแข่งขันฟุตบอล Alice และ Bob วางเดิมพันว่า Green Mo เป็นผู้ชนะ ถ้า Carol ผู้ดำเนินการเว็บไซต์ประเมินผลบอล จะเซ็นต์ผลลัพธ์ด้วย nonce ที่ชื่อ R_c และลงลายมือด้วย s_c_i

สามารถเห็นได้ว่ามีทั้งหมดสามผลลัพธ์ที่เป็นไปได้ (ดังนั้นลายเซ็นของ Carol มีสามผลลัพธ์ที่เป็นไปได้):

• สีเขียวชนะ อลิซชนะ 1 BTC
• Arinana wins, Bob wins 1 BTC
• สองฝ่ายที่เท่ากัน ทุกเงินที่ถูกใช้ได้รับคืนเงินในที่เดิม 01928374656574839201

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

ใส่ #0, 2 BTC: Alie-Bob 2-of-2 ผลลัพธ์หลายลายเซ็น (หรือสัญญาการพนัน)

ผลลัพธ์ #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 || 'สีเขียวชนะ' || PK_c) * PK_c)

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

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

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

สี่. บทนำการใช้งานของข้อจำกัด

OP_CTV และการควบคุมการจราจรแออัด

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

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

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

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

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

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

หรือ Alice และ Bob จะใช้ร่วม หรือ หลังจากนั้น Alice สามารถใช้เองได้

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

OP_Vault กับตู้เซฟ

OP_VAULT เป็นคำขอข้อเสนอที่ถูกสร้างขึ้นเพื่อสร้าง "สัญญาหีบหลอด (vaults)" ที่มีข้อจำกัดโดยเฉพาะ 01928374656574839201

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

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

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

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

完整的 OP_VAULT 提议也利用了一些交易池策略（mempool policy）上的提议（比如 v3 格式的交易）以取得更好的效果。这提醒了我们 “编程” 的含义可以比我们想象的更为广泛。（一个相似的例子是 Nervos Network 里面的 Open Transaction。）

ห้า. เข้าใจ CKB

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

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

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

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

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

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

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

ความสามารถในการตั้งโปรแกรม Lock ที่คำนวณได้ทุกอย่าง

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

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

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

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

ความสามารถในการตั้งโปรแกรมของประเภทที่เป็นการคำนวณแบบอย่างอิสระ

เหตุการณ์ที่กล่าวมาข้างต้น ใช้สำหรับการเขียนโปรแกรม UDT ของ Type อย่างหนึ่ง กับ Lock นั้น หมายความว่าเราสามารถทำให้มีการสร้างช่องทางการแลกเปลี่ยนที่เป็นสัญญาณแบบฟ้าผ่าโดยใช้ UDT เป็นที่สิ้นสุด (รวมถึงสัญญาณอื่น ๆ ของชนิดต่าง ๆ)

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

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

举个例子：笔者曾经提出过一种在BTC上实现免信任NFT担保借贷的โปรโตคอล。这种โปรโตคอล的关键是一种承诺交易，其输入的价值是小于输出的价值的（因此它还不算是一笔有效的交易），但是，一旦能够为这笔交易提供足额的输入，它就是一笔有效的交易：一旦贷款人能够还款，放贷者就不能将质押的NFT据为己有。但是，这个承诺交易的免信任性基于交易对输入和输出的数额的检查，所以贷款人只能使用BTC来还款 —— 即使贷款人和放贷者都愿意接受另一种货币（比如以RGBโปรโตคอล发行的USDT），BTC的承诺交易也无法保证只要贷款人归还了足额的USDT就能拿回自己的NFT，因为BTC交易根本不知道USDT的状态！（修订：换言之，无法构造出以USDT还款为条件的承诺交易。）

If we can initiate an inspection according to the definition of UDT, it will allow the lender to sign another commitment transaction, allowing the borrower to repay the loan using USDT. The transaction will check the input and output quantities of USDT, thereby giving users the ability to repay using USDT without trust.

修订：假定这里用作抵押的 NFT 和用于还款的 token 是使用同一โปรโตคอล（比如 RGB）การออก的，那么，这里的问题是能够解决的，我们可以根据 RGB โปรโตคอล构造一种承诺交易，使得 NFT 的状态转换和还款可以同步发生（在 RGB โปรโตคอล内用交易绑定两个状态转换）。但是，因为 RGB 的交易也要依赖于BTC 交易，这里的承诺交易的构造会有一定的难度。总而言之，尽管问题可以解决，但做不到บิทคอยน์ is first-class citizen。

ต่อไปเราจะพิจารณาความสามารถในการสะท้อนตัวของตนเองอีกครั้ง 01928374656574839201

Lock อ่าน Lock อื่น ๆ

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

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

เลือกอ่านประเภทอื่น (รวมถึงข้อมูล)

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

ประเภท อ่าน Lock อื่น ๆ

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

Type Scirpt อ่าน Type s อื่น ๆ (และ Data) ได้

คุณสามารถแปล "集换卡？集齐 n 个 token 可以换取更大的一个 token : )" จากภาษาจีนแบบตัวย่อได้หรือไม่ ขอบคุณครับ

หก. สรุป

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

"การแก้ไข:"

1. โดยไม่พิจารณาความสามารถในการเข้าถึงแบบ Cross-cell (หรือความสามารถในการภายใน) การล็อค S สามารถถือว่าเป็น Bitcoin ที่มีความสามารถในการเข้าถึงและความสามารถในการเขียนโปรแกรมที่แข็งแกร่งสุด ๆ ดังนั้นเพียงแค่จุดนี้ก็สามารถเขียนโปรแกรมทุกอย่างที่ใช้ Bitcoin ได้ทั้งหมด

2. โดยไม่พิจารณาความสามารถในการเข้าถึงข้ามเซลล์ (เช่นความสามารถในการสืบเสาะข้อมูลภายใน) การแยกแยะ lock s และ type s สามารถถือเป็นการอัพเกรดความปลอดภัย: มันแบ่งแยกการกำหนดทรัพย์สินของ UDT และวิธีการเก็บรักษา; นอกจากนี้ type s (รวมถึง Data) ที่เปิดเผยสถานะนั้นเป็นการให้ UDT เป็นพลเมืองชั้นนำ

สองข้อดังกล่าวหมายความว่ามีสิ่งที่เหมือนกับ "BTC + RGB" ในพาราดิม แต่มีความสามารถในการเขียนโปรแกรมที่แข็งแกร่งกว่า

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

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

ขอบคุณ

ขอบคุณ Retric, Jan Xie และ Xue Jie สำหรับคำแนะนำที่ให้มาในกระบวนการเขียนบทความ แน่นอนว่าความผิดพลาดทั้งหมดในบทความนี้เป็นความผิดของฉันเอง

"การอ้างอิง: "

5._07_05_ความรู้เบื้องต้น_เกี่ยวกับ_ ckb_โมเดลการตรวจสอบและโปรแกรม/

6.（二）ระมัดระวังสัญญาบันทึก (DLC)

13.\_QUESTION/discussions/7