BTC
ETH
HTX
SOL
BNB
ดูตลาด
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

การวิเคราะห์หลักการ BitVM และข้อควรพิจารณาในการเพิ่มประสิทธิภาพ

星球君的朋友们
Odaily资深作者
2024-03-26 02:53
บทความนี้มีประมาณ 5396 คำ การอ่านทั้งหมดใช้เวลาประมาณ 8 นาที
การสำรวจเทคโนโลยี BitVM เพิ่งเริ่มต้นขึ้น ในอนาคต จะมีการสำรวจและดำเนินการทิศทางการเพิ่มประสิทธิภาพเพิ่มเติมเพื่อให้บรรลุการขยายตัวของ Bitcoin และทำให้ระบบนิเวศของ Bitcoin เจริญรุ่งเรือง
สรุปโดย AI
ขยาย
การสำรวจเทคโนโลยี BitVM เพิ่งเริ่มต้นขึ้น ในอนาคต จะมีการสำรวจและดำเนินการทิศทางการเพิ่มประสิทธิภาพเพิ่มเติมเพื่อให้บรรลุการขยายตัวของ Bitcoin และทำให้ระบบนิเวศของ Bitcoin เจริญรุ่งเรือง

แหล่งที่มาดั้งเดิม: กลุ่มวิจัย Bitlayer

ผู้เขียนต้นฉบับ: ลินเดลล์, มิวทูเรนด์

1. บทนำ

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

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

ในเดือนธันวาคม 2023 Robin Linus หัวหน้าโครงการ ZeroSync เผยแพร่บทความชื่อ BitVM:Compute Anything On Bitcoin“เอกสารไวท์เปเปอร์ได้กระตุ้นให้ทุกคนมีความคิดในการปรับปรุงความสามารถในการตั้งโปรแกรมของ Bitcoin บทความนี้เสนอโซลูชันสัญญา Bitcoin ที่สามารถบรรลุความสมบูรณ์ของทัวริงโดยไม่ต้องเปลี่ยนฉันทามติของเครือข่าย Bitcoin เพื่อให้สามารถตรวจสอบการคำนวณที่ซับซ้อนบน Bitcoin ได้โดยไม่ต้องเปลี่ยนกฎพื้นฐานของ Bitcoin BitVM ใช้ประโยชน์จาก Bitcoin Script และ Taproot เพื่อปรับใช้การโรลอัปในแง่ดี ตามลายเซ็นของ Lamport (หรือที่เรียกว่าความมุ่งมั่นบิต) การเชื่อมต่อถูกสร้างขึ้นระหว่าง Bitcoin UTXO สองตัวเพื่อใช้สคริปต์ Bitcoin แบบมีสถานะ ด้วยความมุ่งมั่นต่อโปรแกรมขนาดใหญ่ในที่อยู่ Taproot ผู้ปฏิบัติงานและผู้ตรวจสอบจะมีส่วนร่วมในการโต้ตอบนอกเครือข่ายอย่างกว้างขวาง ส่งผลให้เกิดรอยเท้าบนเครือข่ายขนาดเล็ก หากทั้งสองฝ่ายร่วมมือกัน การคำนวณนอกลูกโซ่ที่ซับซ้อนตามอำเภอใจก็สามารถดำเนินการได้โดยไม่ทิ้งร่องรอยใดๆ บนลูกโซ่ หากทั้งสองฝ่ายไม่ให้ความร่วมมือ เมื่อมีข้อพิพาทเกิดขึ้น จำเป็นต้องมีการดำเนินการแบบออนไลน์ เป็นผลให้ BitVM ขยายกรณีการใช้งานที่เป็นไปได้ของ Bitcoin อย่างมาก ทำให้ Bitcoin ไม่เพียงให้บริการในฐานะสกุลเงิน แต่ยังเป็นแพลตฟอร์มการตรวจสอบสำหรับแอปพลิเคชันแบบกระจายอำนาจที่หลากหลายและงานคอมพิวเตอร์ที่ซับซ้อน

อย่างไรก็ตาม แม้ว่าเทคโนโลยี BitVM จะมีข้อได้เปรียบอย่างมากในการขยาย Bitcoin แต่ก็ยังอยู่ในช่วงเริ่มต้นและยังคงมีปัญหาบางประการในแง่ของประสิทธิภาพและความปลอดภัย ตัวอย่างเช่น: (1) ความท้าทายและการตอบสนองต้องมีการโต้ตอบหลายครั้ง ส่งผลให้ค่าธรรมเนียมการจัดการมีราคาแพงและรอบการท้าทายที่ยาวนาน (2) ข้อมูลลายเซ็นแบบครั้งเดียวของ Lamport มีความยาวและความยาวของข้อมูลจะต้องลดลง (3) ฟังก์ชันแฮชคือ ซับซ้อนและต้องการฟังก์ชันแฮชที่เป็นมิตรกับ Bitcoin ช่วยลดต้นทุน (4) สัญญา BitVM ที่มีอยู่มีขนาดใหญ่มากและความจุบล็อก Bitcoin มีจำนวนจำกัด สามารถใช้สคริปต์แบบไม่มีสคริปต์เพื่อปรับใช้ BitVM สคริปต์แบบไม่มีสคริปต์ ประหยัดพื้นที่บล็อก Bitcoin ในขณะที่ปรับปรุงประสิทธิภาพของ BitVM (5) BitVM ที่มีอยู่ใช้โมเดลการอนุญาต เฉพาะสมาชิกพันธมิตรเท่านั้นที่สามารถเริ่มต้นการท้าทาย และจำกัดอยู่เพียงสองฝ่ายเท่านั้น ควรขยายไปสู่โมเดลการท้าทายหลายฝ่ายที่ไม่ได้รับอนุญาตเพื่อลดสมมติฐานความน่าเชื่อถือเพิ่มเติม ด้วยเหตุนี้ บทความนี้จึงเสนอแนวคิดในการเพิ่มประสิทธิภาพเพื่อปรับปรุงประสิทธิภาพและความปลอดภัยของ BitVM ต่อไป

2.หลักการ BitVM

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

เช่นเดียวกับ Optimistic Rollup และข้อเสนอ MATT (Merkelize All The Things) ระบบ BitVM ขึ้นอยู่กับการพิสูจน์การฉ้อโกงและโปรโตคอลตอบสนองต่อความท้าทาย แต่ไม่ต้องการการแก้ไขกฎฉันทามติของ Bitcoin พื้นฐานเบื้องต้นของ BitVM นั้นเรียบง่าย โดยส่วนใหญ่อิงจากการล็อคแฮช การล็อคเวลา และแผนผัง Taproot ขนาดใหญ่

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

ส่วนประกอบสำคัญของ BitVM คือ:

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

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

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

3.การเพิ่มประสิทธิภาพ BitVM

3.1 ลดจำนวนการโต้ตอบ OP ตาม ZK

ปัจจุบันมี Rollups หลัก 2 รายการ: ZK Rollups และ OP Rollups ในหมู่พวกเขา ZK Rollups อาศัยการตรวจสอบความถูกต้องของ ZK Proof นั่นคือหลักฐานการเข้ารหัสของการดำเนินการที่ถูกต้องและความปลอดภัยขึ้นอยู่กับสมมติฐานความซับซ้อนในการคำนวณ OP Rollups อาศัยหลักฐานการฉ้อโกงโดยถือว่าสถานะที่ส่งมานั้นถูกต้อง การตั้งค่า โดยปกติระยะเวลาท้าทายคือ 7 วัน และการรักษาความปลอดภัยจะถือว่าบุคคลที่ซื่อสัตย์อย่างน้อยหนึ่งรายในระบบสามารถตรวจจับสถานะที่ไม่ถูกต้องและส่งหลักฐานการฉ้อโกงได้ สมมติว่าจำนวนขั้นตอนสูงสุดของโปรแกรมท้าทาย BitVM คือ 2 ^{ 32 } และหน่วยความจำที่ต้องการคือ 2 ^{ 32 }* 4 ไบต์ ซึ่งประมาณ 17 GB ในกรณีที่เลวร้ายที่สุด จะใช้เวลาประมาณ 40 รอบของการท้าทายและการตอบสนอง ประมาณครึ่งปี และสคริปต์ทั้งหมดประมาณ 150 KB สถานการณ์นี้ขาดแรงจูงใจอย่างมาก แต่แทบไม่เคยเกิดขึ้นในทางปฏิบัติเลย

พิจารณาใช้การพิสูจน์ความรู้แบบศูนย์เพื่อลดจำนวนความท้าทายของ BitVM ซึ่งจะช่วยปรับปรุงประสิทธิภาพของ BitVM ตามทฤษฎีการพิสูจน์ความรู้เป็นศูนย์หากข้อมูลDataตอบสนองอัลกอริทึมFมันพิสูจน์ว่าการพิสูจน์เป็นไปตามอัลกอริธึมการตรวจสอบVerifyนั่นคืออัลกอริธึมการตรวจสอบจะให้ผลลัพธ์เป็น True หากข้อมูลDataไม่เป็นไปตามอัลกอริทึมFเป็นการพิสูจน์ว่าการพิสูจน์ไม่เป็นไปตามอัลกอริธึมการตรวจสอบด้วยVerifyนั่นคืออัลกอริธึมการตรวจสอบจะส่งออกเป็นเท็จ ในระบบ BitVM หากผู้ท้าชิงไม่รู้จักข้อมูลที่ส่งโดยผู้พิสูจน์ การท้าทายจะเริ่มต้นขึ้น

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

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

3.2 ลายเซ็นครั้งเดียวที่เป็นมิตรกับ Bitcoin

ในเครือข่าย Bitcoin ธุรกรรมที่เป็นไปตามกฎฉันทามติเป็นธุรกรรมที่ถูกต้อง แต่นอกเหนือจากกฎฉันทามติแล้ว ยังมีการแนะนำกฎมาตรฐานอีกด้วย โหนด Bitcoin ส่งต่อธุรกรรมมาตรฐานการออกอากาศเท่านั้น วิธีเดียวที่จะรวมธุรกรรมที่ถูกต้องแต่ไม่ได้มาตรฐานได้คือการทำงานร่วมกับนักขุดโดยตรง

ตามกฎที่เป็นเอกฉันท์ ขนาดสูงสุดของธุรกรรมแบบเดิม (ที่ไม่ใช่ Segwit) คือ 1 MB ซึ่งครอบครองบล็อกทั้งหมด แต่มาตรฐานของธุรกรรมแบบเดิมถูกจำกัดไว้ที่ 100 kB ตามกฎที่เป็นเอกฉันท์ ขนาดสูงสุดของธุรกรรม Segwit คือ 4 MB ซึ่งเป็นขีดจำกัดน้ำหนัก แต่มาตรฐานของธุรกรรม Segwit ถูกจำกัดไว้ที่ 400 kB

ลายเซ็น Lamport เป็นองค์ประกอบพื้นฐานของ BitVM ซึ่งจะช่วยลดความยาวของลายเซ็นและคีย์สาธารณะซึ่งช่วยลดข้อมูลธุรกรรมและลดค่าธรรมเนียมการจัดการ ลายเซ็นแบบครั้งเดียวของ Lamport ต้องใช้ฟังก์ชันแฮช (เช่น ฟังก์ชันการเรียงสับเปลี่ยนทางเดียว f) ในรูปแบบลายเซ็นครั้งเดียวของ Lamport ความยาวของข้อความคือ v บิต ความยาวคีย์สาธารณะคือ 2 v บิต และความยาวของลายเซ็นคือ 2 v บิตเช่นกัน ลายเซ็นและกุญแจสาธารณะมีความยาวและต้องใช้ก๊าซจัดเก็บจำนวนมาก ดังนั้นจึงจำเป็นต้องค้นหารูปแบบลายเซ็นที่มีฟังก์ชันคล้ายกันเพื่อลดความยาวของลายเซ็นและคีย์สาธารณะ เมื่อเปรียบเทียบกับลายเซ็นแบบครั้งเดียวของ Lamport ลายเซ็นแบบครั้งเดียวของ Winternitz จะลดความยาวของลายเซ็นและคีย์สาธารณะลงอย่างมาก แต่เพิ่มความซับซ้อนในการคำนวณของลายเซ็นและการตรวจสอบลายเซ็น

ในรูปแบบลายเซ็นแบบครั้งเดียวของ Winternitz ให้ใช้ฟังก์ชันพิเศษPจะvข้อความของบิตถูกแมปกับความยาวของnเวกเตอร์ของssค่าของแต่ละองค์ประกอบในคือ { 0,...,d}. โครงการลายเซ็นแบบครั้งเดียวของ Lamport คือd= 1 กรณีพิเศษของโครงการลงนามแบบครั้งเดียวของ Winternitz ในโครงการลายเซ็นแบบครั้งเดียวของ Winternitzn, d, vความสัมพันธ์ระหว่างความพึงพอใจ:n≈v/log 2(d+ 1). เมื่อ d= 15 ก็มีn≈(v/4)+ 1 . สำหรับประกอบด้วยnลายเซ็นขององค์ประกอบ Winternitz สั้นกว่าความยาวคีย์สาธารณะและความยาวลายเซ็นในรูปแบบลายเซ็นครั้งเดียวของ Lamport ถึง 4 เท่า อย่างไรก็ตาม ความซับซ้อนในการตรวจสอบลายเซ็นเพิ่มขึ้น 4 เท่า ใช้ใน BitVMd= 15, v= 160, f=ripemd 160(x) ใช้ลายเซ็นแบบครั้งเดียวของ Winternitz ซึ่งสามารถลดขนาดการคอมมิตบิตลงได้ 50% ซึ่งช่วยลดค่าธรรมเนียมการทำธุรกรรมของ BitVM ลงอย่างน้อย 50% ในอนาคต ในขณะที่เพิ่มประสิทธิภาพการใช้งาน Winternitz Bitcoin Script ที่มีอยู่ ก็สามารถสำรวจรูปแบบลายเซ็นแบบครั้งเดียวที่มีขนาดกะทัดรัดมากขึ้นซึ่งแสดงใน Bitcoin Script ได้

3.3 ฟังก์ชันแฮชที่เป็นมิตรกับ Bitcoin

ตามกฎที่เป็นเอกฉันท์ ขนาดสูงสุดของสคริปต์ P 2 TR คือ 10 kB และขนาดสูงสุดของพยานสคริปต์ P 2 TR จะเหมือนกับขนาดธุรกรรม Segwit สูงสุดซึ่งก็คือ 4 MB อย่างไรก็ตาม ขีดจำกัด standradness ของพยานสคริปต์ P 2 TR คือ 400 kB

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

BLAKE 3 เป็นเวอร์ชันที่ได้รับการปรับปรุงประสิทธิภาพของฟังก์ชันแฮช BLAKE 2 และแนะนำโหมด Bao tree เมื่อเปรียบเทียบกับระบบ BLAKE 2 s จำนวนรอบของฟังก์ชันการบีบอัดจะลดลงจาก 10 เป็น 7 ฟังก์ชันแฮชของ BLAKE 3 จะแบ่งอินพุตออกเป็นส่วนที่ต่อเนื่องกันขนาด 1,024 ไบต์ ส่วนสุดท้ายอาจสั้นกว่าแต่ไม่ว่างเปล่า เมื่อมีเพียงก้อนเดียว ก้อนนั้นจะเป็นโหนดรูทและเป็นโหนดเดียวของแผนผัง จัดเรียงชิ้นส่วนเหล่านี้เป็นโหนดใบของต้นไม้ไบนารี จากนั้นบีบอัดแต่ละชิ้นแยกกัน

เมื่อใช้ BitVM เพื่อตรวจสอบสถานการณ์การพิสูจน์การรวม Merkle อินพุตของการดำเนินการแฮชจะประกอบด้วยค่าแฮช 256 บิตสองค่า นั่นคือ อินพุตของการดำเนินการแฮชคือ 64 ไบต์ เมื่อใช้ฟังก์ชันแฮช BLAKE 3 จะสามารถจัดสรร 64 ไบต์เหล่านี้ภายในก้อนเดียว และการดำเนินการแฮชของ BLAKE 3 ทั้งหมดต้องการให้ใช้ฟังก์ชันการบีบอัดเพียงครั้งเดียวกับก้อนเดียว ในฟังก์ชันการบีบอัดของ BLAKE 3 จำเป็นต้องเรียกใช้ฟังก์ชันกลม 7 รายการและฟังก์ชันการเรียงสับเปลี่ยน 6 รายการ

ในปัจจุบัน การดำเนินการพื้นฐาน เช่น XOR การเพิ่มโมดูลาร์ และการเลื่อนบิตไปทางขวาตามค่า 32 ของคุณเสร็จสมบูรณ์แล้วใน BitVM และสามารถประกอบฟังก์ชันแฮช BLAKE 3 ที่ใช้งานโดยสคริปต์ Bitcoin ได้อย่างง่ายดาย ใช้ 4 ไบต์แยกกันในสแต็กเพื่อแสดง 32 คำเพื่อใช้ u 32 นอกจากนี้ u 32 บิต XOR และ 32 การหมุนบิตตามต้องการโดย BLAKE 3 ฟังก์ชันแฮช BLAKE 3 ปัจจุบันสคริปต์ Bitcoin มีขนาดรวมประมาณ 100 kB ซึ่งเพียงพอสำหรับการสร้าง BitVM เวอร์ชันของเล่น

นอกจากนี้ รหัส BLAKE 3 เหล่านี้ยังสามารถแยกออกได้ ทำให้ Verifier และ Prover สามารถลดข้อมูล on-chain ที่จำเป็นลงได้อย่างมาก โดยแบ่งการดำเนินการในเกมที่ตอบสนองต่อความท้าทายออกเป็นครึ่งหนึ่ง แทนที่จะดำเนินการทั้งหมด สุดท้าย ใช้สคริปต์ Bitcoin เพื่อใช้ฟังก์ชันแฮช เช่น Keccak-256 และ Grøstl เลือกฟังก์ชันแฮชที่เป็นมิตรกับ Bitcoin ที่สุด และสำรวจฟังก์ชันแฮชใหม่ ๆ ที่เป็นมิตรกับ Bitcoin

3.4 Scriptless Scripts BitVM

สคริปต์แบบไม่มีสคริปต์เป็นวิธีดำเนินการสัญญาอัจฉริยะแบบออฟไลน์โดยใช้ลายเซ็น Schnorr แนวคิด Scripless Scripts ถือกำเนิดมาจาก Mimblewimble และไม่จัดเก็บข้อมูลถาวร ยกเว้นเคอร์เนลและลายเซ็น

ข้อดีของสคริปต์แบบไม่มีสคริปต์คือฟังก์ชันการทำงาน ความเป็นส่วนตัว และประสิทธิภาพ

  • การทำงาน:สคริปต์ที่ไม่มีสคริปต์จะเพิ่มขอบเขตและความซับซ้อนของสัญญาอัจฉริยะ ความสามารถในการเขียนสคริปต์ Bitcoin ถูกจำกัดด้วยจำนวน OP_CODES ที่เปิดใช้งานในเครือข่าย และสคริปต์แบบไร้สคริปต์จะถ่ายโอนข้อกำหนดและการดำเนินการของสัญญาอัจฉริยะจากห่วงโซ่ไปสู่การสนทนาเฉพาะในหมู่ผู้เข้าร่วมสัญญาการออกแบบ โดยไม่ต้องรอให้เครือข่าย Bitcoin แยกเพื่อเปิดใช้งานเครือข่ายใหม่ . รหัส

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

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

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

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

3.5 การท้าทายหลายฝ่ายที่ไม่ได้รับอนุญาต

เหตุผลที่ความท้าทายของ BitVM ในปัจจุบันจำเป็นต้องได้รับอนุญาตตามค่าเริ่มต้นก็คือ UTXO ของ Bitcoin สามารถดำเนินการได้เพียงครั้งเดียวเท่านั้น ทำให้ผู้ตรวจสอบที่เป็นอันตราย เสีย สัญญาโดยการท้าทายผู้พิสูจน์ที่ซื่อสัตย์ ขณะนี้ BitVM ถูกจำกัดให้ใช้โหมดท้าทายแบบสองฝ่าย ผู้พิสูจน์ที่พยายามทำความชั่วสามารถท้าทายกับผู้ตรวจสอบที่ตนควบคุมไปพร้อมๆ กัน ซึ่งจะทำให้ เสีย สัญญา ทำให้การกระทำชั่วประสบผลสำเร็จ และผู้ตรวจสอบอื่นๆ ไม่สามารถป้องกันพฤติกรรมดังกล่าวได้ ดังนั้น บนพื้นฐานของ Bitcoin จึงจำเป็นต้องศึกษาโปรโตคอลท้าทาย OP หลายฝ่ายที่ไม่ได้รับอนุญาต ซึ่งสามารถขยายโมเดลความน่าเชื่อถือ 1-of-n ที่มีอยู่ของ BitVM ไปเป็น 1-of-N ในหมู่พวกเขา N มีขนาดใหญ่กว่า n มาก นอกจากนี้ จำเป็นต้องมีการวิจัยเพื่อแก้ไขปัญหาของผู้ท้าทายที่สมรู้ร่วมคิดกับผู้พิสูจน์อักษรหรือท้าทายสัญญาที่ สูญเปล่า อย่างมุ่งร้าย ในที่สุดการใช้โปรโตคอล BitVM ที่น่าเชื่อถือน้อยกว่า

การท้าทายหลายฝ่ายที่ไม่ได้รับอนุญาต ทำให้ทุกคนสามารถเข้าร่วมได้โดยไม่ต้องมีรายการอนุญาต ซึ่งหมายความว่าผู้ใช้สามารถถอนเหรียญจาก L2 ได้โดยไม่ต้องเกี่ยวข้องกับบุคคลที่สามที่เชื่อถือได้ นอกจากนี้ การถอนที่ไม่ถูกต้องสามารถถูกท้าทายและลบโดยผู้ใช้ที่ต้องการเข้าร่วมใน OP Challenge Protocol

การขยาย BitVM ไปสู่โมเดลความท้าทายหลายฝ่ายที่ไม่ได้รับอนุญาตจำเป็นต้องแก้ไขการโจมตีต่อไปนี้:

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

  • การโจมตีล่าช้า:ฝ่ายที่เป็นอันตรายหรือกลุ่มของฝ่ายที่เป็นอันตราย ปฏิบัติตามกลยุทธ์เพื่อป้องกันหรือชะลอการยืนยันผลลัพธ์ที่ถูกต้อง (เช่น การถอนสินทรัพย์ไปที่ L1) ใน L1 และบังคับให้ผู้พิสูจน์ความจริงต้องเสียค่าธรรมเนียม L1 ปัญหานี้สามารถแก้ไขได้โดยกำหนดให้ผู้ท้าชิงเดิมพันล่วงหน้า หากผู้ท้าชิงทำการโจมตีล่าช้า เงินเดิมพันจะถูกริบ อย่างไรก็ตาม หากผู้โจมตีเต็มใจที่จะเสียสละการวางหลักภายในขอบเขตที่กำหนดเพื่อดำเนินการโจมตีแบบดีเลย์ ควรมีมาตรการตอบโต้เพื่อลดผลกระทบของการโจมตีแบบดีเลย์ กระดาษ BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocolอัลกอริธึมที่นำเสนอทำให้ไม่ว่าผู้โจมตีจะเต็มใจที่จะสูญเสียคำสัญญามากเพียงใด การโจมตีกรณีที่เลวร้ายที่สุดสามารถทำให้เกิดความล่าช้าสูงสุดได้เท่านั้น

ในอนาคต เราจะสำรวจโมเดลการท้าทายหลายฝ่ายที่ไม่ได้รับอนุญาตของ BitVM ซึ่งเหมาะสมกับลักษณะของ Bitcoin และสามารถต้านทานปัญหาการโจมตีข้างต้นได้

4 บทสรุป

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

การอ้างอิง

  1. BitVM: Compute Anything on Bitcoin

  2. BitVM:Off-chain Bitcoin Contracts

  3. Robin Linus on BitVM

  4. [bitcoin-dev] BitVM: Compute Anything on Bitcoin

  5. The Odd Couple: ZK and Optimistic Rollups on a Scalability Date

  6. What are Bitcoin's transaction and script limits?

  7. BIP-342: Validation of Taproot Scripts

  8. https://twitter.com/robin_linus/status/1765337186222686347

  9. A Graduate Course in Applied Cryptography

  10. BLAKE 3: one function, fast everywhere

  11. [bitcoin-dev] Implementing Blake 3 in Bitcoin Script

  12. https://github.com/BlockstreamResearch/scriptless-scripts

  13. Introduction to Scriptless Scripts

  14. BitVM using Scriptless Scripts

  15. Solutions to Delay Attacks on Rollups

  16. Introducing DAVE. Cartesi's Permissionless Fault-Proof System.

  17. Delay Attacks on Rollups

  18. Solutions to Delay Attacks on Rollups - Arbitrum Research

  19. Multiplayer Interactive Computation Games Notes

  20. BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol

  21. Permissionless Refereed Tournaments

ลิงค์เดิม

ความปลอดภัย
เทคโนโลยี
ยินดีต้อนรับเข้าร่วมชุมชนทางการของ Odaily
กลุ่มสมาชิก
https://t.me/Odaily_News
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
บัญชีทางการ
https://twitter.com/OdailyChina
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
ค้นหา
สารบัญบทความ
อันดับบทความร้อน
Daily
Weekly
ดาวน์โหลดแอพ Odaily พลาเน็ตเดลี่
ให้คนบางกลุ่มเข้าใจ Web3.0 ก่อน
IOS
Android