ภาพรวม

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

วิปัสสนาหมายถึงความสามารถของสคริปต์ bitcoin ในการตรวจสอบและ จํากัด ข้อมูลธุรกรรม สิ่งนี้ช่วยให้สคริปต์สามารถควบคุมการใช้เงินตามรายละเอียดธุรกรรมเฉพาะทําให้ฟังก์ชันการทํางานที่ซับซ้อนมากขึ้น ปัจจุบัน Bitcoin opcodes ส่วนใหญ่จะผลักข้อมูลที่ผู้ใช้ให้มาลงบนสแต็กหรือจัดการข้อมูลที่มีอยู่บนสแต็ก อย่างไรก็ตาม Introspection opcodes สามารถผลักดันข้อมูลจากธุรกรรมปัจจุบัน (เช่นการประทับเวลาจํานวนเงิน txid ฯลฯ ) ไปยังสแต็กทําให้สามารถควบคุมการใช้จ่าย UTXO ได้ละเอียดยิ่งขึ้น

ในขณะนี้มีเพียงสามรหัสคำสั่งหลักในสคริปต์บิตคอยน์ที่รองรับการสำรวจ: checklocktimeverify, checksequenceverify และ checksig พร้อมกับตัวแปรของมัน checksigverify, checksigadd, checkmultisig, และ checkmultisigverify

covenant, โดยง่าย คือ การ จำกัด วิธี การ โอน ยอด ธนาคาร ที่ อนุญาตให้ผู้ใช้ระบุว่า อัตราการแลกเปลี่ยน utxos ได้อย่างไร มี covenant มากมายที่ถูกนำมาใช้ผ่าน introspection opcodes และการอภิปรายเกี่ยวกับการอวสรรทางถูกจัดอยู่ในหัวข้อของการทำสัญญาบิทคอยน์ optech.

บิทคอยน์ ปัจจุบันมีสองสัญญาซึ่งคือ csv (checksequenceverify) และ cltv (checklocktimeverify) ทั้งคู่เป็นสัญญาที่เชื่อมโยงกับเวลาซึ่งเป็นพื้นฐานสำหรับการขยายมากของตัวแก้ปัญหาเช่น lightning network นี้แสดงให้เห็นว่าการขยายมิติของบิทคอยน์ พึงพอใจในการดูดซึมและสัญญา

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

ด้านล่างเราจะอธิบายข้อเสนอโค้ดสัญญาที่ได้รับความสนใจอย่างแพร่หลาย

ctv (checktemplateverify) bip-119

CTV (CheckTemplateVerify) เป็นข้อเสนอการอัปเกรด Bitcoin ที่มีอยู่ใน BIP-119 ซึ่งได้รับความสนใจจากชุมชนอย่างมาก CTV ช่วยให้สคริปต์เอาต์พุตสามารถระบุเทมเพลตสําหรับการใช้จ่ายเงินในธุรกรรมรวมถึงฟิลด์เช่น Nversion, NlockTime, Scriptsig Hash, Input Count, Sequences Hash, Output Count, Outputs Hash, Input Index ข้อจํากัดเทมเพลตเหล่านี้ถูกนําไปใช้ผ่านข้อผูกมัดแฮช และเมื่อใช้เงินสคริปต์จะตรวจสอบว่าค่าแฮชของฟิลด์ที่ระบุในธุรกรรมการใช้จ่ายตรงกับค่าแฮชในสคริปต์อินพุตหรือไม่ สิ่งนี้จํากัดเวลา วิธีการ และจํานวนธุรกรรมในอนาคตของ UTXO นั้นอย่างมีประสิทธิภาพ

นอกจากนี้ยังไม่นับ txid เป็นส่วนหนึ่งของการหาค่าแฮชนี้ การไม่นับ txid เป็นสิ่งจำเป็นเพราะในทั้งกรณีของธรรมดาและ segwit transactions ค่า txid ขึ้นอยู่กับค่าใน scriptpubkey เมื่อใช้ default sighash_all signing type การรวม txid จะสร้างความขึ้นอยู่กับการขึ้นอยู่รอบเดียวกันในการยืนยันแฮช ทำให้เป็นไปไม่ได้ที่จะสร้าง

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

รากฐานของความสามารถของเบื้องหลังของ Bitcoin เช่นเครือข่ายฟ้าผ่าที่เป็นโซลูชันชั้นสองแบบ pre-signed transactions การ pre-signing โดยทั่วไปจะหมายถึงการสร้างและลงชื่อเอกสารล่วงหน้า แต่ไม่ได้ส่งออกไปจนกว่าเงื่อนไขบางอย่างจะถูกตรงตาม ในพลังงานของเรา ctv จะนำมาใช้ในรูปแบบ pre-signing ที่เข้มงวดมากขึ้น โพสต์การสัญญาณการ pre-signing บนรายการ จำกัดไว้ในเทมเพลตที่กำหนดล่วงหน้า

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

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

apo (sighash_anyprevout) bip-118

bip-118 มีการแนะนำธงแซนเนเจอร์ชนิดใหม่สำหรับ tapscript ซึ่งมีวัตถุประสงค์เพื่อให้การใช้เงินที่ยืดหยุ่นมากขึ้นที่รู้จักกันดีเป็น sighash_anyprevout apo และ ctv มีความคล้ายคลึงกันมาก ขณะที่ที่จัดการกับปัญหาทางวงจรระหว่าง scriptpubkeys และ txids โดยวิธีการของ apo คือการยกเว้นข้อมูลนำเข้าที่เกี่ยวข้องและลงนามเฉพาะเอาท์พุทเท่านั้น ซึ่งทำให้ธุรกรรมสามารถผูกติดกับ utxos ที่แตกต่างกันได้โดยไดนามิก

โดยตรงแล้วการดำเนินการตรวจสอบลายเซ็นต์ op_checksig (และรุ่นย่อย) มีหน้าที่สามารถดำเนินการได้สามสิ่ง:

1. ประสานส่วนของธุรกรรมการใช้จ่าย
2. แฮชพวกเขา
3. การตรวจสอบว่าแฮชได้รับการลงนามโดยคีย์ที่กำหนด

รายละเอียดของลายเซ็นเจอร์มีความยืดหยุ่นมากมาย โดยการตัดสินใจเกี่ยวกับฟิลด์ธุรกรรมที่จะทำลายถูกกำหนดโดยธง sighash ตามนิยามของคำสั่งลายเซ็นต์ในบิพ 342 ธง sighash ถูกแบ่งเป็น sighash_all, sighash_none, sighash_single, และ sighash_anyonecanpay ธง sighash_anyonecanpay ควบคุมข้อมูลนำเข้า ในขณะที่อีกอันควบคุมข้อมูลเอาท์พุท

sighash_all เป็นธง sighash เริ่มต้นที่เซ็นสำหรับเอาท์พุตทั้งหมด; sighash_none เซ็นท์เอาท์พุตทั้งหมด; sighash_single เซ็นท์เอาท์พุตที่ระบุ เซ็นท์เอาท์พุตที่ระบุ เซ็นท์เอาท์พุตที่ระบุ เซ็นท์เอาท์พุตที่ระบุ เซ็นท์เอาท์พุตที่ระบุ เซ็นท์เอาท์พุตที่ระบุ ถ้าตั้งค่า sighash_anyonecanpay, ธงสามถึงฉบับแรกเท่านั้นที่ถูกเซ็นท์; มิเช่นนั้น, จะต้องเซ็นท์ข้อมูลทั้งหมด

อย่างแน่ชัด เสาธง sighash เหล่านี้ไม่กำจัดผลกระทบของอินพุต แม้ว่า sighash_anyonecanpay ซึ่งต้องการยืนยันกับอินพุตหนึ่ง

ดังนั้น BIP 118 จึงเสนอ sighash_anyprevout ลายเซ็น APO ไม่จําเป็นต้องผูกมัดกับ utxo อินพุตที่ใช้ไป (เรียกว่า prevout) แต่ต้องลงนามในเอาต์พุตเท่านั้นให้ความยืดหยุ่นในการควบคุม bitcoin มากขึ้น โดยการทําธุรกรรมก่อนการสร้างและการสร้างลายเซ็นแบบใช้ครั้งเดียวที่สอดคล้องกันและคีย์สาธารณะสินทรัพย์ที่ส่งไปยังที่อยู่คีย์สาธารณะนั้นจะต้องใช้ผ่านธุรกรรมที่สร้างไว้ล่วงหน้าดังนั้นจึงดําเนินการตามพันธสัญญา ความยืดหยุ่นของ APO ยังสามารถใช้สําหรับการซ่อมแซมธุรกรรม หากธุรกรรมติดอยู่ในห่วงโซ่เนื่องจากค่าธรรมเนียมต่ําสามารถสร้างธุรกรรมอื่นได้อย่างง่ายดายเพื่อเพิ่มค่าธรรมเนียมโดยไม่ต้องใช้ลายเซ็นใหม่ ยิ่งไปกว่านั้นสําหรับกระเป๋าเงินหลายลายเซ็นไม่ได้ขึ้นอยู่กับอินพุตที่ใช้ไปทําให้การดําเนินงานสะดวกยิ่งขึ้น

เนื่องจากมันกำจัดการจักรวาลระหว่าง scriptpubkeys และ input txids ได้ apo สามารถทำการสำรวจด้วยการเพิ่มข้อมูล output ในพยาน แม้ว่านี้ยังต้องการการบริโภคพื้นที่พยานเพิ่มเติม

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

ว่าที่วิจารณ์หลักของ apo คว่ำมายอยู่ที่ความจำเป็นของมันต้องมีเวอร์ชันคีย์ใหม่ซึ่งไม่สามารถนำมาใช้งานได้โดยการย้อนกลับได้อย่างง่ายดาย นอกจากนี้ ชนิดแหล่งแสดงลายเซ็นเจอร์ใหม่อาจเปิดโอกาสให้เกิดความเสี่ยงของการใช้จ่ายซ้ำด้วย หลังจากการอภิปรายกับชุมชนอย่างแพร่หลาย apo ได้เพิ่มลายเซ็นเจอร์ปกติลงไปเหนือลายเซ็นเจอร์ต้นฉบับเพื่อบรรเทาความกังวลด้านความปลอดภัย ซึ่งทำให้ได้รับ bip-118 code

op_vault bip-345

BIP-345 เสนอให้เพิ่ม opcodes ใหม่สองตัวคือ op_vault และ op_vault_recover ซึ่งเมื่อรวมกับ CTV จะใช้พันธสัญญาพิเศษที่อนุญาตให้ผู้ใช้บังคับใช้ความล่าช้าในการใช้เหรียญเฉพาะ ในระหว่างความล่าช้านี้ธุรกรรมที่ทําไว้ก่อนหน้านี้สามารถ "ย้อนกลับ" ผ่านเส้นทางการกู้คืน

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

op_vault ทำอย่างไรในการปฏิบัติการถอดถอนเวลาที่สามารถหยุดชะงักได้? op_vault ทำได้นี้โดยการแทนที่สคริปต์ op_vault ที่ใช้ไปด้วยสคริปต์ที่ระบุไว้ ซึ่งทำให้มีการอัปเดตใบเดียวของต้นไม้ mast ในขณะที่ทำให้ใบอื่น ๆ ของต้นไม้ taproot ไม่เปลี่ยนแปลง การออกแบบนี้คล้ายกับ tluv แต่ op_vault ไม่รองรับการอัปเดตกุญแจภายใน

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

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

การนำ vault ผ่าน bip-345 มีความจำเป็นที่จะต้องพิจารณาเรื่องค่าใช้จ่ายโดยเฉพาะสำหรับธุรกรรมการกู้คืน ทางเลือกที่เป็นไปได้รวมถึง cpfp (child pays for parent) จุดยึดชั่วคราว และธงแฮชสำหรับลายเซ็นต์กลุ่มใหม่

tluv (tapleafupdateverify)

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

แนวคิดของโครงการ tluv คือการสร้างที่อยู่ taproot ใหม่โดยขึ้นอยู่กับอินพุทการใช้จ่ายปัจจุบันโดยการนำเข้า opcode ใหม่ tapleaf_update_verify สามารถทำได้โดยการดำเนินการหนึ่งหรือมากกว่าหนึ่งของการดำเนินการต่อไปนี้:

1. อัปเดตคีย์สาธิตภายใน
2. ตัดเส้นทาง Merkle
3. ลบสคริปต์ที่กำลังทำงานอยู่
4. เพิ่มขั้นตอนใหม่ที่จุดสุดท้ายของเส้นทาง Merkle

โดยเฉพาะอย่างยิ่ง tluv ยอมรับอินพุตสามอย่าง

1. หนึ่งที่ระบุวิธีการอัปเดตคีย์สาธารณะภายใน
2. หนึ่งที่ระบุขั้นตอนใหม่สำหรับเส้นทางเมอร์เคิล
3. หนึ่งที่ระบุว่าจะเอาสคริปต์ปัจจุบันออกหรือไม่ และ/หรือตัดกี่ขั้นตอนของเส้นทางเมอร์เคิล

โอปโค้ด tluv คำนวณ updated scriptpubkey และยืนยันว่าเอาต์พุตที่สอดคล้องกับอินพุตปัจจุบันได้ถูกใช้จ่ายให้กับ scriptpubkey นี้

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

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

การสำรวจจำนวนเงินที่เข้ามาเพิ่มความ复杂 เนื่องจากจำนวนเงินในรูปแบบ satoshis ต้องใช้สูงสุดถึง 51 บิตเพื่อแทนแต่สคริปต์อนุญาตให้ทำการคำนวณทางคณิตศาสตร์ได้เพียง 32 บิต เรื่องนี้ต้องการนิยามพฤติกรรม opcode เพื่ออัพเกรดตัวดำเนินการในสคริปต์ หรือใช้ sighash_group เพื่อแทนที่ in_out_amount

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

แมตต์

Matt (เมอร์เคิลไอซ์ออลเดอะธิงส์) มีเป้าหมายในการบรรลุวัตถุประสงค์สามประการ: เมอร์เคิลไอซ์สเตต, เมอร์เคิลไอซ์สคริปต์, และเมอร์เคิลไอซ์เอ็กซิวชัน ซึ่งทำให้สามารถสร้างสัญญาอัจฉริยะแบบสากลได้

1. การเมอร์เคิลไอซ์สถานะ: นี้เกี่ยวข้องกับการสร้างเมอร์เคิลไตร, ที่ในนั้นแต่ละโหนดใบหน้าแทนแฮชของสถานะ, พร้อมกับรากเมอร์เคิลที่แสดงสถานะโดยรวมของสัญญา
2. การเปลี่ยนรหัสมาเกิล: นี่หมายถึงการสร้างมาสต์โดยใช้ tapscript โดยที่ทุกโหนดใบแทนเส้นทางการเปลี่ยนสถานะที่เป็นไปได้
3. การดำเนินการ merkleizing: การดำเนินการถูก merkleized ผ่านการสร้างความผูกมัดด้วยการสร้างสภาวะและกลไกท้าทายการฉ้อโกง สำหรับฟังก์ชันทางคณิตศาสตร์ใด ๆ ผู้เข้าร่วมสามารถคำนวณแบบหลีกเลี่ยงแล้วเผยแพร่การสร้างสภาวะ f(x)=y หากผู้เข้าร่วมอื่น ๆ พบผลลัพธ์ที่ไม่ถูกต้อง f(x)=z พวกเขาสามารถเริ่มต้นท้าทายได้ การอิทธิพลทางกฎหมายถูกดำเนินการผ่านการค้นหาทวิภาคภายใน คล้ายกับหลักการของ optimistic rollup

merkleizing การประหารชีวิต

เพื่อนำมาทำให้มัท, ภาษาสคริปต์บิทคอยน์ต้องมีความสามารถต่อไปนี้:

1. บังคับให้การแสดงผลมีสคริปต์ที่แน่นอน (และจำนวนเงินของพวกเขา)
2. แนบข้อมูลลงในเอาท์พุต
3. อ่านข้อมูลจากอินพุตปัจจุบัน (หรือจากอินพุตอื่น)

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

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

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

ในทางปฏิบัติ สิ่งเหล่านี้กำลังเกิดขึ้นอยู่แล้ว โจแฮน โทราส์ ฮัลเซธ ได้ใช้รหัส op_checkcontractverify จากข้อเสนอ soft fork ของแมตต์ให้เป็นการปฏิบัติelftrace, ซึ่งอนุญาตให้โปรแกรมใดก็ที่รองรับการคอมไพล์ risc-v ที่จะได้รับการตรวจสอบบนบล็อกเชนของบิทคอยน์ ทำให้ฝ่ายหนึ่งในโปรโตคอลสัญญาสามารถเข้าถึงเงินทุนผ่านการตรวจสอบสัญญา ซึ่งจะทำให้สามารถเชื่อมโยงการตรวจสอบที่เกี่ยวข้องกับบิทคอยน์

csfs (op_checksigfromstack)

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

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

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

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

CSFS สามารถใช้ opcodes เช่น CLTV, CSV, CTV, APO และอื่น ๆ ทําให้เป็น opcode วิปัสสนาที่หลากหลาย ดังนั้นจึงช่วยในการแก้ปัญหาความสามารถในการปรับขนาดสําหรับ Bitcoin Layer2 ข้อเสียคือต้องเพิ่มสําเนาที่สมบูรณ์ของธุรกรรมที่ลงนามบนสแต็กซึ่งอาจเพิ่มขนาดของธุรกรรมที่มีไว้สําหรับการวิปัสสนาโดยใช้ CSF อย่างมีนัยสําคัญ ในทางตรงกันข้าม opcodes วิปัสสนาวัตถุประสงค์เดียวเช่น CLTV และ CSV มีค่าโสหุ้ยน้อยที่สุด แต่การเพิ่ม opcode วิปัสสนาพิเศษใหม่แต่ละครั้งจําเป็นต้องมีการเปลี่ยนแปลงฉันทามติ

txhash (op_txhash)

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

เนื่องจากความคล้ายคลึงกันระหว่าง txhash และ ctv มีการพูดคุยอย่างมากในชุมชนเกี่ยวกับสองอย่าง

txhash สามารถถือเป็นการอัพเกรดสากลของ ctv ที่ให้แม่แบบธุรกรรมที่ทันสมัยกว่าที่อนุญาตให้ผู้ใช้ระบุส่วนของธุรกรรมการใช้จ่ายโดยชัดเจน แก้ไขปัญหาหลายอย่างที่เกี่ยวข้องกับค่าธรรมเนียมธุรกรรม ไม่เหมือน opcode covenant อื่น ๆ txhash ไม่ต้องการสำเนาข้อมูลที่จำเป็นในพยาน ลดความต้องการพื้นที่เก็บข้อมูลเพิ่มเติม; ไม่เหมือน ctv txhash ไม่สามารถทำงานร่วมกันกับ nop และสามารถนำมาใช้ได้เฉพาะใน tapscript; การผสมผสานของ txhash และ csfs สามารถเป็นทางเลือกแทน ctv และ apo ได้

จากมุมมองในการสร้างคำสัญญา txhash เป็นสิ่งที่มีประโยชน์มากกว่าในการสร้าง "คำสัญญาเพิ่มเติม" โดยที่ข้อมูลส่วนต่างๆ ของธุรกรรมที่คุณต้องการแก้ไขถูกดันเข้าสู่สแต็ก สะสมกันเข้าด้วยกัน และตรวจสอบว่าแฮชที่ได้จากการดันเข้าสู่สแต็กตรงกับค่าที่ตั้งไว้; ctv เหมาะกับการสร้าง "คำสัญญาลบ" โดยที่ข้อมูลส่วนต่างๆ ของธุรกรรมที่คุณต้องการเก็บไว้ฟรีถูกดันเข้าสู่สแต็ก จากนั้น โดยใช้คำสั่ง rolling sha256 opcode การเริ่มทำการแฮชจะเริ่มต้นจากสถานะระหว่างที่ตั้งไว้ที่คำนำหน้าของข้อมูลแฮชของธุรกรรม ส่วนที่เป็นฟรีจะถูกแฮชเข้ากับสถานะระหว่างนี้

ฟิลด์ txfieldselector ที่กำหนดไว้ในข้อกำหนด txhash คาดหวังว่าจะถูกขยายออกไปสู่ opcodes อื่น ๆ เช่น op_tx

bip ที่เกี่ยวข้องกับ txhash อยู่ในสถานะร่างบน github และยังไม่ได้รับหมายเลข

op_cat

op_cat เป็น opcode ที่ถูกปกคลุมด้วยความลึกลับ ตั้งแต่ต้นแรกถูก Satoshi Nakamoto ทิ้งเพราะปัญหาด้านความปลอดภัย อย่างไรก็ตาม เมื่อเร็ว ๆ นี้ op_cat ได้กระตุ้นการพูดคุยอย่างรุนแรงในหมู่นักพัฒนาบิตคอยน์และแม้แต่กระตุ้นวัฒนธรรมมีมในอินเทอร์เน็ต สุดท้าย op_cat ได้รับการอนุมัติภายใต้ bip-347 และถูกเรียกว่าเป็นข้อเสนอ bip ที่เป็นไปได้มากที่สุดในเวลาสุดท้าย

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

อันที่จริงความสามารถในการเชื่อมต่อสององค์ประกอบสอดคล้องกับโครงสร้างข้อมูลการเข้ารหัสที่มีประสิทธิภาพ: Merkle Trie ในการสร้าง Merkle Trie จําเป็นต้องมีการเรียงต่อกันและการแฮชเท่านั้นและฟังก์ชันการแฮชมีอยู่ในสคริปต์ bitcoin ดังนั้นด้วย op_cat ในทางทฤษฎีเราสามารถตรวจสอบหลักฐานของ Merkle ภายในสคริปต์ bitcoin ซึ่งเป็นหนึ่งในวิธีการตรวจสอบที่มีน้ําหนักเบาที่พบบ่อยที่สุดในเทคโนโลยีบล็อกเชน

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

ในลายเซ็น schnorr ข้อความที่ต้องการลงนามประกอบด้วยฟิลด์ต่อไปนี้:

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

สำหรับหลักการสามารถอ้างอิงได้จากบทความของแอนดรูว์ โพลสตรา "Cat and Schnorr Tricks" ที่เฉพาะเจาะจง

สรุปมาละ ความหลากหลายของ op_cat ทำให้มันสามารถจำลองโค้ด covenant ทุกประเภทเกือบทุกประเภท โค้ด covenant จำนวนมากพึ่งไปที่ฟังก์ชันของ op_cat ซึ่งเสริมสถานะของมันในรายการผสม ทฤษฎีทั้งหมดทำให้เรามีความหวังที่จะสร้าง btc zk rollup ที่มีความมั่นคงทาง trust ได้แค่พึ่งกับ op_cat และโค้ด bitcoin ที่มีอยู่ StarkNet, Chakra และพันธมิตรในระบบนี้กำลังทำให้เกิดเหตุการณ์นี้อย่างใจกล้า

สรุป

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

โดยไม่มีชั้นฐานที่ยืดหยุ่น จะเป็นไปไม่ได้ที่จะสร้างชั้นที่สองที่ยืดหยุ่นมากขึ้น

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

อย่างไรก็ตามลักษณะของการคํานวณบน bitcoin นั้นแตกต่างจาก Ethereum โดยพื้นฐาน Bitcoin รองรับเฉพาะ "การตรวจสอบ" เป็นรูปแบบหนึ่งของการคํานวณและไม่สามารถทําการคํานวณทั่วไปได้ในขณะที่ Ethereum เป็นการคํานวณโดยเนื้อแท้โดยการตรวจสอบเป็นผลพลอยได้จากการคํานวณ ความแตกต่างนี้เห็นได้ชัดจากจุดหนึ่ง: Ethereum เรียกเก็บค่าธรรมเนียมก๊าซสําหรับธุรกรรมที่ไม่สามารถดําเนินการได้ในขณะที่ Bitcoin ไม่ได้

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

APO, op_vault และ TLUV พึ่งพาการใช้งานโดยตรงและการเลือกแอปพลิเคชันเหล่านี้สามารถบรรลุการใช้งานเฉพาะในวิธีที่ถูกกว่าและมีประสิทธิภาพมากขึ้น ผู้ที่ชื่นชอบเครือข่ายสายฟ้าจะชอบ APO สําหรับการบรรลุ ln-symmetry; ผู้ที่ต้องการใช้ห้องนิรภัยจะได้รับบริการที่ดีที่สุดจาก op_vault สําหรับการสร้าง Coinpool TLUV ให้ความเป็นส่วนตัวและประสิทธิภาพมากขึ้น op_cat และ txhash มีความหลากหลายมากขึ้นโดยมีความน่าจะเป็นน้อยกว่าของช่องโหว่ด้านความปลอดภัยและสามารถใช้กรณีการใช้งานได้มากขึ้นเมื่อรวมกับ opcodes อื่น ๆ ซึ่งอาจมีค่าใช้จ่ายของความซับซ้อนของสคริปต์ CTV และ CSF ได้ปรับการประมวลผลบล็อกเชน โดย CTV ใช้เอาต์พุตที่ล่าช้าและ CSF ที่ใช้ลายเซ็นที่ล่าช้า Matt โดดเด่นด้วยกลยุทธ์ในการดําเนินการในแง่ดีและการพิสูจน์การฉ้อโกงโดยใช้โครงสร้างของ Merkle Trie เพื่อใช้สัญญาอัจฉริยะสากลแม้ว่าจะยังคงต้องใช้ opcodes ใหม่สําหรับความสามารถในการวิปัสสนา

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

ข้อความประกาศ:

1. บทความนี้ถูกนำเอามาจาก [ กระจก]. สิทธิ์การคัดลอกทั้งหมดเป็นของผู้เขียนต้นฉบับ [ ชักรา]. หากมีการคัดค้านการพิมพ์ซ้ํานี้โปรดติดต่อ เกตเรียนทีม และพวกเขาจะดำเนินการด้วยรวดเร็ว
2. คำประกาศความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงความคิดเห็นของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำเกี่ยวกับการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นๆ โดยทีมเรียนรู้ Gate.io นอกจากที่ได้กล่าวถึงไว้แล้ว การคัดลอก การแจกจ่าย หรือการลอกเลียนแบบบทความที่แปลแล้วถือเป็นการละเมิดกฎหมาย