แกะรากปัญหา: ข้ามกรอบความคิดแบบไบนารีและการยืนยันความน่าเชื่อถือ

ประเด็นสำคัญ: เบื้องหลังไบนารี่ การตรวจสอบความน่าเชื่อถือ

เมื่อผู้คนดาวน์โหลด Bitcoin Core ส่วนใหญ่จะทำเพียงไม่กี่คลิกเพื่อใช้งาน พวกเขาจะดาวน์โหลดไฟล์ไบนารี่สำเร็จรูป ยืนยันลายเซ็นดิจิทัล (หวังว่าจะทำ!) แล้วเริ่มรันโหนด Bitcoin สิ่งที่เห็นทันทีคือซอฟต์แวร์ที่ทำงานอยู่ แต่สิ่งที่ไม่เห็นคือระบบการสร้าง (build system) และกระบวนการมากมายที่ผลิตซอฟต์แวร์ตัวนี้ ระบบการสร้างที่สะท้อนหลักการของคริปโตในเรื่องการกระจายศูนย์ ความโปร่งใส และการตรวจสอบได้

เบื้องหลังการดาวน์โหลดนี้มีงานวิศวกรรมหลายปีที่ออกแบบมาเพื่อตอบคำถามง่ายๆ ว่า “ทำไมใครๆ จึงควรเชื่อซอฟต์แวร์นี้?” คำตอบคือ: คุณไม่ควรต้องเชื่อ คุณควรตรวจสอบได้

ในยุคที่การโจมตีซัพพลายเชนซอฟต์แวร์สร้างกระแสข่าวไปทั่วโลก ตั้งแต่แพ็กเกจ npm ถูกเจาะ ไลบรารีแฝงหลัง ร้านเซิร์ฟเวอร์ CI ที่ถูกโจมตี กระบวนการสร้าง Bitcoin Core คือโครงการแห่งระเบียบวินัยที่เงียบสงบ วิธีการของมันอาจดูช้าและซับซ้อน เมื่อเทียบกับความสะดวกสบายในการ “push to deploy” แต่เจตนาคือความปลอดภัยไม่ใช่ความสะดวกสบาย

ทำความเข้าใจกับระบบการสร้างของ Bitcoin Core

• หลักการของระบบการสร้าง Bitcoin Core
• การสร้างแบบทำซ้ำได้ (Reproducible Builds)
• ลดการพึ่งพาภายนอก
• ไม่มีการอัปเดตอัตโนมัติ
• การบูรณาการอย่างต่อเนื่อง (Continuous Integration)
• การปรับปรุงอย่างต่อเนื่อง

หลักการของระบบการสร้าง Bitcoin Core

เมื่อพูดถึงการกระจายศูนย์ของ Bitcoin หลายคนมักนึกถึงนักขุดโหนดและนักพัฒนา แต่การกระจายศูนย์ไม่ได้หยุดอยู่แค่ผู้เข้าร่วมโปรโตคอลเท่านั้น มันขยายไปถึงวิธีการสร้างและแจกจ่ายซอฟต์แวร์เอง

หนึ่งในหลักการสำคัญของระบบคริปโตคือ “อย่าเชื่อ จงตรวจสอบ” การรันโหนดด้วยตัวเองคือการตรวจสอบทุกบล็อกและธุรกรรมตามกฎฉันทามติ แต่ระบบการสร้างซอฟต์แวร์ให้โอกาสอีกชั้นของการตรวจสอบในระดับซอฟต์แวร์ Bitcoin คือเงินที่ไม่มีตัวกลางที่น่าเชื่อถือ และ Bitcoin Core ก็ถูกออกแบบให้เป็นซอฟต์แวร์ที่ไม่มีผู้สร้างที่ต้องไว้ใจ ระบบการสร้างจึงพยายามอย่างยิ่งว่าทุกคนที่ไหนก็สามารถสร้างไบนารี่ที่เหมือนกันกับของที่อยู่บนเว็บไซต์ bitcoincore.org ได้อย่างอิสระ

ปรัชญานี้ได้รับแรงบันดาลใจจากบทความปี 1984 ของ Ken Thompson เรื่อง Reflections on Trusting Trust ที่เตือนว่าโค้ดดูสะอาดแต่ถ้าคอมไพเลอร์ที่ใช้สร้างถูกแทรกซึมหรือถูกโจมตี เราก็ไม่ควรเชื่อ นักพัฒนาของ Bitcoin นำบทเรียนนี้มาใช้จริง Michael Ford (fanquake) หนึ่งในผู้ร่วมพัฒนา Bitcoin Core ได้กล่าวไว้ว่า:

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

นี่คือเป้าหมายทางเทคนิคและเป็นส่วนหนึ่งของจิตวิญญาณคริปโต

ในโลกความปลอดภัยมีคำพูดเกี่ยวกับ “พื้นผิวการโจมตี (attack surfaces)” ระบบการสร้าง Bitcoin Core ก็ถือว่ากระบวนการสร้างซอฟต์แวร์คือพื้นผิวการโจมตีที่ต้องลดและป้องกันให้ได้มากที่สุด

การสร้างแบบทำซ้ำได้: การตรวจสอบจากต้นทางถึงปลายทาง

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

“บุคคลที่เชื่อถือไม่ได้คือช่องโหว่ด้านความปลอดภัย” — Nick Szabo (2001)

เพื่อแก้ปัญหานี้ Bitcoin Core ใช้ระบบการสร้างที่พัฒนาโดยใช้ Guix ตัวจัดการแพ็กเกจที่ออกแบบมาเพื่อสร้างสภาพแวดล้อมซอฟต์แวร์ที่ทำซ้ำและมีความแน่นอน

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

จากนั้นผู้ร่วมพัฒนาจะลงนามด้วยลายเซ็นเชิงลึกและเผยแพร่ลายเซ็นเหล่านั้นบนที่เก็บข้อมูล GitHub ชื่อ ‘guix.sigs’ ที่เป็นการยืนยันสำหรับแต่ละรุ่นของ Bitcoin Core บางคนคือทีมผู้พัฒนา แต่ก็เปิดรับคนทั่วไปไม่จำเป็นต้องเขียนโค้ด บ่อยครั้งที่ผู้ร่วมลงนามไม่ได้เขียนโปรแกรมเลย

กระบวนการนี้เรียกว่าการสร้างแบบทำซ้ำได้ (reproducible builds) เป็นทางป้องกันการ “ trusting trust” ของ Thompson หมายความว่าใครก็สามารถนำซอร์สโค้ดเดียวกัน ใช้สภาพแวดล้อม Guix เดียวกัน และยืนยันได้ว่าไบนารี่ที่เป็นทางการตรงกับที่ตนสร้างเอง ในขณะที่การสร้างแบบทำซ้ำได้ยืนยันว่าซอฟต์แวร์ตรงกับซอร์สโค้ด แต่ความถูกต้องของซอฟต์แวร์ต้องขึ้นกับการทดสอบและทบทวนโค้ดอย่างละเอียด

ส่วนใหญ่ผู้ใช้อาจไม่เคยคอมไพล์เต็มรูปแบบ ตรวจสอบไฟล์ Guix หรือตรวจสอบฮัชของการสร้าง แต่แค่องค์กรและทีมงานที่ดูแลระบบนี้ก็ช่วยเสริมความมั่นใจที่ได้มาหลายชั้น

ไบนารี่ที่เป็นทางการบน bitcoincore.org ไม่ใช่แค่ไฟล์ที่ “ผลิตโดยทีม Bitcoin Core” เท่านั้น แต่คือการรวบรวมผลลัพธ์จากผู้สร้างอิสระหลายสิบราย ทุกอย่างที่ผู้ใช้ดาวน์โหลดคือสิ่งที่คนอื่นสร้างและตรวจสอบว่าแท้จริง

นี่คือการตรวจสอบจากต้นทางถึงปลายทางอย่างแท้จริง

ลดการพึ่งพาภายนอก: ลดสิ่งที่ต้องเชื่อถือ

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

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

ทำไม? เพราะการใช้ไลบรารีหรือเครื่องมือภายนอกเพิ่มความซับซ้อน ใส่สมมติฐานที่เราไม่รู้จัก ทุกสิ่งที่เพิ่มเข้ามาคือความเสี่ยงในซัพพลายเชน โค้ดที่ไม่ได้เขียนเอง ตรวจสอบไม่ได้ และควบคุมไม่ได้ การลดการพึ่งพาจึงทำให้ระบบการสร้าง lean, ปลอดภัย และตรวจสอบง่ายขึ้น

Brink ได้สรุปความสำคัญนี้ในบล็อกโพสต์ “Minimizing Dependencies” [1] ที่บอกว่าไม่ใช่เพียงเรื่องง่าย แต่เป็นเรื่องการรักษาความปลอดภัยและเอกราชของโปรเจกต์ ทุกครั้งที่ตัดไลบรารีออกคือการลดจำนวนผู้ที่ต้องไว้ใจและลดความเสี่ยงการฝังหลัง

เป้าหมายสุดท้ายคือการผลิตไบนารีแบบสแตติกเต็มรูปแบบ (fully static binaries) ที่มีทุกอย่างในตัว ไม่ต้องพึ่งพาไลบรารีแบบไดนามิกหรือรันไทม์ ซึ่งช่วยลดปัญหาความแตกต่างของระบบปฏิบัติการ

ในโลกที่ซอฟต์แวร์โดยทั่วไปหนักและพึ่งพาซัพพอร์ตจากแพ็กเกจกลาง Bitcoin Core กำลังเดินสวนทางไปสู่ความเรียบง่ายและเอกราช

ไม่มีระบบอัปเดตอัตโนมัติ

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

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

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

การบูรณาการอย่างต่อเนื่อง: ช้าแต่มั่นคง

ใน Silicon Valley แนวทาง CI/CD คือการพัฒนาแบบคล่องแคล่ว เร็ว และอัตโนมัติ แต่ Bitcoin Core เดินต่างทาง ระบบ CI ของโปรเจกต์ไม่ใช้เพื่อเร่งการปล่อยรุ่น แต่เพื่อปกป้องความสมบูรณ์ของซอฟต์แวร์ การสร้างอัตโนมัติช่วยทดสอบความเข้ากันได้หลายแพลตฟอร์ม ระบบการสร้างรองรับ Linux, macOS, Windows รวมถึงสถาปัตยกรรม x86_64, aarch64 (ARM) และ riscv64

ระบบ CI ทำหน้าที่ประกันคุณภาพและความสอดคล้องด้วยการทดสอบหลายร้อยรายการต่อแต่ละการเปลี่ยนแปลง

การบูรณาการอย่างต่อเนื่องในที่นี้หมายถึงการทดสอบ ตรวจสอบ และรักษาความปลอดภัยอย่างต่อเนื่อง ไม่ใช่การพัฒนาด่วนเร็ว

“ช้าๆ แต่มั่นคงแก้ไขทุกอย่าง”

การปรับปรุงอย่างต่อเนื่อง: ยังไม่จบนะ

ระบบการสร้างไม่ใช่สิ่งที่ตายตัว นักพัฒนายังคงพัฒนาต่อโดยลดไลบรารีภายนอก ปรับปรุงการสร้างที่ครอบคลุมหลายสถาปัตยกรรม และมุ่งสู่ไบนารีแบบสแตติกรันไทม์ฟรี

แม้ Bitcoin Core จะมุ่งสู่ความแน่นอนในการสร้าง แต่ระบบการสร้างเองต้องมีการเปลี่ยนแปลงตลอดเวลาเพื่อตอบรับโลกที่เปลี่ยนไป เช่น ระบบปฏิบัติการ คอมไพเลอร์ ไลบรารี และสถาปัตยกรรมฮาร์ดแวร์ที่เปลี่ยนแปลง

แต่ละเวอร์ชันใหม่ของ macOS หรือ glibc การเลิกใช้คอมไพเลอร์ฟล็ากใหม่ หรือสถาปัตยกรรม CPU ใหม่ๆ ก่อให้เกิดปัญหาที่ต้องแก้ไข เพื่อไม่ให้กระบวนการสร้างล้มเหลว

ความย้อนแย้งของ reproducible builds คือการต้องผันแปรอย่างต่อเนื่องเพื่อให้ยังคงสร้างซ้ำได้ ทีมทำหน้าที่คงเครื่องมือ ปรับแพตซ์ และกระทั่งเปลี่ยนเครื่องมือเพื่อรักษาความเที่ยงตรงท่ามกลางความเปลี่ยนแปลงนี้ ความสมดุลระหว่างความเสถียรและการปรับตัวนี้คือส่วนหนึ่งของความยืดหยุ่นของคริปโต

ติดตามข้อมูลเพิ่มเติมเกี่ยวกับคริปโต

ศึกษาข้อมูลเหรียญคริปโตเพิ่มเติมได้ที่ เว็บไซต์รวมข้อมูลเหรียญคริปโตและข่าวสารอัปเดต

อ้างอิงที่มา

บทความนี้ได้รับแรงบันดาลใจและแปลจาก Bitcoin Magazine: The Core Issue — Beneath The Binary, Verifying Trust โดย Mike Schmidt

คำถามที่พบบ่อย (FAQ)

1. ทำไมระบบการสร้าง Bitcoin Core ถึงสำคัญสำหรับคริปโต?

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

2. ระบบสร้างแบบทำซ้ำได้ (Reproducible Builds) คืออะไร?

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

3. ทำไม Bitcoin Core ไม่ใช้ระบบอัปเดตอัตโนมัติ?

เพราะระบบอัปเดตอัตโนมัติสร้างจุดศูนย์กลางของการควบคุม ซึ่งขัดกับหลักการกระจายศูนย์ของคริปโต Bitcoin Core จึงให้ผู้ใช้เลือกอัปเดตและตรวจสอบด้วยตัวเอง เพื่อสร้างความมั่นใจและความโปร่งใส

4. Bitcoin Core มีมาตรการอย่างไรในการลดความเสี่ยงจากไลบรารีภายนอก?

โดยลดและแทนที่ไลบรารีภายนอกที่ไม่จำเป็น เช่น OpenSSL, MiniUPnP และ Boost ด้วยตัวเลือกที่ง่ายขึ้นหรือภายในตัว เพื่อทำให้ระบบการสร้าง lean และปลอดภัย

5. ทำไมการบูรณาการอย่างต่อเนื่อง (CI) ของ Bitcoin Core ถึงช้าแต่มั่นคง?

เนื่องจาก CI ของ Bitcoin Core มุ่งเน้นที่การรักษาความสมบูรณ์และความปลอดภัยของซอฟต์แวร์ ไม่ใช่เร่งความเร็วในการปล่อยรุ่น จึงทำการทดสอบละเอียดและครอบคลุมแทน