ผู้เขียนต้นฉบับ: HashKey Capital หัวหน้าฝ่ายวิจัยการลงทุน Jeffrey HU, Harper LI ผู้จัดการการลงทุน HashKey Capital
เมื่อเร็ว ๆ นี้ มีกระแสการอภิปรายในชุมชน Bitcoin เกี่ยวกับการเปิดใช้งาน opcodes เช่น OP_CAT อีกครั้ง Taproot Wizard ยังดึงดูดความสนใจของผู้คนจำนวนมากด้วยการเปิดตัว Quantum Cats NFT และอ้างว่าได้รับหมายเลข BIP-420 ผู้สนับสนุนอ้างว่าการเปิดใช้งาน OP_CAT สามารถเปิดใช้งาน พันธสัญญา สัญญาอัจฉริยะ หรือความสามารถในการตั้งโปรแกรมของ Bitcoin ได้
หากคุณสังเกตเห็นคำว่า ข้อจำกัด และค้นหาเพียงเล็กน้อย คุณจะพบว่านี่เป็นช่องโหว่ขนาดใหญ่อีกแห่งหนึ่ง นักพัฒนาพูดคุยกันมานานหลายปี นอกเหนือจาก OP_CAT แล้ว ยังมี OP_CTV, APO, OP_VAULT และเทคนิคอื่นๆ เพื่อใช้ข้อกำหนดที่เข้มงวด
แล้ว “ข้อจำกัด” ของ Bitcoin คืออะไรกันแน่? เหตุใดจึงดึงดูดความสนใจและการอภิปรายของนักพัฒนาจำนวนมากมาหลายปีแล้ว Bitcoin สามารถตั้งโปรแกรมประเภทใดได้บ้าง? หลักการออกแบบเบื้องหลังคืออะไร? บทความนี้พยายามให้ภาพรวมและการอภิปราย
“ข้อจำกัด” คืออะไร
Covenant แปลว่า ข้อจำกัด ในภาษาจีน และบางครั้งแปลว่า สัญญา เป็นกลไกที่สามารถกำหนดเงื่อนไขสำหรับธุรกรรม Bitcoin ในอนาคต
สคริปต์ Bitcoin ปัจจุบันยังมีเงื่อนไขที่เข้มงวด เช่น การป้อนลายเซ็นทางกฎหมายและการส่งสคริปต์ที่ตรงกันเมื่อใช้จ่าย แต่ตราบใดที่ผู้ใช้สามารถปลดล็อคได้ เขาสามารถใช้ UTXO ได้ทุกที่ที่ต้องการ
ข้อจำกัดคือการสร้างข้อจำกัดเพิ่มเติมตามวิธีปลดล็อกข้อจำกัดนี้ เช่น การจำกัดการใช้จ่ายหลัง UTXO ซึ่งให้บรรลุผลคล้ายกับ เงินทุนเฉพาะ หรือเงื่อนไขอินพุตอื่นๆ ที่ส่งในการรอธุรกรรม
พูดอย่างเคร่งครัดมากขึ้น สคริปต์ Bitcoin ปัจจุบันยังมีข้อจำกัดบางประการ ตัวอย่างเช่น การล็อคเวลาตามรหัสการดำเนินการคือการตระหนักถึงขีดจำกัดเวลาก่อนที่ธุรกรรมจะใช้โดยการพินิจพิเคราะห์ฟิลด์ nLock หรือ nSequence ของธุรกรรม แต่โดยพื้นฐานแล้ว จำกัดด้วยข้อจำกัดด้านเวลา
เหตุใดนักพัฒนาและนักวิจัยจึงออกแบบการตรวจสอบขีดจำกัดเหล่านี้ เนื่องจากข้อจำกัดไม่ได้เป็นเพียงข้อจำกัดเพื่อประโยชน์ของข้อจำกัดเท่านั้น แต่ยังกำหนดกฎเกณฑ์สำหรับการดำเนินการธุรกรรมด้วย ด้วยวิธีนี้ ผู้ใช้สามารถดำเนินธุรกรรมตามกฎที่กำหนดไว้ล่วงหน้าเท่านั้น เพื่อให้กระบวนการทางธุรกิจที่กำหนดไว้ล่วงหน้าเสร็จสมบูรณ์
สิ่งนี้สามารถปลดล็อกสถานการณ์การใช้งานแอปพลิเคชันได้มากขึ้น
สถานการณ์การใช้งาน
รับรองว่าจะมีบทลงโทษจากการปักหลัก
หนึ่งในตัวอย่างที่เข้าใจง่ายที่สุดของข้อกำหนดที่เข้มงวดคือธุรกรรมแบบเฉือนของ Babylon ในกระบวนการวางเดิมพัน Bitcoin
กระบวนการวางเดิมพัน Bitcoin ของ Babylon นั้นให้ผู้ใช้ส่งสินทรัพย์ BTC ของพวกเขาไปยังสคริปต์พิเศษบนเครือข่ายหลัก เงื่อนไขการใช้จ่ายมีสองประเภท:
ตอนจบที่มีความสุข: หลังจากช่วงระยะเวลาหนึ่ง ผู้ใช้สามารถปลดล็อคมันได้ด้วยลายเซ็นของเขาหรือเธอ ซึ่งจะทำให้กระบวนการยกเลิกการเดิมพันเสร็จสมบูรณ์
ตอนจบที่ไม่ถูกต้อง: หากผู้ใช้กระทำการที่ชั่วร้าย เช่น การลงนามสองครั้งบนเครือข่าย PoS บางอย่างที่ Babylon เช่า จากนั้นผ่าน EOTS (ลายเซ็นแบบครั้งเดียวที่แยกได้ ลายเซ็นแบบแยกได้แบบครั้งเดียว) ส่วนของสินทรัพย์นี้สามารถปลดล็อคได้ และผู้บริหารในเครือข่ายบังคับให้ทรัพย์สินส่วนหนึ่งถูกส่งไปยังที่อยู่ที่ถูกเผา (สแลช)
ที่มา: Bitcoin Stake: ปลดล็อก 21 M Bitcoins เพื่อรักษาความปลอดภัยของระบบเศรษฐกิจที่พิสูจน์การเดิมพัน
โปรดใส่ใจกับ การบังคับส่ง ที่นี่ ซึ่งหมายความว่าแม้ว่า UTXO นี้จะสามารถปลดล็อกได้ แต่เนื้อหาจะไม่สามารถส่งไปที่อื่นได้ตามอำเภอใจ และทำได้เพียงเผาทิ้งเท่านั้น สิ่งนี้จะช่วยให้มั่นใจได้ว่าผู้ใช้ที่ประสงค์ร้ายจะไม่สามารถใช้ลายเซ็นที่รู้จักเพื่อโอนสินทรัพย์กลับไปหาตนเองเพื่อหลบหนีการลงโทษ
หากมีการใช้งานฟังก์ชันนี้หลังจากมีการใช้ข้อจำกัด เช่น OP_CTV แล้ว opcode เช่น OP_CTV สามารถเพิ่มลงในสาขา การสิ้นสุดที่ไม่ดี ของสคริปต์การปักหลักเพื่อใช้ข้อจำกัดได้
ก่อนที่จะเปิดใช้งาน OP_CTV Babylon จำเป็นต้องใช้วิธีการที่ยืดหยุ่น ซึ่งดำเนินการร่วมกันโดยผู้ใช้และคณะกรรมการ เพื่อจำลองผลกระทบของการบังคับใช้ข้อกำหนดข้อจำกัด
การควบคุมความแออัด
โดยทั่วไป ความแออัดหมายถึงเมื่อค่าธรรมเนียมการทำธุรกรรมบนเครือข่าย Bitcoin สูงมาก และมีธุรกรรมสะสมมากขึ้นในกลุ่มธุรกรรมที่รอการบรรจุ ดังนั้น หากผู้ใช้ต้องการยืนยันธุรกรรมอย่างรวดเร็ว พวกเขาจำเป็นต้องเพิ่มค่าธรรมเนียมการทำธุรกรรม
ในเวลานี้ หากผู้ใช้ต้องส่งธุรกรรมหลายรายการไปยังผู้รับเงินหลายราย เขาจะต้องเพิ่มค่าธรรมเนียมการจัดการและแบกรับต้นทุนที่ค่อนข้างสูง ในขณะเดียวกันก็จะผลักดันอัตราการจัดการของเครือข่ายทั้งหมดให้สูงขึ้นอีกด้วย
หากมีข้อจำกัด วิธีแก้ปัญหาหนึ่งคือให้ผู้ส่งยอมรับธุรกรรมการส่งแบบแบตช์ คำสัญญานี้สามารถทำให้ผู้รับทุกคนเชื่อว่าธุรกรรมขั้นสุดท้ายจะได้รับการดำเนินการ และพวกเขาสามารถรอจนกว่าอัตราการจัดการต่ำก่อนที่จะส่งธุรกรรมที่เฉพาะเจาะจงได้
ดังที่แสดงในแผนภูมิด้านล่าง เมื่อความต้องการพื้นที่บล็อกสูง การทำธุรกรรมจะมีราคาแพงมาก ด้วยการใช้ OP_CHECKTEMPLATEVERIFY ผู้ประมวลผลการชำระเงินปริมาณมากสามารถรวมการชำระเงินทั้งหมดเป็นธุรกรรม O(1) เดียวเพื่อการยืนยัน จากนั้น เมื่อเวลาผ่านไป เมื่อความต้องการพื้นที่บล็อกลดลง การชำระเงินก็สามารถปรับขนาดออกจาก UTXO นั้นได้ 
ที่มา: https://utxos.org/uses/scaling/
สถานการณ์นี้เป็นกรณีแอปพลิเคชันทั่วไปที่เสนอโดยข้อกำหนดข้อจำกัด OP_CTV สามารถดูกรณีการสมัครเพิ่มเติมได้ที่ https://utxos.org/uses/ พูล, ห้องนิรภัย, ขีดจำกัดสัญญาล็อคเวลาแฮชที่ปลอดภัยยิ่งขึ้น (HTLCS) ฯลฯ
ห้องนิรภัย
ห้องนิรภัยเป็นสถานการณ์การใช้งานที่มีการพูดคุยกันอย่างกว้างขวางในแอปพลิเคชัน Bitcoin โดยเฉพาะอย่างยิ่งในด้านข้อกำหนดที่เข้มงวด เนื่องจากการดำเนินงานรายวันจำเป็นต้องมีความสมดุลระหว่างการดูแลกองทุนและความต้องการการใช้กองทุนอย่างหลีกเลี่ยงไม่ได้ ผู้คนจึงหวังว่าจะมีแอปพลิเคชันตู้นิรภัยประเภทหนึ่งที่สามารถรับประกันความปลอดภัยของกองทุน และยังจำกัดความปลอดภัยของเงินทุนแม้ว่าบัญชีจะถูกแฮ็กก็ตาม (รหัสส่วนตัวคือ รั่วไหล) การใช้เงินทุน
แอปพลิเคชันคลาส Vault สามารถสร้างได้ค่อนข้างง่ายโดยใช้เทคนิคสำหรับการนำข้อจำกัดไปใช้
ใช้การออกแบบของ OP_VAULT เป็นตัวอย่าง: เมื่อใช้จ่ายเงินในห้องนิรภัย ธุรกรรมจะต้องถูกส่งไปยังลูกโซ่ก่อน ธุรกรรมนี้บ่งบอกถึงความตั้งใจที่จะใช้ vault ซึ่งเป็น ทริกเกอร์ และกำหนดเงื่อนไขภายใน:
หากทุกอย่างเรียบร้อยดี ธุรกรรมที่สองจะเป็นธุรกรรมที่ทำการถอนเงินครั้งสุดท้าย หลังจากรอ N บล็อก คุณจะสามารถใช้เงินต่อไปได้ทุกที่
หากพบว่าธุรกรรมนี้ถูกขโมย (หรือถูกบังคับระหว่าง การโจมตีด้วยประแจ) สามารถส่งไปยังที่อยู่ที่ปลอดภัยอื่นได้ทันที (พื้นที่เก็บข้อมูลที่ปลอดภัยยิ่งขึ้นสำหรับผู้ใช้) ก่อนที่จะส่งธุรกรรมการถอนของบล็อก N
กระบวนการสำหรับ OP_VAULT แหล่งที่มา: BIP-345
ควรสังเกตว่าสามารถสร้างแอปพลิเคชัน vault ได้โดยไม่มีข้อจำกัด วิธีที่เป็นไปได้คือการใช้คีย์ส่วนตัวเพื่อเตรียมลายเซ็นสำหรับการใช้จ่ายในอนาคต จากนั้นจึงทำลายคีย์ส่วนตัว อย่างไรก็ตาม ยังมีข้อจำกัดหลายประการ เช่น ความจำเป็นเพื่อให้แน่ใจว่าคีย์ส่วนตัวถูกทำลาย (คล้ายกับกระบวนการตั้งค่าที่เชื่อถือได้ในการพิสูจน์ความรู้เป็นศูนย์) จำนวนเงินและค่าธรรมเนียมการจัดการจะถูกกำหนดล่วงหน้า (เนื่องจากความจำเป็นในการ การลงนามล่วงหน้า) และขาดความยืดหยุ่น
การเปรียบเทียบ OP_VAULT และกระบวนการ vault ที่ลงนามล่วงหน้า แหล่งที่มา: BIP-345
ช่องทางของรัฐที่แข็งแกร่งและยืดหยุ่นมากขึ้น
โดยทั่วไปถือได้ว่าช่องทางของรัฐ รวมถึง Lightning Network นั้นมีความปลอดภัยเกือบจะเหมือนกับเชนหลัก (โดยมีเงื่อนไขว่าโหนดสามารถสังเกตสถานะล่าสุดและโดยปกติสามารถเผยแพร่สถานะล่าสุดไปยังเชนได้) อย่างไรก็ตาม ด้วยข้อจำกัด แนวคิดการออกแบบช่องสถานะใหม่บางรายการอาจมีความแข็งแกร่งหรือยืดหยุ่นมากขึ้นนอกเหนือจาก Lightning Network ที่รู้จักกันดี ได้แก่ Eltoo, Ark เป็นต้น
Eltoo (หรือที่เรียกว่า LN-Symmetry) เป็นหนึ่งในตัวอย่างทั่วไป โซลูชันทางเทคนิคนี้มีลักษณะคล้ายคลึงกับ L2 และเสนอเลเยอร์การดำเนินการสำหรับ Lightning Network ที่ช่วยให้สถานะของช่องสัญญาณที่ตามมาสามารถแทนที่สถานะก่อนหน้าได้โดยไม่จำเป็นต้องใช้กลไกการลงโทษ ดังนั้นจึงสามารถหลีกเลี่ยงความจำเป็นในการบันทึกที่คล้ายคลึงกับ Lightning โหนดเครือข่าย สถานะก่อนหน้าหลายรายการเพื่อป้องกันไม่ให้คู่ต่อสู้ของคุณทำสิ่งชั่วร้าย เพื่อให้บรรลุผลข้างต้น Eltoo ได้เสนอวิธีการลงนาม SIGHASH_NOINPUT ซึ่งก็คือ APO (BIP-118)
Ark มีเป้าหมายเพื่อลดปัญหาด้านสภาพคล่องขาเข้าและการจัดการช่องทางของ Lightning Network มันเป็นรูปแบบโปรโตคอล joinpool ผู้ใช้หลายคนสามารถรับผู้ให้บริการเป็นคู่สัญญาภายในระยะเวลาหนึ่งและทำธุรกรรม UTXO เสมือน (vUTXO) นอกเชน แต่แชร์ UTXO บนเชนเพื่อลดต้นทุน เช่นเดียวกับห้องนิรภัย Ark ยังสามารถนำไปใช้กับเครือข่าย Bitcoin ในปัจจุบันได้ อย่างไรก็ตาม หลังจากแนะนำข้อจำกัด Ark ก็สามารถลดจำนวนการโต้ตอบที่จำเป็นตามเทมเพลตธุรกรรมและบรรลุทางออกฝ่ายเดียวที่น่าเชื่อถือมากขึ้น
ภาพรวมทางเทคนิคของข้อจำกัด
ดังที่เห็นได้จากแอปพลิเคชันข้างต้น คำสั่งที่เข้มงวดมีลักษณะเหมือนเอฟเฟกต์มากกว่าเทคโนโลยีบางอย่าง ดังนั้นจึงมีวิธีทางเทคนิคมากมายในการนำไปใช้ หากจัดประเภทไว้ อาจรวมถึง:
ประเภท: ประเภททั่วไป, ประเภทพิเศษ
วิธีการนำไปใช้: ขึ้นอยู่กับ Opcode ตามลายเซ็น
การเรียกซ้ำ: เรียกซ้ำ, ไม่เรียกซ้ำ
ในหมู่พวกเขา การเรียกซ้ำหมายถึงการดำเนินการตามข้อจำกัดบางอย่าง คุณยังสามารถจำกัดเอาต์พุตถัดไปได้โดยการจำกัดเอาต์พุตถัดไป
การออกแบบข้อ จำกัด ที่ได้รับความนิยมบางส่วน ได้แก่ : 
* การเรียกซ้ำ: หากรวมกับ OP_CAT
การออกแบบข้อจำกัด
ดังที่เห็นได้จากบทนำก่อนหน้านี้ สคริปต์ Bitcoin ในปัจจุบันจำกัดเงื่อนไขในการปลดล็อคเป็นหลัก และไม่จำกัดวิธีใช้ UTXO ต่อไป ในการใช้ข้อจำกัด เราต้องคิดย้อนกลับ: เหตุใดสคริปต์ Bitcoin ในปัจจุบันจึงไม่สามารถใช้ข้อจำกัดดังกล่าวได้
สาเหตุหลักคือสคริปต์ Bitcoin ปัจจุบันไม่สามารถอ่านเนื้อหาของธุรกรรมได้ นั่นก็คือ วิปัสสนา ของธุรกรรม
หากเราสามารถใช้วิปัสสนาธุรกรรม - ตรวจสอบเนื้อหาใด ๆ ของธุรกรรม (รวมถึงผลลัพธ์) เราก็สามารถใช้ข้อจำกัดได้
ดังนั้น แนวคิดการออกแบบของข้อกำหนดที่เข้มงวดจึงมุ่งเน้นไปที่วิธีการบรรลุวิปัสสนาเป็นหลัก
อิง Opcode เทียบกับลายเซ็น
แนวคิดที่ง่ายที่สุดและหยาบคายที่สุดคือการเพิ่ม opcode หนึ่งรายการขึ้นไป (เช่น opcode หนึ่งรายการ + พารามิเตอร์หลายรายการ หรือ opcode หลายรายการที่มีฟังก์ชันต่างกัน) เพื่ออ่านเนื้อหาของธุรกรรมโดยตรง นี่คือแนวคิดที่อิงตามรหัสการดำเนินการ
อีกแนวคิดหนึ่งคือคุณไม่สามารถอ่านและตรวจสอบเนื้อหาของธุรกรรมในสคริปต์ได้โดยตรง แต่คุณสามารถใช้แฮชของเนื้อหาธุรกรรมได้ - หากแฮชได้รับการลงนามแล้ว ให้แก้ไขในสคริปต์เช่น OP_CHECKSIG After การตรวจสอบลายเซ็นนี้ เราสามารถใช้วิปัสสนาและข้อจำกัดของธุรกรรมทางอ้อมได้ แนวคิดนี้มีพื้นฐานมาจากการออกแบบลายเซ็นต์ ส่วนใหญ่รวมถึง APO และ OP_CSFS เป็นต้น
เอพีโอ
SIGHASH_ANYPREVOUT (APO) เป็นวิธีลายเซ็น Bitcoin ที่นำเสนอ วิธีที่ง่ายที่สุดในการลงนามคือยอมรับทั้งอินพุตและเอาท์พุตของธุรกรรม แต่ Bitcoin ก็มีวิธีที่ยืดหยุ่นกว่าเช่นกัน นั่นคือ SIGHASH ซึ่งเลือกยอมรับอินพุตหรือเอาท์พุตของธุรกรรม
ช่วงลายเซ็นปัจจุบันของ SIGHASH และการรวมกันสำหรับอินพุตและเอาต์พุตธุรกรรม (ที่มา: Mastering Bitcoin, 2 nd
ดังแสดงในรูปด้านบน นอกเหนือจาก ALL ที่ใช้กับข้อมูลทั้งหมดแล้ว วิธีลายเซ็น NONE ยังใช้กับอินพุตทั้งหมดเท่านั้นและไม่ได้ใช้สำหรับเอาต์พุต SINGLE อิงตามสิ่งนี้และใช้กับเอาต์พุตที่มีหมายเลขลำดับอินพุตเดียวกันเท่านั้น นอกจากนี้ SIGHASH ยังสามารถรวมเข้าด้วยกันได้ หลังจากวางตัวแก้ไข ANYONECANPAY ไว้แล้ว จะใช้ได้กับอินพุตเดียวเท่านั้น
SIGHASH ของ APO จะลงนามเฉพาะเอาต์พุตเท่านั้น ไม่ใช่ส่วนอินพุต นอกจากนี้ยังหมายความว่าธุรกรรมที่ลงนามกับ APO สามารถแนบกับ UTXO ใดๆ ที่ตรงตามเงื่อนไขได้ในภายหลัง
ความยืดหยุ่นนี้เป็นพื้นฐานทางทฤษฎีสำหรับ APO ในการใช้ข้อกำหนดที่เข้มงวด:
สามารถสร้างธุรกรรมอย่างน้อยหนึ่งรายการล่วงหน้าได้
การใช้ข้อมูลของธุรกรรมเหล่านี้จะสร้างคีย์สาธารณะที่สามารถรับลายเซ็นได้เท่านั้น
วิธีนี้ทำให้ทรัพย์สินใดๆ ที่ส่งไปยังที่อยู่คีย์สาธารณะนั้นสามารถใช้ได้ผ่านธุรกรรมที่สร้างไว้ล่วงหน้าเท่านั้น
เป็นที่น่าสังเกตว่าเนื่องจากคีย์สาธารณะนี้ไม่มีคีย์ส่วนตัวที่เกี่ยวข้อง จึงมั่นใจได้ว่าสินทรัพย์เหล่านี้จะสามารถใช้ได้ผ่านธุรกรรมที่สร้างไว้ล่วงหน้าเท่านั้น จากนั้น เราสามารถกำหนดปลายทางของสินทรัพย์ในธุรกรรมที่สร้างไว้ล่วงหน้าเหล่านี้เพื่อใช้ข้อกำหนดที่เข้มงวดได้
เราสามารถเข้าใจเพิ่มเติมได้โดยการเปรียบเทียบสัญญาอัจฉริยะของ Ethereum: สิ่งที่เราสามารถทำได้ผ่านสัญญาอัจฉริยะก็คือ เมื่อผ่านเงื่อนไขบางประการเท่านั้นที่เราจะสามารถถอนเงินจากที่อยู่ของสัญญา แทนที่จะใช้จ่ายตามอำเภอใจด้วยลายเซ็น EOA จากมุมมองนี้ Bitcoin สามารถบรรลุผลนี้ผ่านการปรับปรุงกลไกลายเซ็น
แต่ปัญหาของกระบวนการข้างต้นคือมีการพึ่งพาแบบวงกลมในการคำนวณ เนื่องจากจำเป็นต้องทราบว่าอินพุตจำเป็นต้องลงนามล่วงหน้าและสร้างธุรกรรม
ความสำคัญของ APO และ SIGHASH_NOINPUT ที่ใช้วิธีลายเซ็นนี้คือสามารถแก้ปัญหาการพึ่งพาแบบวงกลมนี้ได้ เมื่อคำนวณ คุณเพียงแค่ต้องรู้ (ระบุ) ผลลัพธ์ทั้งหมดของธุรกรรมเท่านั้น
OP_CTV
OP_CHECKTEMPLATEVERIFY (CTV), BIP-119 ใช้วิธีการปรับปรุง Opcode ใช้แฮชความมุ่งมั่นเป็นพารามิเตอร์ และต้องการให้ธุรกรรมใดๆ ที่ดำเนินการ opcode มีชุดของเอาต์พุตที่ตรงกับความมุ่งมั่นนั้น ผ่าน CTV ผู้ใช้ Bitcoin จะได้รับอนุญาตให้จำกัดวิธีการใช้ Bitcoin
ข้อเสนอเดิมเปิดตัวภายใต้ชื่อ OP_CHECKOUTPUTSHASHVERIFY (COSHV) และในช่วงต้นมุ่งเน้นไปที่ความสามารถในการสร้างธุรกรรมการควบคุมความแออัด ดังนั้นการวิพากษ์วิจารณ์ข้อเสนอยังมุ่งเน้นไปที่โครงการที่ไม่กว้างพอและเฉพาะเจาะจงเกินไปสำหรับกรณีการใช้งานการควบคุมความแออัด
ในกรณีการใช้งานการควบคุมความแออัดที่กล่าวถึงข้างต้น ผู้ส่ง Alice สามารถสร้างและแฮชเอาต์พุต 10 รายการ และใช้การแยกย่อยผลลัพธ์เพื่อสร้างสคริปต์ tapleaf ที่มี COSHV อลิซยังสามารถใช้กุญแจสาธารณะของผู้เข้าร่วมเพื่อสร้างคีย์ภายในของ Taproot ช่วยให้พวกเขาสามารถทำงานร่วมกันในการใช้จ่ายโดยไม่ต้องเปิดเผยเส้นทางสคริปต์ของ Taproot
จากนั้น Alice มอบสำเนาเอาต์พุตทั้ง 10 รายการให้ผู้รับแต่ละคน เพื่อให้แต่ละคนสามารถตรวจสอบธุรกรรมการตั้งค่าของ Alice ได้ เมื่อพวกเขาต้องการใช้จ่ายการชำระเงินในภายหลัง ทั้งสองสามารถสร้างธุรกรรมที่มีผลลัพธ์ที่สัญญาไว้ได้
ตลอดกระบวนการ ขณะที่ Alice สร้างและส่งธุรกรรมการตั้งค่า Alice ก็สามารถส่งสำเนาเอาต์พุตทั้ง 10 ชุดนี้ผ่านวิธีการสื่อสารแบบอะซิงโครนัสที่มีอยู่ เช่น อีเมลหรือคลาวด์ไดรฟ์ ซึ่งหมายความว่าผู้รับไม่จำเป็นต้องออนไลน์หรือโต้ตอบกัน
ที่มา: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments
เช่นเดียวกับ APO ที่อยู่สามารถสร้างได้ตามเงื่อนไขการใช้จ่าย และ ล็อค สามารถทำได้หลายวิธี รวมถึงการเพิ่มคีย์อื่นๆ การล็อคเวลา และตรรกะที่รวมกันได้
ที่มา: https://twitter.com/OwenKemeys/status/1741575353716326835
บนพื้นฐานนี้ CTV เสนอให้สามารถตรวจสอบได้ว่าธุรกรรมการใช้จ่ายที่แฮชตรงกับคำจำกัดความหรือไม่ กล่าวคือ ข้อมูลธุรกรรมสามารถใช้เป็นกุญแจในการเปิด ล็อค
เราสามารถขยายตัวอย่างข้างต้นของตัวรับ 10 ตัวต่อไปได้ ผู้รับสามารถตั้งค่าคีย์ที่อยู่ของตนเป็น tx ที่ลงนามแต่ยังไม่ออกอากาศ และส่งไปยังที่อยู่ผู้รับชุดถัดไป และอื่นๆ เพื่อสร้างระบบดังแสดงในรูปด้านล่าง . โครงสร้างต้นไม้. อลิซสามารถสร้างการเปลี่ยนแปลงยอดคงเหลือในบัญชีที่เกี่ยวข้องกับผู้ใช้หลายรายโดยใช้พื้นที่บล็อก utxo เพียง 1 บล็อกบนเชน
ที่มา: https://twitter.com/OwenKemeys/status/1741575353716326835
แล้วถ้าใบไม้ใบหนึ่งเป็นช่องทางสายฟ้า ห้องเย็น หรือเส้นทางการชำระเงินอื่นๆล่ะ? จากนั้นแผนผังนี้จะขยายจากแผนผังรายจ่ายมิติเดียวและหลายระดับเป็นแผนผังรายจ่ายหลายมิติและหลายระดับ และสถานการณ์ที่สามารถรองรับได้จะสมบูรณ์ยิ่งขึ้นและยืดหยุ่นมากขึ้น
ที่มา: https://twitter.com/OwenKemeys/status/1744181234417140076
นับตั้งแต่มีการเสนอ CTV ก็เปลี่ยนชื่อจาก COSHV ในปี 2019 และได้รับมอบหมายให้เป็น BIP-119 ในปี 2020 และกลายเป็นภาษาโปรแกรม Sapio เพื่อสร้างการสนับสนุนสัญญา CTV ในปี 22 และ 23 ได้รับการพูดคุยกันมากมาย การอัปเดตและการอัปเดตจากชุมชน การถกเถียงเกี่ยวกับแผนการเปิดใช้งานยังคงเป็นหนึ่งในข้อเสนอการอัพเกรด soft fork ที่มีการพูดคุยกันมากขึ้นในชุมชน
OP_CAT
ตามที่แนะนำในตอนต้น OP_CAT ยังเป็นข้อเสนอการอัปเกรดที่กำลังดึงดูดความสนใจอย่างมาก ฟังก์ชั่นที่ใช้คือการเชื่อมสององค์ประกอบเข้าด้วยกันในสแต็ก แม้ว่าจะดูเหมือนง่าย แต่ OP_CAT ก็มีความยืดหยุ่นมากในการปรับใช้ฟังก์ชันต่างๆ ในสคริปต์
ตัวอย่างที่ตรงที่สุดคือการดำเนินการที่เกี่ยวข้องกับต้นไม้ Merkle ต้นไม้ Merkle สามารถเข้าใจได้ว่าเป็นสององค์ประกอบที่ถูกประกบกันก่อนแล้วจึงแฮช ปัจจุบันมีรหัสการดำเนินการแฮช เช่น OP_SHA 256 ในสคริปต์ Bitcoin ดังนั้นหาก OP_CAT สามารถใช้เพื่อแยกสององค์ประกอบได้ ฟังก์ชันการตรวจสอบของต้นไม้ Merkle ก็สามารถนำมาใช้ในสคริปต์ได้ ซึ่งยังมีการตรวจสอบไคลเอ็นต์แบบ light อีกด้วย ขอบเขตความสามารถ
พื้นฐานการใช้งานเพิ่มเติมยังรวมถึงการปรับปรุงลายเซ็น Schnorr: เงื่อนไขลายเซ็นการใช้จ่ายของสคริปต์สามารถตั้งค่าเป็นการเชื่อมต่อคีย์สาธารณะของผู้ใช้และ nonce สาธารณะ ดังนั้นหากผู้ลงนามต้องการลงนามในธุรกรรมอื่น เงินจะถูกนำไปใช้ที่อื่น เพื่อใช้ nonce เดียวกันและทำให้คีย์ส่วนตัวรั่วไหล นั่นคือความมุ่งมั่นต่อ nonce นั้นรับรู้ผ่าน OP_CAT ดังนั้นจึงรับประกันความถูกต้องของธุรกรรมที่ลงนาม
สถานการณ์การใช้งานอื่นๆ ของ OP_CAT ได้แก่: Bistream, ลายเซ็นต้นไม้, ลายเซ็น Lamport ที่ต้านทานควอนตัม, ห้องนิรภัย ฯลฯ
OP_CAT ไม่ใช่ฟีเจอร์ใหม่ มันมีอยู่ใน Bitcoin เวอร์ชันแรกสุด แต่ถูกปิดใช้งานในปี 2010 เนื่องจากอาจถูกโจมตีได้ ตัวอย่างเช่น การใช้ OP_DUP และ OP_CAT ซ้ำอาจทำให้โหนดเต็มระเบิดสแต็กได้อย่างง่ายดายเมื่อประมวลผลสคริปต์ดังกล่าว ดูการสาธิตนี้
แต่ปัญหาการระเบิดของสแต็กที่กล่าวถึงข้างต้นจะไม่เกิดขึ้นหากเปิดใช้งาน OP_CAT อีกครั้งตอนนี้หรือไม่ เนื่องจากข้อเสนอ OP_CAT ปัจจุบันเกี่ยวข้องกับการเปิดใช้งานใน tapscript เท่านั้น และ tapscript จำกัดแต่ละองค์ประกอบสแต็กไว้ที่ไม่เกิน 520 ไบต์ ปัญหาการระเบิดของสแต็กก่อนหน้านี้จะไม่เกิดขึ้น นอกจากนี้ยังมีนักพัฒนาบางคนที่เชื่อว่าการแบน OP_CAT ของ Satoshi Nakamoto โดยตรงอาจรุนแรงเกินไป อย่างไรก็ตาม เนื่องจากความยืดหยุ่นของ OP_CAT สถานการณ์แอปพลิเคชันบางอย่างที่อาจทำให้เกิดช่องโหว่จึงไม่สามารถหมดลงได้ในขณะนี้
ดังนั้น เมื่อพิจารณาถึงสถานการณ์การใช้งานและความเสี่ยงที่อาจเกิดขึ้น OP_CAT จึงได้รับความสนใจเป็นอย่างมากเมื่อเร็วๆ นี้ และยังได้รับการตรวจทานด้านประชาสัมพันธ์อีกด้วย ถือเป็นข้อเสนออัปเกรดที่ได้รับความนิยมมากที่สุดรายการหนึ่งในปัจจุบัน
บทสรุป
วินัยในตนเองนำมาซึ่งอิสรภาพ ดังที่เห็นได้จากบทนำข้างต้น คำสั่งที่เข้มงวดสามารถนำไปใช้ได้โดยตรงในสคริปต์ Bitcoin เพื่อจำกัดการใช้จ่ายในการทำธุรกรรมเพิ่มเติม ดังนั้นจึงบรรลุกฎการทำธุรกรรมที่คล้ายกับผลกระทบของสัญญาอัจฉริยะ เมื่อเปรียบเทียบกับวิธีนอกเครือข่าย เช่น BitVM วิธีการเขียนโปรแกรมนี้สามารถตรวจสอบ Bitcoin ได้แบบเนทีฟมากกว่า และยังสามารถปรับปรุงแอปพลิเคชันบนเครือข่ายหลัก (การควบคุมความแออัด) แอปพลิเคชันนอกเครือข่าย (ช่องทางสถานะ) และทิศทางแอปพลิเคชันใหม่อื่น ๆ ( การลงโทษจากการปักหลัก ฯลฯ)
หากนำเทคโนโลยีการใช้งานข้อกำหนดข้อจำกัดมารวมกับการอัพเกรดพื้นฐานบางอย่างได้ ก็จะเป็นการปลดปล่อยศักยภาพของความสามารถในการตั้งโปรแกรมเพิ่มเติม ตัวอย่างเช่น ข้อเสนอโอเปอเรเตอร์ 64 บิตที่อยู่ระหว่าง การตรวจสอบ เมื่อเร็วๆ นี้สามารถนำไปรวมกับ OP_TLUV ที่เสนอหรือข้อจำกัดอื่นๆ ที่สามารถตั้งโปรแกรมตามจำนวนเอาต์พุต satoshi ตามธุรกรรม
อย่างไรก็ตาม ข้อกำหนดที่เข้มงวดอาจนำไปสู่การละเมิดหรือช่องโหว่โดยไม่ได้วางแผนไว้ ดังนั้นชุมชนจึงระมัดระวังเรื่องนี้มากขึ้น นอกจากนี้ การอัพเกรดข้อจำกัดยังต้องมีการอัพเกรด soft fork ของกฎที่เป็นเอกฉันท์ เนื่องจากสถานการณ์ระหว่างการอัพเกรด taproot การอัพเกรดที่เกี่ยวข้องกับข้อจำกัดอาจต้องใช้เวลาในการดำเนินการให้เสร็จสิ้น
ขอขอบคุณ Ajian, Fisher และ Ben สำหรับการวิจารณ์และข้อเสนอแนะในบทความนี้!
อ้างอิง
https://utxos.org/
แหล่งช่วยที่เกี่ยวข้องกับพันธสัญญา:
https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
https://anyprevout.xyz/
BIP 345: ข้อเสนอ OP_VAULT: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf
https://maltemoeser.de/paper/covenants.pdf
https://bitcoinops.org/en/topics/op_cat/
OP_CAT:
https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
เคล็ดลับ CAT และ Schnorr: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
