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

เหตุการณ์ครั้งหนึ่งพรากไปไม่เพียงแต่สินทรัพย์ แต่ยังพรากความไว้วางใจไปด้วย คริปโตดำเนินต่อไปเช่นนี้ไม่ได้ เราต้องช่วยเหลือตัวเอง

ผู้เขียน: Robert Mao ผู้ก่อตั้งและ CEO ของ ArcBlock

บทความนี้ได้รับอนุญาตให้任何人ทำซ้ำและส่งต่อได้อย่างอิสระ โดยหวังว่าคนจำนวนมากจะได้เห็นเสียงเรียกร้องให้อุตสาหกรรมช่วยเหลือตัวเองนี้

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

เมื่อวันที่ 29 ตุลาคม 2026 ได้เกิดเหตุการณ์ด้านความปลอดภัยครั้งใหญ่ที่ Binance ประกาศเบื้องต้นประเมินว่าสินทรัพย์ประมาณ 6.3 พันล้านดอลลาร์ได้รับผลกระทบ และสินทรัพย์ที่ได้รับผลกระทบประมาณ 3 พันล้านดอลลาร์ถูกอายัดไว้ การสอบสวนชี้เบื้องต้นไปที่แล็ปท็อปของวิศวกร DevOps และต่อมาพบจุดบุกรุกที่เป็นไปได้อื่นๆ เพิ่มเติม Binance ยังระบุว่าไม่พบหลักฐานการรั่วไหลของกุญแจส่วนตัวของกระเป๋าเงิน จำนวนที่ได้รับผลกระทบไม่ใช่ความสูญเสียสุทธิขั้นสุดท้าย และห่วงโซ่การโจมตีทั้งหมดยังอยู่ระหว่างการสอบสวน [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)

ความคิดริเริ่มนี้มุ่งถึงผู้สร้างโครงการบล็อกเชน เช่น Ethereum และ Solana และยังมุ่งถึง Binance, Coinbase, Kraken และทุกตลาดแลกเปลี่ยน กระเป๋าเงิน โปรโตคอล และผู้สร้างด้านความปลอดภัยที่ยินดีเข้าร่วม: ให้เราร่วมกันสร้างรากฐานสำหรับการปกป้องสินทรัพย์ขึ้นใหม่ ผมยินดีเข้าร่วม และหวังว่าคนจำนวนมากจะลงมือร่วมกัน

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

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

เรายังต้องยอมรับว่าการหลอกลวงและแนวปฏิบัติที่เพียงสร้างแนวคิดโดยไม่รับผิดชอบต่อการสร้างได้สร้างความเสียหายแก่อุตสาหกรรมนี้มานานเกินไป ทีมที่สร้างเทคโนโลยีและโครงสร้างพื้นฐานอย่างจริงจังก็ต้องแบกรับผลกระทบจากความไว้วางใจที่สูญเสียไปร่วมกันด้วย เมื่อถึงเวลาที่ผู้คนมองว่า Crypto ทั้งหมดเป็นการหลอกลวง เทคโนโลยีและการสำรวจที่แท้จริงซึ่งควรค่าแก่การรักษาไว้อาจถูกทอดทิ้งไปพร้อมกัน

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

ในปี 2008 ซาโตชิ นากาโมโตะได้เสนอระบบเงินสดอิเล็กทรอนิกส์แบบเพียร์ทูเพียร์ โดยพยายามทำให้การชำระเงินพึ่งพาตัวกลางที่เชื่อถือได้น้อยลง [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) แต่เหตุการณ์สำคัญตั้งแต่นั้นมาก็ได้เผยให้เห็นปัญหาที่ว่าเงินทุน การอนุญาต และการพึ่งพาซอฟต์แวร์กลับมารวมศูนย์อีกครั้งซ้ำแล้วซ้ำเล่า

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

2008 · ไวท์เปเปอร์บิตคอยน์

จุดเริ่มต้น

ไวท์เปเปอร์บิตคอยน์เสนอการชำระเงินแบบเพียร์ทูเพียร์โดยไม่มีสถาบันการเงินเป็นตัวกลาง

แหล่งที่มา

2011–2014 · การโจรกรรมระยะยาวของ Mt. Gox

CEX

Mt. Gox ประสบการโจรกรรมระยะยาวและในที่สุดก็หยุดดำเนินการ ต่อมาการฟ้องร้องของกระทรวงยุติธรรมสหรัฐฯ กล่าวหาว่ามีการโจรกรรม BTC ประมาณ 647,000 BTC ระหว่างปี 2011 ถึง 2014 นี่ไม่ใช่การโจมตีในวันเดียวในปี 2014

แหล่งที่มา

2012 · Bitcoinica และ Bitfloor

CEX / โครงสร้างพื้นฐานการรับฝาก

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

แหล่งที่มา

2015 · กระเป๋าเงินร้อนของ Bitstamp

CEX

กระเป๋าเงินร้อนของ Bitstamp ถูกบุกรุก และสภาพแวดล้อมการดำเนินงานได้รับการสร้างใหม่ในภายหลัง การแยกแยะอย่างเป็นทางการระหว่างขอบเขตของเหตุการณ์และทุนสำรองออฟไลน์แสดงให้เห็นว่าการแยกส่วนสามารถจำกัดขอบเขตการเปิดเผยได้

แหล่งที่มา

2016 · Bitfinex

CEX

BTC ประมาณ 120,000 BTC ถูกโจรกรรมจาก Bitfinex การจัดการแบบหลายลายเซ็นยังคงต้องมีการอนุญาตและการตรวจสอบที่เป็นอิสระแบบครบวงจร

แหล่งที่มา 1 · แหล่งที่มา 2

2016 · The DAO

โปรโตคอลบนเชน

สัญญา The DAO ประสบการโจมตีแบบ reentrancy และ ETH ประมาณ 3.6 ล้าน ETH ถูกโอนไปยัง sub-DAO ซึ่งต่อมากระตุ้นให้เกิดการแยก Ethereum เส้นทางการดำเนินการที่ชอบด้วยกฎหมายสามารถก่อให้เกิดผลลัพธ์ทางธุรกิจที่หายนะได้

แหล่งที่มา 1 · แหล่งที่มา 2

2017 · ไลบรารีกระเป๋าเงินร่วมของ Parity

กระเป๋าเงินสัญญา

ไลบรารีกระเป๋าเงินร่วมของ Parity ถูกทำลาย และ ETH ประมาณ 513,000 ETH ถูกอายัด แม้จะไม่ถูกโอนออกไป เงินทุนก็สามารถกลายเป็นใช้ไม่ได้เนื่องจากความสัมพันธ์แบบพึ่งพาโค้ดร่วมกัน

แหล่งที่มา

2018 · Coincheck

CEXกระเป๋าเงินร้อน NEM ของ Coincheck ถูกขโมย เส้นแบ่งระหว่างเงินสำรองออฟไลน์ สิทธิ์ของกระเป๋าเงินร้อน และความจำเป็นทางธุรกิจ กลายเป็นปัญหาอีกครั้ง

แหล่งที่มา

2019 · Binance

CEX

Binance ประกาศว่ามีการถอน 7,000 BTC ในธุรกรรมเดียว การไหลออกของสินทรัพย์ขนาดใหญ่จำเป็นต้องถูกจำกัดก่อนการลงนาม

แหล่งที่มา

2020 · KuCoin

CEX

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

แหล่งที่มา

2021 · Poly Network

โปรโตคอลข้ามเชน

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

แหล่งที่มา

2022 · Ronin bridge

บริดจ์

สิทธิ์ของ validator บน Ronin ถูกบุกรุก และ 173,600 ETH กับ 25.5 ล้าน USDC ถูกโอนออก กุญแจของ validator หลายรายก็สามารถตกอยู่ในห่วงโซ่การโจมตีเดียวกันได้เช่นกัน

แหล่งที่มา

2022 · กระเป๋าเงิน Slope

กระเป๋าเงิน

เหตุการณ์กระเป๋าเงิน Slope ในระบบนิเวศ Solana ทางการ Solana ระบุว่าข้อมูล private key ถูกส่งไปยังบริการตรวจสอบแอปพลิเคชันโดยไม่ตั้งใจ ไม่ใช่การบุกรุกฉันทามติของ Solana

แหล่งที่มา

2023 · Euler

โปรโตคอลการให้กู้

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

แหล่งที่มา

2023 · Ledger Connect Kit

เครื่องมือเชื่อมต่อกระเป๋าเงิน

Ledger Connect Kit เผชิญกับการโจมตีในห่วงโซ่อุปทาน และโค้ดอันตรายเข้าสู่ส่วนหน้าแอปพลิเคชัน ความปลอดภัยของอุปกรณ์ฮาร์ดแวร์ไม่สามารถทดแทนการตรวจสอบเนื้อหาธุรกรรมได้

แหล่งที่มา

2024 · DMM Bitcoin

CEX

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

แหล่งที่มา

2024 · Radiant Capital

โปรโตคอลการให้กู้ / การลงนาม

สินทรัพย์ประมาณ 50 ล้านดอลลาร์ถูกขโมยจาก Radiant Capital และอุปกรณ์ของนักพัฒนาหลายเครื่องถูกบุกรุก การลงนามหลายฝ่ายยังคงสามารถพึ่งพาข้อมูลธุรกรรมที่ปนเปื้อนร่วมกันได้

แหล่งที่มา

2025 · Bybit / Safe

CEX / ส่วนหน้ากระเป๋าเงิน

เหตุการณ์ Bybit ประมาณ 1.5 พันล้านดอลลาร์เกี่ยวข้องกับสภาพแวดล้อมนักพัฒนาและส่วนหน้าของ Safe และผู้ลงนามได้อนุมัติธุรกรรมที่เปลี่ยนแปลงตรรกะการควบคุมกระเป๋าเงิน

แหล่งที่มา 1 · แหล่งที่มา 2

2025 · Cetus DEX

DEXเหตุการณ์ประมาณ 223 ล้านดอลลาร์ที่ Cetus บน Sui โดยนักวิจัยชี้ไปที่ข้อบกพร่องในไลบรารีคณิตศาสตร์ สภาพแวดล้อมที่ไม่ใช่ EVM ก็ต้องตรวจสอบโค้ดและขอบเขตการเปิดรับสินทรัพย์เช่นกัน

แหล่งที่มา

2026-07 · ข้อบกพร่องตัวเลขสุ่มของ COLDCARD

กระเป๋าเงินฮาร์ดแวร์ / การสร้าง seedช่องโหว่ในเฟิร์มแวร์ทำให้การสร้างซีดอ่อนแอลง ทำให้ผู้โจมตีสามารถสร้างคีย์ส่วนตัวที่เกี่ยวข้องขึ้นมาใหม่ได้ขณะที่อุปกรณ์ออฟไลน์อยู่ การอัปเกรดไม่สามารถแก้ไขซีดที่อ่อนแอซึ่งถูกสร้างขึ้นแล้วได้ ยังคงต้องย้ายข้อมูลตามคำแนะนำ

แหล่งที่มา

2026-10 · การฝังอุปกรณ์ในฮาร์ดแวร์วอลเล็ต Ledger

การโจมตีผ่านฮาร์ดแวร์วอลเล็ต / ช่องทางการจัดจำหน่าย

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

แหล่งที่มา

2026 · เหตุการณ์หลายเชนของ Binance

CEX / หลายเชน

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

แหล่งที่มา 1 · แหล่งที่มา 2 · แหล่งที่มา 3

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

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

การมีส่วนร่วมของ Ethereum มีนัยสำคัญ มันทำให้ผู้คนจำนวนมากขึ้นสามารถเขียนแอปพลิเคชันบนเชน และส่งเสริมชุดเครื่องมือและประสบการณ์การพัฒนาที่หลากหลาย แต่ในปัจจุบัน เชนใหม่และ L2 (เครือข่ายขยายขนาดชั้นที่ 2) จำนวนมากถือว่าความเข้ากันได้กับ EVM เป็นเป้าหมายหลัก EVM ซึ่งเป็นเครื่องเสมือนที่ดำเนินการสัญญาอัจฉริยะของ Ethereum กำลังกลายเป็นข้อสมมติทางเทคนิคที่ถูกทำซ้ำอย่างแพร่หลาย ความเข้ากันได้ทำให้การย้ายแอปพลิเคชันสะดวกจริง เอกสารของโครงการอย่าง Unichain ระบุอย่างชัดเจนถึงการนำเครื่องมือของ Ethereum กลับมาใช้ใหม่เป็นคุณค่าของสภาพแวดล้อมการดำเนินการที่เทียบเท่า [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)

ฉันเชื่อว่าการปฏิบัติต่อความเข้ากันได้กับ EVM ในฐานะคำตอบเริ่มต้นของอุตสาหกรรมกำลังสร้างการรวมศูนย์ความเสี่ยงเชิงโครงสร้าง ชื่อเครือข่ายอาจมีได้หลายชื่อ และผู้ตรวจสอบอาจแตกต่างกัน แต่นักพัฒนาอาจปรับใช้สัญญาเดียวกันซ้ำ ใช้พฤติกรรมการอนุญาตเดียวกัน และพึ่งพาไลบรารีซอฟต์แวร์เดียวกัน ข้อผิดพลาดในdependency ที่ใช้ร่วมกันไม่หายไปเพียงเพราะการปรับใช้เกิดขึ้นบนเชนอื่น นี่คือการตัดสินเกี่ยวกับเส้นทางเทคนิค ไม่ใช่การกล่าวอ้างว่าทุกการใช้งาน EVM จำเป็นต้องมีช่องโหว่เดียวกันนี่คือจุดที่คำวิจารณ์ของผมต่อ Ethereum ตั้งอยู่เช่นกัน ความสามารถในการประมวลผลสัญญาแบบอเนกประสงค์เชื่อมต่อโดยตรงกับสินทรัพย์ที่โอนได้ ทำให้ความรับผิดชอบมหาศาลตกอยู่ที่โค้ดแอปพลิเคชันและการโต้ตอบกับกระเป๋าเงิน สัญญาสามารถเรียกสัญญาอื่นได้ การอนุญาตสามารถคงอยู่ได้เป็นเวลานาน และการยืนยันที่ดูเหมือนธรรมดาอาจเปลี่ยนโหมดการควบคุมบัญชีในภายหลัง ความปลอดภัยจึงขึ้นอยู่กับการที่ทุกทีมพัฒนาต้องเข้าใจการผสมผสานเหล่านี้อย่างถูกต้อง และขึ้นอยู่กับผู้ใช้ทุกคนต้องเข้าใจสิ่งที่ตนได้ลงนามอย่างถูกต้อง

EIP-7702 ทำให้ปัญหานี้ชัดเจนมาก การโอนทั่วไปคือ "ครั้งนี้โอนเท่าไรให้ใคร" ส่วนการอนุญาตมอบอำนาจอาจหมายถึง "จากนี้ไป ให้โค้ดชิ้นนี้ดำเนินการแทนบัญชีของฉัน" มันมีเป้าหมายในการปรับปรุงประสบการณ์ผู้ใช้และทำให้สิทธิ์ละเอียดขึ้น แต่การตั้งค่าการมอบอำนาจเองก็ให้ความสามารถในการดำเนินการในวงกว้าง และสิทธิ์แบบละเอียดยังต้องถูกนำไปใช้อย่างถูกต้องโดยโค้ดที่ได้รับมอบอำนาจ [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) งาน preprint เรื่อง "EIP-7702 Phishing Attack" ของ Minfeng Qi และคณะ ศึกษาวิถีทางการควบคุมบัญชีอย่างต่อเนื่องหลังจากชักจูงให้ลงนามในการอนุญาตดังกล่าว [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) เมื่อความสะดวกเพิ่มขึ้น ความรับผิดชอบด้านความปลอดภัยก็เพิ่มขึ้นเช่นกัน ส่วนformer ไม่สามารถมอบให้ผู้ใช้เพียงอย่างเดียวได้

เหตุการณ์ Binance ครั้งนี้ครอบคลุมหลายเชน และการสอบสวนยังไม่เสร็จสมบูรณ์ ดังนั้นผลกระทบทั้งหมดจึงไม่สามารถโยงโดยตรงไปที่ EIP-7702 หรือ EVM ได้ การเรียกซ้ำ (reentrancy) การถูกบุกรุกของบริการลงนาม และการแก้ไขส่วนหน้า (front-end tampering) ก็ไม่ใช่ช่องโหว่เดียวกัน แต่ความแตกต่างเช่นนี้ไม่ควรกลายเป็นข้ออ้างในการหยุดตั้งคำถามต่อสถาปัตยกรรม: ทำไมชั้นพื้นฐานจึงไม่คงข้อจำกัดที่ไม่อาจข้ามได้ง่ายๆ ไว้มากขึ้น เพื่อรับผิดชอบต่อข้อผิดพลาดในชั้นบน?

MEV ก็ทำให้ผมไม่พอใจเช่นกัน มันหมายถึงพื้นที่ที่ผู้เข้าร่วมได้รับมูลค่าเพิ่มผ่านการรวม การกีดกัน และการจัดลำดับธุรกรรม สำหรับผม การใช้อำนาจจัดลำดับเพื่อสอดแทรกธุรกรรมของผู้ใช้และทำให้ผลการดำเนินการแย่ลง ควรถูกมองว่าเป็นบั๊กที่ต้องแก้ไข ไม่ใช่ถูกห่อหุ้มเป็นคุณสมบัติที่ควรค่าแก่การรักษาเพียงเพราะมีคนได้กำไรจากมัน เอกสารของ Ethereum เองก็ยอมรับอย่างชัดเจนถึงอันตรายของการสอดแทรกธุรกรรมต่อผู้ใช้และความเสี่ยงของ MEV ต่อเสถียรภาพของเครือข่าย [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV ไม่ได้มีเฉพาะใน Ethereum และยังรวมถึงกิจกรรมที่แตกต่างกัน เช่น การเก็งกำไรส่วนต่าง (arbitrage) และการชำระบัญชี (liquidation) อุตสาหกรรมมีการวิจัยเรื่องมาตรการบรรเทาผลกระทบอยู่แล้ว คำวิจารณ์ของผมคือ แรงจูงใจในการรักษาเครือข่ายไม่สามารถกลายเป็นเหตุผลในการเสียสละเงื่อนไขธุรกรรมของผู้ใช้ ระบบธุรกรรมที่ดีกว่าควรเขียนผลลัพธ์การส่งมอบขั้นต่ำและค่าธรรมเนียมที่อนุญาตไว้ในการอนุญาต และจำกัดพื้นที่ให้ผู้จัดลำดับใช้ข้อมูลที่ยังไม่ถูกเติมเต็มเพื่อทำร้ายผู้ใช้ผมรู้สึกมาโดยตลอดว่าอิทธิพลของ Ethereum ที่มีต่อ Crypto นั้นคล้ายกับอิทธิพลของ PHP ที่มีต่ออินเทอร์เน็ตอยู่บ้าง: มันทำให้หลายคนสามารถสร้างสิ่งต่างๆ ได้ และในขณะเดียวกันก็ทิ้งหนี้ทางวิศวกรรมที่ต้องใช้เวลานานในการชดใช้ PHP ยังต้องแก้ไขช่องโหว่การรันโค้ดจากระยะไกลที่ร้ายแรงในเดือนตุลาคม 2026 ความ成熟และความนิยมไม่สามารถแทนที่การเสริมความแข็งแกร่งอย่างต่อเนื่องได้ [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) สิ่งที่มีคุณค่าของอินเทอร์เน็ตคือภาษา เฟรมเวิร์ก และบริการคลาวด์สามารถพัฒนาแยกจากกันได้ เราควรอนุญาตให้รูปแบบสินทรัพย์และวิธีการดำเนินการที่แตกต่างกันพัฒนาต่อไปเช่นกัน แทนที่จะถือว่า "ความเข้ากันได้กับเครื่องเสมือนเดียวกัน" เป็นตั๋วเข้าร่วมระบบนิเวศ

ดังนั้น ผมจึงเรียกร้องให้ระบบนิเวศ Bitcoin, Solana และ Ripple/XRP Ledger รวมถึงผู้สร้างอย่าง ArcBlock เข้าร่วมอย่างจริงจังในการสร้างรากฐานความปลอดภัยร่วมกัน การเข้าร่วมในมาตรฐานและความสามารถในการทำงานร่วมกันไม่จำเป็นต้องทำให้ตัวเองกลายเป็น Ethereum ก่อน ความหลากหลายต้องถูกนำไปใช้ในวิธีการควบคุมและการตรวจสอบสินทรัพย์ และต้องเปิดให้ตรวจสอบต่อสาธารณะ เหตุการณ์ Slope และ Cetus ได้เตือนเราแล้วว่า non-EVM ก็ไม่ได้รับการยกเว้นจากความปลอดภัยเช่นกัน

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

1. ให้การควบคุมความเสี่ยงระดับพื้นฐานจำกัดอำนาจในการจัดการสินทรัพย์

กระเป๋าเงินขนาดใหญ่ควรสามารถตั้งค่าบัญชีขาวของผู้รับ เพดานการใช้จ่ายสะสม และระยะเวลารอสำหรับผู้รับรายใหม่ได้ สิ่งสำคัญคือกฎเหล่านี้ไม่สามารถถูกยกเลิกได้ทันทีด้วยคีย์ธุรกรรมประจำวันเดียวกัน การแก้ไขกฎต้องได้รับการอนุญาตอย่างอิสระและต้องเหลือเวลาไว้สำหรับการตรวจสอบและเพิกถอนสมาร์ตแอคเคานต์ที่มีอยู่แล้วมีพื้นฐานการนำไปใช้ เช่น Safe Guards สามารถเพิ่มข้อจำกัดธุรกรรมเกินกว่ามัลติซิกได้ [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) เราจำเป็นต้องทำให้สิ่งนี้กลายเป็นความสามารถพื้นฐานที่นำไปใช้ได้ง่ายขึ้นและครอบคลุมเส้นทางการควบคุมสินทรัพย์ทั้งหมด หากจำกัดเพียงการโอนโดยตรง แต่ยังอนุญาตให้มีการเลี่ยงผ่านการอนุมัติแบบไม่จำกัด โมดูล หรือการอัปเกรด การป้องกันก็จะล้มเหลว ไม่ว่าจะสามารถอัปเกรดสัญญาไวท์ลิสต์ได้หรือไม่ และสิทธิ์ของผู้รับมีการเปลี่ยนแปลงหรือไม่ ก็ต้องเข้าสู่ขอบเขตการตรวจสอบด้วย

Activation Lock ของ Apple มอบแรงบันดาลใจในชีวิตประจำวัน: มันจำกัดการเปิดใช้งานอุปกรณ์ที่ถูกขโมยซ้ำ และจำกัดการสอบเทียบชิ้นส่วนที่ถูกขโมยบางส่วน โดยมีเป้าหมายเพื่อลดมูลค่าที่สามารถถูกใช้ประโยชน์ได้หลังการโจมตี [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) กระเป๋าเงินก็ควรค่าแก่การออกแบบในทิศทางนี้เช่นกัน หากผู้โจมตีได้รับคีย์ ช่วงของสินทรัพย์ที่สามารถแปลงเป็นเงินสดได้ก็ยังคงถูกจำกัด และผลตอบแทนที่คาดหวังจากการโจมตีอาจลดลง ความเสี่ยงเช่นการรบกวนบริการยังต้องได้รับการจัดการแยกต่างหาก

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

II. ทำให้กระเป๋าเงินแบกรับความรับผิดชอบด้านความปลอดภัย แทนที่จะเพียงแค่ส่งมอบคำช่วยจำ

ผมมีความไม่พอใจอย่างมากต่อระบบกระเป๋าเงินในปัจจุบัน: หากผลิตภัณฑ์ขอให้คนธรรมดาคัดลอกชุดคำศัพท์ กำหนดให้พวกเขาห้ามรั่วไหล หาย หรือถูกหลอกเอาไป และจากนั้นโยนความผิดทั้งหมดที่ตามมาให้เป็นความรับผิดชอบของผู้ใช้ ผมถือว่านี่คือการออกแบบที่ไม่รับผิดชอบ การดูแลตนเองควรให้การควบคุมแก่ผู้คน และควรให้ความสามารถในการป้องกันและการกู้คืนที่ใช้งานได้จริงแก่ผู้คนด้วย ไม่ควรกำหนดให้ผู้ใช้ทุกคนต้องกลายเป็นผู้เชี่ยวชาญด้านความปลอดภัยก่อน นี่ก็เป็นเกณฑ์ขั้นต่ำที่ Crypto ต้องข้ามไปเพื่อเข้าถึงผู้ใช้ธรรมดามากขึ้นเหตุการณ์ล่าสุดได้วางปัญหานี้ไว้บนโต๊ะอย่างตรงไปตรงมา ในเดือนตุลาคม 2026 Ledger ยืนยันว่าแฮกเกอร์ได้ดัดแปลงอุปกรณ์แท้แล้วส่งกลับเข้าสู่ตลาดผ่านช่องทางจัดจำหน่ายในเอเชียตะวันออกเฉียงใต้ โดยมีชิ้นส่วนที่ถูกฝังไว้ขโมย recovery words ระหว่างการตั้งค่าเริ่มต้น Ledger นิยามสิ่งนี้ว่าเป็นการโจมตีแบบกระจายเฉพาะพื้นที่หลังจากอุปกรณ์ออกจากโรงงาน มากกว่าการถูกบุกรุกของชิป ระบบปฏิบัติการ หรือเซิร์ฟเวอร์ของบริษัท [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) เหตุการณ์ในเดือนกรกฎาคมของ COLDCARD เกี่ยวข้องกับการที่เฟิร์มแวร์อ่อนแอการสร้าง seed: อุปกรณ์ไม่จำเป็นต้องถูกควบคุมจากระยะไกลเพื่อให้แฮกเกอร์สร้าง private key ที่เกี่ยวข้องขึ้นมาใหม่ได้ การอัปเดตเฟิร์มแวร์แก้ไขกระบวนการสร้างสำหรับอนาคต แต่ seed ที่อ่อนแอซึ่งถูกสร้างไปแล้วยังคงต้องย้ายข้อมูล [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)

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

เป้าหมายของการปรับปรุงควรเป็นวงจรชีวิตกระเป๋าเงินที่สมบูรณ์: วิธีสร้างคีย์ วิธีอธิบายธุรกรรม วิธีแยกสิทธิ์ และวิธีการกู้คืนทำงานอย่างไรหลังจากอุปกรณ์สูญหาย Account abstraction กล่าวคือการอนุญาตให้บัญชีตรวจสอบการอนุญาตผ่านกฎที่ตั้งโปรแกรมได้ และการสำรองข้อมูลแบบ threshold เช่น SLIP-39 ทั้งสองมีมาตรฐานและพื้นฐานการใช้งานอยู่แล้ว จึงไม่อาจกล่าวได้ว่าไม่มีใครในอุตสาหกรรมกำลังดำเนินการเรื่องนี้ [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) แต่เราจำเป็นต้องทำให้ความสามารถเหล่านี้กลายเป็นการป้องกันที่ผ่านการทดสอบและใช้งานง่าย แทนที่จะให้ผู้ใช้ประกอบแผนที่ซับซ้อนด้วยตนเอง

การทำให้ mnemonic words สับสนแบบง่ายๆ ไม่เพียงพอ ทิศทางที่น่าเชื่อถือกว่าประกอบด้วยการสำรองข้อมูลแบบเข้ารหัสที่ผ่านการตรวจสอบ การกู้คืนแบบ threshold และการอนุญาตอุปกรณ์อิสระ และให้ผู้ใช้ทำการฝึกซ้อมกู้คืนก่อนฝากสินทรัพย์จำนวนมาก ชิ้นส่วนสำรองข้อมูลและ multisig เป็นเลเยอร์ที่แตกต่างกัน: อดีตอาจรวมตัวกลับเป็นความลับเดียวกันระหว่างการกู้คืน ในขณะที่หลังต้องให้ผู้ลงนามอิสระหลายรายอนุมัติธุรกรรม บริการกู้คืนต้องไม่กลายเป็น master key ใหม่โดยไม่ส่งเสียง และรหัสผ่านเพิ่มเติมก็ไม่ควรกลายเป็นกับดักอีกอย่างที่การสูญหายหมายถึงการสูญเสียที่ไม่สามารถกู้คืนได้กระเป๋าเงินส่วนบุคคลและระบบกระเป๋าเงินของศูนย์ซื้อขายสามารถใช้ข้อกำหนดด้านความปลอดภัยร่วมกันสำหรับคำอธิบายธุรกรรม คำขอลงนาม ข้อจำกัดของสินทรัพย์ และกระบวนการกู้คืน ขณะเดียวกันก็ใช้ขีดจำกัดและนโยบายการอนุมัติที่แตกต่างกัน PSBT ของบิตคอยน์ได้จัดเตรียมรูปแบบสำหรับการส่งธุรกรรมที่ยังไม่ได้ลงนามข้ามเครื่องมือต่างๆ และอินเทอร์เฟซร่วมนี้สมควรได้รับการพัฒนาต่อไป [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) สิ่งที่เป็นร่วมกันคือข้อกำหนดด้านความปลอดภัยที่ตรวจสอบได้ แต่ละเชนยังคงต้องชี้แจงกฎการปรับใช้ของตนเอง กระเป๋าเงินควรนำเสนออย่างชัดเจนว่าการลงนามนี้จะโอนอะไรและให้อำนาจแก่ใครในระดับใดในภายหลัง และนโยบายอิสระควรปฏิเสธการดำเนินการที่เกินขอบเขต หน้า confirmation ที่สวยงามขึ้นนั้นไม่เพียงพอ

III. บรรลุความสามารถในการตรวจสอบได้ด้วยการเปิดเผยข้อมูลเท่าที่จำเป็นน้อยที่สุด

การพิสูจน์ว่าเงื่อนไขหนึ่งเป็นจริงไม่ควรต้องให้ผู้ใช้เปิดเผยข้อมูลพื้นฐานทั้งหมดเสมอไป การเปิดเผยแบบเลือกได้ การพิสูจน์แบบไม่เปิดเผยข้อมูล (zero-knowledge proofs) และการให้สิทธิ์เข้าถึงเพื่อการตรวจสอบตามความต้องการ ควรกลายเป็นตัวเลือกปกติในโครงสร้างพื้นฐาน สิ่งนี้ยังเกี่ยวข้องกับความปลอดภัยของสินทรัพย์ด้วย: ตัวตนสาธารณะและความสัมพันธ์ของสินทรัพย์อาจให้เบาะแสสำหรับการหลอกลวงแบบเจาะจง ข้อมูลที่ธุรกิจไม่จำเป็นควรถูกเปิดเผยให้น้อยที่สุดเท่าที่จะเป็นไปได้

ระบบ verifiable credential ของ W3C มีเส้นทางทางเทคนิคสำหรับการเปิดเผยแบบเลือกได้อยู่แล้ว อย่างไรก็ตาม การพิสูจน์ว่าข้อมูลนำเข้ามีความถูกต้อง credential ยังคงใช้ได้ และสถานะถูกเพิกถอนอย่างไรนั้นยังคงต้องชี้แจง [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) การนำ zero-knowledge proofs (ZK) มาใช้ไม่ได้ซ่อนจำนวนและความสัมพันธ์ของธุรกรรมโดยอัตโนมัติ การพิสูจน์เพื่อการขยายขนาดและการปกป้องความเป็นส่วนตัวเป็นเป้าหมายที่แตกต่างกัน

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

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

IV. ทำให้บริการธุรกรรมปลอดจากการดูแลแบบรวมศูนย์มากที่สุดเท่าที่จะเป็นไปได้การจับคู่คำสั่งซื้อ การค้นหาเส้นทาง และการชำระบัญชีสินทรัพย์ ควรได้รับการออกแบบแยกจากกัน บริการที่ให้จุดเข้าใช้งานสำหรับการซื้อขายควรได้รับเฉพาะสิทธิ์ที่จำเป็นต่อการทำธุรกรรมชำระบัญชีปัจจุบันให้สำเร็จเท่านั้น เท่าที่จะเป็นไปได้ เพื่อให้สินทรัพย์ของผู้ใช้ยังคงอยู่ภายใต้การควบคุมของแต่ละฝ่ายในช่วงเวลาที่เหลือ โปรโตคอลธุรกรรมแบบอิงเจตนาที่มีอยู่ได้สำรวจเส้นทางนี้ไปแล้วบางส่วน และอุตสาหกรรมสามารถดำเนินการต่อให้สมบูรณ์ได้ [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)

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

IBIT เป็นผลิตภัณฑ์ซื้อขายแลกเปลี่ยนบิตคอยน์ของ iShares และสิ่งที่ซื้อขายในตลาดคือหุ้นของผลิตภัณฑ์นี้ การจัดวางของผลิตภัณฑ์นี้เป็นตัวอย่างของการแยกบางส่วน: หุ้นและบิตคอยน์อ้างอิงถูกบันทึกแยกจากกัน และคีย์ส่วนตัวที่เกี่ยวข้องกับ Vault Balance (ยอดคงเหลือในการดูแล) ถูกเก็บไว้ในที่จัดเก็บแบบออฟไลน์ การเปลี่ยนแปลงในบันทึกการซื้อขายหุ้นไม่จำเป็นต้องให้บิตคอยน์อ้างอิงเคลื่อนย้ายตามทุกธุรกรรม [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) สิ่งที่สามารถเรียนรู้ได้จากสิ่งนี้คือการแยกสิทธิ์ในการซื้อขายและสิทธิ์ในการจัดการเงินสำรอง Trading Balance (ยอดคงเหลือของบริการซื้อขาย) มีการจัดวางที่แตกต่างออกไป และการดูแลเองก็มีความเสี่ยงเช่นกัน การจัดเก็บแบบออฟไลน์ต้องจับคู่กับการตรวจสอบคำสั่งและลายเซ็นที่เป็นอิสระ

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

V. ใช้สถาปัตยกรรมแบบแบ่งชั้นเพื่อแยกความล้มเหลวและรักษาความสามารถในการแทนที่เราต้องการอินเทอร์เฟซสำหรับระบุตัวตนและการอนุญาต นโยบายสินทรัพย์ และวิธีการตรวจสอบการชำระบัญชีที่สามารถพัฒนาได้อย่างอิสระ แต่ละเชนสามารถคงรูปแบบการประมวลผลของตนเองและเชื่อมต่อผ่านอินเทอร์เฟซที่ชัดเจน อินเทอร์เฟซควรระบุการรับประกันความปลอดภัยและเงื่อนไขของการรับประกันนั้น ไม่ใช่เพียงบอกว่า "การเรียกสำเร็จ" ประสบการณ์จากอินเทอร์เน็ตสนับสนุนแนวทางนี้ ใน RFC 9518 เรื่อง "Centralization, Decentralization, and Internet Standards" Mark Nottingham ได้กล่าวถึงโดยเฉพาะถึงสถานการณ์ที่การรวมศูนย์สามารถเป็นประโยชน์ และยังวิเคราะห์ถึงอำนาจและความเสี่ยงที่มันนำมาด้วย [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) นี่คือทัศนคติที่ควรค่าแก่การเรียนรู้: ให้สถาปัตยกรรมเป็นผู้ตอบว่าความรับผิดชอบใดสามารถรวมศูนย์ได้ ในระดับใด และจะป้องกันไม่ให้อำนาจนั้นขยายตัวได้อย่างไร บริการหนึ่งอาจได้รับอนุญาตให้ระบุความผิดปกติแบบรวมศูนย์ได้ ในขณะที่สิทธิ์ในการแตะต้องสินทรัพย์ถูกจำกัด ผู้ใช้ควรสามารถสลับบริการได้โดยไม่สูญเสียนโยบายสินทรัพย์และบันทึกการตรวจสอบของตนเอง

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

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

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

6. ให้ผู้ใช้ตรวจสอบสินทรัพย์ของตนเองได้อย่างเบาๆ

คนทั่วไปไม่ควรต้องจัดเก็บและประมวลผลประวัติทั้งหมดของทั้งเชนเพื่อตรวจสอบยอดคงเหลือและใบเสร็จของตนเอง และไม่ควรต้องเชื่อถือเพียงเซิร์ฟเวอร์เดียวที่อยู่เบื้องหลังกระเป๋าเงิน ซาโตชิ นากาโมโตะได้เสนอ SPV หรือการตรวจสอบการชำระเงินแบบง่ายไว้แล้วในส่วนที่ 8 ของไวท์เปเปอร์ BIP-157 ของบิตคอยน์ยังคงสำรวจการให้ไคลเอนต์ดาวน์โหลดฟิลเตอร์และค้นหาบล็อกที่เกี่ยวข้องกับตนเองต่อไป อีเธอเรียมก็มีการออกแบบไคลเอนต์แบบเบาเช่นกัน [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) ดังนั้นปัญหาจึงไม่ใช่ว่าไม่มีใครเคยคิดถึงมัน แต่คือเรายังต้องสร้างความสามารถในการตรวจสอบที่มีเงื่อนไขความปลอดภัยชัดเจนไว้ในกระเป๋าเงินที่ผู้ใช้ใช้ทุกวันยกตัวอย่างเชนที่รองรับการพิสูจน์สถานะบัญชี: เมื่อสอบถามยอดคงเหลือ เซิร์ฟเวอร์ควรส่งคืนทั้งยอดคงเหลือและการพิสูจน์ กระเป๋าเงินจะตรวจสอบไดเจสต์บล็อกแบบสั้นก่อน กล่าวคือส่วนหัวบล็อก ตามกฎของเชนนั้น จากนั้นจึงตรวจสอบว่ายอดคงเหลือนี้สอดคล้องกับข้อมูลที่ไดเจสต์ผูกพันไว้หรือไม่ เซิร์ฟเวอร์ให้คำตอบ และกระเป๋าเงินสามารถตรวจสอบคำตอบได้ SPV ของบิตคอยน์ตรวจสอบหลักฐานว่าธุรกรรมที่เกี่ยวข้องถูกรวมไว้ในบล็อกแล้ว แต่ไม่สามารถคัดลอกมาใช้เป็นหลักฐานยอดคงเหลือได้โดยตรง กระเป๋าเงินควรแสดงอย่างชัดเจนว่าซิงค์ไปถึงจุดใดและข้อมูลใดได้รับการตรวจสอบแล้ว เมื่อหลักฐานขาดหาย ข้อมูลล้าสมัย หรือแหล่งข้อมูลขัดแย้งกัน ควรแจ้งเตือนหรือหยุดการดำเนินการที่มีความเสี่ยงสูงซึ่งพึ่งพาข้อมูลนี้ และต้องไม่ถอยกลับไปสู่ความเชื่อแบบไม่ตรวจสอบโดยไม่แจ้งให้ทราบ

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

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

7. สร้างการระบุความผิดปกติและการตรวจสอบความปลอดภัยให้เป็นโครงสร้างพื้นฐานสาธารณะ

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

ในขณะเดียวกัน เราจำเป็นต้องร่วมกันดูแลกรณีการโจมตี การทดสอบสิทธิ์ และเครื่องมือตรวจสอบที่สามารถรันซ้ำได้ การแบ่งปันข้อกำหนดและการรักษาการใช้งานอิสระและการตรวจสอบอิสระเท่านั้นจึงจะลดความล้มเหลวแบบร่วมกันได้ มูลนิธิและตลาดแลกเปลี่ยนมีการลงทุนด้านความปลอดภัยอยู่แล้ว เช่น โครงการ Trillion Dollar Security Initiative ของมูลนิธิ Ethereum [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) คำถามถัดไปที่ต้องถามคือ การลงทุนนั้นสามารถเปลี่ยนเป็นโครงสร้างพื้นฐานสาธารณะที่ทีมอื่นสามารถนำไปใช้และตรวจสอบได้หรือไม่ไม่มีรายการงานทั้งเจ็ดนี้ที่สามารถรับประกันความปลอดภัยโดยสมบูรณ์ได้ สิ่งที่พวกเขาต้องส่งมอบคือขอบเขตที่ตรวจสอบได้: ภายใต้เงื่อนไขการถูกบุกรุกสิทธิ์ใด ทรัพย์สินจะถูกเปิดเผยมากที่สุดเท่าใด ความผิดปกติจะถูกค้นพบได้เร็วเพียงใด และการกู้คืนยังต้องพึ่งพาใคร

ถึงจุดนี้ บางคนอาจกล่าวว่า: ทิศทางฟังดูถูกต้อง แต่ทั้งอุตสาหกรรมดำเนินมากี่ปีแล้ว การสร้างใหม่จะต้องใช้คนจำนวนเท่าใดและเวลาเท่าใด นี่ไม่ใช่ลัทธิอุดมคติอีกหรือ

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

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

งานวิจัยของ Anthropic และ PNNL ให้ตัวอย่างที่เป็นรูปธรรม: ในสภาพแวดล้อมจำลองโครงสร้างพื้นฐานสำคัญที่จำกัด นักวิจัยรายงานว่าการสร้างเส้นทางการโจมตีใหม่ลดลงจากที่อาจใช้เวลาหลายสัปดาห์เหลือประมาณสามชั่วโมง [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) มันไม่สามารถพิสูจน์ได้ว่าทีมเล็กๆ สามารถเขียนใหม่ทั้งอุตสาหกรรมได้อย่างปลอดภัยแล้ว แต่แสดงให้เห็นว่างานตรวจสอบและงานรุก-defense ที่เคยมีต้นทุนสูงสามารถมีเงื่อนไขต้นทุนใหม่ได้

แนวทางองค์กรหนึ่งที่สามารถเริ่มได้ตอนนี้คือการร่วมกันสร้าง Build in Public AI Factory ผู้เชี่ยวชาญในอุตสาหกรรม นักวิชาการ และผู้ปฏิบัติงานเขียนข้อกำหนดและข้อกำหนดการยอมรับ (spec) อย่างเปิดเผย อธิบายว่าสิ่งใดต้องได้รับการปกป้อง การดำเนินการใดได้รับอนุญาต และขอบเขตใดยังต้องคงอยู่หลังจากสิทธิ์ใดถูกบุกรุก แล้วเปลี่ยนข้อกำหนดเหล่านี้เป็นการทดสอบการยอมรับ กลุ่มของ coding agents รับงานเขียนโค้ด ทดสอบ และดีบักหลัก ทีมต่างๆ ตรวจสอบการออกแบบและผลลัพธ์ และมนุษย์รับผิดชอบการตัดสินใจและการยอมรับผู้เข้าร่วมสามารถร่วมเสนอไอเดีย เครื่องจักร พลังประมวลผล และโควตาการเรียกใช้โมเดล หรือก็คือ AI โทเคน บริษัท AI และคลาวด์คอมพิวติ้งยังสามารถสนับสนุนการก่อสร้างสาธารณะนี้ผ่านโควตาโมเดล ทรัพยากรการประมวลผล และเครื่องมือ สเปก โค้ดต้นแบบ เวิร์กโฟลว์ของเอเจนต์ สภาพแวดล้อมการทดสอบ และผลการตรวจสอบ ทั้งหมดนี้สามารถกลายเป็นโครงสร้างพื้นฐานที่ดูแลร่วมกันได้ ทำให้ทีมถัดไปสามารถทำงานต่อได้โดยตรงจากจุดนั้น เป้าหมายคือการสร้างขีดความสามารถในการพัฒนาให้เป็นสิ่งอำนวยความสะดวกสาธารณะที่นำกลับมาใช้ใหม่ได้ และลดการพึ่งพาเวลาของบุคคลใดบุคคลหนึ่งหรือทีมใดทีมหนึ่ง

ผู้โจมตีก็ใช้ AI เช่นกัน และเราไม่มีเหตุผลที่จะปล่อยให้การป้องกันยังคงอยู่ในวิธีการผลิตแบบเดิมอีกต่อไป [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) แต่การสร้างโค้ดได้อย่างรวดเร็วเป็นเพียงจุดเริ่มต้นเท่านั้น การจะเปลี่ยนขีดความสามารถของ AI ให้เป็นการปรับปรุงโครงสร้างพื้นฐานได้นั้น จำเป็นต้องเขียนข้อจำกัดให้ชัดเจน ทำให้การทดสอบสามารถรันซ้ำได้ และทำให้คอมโพเนนต์สามารถตรวจสอบและแทนที่ได้

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

ผมไม่เชื่อว่าอุตสาหกรรมนี้ขาดคนเก่ง และไม่เชื่อว่าอุตสาหกรรม Crypto และ AI จะหาทรัพยากรมาสนับสนุนงานนี้ไม่ได้ สิ่งที่ยากกว่าคือการจัดระเบียบ talent เงินทุน และความรับผิดชอบที่ยั่งยืนให้อยู่ด้วยกัน มูลนิธิและบริษัทที่มีความสามารถควรยินดีแบกรับต้นทุนระยะยาวของงานพื้นฐานที่ไม่สร้างรายได้โดยตรงแต่เป็นประโยชน์ต่อทุกคน

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

เราควรสร้างโครงสร้างพื้นฐานชนิดที่แม้บางส่วนถูกบุกรุก สินทรัพย์ยังคงมีขอบเขต ระบบอื่นยังคงปฏิเสธข้อผิดพลาดได้ และผู้ใช้ยังคงมีเส้นทางสู่การกู้คืนและการออกไป ยืมชื่อจาก Star Wars นี่คือ A New Hope ของเรา [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) ความหวังมาจากผู้สร้างธรรมดาที่เต็มใจลงมือทำ และยังมาจากช่วงเวลานี้ที่เอเจนต์เขียนโค้ดและวิธีการทางวิศวกรรมใหม่ ๆ ทำให้พวกเขาสามารถรับงานก่อสร้างได้มากขึ้นฉันขอเชิญชวนผู้สร้างโครงการอย่าง Ethereum, Solana, Bitcoin และ XRP Ledger ตลอดจนตลาดแลกเปลี่ยนอย่าง Binance, Coinbase และ Kraken รวมถึงทีมกระเป๋าเงิน โปรโตคอล การวิจัยความปลอดภัย AI และคลาวด์คอมพิวติ้ง: เริ่มต้นด้วยโครงการนำร่องที่มีขอบเขตชัดเจนและร่วมกันสร้างการปรับปรุงที่ทีมอื่นสามารถนำไปใช้และทดสอบได้

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

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

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

ฉันยินดีเข้าร่วมในการจัดระเบียบข้อกำหนดด้านการจำกัดและการกู้คืนสินทรัพย์ในบทความนี้ให้เป็นข้อกำหนดสาธารณะฉบับแรก และฉันก็ยินดีมีส่วนร่วมในแนวปฏิบัติทางเทคนิคและวิศวกรรมที่เกี่ยวข้องเพื่อสร้าง AI Factory สาธารณะสำหรับโครงการนำร่องนี้ร่วมกับผู้เข้าร่วมคนอื่น ๆ ก่อนอื่นให้เลือกปัญหาที่เฉพาะเจาะจงมาก: เมื่อคีย์ธุรกรรมประจำวันถูกบุกรุกแล้ว จะยังป้องกันไม่ให้ผู้โจมตีดูดเงินออกจากกระเป๋าเงินทั้งหมดในคราวเดียวได้อย่างไร? เขียนช่วงความสูญเสียที่อนุญาต อำนาจในการแก้ไขกฎ และเงื่อนไขการกู้คืนลงใน Acceptance Tests จากนั้นให้ Development Agents สร้างต้นแบบ และให้กลุ่ม Agents อีกกลุ่มและนักวิจัยอิสระค้นหาเส้นทางหลบเลี่ยง เซิร์ฟเวอร์ข้อมูลที่ส่งคืนยอดคงเหลือไม่ถูกต้อง และการกู้คืนหลังสูญหายอุปกรณ์ ก็สามารถค่อย ๆ เพิ่มเข้าไปในการทดสอบได้ สิ่งที่ต้นแบบทำได้ จุดที่ล้มเหลว และสิ่งที่ยังต้องพึ่งพาอยู่ ควรได้รับการอธิบายต่อสาธารณะทั้งหมด และตัดสินใจขั้นตอนต่อไปบนพื้นฐานของหลักฐาน

ผู้ที่ยินดีเข้าร่วมสามารถโพสต์หรืออ้างอิงความคิดริเริ่มนี้ต่อสาธารณะบน X และ @mave99a และพูดคุยเกี่ยวกับปัญหาที่คุณต้องการแก้ไข กรณีการโจมตีที่ผ่านการปกปิดข้อมูล หรือทรัพยากรที่คุณสามารถมีส่วนร่วม ฉันหวังว่าการอภิปรายจะเป็นไปอย่างเปิดเผย เพื่อให้ผู้สร้างมากขึ้นได้เห็นและเข้าร่วม

Crypto ไม่สามารถดำเนินต่อไปเช่นนี้ได้ ผู้ที่ยินดีร่วมมือกัน มาร่วมลงมือตอนนี้ เริ่มต้นด้วยการปรับปรุงหนึ่งอย่างที่สามารถสร้างได้และสามารถทนต่อการทดสอบได้Binance, โพสต์ประกาศอย่างเป็นทางการครั้งแรกและการอัปเดตอย่างเป็นทางการจากการสอบสวนติดตามผล, 2026-10-30; การวิเคราะห์หลายเชนของ TRM ฉบับร่างนี้ได้รับการตรวจสอบ ณ วันที่ 2026-10-30; สถานะการสอบสวนและการกู้คืนอาจเปลี่ยนแปลงได้ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)

Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008 [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)

Uniswap, Unichain EVM Equivalence การกระจุกตัวของความเสี่ยงจาก dependency ที่ใช้ร่วมกันเป็นดุลยพินิจของผู้เขียนในบทความนี้ ไม่ใช่ข้อสรุปของเอกสารดังกล่าว [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)

Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, สร้างเมื่อ 2024-05-07 [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)

Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 preprint; ไม่ใช่การระบุว่าเป็นเหตุการณ์ Binance ครั้งนี้ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)

Ethereum, Maximal extractable value (MEV), กลไกการจัดลำดับ, ประเภทต่างๆ และผลกระทบเชิงลบ; "ควรได้รับการแก้ไขในฐานะบั๊ก" เป็นจุดยืนเชิงวิศวกรรมของผู้เขียนต่อพฤติกรรมที่สร้างความเสียหายแก่ผู้ใช้ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)

คลังข่าวอย่างเป็นทางการของ PHP ปี 2026; การอัปเดต Known Exploited Vulnerabilities ของ CISA 2026-10-26, CVE-2026-109618, CVE-2026-109619 [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)

Safe, Guards and Modules, คำอธิบายฟังก์ชันการทำงานและความเสี่ยงด้านสิทธิ์ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)

Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; คำอธิบายการรองรับ parts pairing ในปัจจุบัน [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, แถลงการณ์ของผู้จำหน่ายเกี่ยวกับการโจมตีในห่วงโซ่การจัดจำหน่าย; Joe Grand, งานวิจัย reverse engineering เกี่ยวกับ hardware implant อย่านำเสนอประมาณการความสูญเสียบนเครือข่ายที่ยังไม่ได้รับการยืนยันว่าเป็นข้อสรุปที่แน่ชัด [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)

Coinkite, Current COLDCARD Security Status, เข้าถึงเมื่อ 2026-10-30, บันทึกที่อัปเดตอย่างต่อเนื่องของเหตุการณ์ในเดือนกรกฎาคม 2026 และการแก้ไข; การอัปเกรดและการย้าย seed เป็นการดำเนินการที่แตกต่างกันสองอย่าง [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)

ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, การกู้คืนแบบ threshold, ความเข้ากันได้ และความเสี่ยงเพิ่มเติมของ passphrase กลไกที่มีอยู่เป็นรากฐานสำหรับการสร้าง และไม่ได้หมายความว่าทุกการติดตั้งใช้งานจะเชื่อถือได้ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: รูปแบบธุรกรรม Bitcoin ที่ลงนามบางส่วน (Partially Signed Bitcoin Transaction Format) เป็นรูปแบบการแลกเปลี่ยนสำหรับธุรกรรมที่ยังไม่ได้ลงนาม ไม่ใช่ข้อกำหนดกลยุทธ์สินทรัพย์ทั่วไปข้ามเชน [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)

W3C, ภาพรวมข้อมูลรับรองที่ตรวจสอบได้ v1.0, 2026-07-30 Group Note; บันทึกความเป็นส่วนตัวของ Ethereum สถานะมาตรฐานของเทคโนโลยีที่อธิบายในภาพรวมเป็นอิสระในแต่ละกรณี [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)

เอกสาร CoW Protocol, เจตนาของธุรกรรมและกลไก solver; บทความนี้ไม่ได้ให้การรับรองความปลอดภัยอย่างครอบคลุมสำหรับการติดตั้งใด ๆ โดยเฉพาะ [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)

iShares, รายงานประจำปี IBIT 2025, หน้า PDF 8–10 ข้อตกลงการดูแลรักษาทรัพย์สิน และหน้า 45 การเปิดเผยความเสี่ยง [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)

Mark Nottingham, RFC 9518: การรวมศูนย์ การกระจายศูนย์ และมาตรฐานอินเทอร์เน็ต, 2023-12, ส่งโดยอิสระ, RFC เชิงข้อมูล, ไม่ใช่ข้อกำหนดในเส้นทางมาตรฐาน [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)

Bitcoin whitepaper หมวด 8 การตรวจสอบการชำระเงินแบบง่าย; BIP-157: การกรองบล็อกฝั่งไคลเอนต์; Ethereum, ไคลเอนต์แบบเบา ไคลเอนต์แบบเบาที่แตกต่างกันมีขอบเขตการตรวจสอบและเงื่อนไขความเชื่อถือที่แตกต่างกัน [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)

Ethereum Foundation, ประกาศโครงการความปลอดภัยระดับล้านล้านดอลลาร์, 2025-05-14 [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)

Anthropic, AI เพื่อปกป้องโครงสร้างพื้นฐานที่สำคัญ, 2026-01-08, การวิจัยในสภาพแวดล้อมจำกัดร่วมกับ PNNL [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)

Anthropic, การทำแผนที่ภัยคุกคามไซเบอร์ที่ขับเคลื่อนด้วย AI, การวิจัยเกี่ยวกับตัวอย่างการใช้งานในทางที่ผิดจริง [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)

Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; บทความนี้ยืมชื่อเรื่องและภาพลักษณ์ของการช่วยเหลือตนเองร่วมกัน [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)