นี่คือบทบรรณาธิการความคิดเห็นโดย Shinobi นักการศึกษาที่เรียนรู้ด้วยตนเองในพื้นที่ Bitcoin และโฮสต์พอดคาสต์ Bitcoin เชิงเทคโนโลยี
ในวันที่ 9 ตุลาคม 2022 Burak จาก Bitmatrix (เครื่องมือสลับที่สร้างขึ้นบนเครือข่าย Liquid) ได้สร้างและเผยแพร่ ธุรกรรมไปยังเครือข่าย Bitcoin หลัก ใช้ UTXO กับ Tapscript multisig ที่มีเกณฑ์ 998 จาก 999 ธุรกรรมนี้มีลายเซ็นส่วนตัว 998 ลายเซ็นในสนามพยาน และมีขนาดเกือบ 0.1 MB และเป็นเรื่องตลกที่นำกุญแจสาธารณะที่เหมือนกันทุกประการมาใช้ซ้ำสำหรับผู้เข้าร่วม 999 คนใน multisig ทุกคน ธุรกรรมนี้ทำให้เกิดการหยุดชะงักครั้งใหญ่สำหรับเครือข่าย Lightning โดยการเปิดเผยจุดบกพร่องใน LND และ btcd (ไคลเอนต์สำรองสำหรับเครือข่าย Bitcoin)
วัตถุประสงค์ทั้งหมดของการทำธุรกรรมนี้คือเพื่อแสดงให้เห็นถึงความสามารถในการปรับขนาดที่ดีขึ้นของสคริปต์หลายลายเซ็นที่ Taproot ได้เปิดใช้งาน แม้จะไม่ได้ใช้โปรโตคอล MuSig ที่อิง Schnorr-signature แล้ว Taproot ก็เปิดใช้ชุดผู้เข้าร่วม multisig ที่ใหญ่กว่าเดิมได้ เวอร์ชันของ Bitcoin Script นี่อาจเป็นการอภิปรายย่อยๆ เล็กน้อยเกี่ยวกับข้อจำกัดด้านขนาดก่อนหน้าของ multisig หากคุณดำดิ่งลงไปในทุกวิถีทางที่เป็นไปได้ที่คุณสามารถสร้าง multisig ด้วย Bitcoin Script ดังนั้นเพื่อความเรียบง่าย ฉันจะพูดถึงข้อจำกัดก่อนหน้านี้ที่ใช้ ไปยัง Pay-to-script-hash (P2SH) และ Pay-to-witness-script-hash (P2WSH) การสร้างหลายซิก เมื่อพูดถึงวิธีมาตรฐานในการทำ P2SH multisig ขีดจำกัดขนาดสูงสุดของผู้เข้าร่วมคือ 15 และในกรณีของ multisig P2WSH มาตรฐาน ขนาดสูงสุดคือ 20 ขีดจำกัดเหล่านี้เป็นเพราะว่าสคริปต์มีขนาดใหญ่เพียงใด กำลังใช้สคริปต์ต่าง ๆ เหล่านี้ และข้อจำกัดในจำนวนการประมวลผลที่อนุญาตให้ทำในขอบเขตของสคริปต์เดียว การละเมิดข้อจำกัดเหล่านี้จะทำให้ธุรกรรมไม่ถูกต้อง
เมื่อใช้ Taproot ขีดจำกัดขนาดสคริปต์เหล่านี้จะถูกลบออกอย่างสมบูรณ์ ซึ่งหมายความว่าข้อจำกัดเดียวที่มีขนาดสคริปต์ Taproot คือขีดจำกัดของขนาดบล็อกเอง นี่คือปัญหาที่เกิดขึ้นเกี่ยวกับ LND และ btcd กฎฉันทามติที่ใช้ใน btcd ได้ลบข้อจำกัดเหล่านี้อย่างถูกต้องเกี่ยวกับขนาดสคริปต์ แต่ปัญหาคือฐานรหัสสำหรับการสื่อสารแบบเพียร์ทูเพียร์ยังใช้การตรวจสอบขนาดสคริปต์เพื่อเพิ่มการป้องกันสองชั้นสำหรับผู้ดำเนินการโหนด บล็อกและธุรกรรมจะต้องผ่านการตรวจสอบฉันทามติ”ก่อนฉันทามติ”ก่อนที่จะทำให้มันเป็นรหัสฉันทามติหลักที่ทำการตรวจสอบความถูกต้อง ตรรกะที่ตรวจสอบสิ่งต่าง ๆ ซ้ำ ๆ เพิ่มชั้นพิเศษของการป้องกันบล็อกหรือธุรกรรมที่ไม่ถูกต้อง โค้ดนี้ไม่ได้รับการอัปเดตอย่างเหมาะสมเพื่อลบขีดจำกัดขนาดสคริปต์ และยังคงบังคับใช้ขีดจำกัดของสคริปต์ก่อนหน้าสำหรับ SegWit กับธุรกรรม Taproot ดังนั้นในขณะที่รหัสฉันทามติที่แท้จริงเองจะตรวจสอบธุรกรรม Taproot ที่มีขนาดใหญ่มากนี้อย่างเหมาะสม บล็อกที่มีมันไม่เคยผ่านจากการตรวจสอบความถูกต้องแบบเพียร์ทูเพียร์ไปสู่ตรรกะการตรวจสอบฉันทามติที่แท้จริง หมายความว่าโหนด btcd ทั้งหมดจนตรอกที่บล็อกรวมถึง การทำธุรกรรมของ Burak
เหตุใดสิ่งนี้จึงส่งผลกระทบต่อ LND เนื่องจากผู้คนจำนวนมากใช้งาน Bitcoin Core ภายใต้อินสแตนซ์ LND ของพวกเขา เป็นเพราะ LND ใช้รหัสเดียวกันกับ btcd เพื่อรับและประมวลผลบล็อก ดังนั้นแม้ว่าโหนด LND ของคุณจะทำงานบน Bitcoin Core ซึ่งจะตรวจสอบบล็อกที่เกี่ยวข้องอย่างเหมาะสมและไม่หยุดชะงัก อินสแตนซ์ LND ของคุณจะปฏิเสธที่จะยอมรับการบล็อกนั้นและหยุดชะงักแม้ว่าโหนดลูกโซ่หลักของคุณจะดำเนินไปอย่างถูกต้อง
จุดบกพร่องนี้ได้รับการแก้ไขอย่างรวดเร็ว และสำหรับความรู้ของฉันไม่ได้ถูกนำไปใช้ในทางที่ก่อให้เกิดอันตรายใดๆ แต่สิ่งนี้ได้เปิดโหนด LND ทุกโหนดบนเครือข่าย Lightning ซึ่งอาจนำไปสู่การขโมยเงินในช่องต่างๆ ได้ เว้นแต่ พวกเขากำลังใช้หอสังเกตการณ์ภายนอก เนื่องจากโหนดหยุดชะงักที่บล็อกนั้น มันจึงไม่มีมุมมองแบบเรียลไทม์ของบล็อคเชน และในกรณีที่คู่สัญญาช่องทางส่งสถานะแชนเนลเก่าไปยังบล็อคเชน มันคงไม่รู้ตัวและไม่สามารถตอบสนองได้ ด้วยธุรกรรมการลงโทษที่เหมาะสมเพื่อรักษาความปลอดภัยของเงินทุนของผู้ใช้ นี่เป็นข้อผิดพลาดที่ร้ายแรงมากซึ่งทำให้เปอร์เซ็นต์มหาศาลของ bitcoin บนเครือข่าย Lightning เสี่ยงต่อการถูกขโมย เว้นแต่ผู้ใช้จะทำการแพตช์และอัปเดตโหนดด้วยตนเอง หรือตรวจสอบช่องของพวกเขาเป็นการส่วนตัวเพื่อให้สามารถตอบกลับได้ด้วยตนเองในกรณีที่ปิด กับสภาพที่ล้าสมัย ฉันต้องบอกว่าตัวดำเนินการโหนดที่ไม่ใช่ด้านเทคนิคส่วนใหญ่อาจไม่สามารถทำได้
โชคดีที่ปัญหานี้ไม่ได้ถูกเอารัดเอาเปรียบอย่างกว้างขวาง แต่หากสิ่งนี้ถูกค้นพบใน codebase ก่อนการทำธุรกรรมของ Burak จะถูกผลักไปที่บล็อคเชน สิ่งนี้อาจถูกเอาเปรียบโดยเจตนาโดยผู้ไม่หวังดีในทางยุทธวิธี บุคคลหรือกลุ่มคนสามารถเปิดช่องจำนวนมากบนเครือข่ายได้ง่ายมาก และแลกเปลี่ยนเงินทั้งหมดในช่องเหล่านั้นกลับเป็นตัวเองในเครือข่ายผ่าน submarine swap โดยปล่อยให้เงินทั้งหมดในช่องที่อยู่อีกด้านหนึ่ง แล้วส่ง ธุรกรรม Taproot ขนาดใหญ่เช่น Burak ทำ ปิดช่องของพวกเขาทันทีโดยใช้สถานะที่ล้าสมัย ผู้ที่ตกเป็นเหยื่อจะไม่รู้ด้วยซ้ำ และแม้ว่าพวกเขาจะมีความสามารถทางเทคนิคที่ค่อนข้างต่ำของผู้ดำเนินการโหนดจำนวนมาก แต่ก็เป็นไปได้มากที่คนส่วนใหญ่จะไม่สามารถตอบสนองได้ทันเวลาเพื่อแก้ไขปัญหาด้วยตนเองด้วย ธุรกรรมการลงโทษ
จุดบกพร่องนี้เน้นสองประเด็นสำคัญที่ต้องพิจารณา ประการแรก การใช้งานโหนด Bitcoin แบบอิสระหลายครั้งอาจเป็นอันตรายได้ โชคดีที่แทบไม่มีใครเรียกใช้ btcd เป็นโหนดสำหรับสิ่งใดๆ ที่ร้ายแรง ดังนั้นผลกระทบที่เกิดขึ้นกับเครือข่าย Bitcoin พื้นฐานจึงเป็นสิ่งที่สามารถละเลยได้อย่างสมบูรณ์ ยกเว้นบุคคลจำนวนไม่มากที่โหนดหยุดทำงาน หากนักขุดใช้ btcd ซึ่งอาจส่งผลให้ chainsplit ในเครือข่าย Bitcoin แยกตัวออกไปได้ง่ายมาก ซึ่งจะทำให้ผู้ดำเนินการ btcd ทั้งหมดออกจากเครือข่ายของชนกลุ่มน้อยซึ่งจะต้องมีการแทรกแซงด้วยตนเองเพื่อแก้ไข ปัญหาที่สองคือ ในกรณีของเลเยอร์ที่สองเหนือเครือข่ายหลัก การดำเนินการตรวจสอบฉันทามติควรทำอย่างระมัดระวัง นี่เป็นปัญหาที่ยุ่งยาก เพราะในขณะที่โหนด Lightning ใดๆ ที่ทำงานบนโหนดเต็มของ Bitcoin ในทางทฤษฎีนั้น สามารถเอาต์ซอร์สการตรวจสอบนี้ไปยังโหนดนั้นได้ 100% เท่านั้น ไม่ใช่ว่าโหนด Lightning ทั้งหมดจะใช้ประโยชน์จากโหนดแบบเต็มที่เชื่อถือได้ของพวกเขาเอง ไม่น่าจะมีการเปลี่ยนแปลง — ผู้ใช้จำนวนมากมักจะยังคงใช้งานโหนดในลักษณะดังกล่าว ดังนั้นในบางระดับการตรวจสอบกฎฉันทามติของ Bitcoin บางส่วนหรือทั้งหมดจะต้องได้รับการสนับสนุนในการใช้งาน Lightning ด้วยเช่นกัน
ต่อจากนี้ไป ฉันหวังว่านี่จะเป็นการปลุกให้ตื่นขึ้นถึงความสำคัญของการตรวจสอบความถูกต้องฉันทามติที่ซิงค์กันในซอฟต์แวร์ต่างๆ ในพื้นที่นี้ โดยไม่มีความบังเอิญระหว่างทุกสิ่งที่มี ไม่ใช่เครือข่าย Bitcoin ที่เชื่อมโยงกันเป็นเอกพจน์ ทุกคนควรดีใจมากที่สิ่งนี้ไม่ได้ส่งผลให้เกิดการแสวงหาผลประโยชน์ครั้งใหญ่ในเครือข่ายทั้งหมด แต่ผู้คนควรตระหนักว่าปัญหานี้อาจร้ายแรงเพียงใดหากสิ่งต่าง ๆ ไม่ได้แสดงออกมาอย่างที่พวกเขาทำ
นี่คือแขกโพสต์โดย Shinobi ความคิดเห็นที่แสดงออกมาเป็นความคิดเห็นของตนเองทั้งหมดและไม่จำเป็นต้องสะท้อนถึง BTC Inc หรือ Bitcoin Magazine
