"พันธสัญญา" ของ Bitcoin เป็นกลไกที่กําหนดเงื่อนไขสําหรับการทําธุรกรรม Bitcoin ในอนาคต บทความนี้สรุปแนวคิดพื้นฐานสถานการณ์การใช้งานและวิธีการใช้งานทางเทคนิคของข้อ จํากัด และกล่าวถึงหลักการออกแบบที่อยู่เบื้องหลัง มีการแนะนําข้อเสนอทางเทคนิคเช่น OP_CAT, OP_CTV และ APO และวิธีที่พวกเขาปรับปรุงความสามารถในการตั้งโปรแกรมและฟังก์ชั่นสัญญาอัจฉริยะของ Bitcoin ในเวลาเดียวกันบทความยังสัมผัสกับการใช้ข้อ จํากัด ในเครือข่าย Bitcoin เช่นการควบคุมความแออัดห้องนิรภัยช่องทางสถานะ ฯลฯ และหารือเกี่ยวกับแนวคิดการออกแบบสําหรับการใช้ข้อ จํากัด และข้อพิพาทของชุมชนที่อาจเกิดขึ้น

ร่วมเขียนโดยเจฟเฟรี่ หูและHarper Li

นี่คือคลื่นลูกล่าสุดของการอภิปรายในชุมชน Bitcoin เกี่ยวกับการเปิดใช้งาน opcodes อีกครั้งเช่น OP_CAT และ Taproot Wizard ได้รับความสนใจอย่างมากจากการเปิดตัว NFT ของ Quantum Cats โดยอ้างว่าได้รับมอบหมาย BIP-420 ผู้เสนออ้างว่าการเปิดใช้งาน OP_CAT จะตระหนักถึง "พันธสัญญา" และนํามาซึ่งสัญญาอัจฉริยะหรือความสามารถในการตั้งโปรแกรมใน Bitcoin

หากคุณสังเกตคำว่า "covenants" และค้นหาเล็กน้อย คุณจะเห็นว่านี่เป็นรู้เรืองที่ซับซ้อนอีกอันหนึ่ง นักพัฒนาได้พูดถึงเทคโนโลยีที่ใช้ในการสร้าง covenants มาหลายปี เช่น OP_CTV, APO, OP_VAULT และอื่น ๆ นอกจาก OP_CAT

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

ดังนั้น Bitcoin's “covenants” คืออะไร? ทำไมมันถึงดึงดูดความสนใจและการอภิปรายจากนักพัฒนามาโดยเป็นเวลาหลายปี? ความสามารถในการตั้งโปรแกรมของ Bitcoin สามารถบรรลุได้อย่างไร? หลักการออกแบบที่อยู่เบื้องหลังมีอะไรบ้าง? บทความนี้พยายามให้ภาพรวมและการอภิปราย

Covenants คืออะไร?

Covenant เป็นกลไกที่สามารถตั้งเงื่อนไขบนธุรกรรม Bitcoin ในอนาคต

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

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

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

ดังนั้นอย่างที่น่าจะไม่ได้คาดคิด สิ่งนี้นำเสนอสถานการณ์การใช้งานที่มากขึ้น

สถานการณ์การใช้งาน

การรับรองการลงทุนโดยมีการลงโทษ

หนึ่งในตัวอย่างที่เข้าใจง่ายที่สุดเกี่ยวกับสัญญาคือ กระบวนการ Slashing ของ Babylon ในกระบวนการเดิมพันบิทคอยน์

กระบวนการสเตคบิทคอยน์ของ Babylon นั้น เกี่ยวข้องกับผู้ใช้ที่ส่ง BTC ของตนไปยังสคริปต์พิเศษบนเชนหลักด้วยเงื่อนไขการใช้จ่ายสองรูปแบบ:

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

Source: Bitcoin Staking: Unlocking 21M Bitcoins to Secure the Proof-of-Stake Economy

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

คุณสมบัตินี้หลังจากการนำ covenant เช่น OP_CTV มาใช้งาน สามารถนำมาใช้งานได้โดยการเพิ่ม opcodes ไปยัง "bad ending" ของสคริปต์การจับมัด

ก่อนที่ OP_CTV จะเปิดใช้งาน บาบิลอนจะต้องมี workaround เพื่อจำลองผลของการบังคับ covenants โดยการทำงานร่วมกันของผู้ใช้ + คณะกรรมการ

ควบคุมการประสาน/มาตราส่วน

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

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

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

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

Source: https://utxos.org/uses/scaling/

สถานการณ์นี้เป็นหนึ่งในกรณีการใช้งานที่สามารถพบได้มากขึ้นโดยข้อจำกัด OP_CTV นี้ มีกรณีการใช้งานอีกมากมายที่สามารถพบได้ที่ https://utxos.org/uses.นอกจากการควบคุมการแอคทราฟฟิกของการจราจรที่กล่าวถึงข้างต้น หน้าเว็บรายชื่อการเดิมพัน Soft Fork Bets, ตัวเลือกแบบกระจาย, Drivechains, Batch Channels, ช่อง Non-Interactive, สระเหมือง Trustless Coordination-Free, ห้องเก็บของ, สัญญา Safer Hashed Time Locked (HTLCS) Limits, และอื่น ๆ

ห้องเก็บของ

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

โดยอ้างอิงจากเทคนิคที่ใช้ในการดำเนินการข้อจำกัดความสามารถนี้ ห้องเก็บรักษาที่มีลักษณะนี้สามารถสร้างได้อย่างสะดวก

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

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

กระบวนการของ OP_VAULT แหล่งที่มา: BIP-345

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

Precomputed vaults และ OP_VAULT โดยมีที่มา: BIP-345

ช่องสถานะที่แข็งแรงและยืดหยุ่นมากขึ้น

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

Eltoo (ที่เป็นที่รู้จักในชื่อ LN-Symmetry) เป็นตัวอย่างที่โดดเด่น โดยการใช้ตัวอักษรย่อของ "L2" เทคโนโลยีนี้เสนอชั้นการดำเนินการสำหรับ Lightning Network ที่อนุญาตให้สถานะของช่องหลังสุดสามารถแทนที่สถานะก่อนหน้าโดยไม่มีกลไกโทษ ซึ่งจะป้องกันประสิทธิภาพเพื่อให้โหนดของ Lightning Network ไม่จำเป็นต้องบันทึกสถานะก่อนหน้าหลายรายการเพื่อป้องกันอันตรายจากฝ่ายศัตรูในการกระทำที่ไม่เป็นธรรม เพื่อให้ได้ผลลัพธ์ดังกล่าว Eltoo เสนอลายเซ็นเจอร์ SIGHASH_NOINPUT และ APO (BIP-118)

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

ภาพรวมของสัญญา

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

• ประเภท: ทั่วไป, จำกัด
• การปฏิบัติ: ขึ้นอยู่กับโอป๊คอด ขึ้นอยู่กับลายเซ็นต์
• Recursion: recursive, non-recursive

ที่นี่ recursive หมายถึง: มีบางการดำเนินการของสัญญาที่ยังสามารถ จำกัดผลลัพธ์ของธุรกรรมถัดไปได้โดย จำกัดผลลัพธ์ของธุรกรรมนี้ ซึ่งหมายถึง ธุรกรรมแต่ละรายการในโซ่ของธุรกรรมถูก จำกัดโดยธุรกรรมก่อนหน้า

บางส่วนของการออกแบบสัญญายอดนิยมมีดังนี้:

การออกแบบของพันธบัญญัติ

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

เหตุผลหลักคือสคริปต์ Bitcoin ปัจจุบันไม่สามารถอ่านธุรกรรมเองซึ่งหมายความว่าการสอดคล้องของธุรกรรม

หากเราสามารถใช้การสะท้อนภายใน - การตรวจสอบทุกอย่างในธุรกรรม (รวมถึงเอาท์พุต) - เราก็สามารถใช้การใช้งานได้

ดังนั้นการออกแบบของสัญญาก็เน้นไปที่วิธีการนำมาใช้แบบสะท้อนตัวเอง

การใช้ Opcode เป็นพื้นฐานเทียบกับการใช้ลายเซ็นเจอร์

ความคิดที่ง่ายและหยาบโดยสุดคือการเพิ่มออปโค้ดหนึ่งหรือมากกว่า (หนึ่งออปโค้ด + พารามิเตอร์หลายตัว หรือหลายออปโค้ดที่มีฟังก์ชันต่างกัน) และอ่านเนื้อหาของธุรกรรมโดยตรง สิ่งนี้เรียกว่าความคิดที่ขึ้นอยู่กับออปโค้ด

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

APO

SIGHASH_ANYPREVOUT (APO) เป็นข้อเสนอสำหรับฮาชลายลายรายเซ็นเซ็นเจอร์ วิธีที่ง่ายที่สุดในการเซ็นคือการสัญญาว่าทั้งในและทั้งในของธุรกรรม แต่มีวิธีที่ยืดหยุ่นกว่าสำหรับบิตคอยน์ในการสัญญาว่าทั้งแหละหรือทั้งออกของธุรกรรมที่รู้จักกันดีว่า SIGHASH

ช่วงปัจจุบันของ SIGHASH และการรวมกันของลายเซ็นเจอร์สำหรับข้อมูลนำเข้าและข้อมูลส่งออกของธุรกรรม

ดังที่แสดงไว้ข้างต้นนอกเหนือจาก ALL ซึ่งใช้กับข้อมูลทั้งหมดแล้ว NONE จะถูกเซ็นชื่อในลักษณะที่ใช้กับอินพุตทั้งหมดเท่านั้นและไม่ใช่กับเอาต์พุตและ SINGLE สร้างสิ่งนี้โดยนําไปใช้กับเอาต์พุตที่มีหมายเลขดัชนีอินพุตเดียวกันเท่านั้น นอกจากนี้ SIGHASH ยังสามารถรวมเข้าด้วยกันโดยมีตัวปรับแต่ง ANYONECANPAY ซ้อนทับเพื่อใช้กับอินพุตเดียวเท่านั้น

APO's SIGHASH, อีกอย่างที่สำคัญคือ ลงลายเฉพาะส่วนเอาท์พุตเท่านั้น ไม่ได้ลงลายเพื่ออินพุต นั่นหมายความว่า ธุรกรรมที่ลงลายด้วย APO สามารถแนบไปยัง UTXO ใดก็ได้ในภายหลังที่ตรงตามเงื่อนไข

ความยืดหยุ่นนี้คือเหตุผลของการนำเสนอของ APO ในการดำเนินการตามข้อกำหนด:

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

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

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

ปัญหาของกระบวนการดังกล่าว อย่างไรก็ตามคือ ว่ามีdev@lists.linuxfoundation.org/msg08075.html">ความขึ้นอยู่แบบวงรีในการคำนวณ เนื่องจากต้องใช้ข้อมูลนำเข้าในการลงลายล่วงหน้าและสร้างธุรกรรม

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

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), หรือ BIP-119, ใช้การปรับปรุง Opcode โดยมีการใช้อาร์กิวเมนต์เป็นค่าความมั่นใจ และต้องการให้ธุรกรรมใดที่เรียกใช้ opcode มีชุดเอาต์พุตที่ตรงกับความมั่นใจนั้น ด้วย CTV จะช่วยให้ผู้ใช้ Bitcoin สามารถจำกัดวิธีการใช้ Bitcoin ได้

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

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

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

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

ต้นฐาน:https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

เช่นเดียวกับ APO ที่อยู่สามารถสร้างได้ตามเงื่อนไขการใช้จ่ายและ "ล็อค" สามารถทําได้หลายวิธีรวมถึงคีย์พิเศษไทม์ล็อคสัมพัทธ์หรือคงที่และตรรกะอื่น ๆ เพื่อรวมเข้าด้วยกัน

Source: https://twitter.com/OwenKemeys/status/1741575353716326835

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

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

แหล่งที่มา: https://twitter.com/OwenKemeys/status/1741575353716326835

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

แหล่งที่มา: https://twitter.com/OwenKemeys/status/1744181234417140076

ตั้งแต่วันที่โครงการถูกเสนอ CTV ได้เปลี่ยนชื่อจาก COSHV เมื่อปี 2019 และได้รับการกำหนด BIP-119 เมื่อปี 2020 และการเกิดขึ้นของ Sapio ซึ่งเป็นภาษาโปรแกรมที่ใช้สร้างสัญญาเพื่อสนับสนุน CTV และได้รับการอภิปรายจากชุมชนมากมาย การปรับปรุง และการโต้วาทีเกี่ยวกับตัวเลือกในการเปิดใช้งานในปี 2022 และ 2023 และยังคงเป็นหนึ่งในข้อเสนออัพเกรดซอฟต์ฟอร์คที่ได้รับการอภิปรายมากที่สุดในชุมชน

OP_CAT

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

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

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

การประยุกต์ใช้ OP_CAT อื่น ๆ รวมถึงBistream,ลายเซ็นต์ต้นไม้, ลามพอร์ตที่ต้าอนาโควียมที่ต้าอนา, ตู้, และอื่น ๆ

OP_CAT ตัวเองไม่ใช่คุณลักษณะใหม่เนื่องจากมีอยู่ในรุ่นแรกของบิทคอยน์แต่ก็ปิดการใช้งานในปี 2010 เนื่องจากศักยภาพในการถูกโจมตี ตัวอย่างเช่น การใช้ OP_DUP และ OP_CAT ซ้ำ ๆ อาจทำให้ full node stack ระเบิดได้อย่างง่าย ๆ เมื่อประมวลผลสคริปต์เหล่านี้ เช่นที่เห็นใน demo.

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

ดังนั้น โดยผสมผสานฉากการใช้งานและความเสี่ยงที่เป็นไปได้ OP_CAT ได้รับความสนใจมากเมื่อเร็วๆ นี้ และยังมีการทบทวน PR, และเป็นหนึ่งในข้อเสนออัปเกรดที่ฮอตเทสที่สุดในขณะนี้

สรุป

“การกำกับดูแลตนเองนำความเสรีไปมา”, ดังที่เห็นจากบทนำข้างต้น สัญญาสามารถถูกนำมาใช้งานโดยตรงลงในสคริปต์ของบิทคอยน์เพื่อให้มีการใช้จ่ายเพิ่มเติมในธุรกรรม ซึ่งทำให้มีกฎเกณฑ์ในการทำธุรกรรมที่คล้ายกับสมาร์ตคอนแทรคต่างๆ การเขียนโปรแกรมนี้สามารถที่จะทำการตรวจสอบได้อย่างเป็นธรรมชาติกว่าในบิทคอยน์มากกว่าวิธีการที่เกิดขึ้นนอกเครือข่ายเช่น BitVM และยังสามารถปรับปรุงแอปพลิเคชันบนโซนหลักได้อีกด้วย (การควบคุมการแอพลิเคชันที่แอบแฝง) แอปพลิเคชันนอกเครือข่าย (ช่องสถานะ) และทิศทางใหม่ของแอปพลิเคชันอื่นๆ (การเสียสลัวการค้ำประกัน ฯลฯ)

เทคนิคการปรับใช้ของสัญญาร่วมกับการอัปเกรดบางอย่างอาจเปิดรอบของความสามารถในการตั้งโปรแกรมได้อีกมาก ตัวอย่างเช่น การเสนอล่าสุดสำหรับการคำนวณ 64 บิต

ในreview could be further combined with the proposed OP_TLUV หรือสัญญาอื่น ๆ ที่สามารถโปรแกรมได้ตามจำนวนของ satoshi ที่เป็นเอาท์พุตจากธุรกรรม

อย่างไรก็ตาม, ข้อตกลงก็สามารถเป็นสาเหตุให้เกิดการใช้งานอย่างไม่คาดคิดหรือมีช่องโหว่ ดังนั้นชุมชนก็ระมัดระวังในเรื่องนี้เช่นกัน นอกจากนี้, การอัพเกรดของข้อตกลงยังต้องใช้การอัพเกรดโฟร์คที่อ่อนนุ่มของกฎกติกา โดยดูจากสถานการณ์ที่เกี่ยวข้องกับการอัพเกรด taproot, มีโอกาสที่การอัพเกรดที่เกี่ยวข้องกับข้อตกลงก็จะใช้เวลาในการเสร็จสิ้นเช่นกัน

ขอขอบคุณพิเศษ

ขอบคุณ Ajian, Fisherและเบนสำหรับการตรวจสอบและคำแนะนำ!

การอ้างอิง

• https://utxos.org/
• https://bitcoincovenants.com/
• คอลเลกชันของทรัพยากรที่เกี่ยวข้องกับพันธบัตร: https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
• https://anyprevout.xyz/
• BIP 345: ข้อเสนอ OP_VAULThttps://www.btcstudy.org/2023/04/13/บิทคอยน์-ความสามารถในการตั้งโปรแกรม-345-op-vault-commit-0b0674c546/
• https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/th/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

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

อัปเดตข่าวล่าสุดจาก HashKey Capital -

เว็บไซต์ — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

รายงาน:

1. บทความนี้ถูกคัดลอกมาจาก [สื่อ] ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [Jeffrey Hu และ Harper Li], if you have any objections to the reprint, please contact the เกตเรียนทีม และทีมจะดำเนินการโดยเร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง

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

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