การใช้ประโยชน์จากแมลงสายฟ้าเป็นทางเลือกที่ถูกต้องตามหลักจริยธรรม

นี่คือบทบรรณาธิการความคิดเห็นโดย Shinobi นักการศึกษาที่เรียนรู้ด้วยตนเองในพื้นที่ Bitcoin และโฮสต์พอดคาสต์ Bitcoin ที่เน้นเทคโนโลยี

เป็นครั้งที่สองในรอบประมาณหนึ่งเดือนที่ btcd/LND มีข้อผิดพลาดในการใช้ประโยชน์ ซึ่งทำให้พวกเขาเบี่ยงเบนไปจาก Bitcoin Core ที่เป็นเอกฉันท์ เป็นอีกครั้งที่ Burak เป็นผู้พัฒนาที่จุดชนวนช่องโหว่นี้ ซึ่งคราวนี้เป็นความตั้งใจอย่างชัดเจน และอีกครั้งหนึ่งที่เป็นปัญหาเกี่ยวกับโค้ดสำหรับแยกวิเคราะห์ธุรกรรม Bitcoin ที่อยู่เหนือชั้นฉันทามติ อย่างที่ฉันได้พูดคุยกันในของฉัน ชิ้นส่วนในจุดบกพร่องก่อนหน้า ที่ Burak เรียกใช้ ก่อนที่ Taproot จะมีข้อจำกัดว่าสคริปต์และข้อมูลพยานในการทำธุรกรรมจะมีขนาดใหญ่เพียงใด ด้วยการเปิดใช้งาน Taproot ขีดจำกัดเหล่านั้นจะถูกลบออก เหลือเพียงข้อจำกัดบนขีดจำกัดขนาดบล็อกเท่านั้นที่จำกัดส่วนเหล่านี้ของธุรกรรมแต่ละรายการ ปัญหาของบั๊กล่าสุดคือแม้ว่าโค้ดที่เป็นเอกฉันท์ใน btcd จะได้รับการอัปเกรดอย่างเหมาะสมเพื่อสะท้อนถึงการเปลี่ยนแปลงนี้ แต่โค้ดที่จัดการการส่งผ่านแบบ peer-to-peer รวมถึงการแยกวิเคราะห์ข้อมูลก่อนส่งหรือเมื่อรับ ก็ไม่ได้อัปเกรดอย่างถูกต้อง ดังนั้นการบล็อกการประมวลผลรหัสและธุรกรรมก่อนที่จะถูกส่งออกไปเพื่อตรวจสอบความถูกต้องสำหรับฉันทามติข้อมูลจึงล้มเหลว ไม่เคยส่งต่อไปยังตรรกะการตรวจสอบฉันทามติ และการบล็อกที่เป็นปัญหาไม่สามารถตรวจสอบได้

สิ่งที่คล้ายกันมากเกิดขึ้นในครั้งนี้ ข้อจำกัดอีกประการหนึ่งในส่วนเพียร์ทูเพียร์ของโค้ดเบสคือการบังคับใช้ข้อจำกัดเกี่ยวกับข้อมูลพยานอย่างไม่ถูกต้อง โดยจำกัดไว้ที่สูงสุด 1/8 ของขนาดบล็อก ซึ่งตรงข้ามกับขนาดเต็มบล็อก Burak สร้าง การทำธุกรรม ด้วยข้อมูลพยานเพียงหน่วยน้ำหนักเดียวเกินขีดจำกัดที่เข้มงวด และโหนด btcd และ LND จนตรอกอีกครั้งที่ความสูงบล็อกนั้น ธุรกรรมนี้เป็นธุรกรรมที่ไม่ได้มาตรฐาน ซึ่งหมายความว่าแม้ว่ามันจะถูกต้องอย่างสมบูรณ์ตามกฎที่สอดคล้องกัน แต่มันไม่ถูกต้องตามนโยบายเริ่มต้นของ mempool ดังนั้นโหนดจะไม่ส่งต่อข้ามเครือข่าย เป็นไปได้อย่างสมบูรณ์แบบที่จะขุดมันลงในบล็อก แต่วิธีเดียวที่จะทำเช่นนั้นได้คือการมอบมันให้กับนักขุดโดยตรง ซึ่งเป็นสิ่งที่ Burak ทำด้วยความช่วยเหลือของ F2Pool

สิ่งนี้ผลักดันให้เกิดประเด็นที่ว่าโค้ดใดๆ ที่มีวัตถุประสงค์เพื่อแยกวิเคราะห์และตรวจสอบความถูกต้องของข้อมูล Bitcoin จะต้องได้รับการตรวจสอบอย่างหนักเพื่อให้แน่ใจว่าสอดคล้องกับสิ่งที่ Bitcoin Core จะทำ ไม่สำคัญว่าโค้ดนั้นจะเป็นกลไกฉันทามติสำหรับการใช้งานโหนดหรือเป็นเพียงส่วนหนึ่งของโค้ดที่ส่งธุรกรรมสำหรับโหนด Lightning ข้อผิดพลาดที่สองนี้คือ อยู่เหนือเดือนก่อนอย่างแท้จริง ในโค้ดเบส มันไม่ได้ถูกค้นพบโดยใครก็ตามที่ Lightning Labs AJ Towns รายงานเมื่อวันที่ 11 ตุลาคม สองวันหลังจากบั๊กดั้งเดิมถูกทริกเกอร์โดยธุรกรรมหลายซิกของ Burak 998 จาก 999 มันถูกโพสต์แบบสาธารณะบน Github เป็นเวลา 10 ชั่วโมงก่อนที่จะถูกลบ จึงมีการแก้ไขแต่ไม่ได้เผยแพร่ โดยตั้งใจที่จะแก้ไขปัญหาอย่างเงียบๆ ในรุ่นถัดไปของ LND

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

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

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

LND ไม่ใช่สิ่งเดียวที่ได้รับผลกระทบ ของเหลว กระบวนการตรึงก็พังเช่นกันจำเป็นต้องมีการอัปเดตไปยังเจ้าหน้าที่ของสหพันธ์เพื่อแก้ไข Rust Bitcoin เวอร์ชันเก่า ก็ได้รับผลกระทบเช่นกัน ซึ่งทำให้แผงลอยส่งผลกระทบต่อ Block Explorer และอินสแตนซ์ Electrs บางตัว (การใช้งานเซิร์ฟเวอร์แบ็กเอนด์สำหรับ Electrum Wallet) ตอนนี้ ยกเว้นหมุดของ Liquid ที่จะเปิดเผยเงินทุนไปยังคีย์การกู้คืนฉุกเฉินที่ Blockstream ถืออยู่หลังจากหมดเวลาล็อคอิน และตามความเป็นจริงแล้วในพล็อตเรื่องภาพยนตร์สไตล์การปล้นที่ Blockstream ขโมยเงินเหล่านี้ไป ทุกคนรู้ดีอยู่แล้วว่าจะต้องตามใคร — คนอื่นๆ เหล่านี้ ปัญหาไม่เคยทำให้เงินทุนของใครตกอยู่ในความเสี่ยงเลย นอกจากนี้ Rust Bitcoin ยังได้แก้ไขข้อบกพร่องเฉพาะนี้ในเวอร์ชันใหม่กว่า ซึ่งเห็นได้ชัดว่าไม่ได้นำไปสู่การสื่อสารกับผู้ดูแลโค้ดเบสอื่น ๆ เพื่อเน้นย้ำถึงปัญหาที่อาจเกิดขึ้น เป็นเพียงการใช้ประโยชน์จากจุดบกพร่องบนเครือข่ายเท่านั้นที่เปิดเผยอย่างกว้างขวางว่าปัญหานี้มีอยู่ในโค้ดเบสหลายตัว

สิ่งนี้ทำให้เกิดปัญหาใหญ่บางประการเมื่อพูดถึงช่องโหว่เช่นนี้ในซอฟต์แวร์เลเยอร์ 2 บน Bitcoin ประการแรก ความจริงจังในการตรวจสอบโค้ดเบสเหล่านี้เพื่อหาจุดบกพร่องด้านความปลอดภัย และวิธีการจัดลำดับความสำคัญเทียบกับการผสานรวมคุณสมบัติใหม่ ฉันคิดว่ามันบอกได้อย่างชัดเจนว่าการรักษาความปลอดภัยไม่ได้ถูกจัดลำดับความสำคัญเสมอไป เนื่องจากข้อผิดพลาดที่สองนี้ไม่ได้ถูกพบโดยผู้ดูแลของโค้ดเบสที่มีอยู่ แม้ว่ามันจะอยู่ติดกับข้อบกพร่องเริ่มต้นที่ค้นพบเมื่อเดือนที่แล้วก็ตาม หลังจากข้อผิดพลาดสำคัญประการหนึ่งที่ทำให้เงินทุนของผู้ใช้ตกอยู่ในความเสี่ยง การตรวจสอบภายในของ codebase นั้นไม่เสร็จสิ้นใช่หรือไม่ ต้องใช้คนจากนอกโครงการค้นพบมันเหรอ? นั่นไม่ได้แสดงให้เห็นถึงความสำคัญในการปกป้องเงินทุนของผู้ใช้มากกว่าการสร้างคุณสมบัติใหม่เพื่อดึงดูดผู้ใช้มากขึ้น ประการที่สอง ความจริงที่ว่าปัญหานี้ได้รับการแก้ไขแล้วใน Rust Bitcoin แสดงให้เห็นว่าขาดการสื่อสารระหว่างผู้ดูแลโค้ดเบสที่แตกต่างกันเกี่ยวกับจุดบกพร่องเช่นนี้ สิ่งนี้ค่อนข้างเข้าใจได้ เนื่องจากการมีโค้ดเบสที่แตกต่างกันอย่างสิ้นเชิงไม่ได้ทำให้คนที่พบข้อบกพร่องในทีมคิดทันทีว่า "ฉันควรติดต่อทีมอื่นที่เขียนซอฟต์แวร์ที่คล้ายกันในภาษาการเขียนโปรแกรมที่แตกต่างกันโดยสิ้นเชิง เพื่อเตือนพวกเขาเกี่ยวกับศักยภาพของข้อบกพร่องดังกล่าว" คุณไม่พบจุดบกพร่องใน Windows จากนั้นจึงคิดที่จะรายงานจุดบกพร่องไปยังผู้ดูแลเคอร์เนล Linux ทันที Bitcoin เป็นโปรโตคอลสำหรับการกระจายความเห็นพ้องต้องกันในเครือข่ายทั่วโลกนั้นเป็นสัตว์ร้ายที่แตกต่างออกไปมาก บางทีนักพัฒนา Bitcoin ควรเริ่มคิดตามแนวทางเหล่านั้นเมื่อพูดถึงช่องโหว่ในซอฟต์แวร์ Bitcoin โดยเฉพาะอย่างยิ่งเมื่อพูดถึงการแยกวิเคราะห์และตีความข้อมูลที่เกี่ยวข้องกับฉันทามติ

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

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

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

นี่คือแขกโพสต์โดย Shinobi ความคิดเห็นที่แสดงออกมานั้นเป็นความคิดเห็นของตนเองทั้งหมด และไม่จำเป็นต้องสะท้อนความคิดเห็นของ BTC Inc หรือ Bitcoin Magazine