เมื่อคืนวันที่ 22 กันยายน ผู้ใช้รายหนึ่งได้ส่งธุรกรรมโอน ATOM

ผ่านไปหนึ่งคืน ธุรกรรมยังคงอยู่ในสถานะ "รอการยืนยัน"

Private key ไม่ได้หายไป และกระเป๋าเงินก็ไม่ได้แสดงความผิดปกติในการลงนาม เมื่อตรวจสอบอีกครั้งในวันถัดไป RPC สาธารณะหลายแห่งต่างแสดงว่า Cosmos Hub หยุดอยู่ที่ความสูงบล็อก 33,086,740

ไม่มีบล็อกใหม่เกิดขึ้น จึงไม่มีที่ใดสามารถนำธุรกรรมนี้ไปบรรจุเข้าไปได้

จนกระทั่งประมาณหนึ่งวันต่อมา Cosmos Hub กลับมาผลิตบล็อกได้อีกครั้ง ธุรกรรมโอน ATOM ที่ก่อนหน้านี้อยู่ในสถานะรอการยืนยันจึงสำเร็จในที่สุด

สำหรับผู้ใช้ทั่วไป นี่อาจเป็นบทเรียนที่ตรงที่สุดในการทำความเข้าใจฉันทามติของบล็อกเชน

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

การหยุดชะงักของ Cosmos Hub ในครั้งนี้ เปิดเผยกลไกที่ปกติซ่อนอยู่ใต้พื้นดินให้ผู้ใช้ทั่วไปได้เห็นอย่างครบถ้วน

1. ทำไม Cosmos จึง "หยุดผลิตบล็อก" อย่างกระทันหัน?

ก่อนอื่นต้องอธิบายประเด็นที่อาจทำให้สับสนว่า สิ่งที่ถูกโจมตีโดยตรงในครั้งนี้ไม่ใช่ Cosmos Hub

เหตุการณ์เริ่มต้นขึ้นที่ Neutron

เมื่อวันที่ 22 กันยายน ข้อเสนอการกำกับดูแลของ Neutron ชื่อ "AIATO: AI Agent Takeover" ได้รับการอนุมัติ ผู้โจมตีใช้ช่องโหว่ในอำนาจการกำกับดูแลระดับเชน ใช้คำสั่งพิเศษที่เฟรมเวิร์ก wasmd ให้มาโดยกำเนิด เปลี่ยนผู้ดูแลสัญญาของแอปพลิเคชันอย่าง Astroport และ Drop ให้เป็นที่อยู่ที่ผู้โจมตีควบคุม

นี่ไม่ใช่สิ่งที่เราเข้าใจกันทั่วไปว่าเป็น "ช่องโหว่ในโค้ด" หรือ "ข้อบกพร่องของโปรโตคอล"

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

แต่สิ่งที่ทำให้ Cosmos Hub ถูกพัวพันเข้าไปจริงๆ คือการโอนเงินข้ามเชนที่เกิดขึ้นตามมา

การทบทวนของ Cosmos Labs แสดงว่า ก่อนที่ Neutron จะหยุดทำงาน ผู้โจมตีได้โอนสินทรัพย์บางส่วนไปยังหลายเครือข่ายแล้ว โดยมี ATOM ประมาณ 1.7 ล้าน枚 ถูกโอนเข้า Cosmos Hub และเริ่มแลกเปลี่ยนผ่านสภาพคล่องข้ามเชน

กล่าวคือ Cosmos Hub เองไม่ได้ถูกโจมตีโดยตรง และเงินของผู้ใช้ Hub ทั่วไปก็ไม่ได้ถูกขโมยโดยตรงจากช่องโหว่ของ Neutron

แต่ ATOM ที่ได้จากการโจมตีได้เข้าสู่ Hub แล้ว เพื่อหยุดยั้งไม่ให้ ATOM ที่เหลือไหลออกต่อไป ผู้ตรวจสอบ Cosmos Hub บางส่วนจึงเริ่มหยุดรันโหนด

จนถึงประมาณ 19:18 น. ของวันที่ 22 กันยายน (เวลา SGT) ผู้ตรวจสอบที่หยุดรันได้คิดเป็นสัดส่วนเกินหนึ่งในสามของ voting power ทั้งหมดแล้ว Cosmos Hub จึงไม่สามารถสร้างบล็อกใหม่ต่อไปได้ และหยุดอยู่ที่ 33,086,740

ขั้นตอนนี้สำคัญมาก

มันหมายความว่า Cosmos Hub ไม่มี "ปุ่ม Pause" ที่บริษัทใดสามารถกดได้โดยตรง และไม่ได้ผ่านการลงคะแนนกำกับดูแลบนเชนก่อน สิ่งที่ทำให้เครือข่ายหยุดจริงๆ คือผู้ตรวจสอบจำนวนมากพอที่ไม่เข้าร่วมการสร้างฉันทามติอีกต่อไป

แต่สิ่งที่ควรให้ความสนใจมากกว่าคือกระบวนการกู้คืนหลังจากนั้น

ประมาณ 4 ชั่วโมงหลังเชนหยุด ผู้ตรวจสอบได้รับแผนการกู้คืนฉบับสมบูรณ์: ดำเนินการแก้ไขสถานะแบบครั้งเดียว ณ ความสูงที่เชนหยุด โดยโอน ATOM ที่เหลือในที่อยู่ของผู้โจมตีไปยังที่อยู่ multi-sig ที่บริหารร่วมกันโดยผู้ตรวจสอบในชุมชน

จากนั้น Cosmos Labs ได้สร้างแพตช์ Gaia v28.3.0 ตามแผนที่ผู้ตรวจสอบตกลงกันแล้ว ทดสอบ และแจกจ่ายให้ผู้ตรวจสอบ

Gaia เวอร์ชันนี้จะดำเนินการเปลี่ยนแปลงสถานะแบบครั้งเดียว ณ ความสูงการกู้คืนที่กำหนด โดยโอน 1,227,121 ATOM จากที่อยู่ของผู้โจมตีไปยังที่อยู่ multi-sig 4-of-6 ที่ประกอบด้วย Nansen, Keplr, Enigma, Silknodes, Kiln และ Polkachu

จนถึงเช้ามืดวันที่ 23 กันยายน ผู้ตรวจสอบที่ยืนยันการติดตั้ง v28.3.0 มีสัดส่วนเกิน 67% ของ voting power ทั้งหมด ดังนั้นเมื่อเวลา 12:00 UTC ของวันนั้น Cosmos Hub จึงประสานงานรีสตาร์ท ประมาณ 6 นาทีต่อมา การแก้ไขสถานะแบบครั้งนี้ได้ดำเนินการที่ความสูงบล็อก 33,086,741 และเครือข่ายกลับมาผลิตบล็อกได้ตามปกติ

กล่าวโดยสรุป ตลอดกระบวนการตั้งแต่ Cosmos หยุดผลิตบล็อกจนกลับมาทำงานได้ เป็นผู้ตรวจสอบที่ทำให้เครือข่ายสูญเสีย Liveness ก่อน จากนั้น voting power เกินสองในสามจึงยอมรับชุดกฎการเปลี่ยนสถานะใหม่ และสุดท้ายทำให้กฎชุดนี้กลายเป็น canonical state หลังการกู้คืน

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

คำตอบจริงๆ ซ่อนอยู่ในคำว่า "ฉันทามติ"

2. สิ่งที่เรียกว่าฉันทามติ ไม่เคยหมายถึง "ไม่มีวันหยุด"

สิ่งที่คนมักเข้าใจผิดมากที่สุดเกี่ยวกับบล็อกเชน คือการนำ "การกระจายอำนาจ" ไป equate กับ "ไม่มีวันดาวน์"

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

เพียงแต่ public chain ต่างๆ มีวิธีการบรรลุสิ่งนี้ไม่เหมือนกัน

เช่น Bitcoin ที่คลาสสิกที่สุดคือ PoW หรือ proof of work — นักขุดแข่งขันกันผลิตบล็อกด้วยพลังคำนวณ เมื่อเครือข่ายมีสองสาขาที่ถูกต้องปรากฏขึ้นในช่วงเวลาสั้น โหนดจะเลือกสาขาหนึ่งตามปริมาณงานสะสมเพื่อสร้างต่อไป

ดังนั้น Bitcoin จึงไม่มีช่วงเวลาที่ชัดเจนว่า "หลังจากโหวต 67% แล้วบล็อกนี้จะ Finalized ตลอดไป" มันใกล้เคียงกับความสมบูรณ์เชิงความน่าจะเป็นมากกว่า ยิ่งมีบล็อกตามหลังมากเท่าไร การจะจัดระเบียบธุรกรรมก่อนหน้าใหม่ก็ต้องใช้ต้นทุนพลังคำนวณสูงขึ้นเรื่อยๆ

นี่ก็เป็นเหตุผลที่คนมักพูดกันว่า ธุรกรรม Bitcoin ควรรอการยืนยัน 6 บล็อก เพราะถึงพลังคำนวณจะสูงแค่ไหน ก็ไม่สามารถข้ามกฎฉันทามติที่โหนดกำลังดำเนินการอยู่ได้ง่ายๆ

แน่นอน นี่ไม่ได้หมายความว่าสถานะของ Bitcoin "ไม่สามารถแก้ไขได้อย่างเด็ดขาด" ในทุกสถานการณ์ ในทางทฤษฎี หากระบบนิเวศทั้งหมดยอมรับไคลเอนต์ใหม่และกฎฉันทามติใหม่ ผ่าน Hard Fork ก็สามารถทำให้การเปลี่ยนแปลงสถานะที่ผิดกฎภายใต้กฎเดิมกลายเป็นถูกต้องได้เช่นกัน

แต่ปัญหาอยู่ตรงนี้ ใครมีความสามารถทำให้นักขุด Full Node แพลตฟอร์มซื้อขาย กระเป๋าเงิน และผู้ใช้มากพอร่วมกันยอมรับกฎใหม่ชุดนี้?

แทบไม่มีเลย

ทีมพัฒนไม่สามารถตัดสินใจกฎฉันทามติแทนเครือข่าย Bitcoin ทั้งหมดได้ นักขุดและแพลตฟอร์มซื้อขายก็ยากเช่นกัน เพราะ门槛ฉันทามติที่ต้องข้ามนั้นสูงมาก ตอนที่ Binance ถูกแฮ็ก 7,000 BTC ก็มีคนแนะนำให้ CZ ติดต่อนักขุดรายใหญ่ให้ดำเนินการ แต่สุดท้ายก็เงียบหายไป

Ethereum เป็นอีกตัวอย่างที่คลาสสิกมาก

หลังจากเปลี่ยนมาใช้ PoS ปัจจุบัน Ethereum ใช้ฉันทามติ Gasper ซึ่งประกอบด้วย Casper FFG และ LMD-GHOST เข้าใจง่ายๆ คือ กลไกส่วนหนึ่งรับผิดชอบตัดสินว่า "ตอนนี้ควรตามเชนไหน" อีกส่วนหนึ่งรับผิดชอบทำให้บล็อกได้รับ Finality อย่างแท้จริง

เมื่อผู้ตรวจสอบที่เป็นตัวแทนของ ETH ที่ stake อย่างน้อยสองในสามบรรลุข้อตกลงเกี่ยวกับ checkpoint ที่เกี่ยวข้อง บล็อกจึงจะก้าวไปสู่การ確定ขั้นสุดท้ายได้ ในทางกลับกัน หาก stake เกินหนึ่งในสามไม่เข้าร่วมโหวตอย่างถูกต้องเป็นเวลานาน เครือข่ายอาจไม่สามารถสร้าง Finality ได้ชั่วคราว แต่ Ethereum ยังออกแบบ inactivity leak ไว้ เมื่อไม่สามารถ finalizing ได้เป็นเวลานาน จะค่อยๆ ลดน้ำหนักที่มีประสิทธิผลของผู้ตรวจสอบที่ออฟไลน์ ทำให้เครือข่ายมีโอกาสกลับมาสร้าง Finality ได้ในที่สุด

การจะเปลี่ยนผลลัพธ์เช่นนี้จริงๆ ก็ต้องเปลี่ยนกฎโปรโตคอลและไคลเอนต์เช่นกัน

เช่นเดียวกับเหตุการณ์ The DAO ในปี 2016 ชุมชน Ethereum สุดท้ายผ่าน Hard Fork ดำเนินการแก้ไขสถานะพิเศษที่ Ethereum Foundation เรียกว่า irregular state change โดยตรง ณ บล็อก 1,920,000 โอน ETH ที่เกี่ยวข้องไปยังสัญญากู้คืน

เพียงแต่ นักขุดและชุมชนส่วนหนึ่งที่ปฏิเสธการอัปเกรดและยังคงดูแลสถานะเดิม สุดท้ายได้ก่อตั้ง Ethereum Classic (ETC) ขึ้นมา นำไปสู่การแยกเชน ETH กับ ETC ที่ทุกคนรู้จัก แสดงว่าไม่ใช่ทุกคนที่ยอมรับกฎชุดนี้

Cosmos Hub แตกต่างออกไป มันใช้ CometBFT ซึ่งใกล้เคียงกับฉันทามติ BFT ทั่วไปมากกว่า

อาจเข้าใจได้ว่าเป็นฉันทามติ BFT ที่เป็นแบบฉบับมากกว่า นั่นคือ บล็อกจะ commit ได้จริงต้องได้รับการ Commit จาก voting power เกินสองในสาม

ข้อดีคือ Finality ชัดเจนมาก เมื่อบล็อกผ่านการโหวตจากอำนาจตรวจสอบมากพอและ commit แล้ว ก็ไม่จำเป็นต้องรอ blocK เพิ่มขึ้นเรื่อยๆ แลกความปลอดภัยด้วยความน่าจะเป็นเหมือน PoW

แต่อีกด้านก็ตรงไปตรงมาเช่นกัน นั่นคือหาก voting power หนึ่งในสามหรือมากกว่าไม่ให้คะแนนเสียงที่จำเป็นต่อการสร้าง Commit อีกต่อไป ผู้ตรวจสอบที่เหลือพยายามแค่ไหนก็รวมกันได้ไม่เกินสองในสาม

เมื่อถึงตอนนั้น ทางเลือกที่ปลอดภัยที่สุดของเครือข่ายก็คือ "หยุดผลิตบล็อก" เหมือนในครั้งนี้ ดังนั้นจากมุมมองของระบบกระจายศูนย์ การหยุดชะงักชั่วคราวของ Cosmos Hub ครั้งนี้จึงไม่ใช่เรื่องลึกลับ

พูดสั้นๆ คือ หลังจากกลุ่มผู้ตรวจสอบที่ถือ voting power มากพอหยุดเข้าร่วม โปรโตคอลฉันทามติก็ทำตามกฎของตัวเอง ยอมสูญเสียความพร้อมใช้งานดีกว่าconfirmบล็อกใหม่ต่อไปทั้งที่ฉันทามติไม่เพียงพอ

เบื้องหลังนี้จริงๆ สอดคล้องกับสองแนวคิดในระบบกระจายศูนย์ที่ผู้ใช้ทั่วไปมักสับสน:

• Safety: ต้องไม่ให้โหนดต่างกันยืนยันสถานะสุดท้ายที่ขัดแย้งกันสองสถานะพร้อมกัน
• Liveness: เครือข่ายยังสามารถเดินหน้าต่อและประมวลผลธุรกรรมใหม่ได้หรือไม่

สำหรับระบบ BFT เมื่อโหนดที่เข้าร่วมฉันทามติไม่เพียงพอ การหยุดชั่วคราวบางครั้งก็เป็นราคาที่ต้องจ่ายเพื่อรักษา Safety พูดตรงๆ ก็คือ บัญชีกระจายศูนย์เล่มนี้ยอมหยุดอยู่ตรงนั้นก่อน ดีกว่าให้คนที่เหลือต่างจดบันทึกกันเอง

เมื่อมองย้อนกลับจากมุมนี้ จะพบว่าเหตุการณ์ที่ดูเหมือนแตกต่างกันโดยสิ้นเชิงในประวัติศาสตร์ public chain จริงๆ แล้วล้วน revolve around เรื่องเดียวกัน:

เมื่อโหนดกระจายศูนย์ไม่สามารถบรรลุความเห็นพ้องต้องกันเกี่ยวกับ "สถานะที่ถูกต้อง" ต่อไปได้ เครือข่ายควรทำอย่างไร?

3. จาก Bitcoin ถึง Solana ขอบเขตความเสี่ยงที่แท้จริงของ public chain อยู่ตรงไหน?

นี่ไม่ใช่ครั้งแรกที่ Cosmos นำปัญหานี้ขึ้นมาบนโต๊ะ

ย้อนไปปี 2013 Bitcoin เคยเกิดอุบัติเหตุการแยกเชนที่คลาสสิกมาก

ตอนนั้น Bitcoin 0.8 เปลี่ยนฐานข้อมูลพื้นฐานจาก Berkeley DB เป็น LevelDB จากนั้นบล็อกที่มี input ธุรกรรมจำนวนมากก็ปรากฏขึ้น โหนดเวอร์ชันใหม่สามารถประมวลผลได้ปกติ แต่โหนดเวอร์ชันเก่าบางส่วนตัดสินว่าบล็อกนี้ไม่ถูกต้องเนื่องจากข้อจำกัดจำนวน lock ของ Berkeley DB

ดังนั้นฉากที่น่าอึดอัดก็ปรากฏขึ้น ทุกคนรัน Bitcoin เหมือนกัน แต่ไคลเอนต์ใหม่และเก่าเริ่มให้คำตอบต่างกันว่า "บล็อกนี้ถูกกฎหมายหรือไม่"

เครือข่ายจึงแยกเป็นสองเชน และฝั่ง 0.8 ใหม่เคยมีพลังคำนวณประมาณ 60% ไม่สามารถพึ่งการแข่งขันพลังคำนวณปกติให้บรรจบกันได้อย่างรวดเร็ว

สุดท้าย pool ขุดขนาดใหญ่ประสานงานกันสลับกลับไปเวอร์ชันเก่า ได้พลังคำนวณมากขึ้นในฝั่งกฎเดิม เครือข่ายจึงกลับมาบรรจบกัน และ Bitcoin ก็ทบทวนอุบัติเหตุนี้เป็นพิเศษผ่าน BIP 50

ถึงปี 2016 เหตุการณ์ The DAO ของ Ethereum ก็ผลักปัญหานี้ไปอีกขั้น

ดังที่กล่าวข้างต้น เหตุการณ์ The DAO สุดท้ายชุมชน Ethereum ผ่าน Hard Fork ดำเนินการแก้ไขสถานะพิเศษที่ Ethereum Foundation เรียกว่า irregular state change อย่างชัดเจน ณ บล็อก 1,920,000 โอน ETH ที่เกี่ยวข้องไปยังสัญญากู้คืน

แต่ไม่ใช่ทุกคนที่เห็นด้วยกับการจัดการนี้ นักขุดและชุมชนส่วนหนึ่งที่ปฏิเสธการแก้ไขสถานะยังคงดูแลกฎเดิม จึงเกิด Ethereum Classic (ETC) ที่ดำรงอยู่ยาวนานในภายหลัง

DAO Fork ครั้งนี้ก็เป็นเหตุการณ์คลาสสิก เท่ากับบอกทุกคนว่า เมื่อเกิดเหตุการณ์สุดขั้ว นอกเหนือจากฉันทามติของโค้ดแล้วยังมีฉันทามติทาง