ผู้เขียนต้นฉบับ: Janos Nick, Blockstream

การรวบรวมต้นฉบับ: Bai Ding, Faust, Geek Web3

บทคัดย่อ: บทความนี้กระชับแต่ตรงประเด็นว่าจะทำให้ Bitcoin รองรับฟังก์ชันการตรวจสอบ ZK ได้อย่างไร หัวข้อเฉพาะที่ครอบคลุมรวมถึงข้อบกพร่องด้านการทำงานของ Bitcoin UTXO และสคริปต์ แนวคิดเช่น Taproot และ OP_CAT และ BitVM และ Chain State Proof เนื้อหาทั่วไป บทความนี้นำเสนอมุมมองที่ค่อนข้างชัดเจน:

การนำ ZK เข้าสู่โปรโตคอล Bitcoin เป็นแนวโน้มที่หลีกเลี่ยงไม่ได้ มีสองเส้นทางสำหรับสิ่งนี้ วิธีแรกคือการอนุญาตให้สคริปต์ Bitcoin รองรับการตรวจสอบ SNARK โดยตรง ซึ่งต้องการความช่วยเหลือจากโค้ดการดำเนินการ OP_CAT และความน่าจะเป็นที่ OP_CAT จะผ่านในที่สุด สูงมาก เส้นทางที่สองขึ้นอยู่กับ BitVM จำเป็นต้องแนะนำวิธีการป้องกันการฉ้อโกง และทีมงาน ZeroSync ยังเสนอ Chain State Proofs เพื่อลดต้นทุนในการตรวจสอบข้อมูลประวัติไคลเอ็นต์ของโหนด

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

สิ่งนี้ย้อนกลับไปสู่ต้นกำเนิดทางประวัติศาสตร์ของ Bitcoin เมื่อ Satoshi Nakamoto เผยแพร่สมุดปกขาว Bitcoin เขากล่าวว่า: "ฉันกำลังทำงานกับระบบการชำระเงินทางอิเล็กทรอนิกส์ใหม่ล่าสุด ระบบนี้เป็นระบบ P2P ที่สมบูรณ์และไม่จำเป็นต้องพึ่งพาบุคคลที่สามใดๆ" ข้อความนี้เผยแพร่ในรายชื่อผู้รับจดหมายของ Cypherpunks (กลุ่มสนทนาทางอีเมลที่ก่อตั้งในปี 1992 โดยกลุ่มนักเขียนการเข้ารหัสและผู้ที่ชื่นชอบเทคโนโลยีที่เกี่ยวข้องกับการปกป้องความเป็นส่วนตัวและเทคโนโลยีการเข้ารหัส)

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

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

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

แม้ว่าจะมีไคลเอนต์กระเป๋าเงินบางรายที่มีฟังก์ชั่นความเป็นส่วนตัวที่สามารถแก้ไขปัญหาข้างต้นได้ในระดับหนึ่ง ผู้พัฒนาไคลเอนต์กระเป๋าเงินเหล่านี้ต้องเผชิญกับภัยคุกคามในขนาดต่างๆ ตัวอย่างเช่น ผู้พัฒนากระเป๋าเงิน Samourai CoinJoin ถูก FBI จับกุมในเดือนเมษายน 2024 และหนึ่งสัปดาห์ต่อมา ผู้พัฒนากระเป๋าเงิน Wasabi ได้ปิดองค์ประกอบการประสานงาน CoinJoin ของตน เห็นได้ชัดว่ากระเป๋าเงินความเป็นส่วนตัวเหล่านี้ไม่สมควรได้รับความไว้วางใจจากผู้ใช้เลย

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

เพื่อตอบสนองต่อปัญหาข้างต้น มีข้อเสนอมากมายในชุมชน Bitcoin และข้อเสนอที่มีผลทางทฤษฎีที่ดีที่สุดควรเกี่ยวข้องกับ ZK และ SNARK ด้วย ZK และ SNARK คุณสามารถบรรลุคุณสมบัติต่อไปนี้:

1. ปรับปรุงความเป็นส่วนตัวอย่างมีนัยสำคัญ: ใช้ Homomorphic Peterson เพื่อยืนยันจำนวนธุรกรรมและ Range Proof เพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้อย่างมีนัยสำคัญ (เช่นเดียวกับที่ทำในห่วงโซ่ด้านองค์ประกอบของ Blockstream) ซ่อนการติดตามธุรกรรมผ่านลายเซ็นที่เชื่อมโยงได้ (เช่น Monero) เป็น Zcash)

2. ปรับปรุงปริมาณธุรกรรม

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

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

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

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

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

มีสคริปต์ Bitcoin ทั่วไปหลายประเภทที่มีมาตั้งแต่เริ่มต้นของ Bitcoin ตัวอย่างเช่น สคริปต์ที่พบบ่อยที่สุดใน Bitcoin ประกอบด้วยคีย์สาธารณะ + opcode ที่ตรวจสอบลายเซ็นดิจิทัล opcode นี้กำหนดว่าในการใช้/ปลดล็อก UTXO จะต้องแสดงลายเซ็นดิจิทัลของคีย์สาธารณะที่เกี่ยวข้อง

ที่นี่เราสรุปการทำงานของ Bitcoin Script ก่อนอื่น Bitcoin Script สามารถทำอะไรได้บ้าง?

· สามารถจัดเรียงสแต็กใหม่ได้ สามารถตรวจสอบความเท่าเทียมกันได้ (ใช้การตรวจสอบความเท่าเทียมกันเพื่อตรวจสอบว่าตรงตามเงื่อนไขเฉพาะหรือไม่ ดังนั้นจึงรับประกันความปลอดภัยและความถูกต้องของธุรกรรม) และการดำเนินการสาขาที่คล้ายกับ if-else สามารถทำได้

· สามารถดำเนินการทางคณิตศาสตร์แบบจำกัดกับตัวเลข 32 บิต ได้ เช่น การบวกและการลบ

· ข้อมูลสามารถแฮชได้และสามารถตรวจสอบลายเซ็น ECDSA และ Schnorr ได้

Bitcoin Script ไม่สามารถทำอะไรได้บ้าง?

· ไม่มีการวนซ้ำ การกระโดด หรือการเรียกซ้ำ กล่าวคือ ทัวริงยังไม่สมบูรณ์ และความสามารถในการโปรแกรมมีจำกัดมาก

· การดำเนินการระดับบิตไม่สามารถทำได้ ไม่มี opcodes สำหรับการคูณและการหาร

· ไม่สามารถเชื่อมองค์ประกอบบนสแต็กได้

· ความสามารถเพียงเล็กน้อยในการอ่านและตรวจสอบข้อมูลธุรกรรมออนไลน์

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

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

Bitcoin Script สามารถตรวจสอบ SNARK ได้หรือไม่? แม้ว่าสคริปต์ Bitcoin จะไม่สมบูรณ์ในทางทฤษฎี แต่การดำเนินการขั้นพื้นฐานก็เพียงพอที่จะตรวจสอบการคำนวณใดๆ ได้ อย่างไรก็ตาม ในทางปฏิบัติ การตรวจสอบ SNARK ไม่สามารถทำได้เนื่องจากขนาดของโปรแกรมที่จำเป็นสำหรับขั้นตอนการตรวจสอบเกินขีดจำกัดบล็อกสูงสุดของ Bitcoin ที่ 4MB

บางทีเราอาจลองดำเนินการทางคณิตศาสตร์ในเขตข้อมูลจำกัดขนาดใหญ่ได้ แต่ค่าใช้จ่ายก็สูงมาก ตัวอย่างเช่น การคูณจำนวนเต็ม 254 บิตสองตัวที่ BitVM นำมาใช้ ทำให้ขนาดสคริปต์ Bitcoin ที่เกี่ยวข้องมีขนาดเกือบ 8KB

นอกจากนี้ การตรวจสอบการพิสูจน์ Merkle โดยไม่มี OP_CAT ก็มีราคาแพงเช่นกัน เนื่องจากต้องใช้การดำเนินการที่คล้ายคลึงกับ for loops

กลับมาที่คำถามก่อนหน้านี้: ทำไมเราไม่สามารถเปลี่ยนโปรโตคอล Bitcoin และเพิ่ม opcodes ที่ทรงพลังกว่านี้ได้?

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

แน่นอนว่า Bitcoin ไม่คงที่อย่างสมบูรณ์ การอัปเดตล่าสุดคือ SegWit ในปี 2560 และ Taproot ในปี 2564

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

นอกจากนี้ การปรับปรุง Bitcoin ของ Taproot นั้นส่วนใหญ่แบ่งออกเป็นสามส่วนดังต่อไปนี้:

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

ประการที่สอง Taproot จะลดข้อมูลสคริปต์ที่ต้องเปิดเผยในห่วงโซ่ คุณสามารถรวบรวมสคริปต์หลายรายการไว้ในแผนผัง Merkle โดยแต่ละสคริปต์จะอยู่บนลีฟที่แตกต่างกัน หากคุณต้องการทริกเกอร์สคริปต์บางตัว คุณเพียงแค่ต้องเปิดเผยเท่านั้น . ใบไม้ที่ตั้งอยู่และหลักฐาน Merkle;

ประการที่สาม Taproot ยังเพิ่มการออกแบบกลไกอื่นๆ ด้วย

ต้องบอกว่าเนื่องจาก Bitcoin มีแบบอย่างในการเพิ่มฟังก์ชันที่มีประสิทธิภาพมากขึ้นเช่น Tarpoot ทำไมไม่เพิ่ม opcode เฉพาะเพื่อตรวจสอบ SNARK ล่ะ? เนื่องจากการเพิ่มสิ่งที่เรียกว่า OP_SNARK opcode นั้นแตกต่างจากการอัพเกรด Taproot มาก

ประการแรก มีแนวคิดการออกแบบมากมายสำหรับ OP_SNARK และเป็นเรื่องยากสำหรับคนส่วนใหญ่ที่จะสนับสนุนโซลูชันเดียว ประการที่สอง หากข้อเสนอดังกล่าวผ่าน โหนด Bitcoin ทั้งหมดจะต้องสนับสนุนโซลูชัน OP_SNARK เฉพาะนี้ ซึ่งจะเพิ่มความท้าทายทางเทคนิคครั้งใหญ่ . ภาระ.

นอกจากนี้ ความซับซ้อนของ OP_SNARK เองก็เป็นความท้าทายที่ยิ่งใหญ่เช่นกัน หากไม่รวมการทดสอบ Taproot จะเพิ่มโค้ดประมาณ 1,600 บรรทัดเท่านั้น ซึ่งเป็นที่ยอมรับ ในขณะที่ OP_SNARK มีโค้ดที่ซับซ้อนกว่ามาก

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

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

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

ด้านล่างนี้เราจะพูดถึงข้อเสนอที่เรียบง่ายแต่มีน้ำหนักมาก ซึ่งอาจทำให้ Bitcoin Script มีประสิทธิภาพมากขึ้น นั่นคือ opcode OP_CAT ดังที่เราได้กล่าวไว้ก่อนหน้านี้ OP_CAT มีอยู่ใน Bitcoin เวอร์ชันเริ่มต้น แต่ opcode นี้สามารถอนุญาตให้โหนด Bitcoin ถูกโจมตี DOS ภายใต้เงื่อนไขบางประการ ดังนั้น Satoshi Nakamoto จึงถูกปิดใช้งาน ขณะนี้บางคนในชุมชน Bitcoin ต้องการเปิดใช้งานอีกครั้ง . มัน.

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

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

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

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

โดยสรุป อาจมีเส้นทางที่เป็นไปได้สำหรับ Bitcoin ในการเปิดใช้งานการตรวจสอบ SNARK ในสคริปต์ Bitcoin โดยการเปิดใช้งาน opcode แบบง่าย ๆ เช่น OP_CAT นอกจากนี้ยังเป็นที่น่าสังเกตว่ามีข้อเสนอล่าสุดที่เรียกว่า "Great Script Restoration" ซึ่งเปิดใช้งาน opcodes การคูณ ทำให้ opcodes ทางคณิตศาสตร์ทั้งหมดทำงานด้วยความแม่นยำตามอำเภอใจ

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

ปัจจุบัน บล็อก Bitcoin สามารถบรรจุข้อมูลได้สูงสุด 4MB และคาดว่าจะขุดบล็อกได้ทุกๆ 10 นาที บล็อกเกือบทั้งหมดสามารถเต็มไปด้วยสคริปต์ Bitcoin และพยานพยาน (คล้ายกับลายเซ็นดิจิทัล) จากการคำนวณ แต่ละบล็อกสามารถมีการตรวจสอบลายเซ็นได้สูงสุด 80K โดยเฉลี่ย แต่ละบล็อกรองรับการตรวจสอบลายเซ็น 7K ถึง 10K CPU Intel ปี 2020 ของฉันใช้เวลาโดยเฉลี่ย 3.2 วินาทีในการตรวจสอบบล็อก Bitcoin แน่นอนว่าไม่เพียงแต่การตรวจสอบลายเซ็นที่ใช้เวลานานเท่านั้นที่ส่งผลต่อความเร็วในการตรวจสอบบล็อกอีกด้วย

นอกจากนี้ หากธุรกรรม Bitcoin รองรับ ZK-ization ในอนาคต ดูเหมือนว่าจะไม่เป็นอันตรายแม้ว่าจะขยายเวลาการสร้างธุรกรรมออกไปก็ตาม สำหรับกระเป๋าเงินฮาร์ดแวร์ที่ใช้สำหรับการจัดเก็บทรัพย์สินในระยะยาว มักจะมีหน้าจอและมีขนาดไม่ใหญ่นัก หน้าที่ของพวกเขาคือจัดเก็บกุญแจและสร้างลายเซ็น CPU ของกระเป๋าฮาร์ดแวร์โดยทั่วไปค่อนข้างอ่อนแอ เช่น CPU แบบดูอัลคอร์ 240MHz พร้อมหน่วยความจำจำนวนหนึ่ง ซึ่งตอบสนองเร็วมากเมื่อลงนามธุรกรรม Bitcoin

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

เราได้ใช้เวลามากมายในการพูดคุยถึงวิธีเปลี่ยนการออกแบบพื้นฐานของ Bitcoin ข้างต้น แต่ในความเป็นจริงแล้ว มีสถานการณ์การใช้งานมากมายที่สามารถนำมาใช้ได้โดยไม่ต้องเปลี่ยน Bitcoin ที่นี่ฉันต้องการเน้นแอปพลิเคชันที่เกี่ยวข้องกับ BitVM - Chain State Proofs ซึ่งรวมกับ ZK สามารถพิสูจน์ความถูกต้องของบล็อกแฮชได้

เทคโนโลยีนี้ทำให้เกิดการเปลี่ยนแปลงอะไรกับ Bitcoin? ประการแรก ด้วย Chain State Proofs ภาระงานของการซิงโครไนซ์และการตรวจสอบข้อมูลปฏิทิน Bitcoin จะถูกบีบอัด ซึ่งช่วยลดต้นทุนการรันโหนดได้อย่างมาก ปัจจุบัน ใช้เวลา 5 ชั่วโมง 30 นาทีในการซิงโครไนซ์และตรวจสอบบล็อก Bitcoin ล่าสุดจากบล็อกกำเนิดบนอุปกรณ์ที่มีฮาร์ดแวร์ที่ดี ในขณะที่จะใช้เวลาหลายวันบนอุปกรณ์ระดับ Raspberry Pi หากมีการพิสูจน์สถานะ ในครั้งนี้ - กระบวนการบริโภคสามารถลดลงได้อย่างมาก ประการที่สอง การพิสูจน์สถานะลูกโซ่เป็นส่วนสำคัญที่สามารถใช้ได้กับ BitVM และจะส่งเสริมการใช้งาน BitVM

ทีม ZeroSync ดำเนินการวิจัยเชิงลึกเกี่ยวกับ Chain State Proofs และสร้าง "header chain Proofs" ที่เบากว่า โซลูชันนี้เมื่อรวมกับ ZK จะพิสูจน์ความถูกต้องของส่วนหัวของบล็อก Bitcoin เท่านั้น จึงสร้าง "header chain" ซึ่งมีทั้งหมด 850,000 ส่วนหัวของบล็อกในประวัติศาสตร์ Bitcoin และสร้างแฮชขนาด 80 ไบต์สำหรับแต่ละส่วนหัวของบล็อก

โครงการนี้ต้องการการคำนวณ SHA-256 สองครั้งในแต่ละส่วนหัวของบล็อก Bitcoin เพื่อตรวจสอบหลักฐาน PoW ที่สอดคล้องกัน ZeroSync ใช้ STARK เพื่อสร้างหลักฐานห่วงโซ่ส่วนหัวของ Bitcoin ค่าใช้จ่ายในการสร้างหลักฐานอยู่ที่ประมาณ 4,000 เหรียญสหรัฐ และใช้เวลาเพียง 3 วินาทีในการตรวจสอบหลักฐานด้วยเบราว์เซอร์ของฉัน

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

อย่างไรก็ตาม แม้ว่าสถานการณ์การโจมตีนี้จะมีอัตราความสำเร็จต่ำ แต่การพิสูจน์ด้วย Header Chain Proof ก็ไม่สามารถถือเป็นวิธีแก้ปัญหาที่เข้าใจผิดได้ หากผู้โจมตีสามารถขโมย BTC จำนวนมหาศาลได้ หากเราต้องการพิสูจน์สถานะลูกโซ่โดยสมบูรณ์ เราจำเป็นต้องพิสูจน์โดยตรงว่าเนื้อหาทั้งหมดในบล็อก Bitcoin นั้นถูกต้อง รวมถึงการตรวจสอบลายเซ็น ECDSA และ Schnorr ตามเส้นโค้งวงรี secp256k1

บล็อกประวัติรายเดือนของ Bitcoin สามารถมีลายเซ็นได้ 30 ล้านลายเซ็น และประวัติประกอบด้วยการดำเนินการลายเซ็นทั้งหมด 2.5 พันล้านรายการ และการดำเนินการ SHA-256 จำนวนมาก ด้วยวิธีนี้ เครือข่าย Bitcoin จะสร้างข้อมูลบล็อกประมาณ 7GB ทุกเดือน และข้อมูลประวัติทั้งหมดรวมกันมากกว่า 650GB ในความเป็นจริงตัวเลขนี้อาจเป็น 2 ถึง 3 ครั้ง

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

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

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

หลายคนในชุมชน Bitcoin รู้สึกตื่นเต้นกับศักยภาพของ SNARK/STARK วิธีที่เป็นไปได้มากที่สุดเพื่อให้บรรลุการตรวจสอบ SNARK ในระยะกลางถึงระยะยาวนั้นเป็นไปได้มากที่สุดคือ BitVM แต่ต้องใช้การลงทุนด้าน R&D มากขึ้นเพื่อให้มีประสิทธิภาพในทางปฏิบัติ

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

ลิงค์เดิม