บล็อกเชนไม่ได้กระจายศูนย์มากอย่างที่เราคิด

ในรอบเดือนที่ผ่านมา มีเปเปอร์วิจัยชิ้นหนึ่งที่โด่งดังในวงการบล็อกเชน นั่นคือ รายงานเรื่อง Are Blockchains Decentralized? (Blog Post, ข่าวใน Blognone) ที่ทำโดย Trail of Bits บริษัทด้าน security audit ชื่อดัง และได้รับจ้างจาก DARPA หน่วยงานวิจัยของกระทรวงกลาโหมสหรัฐ (หน่วยเดียวกับที่สร้างอินเทอร์เน็ตนั่นล่ะ)

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

วัตถุประสงค์ของงานวิจัยชิ้นนี้ ไม่ใช่การพิสูจน์ว่าบล็อกเชนไม่ปลอดภัย (blockchain is not secured) ผ่านการแฮ็กระบบแบบที่เราคุ้นเคย แต่เป็นการตรวจสอบว่า ในทางปฏิบัติแล้ว การรันเครือข่ายบล็อกเชนนั้นกระจายศูนย์ (decentralized) จริงๆ อย่างที่กล่าวอ้างกันในทางทฤษฎีหรือไม่

คำตอบที่ได้คือ บล็อกเชนนั้นกระจายศูนย์ในระดับหนึ่งจริง แต่ไม่เยอะในระดับที่กล่าวอ้างกัน (ส่วนหนึ่งก็คงเป็นเพราะไม่เคยมีใครลองทดสอบแบบ Trail of Bits จริงๆ จังๆ ด้วย เลยไม่มีใครรู้มาก่อนว่า เออ มันรวมศูนย์กว่าที่คิดนะ)

ผมคิดว่าแนวทางของ Trail of Bits คือต้องการลองดูว่า ถ้าเราต้องการเอาชนะกำแพง 51% Attack ซึ่งเป็นแนวคิดสำคัญของโลกบล็อกเชน (รวมเสียงในเครือข่ายให้มากกว่า 51% เพื่อยึดครองเครือข่าย) สามารถทำได้อย่างไรบ้าง โดยที่ในทางปฏิบัติ เราอาจไม่จำเป็นต้องมีเสียงให้ครบ 51% จริงๆ ก็ได้ เพราะถ้า “ปิด” หรือทำให้คุณสมบัติบางอย่างของบล็อกเชนใช้การไม่ได้ ตัวเครือข่ายมันจะอ่อนแอลงเอง

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

แนวทาง centrality ที่ Trail of Bits เสนอมีด้วยกัน 6 รูปแบบ ซึ่งเป็นการชี้ช่องในทางทฤษฎีว่า “เป็นไปได้” ยังไม่ได้เป็นการลองเอาชนะเครือข่ายดูจริงๆ

Authoritative Centrality

แนวคิดพื้นฐานของบล็อกเชนนับตั้งแต่ Bitcoin ถูกออกแบบขึ้นมาคือ โหนดต่างๆ นั้นไม่รู้จักและไม่ไว้วางใจกัน ทุกโหนด “แข่งขัน” กันเพื่อตรวจสอบธุรกรรมแลกกับรางวัลจูงใจ (ซึ่งก็คือการขุดเหมืองหรือ mining)

แต่ในทางปฏิบัติแล้ว เมื่อการขุดเหมืองทำได้ยากขึ้นเรื่อยๆ รางวัลจูงใจก็ลดลงเรื่อยๆ (ตามแนวทาง halving และปัจจัยอื่นๆ) ทำให้เกิดแนวคิดรวมกลุ่มขุดเหมือง (mining pools) ที่ตัวของ Satoshi Nakamoto เองก็คงนึกไม่ถึงมาก่อน

ประชากรชาวเหมืองมีการจัดการกันเอง และแต่ละค่ายก็ประดิษฐ์โปรโตคอลสำหรับแจกจ่ายงาน-แจกจ่ายรางวัลระหว่างกันเอง ซึ่งเป็นโปรโตคอลแบบรวมศูนย์ (centralized) ที่ไปรันงานบนเครือข่ายบล็อกเชนแบบกระจายศูนย์อีกที

พลังของการขุดเหมืองนั้นยิ่งใหญ่มาก จนทำให้วันนี้ กลุ่มขุดเหมืองรายใหญ่ 4 อันดับแรก ครอบครองพลังประมวลผล (hashrate) รวมกันมากกว่า 51% ของเครือข่าย Bitcoin แล้ว

นั่นแปลว่า ถ้ากลุ่มขุดเหมือง 4 อันดับแรก (ที่ภายในก็จัดการกันเองแบบ centralized) สามารถจับมือกันได้ ก็สามารถเอาชนะและครอบครองเครือข่ายได้

ถ้าเราเทียบกับตัวเลขในทางทฤษฎีตามแนวคิดของ Nakamoto คือต้องครอบครอง 51% ของจำนวนโหนดทั้งหมดในเครือข่าย ตีออกมาเป็นเลขกลมๆ คือประมาณ 59,000 โหนด นั้นเทียบกันไม่ได้เลยกับการครอบครองแค่ 4 หน่วยงานแล้วเอาชนะเครือข่ายได้

ตัวเลข 4 ที่ว่านี้ถูกเรียกว่า Nakamoto Coefficient หมายถึงจำนวนหน่วย/หน่วยงาน (entity) ที่น้อยที่สุดที่ต้องใช้เพื่อเอาชนะเครือข่าย กรณีของ Bitcoin คือ 4 ตามที่เขียนไป ส่วน Ethereum นั้นคือ 2 (ภายหลังเพิ่มเป็น 3)

ส่วนเครือข่ายบล็อกเชนประเภท Proof of Stake (PoS) รายอื่นๆ ใช้วิธีนำเหรียญไปค้ำประกัน (stake) และมักมีกฎว่าหากโหนดกลุ่มใดมีเหรียญมูลค่าเกิน 1/3 แปลว่ามีความประสงค์ร้าย และจะทำให้เครือข่ายหยุดทำงานชั่วคราว จึงพอคำนวณจำนวน Coefficient กลับมาได้ที่ราว 10-25 ราย ตามตาราง

Consensus Centrality

ถัดจากเรื่อง Authoritative Centrality ที่เป็นเรื่องจำนวนโหนดที่ต้องในการครองเสียงข้างมากของเครือข่ายแล้ว

ในบรรดากลุ่มโหนดผู้นำ (เช่น mining pools สำหรับกรณี Bitcoin และ staked validators ในกรณีของเครือข่าย PoS) มีการจัดการกันเองอย่างไร ก็เป็นประเด็นที่ต้องพิจารณาด้วยเช่นกัน

วงการ mining pool มีการคิดโปรโตคอลสื่อสารระหว่างกันเพื่อจ่ายงาน ส่วนใหญ่ใช้ Stratum (เริ่มโดย Slushpool) ซึ่งเป็น JSON RPC ที่ค่อยๆ สร้างกันมาโดยไม่มีมาตรฐานกลาง ตัวโปรโตคอล Stratum นั้นไม่ได้เข้ารหัสข้อมูล (อาจเป็นเพราะต้องฝังไว้ในฮาร์ดแวร์ขุดเหมือง ที่ไม่มีพลังประมวลผล TLS/SSL) และในอดีตคือไม่มีระบบ authentication ด้วยซ้ำ (ตอนนี้แก้ไขไปบ้างแล้ว แต่ก็ไม่ได้แก้ทั้งหมด เช่น ยังมีการ hardcode รหัสผ่านอยู่)

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

Motivational Centrality

หัวข้อนี้กล่าวถึงการโจมตีที่เรียกว่า

• Sybil attack มันคือการที่ผู้ประสงค์ร้ายสักองค์กร สร้างโหนดใหม่จำนวนมากๆ เข้ามาในเครือข่าย เพื่อสร้างอิทธิพลในเครือข่ายบล็อกเชน
• Eclipse attack เป็นการทำให้โหนดจำนวนหนึ่งใช้การไม่ได้ (DoS) เพื่อให้ระบบหยุดชะงัก การสื่อสารดีเลย์ จนเกิดภาวะ 2 เหมืองสร้างบล็อกแบบเดียวกัน ต่อท้ายบล็อกแม่อันเดียวกัน จะเกิดภาวะ fork แยกเป็นสองสาย ซึ่งสุดท้ายเครือข่ายต้องตัดสินใจเลือกสายใดสายหนึ่งเป็นตัวจริง ดังนั้นข้อมูลในอีกสายหนึ่งจะถูกทิ้งไป (สายนี้เรียกว่า ommer/uncle) และสิ้นเปลืองพลังงานในการขุดของสายนี้ไปโดยใช่เหตุ

Trail of Bits ลองคำนวณพลังประมวลผลที่เสียไปจากปัญหาการดีเลย์ดังกล่าว และพบว่าพลังประมวลของเครือข่าย Bitcoin มีจริงๆ เพียง 98.68% ของพลังที่ควรจะเป็น (เท่ากับว่าเสียการคิด hashrate ทิ้งไป 1% กว่าๆ) หากเราลองเทียบดูกับเกณฑ์เรื่อง 51% Attack ก็จะพบว่าจริงๆ ใช้พลังงานเพียง 49% ก็เพียงพอ ทำให้การครอบงำเครือข่ายขึ้นไปอีก

Trail of Bits ยังประเมินว่า ถ้าการดีเลย์ของข้อมูลบล็อกยาวนานขึ้นอีกนิด (หลักไม่กี่นาที) จะทำให้สัดส่วนการครอบงำเครือข่ายลดลงมาเหลือเพียง 40% ของ hashrate และถ้ายาวประมาณเกือบ 1 ชั่วโมง ก็ใช้เพียง 20% ของ hashrate

การโจมตีแบบ Sybil attack ไม่ได้เป็นแค่ในทฤษฎี เพราะเคยเกิดขึ้นจริงแล้วกับเครือข่าย Bitcoin ช่วงเดือนกรกฎาคม 2021 แม้ไม่สามารถสรุปได้ว่าคนทำมีจุดประสงค์อะไร แต่ก็ส่งผลให้จำนวนการเชื่อมต่อในเครือข่ายลดลงในช่วงที่โจมตี

นอกจากนี้ยังมีงานวิจัยของ Yujin Kwon และคณะ ที่พบว่าในทางทฤษฎีแล้ว หากเป็นเครือข่ายแบบ Permissionless Blockchain ที่ใครๆ ก็เข้าร่วมได้ (Bitcoin & Ethereum) เราไม่สามารถป้องกัน Sybil attack ได้ทั้งหมด ยกเว้นจะต้องมีหน่วยงานกลาง centralized trusted third party (TTP) มาช่วยตรวจสอบให้ ซึ่งก็จะเสียจุดเด่นเรื่องความไร้ศูนย์กลางไป

Topological Centrality

หัวข้อนี้เป็นเรื่องการเชื่อมต่อของเครือข่าย (topology) ซึ่งตามทฤษฎีเครือข่าย (network theory หรือ graph theory) เราจะมีการกระจายตัวของโหนดในเครือข่ายแบบที่เรียกว่า scale-free network หรืออธิบายเป็นภาษาชาวบ้านๆ คือ มีโหนดจำนวนน้อยที่มีการเชื่อมต่อเยอะๆ (ฮับ) เป็นตัวหลักอยู่ในเครือข่าย ส่วนโหนดอื่นๆ ที่เหลือส่วนใหญ่จะมีการเชื่อมต่อไม่เยอะนัก (แนะนำให้ดูคลิปนี้ประกอบ อธิบายง่ายดี)

เครือข่ายแบบ peer-to-peer ที่เกิดขึ้นตามธรรมชาตินั้นมักเป็นเครือข่ายแบบ scale-free ซึ่งมีข้อดีตรงที่การสื่อสารภายในเครือข่ายทำได้เร็ว (มี hop น้อย) ในกรณีของบล็อกเชน เครือข่ายที่เป็น scale-free จะช่วยให้โหนดต่างๆ หาฉันทามติ (consensus) กันได้เร็วขึ้น เกิดปัญหาข้อมูลดีเลย์จนนำไปสู่ Eclipse attack ได้น้อยลง

คำถามสำคัญคือ เครือข่ายบล็อกเชนมีคุณสมบัติเป็น scale-free หรือไม่

คนส่วนใหญ่มักคิดว่าใช่ แต่การสังเกตของ Trail of Bits พบว่าเครือข่าย Bitcoin ไม่ใช่ scale-free อย่างที่คิดกัน

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

Trail of Bits ไปขุดซอร์สโค้ดของ Bitcoin Core แล้วพบว่า

• มีการจำกัดจำนวน peer ที่โหนดจะแชร์ให้โหนดอื่นๆ รู้จัก ที่จำนวน 23% ของ peer หรือ 1,000 (ขึ้นกับจำนวนไหนน้อยกว่า)
• ปิดการทำ NAT (network address translation) และ UPnP (Universal Plug and Play) ไว้เป็นดีฟอลต์ แปลว่าโหนดที่ไม่มี Public IP (เช่น อยู่หลังไฟร์วอลล์หรือใช้เน็ตบ้าน) จะไม่สามารถรับการเชื่อมต่อขาเข้าจาก peer ข้างนอกได้ ทำได้แค่ส่งทราฟฟิกออกเท่านั้น (มี cap ด้วยที่ขาออก 8 โหนด)
• โหนดที่เป็นสาธารณะ มี Public IP มีกำหนดการเชื่อมต่อขาเข้า cap ที่ 125 โหนด
• โหนดยังพยายามกระจาย peer ให้หลากหลายขึ้น ด้วยวิธีจำกัด IP ที่คล้ายๆ กันไม่ให้เชื่อมต่อเข้ามา

ด้วยปัจจัยทั้งหลายเหล่านี้ ทำให้ topology ของเครือข่าย Bitcoin มีการกระจายตัวที่ไม่ดีนัก ตามทฤษฎีแล้วควรมีค่า diameter (ระยะจากโหนดถึงโหนดที่ไกลที่สุด) ที่ 5 แต่จากการทดสอบจริงของ Trail of Bits พบว่าระยะจริงๆ อยู่ที่ราว 4 กว่าๆ เท่านั้น

Trail of Bits ยังลองไล่สายของโหนดในเครือข่าย Bitcoin เพื่อมาพล็อตชาร์ทหาความสัมพันธ์ ในเครือข่ายที่มีสุขภาพดี การกระจายตัวควรเป็นไปตามเส้นสีแดง (เส้นชาร์ทยกกำลัง Power-Law ที่เขียนด้วยแกนแบบ log scale) แต่การกระจายตัวจริงๆ กลับเป็นไปตามเส้นสีน้ำเงินแทน โดยโหนดส่วนใหญ่มี peer ที่ 125 ซึ่งมาจาก cap ในตัวไคลเอนต์ดังที่เขียนไปข้างต้น

ชาร์ทนี้แสดงให้เห็นว่า โหนดส่วนใหญ่ในเครือข่าย Bitcoin ไม่ค่อยเกิดประโยชน์กับตัวเครือข่ายนัก คือ มีโหนดที่มี peer น้อย (ไม่ค่อยมีประโยชน์) จำนวนเยอะเกินไป (ด้านขวาในชาร์ท) ส่วนโหนดที่มี peer มากๆ (มีประโยชน์) จำนวนน้อยเกินไป (ด้านซ้ายในชาร์ท)

การไล่สายโหนดของ Trail of Bits ยังพบว่ามีโหนดที่เป็น Public IP เพียง 6-11% ของทั้งเครือข่ายเท่านั้น ซึ่งตามทฤษฎีเครือข่ายแล้วก็ควรมีอย่างน้อย 10% (เรียกได้ว่าน้อยกว่าค่าที่ควรจะเป็นไปสักหน่อย)

Network Centrality

ถัดจากเรื่องแพทเทิร์นการเชื่อมต่อของเครือข่าย (topology) มาดูเรื่องตัวเครือข่ายจริงๆ กันบ้าง จากการตรวจสอบ Trail of Bits พบว่า

• 60% ของทราฟฟิก Bitcoin มีการเดินทางข้าม ISP กันเพียง 3 ISP เท่านั้น
• 50% ของโหนดแบบ Public มาจาก IP ใน 3 ประเทศคือ เยอรมนี ฝรั่งเศส สหรัฐอเมริกา
• โหนด 1/3 ของเครือข่ายอยู่ในอเมริกา, 1/4 อยู่ในเยอรมนี, 1/10 อยู่ในฝรั่งเศส
• 50% ของเครือข่าย Bitcoin ถูกส่งผ่าน Tor อีกชั้นด้วย

ด้วยปัจจัยทั้งหมดที่ว่ามา จะเห็นว่าโหนดจริงๆ ของเครือข่าย Bitcoin มีความกระจุกตัวในระดับหนึ่ง ไม่ได้ “กระจายศูนย์มากๆ” อย่างที่เชื่อกัน ตรงนี้อาจเป็นช่องว่างให้เกิดการโจมตีระดับเครือข่ายได้

ตัวอย่างระดับ สหรัฐอเมริกาสั่งแบนทราฟฟิก Bitcoin ทั้งหมดอาจโอเวอร์ไป แต่ในทางปฏิบัติ หากมีคนควบคุม ISP หรือเครือข่ายบางส่วน แล้วบล็อคทราฟฟิกระหว่างโหนด (ที่ส่งยืนยันธุรกรรมไปมาระหว่างโหนด หรือในวงการเรียก gossip แล้วธุรกรรมยังไปไม่ถึงปลายทาง) จะทำให้เครือข่ายอ่อนแอลง การโจมตีแบบ 51% Attack ง่ายขึ้น ตามที่กล่าวมาแล้วในเรื่อง Eclipse attack

ที่สำคัญคือการโจมตีแบบนี้เคยเกิดขึ้นแล้ว โดยระหว่างปี 2020-2021 มีการตรวจพบผู้ไม่ประสงค์ดี (คาดว่ามาจากรัสเซีย) ใช้การโจมตีแบบ Sybil attack เพื่อครอบครอง exit node ของ Tor ได้เป็นสัดส่วนถึง 40% เมื่อบวกกับการที่ทราฟฟิกของ Bitcoin วิ่งผ่าน Tor ก็ส่งผลให้ผู้ประสงค์ร้ายควบคุมทราฟฟิกของ Bitcoin ได้มากในระดับหนึ่งเลย

Trail of Bits จึงเสนอตัวชี้วัดอิทธิพลของโหนดต่อการหาฉันทามติในเครือข่าย (“the amount of influence a node has on the consensus of the entire network based on its topological position”) เรียกว่า Consensus Influence ซึ่งไม่เหมือนกับจำนวนโหนดซะทีเดียว เพราะนับเรื่องตำแหน่งของโหนดในเครือข่าย (topology) มาประกอบด้วย

ผลออกมาเป็นไปตามชาร์ทคือ ค่า Consensus Influence ของสหรัฐอเมริกาและเยอรมนีสูงที่สุด (มีจำนวนโหนดสูงสุด แต่ไม่เท่ากันซะทีเดียว)

Software Centrality

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

ประเด็นด้านซอฟต์แวร์มีหลายหัวข้อย่อย ดังนี้

• พบว่าโหนด Bitcoin สัดส่วน 21% ใช้ซอฟต์แวร์ Bitcoin Core เวอร์ชันเก่า ที่มีช่องโหว่ความปลอดภัย
• กระบวนการพัฒนา Bitcoin Core เองก็มีความกระจุกตัวสูง มีนักพัฒนาเพียง 4 คนที่มีสิทธิแก้ไขโค้ด และอาจเป็นเป้าหมายของแฮ็กเกอร์ในการแฮ็ก/phishing ได้ ก่อนหน้านี้เคยมีเคสหัวหน้าทีม Solana โดนมุ่งเป้าโจมตีด้วยมัลแวร์ Pegasus มาแล้ว
• ตัวผู้ใช้ Bitcoin เองก็มีทางเลือก 2 ทาง คือการรันวอลเล็ตเอง (non-custodial) ซึ่งอาจมีความเสี่ยงเรื่องความน่าเชื่อถือของนักพัฒนาวอลเล็ต และการฝากเงินไว้กับตัวแทน (custodial exchange) ซึ่งแบบหลังเป็นระบบรวมศูนย์ แต่ผู้ใช้นิยมมากกว่า เพราะสะดวกกว่า มั่นใจกว่ารันวอลเล็ตเอง
• ในแง่ของสาแหรกตระกูลซอฟต์แวร์บล็อกเชนทั้งหลาย ตั้งแต่ Bitcoin, Ethereum ไปจนถึง Dogecoin, Monero, Litecoin ทาง Trail of Bits ลองเอาซอร์สโค้ดมาวิเคราะห์ดู พบว่าบางโครงการที่ไม่เกี่ยวข้องกันเลย (เช่น Monero กับ Bitcoin) ก็ยังมีความคล้ายคลึงกันของซอร์สโค้ดสูงมาก
• ฝั่งของกลุ่มเหมือง (mining pool) ก็มีวิธีการที่แตกต่างกันแบบสุดขั้ว เช่น AntPool แจกจ่ายเฉพาะไบนารีเท่านั้น และไม่เคยมีการตรวจสอบความปลอดภัย, ViaBTC เป็นโอเพนซอร์ส ดูโค้ดได้ แต่ Trail of Bits ตรวจสอบแล้วพบว่ามีความซับซ้อนสูง พยายามใช้ C เขียนทุกอย่าง หากซอฟต์แวร์กลุ่มเหมืองโดนเจาะ ถ้านำไปบวกกับปัจจัยในหัวข้อก่อนๆ ก็อาจทำ 51% Attack ได้เช่นกัน
• ตัวโค้ดที่รันบนเชนอย่างพวก Smart Contract ของ Ethereum มีการรียูสโค้ดกันเยอะมาก มักนิยมใช้ไลบรารีกลาง OpenZeppelin เหมือนกัน จากการสุ่มตรวจโค้ด 1,685 ชุด พบว่า 90% ของ contrast มีความเหมือนกันอย่างน้อย 56% และมี 7% ที่เหมือนกันเป๊ะๆ ทุกอย่าง

บทสรุป

รายงานของ Trail of Bits ไม่ได้บอกว่า บล็อกเชนไม่ปลอดภัย (ในเซนส์แบบดั้งเดิมคือโดนแฮ็กจากช่องโหว่) แต่จะบอกว่า เครือข่ายบล็อกเชนที่รันอยู่นั้น ไม่ได้ทนทานต่อการโจมตี 51% Attack มากอย่างที่เราคิดกัน (ไม่ได้แปลว่าไม่ทนทานเลย แต่ทนทานน้อยลง ตัวอย่างเช่น อาจทนทานได้สัก 20-30% Attack เรื่องตัวเลขคงแล้วแต่ว่าจะถูกโจมตีด้วยอะไรผสมกันบ้าง) ซึ่งผู้วิจัยก็เสนอแนวทางกว้างๆ 6 รูปแบบว่าความเป็นไปได้ในการโจมตีเครือข่ายบล็อกเชนมีอะไรบ้าง

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

บทความอื่นที่เกี่ยวข้อง

• บล็อกเชนคือเทคโนโลยีที่ไร้ประโยชน์
• ตามสืบรากเหง้าของ Bitcoin
• มายาคติแห่ง Decentralization