SegWit คืออะไร ทำไมต้อง "แยก" Signature ออกจาก Transaction ของ Bitcoin ทุกรายการ

บทความนี้เป็น Optional เจาะลึกจาก ใครควบคุม Bitcoin กันแน่? สงคราม Blocksize War และสุสานเหรียญที่พยายามแทนที่มัน อ่านเดี่ยวๆ ได้ แต่แนะนำให้อ่านประกอบถ้าอยากรู้บริบทการเมืองทั้งหมดของสงคราม

ลองสังเกตที่อยู่กระเป๋า Bitcoin ครั้งต่อไป จะพบว่ามันไม่ได้ขึ้นต้นเหมือนกันหมด บางที่อยู่ขึ้นต้นด้วยเลข "1" บางที่ขึ้นต้นด้วยเลข "3" และที่อยู่ที่เห็นบ่อยขึ้นเรื่อยๆ ช่วงหลังจะขึ้นต้นด้วย "bc1" ความต่างนี้ไม่ใช่เรื่องความสวยงามหรือเวอร์ชันของกระเป๋าที่ใช้ แต่คือร่องรอยของการอัปเกรดโครงสร้างพื้นฐานครั้งใหญ่ที่สุดครั้งหนึ่งของ Bitcoin ที่ชื่อ SegWit ซึ่งเปลี่ยนวิธีที่ธุรกรรม Bitcoin แทบทุกรายการทำงานมาตั้งแต่ปี 2017 โดยที่ผู้ใช้ส่วนใหญ่ไม่เคยรู้ตัวว่ามันเกิดขึ้น

ที่บทความหลักของซีรีส์นี้เล่า Blocksize War ไว้แล้วว่าเป็นสงครามการเมืองระหว่างฝั่งอยากขยายขนาดบล็อกตรงๆ (Big Block) กับฝั่งเลือกทางแก้ซับซ้อนกว่าแต่ปลอดภัยกว่า (Small Block) สิ่งที่บทความหลักไม่ได้ลงรายละเอียดคือ ทางแก้ที่ฝั่ง Small Block เลือกใช้คืออะไร ทำงานยังไง และทำไมถึงกลายเป็นจุดชนวนที่ทำให้สงครามยืดเยื้อเกือบสองปี บทความนี้จะพาไปรื้อดูตัว SegWit เอง ตั้งแต่ปัญหาที่ถูกออกแบบมาแก้ กลไกทางเทคนิคที่แท้จริง ไปจนถึงการเมืองเบื้องหลังที่เฉียดฉิวกว่าที่หลายคนรู้

SegWit คืออะไร กันก่อน

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

ภาพ: เทียบโครงสร้างธุรกรรมแบบเดิมที่รวมข้อมูลลายเซ็นไว้ก้อนเดียวกับข้อมูลธุรกรรม กับธุรกรรมแบบ SegWit ที่แยกข้อมูลลายเซ็นออกไปเป็นส่วน witness ต่างหาก

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

ปัญหาที่ 1: Transaction Malleability ปัญหาที่ฟังดูเล็กแต่ปิดประตู Lightning Network ไปเลย

ก่อนปี 2017 ธุรกรรม Bitcoin ทุกรายการมีจุดอ่อนทางเทคนิคจุดหนึ่งที่เรียกว่า transaction malleability (แปลตรงตัวประมาณ "ความสามารถในการถูกดัดแปลงได้ของธุรกรรม") อธิบายง่ายๆ คือ ธุรกรรม Bitcoin แต่ละรายการมี ID ประจำตัวที่คำนวณมาจากข้อมูลทั้งหมดในธุรกรรมนั้น รวมถึงข้อมูลลายเซ็นด้วย ปัญหาคือส่วนลายเซ็นสามารถถูกดัดแปลงเล็กน้อยได้โดยที่ลายเซ็นยังคงถูกต้องตามกฎเหมือนเดิมทุกประการ (ยืนยันได้ว่าเจ้าของอนุญาตจริง) แต่พอข้อมูลลายเซ็นเปลี่ยน ID ของธุรกรรมทั้งรายการก็เปลี่ยนตามไปด้วย ทั้งที่เนื้อหาจริงของธุรกรรม (ใครจ่ายให้ใคร จำนวนเท่าไร) ไม่ได้เปลี่ยนแปลงเลยสักนิด

ฟังดูเหมือนเรื่องจุกจิกไม่มีผลอะไร แต่ปัญหานี้ทำลายสมมติฐานสำคัญข้อหนึ่งที่ระบบที่ต้องอ้างอิง ID ธุรกรรมล่วงหน้าต้องพึ่งพา นั่นคือ Lightning Network ระบบ payment channel ที่ทั้งสองฝ่ายเปิดช่องทางจ่ายเงินกันไปมาแบบออฟเชนได้หลายรอบ โดยอาศัยธุรกรรมที่อ้างอิง ID ของธุรกรรมก่อนหน้าเป็นห่วงโซ่ต่อกัน ถ้า ID ของธุรกรรมสามารถถูกเปลี่ยนได้โดยไม่ต้องรู้ private key ของใครเลย ฝ่ายตรงข้าม (หรือใครก็ตามที่ดักดูธุรกรรมอยู่บนเครือข่าย) ก็อาจจะดัดแปลง ID แล้วทำให้ห่วงโซ่ที่อ้างอิงกันพังลง กลายเป็นช่องโหว่ที่ทำให้สร้างระบบ payment channel แบบ trustless (ไม่ต้องเชื่อใจอีกฝ่าย) ไม่ได้เลยในทางปฏิบัติ

ภาพ: อธิบายปัญหา transaction malleability ว่าการดัดแปลงลายเซ็นเล็กน้อยโดยที่ยังถูกต้องตามกฎสามารถเปลี่ยน ID ธุรกรรมได้ทั้งที่ผู้จ่าย ผู้รับ และจำนวนเงินไม่เปลี่ยนเลย ซึ่งเป็นช่องโหว่ที่ทำลายห่วงโซ่ธุรกรรมแบบ Lightning Network

ปัญหาที่ 2: Quadratic Sig-Hashing ยิ่งธุรกรรมซับซ้อน ยิ่งตรวจช้าแบบไม่เป็นเส้นตรง

ปัญหาที่สองซึ่งเทคนิคกว่าและเป็นเหตุผลเชิงวิศวกรรมล้วนๆ คือวิธีที่ Bitcoin คำนวณค่า hash ของลายเซ็นในธุรกรรมที่มี input (แหล่งเงินที่นำมาใช้) หลายรายการ ระบบเดิมต้องคำนวณ hash ใหม่ทั้งก้อนซ้ำแล้วซ้ำเล่าสำหรับทุก input ที่ต้องตรวจสอบ ทำให้เวลาที่ใช้ตรวจสอบเพิ่มขึ้นแบบ กำลังสอง (quadratic) เทียบกับขนาดของธุรกรรม ไม่ใช่เพิ่มแบบเป็นเส้นตรงตามสัดส่วน

พูดให้เห็นภาพคือ ถ้าธุรกรรมมี input เพิ่มเป็นสองเท่า เวลาตรวจสอบไม่ได้เพิ่มเป็นสองเท่าตาม แต่เพิ่มขึ้นถึงสี่เท่า ปัญหานี้ทำให้ธุรกรรมขนาดใหญ่มากๆ กลายเป็นความเสี่ยงด้าน "denial of service" ทางทฤษฎีได้ เพราะใครก็ตามที่สร้างธุรกรรมซับซ้อนพอ อาจทำให้โหนดทั่วเครือข่ายต้องเสียเวลาคำนวณตรวจสอบนานผิดปกติ SegWit แก้ปัญหานี้ไปพร้อมกันด้วยวิธีคำนวณ sig-hash แบบใหม่ที่ไม่ต้องคำนวณซ้ำข้อมูลเดิมทุกรอบ ทำให้เวลาตรวจสอบกลับมาเพิ่มแบบเส้นตรงตามขนาดธุรกรรมตามปกติ

ภาพ: กราฟเทียบเวลาตรวจสอบธุรกรรมที่เพิ่มขึ้นแบบกำลังสองในระบบเดิม กับที่ SegWit แก้ให้กลับมาเพิ่มแบบเส้นตรงตามขนาดธุรกรรมตามปกติ

กลไกจริง: "แยก" ยังไง แล้วทำไมได้พื้นที่เพิ่มโดยไม่ต้อง Hardfork

หัวใจของ SegWit คือการย้ายข้อมูลลายเซ็นออกจากโครงสร้างธุรกรรมหลัก ไปเก็บไว้ในส่วนที่เรียกว่า "witness" ต่างหาก ซึ่งอยู่นอกขอบเขตการคำนวณ ID ธุรกรรมแบบเดิม ผลคือ ID ธุรกรรมจะคำนวณจากข้อมูลที่ไม่รวมลายเซ็นอีกต่อไป ต่อให้มีใครดัดแปลงรูปแบบข้อมูลลายเซ็นยังไง ID ธุรกรรมก็จะไม่เปลี่ยน แก้ปัญหา malleability ได้จากรากเลย

ส่วนเรื่องขนาดบล็อก ระบบเดิมของ Bitcoin จำกัดขนาดบล็อกไว้ที่ 1 MB นับทุกไบต์เท่ากันหมด ไม่ว่าจะเป็นข้อมูลธุรกรรมหรือข้อมูลลายเซ็น SegWit เปลี่ยนวิธีนับใหม่ทั้งหมด แทนที่จะนับเป็น "ไบต์" มันนับเป็นหน่วยที่เรียกว่า weight unit (WU) โดยกำหนดว่าข้อมูลส่วนที่ไม่ใช่ witness นับเป็น 4 WU ต่อไบต์ ส่วนข้อมูล witness ที่แยกออกไปแล้วนับแค่ 1 WU ต่อไบต์ (ถูกกว่าถึง 4 เท่า) แล้วตั้งเพดานรวมไว้ที่ราว 4 ล้าน weight unit ต่อบล็อก แทนเพดาน 1 MB แบบเดิม

ผลลัพธ์คือ เนื่องจากข้อมูลลายเซ็นมักกินสัดส่วนราวครึ่งหนึ่งของธุรกรรมทั่วไป และตอนนี้ข้อมูลส่วนนั้นถูก "ลดราคา" ลง 4 เท่าในการนับพื้นที่ บล็อกหนึ่งบล็อกจึงจุธุรกรรมได้มากขึ้นจริงในทางปฏิบัติ คิดเป็น capacity ที่มีผลราวๆ 2 MB ต่อบล็อก แม้จะไม่ใช่ตัวเลข 2 MB ตายตัวเป๊ะๆ ก็ตาม (ขึ้นกับสัดส่วนข้อมูล witness ต่อธุรกรรมในแต่ละบล็อกจริง)

จุดที่ฉลาดที่สุดของกลไกนี้คือ มันทำทั้งหมดนี้ผ่าน softfork ไม่ใช่ hardfork เปรียบเหมือนเปลี่ยนสีปกสมุดบัญชีแต่ข้อมูลข้างในยังอ่านร่วมกันได้ โหนดเก่าที่ไม่อัปเกรดยังคงมองเห็นธุรกรรม SegWit เป็นธุรกรรมที่ถูกต้องอยู่ ไม่ต้องบังคับทุกคนอัปเกรดพร้อมกันเหมือน hardfork ซึ่งเป็นเหตุผลสำคัญที่ฝั่ง Small Block เลือกทางนี้แทนการขยายขนาดบล็อกแบบตรงไปตรงมา เทคนิคที่ทำให้ softfork แบบนี้เป็นไปได้เป็นแนวคิดของ Luke Dashjr นักพัฒนา Bitcoin Core

ภาพ: เทียบเพดานความจุบล็อกแบบเดิมที่ 1 MB กับระบบนับ weight unit ของ SegWit ที่ลดราคาข้อมูลลายเซ็นลง 4 เท่า ทำให้บล็อกจุธุรกรรมได้มากขึ้นจริงในทางปฏิบัติโดยไม่ต้อง Hardfork

ทำไม SegWit ถึงเป็นเงื่อนไขที่ Lightning Network ขาดไม่ได้

ย้อนกลับไปที่ปัญหา malleability ที่เล่าไปก่อนหน้า นี่คือจุดที่ SegWit เชื่อมโยงโดยตรงกับ Lightning Network ระบบ scaling ชั้นสอง (layer-two) ที่ถูกอธิบายไว้ครั้งแรกในเปเปอร์ของ Joseph Poon และ Thaddeus Dryja ช่วงต้นปี 2015 แนวคิดของ Lightning คือให้สองฝ่ายเปิดช่องทางจ่ายเงินกันไปมาได้หลายรอบแบบออฟเชน โดยใช้ blockchain หลักเป็นแค่กลไกสำรองไว้ตัดสินข้อพิพาทถ้าฝ่ายใดฝ่ายหนึ่งโกง ไม่ใช่บันทึกทุกธุรกรรมย่อยลงเชนโดยตรง

ปัญหาคือระบบแบบนี้ต้องอาศัยการอ้างอิง ID ธุรกรรมล่วงหน้าเป็นห่วงโซ่ต่อเนื่องกัน ถ้า ID ธุรกรรมยังถูกดัดแปลงได้แบบที่ปัญหา malleability เปิดช่องไว้ ทั้งระบบก็เสี่ยงพังได้ตลอดเวลาโดยไม่ต้องมีใครขโมย private key เลยด้วยซ้ำ พูดง่ายๆ คือ การแก้ปัญหา malleability ไม่ใช่แค่ "ฟีเจอร์เสริม" ของ SegWit แต่เป็น เงื่อนไขทางเทคนิคที่จำเป็น ก่อนที่ Lightning Network จะสร้างขึ้นมาใช้งานจริงแบบ trustless ได้เลย

ในช่วงปี 2015-2016 ระหว่างที่สงคราม Blocksize War กำลังดุเดือด ร้านค้าออนไลน์รายใหญ่หลายเจ้าเริ่มรับ Bitcoin เป็นช่องทางจ่ายเงินบนเชนโดยตรงมากขึ้น แต่ภายหลังพิสูจน์ว่าโมเดลนี้เปราะบางเมื่อค่าธรรมเนียมธุรกรรมพุ่งสูงขึ้นตามความหนาแน่นของเครือข่าย จนร้านค้าจำนวนมากถอดช่องทางจ่ายด้วย Bitcoin ออกไปในที่สุด เหตุการณ์นี้ยิ่งตอกย้ำว่าทำไมการรอ Lightning Network (ที่อาศัย SegWit เป็นฐาน) ถึงสำคัญสำหรับอนาคตการใช้งาน Bitcoin ในชีวิตประจำวันแบบค่าธรรมเนียมต่ำ แม้ในตอนนั้นฝั่ง Big Block จะมองว่า Lightning เป็นเพียงข้ออ้างถ่วงเวลาที่ยังพิสูจน์ไม่ได้จริงก็ตาม

ภาพ: กลไก payment channel ของ Lightning Network ที่สองฝ่ายจ่ายเงินกันไปมาได้หลายรอบแบบออฟเชน แล้วค่อยบันทึกลงบล็อกเชนจริงแค่ตอนเปิดหรือปิดช่องทาง ซึ่งต้องอาศัยการแก้ปัญหา malleability จาก SegWit ก่อนถึงจะทำได้

การเมืองเบื้องหลัง: ทำไมไอเดียที่เสนอปี 2015 กว่าจะปล่อยจริงต้องรอนานกว่า 10 เดือน

หมายเหตุ: เนื้อหาในหัวข้อนี้เรียบเรียงจากบทที่ 5 ของหนังสือ The Blocksize War (Jonathan Bier) ซึ่งเป็นการสรุปความ ไม่ใช่การอ้างคำต่อคำจากต้นฉบับ

SegWit ไม่ได้เป็นแค่โจทย์วิศวกรรมล้วนๆ มันมีเส้นเรื่องการเมืองที่ยาวและซับซ้อนไม่แพ้ตัวเทคนิคเอง ตามที่เล่าไว้ในหนังสือ The Blocksize War งานประชุม Scaling Bitcoin ที่ฮ่องกงในเดือนธันวาคม 2015 คือจุดที่ Pieter Wuille นักพัฒนา Bitcoin Core นำเสนอ SegWit ต่อสาธารณะเป็นครั้งแรก ในวันที่สองของงาน โดยเสนอเป็นทางออกที่ให้ทั้งการแก้ malleability และเพิ่ม capacity ไปพร้อมกันโดยไม่ต้อง hardfork

แต่กว่าโค้ด SegWit จะถูกปล่อยจริงเข้าไปใน Bitcoin Core ก็ต้องรอจนถึงเดือนพฤศจิกายน 2016 หนังสือเรียกช่วงรอนี้ตรงๆ ว่า "นานกว่า 10 เดือน" นับจากวันนำเสนอ (นับตามปฏิทินคือเกือบ 11 เดือน) ความล่าช้านี้เองคือสิ่งที่ฝั่ง Big Block หยิบมาโจมตี พวกเขามองว่าความซับซ้อนของกลไก SegWit (ที่แม้แต่นักพัฒนาระดับสูงบางคนยังตีความผิดในช่วงแรก) บวกกับชื่อที่ฟังดูงงๆ สำหรับคนทั่วไป คือสัญญาณของกลยุทธ์ถ่วงเวลาโดยเจตนา ไม่ใช่แค่ความซับซ้อนทางเทคนิคที่หลีกเลี่ยงไม่ได้

อีกจุดที่กลายเป็นข้อถกเถียงร้อนแรงคือเกณฑ์การเปิดใช้งาน (activation threshold) SegWit ถูกตั้งเกณฑ์ไว้สูงถึง 95% ของ miner signal ภายใน 2,016 บล็อก พร้อมช่วงผ่อนผันอีก 2 สัปดาห์หลังถึงเกณฑ์ และถ้าครบ 12 เดือนแล้วยังไปไม่ถึง 95% ก็จะยกเลิกความพยายามทั้งหมด เกณฑ์นี้สูงกว่า 75% ที่ Bitcoin XT และ Bitcoin Classic ใช้มากอย่างเห็นได้ชัด ฝั่ง Big Block จึงมองว่าไม่มีทางที่โลกจริงจะได้ฉันทามติ 95% กับเรื่องอะไรได้ นักขุดกลุ่มเล็กๆ แค่ 5% ก็ยับยั้งการเปลี่ยนแปลงได้ง่ายเกินไป และเมื่อเทียบกับเกณฑ์ 75% ที่ฝั่งตัวเองเคยเสนอ ก็ยิ่งมองว่าเป็นมาตรฐานสองชั้นที่ตั้งใจกีดกัน

ภาพ: เทียบเกณฑ์ signal ที่ SegWit ใช้ 95% กับที่ Bitcoin XT และ Classic เคยเสนอไว้แค่ 75% พร้อมชี้ว่าเกณฑ์ 95% นี้สานต่อมาตรฐานเดิมที่ softfork 3 ครั้งก่อนหน้าเคยใช้ ไม่ใช่การตั้งเกณฑ์ใหม่เพื่อสกัด SegWit โดยเฉพาะ

แต่เกณฑ์ 95% ไม่ได้ถูกเลือกมาลอยๆ ตามที่หนังสือเล่าไว้ softfork สามครั้งล่าสุดก่อนหน้า SegWit ก็ใช้เกณฑ์ 95% เหมือนกันทั้งหมด คือ BIP 66 (จำกัดรูปแบบลายเซ็นให้เป็น DER encoding) เดือนกรกฎาคม 2015, BIP 65 (Check Lock Time Verify) เดือนธันวาคม 2015 และชุด BIP 68/112/113 เดือนกรกฎาคม 2016 ทีมพัฒนาจึงแค่สานต่อมาตรฐานเดิมที่เคยใช้มา ไม่ได้ตั้งขึ้นใหม่เฉพาะเจาะจงเพื่อสกัด SegWit ฝั่งที่มองว่าเป็น "safety feature" ไม่ใช่ "โหวตทางการเมือง" ก็มีเหตุผลรองรับอยู่บ้าง แม้จะฟังดูสวนทางสามัญสำนึกของฝั่ง Big Block ก็ตาม อย่างไรก็ตาม softfork ก่อนหน้าเหล่านี้ก็ไม่ได้ราบรื่นสมบูรณ์แบบเสมอไป ตอน BIP 66 เปิดใช้งานเดือนกรกฎาคม 2015 เกิดเหตุ chain split สั้นๆ อยู่ไม่กี่บล็อก เพราะนักขุดบางส่วนติดธงว่าอัปเกรดแล้วแต่จริงๆ ยังไม่ได้อัปเกรด ทำให้เกิดบล็อกที่ผิดกฎขึ้นมาชั่วครู่ ประวัติศาสตร์ตรงนี้เองที่ยิ่งตอกย้ำให้ฝั่ง Small Block อยากตั้งเกณฑ์ให้สูงและปลอดภัยไว้ก่อน

ในทางเทคนิคนี่คือของที่ออกแบบมาดี Jonathan Bier ผู้เขียนหนังสือ The Blocksize War สรุปย่อหน้าปิดของบทนี้ไว้สั้นๆ ตรงประเด็นว่า "While SegWit was engineering wizardry, it did little to calm tensions in the conflict." (แม้ SegWit จะเป็นความมหัศจรรย์ทางวิศวกรรม แต่มันแทบไม่ได้ช่วยลดความตึงเครียดของความขัดแย้งลงเลย) ของดีทางเทคนิคกับของที่การเมืองยอมรับได้ ไม่ใช่เรื่องเดียวกันเสมอไป

ภาพ: ไทม์ไลน์การเมืองเบื้องหลัง SegWit ตั้งแต่วันที่ Pieter Wuille นำเสนอที่ฮ่องกงปี 2015 ผ่านช่วงรอนานกว่า 10 เดือนก่อนปล่อยโค้ดจริง จนถึงวันเปิดใช้งานจริงบนเครือข่ายปี 2017

กว่าจะเปิดใช้งานจริง: จาก 95% ที่ไปไม่ถึง สู่แรงกดดันจากผู้ใช้

ปัญหาคือ ต่อให้โค้ด SegWit พร้อมใช้งานตั้งแต่ปลายปี 2016 เกณฑ์ 95% ก็ไปไม่ถึงสักที นักขุดจำนวนมาก (โดยเฉพาะฝั่งที่เกี่ยวข้องกับ Bitmain) ยังลังเลหรือคัดค้าน จนกระทั่งเกิดแรงกดดันจากฝั่งที่ไม่มีใครคาดคิด คือผู้ใช้ทั่วไปที่รัน full node เอง ผ่านแคมเปญ UASF (User-Activated Softfork) ที่กำหนดวันบังคับไว้ตายตัวว่าจะปฏิเสธบล็อกที่ไม่ signal รองรับ SegWit ตั้งแต่ 1 สิงหาคม 2017 ไม่ต้องรอ miner majority เห็นด้วยก่อน (เรื่องนี้บทความหลัก ใครควบคุม Bitcoin เล่าไว้แล้วว่าเป็นจุดพลิกของทั้งสงคราม จะไม่ลงรายละเอียดซ้ำที่นี่)

เมื่อเส้นตายของ UASF ใกล้เข้ามา ฝั่งนักขุดก็เริ่มยอมถอย นำไปสู่ข้อตกลง New York Agreement (NYA) ที่ประชุมกันเดือนพฤษภาคม 2017 ข้อความข้อตกลงระบุไว้ตรงๆ ว่า "Activate Segregated Witness at an 80% threshold, signaling at bit 4 / Activate a 2 MB hard fork within six months" (เปิดใช้ SegWit ที่เกณฑ์ 80% ส่งสัญญาณที่ bit 4 พร้อมสัญญาว่าจะ hardfork ขยายเป็น 2 MB ภายใน 6 เดือน) แต่ข้อตกลงนี้มีจุดบกพร่องทางเทคนิค คือ bit 4 ที่ระบุไว้ไม่สามารถเปิดใช้งาน SegWit ได้จริงตามกลไกที่วางไว้แต่แรก ทำให้ต้องมีข้อเสนอแก้ทางเทคนิคเพิ่มเติมที่ชื่อ BIP 91 ขึ้นมาเป็นทางออกที่เข้ากันได้กับทั้งฝั่ง UASF และฝั่งนักขุด

BIP 91 lock-in สำเร็จในวันที่ 21 กรกฎาคม 2017 และ SegWit ก็เปิดใช้งานจริงบนเครือข่าย Bitcoin ในเดือนสิงหาคม 2017 โดยไม่เกิด chain split ของสายหลัก เพียงไม่กี่วันก่อนเส้นตายที่ UASF ขีดไว้เท่านั้น จุดนี้คือสิ่งที่ผู้เขียนหนังสือ The Blocksize War ยกให้เป็นหลักฐานว่าภัยคุกคามจากฝั่งผู้ใช้ (ไม่ใช่นักขุด) ได้ผลจริงในทางปฏิบัติ ไม่ใช่แค่ท่าทีข่มขู่เฉยๆ

ภาพ: ข้อความจริงจาก New York Agreement เดือนพฤษภาคม 2017 ที่ตกลงเปิดใช้ SegWit ที่เกณฑ์ 80% พร้อมไทม์ไลน์ว่ากว่าจะเปิดใช้งานจริงได้สำเร็จก็เฉียดเส้นตายของ UASF ไปเพียงไม่กี่วัน

คนไทยเจอเรื่องแบบนี้มาแล้วจริง ตอนบัตร ATM เปลี่ยนจากแถบแม่เหล็กเป็นชิป

สิ่งที่ SegWit ทำกับ Bitcoin คือการเปลี่ยน "ท่อน้ำ" เบื้องหลังทั้งระบบ โดยคนใช้งานทั่วไปแทบไม่รู้สึกถึงความเปลี่ยนแปลง คนไทยเคยเจอเหตุการณ์ลักษณะเดียวกันมาก่อนแล้วจริงๆ กับบัตร ATM และบัตรเดบิต

ธนาคารแห่งประเทศไทยผลักดันให้ธนาคารพาณิชย์ทยอยเปลี่ยนบัตร ATM และบัตรเดบิตจากแถบแม่เหล็กเดิม มาเป็นแบบมีชิป (มาตรฐาน EMV) ตั้งแต่กลางปี 2559 กำหนดเส้นตายว่าหลังวันที่ 15 มกราคม 2563 บัตรแถบแม่เหล็กจะใช้กดเงินหรือรูดจ่ายไม่ได้อีกต่อไป เหตุผลหลักคือความปลอดภัย ชิปสร้าง "รหัสธุรกรรมแบบใช้ครั้งเดียว" ขึ้นใหม่ทุกครั้งที่ทำรายการ ยากต่อการปลอมแปลงหรือคัดลอกไปใช้ซ้ำ ต่างจากแถบแม่เหล็กเดิมที่ข้อมูลนิ่งอยู่กับที่ ใครมีเครื่องอ่านก็คัดลอกไปใช้ปลอมได้ง่าย

สังเกตให้ดีจะเห็นว่าโครงสร้างเรื่องนี้คล้าย SegWit ทั้งคู่คือการเปลี่ยนกลไกความปลอดภัยเบื้องหลังทั้งระบบ ไม่ใช่แค่แก้จุดเดียว ข้อมูลที่เคย "ตายตัวและถูกคัดลอกซ้ำได้" (แถบแม่เหล็ก เทียบได้กับลายเซ็นที่เคยเปลี่ยน ID ธุรกรรมได้) กลายเป็นข้อมูลปลอมแปลงไม่ได้อีกต่อไป และใช้เวลาเปลี่ยนผ่านเป็นปี ไม่ใช่ข้ามคืน คนถือบัตรส่วนใหญ่แค่เห็นบัตรใบใหม่หน้าตาคล้ายเดิม มีชิปสี่เหลี่ยมเล็กๆ เพิ่มมา ไม่รู้เบื้องหลังว่าการเข้ารหัสเปลี่ยนไปทั้งระบบ เหมือนคนใช้ Bitcoin ผ่านกระเป๋าที่อัปเดตอัตโนมัติ ที่แทบไม่รู้ตัวว่าธุรกรรมเปลี่ยนโครงสร้างไปแล้วตั้งแต่ปี 2017

ต้องย้ำให้ชัดว่านี่คือการเปรียบเทียบเชิงโครงสร้างของ "การอัปเกรดความปลอดภัยที่มองไม่เห็นแต่เปลี่ยนทั้งระบบ" เท่านั้น กลไกทางเทคนิคจริงต่างกันโดยสิ้นเชิง (SegWit แก้ปัญหา malleability ระดับโปรโตคอลกระจายศูนย์ ส่วนชิป EMV แก้ปัญหาการปลอมแปลงบัตรระดับอุปกรณ์ที่มีธนาคารกลางเป็นผู้บังคับใช้) ไม่ได้แปลว่าทั้งสองเรื่องเหมือนกันในรายละเอียด

ภาพ: เทียบการเปลี่ยนบัตร ATM ไทยจากแถบแม่เหล็กเป็นชิป EMV กับการเปลี่ยนที่อยู่ Bitcoin จาก "1" เป็น "bc1" ชี้ว่าทั้งคู่คือการอัปเกรดความปลอดภัยเบื้องหลังทั้งระบบที่ผู้ใช้ทั่วไปแทบไม่รู้ตัว

มรดกของ SegWit: ทำไมกระเป๋า/เว็บเทรดยุคนี้ตั้งค่าเริ่มต้นเป็น SegWit หรือใหม่กว่า

ผ่านมาเกือบสิบปีนับจากวันที่ SegWit เปิดใช้งานจริง วันนี้กระเป๋าเงินและเว็บเทรด Bitcoin ส่วนใหญ่ตั้งค่าเริ่มต้นให้สร้างที่อยู่แบบ SegWit (ที่อยู่ขึ้นต้น "3" สำหรับ SegWit แบบ wrapped หรือ "bc1" สำหรับ native SegWit / bech32) หรือใหม่กว่านั้นอย่าง Taproot (ที่อยู่ขึ้นต้น "bc1p") แทนที่ที่อยู่แบบเดิม (ขึ้นต้น "1") ที่เคยเป็นมาตรฐานเดียวในยุคแรก

เหตุผลหลักคือเรื่องค่าธรรมเนียม เพราะธุรกรรมที่ใช้ที่อยู่แบบ SegWit จะมีข้อมูลส่วนที่ถูกนับเป็น weight unit ราคาถูกกว่า (ข้อมูล witness นับแค่ 1 WU ต่อไบต์ เทียบกับ 4 WU ของข้อมูลส่วนอื่น) ทำให้ธุรกรรมแบบเดียวกันเสียค่าธรรมเนียมโดยเฉลี่ยถูกกว่าที่อยู่แบบเดิมอย่างมีนัยสำคัญ ผู้ให้บริการกระเป๋าเงินและ exchange ส่วนใหญ่จึงเปลี่ยนมาตั้งค่าเริ่มต้นเป็น SegWit กันหมด เพื่อประหยัดค่าธรรมเนียมให้ผู้ใช้โดยอัตโนมัติ โดยที่ผู้ใช้ส่วนใหญ่ไม่เคยต้องไปตั้งค่าอะไรเองเลย

พูดอีกแบบคือ ทุกครั้งที่มีคนส่ง Bitcoin ผ่านที่อยู่ "bc1..." โดยไม่รู้ตัวเลยว่าทำไมมันขึ้นต้นแบบนั้น นั่นคือผลลัพธ์ปลายทางของสงครามการเมืองที่ยืดเยื้อเกือบสองปี ของการถกเถียงทางเทคนิคเรื่อง malleability กับ weight unit และของการเผชิญหน้าครั้งประวัติศาสตร์ระหว่างนักขุดกับผู้ใช้ทั่วไปที่รัน node เองที่บทความหลักของซีรีส์นี้เล่าไว้ ทั้งหมดนี้ถูกบีบอัดกลายเป็นแค่ตัวอักษรสามตัวหน้าที่อยู่กระเป๋าเงินที่แทบไม่มีใครสังเกต

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

SegWit คืออะไร สรุปสั้นๆ?

SegWit (Segregated Witness) คือการอัปเกรดโปรโตคอล Bitcoin แบบ softfork ที่แยกข้อมูลลายเซ็นดิจิทัล (witness) ออกจากโครงสร้างธุรกรรมหลัก แก้ปัญหา transaction malleability เปิดทางให้ Lightning Network เกิดขึ้นได้ และเพิ่มความจุบล็อกได้จริงในทางปฏิบัติผ่านระบบนับ weight unit แบบใหม่ เปิดใช้งานจริงบนเครือข่าย Bitcoin เดือนสิงหาคม 2017

ที่อยู่ Bitcoin ที่ขึ้นต้นด้วย 1, 3 และ bc1 ต่างกันยังไง?

"1" คือที่อยู่แบบดั้งเดิม (Legacy) ก่อนมี SegWit "3" คือที่อยู่แบบ SegWit ที่ห่อ (wrapped) ให้กระเป๋าเก่าใช้งานร่วมได้ ส่วน "bc1" คือ native SegWit (bech32) ที่ประหยัดค่าธรรมเนียมสุดในกลุ่ม SegWit ส่วน "bc1p" คือ Taproot ที่ใหม่กว่า SegWit อีกขั้น

Transaction Malleability คืออะไร ทำไมถึงสำคัญ?

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

SegWit ทำให้ Bitcoin จุข้อมูลได้กี่ MB จริงๆ?

ไม่ใช่ตัวเลขตายตัว เพราะระบบนับเป็น weight unit (เพดานรวมราว 4 ล้าน WU ต่อบล็อก) ไม่ใช่ไบต์ตรงๆ อีกต่อไป แต่โดยเฉลี่ยแล้วให้ผลเทียบเท่า capacity ที่เพิ่มขึ้นราว 2 MB ต่อบล็อก ขึ้นกับสัดส่วนข้อมูล witness ในแต่ละบล็อกจริง

ทำไม SegWit ถึงใช้เวลานานมากกว่าจะเปิดใช้งานจริง?

เพราะตั้งเกณฑ์ miner signal ไว้สูงถึง 95% (สานต่อมาตรฐานเดิมที่ softfork 3 ครั้งก่อนหน้าเคยใช้ทั้งหมด) ประกอบกับความล่าช้าระหว่างวันนำเสนอ (ธ.ค. 2015) กับวันปล่อยโค้ดจริง (พ.ย. 2016) และแรงต้านจากฝั่งนักขุดบางส่วน จนต้องรอแรงกดดันจากแคมเปญ UASF ของผู้ใช้ก่อนถึงเปิดใช้งานจริงได้สำเร็จ

SegWit กับ UASF เกี่ยวข้องกันยังไง?

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

📖 เนื้อหาประวัติศาสตร์การเมืองในบทความนี้ (การนำเสนอ SegWit ที่ Scaling Bitcoin ฮ่องกง ธ.ค. 2015, ความล่าช้าถึงเดือน พ.ย. 2016, เกณฑ์ signal 95% ที่สืบทอดมาจาก softfork รุ่นก่อนหน้า, New York Agreement, BIP 91) เรียบเรียงและตรวจทานกับต้นฉบับจากหนังสือ The Blocksize War โดย Jonathan Bier นักวิเคราะห์จาก BitMEX Research หนังสือเล่มนี้เผยแพร่ฟรีเป็นซีรีส์บล็อกเต็มเล่มบน bitmex.com/blog และมีฉบับเต็มวางจำหน่ายบน Amazon (ผู้เขียนบริจาค 50% ของรายได้ให้ Médecins Sans Frontières) ส่วนคำอธิบายกลไกทางเทคนิคของ SegWit (witness data, weight unit, malleability, quadratic sig-hashing) เป็นความรู้พื้นฐานด้านโปรโตคอล Bitcoin ที่เป็นที่ยอมรับทั่วไป ไม่ได้ผูกกับแหล่งใดแหล่งหนึ่งโดยเฉพาะ