เปิดใช้ ZK ในบิตคอยน์: จาก OP_CAT ไปสู่ State Proofs และ BitVM

ขั้นสูงAug 16, 2024
สำรวจวิธีการนำศักยภาพการพิสูจน์ที่เป็นศูนย์ศักราช (ZK) ไปรวมกับบิทคอยน์ โดยเน้นที่วิธีการที่สองสำหรับการตรวจสอบ SNARK: การเปิดใช้งาน OP_CAT ในสคริปต์บิทคอยน์และการใช้ปริศนาฟรอดโปรฟ์และปริศนาฟรอดใน Chain State Proofs เพื่อลดต้นทุนการตรวจสอบ
เปิดใช้ ZK ในบิตคอยน์: จาก OP_CAT ไปสู่ State Proofs และ BitVM

บทคัดย่อ

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


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


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

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

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

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

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


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

  1. การรักษาความเป็นส่วนตัวที่ดีขึ้นอย่างมาก: ใช้การสมมุติฐาน Peterson ในการสมบูรณ์ของจำนวนการทำธุรกรรมและการพิสูจน์ช่วงเพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้ (เช่นในการใช้ฝั่ง Blockstream ของ Blockstream); ใช้ลายเซ็นต่อเนื่อง (เช่น Monero) เพื่อซ่อนร่องรอยการทำธุรกรรม; บรรทุกธุรกรรมเพื่อความเป็นส่วนตัวแท้จริง (เช่น Zcash)

  2. เพิ่มประสิทธิภาพการทำธุรกรรม

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

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


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

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

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

การอ่านแนะนำ: [การเข้าใกล้ BTC: ความรู้พื้นฐานสำหรับเข้าใจ BitVM (1)]


ความสามารถของสคริปต์บิทคอยน์

สคริปต์บิตคอยน์สามารถทำอะไรได้:

  • จัดเรียงสแต็กและดำเนินการตรวจสอบความเท่าเทียม (เพื่อยืนยันเงื่อนไขที่เฉพาะเจาะจงและให้ความมั่นคงของการทำธุรกรรมและความถูกต้อง)
  • ดำเนินการทางเงื่อนไขที่คล้ายกับคำสั่ง if-else
  • ดำเนินการดำเนินการทางคณิตศาสตร์ที่จำกัดบนตัวเลข 32 บิต เช่น การบวกและการลบ
  • ตรวจสอบข้อมูลแฮชและยืนยันลายเซ็น ECDSA และลายเซ็น Schnorr

สคริปต์บิทคอยน์ที่ไม่สามารถทำได้:

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

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

ดังนั้น Bitcoin Script สามารถตรวจสอบ SNARKs ได้หรือไม่? ในทางทฤษฎีแม้ว่า Bitcoin Script จะไม่สมบูรณ์ทัวริง แต่การดําเนินการขั้นพื้นฐานก็เพียงพอที่จะตรวจสอบการคํานวณใด ๆ อย่างไรก็ตามในทางปฏิบัติการตรวจสอบ SNARK ไม่สามารถทําได้เนื่องจากขนาดโปรแกรมที่จําเป็นสําหรับขั้นตอนการตรวจสอบเกินขีด จํากัด บล็อกสูงสุดของ Bitcoin ที่ 4MB ในขณะที่เราสามารถพยายามดําเนินการทางคณิตศาสตร์ในสาขาที่ จํากัด ขนาดใหญ่ค่าใช้จ่ายจะสูงอย่างห้ามปราม ตัวอย่างเช่นใน BitVM การคูณจํานวนเต็ม 254 บิตสองจํานวนส่งผลให้ขนาดสคริปต์ Bitcoin เกือบ 8KB ยิ่งไปกว่านั้นหากไม่มี OP_CAT ค่าใช้จ่ายในการตรวจสอบหลักฐานของ Merkle ก็สูงเช่นกันเนื่องจากต้องมีการดําเนินการคล้ายกับลูป


ดังนั้นทําไมไม่เพียงแค่ปรับเปลี่ยนโปรโตคอล Bitcoin เพื่อเพิ่ม opcodes ที่มีประสิทธิภาพมากขึ้น? ดังที่ได้กล่าวไว้ก่อนหน้านี้การบรรลุฉันทามติส่วนใหญ่เกี่ยวกับกฎโปรโตคอลใหม่นั้นยากมาก Bitcoin ขาดผู้มีอํานาจตัดสินใจแบบรวมศูนย์และข้อเสนอใด ๆ ในการปรับปรุง Bitcoin Script ต้องเผชิญกับการต่อต้านอย่างมากจากผู้มีส่วนได้ส่วนเสียที่มีมุมมองที่แตกต่างกัน ไม่มีวิธีที่มีประสิทธิภาพในการวัดฉันทามติของชุมชนในเครือข่าย Bitcoin และการบังคับให้อัปเดตโดยไม่มีอาจนําไปสู่การแยกโซ่ แน่นอนว่า Bitcoin ไม่สามารถเปลี่ยนแปลงได้ทั้งหมด การอัปเดตล่าสุดคือ SegWit ในปี 2017 และ Taproot ในปี 2021


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

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

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

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

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


เมื่อพิจารณาถึงแบบอย่างของ Bitcoin กับ Taproot สําหรับการรวมคุณสมบัติขั้นสูงเพิ่มเติมเราอาจสงสัยว่าเหตุใดจึงไม่มีการแนะนํา opcode เฉพาะสําหรับการตรวจสอบ SNARK ความแตกต่างที่สําคัญอยู่ที่ความซับซ้อนและฉันทามติที่จําเป็นสําหรับ OP_SNARK ซึ่งแตกต่างจาก Taproot ซึ่งมีการออกแบบที่ชัดเจนและตรงไปตรงมาซึ่งได้รับการสนับสนุนอย่างกว้างขวางข้อเสนอ OP_SNARK แตกต่างกันอย่างมากทําให้ยากที่จะรวบรวมชุมชนด้วยแนวทางเดียว หากนําไปใช้ทุกโหนด Bitcoin จะต้องรองรับวิธีการตรวจสอบ SNARK เฉพาะนี้ซึ่งจะเพิ่มความต้องการทางเทคนิคอย่างมาก ยิ่งไปกว่านั้นความซับซ้อนโดยธรรมชาติของ OP_SNARK เป็นอุปสรรคสําคัญ - Taproot เพิ่มโค้ดประมาณ 1,600 บรรทัดซึ่งสามารถจัดการได้ตามมาตรฐานชุมชนในขณะที่ OP_SNARK จะทําให้เกิดการเข้ารหัสที่ซับซ้อนมากขึ้น นอกจากนี้การกําหนดว่าใครจะประเมินการเปิดใช้งาน OP_SNARK และบรรลุฉันทามติเมื่อมีเพียงไม่กี่คนที่เข้าใจความซับซ้อนของมันอย่างเต็มที่จะเพิ่มระดับความยาก ด้วยความท้าทายเหล่านี้การอัพเกรด OP_SNARK ไม่น่าจะเกิดขึ้นจริงในอนาคตอันใกล้

อย่างไรก็ตาม มีวิธีอื่น ๆ ในการยืนยัน SNARKs ใน Bitcoin Script เราสามารถทำให้ Bitcoin scripts มีประสิทธิภาพมากขึ้นโดยการเพิ่ม opcodes ที่ง่ายขึ้น ทำให้ผู้คนสามารถนำโปรแกรมตรวจสอบ SNARK เข้าไปในสคริปต์ได้ แต่ในความเป็นจริงมันยากมากที่จะเขียนโปรแกรมตรวจสอบ SNARK ในภาษา Bitcoin script จึงทำให้ทีมวิจัย Blockstream กำลังพัฒนา Simplicity ภาษาโปรแกรมที่ออกแบบมาเพื่อแทนที่ Bitcoin Script Simplicity ออกแบบมาเฉพาะเพื่อระบบความเห็นร่วมบนบล็อกเชนและมีเจตนาที่จะไม่ใช่ Turing-complete เพื่อทำให้ง่ายต่อการวิเคราะห์แบบคงทนและการยืนยันทางกฎหมาย


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

ฟังก์ชันของ OP_CAT นั้นตรงไปตรงมา โดยนําองค์ประกอบสองอันดับแรกจากสแต็ค มาต่อกัน แล้วดันผลลัพธ์กลับไปยังสแต็ค แม้ว่าสิ่งนี้อาจดูเหมือนพื้นฐาน แต่ก็มีศักยภาพในการปลดล็อกการปรับปรุงที่สําคัญในภาษาสคริปต์ของ Bitcoin ตัวอย่างเช่นสคริปต์ Bitcoin ปัจจุบันไม่สามารถเข้าถึงข้อมูลธุรกรรมแบบ on-chain บางอย่างเช่นจํานวนเงินที่เกี่ยวข้อง แต่ด้วย OP_CAT ความสามารถนี้สามารถแนะนําได้ นอกจากนี้ OP_CAT อาจเป็นเครื่องมือในการตรวจสอบหลักฐานของ Merkle

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

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

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

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

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

นอกจากนี้หากการทำธุรกรรม Bitcoin รองรับ Zero-Knowledge (ZK) Proofs ได้ในภายหลัง การเพิ่มเวลาในการสร้างธุรกรรมอาจไม่เป็นปัญหาใหญ่อีกต่อไป กระเป๋าเก็บเงินฮาร์ดแวร์ซึ่งใช้สำหรับการเก็บทรัพย์สินระยะยาวมักจะมีจอและออกแบบขนาดเล็กเน้นการเก็บรักษาคีย์และสร้างลายเซ็น กระเป๋าเหล่านี้มักมีหน่วยประมวลผลที่มีพลังงานต่ำเช่น 240MHz dual-core processor แต่ก็สามารถจัดการธุรกรรม Bitcoin ได้อย่างมีประสิทธิภาพ


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


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

ในที่สอง Chain State Proofs เป็นสิ่งสำคัญในการก้าวหน้า BitVM ทีม ZeroSync ได้ศึกษา Chain State Proofs อย่างละเอียดและพัฒนาเวอร์ชันที่เรียกว่า 'header chain Proofs' ที่มีขั้นตอนการใช้ zero-knowledge proofs เพื่อตรวจสอบ Bitcoin block headers และสร้าง 'header chain' ที่รวมถึง block headers ทั้งหมด 850,000 รายการในประวัติศาสตร์ของ Bitcoin ทุกชุด block headers จะถูกแฮชเพื่อสร้าง proof 80 ไบต์ วิธีนี้ต้องใช้การคำนวณ SHA-256 คูณสองสำหรับแต่ละ header เพื่อยืนยันพรูฟการทำงาน ZeroSync ใช้ STARKs เพื่อสร้าง proof นี้ที่มีค่าประมาณ 4,000 ดอลลาร์ในการผลิต ในขณะที่การตรวจสอบใช้เวลาเพียงประมาณ 3 วินาทีในเบราว์เซอร์ของฉัน


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

อย่างไรก็ตาม แม้ว่าโอกาสที่การโจมตีดังกล่าวจะประสบความสําเร็จจะต่ํา แต่หากอาจทําให้ผู้โจมตีสามารถขโมย 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 แก้ไขปัญหานี้โดยใช้หลักฐานการฉ้อโกงเพื่อตรวจจับ Provers ที่เป็นอันตราย หาก Prover อ้างสิทธิ์ที่ไม่ถูกต้องหรือใช้ที่เก็บข้อมูล KV ที่ผิดพลาดผู้อื่นสามารถเริ่มธุรกรรมบนบล็อกเชน Bitcoin เพื่อรายงานการประพฤติมิชอบของ Prover และยึดทรัพย์สินที่ถือหุ้นของ Prover


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

อ่านเนื้อหาต้นฉบับที่นี่: https://www.youtube.com/watch?v=GrSCZmFuy7U

คำปฏิเสธ:

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

เปิดใช้ ZK ในบิตคอยน์: จาก OP_CAT ไปสู่ State Proofs และ BitVM

ขั้นสูงAug 16, 2024
สำรวจวิธีการนำศักยภาพการพิสูจน์ที่เป็นศูนย์ศักราช (ZK) ไปรวมกับบิทคอยน์ โดยเน้นที่วิธีการที่สองสำหรับการตรวจสอบ SNARK: การเปิดใช้งาน OP_CAT ในสคริปต์บิทคอยน์และการใช้ปริศนาฟรอดโปรฟ์และปริศนาฟรอดใน Chain State Proofs เพื่อลดต้นทุนการตรวจสอบ
เปิดใช้ ZK ในบิตคอยน์: จาก OP_CAT ไปสู่ State Proofs และ BitVM

บทคัดย่อ

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


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


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

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

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

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

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


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

  1. การรักษาความเป็นส่วนตัวที่ดีขึ้นอย่างมาก: ใช้การสมมุติฐาน Peterson ในการสมบูรณ์ของจำนวนการทำธุรกรรมและการพิสูจน์ช่วงเพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้ (เช่นในการใช้ฝั่ง Blockstream ของ Blockstream); ใช้ลายเซ็นต่อเนื่อง (เช่น Monero) เพื่อซ่อนร่องรอยการทำธุรกรรม; บรรทุกธุรกรรมเพื่อความเป็นส่วนตัวแท้จริง (เช่น Zcash)

  2. เพิ่มประสิทธิภาพการทำธุรกรรม

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

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


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

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

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

การอ่านแนะนำ: [การเข้าใกล้ BTC: ความรู้พื้นฐานสำหรับเข้าใจ BitVM (1)]


ความสามารถของสคริปต์บิทคอยน์

สคริปต์บิตคอยน์สามารถทำอะไรได้:

  • จัดเรียงสแต็กและดำเนินการตรวจสอบความเท่าเทียม (เพื่อยืนยันเงื่อนไขที่เฉพาะเจาะจงและให้ความมั่นคงของการทำธุรกรรมและความถูกต้อง)
  • ดำเนินการทางเงื่อนไขที่คล้ายกับคำสั่ง if-else
  • ดำเนินการดำเนินการทางคณิตศาสตร์ที่จำกัดบนตัวเลข 32 บิต เช่น การบวกและการลบ
  • ตรวจสอบข้อมูลแฮชและยืนยันลายเซ็น ECDSA และลายเซ็น Schnorr

สคริปต์บิทคอยน์ที่ไม่สามารถทำได้:

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

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

ดังนั้น Bitcoin Script สามารถตรวจสอบ SNARKs ได้หรือไม่? ในทางทฤษฎีแม้ว่า Bitcoin Script จะไม่สมบูรณ์ทัวริง แต่การดําเนินการขั้นพื้นฐานก็เพียงพอที่จะตรวจสอบการคํานวณใด ๆ อย่างไรก็ตามในทางปฏิบัติการตรวจสอบ SNARK ไม่สามารถทําได้เนื่องจากขนาดโปรแกรมที่จําเป็นสําหรับขั้นตอนการตรวจสอบเกินขีด จํากัด บล็อกสูงสุดของ Bitcoin ที่ 4MB ในขณะที่เราสามารถพยายามดําเนินการทางคณิตศาสตร์ในสาขาที่ จํากัด ขนาดใหญ่ค่าใช้จ่ายจะสูงอย่างห้ามปราม ตัวอย่างเช่นใน BitVM การคูณจํานวนเต็ม 254 บิตสองจํานวนส่งผลให้ขนาดสคริปต์ Bitcoin เกือบ 8KB ยิ่งไปกว่านั้นหากไม่มี OP_CAT ค่าใช้จ่ายในการตรวจสอบหลักฐานของ Merkle ก็สูงเช่นกันเนื่องจากต้องมีการดําเนินการคล้ายกับลูป


ดังนั้นทําไมไม่เพียงแค่ปรับเปลี่ยนโปรโตคอล Bitcoin เพื่อเพิ่ม opcodes ที่มีประสิทธิภาพมากขึ้น? ดังที่ได้กล่าวไว้ก่อนหน้านี้การบรรลุฉันทามติส่วนใหญ่เกี่ยวกับกฎโปรโตคอลใหม่นั้นยากมาก Bitcoin ขาดผู้มีอํานาจตัดสินใจแบบรวมศูนย์และข้อเสนอใด ๆ ในการปรับปรุง Bitcoin Script ต้องเผชิญกับการต่อต้านอย่างมากจากผู้มีส่วนได้ส่วนเสียที่มีมุมมองที่แตกต่างกัน ไม่มีวิธีที่มีประสิทธิภาพในการวัดฉันทามติของชุมชนในเครือข่าย Bitcoin และการบังคับให้อัปเดตโดยไม่มีอาจนําไปสู่การแยกโซ่ แน่นอนว่า Bitcoin ไม่สามารถเปลี่ยนแปลงได้ทั้งหมด การอัปเดตล่าสุดคือ SegWit ในปี 2017 และ Taproot ในปี 2021


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

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

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

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

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


เมื่อพิจารณาถึงแบบอย่างของ Bitcoin กับ Taproot สําหรับการรวมคุณสมบัติขั้นสูงเพิ่มเติมเราอาจสงสัยว่าเหตุใดจึงไม่มีการแนะนํา opcode เฉพาะสําหรับการตรวจสอบ SNARK ความแตกต่างที่สําคัญอยู่ที่ความซับซ้อนและฉันทามติที่จําเป็นสําหรับ OP_SNARK ซึ่งแตกต่างจาก Taproot ซึ่งมีการออกแบบที่ชัดเจนและตรงไปตรงมาซึ่งได้รับการสนับสนุนอย่างกว้างขวางข้อเสนอ OP_SNARK แตกต่างกันอย่างมากทําให้ยากที่จะรวบรวมชุมชนด้วยแนวทางเดียว หากนําไปใช้ทุกโหนด Bitcoin จะต้องรองรับวิธีการตรวจสอบ SNARK เฉพาะนี้ซึ่งจะเพิ่มความต้องการทางเทคนิคอย่างมาก ยิ่งไปกว่านั้นความซับซ้อนโดยธรรมชาติของ OP_SNARK เป็นอุปสรรคสําคัญ - Taproot เพิ่มโค้ดประมาณ 1,600 บรรทัดซึ่งสามารถจัดการได้ตามมาตรฐานชุมชนในขณะที่ OP_SNARK จะทําให้เกิดการเข้ารหัสที่ซับซ้อนมากขึ้น นอกจากนี้การกําหนดว่าใครจะประเมินการเปิดใช้งาน OP_SNARK และบรรลุฉันทามติเมื่อมีเพียงไม่กี่คนที่เข้าใจความซับซ้อนของมันอย่างเต็มที่จะเพิ่มระดับความยาก ด้วยความท้าทายเหล่านี้การอัพเกรด OP_SNARK ไม่น่าจะเกิดขึ้นจริงในอนาคตอันใกล้

อย่างไรก็ตาม มีวิธีอื่น ๆ ในการยืนยัน SNARKs ใน Bitcoin Script เราสามารถทำให้ Bitcoin scripts มีประสิทธิภาพมากขึ้นโดยการเพิ่ม opcodes ที่ง่ายขึ้น ทำให้ผู้คนสามารถนำโปรแกรมตรวจสอบ SNARK เข้าไปในสคริปต์ได้ แต่ในความเป็นจริงมันยากมากที่จะเขียนโปรแกรมตรวจสอบ SNARK ในภาษา Bitcoin script จึงทำให้ทีมวิจัย Blockstream กำลังพัฒนา Simplicity ภาษาโปรแกรมที่ออกแบบมาเพื่อแทนที่ Bitcoin Script Simplicity ออกแบบมาเฉพาะเพื่อระบบความเห็นร่วมบนบล็อกเชนและมีเจตนาที่จะไม่ใช่ Turing-complete เพื่อทำให้ง่ายต่อการวิเคราะห์แบบคงทนและการยืนยันทางกฎหมาย


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

ฟังก์ชันของ OP_CAT นั้นตรงไปตรงมา โดยนําองค์ประกอบสองอันดับแรกจากสแต็ค มาต่อกัน แล้วดันผลลัพธ์กลับไปยังสแต็ค แม้ว่าสิ่งนี้อาจดูเหมือนพื้นฐาน แต่ก็มีศักยภาพในการปลดล็อกการปรับปรุงที่สําคัญในภาษาสคริปต์ของ Bitcoin ตัวอย่างเช่นสคริปต์ Bitcoin ปัจจุบันไม่สามารถเข้าถึงข้อมูลธุรกรรมแบบ on-chain บางอย่างเช่นจํานวนเงินที่เกี่ยวข้อง แต่ด้วย OP_CAT ความสามารถนี้สามารถแนะนําได้ นอกจากนี้ OP_CAT อาจเป็นเครื่องมือในการตรวจสอบหลักฐานของ Merkle

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

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

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

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

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

นอกจากนี้หากการทำธุรกรรม Bitcoin รองรับ Zero-Knowledge (ZK) Proofs ได้ในภายหลัง การเพิ่มเวลาในการสร้างธุรกรรมอาจไม่เป็นปัญหาใหญ่อีกต่อไป กระเป๋าเก็บเงินฮาร์ดแวร์ซึ่งใช้สำหรับการเก็บทรัพย์สินระยะยาวมักจะมีจอและออกแบบขนาดเล็กเน้นการเก็บรักษาคีย์และสร้างลายเซ็น กระเป๋าเหล่านี้มักมีหน่วยประมวลผลที่มีพลังงานต่ำเช่น 240MHz dual-core processor แต่ก็สามารถจัดการธุรกรรม Bitcoin ได้อย่างมีประสิทธิภาพ


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


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

ในที่สอง Chain State Proofs เป็นสิ่งสำคัญในการก้าวหน้า BitVM ทีม ZeroSync ได้ศึกษา Chain State Proofs อย่างละเอียดและพัฒนาเวอร์ชันที่เรียกว่า 'header chain Proofs' ที่มีขั้นตอนการใช้ zero-knowledge proofs เพื่อตรวจสอบ Bitcoin block headers และสร้าง 'header chain' ที่รวมถึง block headers ทั้งหมด 850,000 รายการในประวัติศาสตร์ของ Bitcoin ทุกชุด block headers จะถูกแฮชเพื่อสร้าง proof 80 ไบต์ วิธีนี้ต้องใช้การคำนวณ SHA-256 คูณสองสำหรับแต่ละ header เพื่อยืนยันพรูฟการทำงาน ZeroSync ใช้ STARKs เพื่อสร้าง proof นี้ที่มีค่าประมาณ 4,000 ดอลลาร์ในการผลิต ในขณะที่การตรวจสอบใช้เวลาเพียงประมาณ 3 วินาทีในเบราว์เซอร์ของฉัน


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

อย่างไรก็ตาม แม้ว่าโอกาสที่การโจมตีดังกล่าวจะประสบความสําเร็จจะต่ํา แต่หากอาจทําให้ผู้โจมตีสามารถขโมย 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 แก้ไขปัญหานี้โดยใช้หลักฐานการฉ้อโกงเพื่อตรวจจับ Provers ที่เป็นอันตราย หาก Prover อ้างสิทธิ์ที่ไม่ถูกต้องหรือใช้ที่เก็บข้อมูล KV ที่ผิดพลาดผู้อื่นสามารถเริ่มธุรกรรมบนบล็อกเชน Bitcoin เพื่อรายงานการประพฤติมิชอบของ Prover และยึดทรัพย์สินที่ถือหุ้นของ Prover


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

อ่านเนื้อหาต้นฉบับที่นี่: https://www.youtube.com/watch?v=GrSCZmFuy7U

คำปฏิเสธ:

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