1 บทนำ

สำหรับอัลกอริทึม f ผู้ร่วมมือที่ไม่เชื่อถือกันสองคน คือ Alice และ Bob สามารถสร้างความเชื่อถือได้ตามวิธีต่อไปนี้:

1. เมื่อ Alice ป้อน x เข้าสู่อัลกอริทึม f และได้ผลลัพธ์เป็น y โดย Bob ก็รันอัลกอริทึม f ด้วยข้อมูลนำเข้า x เดียวกัน และได้ผลลัพธ์เป็น y' หาก y = y' แล้ว Bob ยืนยันข้อมูลนำเข้า x และผลลัพธ์ y ที่ Alice ได้รับให้ นี่คือกลไกการพิสูจน์ความถูกต้องพิเศษที่ใช้ในการเชื่อมั่นบล็อกเชน โดยที่ Alice เป็นโหนดที่แพ็กเก็จบล็อกและ Bob เป็นโหนดที่มีส่วนร่วมในการเชื่อมั่น
2. อลิซป้อนข้อมูล x เรียกใช้โปรแกรม zk.prove บนอัลกอริทึม f และได้รับผลลัพธ์ y และพิสูจน์หลักฐาน บ๊อบรันโปรแกรม zk.verify ตาม f, y และหลักฐาน หากผลลัพธ์เป็นจริงบ๊อบก็ยอมรับผลลัพธ์ของอลิซ หากผลลัพธ์เป็นเท็จแสดงว่าบ๊อบไม่ยอมรับผลลัพธ์ของอลิซ นี่คือหลักฐานความถูกต้องซึ่ง Bob สามารถเป็นสัญญาแบบ on-chain ได้
3. อลิซป้อนข้อมูล x เรียกใช้อัลกอริทึม f และรับผลลัพธ์ y บ๊อบยังเรียกใช้อัลกอริทึม f ด้วยอินพุต x เดียวกันส่งผลให้ y′ ถ้า y = y′แสดงว่าไม่มีอะไรทํา ถ้า y ≠ y′ แล้ว Bob ท้าทาย Alice ด้วยโปรแกรมที่ท้าทายคือ f จํานวนการโต้ตอบระหว่างอลิซและบ๊อบอาจเป็นหนึ่งหรือหลาย อนุญาโตตุลาการทําได้ผ่านกระบวนการตอบสนองต่อความท้าทาย. นี่คือหลักฐานการทุจริตโดยที่บ๊อบเป็นผู้ท้าชิงฟังนอกสายโซ่และท้าทายบนโซ่
4. เอลิซป้อน x, รันโปรแกรม zk.prove บนอัลกอริทึม f, และได้ผลลัพธ์ y และพิสูจน์ proof บ็อบรันโปรแกรม zk.verify ขึ้นอยู่กับ f, y และ proof หากผลลัพธ์เป็นจริง จะไม่มีอะไรเกิดขึ้น; หากผลลัพธ์เป็นเท็จ บ็อบจะท้าทายอลิซ โดยโปรแกรมที่ถูกท้าทายคือ zk.verify จำนวนความประสงค์ระหว่างอลิซและบ็อบสามารถเป็นหนึ่งหรือหลายรอบ การอุทธรณ์ถูกบันทึกผ่านกระบวนการท้าทาย-ตอบโต้ นี่คือการพิสูจน์การฉ้อโกง ที่บ็อบเป็นผู้ท้าทาย ฟังเสียงออฟเชนและท้าทายออนเชน

สำหรับ 2, 3 และ 4 ดังกล่าว ให้ x เป็นธุรกรรม Layer2 และสถานะเริ่มต้น f เป็นโปรแกรมความเห็นชั้น Layer2 และ y เป็นสถานะสิ้นสุดของการทำธุรกรรมที่สอดคล้องกับการขยายมิติ Layer2 บนบล็อกเชน

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

ตาราง 1: วิธีการสร้างความเชื่อมั่น

นอกจากนี้ มีสิ่งที่สำคัญที่ต้องระบุ:

• ความสำคัญในการแยกแยะระหว่างการพิสูจน์การฉ้อโกงและการพิสูจน์ความถูกต้องไม่อยู่ที่ระบบพิสูจน์ ZK เช่น SNARK/STARK ที่ใช้ ระบบพิสูจน์ ZK แสดงถึงวิธีการที่ใช้ในการพิสูจน์ในขณะที่การฉ้อโกงหรือความถูกต้องแทนเนื้อหาที่ได้รับการพิสูจน์ นั่นเป็นเหตุผลที่ฉบับที่ 1 ในตารางที่ 1 ถูกกล่าวว่าเป็นการพิสูจน์ความถูกต้อง
• การพิสูจน์ความถูกต้องมีความคล่องตัวมากขึ้น แต่ความซับซ้อนในการตรวจสอบบนเชื่อมต่อเป็นสูงเมื่อเทียบกับการพิสูจน์การเจ้าหนี้ การพิสูจน์การฉ้อโกงมีความซับซ้อนในการตรวจสอบบนเชื่อมต่อที่ต่ำกว่า แต่ความคล่องตัวของมันสู้ไม่ได้
• สำหรับกรณี 2 และ 4 ในตาราง 1 โดยใช้เทคนิค ZK การวนซ้ำและการผสมกัน สามารถคำนวณ f หลายรายการและบีบอัดลดต้นทุนในการตรวจสอบของการคำนวณนอกเชือบบนเชน

ปัจจุบันได้รับประโยชน์จากสัญญาอัจฉริยะที่สมบูรณ์ของ Turing ของ Solidity การพิสูจน์การฉ้อโกงและเทคโนโลยีการพิสูจน์ความถูกต้องถูกนํามาใช้กันอย่างแพร่หลายในการปรับขนาด Ethereum Layer2 อย่างไรก็ตามภายใต้กระบวนทัศน์ Bitcoin ซึ่งถูก จํากัด โดยฟังก์ชัน opcode ที่ จํากัด ของ Bitcoin องค์ประกอบสแต็ค 1000 และข้อ จํากัด อื่น ๆ การประยุกต์ใช้เทคโนโลยีเหล่านี้ยังอยู่ในขั้นตอนการสํารวจ บทความนี้สรุปข้อ จํากัด และเทคโนโลยีที่ก้าวหน้าภายใต้กระบวนทัศน์ Bitcoin ในบริบทของการปรับขนาด Bitcoin Layer2 ศึกษาการพิสูจน์ความถูกต้องและเทคโนโลยีการพิสูจน์การฉ้อโกงและสรุปเทคโนโลยีการแบ่งส่วนสคริปต์ที่เป็นเอกลักษณ์ภายใต้กระบวนทัศน์ Bitcoin

2 ข้อจำกัดและการ突破ในระบบบิทคอยน์

มีข้อ จํากัด มากมายภายใต้กระบวนทัศน์ Bitcoin แต่สามารถใช้วิธีการหรือเทคนิคที่ชาญฉลาดต่างๆเพื่อเอาชนะข้อ จํากัด เหล่านี้ได้ ตัวอย่างเช่นความมุ่งมั่นของบิตสามารถทะลุผ่านข้อ จํากัด แบบไร้สถานะ UTXO, taproot สามารถทําลายข้อ จํากัด ของพื้นที่สคริปต์เอาต์พุตตัวเชื่อมต่อสามารถทําลายข้อ จํากัด ของวิธีการใช้จ่าย UTXO และสัญญาสามารถทําลายข้อ จํากัด ก่อนลายเซ็นได้

2.1 โมเดล UTXO และ ข้อ จำกัด ของสคริปต์

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

1. สคริปต์ Bitcoin เป็นรูปแบบที่ไม่มีสถานะ;
2. สำหรับประเภทเอาท์พุต P2TR จำนวนสูงสุดของออปโค้ดที่สามารถรับได้ในธุรกรรมเดียวคือประมาณ 4 ล้าน ซึ่งเต็มบล็อกทั้งหมด ในขณะที่สำหรับประเภทเอาท์พุตอื่น ๆ มีออปโค้ดเพียง 10,000 คำสั่งเท่านั้น;
3. วิธีการใช้จ่ายของ UTXO เดี่ยว ถูกจำกัด โดยขาดความสนใจในการใช้วิธีการจ่ายร่วมกัน;
4. ไม่รองรับฟังก์ชั่นสัญญาที่ยืดหยุ่น;
5. ขนาดของสแต็กถูกจำกัดไว้ที่สูงสุด 1000 องค์ประกอบ (altstack + stack) และขนาดสูงสุดขององค์ประกอบเดียวคือ 520 ไบต์
6. การดำเนินการทางคณิตศาสตร์ (เช่น การบวก และ การลบ) ถูกจำกัดไว้ที่องค์ประกอบ 4 ไบต์ พวกเขาไม่สามารถถูกแก้ไขเป็นองค์ประกอบที่ยาวยิ่งเช่น 20 ไบต์หรือขนาดที่ใหญ่กว่า ซึ่งจำเป็นสำหรับการดำเนินการทางกลศาสตร์;
7. คำสั่งเช่น OPMUL และ OPCAT ถูกปิดใช้งานแล้ว และการจำลองด้วยคำสั่งที่มีอยู่มีค่าใช้จ่ายสูงมาก เช่นการจำลองการแฮช BLAKE3 รอบเดียว ด้วยขนาดสคริปต์ประมาณ 75K

2.2 Bit Commitment: Breaking Through the UTXO Stateless Limitation

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

หลักการของการสมัครสมาชิกบิตคอยน์ค่อนข้างเรียบง่าย บิตหมายถึงการตั้งค่าค่าแฮชสองค่าที่แตกต่างกัน หรือ hash0 และ hash1 สำหรับแต่ละบิตในข้อความที่ต้องการลงลายมือ หากค่าบิตที่ต้องการลงลายมือเป็น 0 จะเปิดเผย preimage0 ของ hash0 หากค่าบิตที่ต้องการลงลายมือเป็น 1 จะเปิดเผย preimage1 ของ hash1

ยกตัวอย่างข้อความบิตเดียว m ∈{0,1} สคริปต์ปลดล็อกความมุ่งมั่นของบิตที่สอดคล้องกันเป็นเพียงภาพเบื้องต้นบางส่วน: หากค่าบิตเป็น 0 สคริปต์ปลดล็อคที่เกี่ยวข้องคือ preimage0—"0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140"; ถ้าค่าบิตเป็น 1 สคริปต์ปลดล็อคที่เกี่ยวข้องคือ preimage1—"0x47c31e611a3bd2f3a7a42207613046703fa27496" ดังนั้นด้วยความมุ่งมั่นเล็กน้อยจึงเป็นไปได้ที่จะทําลายข้อ จํากัด แบบไร้สัญชาติของ UTXO และบรรลุสคริปต์ Bitcoin ที่มีสถานะทําให้คุณสมบัติใหม่ที่น่าสนใจต่างๆเป็นไปได้

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // นี่คือ hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // นี่คือ hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// ตอนนี้ค่าการคาดการณ์บิตอยู่บนสแต็ก จะเป็น '0' หรือ '1'

ปัจจุบันมีการนำไปใช้งานอยู่ 2 รูปแบบของการตั้งค่าบิทคอยน์:

• ลามพอร์ตวงจรลับเวลา: หลักการเป็นไปได้อย่างง่ายดายและต้องใช้ฟังก์ชันแฮชเท่านั้นซึ่งทำให้เหมาะกับบิตคอยน์ สำหรับทุกบิตในข้อความจำเป็นต้องสร้างค่าแฮชสองค่าซึ่งจะทำให้ข้อมูลลายเซ็นที่ใหญ่มาก กล่าวอีกนัยหนึ่งสำหรับข้อความที่มีความยาว v บิต ความยาวของกุญแจสาธารณะคือ 2v บิตและความยาวของลายเซ็นต์คือ v บิต
• Winternitz One-Time Signature: เมื่อเทียบกับลายเซ็น Lamport จะช่วยลดความยาวของลายเซ็นและคีย์สาธารณะได้อย่างมาก แต่เพิ่มความซับซ้อนในการลงนามและการตรวจสอบ โครงร่างนี้ช่วยให้สามารถตั้งค่าความยาวของแฮชเชนที่แตกต่างกัน d ได้อย่างยืดหยุ่น จึงสร้างสมดุลระหว่างความยาวและความซับซ้อน ตัวอย่างเช่น การตั้งค่า d = 15 ส่งผลให้ทั้งความยาวคีย์สาธารณะและความยาวลายเซ็นสั้นลงประมาณ 4 เท่า แต่ความซับซ้อนในการตรวจสอบจะเพิ่มขึ้น 4 เท่า นี่เป็นการแลกเปลี่ยนระหว่างพื้นที่สแต็คของ Bitcoin และขนาดสคริปต์ ลายเซ็น Lamport สามารถเห็นได้ว่าเป็นกรณีพิเศษของลายเซ็น Winternitz เมื่อ d = 1

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

2.3 Taproot: การทะลุขีดจำกัดพื้นที่สคริปต์

การอัปเกรดซอฟต์ฟอร์ก Bitcoin Taproot ที่เริ่มใช้งานในเดือนพฤศจิกายน พ.ศ. 2021 ประกอบด้วยข้อเสนอสามข้อ: ลายเซ็น Schnorr (BIP 340), Taproot (BIP 341) และ TapScript (BIP 342) มันทำให้มีชนิดธุรกรรมใหม่ - ธุรกรรม Pay-to-Taproot (P2TR) ธุรกรรม P2TR สามารถสร้างรูปแบบธุรกรรมที่เป็นส่วนตัวมากขึ้น ยืดหยุ่น และมีขนาดใหญ่ขึ้นโดยการรวมความสามารถของ Taproot, MAST (Merkel Abstract Syntax Tree) และลายเซ็น Schnorr

P2TR รองรับวิธีการใช้จ่ายสองวิธี: การใช้จ่ายตามเส้นทางคีย์หรือเส้นทางสคริปต์

ตามข้อกําหนดใน Taproot (BIP 341) เมื่อใช้จ่ายผ่านเส้นทางสคริปต์เส้นทาง Merkle ที่สอดคล้องกันต้องไม่เกินความยาวสูงสุด 128 ซึ่งหมายความว่าจํานวน tapleafs ใน taptree ต้องไม่เกิน 2 ^ 128 นับตั้งแต่การอัพเกรด SegWit ในปี 2017 เครือข่าย Bitcoin จะวัดขนาดบล็อกในหน่วยน้ําหนักโดยรองรับน้ําหนักสูงสุด 4 ล้านหน่วย (ประมาณ 4MB) เมื่อใช้เอาต์พุต P2TR ผ่านเส้นทางสคริปต์ จะต้องเปิดเผยสคริปต์ tapleaf เดียวซึ่งหมายความว่าบล็อกนั้นเต็มไปด้วยสคริปต์ tapleaf เดียว นี่หมายความว่าสําหรับธุรกรรม P2TR ขนาดสคริปต์ที่สอดคล้องกับแต่ละ tapleaf สามารถสูงสุดประมาณ 4MB อย่างไรก็ตามภายใต้นโยบายเริ่มต้นของ Bitcoin โหนดจํานวนมากส่งต่อธุรกรรมที่มีขนาดเล็กกว่า 400K เท่านั้น ธุรกรรมขนาดใหญ่จําเป็นต้องร่วมมือกับนักขุดเพื่อบรรจุ

พรีเมี่ยมพื้นที่สคริปต์ที่นําโดย Taproot ทําให้มีค่ามากขึ้นในการจําลองการดําเนินการเข้ารหัสเช่นการคูณและการแฮชโดยใช้ opcodes ที่มีอยู่

เมื่อสร้างการคํานวณที่ตรวจสอบได้ตาม P2TR ขนาดสคริปต์ที่สอดคล้องกันจะไม่ จํากัด อยู่ที่ข้อ จํากัด 4MB อีกต่อไป แต่สามารถแบ่งออกเป็นฟังก์ชันย่อยหลายฟังก์ชันที่กระจายอยู่ใน tapleafs หลายตัวจึงทําลายข้อ จํากัด พื้นที่สคริปต์ 4MB ในความเป็นจริงอัลกอริธึมตรวจสอบ Groth16 ที่ใช้ใน BitVM2 ปัจจุบันมีขนาดสูงสุด 2GB อย่างไรก็ตามสามารถแยกและกระจายไปทั่ว tapleafs ประมาณ 1,000 รายการและเมื่อรวมเข้ากับความมุ่งมั่นของบิตความสอดคล้องระหว่างอินพุตและเอาต์พุตของแต่ละฟังก์ชันย่อยสามารถถูก จํากัด ได้ทําให้มั่นใจได้ถึงความสมบูรณ์และความถูกต้องของการคํานวณทั้งหมด

2.4 ผลลัพธ์ของตัวเชื่อมต่อ: รุนแรงล้างผ่านข้อ จำกัด วิธีการใช้จ่าย UTXO

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

อย่างไรก็ตาม Burak ผู้ก่อตั้งโปรโตคอล Ark ใช้ธง SIGHASH อย่างชาญฉลาดเพื่อให้ได้เอาต์พุตตัวเชื่อมต่อ โดยเฉพาะอลิซสามารถสร้างลายเซ็นเพื่อส่ง BTC ของเธอไปให้บ๊อบได้ อย่างไรก็ตามเนื่องจากลายเซ็นสามารถยอมรับอินพุตได้หลายตัวอลิซจึงสามารถตั้งค่าลายเซ็นของเธอให้เป็นเงื่อนไข: ลายเซ็นนั้นใช้ได้สําหรับธุรกรรม Taketx หากและเฉพาะในกรณีที่ธุรกรรมนั้นใช้อินพุตที่สอง อินพุตที่สองเรียกว่าตัวเชื่อมต่อซึ่งเชื่อมโยง UTXO A และ UTXO B กล่าวอีกนัยหนึ่งธุรกรรม Taketx จะใช้ได้หาก Challengetx ไม่ได้ใช้ UTXO B เท่านั้น ดังนั้นโดยการทําลายเอาต์พุตตัวเชื่อมต่อประสิทธิภาพของธุรกรรม Taketx สามารถถูกบล็อกได้

รูปที่ 1: ภาพตัวอย่างการเชื่อมต่อของคอนเนกเตอร์

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

2.5 สัญญา: การทะเลาะกับข้อจำกัดในการเซ็นต์ล่วงหน้า

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

การปรับใช้สัญญาปัจจุบันสามารถแบ่งออกเป็นสองหมวดหมู่ได้:

• การลงนามล่วงหน้า: ตามความสามารถของสคริปต์ Bitcoin ที่มีอยู่สัญญาที่กําหนดไว้ล่วงหน้าที่มีฟังก์ชันจํากัดจะถูกสร้างขึ้นผ่านการลงนามล่วงหน้า ซึ่งหมายถึงการออกแบบและลงนามในธุรกรรมในอนาคตที่เป็นไปได้ทั้งหมดล่วงหน้าล็อคผู้เข้าร่วมไว้ในคีย์ส่วนตัวและอัตราค่าธรรมเนียมเฉพาะ บางโครงการยังกําหนดให้ผู้เข้าร่วมต้องสร้างคีย์ส่วนตัวระยะสั้นสําหรับธุรกรรมที่ลงนามล่วงหน้าทั้งหมด เมื่อการลงนามล่วงหน้าเสร็จสมบูรณ์คีย์ส่วนตัวระยะสั้นเหล่านี้จะถูกลบอย่างปลอดภัยเพื่อป้องกันไม่ให้ผู้โจมตีได้รับและขโมยเงิน อย่างไรก็ตามทุกครั้งที่มีการเพิ่มผู้เข้าร่วมใหม่หรือมีการอัปเดตการดําเนินการกระบวนการข้างต้นจะต้องทําซ้ําซึ่งนําไปสู่ค่าบํารุงรักษาที่สูง ตัวอย่างเช่น Lightning Network บรรลุสัญญาสองฝ่ายผ่านการลงนามล่วงหน้าและใช้เทคโนโลยี Hash Time-Locked Contracts (HTLC) เพื่อใช้ฟังก์ชันการกําหนดเส้นทางสําหรับสัญญาสองฝ่ายหลายสัญญา จึงบรรลุกลยุทธ์การปรับขนาดที่ลดความน่าเชื่อถือ อย่างไรก็ตามเครือข่าย Lightning ต้องการการลงนามล่วงหน้าหลายธุรกรรมและ จํากัด เพียงสองฝ่ายทําให้ค่อนข้างยุ่งยาก ใน BitVM1 ธุรกรรมหลายร้อยรายการจะต้องลงนามล่วงหน้าในการเริ่มต้นแต่ละครั้งในขณะที่ใน BitVM2 ที่ปรับให้เหมาะสมจํานวนธุรกรรมที่ต้องลงนามล่วงหน้าในการเริ่มต้นแต่ละครั้งก็ถึงหลายสิบรายการ ทั้งใน BitVM1 และ BitVM2 เฉพาะผู้ให้บริการที่เข้าร่วมในการลงนามล่วงหน้าเท่านั้นที่มีสิทธิ์ได้รับการชําระเงินคืน หากผู้เข้าร่วม n มีส่วนร่วมในการลงนามล่วงหน้าและผู้เข้าร่วมแต่ละคนจําเป็นต้องลงนามในธุรกรรม m ล่วงหน้าความซับซ้อนในการลงนามล่วงหน้าสําหรับผู้เข้าร่วมแต่ละคนจะเป็น n * m
• การแนะนํา Contract Opcodes: การแนะนํา opcodes ฟังก์ชันสัญญาใหม่สามารถลดความซับซ้อนในการสื่อสารและค่าใช้จ่ายในการบํารุงรักษาระหว่างผู้เข้าร่วมสัญญาได้อย่างมากดังนั้นจึงแนะนําวิธีการใช้งานสัญญาที่ยืดหยุ่นมากขึ้นสําหรับ Bitcoin ตัวอย่างเช่น OPCAT: ใช้เพื่อเชื่อมต่อสตริงไบต์ แม้ว่าฟังก์ชั่นจะง่ายมาก แต่ก็มีประสิทธิภาพมากและสามารถลดความซับซ้อนของ BitVM ได้อย่างมาก OPTXHASH: ช่วยให้สามารถควบคุมการกระทําภายในสัญญาได้ดีขึ้น หากใช้ใน BitVM จะสามารถรองรับตัวดําเนินการชุดใหญ่ได้ซึ่งจะช่วยปรับปรุงสมมติฐานด้านความปลอดภัยของ BitVM และลดความน่าเชื่อถือได้อย่างมาก นอกจากนี้วิธีการลงนามล่วงหน้าโดยเนื้อแท้หมายความว่าผู้ประกอบการใน BitVM สามารถใช้กระบวนการชําระเงินคืนเท่านั้นซึ่งนําไปสู่ประสิทธิภาพการใช้เงินทุนที่ลดลง ในขณะที่ผ่าน opcodes สัญญาใหม่อาจเป็นไปได้ที่จะจ่ายโดยตรงจากกลุ่มกองทุน peg-in ให้กับผู้ใช้ผลผลิตซึ่งจะช่วยปรับปรุงประสิทธิภาพของเงินทุนต่อไป ดังนั้นรูปแบบสัญญาที่ยืดหยุ่นจะทําลายข้อ จํากัด การลงนามล่วงหน้าแบบเดิมได้อย่างมีประสิทธิภาพ

3 บิทคอยน์ Layer2 Scaling: Validity Proofs และ Fraud Proofs

ทั้งหลักฐานความถูกต้องและหลักฐานการฉ้อโกงสามารถใช้สําหรับการปรับขนาด Bitcoin L2 โดยมีความแตกต่างที่สําคัญแสดงในตารางที่ 2

ตาราง 2: การพิสูจน์ความถูกต้อง vs การพิสูจน์การฉ้อโกง

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

ตามจํานวนการโต้ตอบที่ท้าทายระหว่างอลิซและบ๊อบหลักฐานการฉ้อโกงสามารถแบ่งออกเป็นหลักฐานการฉ้อโกงรอบเดียวและหลักฐานการฉ้อโกงหลายรอบดังแสดงในรูปที่ 2

รูปที่ 2: พิสูจน์การฉ้อโกงแบบเดียวกับพิสูจน์การฉ้อโกงหลายรอบ

ดังที่แสดงในตารางที่ 3 หลักฐานการทุจริตสามารถดําเนินการผ่านรูปแบบการโต้ตอบที่แตกต่างกันรวมถึงรูปแบบการโต้ตอบแบบรอบเดียวและรูปแบบการโต้ตอบหลายรอบ

ตาราง 3: ปฏิสัมพันธ์หนึ่งรอบ ปะทะ แบบหลายรอบ

ในแบบจำลองการปรับขนาด Layer2 ของ Bitcoin BitVM1 ใช้กลไกยืนยันการฉ้อโกงหลายรอบในขณะที่ BitVM2 ใช้กลไกยืนยันการฉ้อโกงในรอบเดียว และ bitcoin-circle stark ใช้การพิสูจน์ความถูกต้อง ในนี้ BitVM1 และ BitVM2 สามารถนำมาใช้ได้โดยไม่ต้องทำการปรับเปลี่ยนใด ๆ ในโปรโตคอล Bitcoin ในขณะที่ bitcoin-circle stark ต้องการแนะนำ opcode ใหม่ OP_CAT

สําหรับงานคํานวณส่วนใหญ่ Signet, testnet และ mainnet ของ Bitcoin ไม่สามารถแสดงสคริปต์ขนาด 4MB ได้อย่างสมบูรณ์ซึ่งจําเป็นต้องใช้เทคโนโลยีการแยกสคริปต์นั่นคือการแยกสคริปต์การคํานวณทั้งหมดออกเป็นชิ้นเล็กกว่า 4MB กระจายไปทั่ว tapleafs ต่างๆ

3.1 พิสูจน์การทุจริตหลายรอบบนบิทคอยน์

ดังที่แสดงในตารางที่ 3 หลักฐานการทุจริตหลายรอบเหมาะสําหรับสถานการณ์ที่มีความปรารถนาที่จะลดการคํานวณอนุญาโตตุลาการแบบ on-chain และ/หรือในกรณีที่ไม่สามารถระบุส่วนการคํานวณที่มีปัญหาได้ในขั้นตอนเดียว หลักฐานการทุจริตหลายรอบตามชื่อที่แนะนําต้องมีการโต้ตอบหลายรอบระหว่างผู้พิสูจน์และผู้ตรวจสอบเพื่อค้นหาส่วนการคํานวณที่มีปัญหาตามด้วยอนุญาโตตุลาการตามส่วนที่ระบุ

เอกสารไวท์เปเปอร์ BitVM รุ่นแรกของ Robin Linus (โดยทั่วไปเรียกว่า BitVM1) ใช้หลักฐานการฉ้อโกงหลายรอบ สมมติว่าแต่ละช่วงเวลาการท้าทายใช้เวลาหนึ่งสัปดาห์และใช้วิธีการค้นหาแบบไบนารีเพื่อค้นหาส่วนการคํานวณที่มีปัญหาระยะเวลาตอบสนองความท้าทายแบบ on-chain สําหรับ Groth16 Verifier อาจขยายได้ถึง 30 สัปดาห์ส่งผลให้ทันเวลาไม่ดี แม้ว่าปัจจุบันจะมีทีมวิจัยวิธีการค้นหา n-ary ที่มีประสิทธิภาพมากกว่าการค้นหาแบบไบนารี แต่ความตรงต่อเวลาของพวกเขายังคงต่ํากว่าอย่างมีนัยสําคัญเมื่อเทียบกับรอบ 2 สัปดาห์ในการพิสูจน์การฉ้อโกงรอบเดียว

ในปัจจุบัน multi-round fraud proofs ใน Bitcoin paradigm ใช้การท้าทายที่ได้รับอนุญาตในขณะที่ one-round fraud proofs ได้บรรลุวิธีการท้าทายที่ได้รับอนุญาตลดความเสี่ยงของการกล่าวหาระหว่างผู้เข้าร่วมและเพิ่มความปลอดภัย ในที่สุด Robin Linus ใช้ข้อได้เปรียบของ Taproot ให้เต็มที่เพื่อปรับปรุง BitVM1 ไม่เพียงทำให้จำนวนรอบการโต้ตอบลดลงเหลือแค่หนึ่งรอบ แต่วิธีการท้าทายยังถูกขยายไปสู่การเข้าถึงที่ได้รับอนุญาต แม้ว่าจะมีค่าคอมพิวเตชันการตัดสินในเครือข่ายเพิ่มขึ้น

3.2 พิสูจน์การโกงรอบเดียวบนบิตคอยน์

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

รูปที่ 3: การพิสูจน์ฉ้อโกงในรอบเดียว

ในวันที่ 15 สิงหาคม 2024 Robin Linus ได้เผยแพร่ BitVM2: Bridging Bitcoin to Second Layers กระดาษขาวทางเทคนิค ซึ่งนำมาใช้สร้างสะพาน跨เชนโยงโดยใช้เมธอดการพิสูจน์ปลอมโดยใช้รอบเดียวที่คล้ายกับที่แสดงในภาพที่ 3

3.3 การพิสูจน์ความถูกต้องบนบิตคอยน์ด้วย OP_CAT

OPCAT เป็นส่วนหนึ่งของภาษาสคริปต์ต้นฉบับเมื่อ Bitcoin ถูกเปิดตัว แต่ถูกปิดใช้งานในปี 2010 เนื่องจากช่องโหว่ด้านความปลอดภัย อย่างไรก็ตาม ชุมชน Bitcoin ได้พูดคุยกันเกี่ยวกับการเปิดใช้งานใหม่มาหลายปี ตอนนี้ OPCAT ได้รับหมายเลข 347 และได้เปิดใช้งานบน signet ของ Bitcoin แล้ว

ฟังก์ชันหลักของ OP_CAT คือการรวมสององค์ประกอบในสแต็กและผลักดันผลลัพธ์ที่ผสมกลับเข้าสู่สแต็ก ฟังก์ชันนี้เปิดโอกาสให้สัญญาและ STARK Verifiers บน Bitcoin ได้

• สัญญา: Andrew Poelstra เสนอ CAT และ Schnorr Tricks I โดยใช้เทคนิค OPCAT และ Schnorr เพื่อใช้สัญญากับ Bitcoin อัลกอริทึม Schnorr เป็นลายเซ็นดิจิทัลสําหรับประเภทเอาต์พุต P2TR สําหรับประเภทเอาต์พุตอื่น ๆ สามารถใช้เทคนิค ECDSA ที่คล้ายกันดังที่เห็นในพันธสัญญากับ CAT และ ECDSA ด้วยความช่วยเหลือของสัญญา OPCAT อัลกอริทึม STARK Verifier สามารถแบ่งออกเป็นหลายธุรกรรมค่อยๆตรวจสอบหลักฐาน STARK ทั้งหมด
• ตัวตรวจสอบ STARK: ตัวตรวจสอบ STARK มีหน้าที่เชื่อมต่อข้อมูลที่เกี่ยวข้องกันและทำการแฮช เป็นการดำเนินการ Bitcoin script แบบธรรมชาติที่สามารถประหยัดเวลาได้มาก ตัวอย่างเช่น OPSHA256 เป็นคำสั่งเดียวในรูปแบบธรรมชาติของมัน ในขณะที่รูปแบบจำลองต้องใช้ร้อยละหนึ่งของ K คำสั่ง การดำเนินการแฮชหลักใน STARK นั้นเกี่ยวข้องกับการตรวจสอบเส้นทาง Merkle และการแปลง Fiat-Shamir ดังนั้น OPCAT เป็นมิตรมากกับอัลกอริทึมตรวจสอบ STARK

เทคโนโลยีการแยกสคริปต์บิทคอยน์ 3.4

แม้ว่าโหลดการคํานวณที่จําเป็นในการเรียกใช้อัลกอริธึมตัวตรวจสอบที่เกี่ยวข้องเพื่อตรวจสอบการพิสูจน์หลังจากหลักฐาน SNARK / STARK มีขนาดเล็กกว่าที่จําเป็นในการเรียกใช้การคํานวณดั้งเดิมโดยตรง f แต่จํานวนสคริปต์ที่จําเป็นเมื่อแปลงเพื่อใช้อัลกอริทึมผู้ตรวจสอบในสคริปต์ Bitcoin ยังคงมหาศาล ปัจจุบันตาม opcodes Bitcoin ที่มีอยู่ขนาดสคริปต์ตรวจสอบ Groth16 ที่ปรับให้เหมาะสมและขนาดสคริปต์ Fflonk verifier ยังคงมากกว่า 2GB อย่างไรก็ตามขนาดของบล็อก Bitcoin เดียวมีเพียง 4MB ทําให้ไม่สามารถเรียกใช้สคริปต์ตรวจสอบทั้งหมดภายในบล็อกเดียว อย่างไรก็ตามตั้งแต่การอัปเกรด Taproot Bitcoin รองรับการดําเนินการสคริปต์โดย tapleaf ทําให้สคริปต์ตรวจสอบสามารถแบ่งออกเป็นหลายชิ้นโดยแต่ละชิ้นทําหน้าที่เป็น tapleaf เพื่อสร้าง taptree ความสอดคล้องของค่าระหว่างชิ้นสามารถมั่นใจได้ผ่านความมุ่งมั่นเล็กน้อย

ในขณะที่มีสัญญา OP_CAT อยู่ ตัวตรวจสอบ STARK สามารถแบ่งเป็นธุรกรรมมาตรฐานหลายอย่างที่เล็กกว่า 400KB อนุญาตให้การตรวจสอบความถูกต้องของ STARK ทั้งหมดเสร็จสมบูรณ์โดยไม่จำเป็นต้องร่วมมือกับนักขุด

ส่วนนี้เน้นทางเทคโนโลยีการแบ่งแยกที่เกี่ยวข้องของสคริปต์บิทคอยน์ภายใต้เงื่อนไขที่มีอยู่โดยไม่มีการนำเสนอหรือเปิดใช้งานโคดด้านใหม่ใด ๆ

เมื่อทำการแยกสคริปต์ ต้องมีการดูแลมิติชนิดต่าง ๆ ของข้อมูลต่อไปนี้ให้สมดุล:

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

ปัจจุบันวิธีการแยกสคริปต์สามารถแบ่งออกเป็นสามประเภทหลักดังต่อไปนี้:

• การแยกอัตโนมัติ: วิธีนี้แสวงหาวิธีการแยกที่ขนาดสคริปต์อยู่ที่ประมาณ 3MB และขนาดสแต็คจะลดลงตามขนาดสแต็คและขนาดสคริปต์ ข้อดีของวิธีนี้คือเป็นอิสระจากอัลกอริธึมการตรวจสอบเฉพาะและสามารถขยายไปยังการแยกสคริปต์สําหรับการคํานวณใด ๆ ข้อเสียคือ: (1) ต้องทําเครื่องหมายบล็อกลอจิคัลทั้งหมดแยกกัน เช่น บล็อกโค้ด OP_IF ที่ไม่สามารถแยกได้ มิฉะนั้นผลการดําเนินการของสคริปต์แยกจะไม่ถูกต้อง (2) ผลการดําเนินการของชิ้นอาจสอดคล้องกับองค์ประกอบหลายอย่างบนสแต็คซึ่งต้องมีการทําเครื่องหมายจํานวนองค์ประกอบสแต็คที่ต้องใช้ความมุ่งมั่นของบิตตามตรรกะการคํานวณจริง (3) ความสามารถในการอ่านฟังก์ชันเชิงตรรกะที่ดําเนินการโดยสคริปต์แต่ละชิ้นไม่ดีทําให้การตรวจสอบทําได้ยาก (4) สแต็คอาจมีองค์ประกอบที่ไม่จําเป็นสําหรับชิ้นถัดไปทําให้เสียพื้นที่สแต็ค
• การแยกฟังก์ชัน: วิธีนี้แยกตามฟังก์ชันย่อยต่างๆ ในการคํานวณ โดยมีค่าอินพุตและเอาต์พุตที่ชัดเจนสําหรับฟังก์ชันย่อย ในขณะที่แยกสคริปต์มันยังใช้สคริปต์ความมุ่งมั่นบิตที่จําเป็นสําหรับแต่ละชิ้นเพื่อให้แน่ใจว่าขนาดสคริปต์ทั้งหมดของชิ้นสุดท้ายน้อยกว่า 4MB และขนาดสแต็คน้อยกว่า 1000 ข้อดีคือ: ฟังก์ชั่นที่ชัดเจนตรรกะที่ชัดเจนสําหรับแต่ละชิ้นการอ่านที่ดีและความสะดวกในการตรวจสอบ ข้อเสียคือ: นิพจน์ของตรรกะการคํานวณดั้งเดิมอาจไม่ตรงกับตรรกะระดับสคริปต์ และฟังก์ชันย่อยการคํานวณดั้งเดิมอาจเหมาะสมที่สุด แต่ไม่ได้แสดงถึงความเหมาะสมระดับสคริปต์
• การแยกด้วยตนเอง: ในวิธีนี้จุดแยกไม่ได้ขึ้นอยู่กับฟังก์ชันย่อยที่ใช้งานได้ แต่ตั้งค่าด้วยตนเอง เหมาะอย่างยิ่งสําหรับกรณีที่มีขนาดฟังก์ชันย่อยเดียวเกิน 4MB ข้อดีคือ: ช่วยให้สามารถแยกฟังก์ชันย่อยขนาดสคริปต์หนักได้ด้วยตนเองเช่นฟังก์ชันที่เกี่ยวข้องกับการคํานวณ Fq12 ตรรกะที่ชัดเจนสําหรับแต่ละชิ้นอ่านได้ดีและง่ายต่อการตรวจสอบ ข้อเสียคือ: ถูก จํากัด ด้วยความสามารถในการปรับแต่งด้วยตนเองเมื่อสคริปต์โดยรวมได้รับการปรับให้เหมาะสมจุดแยกด้วยตนเองที่ตั้งไว้ก่อนหน้านี้อาจไม่เหมาะสมและจําเป็นต้องปรับใหม่

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

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

• ค้นหาอัลกอริทึมที่ปรับปรุงความใกล้ชิดของหน่วยความจำ แม้ว่าจะเสียค่าโคมพิวเตอร์บางส่วน ในการลดจำนวนบิตข้อมูลนำเข้า / ออกจากชิ้น โดยลดจำนวนของข้อมูลที่ต้องใช้สำหรับการยืนยันในการออกแบบธุรกรรม assertTx ของ BitVM2
• ใช้คุณสมบัติของการสลับกันของการดำเนินการที่เกี่ยวข้อง (เช่น การดำเนินการตรรกะ) เช่น x&y = y&x เพื่อประหยัดส่วนใหญ่ของตารางค้นหา
• ปัจจุบัน, ขนาดสคริปต์ที่สอดคล้องกับการดำเนินการ Fq12 มีขนาดใหญ่; พิจารณาการใช้เทคนิค Fiat-Shamir, Schwartz-Zipple, และ polynomial commitment schemes เพื่อลดความซับซ้อนในการคำนวณของการขยาย Fq12 อย่างมาก

4 สรุป

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

ข้อความประกันความเสียหาย:

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