Trianacode

วิกฤตทรัพย์สินร่วมในโอเพนซอร์ส: บทเรียนจากกระเป๋า Bitcoin

Connie Lawrence
,

เหตุการณ์ Coldcard ชี้ให้เห็นช่องว่างระหว่าง “โอเพนซอร์ส” ในทฤษฎีกับการปฏิบัติ

Bitcoin Magazine รายงานว่า การแฮ็กกระเป๋า Coldcard ซึ่งเป็นฮาร์ดแวร์วอลเล็ตแบบ self-custody ที่ได้รับความนิยม ส่งผลให้ผู้ใช้สูญเสีย Bitcoin มูลค่ามากกว่า 100 ล้านดอลลาร์ หรือคิดเป็นจำนวนมากกว่า 1,500 BTC เหตุการณ์ดังกล่าวทำให้เกิดข้อสงสัยอย่างกว้างขวางว่าคำว่า “โอเพนซอร์ส” ที่หลายฝ่ายอ้างอิงนั้นมีความหมายเพียงใดในทางปฏิบัติ

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

FOSS, FLOSS และ Source Available: ความแตกต่างที่กระทบความปลอดภัยโดยตรง

Bitcoin Magazine อธิบายว่า ภาษาที่ใช้เรียกซอฟต์แวร์โอเพนซอร์สนั้นมีความซับซ้อน และความแตกต่างแต่ละคำมีนัยสำคัญทางกฎหมายและทางปฏิบัติ

  • FOSS (Free and Open Source Software) และ FLOSS (Free/Libre and Open Source Software) คือซอฟต์แวร์ที่ผ่านนิยามอย่างเป็นทางการของเสรีภาพผู้ใช้ มูลนิธิ Free Software Foundation หรือ FSF กำหนด “ซอฟต์แวร์เสรี” ผ่านเสรีภาพ 4 ประการ โดยเน้นย้ำว่า “free” หมายถึงเสรีภาพ ไม่ใช่ราคา
  • “Source available” หรือ “source viewable” เป็นคนละเรื่อง โค้ดอาจเปิดให้อ่านได้ แต่ใบอนุญาตจำกัดสิทธิ์ในการขาย เช่นเดียวกับเฟิร์มแวร์ของ Coldcard ที่เผยแพร่ภายใต้ MIT บวก Commons Clause ซึ่งตัดสิทธิ์ในการ “ขาย” ซอฟต์แวร์ออกโดยเฉพาะ

เกณฑ์ของ OSI และ Commons Clause

นิยามโอเพนซอร์สของ Open Source Initiative หรือ OSI เพิ่มเกณฑ์อีก 10 ข้อ เช่น การแจกจ่ายต่อโดยไม่เก็บค่าตอบแทน การเปิดเผยซอร์สโค้ดในรูปแบบที่แก้ไขได้ สิทธิ์ในการสร้างและแจกจ่ายงานดัดแปลง รวมถึงการไม่เลือกปฏิบัติต่อบุคคล กลุ่ม หรือสาขาอาชีพ รวมถึงการใช้งานเชิงพาณิชย์ ใบอนุญาตต้องผ่านครบทั้ง 10 ข้อจึงจะถือว่าเป็นโอเพนซอร์สตามมาตรฐาน OSI

FAQ ของ Commons Clause ระบุชัดเจนว่า “Is this ‘Open Source’? No” และอธิบายว่าการใช้ clause นี้ทำให้ซอฟต์แวร์ผ่านหลายองค์ประกอบของนิยามโอเพนซอร์ส แต่ไม่ผ่านครบทุกข้อ จึงไม่ควรเรียกว่าโอเพนซอร์ส ความแตกต่างนี้มีผลโดยตรงต่อการที่องค์กรหรือผู้ใช้ตัดสินใจเชื่อถือซอฟต์แวร์ ซึ่งสอดคล้องกับบทความ ข้อผิดพลาดที่พบบ่อยเกี่ยวกับการอนุญาตใช้งานซอฟต์แวร์โอเพนซอร์ส ที่กล่าวถึงความสับสนระหว่าง “โอเพนซอร์ส” กับ “source available” ไว้อย่างชัดเจน

วิกฤตทรัพย์สินร่วม: เมื่อโค้ดเปิดเผยแต่ไม่มีใครตรวจ

Bitcoin Magazine วิเคราะห์ว่า เสรีภาพ 4 ประการเป็นแกนปรัชญาของโอเพนซอร์ส แต่ในทางปฏิบัติ เสรีภาพเหล่านี้ตั้งอยู่บนสมมติฐานทางเศรษฐศาสตร์ข้อหนึ่ง นั่นคือ จะมีคนจำนวนมากพอที่มีแรงจูงใจเพียงพอจะตรวจสอบโค้ดจริง ๆ เมื่อสมมติฐานนี้ล้มเหลว ระบบจะสร้าง “วิกฤตทรัพย์สินร่วม” (tragedy of the commons) ขึ้น คือทรัพยากรที่ใช้ร่วมกันถูกใช้มากเกินไปหรือถูกทอดทิ้ง เพราะแต่ละคนเลือกทำตามผลประโยชน์ระยะสั้นของตัวเอง แทนที่จะทำเพื่อประโยชน์ระยะยาวของกลุ่ม

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

ตัวเลขจาก Coldcard กับ Trezor ที่สะท้อนการตรวจสอบจริง

Bitcoin Magazine รายงานว่า ในกรณีของ Coldcard จุดบกพร่องสำคัญด้าน entropy อยู่ในเฟิร์มแวร์ที่เปิดเผยต่อสาธารณะเป็นเวลาประมาณ 5 ปี ก่อนจะถูกโจมตีและค้นพบ บั๊กนี้เข้าสู่โค้ดเบสในช่วงการเขียนใหม่ครั้งใหญ่ในปี 2021 ซึ่งเป็นช่วงเดียวกับที่ลบโค้ดที่มาจาก GPL ออกจาก Trezor ซึ่งเป็นกระเป๋าฮาร์ดแวร์รายแรกและปัจจุบันเป็นอันดับสองในอุตสาหกรรม self-custody

ไลบรารี บทบาท ดาว (Stars) Forks
libngu ไลบรารีทดแทน trezor-crypto ใน Coldcard 7 น้อยกว่า 20
trezor-crypto ไลบรารีเดิมที่ถูกแทนที่ 512 212

ตัวเลขจาก Bitcoin Magazine แสดงให้เห็นว่า libngu ถูกใช้งานจริงในระบบ production มากว่า 5 ปี แต่มีคนติดดาวเพียง 7 ดาว และมีการ fork น้อยกว่า 20 ครั้ง เทียบกับ trezor-crypto ที่มีดาวถึง 512 ดวงและมี 212 forks ความแตกต่างของตัวเลขเหล่านี้สะท้อนถึงปริมาณการตรวจสอบจากชุมชนที่ต่างกันอย่างมีนัยสำคัญ ซึ่งเป็นปัจจัยที่นักพัฒนาควรนำไปประเมินก่อนเลือกใช้ไลบรารีใดในระบบของตน

Bitcoin Core กับแบบอย่างของวัฒนธรรมการตรวจสอบ

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

คำศัพท์ในการตรวจสอบโค้ด

ผู้ตรวจสอบใช้คำศัพท์เฉพาะ เช่น Concept ACK (ยอมรับเป้าหมาย), Approach ACK (ยอมรับทั้งเป้าหมายและวิธีการ), ACK พร้อม commit hash (ทดสอบและอนุมัติให้ merge), หรือ NACK (ไม่เห็นด้วย ซึ่งควรมีเหตุผลทางเทคนิคประกอบ) การเปลี่ยนแปลงที่กระทบ consensus ต้องผ่านเกณฑ์ที่สูงกว่ามาก มักต้องมี Bitcoin Improvement Proposal และการอภิปรายหลายปีใน bitcoin-dev mailing list และ IRC

โครงสร้างเงินทุนและช่องทางสาธารณะ

Bitcoin Magazine ระบุว่า ไม่มีชนชั้นพิเศษของ “Bitcoin Core developers” ความไว้วางใจเกิดจากการพิสูจน์ความสามารถอย่างต่อเนื่อง Maintainer มีอยู่เพื่อตรวจสอบและ merge โค้ด จัดการ release และคัดกรองเบื้องต้น แต่ผลงานที่ออกมาคือโค้ดโอเพนซอร์สล้วนที่ทุกคนตรวจสอบได้ ผู้ที่มี commit ถูก merge มักถูกเรียกว่า Bitcoin Core Contributors

แหล่งเงินทุนสำหรับงานนี้มาจากโครงสร้างไม่แสวงหากำไรและทุน เช่น Brink, OpenSats, Spiral มากกว่าที่จะมาจาก roadmap ของผลิตภัณฑ์เชิงพาณิชย์แบบดั้งเดิม การอภิปรายทางเทคนิคเกิดขึ้นแบบสาธารณะบน bitcoin-dev mailing list และช่อง #bitcoin-core-dev ใน Libera Chat ขณะที่ GitHub issues และ pull requests หลายอันมีประวัติคอมเมนต์ยาวนานหลายปี ผลลัพธ์คือวัฒนธรรมการพัฒนาที่ให้ความสำคัญกับความถูกต้องและการตรวจสอบได้ มากกว่าความเร็วหรือฟีเจอร์เชิงพาณิชย์

บทเรียนสำหรับทีมพัฒนาและผู้ใช้

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

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

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

อ่านเพิ่มเติม

← Previous
Next →

More Articles