สะพานข้ามเชน (cross-chain bridges) สูญเสียเงินจากการถูกโจมตีมากกว่าหมวดอื่นเกือบทั้งหมดในวงการคริปโต
สะพาน Ronin สูญเสีย 625 ล้านดอลลาร์ในปี 2022 Wormhole สูญเสีย 320 ล้านดอลลาร์ในปีเดียวกัน Nomad สูญเสีย 190 ล้านดอลลาร์เพียงไม่กี่เดือนถัดมา
แต่สะพานกลับยิ่งสำคัญกว่าที่เคยเป็นมา
TAC, Celo และโปรเจกต์อีกนับสิบพึ่งพาสะพานเหล่านี้ในการเชื่อมต่อระบบนิเวศบล็อกเชนที่แยกจากกัน ซึ่งปกติแล้วไม่สามารถสื่อสารกันได้
การจะเข้าใจว่าทำไมสะพานถึงทั้งขาดไม่ได้และอันตราย ต้องเริ่มจากการเข้าใจว่ามันทำอะไรในเชิงเทคนิคกันแน่
TL;DR
- สะพานบล็อกเชนคือซอฟต์แวร์ที่ล็อกสินทรัพย์บนเชนหนึ่ง แล้วสร้างโทเคนตัวแทนเทียบเท่าบนอีกเชนหนึ่ง เพื่อให้มูลค่าเคลื่อนย้ายข้ามเครือข่ายที่แยกจากกันได้
- สะพานเป็นเป้าหมายมูลค่าสูง เพราะเป็นผู้ดูแลสินทรัพย์ที่ถูกล็อกไว้จำนวนมหาศาล บางครั้งถึงระดับพันล้านดอลลาร์ ในสมาร์ตคอนแทรกต์หรือกระเป๋า multisig
- มีดีไซน์สะพานหลักอยู่สี่แบบ (lock-and-mint, burn-and-mint, กองสภาพคล่อง และ light-client verification) ซึ่งแต่ละแบบมีข้อแลกเปลี่ยนด้านความปลอดภัยต่างกัน
- แฮ็กครั้งใหญ่ส่วนมากโจมตีที่การขโมยกุญแจของ validator การบิดเบือน oracle หรือบั๊กในลอจิกของสมาร์ตคอนแทรกต์ ไม่ใช่โจมตีตัวบล็อกเชนพื้นฐานโดยตรง
- ดีไซน์รุ่นใหม่ที่ลดการพึ่งพาความเชื่อใจโดยใช้ zero-knowledge proofs กำลังช่วยลดพื้นผิวการโจมตี แต่ทุกวันนี้ยังไม่มีสะพานแบบใดที่ปลอดภัยไร้ความเสี่ยง
สะพานบล็อกเชนจริง ๆ แล้วทำอะไร
บล็อกเชนสองเครือข่ายเป็นระบบที่แยกจากกันโดยสิ้นเชิงตามค่าเริ่มต้น
Bitcoin (BTC) ไม่รู้เลยว่า Ethereum (ETH) มีอยู่ Ethereum ก็ไม่สามารถอ่านสถานะอัปเดตของ Solana (SOL) ได้โดยตรง
แต่ละเชนประมวลผลธุรกรรมของตนเอง เก็บบัญชีแยกประเภทของตนเอง และทำฉันทามติของตนเอง ไม่มีหน่วยความจำส่วนกลางที่แชร์กันระหว่างเชน
สะพานคือเลเยอร์ซอฟต์แวร์ที่สร้าง “ภาพลวงตา” ว่ามีการเคลื่อนไหวข้ามเชนเกิดขึ้น
ในทางปฏิบัติ สินทรัพย์ไม่ได้ “ย้าย” จากเชนหนึ่งไปอีกเชนโดยตรง สิ่งที่เกิดขึ้นจริงคือกระบวนการสองขั้น: สินทรัพย์จะถูกล็อก (หรือเผา) บนเชนต้นทาง แล้วจึงสร้างตัวแทนที่สอดคล้องกัน (mint หรือปล่อยออก) บนเชนปลายทาง
โปรโตคอลสะพานจะประสานสองเหตุการณ์นี้และรับประกันว่ามันเชื่อมโยงกัน
สะพานไม่ได้เทเลพอร์ตโทเคนของคุณ มันล็อกโทเคนไว้ด้านหนึ่งแล้วพิมพ์ IOU อีกด้านหนึ่ง — คำถามด้านความปลอดภัยที่แท้จริงคือ: ใครคุมกลไกล็อก และใครมีสิทธิ์สั่งพิมพ์?
ความแตกต่างนี้สำคัญมากในมุมความปลอดภัย
สินทรัพย์ดั้งเดิมจะถูกเก็บไว้ที่ไหนสักแห่ง การเก็บรักษานั่นแหละคือพื้นผิวการโจมตี
ว่าจะเป็นสมาร์ตคอนแทรกต์ กระเป๋า multisig ที่คณะ validator ถือกุญแจไว้ หรือระบบพิสูจน์ทางคริปโต นั่นแทบจะเป็นตัวกำหนดทั้งหมดว่าสะพานจะปลอดภัยแค่ไหน
อ่านเพิ่มเติม: Bitget ป้องกันการโจมตีไซเบอร์ 150 ล้านครั้งในหนึ่งปี รายงานใหม่เผย
ดีไซน์สะพานหลัก 4 แบบ
ไม่ใช่ว่าสะพานทุกอันจะทำงานเหมือนกัน ปัจจุบันมีสถาปัตยกรรมหลัก ๆ อยู่สี่แบบในการใช้งานจริง โดยแต่ละแบบเลือกแลกเปลี่ยนระหว่างความปลอดภัย ความเร็ว ประสิทธิภาพเงินทุน และการกระจายศูนย์ไม่เท่ากัน
Lock-and-Mint เป็นดีไซน์ที่พบบ่อยที่สุด ผู้ใช้ส่งโทเคนไปยังสมาร์ตคอนแทรกต์บนเชนต้นทาง ซึ่งโทเคนจะถูกล็อกไว้ ชุด validator ของสะพานจะเฝ้าดูการฝากนี้ แล้วสั่งให้เชนปลายทาง mint โทเคน “wrapped” ที่เป็นตัวแทนโทเคนเดิม Wrapped Bitcoin (WBTC) บน Ethereum ใช้วิธีนี้ เช่นเดียวกับ ETH ส่วนใหญ่ที่ถูกบริดจ์ไปยัง Layer 2 รุ่นแรก ๆ โทเคน wrapped แสดงสิทธิในการเคลมโทเคนต้นฉบับที่ถูกล็อกไว้ เมื่อผู้ใช้ต้องการย้ายกลับ ก็เผาโทเคน wrapped แล้วล็อกบนเชนต้นทางจะปล่อยออกมา
Burn-and-Mint ใช้เมื่อผู้ออกโทเคนควบคุมอุปทานได้โดยตรงบนหลายเชน แทนที่จะ wrap โทเคนจะถูกเผาบนเชนต้นทาง (ทำให้อุปทานที่นั่นลดลง) และ mint โทเคนใหม่บนเชนปลายทาง Cross-Chain Transfer Protocol (CCTP) ของ Circle สำหรับ USD Coin (USDC) ใช้รูปแบบนี้ เพราะ Circle เป็นผู้อนุมัติการ mint เอง จึงไม่มีพูลโทเคนที่ถูกล็อกให้แฮ็กเกอร์ขโมย แต่คุณต้องเชื่อใจ Circle เต็มที่
สะพานแบบกองสภาพคล่อง (Liquidity Pool bridges) เช่นที่ใช้โดย Hop Protocol และ Across Protocol ทำงานต่างออกไป แทนที่จะล็อกสินทรัพย์แล้ว mint ตัวแทน โปรโตคอลจะอาศัยผู้ให้สภาพคล่องที่ถือโทเคนเนทีฟทั้งสองฝั่ง ผู้ใช้ฝากบนเชนต้นทาง แล้วผู้ให้สภาพคล่องบนเชนปลายทางจะส่งโทเคนเนทีฟเทียบเท่าให้ทันที จากนั้น LP จะได้รับเงินคืนผ่านโปรโตคอล วิธีนี้เร็วกว่าทั้งยังเลี่ยงโทเคน wrapped แต่ต้องพึ่งพาสภาพคล่องที่เพียงพอและเพิ่มความเสี่ยงด้านคู่สัญญาของ LP
Light-Client Verification เป็นดีไซน์ที่พึ่งพาความเชื่อใจน้อยที่สุดและสร้างยากที่สุด ในรูปแบบนี้ เชนปลายทางจะรันหลักฐานทางคริปโตของฉันทามติของเชนต้นทาง อยู่ภายในสมาร์ตคอนแทรกต์หรือวงจร ZK โดยตรง จึงไม่ต้องมีคณะ validator ภายนอกมารับรอง คณิตศาสตร์จะพิสูจน์เองว่าการฝากเกิดขึ้นจริง IBC (Inter-Blockchain Communication) มาตรฐานสะพานที่ใช้ในเครือข่าย Cosmos (ATOM) ใกล้เคียงโมเดลนี้ สะพานแบบ ZK เช่น SP1 ของ Succinct และ zkBridge ของ Polyhedra ดันแนวทางนี้ไปต่อโดยใช้ zero-knowledge proofs ในการพิสูจน์การเปลี่ยนสถานะให้มีต้นทุนถูกลง
อ่านเพิ่มเติม: HIVE เพิ่งกู้เงิน 115 ล้านดอลลาร์ดอกเบี้ย 0% เพื่อเดิมพันสวนทางกับการขุด Bitcoin
ทำไมสะพานจึงสะสมความเสี่ยงไว้มาก
พื้นผิวการโจมตีของสะพานต่างจากของบล็อกเชนเดี่ยวอย่างสิ้นเชิง เชนอย่าง Ethereum ได้รับความปลอดภัยจากมูลค่าหลายแสนล้านดอลลาร์ที่ถูก stake เป็น ETH และมี validator หลายแสนราย การเจาะเชนให้ได้ผลต้องควบคุม validator ส่วนใหญ่ในเวลาเดียวกัน ซึ่งมีต้นทุนสูงแทบเป็นไปไม่ได้
ชุด validator ของสะพานมักจะเล็กกว่ามาก สะพาน Ronin ซึ่งให้บริการเกม Axie Infinity บนไซด์เชนของตนเอง มี validator เพียงเก้าโหนด แฮ็กเกอร์ต้องควบคุมเพียงห้าโหนดเพื่ออนุมัติการถอนเงิน กลุ่ม Lazarus ซึ่งเป็นองค์กรแฮ็กเกอร์ที่รัฐบาลเกาหลีเหนือหนุนหลัง ขโมยกุญแจส่วนตัวห้าดอกจากฟิชชิงและข้อเสนอรับเข้าทำงานปลอม พวกเขาอนุมัติการถอนเงินปลอมมูลค่า 625 ล้านดอลลาร์ เชน Ethereum และ Ronin ตัวจริงไม่เคยถูกแตะต้องเลย
การแฮ็ก Ronin ไม่ได้ทำลายบล็อกเชน แต่มันทำลายคณะ validator เก้าโหนด ที่กุญแจห้าดอกถูกเก็บอย่างไม่ปลอดภัย สะพานจึงเป็นจุดอ่อนที่สุดโดยดีไซน์
นี่คือปัญหาเชิงโครงสร้างของสะพานที่ใช้ validator ภายนอก ความปลอดภัยของมันไม่ได้สืบทอดมาจากเชนที่เชื่อมต่อกัน แต่มาจากระบบแยกต่างหากที่มักเล็กกว่า และผ่านศึกน้อยกว่า ยิ่งสะพานถือมูลค่ามากเท่าใด ก็ยิ่งดึงดูดการโจมตีมากเท่านั้น แต่โมเดลความปลอดภัยไม่ได้เพิ่มขึ้นตามมูลค่าทรัพย์สินที่ดูแลโดยอัตโนมัติ
การโจมตี Wormhole ในเดือนกุมภาพันธ์ 2022 ใช้กลไกต่างออกไปแต่ผลลัพธ์คล้ายกัน แฮ็กเกอร์พบบั๊กในสมาร์ตคอนแทรกต์ของ Wormhole บน Solana ที่ทำให้สามารถปลอมเหตุการณ์ “guardian signature verification” ได้ พวกเขาหลอกให้คอนแทรกต์เชื่อว่า 120,000 ETH ถูกฝากบน Ethereum ทั้งที่ไม่จริง แล้ว mint wrapped ETH มูลค่า 320 ล้านดอลลาร์บน Solana ไม่มี validator ใดถูกเจาะ ช่องโหว่อยู่ที่ลอจิกของคอนแทรกต์เอง Jump Crypto ซึ่งเป็นผู้สนับสนุน Wormhole เติมเงินทดแทนภายใน 24 ชั่วโมง ป้องกันไม่ให้ตลาดพังลง แต่ก็ไม่อาจลบล้างข้อบกพร่องเชิงพื้นฐานได้
อ่านเพิ่มเติม: ผู้ใช้ Polymarket สูญ 3.1 ล้านดอลลาร์จากการโจมตีฝั่ง frontend ท่ามกลางการสอบสวนของ CFTC
บทบาทของ Validators และ Oracles
สะพานส่วนใหญ่ที่ไม่ใช่ระบบ light-client ล้วนต้องพึ่งพาผู้สังเกตภายนอกบางรูปแบบ เพื่อยืนยันว่ามีการฝากเกิดขึ้น และอนุมัติการ mint หรือการปล่อยโทเคนที่เกี่ยวข้อง
ผู้สังเกตเหล่านี้มีหลายชื่อ — validators, relayers, guardians, attestors — แต่ทำหน้าที่เดียวกันคือ เฝ้าดูเชนหนึ่งแล้วรายงานสถานะไปยังอีกเชนหนึ่ง
คำถามด้านความเชื่อใจคือ: ต้องทำอย่างไรให้ผู้สังเกตเหล่านี้ “โกหก” ได้?
ในโมเดล multisig คำตอบคือ “ขโมยกุญแจให้ได้พอ” ในโมเดลที่อิง oracle คำตอบอาจเป็น “บิดเบือนราคา หรือข้อมูลบล็อกที่ oracle รายงาน” ในโมเดล validator แบบ proof-of-stake คำตอบคือ “ถือ stake ให้ได้มากพอที่จะคุมเสียงข้างมากพิเศษ”
LayerZero ใช้โมเดลที่แต่ละแอปตั้งค่า oracle และ relayer ของตัวเอง ทำให้มีความปลอดภัยแบบเฉพาะแอป แทนที่จะใช้ชุด validator สะพานร่วมกัน ความเสี่ยงจึงย้ายจาก “สะพานเดียวพัง ทุกอย่างพัง” ไปเป็น “แต่ละแอปรับความเสี่ยงของตัวเอง” ซึ่งช่วยแยกปัญหาได้จริง แต่ก็เพิ่มภาระให้ฝั่งนักพัฒนาในการตั้งค่าความปลอดภัยให้ถูกต้อง
Axelar ใช้เครือข่าย proof-of-stake ของ validator ของตัวเองในการเฝ้าดูเหตุการณ์ข้ามเชน ความปลอดภัยของสะพานจึงผูกกับมูลค่าโทเคนของ Axelar ที่ถูก stake โดย validator คล้ายโมเดลของบล็อกเชนเลเยอร์ 1 แต่โฟกัสที่การส่งข้อความข้ามเชน
ความท้าทายพื้นฐานคือ คุณไม่สามารถตรวจสอบสถานะของเชนภายนอกได้แบบเนทีฟ โดยไม่รันโหนดเต็มของเชนนั้น ซึ่งมีต้นทุนแพง วิธี light-client และ ZK แก้ปัญหานี้ด้วยคริปโตกราฟี ส่วนทุกวิธีที่เหลือคือการเชื่อใจตัวกลางให้รายงานอย่างซื่อสัตย์
อ่านเพิ่มเติม: Ethereum กำลังจะร่วงสู่ 1,000 ดอลลาร์หลังเสียแนวรับสำคัญหรือไม่?
ZK Proofs กำลังเปลี่ยนความปลอดภัยของสะพานอย่างไร
Zero-knowledge proofs เป็นทางออกระยะยาวที่มีแนวโน้มดีที่สุดสำหรับปัญหาความเชื่อใจในสะพาน ZK proof ช่วยให้ฝ่ายหนึ่งพิสูจน์ให้ฝ่ายอื่นเห็นว่าข้อความบางอย่างเป็นจริง เช่น “ธุรกรรมนี้ถูกบรรจุอยู่ในบล็อกที่ final แล้วบน Ethereum” โดยที่ผู้ตรวจสอบไม่ต้องรันการคำนวณทั้งหมดซ้ำเอง
เมื่อนำมาใช้กับสะพาน นั่นหมายถึงเชนปลายทางสามารถตรวจสอบเหตุการณ์บนเชนต้นทางได้ เข้ารหัสเชิงคริปโต โดยไม่ต้องเชื่อถือผู้ตรวจสอบภายนอกใด ๆ ตัวพิสูจน์ (proof) เองก็คือคำยืนยัน (attestation) ตัวตรวจสอบที่ถูกเจาะระบบไม่สามารถปลอมแปลงหลักฐาน ZK ที่ถูกต้องได้ และก็ไม่มีคีย์ส่วนตัวให้ขโมย ความปลอดภัยมาจากคณิตศาสตร์ล้วน ๆ
ความท้าทายเชิงปฏิบัติคือ “ต้นทุนการคำนวณ” การสร้าง ZK proof สำหรับฉันทามติทั้งเชน (เช่น การรวมลายเซ็น BLS ใน Ethereum Proof of Stake จากตัวตรวจสอบหลายพันราย) ต้องใช้การประมวลผลอย่างมหาศาล แม้ต้นทุนนี้จะลดลงอย่างมากเมื่อเทคโนโลยี ZK proving พัฒนาขึ้นแล้วก็ตาม ทีมอย่าง Succinct Labs, =nil; Foundation และ Polyhedra กำลังสร้างระบบ proving ที่ออกแบบมาเฉพาะเพื่อการยืนยัน state ของบล็อกเชน
TAC เลเยอร์ 1 ที่กำลังเป็นกระแสบน CoinGecko ใช้วิธีการเฉพาะกับปัญหานี้: เชื่อมสะพานระหว่างระบบนิเวศนักพัฒนา EVM ของ Ethereum เข้ากับ TON (The Open Network) และฐานผู้ใช้ Telegram โดยใช้โมเดลตัวตรวจสอบและ proof แบบไฮบริด โปรเจกต์อย่าง TAC แสดงให้เห็นถึงดีมานด์เชิงปฏิบัติสำหรับบริดจ์ Telegram มีผู้ใช้แอคทีฟรายเดือนราว 950 ล้านคน การเชื่อมผู้ใช้กลุ่มนี้เข้ากับแอปพลิเคชันที่รองรับ Ethereum ต้องอาศัยโครงสร้างพื้นฐาน cross-chain แบบที่บริดจ์จัดหาให้พอดี
ข้อแลกเปลี่ยนของ ZK bridge ในวันนี้คือ “ความหน่วงเวลา” การสร้าง proof สำหรับบล็อก Ethereum ที่ final แล้วอาจใช้เวลาหลายนาที สำหรับแอปที่ต้องการ finality รวดเร็ว บริดจ์แบบ optimistic ที่มีช่วงเวลา fraud-proof จึงยังมักถูกเลือกใช้งานมากกว่า โดยยอมรับดีเลย์การถอนที่ยาวกว่า (มักจะประมาณ 7 วันบน optimistic rollup รายใหญ่) แลกกับความเรียบง่ายของระบบ
อ่านเพิ่มเติม: Chainlink’s Wallet Record Turns LINK’s $9 Rebound Into The Main Test
Native Bridge เทียบกับ Third-Party Bridge
เมื่อคุณย้ายสินทรัพย์ระหว่างเลเยอร์ 1 กับเลเยอร์ 2 rollup คุณมักใช้ “native bridge” ซึ่งเป็นบริดจ์ที่สร้างและดูแลโดยทีม rollup เอง ผูกแน่นกับโมเดลความปลอดภัยของ rollup นั้น ๆ Arbitrum (ARB) มี native bridge ของตัวเอง, Optimism (OP) ก็มี native bridge ของตัวเอง และ native bridge ของ zkSync ก็อยู่ในกลุ่มนี้เช่นกัน
Native bridge สืบทอดการรับประกันด้านความปลอดภัยส่วนใหญ่จากตัว rollup เอง บน optimistic rollup การถอนที่เป็นการทุจริตสามารถถูกท้าทายได้ภายในช่วงเวลา fraud proof 7 วัน บน ZK rollup การถอนจะถูก final ก็ต่อเมื่อมีการโพสต์ ZK proof ที่ถูกต้องของ batch ธุรกรรมขึ้นบน Ethereum เท่านั้น การรับประกันเหล่านี้แข็งแกร่งกว่าส่วนใหญ่ของ third-party bridge อย่างมีนัยสำคัญ
ข้อแลกเปลี่ยนคือ native bridge มักจะไปได้แค่ทิศทางเดียว: จาก L1 ไป L2 และกลับ ไม่สามารถบริดจ์สินทรัพย์ Ethereum ไป Solana หรือนำสินทรัพย์ข้ามระหว่าง L2 สองตัวโดยตรงได้ สำหรับการเคลื่อนย้ายข้ามระบบนิเวศ เช่น จาก Ethereum ไป Solana หรือจาก Arbitrum ไป Polygon (POL) ผู้ใช้จำเป็นต้องใช้ third-party bridge ซึ่งมีความเสี่ยงจากตัวตรวจสอบและสัญญาอัจฉริยะตามที่อธิบายไปแล้วข้างต้น
สิ่งนี้สร้าง “ภาษีจำแนกประเภท” เชิงปฏิบัติขึ้นมา: ใช้ native bridge สำหรับการย้ายจาก L1 ไป L2 เมื่อต้องการให้ความสำคัญสูงสุดกับความปลอดภัย และใช้ third-party bridge ที่ผ่านการตรวจสอบ (audited) และมีประวัติการใช้งานที่ดีสำหรับการเคลื่อนย้ายข้ามระบบนิเวศ เมื่อคุณยอมรับความเสี่ยงเพิ่มเติมนั้น การตรวจดูว่าบริดจ์ถูก audit โดยบริษัทความปลอดภัยที่น่าเชื่อถือ (Trail of Bits, OpenZeppelin, Certik, Spearbit) หรือไม่ และทบทวนประวัติการถูกโจมตีในอดีต ถือเป็นการตรวจสอบขั้นต่ำที่ควรทำก่อนใช้บริการโอนข้ามเชนใด ๆ
อ่านเพิ่มเติม: Russian Hackers Found A Signal Weak Spot In Recovery Keys
ใครกันที่ “จำเป็นจริง ๆ” ต้องใช้บริดจ์
บริดจ์ไม่ได้จำเป็นสำหรับผู้ใช้คริปโตทั่วไปส่วนใหญ่ หากคุณถือ Bitcoin (BTC) หรือ Ethereum (ETH) อยู่บนกระดานเทรดแบบรวมศูนย์ และแค่อยากรับเอา “การเคลื่อนไหวของราคา” คุณจะไม่ต้องยุ่งกับบริดจ์เลย
คุณต้องใช้บริดจ์เมื่อต้องการใช้แอปพลิเคชันที่อยู่บนเชนคนละเชนกับที่สินทรัพย์ของคุณอยู่ หาก ETH ของคุณอยู่บน Ethereum mainnet แต่คุณอยากใช้โปรโตคอล DeFi บน Arbitrum คุณก็จะบริดจ์ผ่าน native bridge ของ Arbitrum หากคุณอยากใช้แอปบน Solana ที่รองรับเฉพาะ Solana แต่คุณมี USDC ที่เริ่มต้นมาจาก Ethereum คุณก็จะใช้ third-party bridge
นักพัฒนาที่สร้างแอปพลิเคชัน cross-chain คือกลุ่มผู้ใช้บริดจ์หนักที่สุด โปรโตคอลใดก็ตามที่ต้องการรวมสภาพคล่องจากหลายเชน หรือเกมใดก็ตามที่ต้องการให้ผู้เล่นใช้สินทรัพย์เดียวกันข้ามหลายเน็ตเวิร์ก จำเป็นต้องฝังโครงสร้างพื้นฐานด้านการบริดจ์เข้าไปในตัวโปรดักต์ นี่คือเหตุผลว่าทำไมโปรเจกต์อย่าง LayerZero, Axelar, Wormhole และ Hyperlane จึงวางตัวเองว่าเป็น “โปรโตคอลส่งข้อความแบบ omnichain” มากกว่าการเป็นแค่บริดจ์: พวกเขาคือโครงสร้างพื้นฐานสำหรับนักพัฒนา ไม่ใช่แค่ทางให้ผู้ใช้ปลายทางโอนโทเค็น
สำหรับผู้ใช้ทั่วไป แนวทางเชิงปฏิบัติค่อนข้างตรงไปตรงมา ใช้ canonical native bridge เมื่อย้ายระหว่าง L1 กับ L2 รายใหญ่ สำหรับ third-party bridge ให้จำกัดมูลค่าที่นำไปใช้ให้อยู่ในระดับที่คุณยอมเสียได้ ตรวจดูประวัติการ audit และให้ความสำคัญกับบริดจ์ที่ทำงานโดยไม่มีเหตุการณ์ผิดปกติเป็นเวลาอย่างน้อยหนึ่งปี ภายใต้ TVL ที่มีนัยสำคัญ แนวคิด “บริดจ์ช้า ๆ บริดจ์ทีละน้อย” ไม่ใช่ความขี้ขลาด แต่มันสะท้อนโปรไฟล์ความเสี่ยงที่แท้จริงของเทคโนโลยีในสภาพปัจจุบัน
อ่านเพิ่มเติม: Claude Fable 5 May Return As Washington Softens Anthropic Standoff
บทสรุป
บริดจ์ข้ามเชนแก้ปัญหาที่แท้จริงและเลี่ยงไม่ได้
บล็อกเชนแต่ละอันคือระบบอธิปไตยของตัวเอง หากไม่มีบริดจ์ คริปโตจะกลายเป็นกลุ่ม “ไซโลโดดเดี่ยว” ที่สินทรัพย์และแอปพลิเคชันไม่เคยมีปฏิสัมพันธ์กันเลย
ความสามารถในการทำงานร่วมกัน (interoperability) ที่บริดจ์สร้างขึ้นเป็นรากฐานของ DeFi ส่วนใหญ่ วงการเกมมิ่ง และระบบ multi-chain ที่โปรเจกต์อย่าง TAC กำลังสร้างให้เติบโตขึ้น
เหตุการณ์แฮ็กไม่ได้พิสูจน์ว่าบริดจ์ “เสียโดยเนื้อแท้”
มันพิสูจน์ว่างานออกแบบบริดจ์ยุคแรก ๆ ทำ “ดีลด้านความปลอดภัย” ที่ก้าวร้าวเกินไป — ตั้งคณะตัวตรวจสอบขนาดเล็ก ใช้ลอจิกสัญญาอัจฉริยะที่ไม่เคย audit พึ่งพา oracle — ซึ่งไม่สอดคล้องกับมูลค่ามหาศาลที่พวกมันต้องดูแลในภายหลัง
แต่ละการโจมตีครั้งใหญ่ได้ผลักดันอุตสาหกรรมไปสู่การออกแบบที่ดีกว่า: ชุดตัวตรวจสอบที่ใหญ่ขึ้น การตรวจสอบอย่างเป็นทางการ (formal verification) ระบบ proof แบบ ZK และ native rollup bridge ที่สืบทอดความปลอดภัยจาก L1 มาโดยตรง
อ่านต่อถัดไป: PUMP Gains 12% While Protocol Data Warns The Rebound May Be Fragile