727 FinanceMột sự cố không chỉ lấy đi tài sản mà còn lấy đi niềm tin. Crypto không thể tiếp tục như thế này; chúng ta phải tự cứu lấy mình.
Tác giả: Robert Mao, Người sáng lập và CEO của ArcBlock
Bài viết này được phép cho bất kỳ ai tự do sao chép và chuyển tiếp, với hy vọng nhiều người hơn sẽ thấy lời kêu gọi này để ngành công nghiệp tự cứu mình.
Crypto không thể tiếp tục như thế này. Hết lần này đến lần khác, những vụ trộm cắp quy mô lớn không chỉ lấy đi tài sản mà còn lấy đi niềm tin của những người tham gia vào toàn bộ ngành công nghiệp. Chúng ta phải tự cứu mình.
Vào ngày 29 tháng 10 năm 2026, một sự cố bảo mật nghiêm trọng đã xảy ra tại Binance. Thông báo sơ bộ của họ ước tính khoảng 6,3 tỷ USD tài sản bị ảnh hưởng, và khoảng 3 tỷ USD trong số tài sản bị ảnh hưởng đã bị đóng băng; cuộc điều tra ban đầu chỉ ra máy tính xách tay của một kỹ sư DevOps, và sau đó các điểm xâm nhập khả thi khác cũng được phát hiện. Binance cũng tuyên bố rằng không tìm thấy bằng chứng về việc rò rỉ khóa riêng tư của ví. Số tiền bị ảnh hưởng không phải là tổn thất ròng cuối cùng, và toàn bộ chuỗi tấn công vẫn đang được điều tra. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Sáng kiến này dành cho những người xây dựng các dự án blockchain như Ethereum và Solana, và cũng dành cho Binance, Coinbase, Kraken, và tất cả các sàn giao dịch, ví, giao thức, và những người xây dựng bảo mật sẵn sàng tham gia: hãy cùng nhau xây dựng lại nền tảng để bảo vệ tài sản. Tôi sẵn sàng tham gia, và tôi hy vọng nhiều người hơn sẽ cùng hành động.
Điều này đã đủ nặng nề. Nhưng điều khiến tôi lo lắng hơn là sự cố này sẽ phá hủy bao nhiêu niềm tin vào Crypto, và sẽ khiến bao nhiêu kẻ tấn công coi ngành công nghiệp này là mục tiêu vẫn đáng để tiếp tục tấn công. Ngay cả khi ai đó cuối cùng phải gánh chịu tổn thất, việc bồi thường không thể tự động sửa chữa niềm tin của người dùng, cũng không thể ngăn chặn sự phá hủy tương tự xảy ra lần nữa.
Binance chỉ là điểm khởi đầu buộc chúng ta phải đối mặt với vấn đề ngày hôm nay. Nhìn xa hơn, các sàn giao dịch, cầu nối, giao thức trên chuỗi, và ví đã để lại một vết thương dài từ lâu. Các mạng lưới và sản phẩm mới liên tục xuất hiện, nhưng các phương thức thất bại cũ lặp đi lặp lại. Chúng ta không thể đưa ra một thông báo, chờ một thời gian, rồi coi sự cố tiếp theo là chuyện thường ngày.
Chúng ta cũng phải thừa nhận rằng các trò lừa đảo và thực tiễn chỉ tạo ra khái niệm mà không chịu trách nhiệm xây dựng đã gây hại cho ngành công nghiệp này quá lâu. Các đội ngũ nghiêm túc xây dựng công nghệ và cơ sở hạ tầng cũng phải cùng nhau gánh chịu hậu quả của niềm tin bị mất. Đến khi mọi người coi toàn bộ Crypto là lừa đảo, công nghệ và sự khám phá thực sự đáng được bảo tồn cũng có thể bị bỏ rơi theo.
Là người sáng lập ArcBlock và là một người thực hành trong Crypto và Blockchain, tôi không muốn chấp nhận một kết quả như vậy. Tôi tin rằng ngành công nghiệp này có giá trị đáng được bảo vệ, và tôi cũng tin rằng chúng ta phải chịu trách nhiệm về nền tảng bảo mật của chính mình. Nếu chúng ta tiếp tục thụ động chờ đợi sự cố tiếp theo, việc chảy máu lặp đi lặp lại cuối cùng có thể phá hủy mọi thứ chúng ta đã cùng nhau xây dựng.Vì vậy, tôi muốn đưa ra sáng kiến này: những người xây dựng sàn giao dịch, ví và blockchain nên cùng nhau xây dựng lại nền tảng kiểm soát tài sản và xác minh bảo mật, để phạm vi thiệt hại từ một lần xâm nhập duy nhất được hạn chế. Dòng thời gian dưới đây giải thích lý do tại sao cần thay đổi; đề xuất kỹ thuật tiếp theo là công việc mà tôi tin rằng chúng ta có thể bắt đầu thực hiện.
Năm 2008, Satoshi Nakamoto đề xuất một hệ thống tiền điện tử ngang hàng, cố gắng làm cho thanh toán ít phụ thuộc hơn vào các trung gian đáng tin cậy. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Tuy nhiên, các sự cố lớn kể từ đó đã nhiều lần phơi bày vấn đề quỹ, ủy quyền và phụ thuộc phần mềm lại trở nên tập trung.
Dưới đây là danh sách theo thứ tự thời gian các sự cố tiêu biểu trong các lĩnh vực như sàn giao dịch tập trung (CEX), sàn giao dịch phi tập trung (DEX), cầu nối và ví. Đây không phải là cơ sở dữ liệu sự cố đầy đủ, cũng không phải thống kê tổn thất theo từng năm. Khi có liệt kê số tiền, chúng đề cập đến tác động gộp ước tính tại thời điểm sự cố; hành vi trộm cắp, đóng băng và phục hồi sau đó được mô tả riêng và không thể cộng lại thành tổn thất vĩnh viễn.
2008 · Sách trắng Bitcoin
Điểm khởi đầu
Sách trắng Bitcoin đề xuất thanh toán ngang hàng không có tổ chức tài chính làm trung gian.
Nguồn
2011–2014 · Trộm cắp dài hạn tại Mt. Gox
CEX
Mt. Gox bị trộm cắp dài hạn và cuối cùng ngừng hoạt động. Một bản cáo trạng sau đó của Bộ Tư pháp Hoa Kỳ cáo buộc rằng khoảng 647.000 BTC đã bị đánh cắp từ năm 2011 đến 2014. Đây không phải là một cuộc tấn công trong một ngày vào năm 2014.
Nguồn
2012 · Bitcoinica và Bitfloor
CEX / cơ sở hạ tầng lưu ký
Môi trường lưu trữ Linode của Bitcoinica bị xâm phạm; cùng năm đó, bản sao lưu ví không mã hóa của Bitfloor trở thành điểm xâm nhập tấn công. Máy chủ và bản sao lưu đằng sau nền tảng cũng là một phần của ranh giới bảo mật tài sản.
Nguồn
2015 · Ví nóng Bitstamp
CEX
Ví nóng của Bitstamp bị xâm phạm, và môi trường vận hành sau đó được xây dựng lại. Sự phân biệt chính thức giữa phạm vi sự cố và dự trữ ngoại tuyến cho thấy rằng cách ly có thể hạn chế phạm vi phơi nhiễm.
Nguồn
2016 · Bitfinex
CEX
Khoảng 120.000 BTC đã bị đánh cắp từ Bitfinex. Các thỏa thuận đa chữ ký vẫn yêu cầu ủy quyền và xác minh độc lập từ đầu đến cuối.
Nguồn 1 · Nguồn 2
2016 · The DAO
Giao thức trên chuỗi
Hợp đồng The DAO bị tấn công tái nhập, và khoảng 3,6 triệu ETH được chuyển vào một sub-DAO, sau đó kích hoạt một phân nhánh Ethereum. Một đường thực thi hợp pháp có thể tạo ra kết quả kinh doanh thảm khốc.
Nguồn 1 · Nguồn 2
2017 · Thư viện ví chia sẻ Parity
Ví hợp đồng
Thư viện ví chia sẻ Parity bị phá hủy, và khoảng 513.000 ETH bị đóng băng. Ngay cả khi không bị chuyển đi, quỹ có thể trở nên không thể sử dụng vì phụ thuộc mã chia sẻ.
Nguồn
2018 · Coincheck
CEXVí nóng NEM của Coincheck đã bị đánh cắp. Ranh giới giữa dự trữ ngoại tuyến, quyền hạn ví nóng và nhu cầu kinh doanh một lần nữa lại trở thành vấn đề.
Nguồn
2019 · Binance
CEX
Binance thông báo 7.000 BTC đã bị rút trong một giao dịch duy nhất. Dòng chảy tài sản quy mô lớn cần được hạn chế trước khi ký.
Nguồn
2020 · KuCoin
CEX
Sự cố ví nóng KuCoin, một lượng lớn tài sản sau đó đã được thu hồi thông qua hợp tác đa bên. Tổng số tiền bị đánh cắp và tổn thất cuối cùng không phải là cùng một con số.
Nguồn
2021 · Poly Network
Giao thức chuỗi chéo
Khoảng 612 triệu USD tài sản đã được chuyển ra khỏi Poly Network và sau đó được trả lại theo từng giai đoạn. Ủy quyền chuỗi chéo và kiểm soát tài sản không thể chỉ dựa vào các đường dẫn kinh doanh thông thường.
Nguồn
2022 · Cầu Ronin
Cầu nối
Quyền hạn trình xác thực Ronin đã bị xâm phạm, 173.600 ETH và 25,5 triệu USDC đã được chuyển ra. Khóa của nhiều trình xác thực cũng có thể rơi vào cùng một chuỗi tấn công.
Nguồn
2022 · Ví Slope
Ví
Sự cố ví Slope trong hệ sinh thái Solana. Solana chính thức tuyên bố rằng thông tin khóa riêng đã vô tình được truyền đến một dịch vụ giám sát ứng dụng; đó không phải là sự xâm phạm đồng thuận của Solana.
Nguồn
2023 · Euler
Giao thức cho vay
Khoảng 197 triệu USD tài sản đã được chuyển ra khỏi Euler do lỗ hổng giao thức và sau đó được thu hồi. Các kết hợp phức tạp trong một giao dịch duy nhất có thể khuếch đại các lỗ hổng logic kinh doanh.
Nguồn
2023 · Ledger Connect Kit
Công cụ kết nối ví
Ledger Connect Kit bị tấn công chuỗi cung ứng, mã độc đã xâm nhập vào giao diện người dùng ứng dụng. Bảo mật thiết bị phần cứng không thể thay thế việc xác minh nội dung giao dịch.
Nguồn
2024 · DMM Bitcoin
CEX
Khoảng 308 triệu USD đã bị đánh cắp từ DMM Bitcoin. FBI và các cơ quan khác sau đó đã tiết lộ các cuộc tấn công kỹ thuật xã hội nhắm vào nhân sự liên quan và chuỗi ký.
Nguồn
2024 · Radiant Capital
Giao thức cho vay / ký
Khoảng 50 triệu USD đã bị đánh cắp từ Radiant Capital, nhiều thiết bị của nhà phát triển đã bị xâm phạm. Ký đa bên vẫn có thể cùng nhau phụ thuộc vào thông tin giao dịch bị nhiễm độc.
Nguồn
2025 · Bybit / Safe
CEX / giao diện ví
Sự cố Bybit khoảng 1,5 tỷ USD liên quan đến môi trường nhà phát triển và giao diện của Safe, những người ký đã phê duyệt một giao dịch thay đổi logic kiểm soát ví.
Nguồn 1 · Nguồn 2
2025 · Cetus DEX
DEXSự cố khoảng 223 triệu USD tại Cetus trên Sui, các nhà nghiên cứu chỉ ra một lỗ hổng trong thư viện toán học. Môi trường không phải EVM cũng phải kiểm tra mã của họ và phạm vi tiếp xúc tài sản.
Nguồn
2026-07 · Lỗ hổng số ngẫu nhiên COLDCARD
Ví phần cứng / tạo seedMột lỗ hổng firmware đã làm suy yếu việc tạo seed, cho phép kẻ tấn công tái tạo các private key liên quan khi thiết bị đang offline. Việc nâng cấp không thể khắc phục các seed yếu đã được tạo ra; vẫn cần thực hiện di chuyển theo khuyến nghị.
Nguồn
2026-10 · Cấy ghép phần cứng Ledger
Ví phần cứng / tấn công phân phối
Ledger xác nhận rằng các thiết bị chính hãng đã bị sửa đổi và lưu hành qua các kênh phân phối tại Đông Nam Á, với các linh kiện được cấy ghép đánh cắp cụm từ khôi phục trong quá trình khởi tạo. Nhà cung cấp cho biết chip, hệ điều hành và máy chủ của họ không bị xâm phạm.
Nguồn
2026 · Sự cố đa chuỗi Binance
CEX / đa chuỗi
Binance ban đầu ước tính khoảng 6,3 tỷ USD tài sản bị ảnh hưởng, và các cuộc điều tra về các điểm xâm nhập khác vẫn đang tiếp diễn. Một hệ điều hành duy nhất có thể làm lộ tài sản trên nhiều mạng cùng lúc.
Nguồn 1 · Nguồn 2 · Nguồn 3
Ở đây có các CEX, nhưng cũng có các sàn phi tập trung, giao thức cho vay và cầu nối; có tài sản bị đánh cắp, và tài sản bị đóng băng. Các cuộc tấn công xảy ra ở những tầng khác nhau, và phương thức khắc phục cũng khác nhau. Tôi phản đối việc quy giản tất cả những điều này thành một câu duy nhất "người dùng đã không bảo vệ private key của mình." Làm sao người dùng có thể biết rằng môi trường phát triển của một công cụ nào đó, một thư viện dùng chung nào đó, hay một sự ủy quyền khó hiểu nào đó sẽ trở thành điểm xâm nhập vào toàn bộ tài sản của họ?
Các mạng phân tán đã làm được rất nhiều, nhưng việc cô lập lỗi đối với kiểm soát tài sản vẫn còn cách xa mức đủ. Việc thực thi trên chuỗi hoàn thành một giao dịch một cách trung thực, nhưng nó không thể trả lời thay chúng ta tại sao giao dịch đó lại có quyền di chuyển nhiều đến vậy.
Đóng góp của Ethereum là đáng kể. Nó cho phép nhiều người hơn viết ứng dụng trên chuỗi và nuôi dưỡng một bộ công cụ và kinh nghiệm phát triển phong phú. Nhưng ngày nay, nhiều chuỗi mới và L2 (mạng mở rộng lớp 2) coi khả năng tương thích EVM là mục tiêu chính của họ. EVM, máy ảo thực thi hợp đồng thông minh Ethereum, đang trở thành một tiền đề kỹ thuật được sao chép rộng rãi. Khả năng tương thích thực sự giúp việc di chuyển ứng dụng trở nên thuận tiện; tài liệu của các dự án như Unichain nêu rõ việc tái sử dụng bộ công cụ Ethereum là giá trị của một môi trường thực thi tương đương. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Tôi tin rằng việc coi khả năng tương thích EVM là câu trả lời mặc định của ngành đang tạo ra sự tập trung rủi ro mang tính cấu trúc. Có thể có nhiều tên mạng, các validator có thể khác nhau, nhưng các nhà phát triển có thể liên tục triển khai cùng những hợp đồng, sử dụng cùng những thói quen ủy quyền, và dựa vào cùng những thư viện phần mềm. Các lỗi trong những phụ thuộc dùng chung không biến mất chỉ vì việc triển khai diễn ra trên một chuỗi khác. Đây là một đánh giá về con đường kỹ thuật, không phải là khẳng định rằng mọi triển khai EVM nhất thiết đều có cùng một lỗ hổng.Đây cũng là nơi mà sự phê phán của tôi đối với Ethereum nằm ở đó. Khả năng thực thi hợp đồng đa dụng kết nối trực tiếp với tài sản có thể chuyển nhượng, đặt trách nhiệm to lớn lên mã ứng dụng và tương tác ví. Hợp đồng có thể gọi hợp đồng, ủy quyền có thể tồn tại trong thời gian dài, và một xác nhận tưởng chừng bình thường có thể thay đổi chế độ kiểm soát tiếp theo của một tài khoản. Bảo mật ngày càng phụ thuộc vào việc mỗi đội phát triển hiểu đúng các tổ hợp này, và vào việc mỗi người dùng hiểu đúng những gì họ đã ký.
EIP-7702 làm cho vấn đề này rất rõ ràng. Một giao dịch chuyển tiền thông thường là "lần này bao nhiêu cho ai"; một ủy quyền giao phó có thể là "từ nay về sau, hãy để đoạn mã này thực thi các thao tác thay mặt tài khoản của tôi." Nó có mục tiêu cải thiện trải nghiệm người dùng và tinh chỉnh quyền hạn, nhưng việc thiết lập một ủy quyền tự nó trao khả năng thực thi rộng rãi, và các quyền hạn chi tiết vẫn phải được mã được ủy quyền triển khai một cách chính xác. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Bản in trước "EIP-7702 Phishing Attack" của Minfeng Qi và cộng sự nghiên cứu con đường kiểm soát liên tục một tài khoản sau khi dụ dỗ ký các ủy quyền như vậy. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) Khi sự tiện lợi tăng lên, trách nhiệm bảo mật cũng tăng lên; không thể đơn giản giao phó cái trước cho người dùng.
Sự cố Binance này trải rộng nhiều chuỗi, và cuộc điều tra vẫn chưa hoàn tất, vì vậy không thể quy toàn bộ tác động trực tiếp cho EIP-7702 hoặc EVM. Tấn công tái nhập, xâm phạm dịch vụ ký, và giả mạo giao diện người dùng cũng không phải là cùng một lỗ hổng. Nhưng những phân biệt như vậy không nên trở thành cái cớ để ngừng đặt câu hỏi về kiến trúc: tại sao lớp nền tảng không giữ lại nhiều ràng buộc hơn không thể dễ dàng bị vượt qua, thay mặt cho các lỗi ở lớp trên?
MEV cũng làm tôi không hài lòng. Nó đề cập đến không gian mà các bên tham gia có được giá trị thêm thông qua việc đưa vào, loại trừ và sắp xếp các giao dịch. Đối với tôi, việc sử dụng quyền sắp xếp để kẹp các giao dịch của người dùng và làm xấu đi kết quả thực thi của họ nên được coi là một lỗi cần sửa chữa, chứ không phải được đóng gói như một tính năng đáng bảo tồn chỉ vì ai đó có thể kiếm lợi từ nó. Tài liệu của chính Ethereum cũng thừa nhận rõ ràng tác hại của việc kẹp giao dịch đối với người dùng và rủi ro của MEV đối với sự ổn định của mạng. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV không phải là duy nhất của Ethereum và cũng bao gồm các hoạt động khác nhau như chênh lệch giá và thanh lý; ngành công nghiệp đã có nghiên cứu giảm thiểu. Sự phê phán của tôi là động lực duy trì mạng lưới không thể trở thành lý do để hy sinh điều kiện giao dịch của người dùng. Một hệ thống giao dịch tốt hơn nên ghi kết quả giao hàng tối thiểu và phí cho phép vào ủy quyền, và hạn chế không gian để những người sắp xếp sử dụng thông tin chưa được lấp đầy để gây hại cho người dùng.Tôi luôn cảm thấy tác động của Ethereum đối với Crypto có phần nào giống như tác động của PHP đối với Internet: nó cho phép nhiều người xây dựng mọi thứ, và nó cũng để lại món nợ kỹ thuật sẽ mất rất lâu để trả. PHP vẫn cần vá một lỗ hổng thực thi mã từ xa nghiêm trọng vào tháng 10 năm 2026. Sự trưởng thành và phổ biến không thể thay thế cho việc gia cố liên tục. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) Điều quý giá ở Internet là các ngôn ngữ, framework và dịch vụ đám mây có thể phát triển riêng rẽ. Chúng ta cũng nên cho phép các mô hình tài sản và phương thức thực thi khác nhau tiếp tục phát triển, thay vì coi "tương thích với cùng một máy ảo" là tấm vé để tham gia hệ sinh thái.
Vì vậy, tôi kêu gọi các hệ sinh thái Bitcoin, Solana và Ripple/XRP Ledger, cũng như các nhà xây dựng bao gồm ArcBlock, tham gia một cách nghiêm túc vào việc xây dựng nền tảng bảo mật chung. Tham gia vào các tiêu chuẩn và khả năng tương tác không đòi hỏi trước tiên phải tự biến mình thành Ethereum. Tính đa dạng phải được thực hiện trong các phương thức kiểm soát và xác minh tài sản và phải mở cho sự giám sát của công chúng. Các sự cố Slope và Cetus đã nhắc nhở chúng ta rằng non-EVM cũng không có miễn trừ bảo mật.
Điều tôi hy vọng sẽ thành hình là một đặc tả bảo mật mà các môi trường thực thi khác nhau đều có thể áp dụng: cùng các giới hạn tài sản và yêu cầu xác minh có thể được EVM và các con đường khác triển khai riêng rẽ, và sau đó các bảo đảm và chi phí của mỗi bên có thể được công khai xem xét.
1. Hãy để các kiểm soát rủi ro nền tảng ràng buộc quyền định đoạt tài sản
Các ví lớn nên có thể thiết lập danh sách trắng người nhận, hạn mức chi tiêu lũy kế và thời gian chờ đối với người nhận mới. Điều quan trọng là các quy tắc này không thể bị hủy bỏ ngay lập tức bởi cùng một khóa giao dịch hàng ngày. Việc sửa đổi các quy tắc đòi hỏi sự ủy quyền độc lập và phải để lại thời gian cho việc giám sát và thu hồi.Các tài khoản thông minh hiện có đã có nền tảng triển khai, ví dụ Safe Guards có thể thêm các hạn chế giao dịch ngoài multisig. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Chúng ta cần biến đây thành một năng lực nền tảng dễ áp dụng hơn, bao phủ toàn bộ các đường kiểm soát tài sản. Nếu chỉ hạn chế chuyển khoản trực tiếp trong khi vẫn cho phép vượt qua bằng phê duyệt không giới hạn, module hoặc nâng cấp, thì biện pháp bảo vệ sẽ thất bại. Việc hợp đồng whitelist có thể được nâng cấp hay không và quyền hạn của người nhận có thay đổi hay không cũng phải nằm trong phạm vi xác minh. Apple's Activation Lock mang đến một nguồn cảm hứng trong đời sống thường ngày: nó hạn chế việc kích hoạt lại các thiết bị bị đánh cắp và giới hạn việc hiệu chuẩn một số linh kiện bị đánh cắp, với mục tiêu giảm giá trị có thể bị khai thác sau khi bị trộm. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Ví tiền cũng đáng được thiết kế theo hướng này. Nếu kẻ tấn công có được khóa, phạm vi tài sản có thể bị rút ra vẫn bị giới hạn, và lợi nhuận kỳ vọng từ một cuộc tấn công có thể giảm đi; các rủi ro như làm gián đoạn dịch vụ vẫn cần được xử lý riêng.
Đây là điều tôi gọi là "hiến pháp" của an ninh tài sản: thẩm quyền vận hành có thể bị xâm phạm, nhưng thẩm quyền sửa đổi ranh giới phải được giữ độc lập. Các quy trình khôi phục cũng phải bị ràng buộc, để ngăn một lần cấu hình sai duy nhất khóa vĩnh viễn tài sản.
II. Khiến ví tiền gánh vác trách nhiệm an ninh, thay vì chỉ đơn thuần giao nộp cụm từ ghi nhớ
Tôi có sự bất mãn mạnh mẽ với các hệ thống ví tiền ngày nay: nếu một sản phẩm yêu cầu một người bình thường chép lại một bộ từ, yêu cầu họ không bao giờ làm lộ, làm mất hoặc bị lừa lấy đi, rồi sau đó quy mọi thất bại tiếp theo cho trách nhiệm của người dùng, tôi coi đây là một thiết kế vô trách nhiệm. Tự lưu giữ nên mang lại cho con người quyền kiểm soát, và nó cũng nên mang lại cho con người khả năng bảo vệ và khôi phục có thể sử dụng được. Nó không nên yêu cầu mọi người dùng trước tiên phải trở thành chuyên gia an ninh. Đây cũng là một ngưỡng mà Crypto phải vượt qua để tiếp cận nhiều người dùng bình thường hơn.Các sự cố gần đây đã đặt vấn đề này thẳng lên bàn. Vào tháng 10 năm 2026, Ledger xác nhận rằng kẻ tấn công đã sửa đổi các thiết bị chính hãng và sau đó gửi chúng trở lại thị trường thông qua các kênh phân phối ở Đông Nam Á, với các linh kiện được cấy ghép đánh cắp cụm từ khôi phục trong quá trình khởi tạo. Ledger định nghĩa đây là một cuộc tấn công phân phối cục bộ sau khi thiết bị rời khỏi nhà máy, chứ không phải là sự xâm phạm chip, hệ điều hành hoặc máy chủ của họ. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) Sự cố tháng 7 của COLDCARD liên quan đến việc firmware làm suy yếu quá trình tạo seed: thiết bị không cần bị điều khiển từ xa để kẻ tấn công có thể tái tạo các khóa riêng tư liên quan. Cập nhật firmware sẽ sửa quy trình tạo cho các lần sau, nhưng các seed yếu đã được tạo ra vẫn cần được di chuyển. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Hai sự cố này không phải là cùng một loại lỗ hổng, nhưng cùng nhau chúng cho thấy: ngay cả khi người dùng cẩn thận sao chép các từ và giữ thiết bị ngoại tuyến, họ không thể xác minh tính ngẫu nhiên và tính toàn vẹn của chuỗi cung ứng thay mặt nhà sản xuất. Việc thiết bị hiển thị các từ sao lưu có mục đích là khôi phục ngoại tuyến, nhưng nó cũng khiến bí mật khôi phục hoàn chỉnh đi qua một đường dẫn hiển thị và sao lưu cần được bảo vệ. Bảo mật chip không thể thay thế việc xác minh toàn bộ thiết bị và quy trình giao hàng.
Mục tiêu của cải tiến nên là vòng đời ví hoàn chỉnh: cách khóa được tạo, cách giao dịch được giải thích, cách phân tách quyền hạn và cách khôi phục hoạt động sau khi thiết bị bị mất. Trừu tượng hóa tài khoản, tức là cho phép tài khoản xác minh ủy quyền thông qua các quy tắc có thể lập trình, và sao lưu ngưỡng như SLIP-39, cả hai đều đã có tiêu chuẩn và nền tảng triển khai, nên không thể nói rằng không có ai trong ngành đang nghiên cứu chúng. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Nhưng chúng ta cần biến những khả năng này thành các biện pháp bảo vệ đã được kiểm nghiệm, dễ sử dụng, thay vì để người dùng tự lắp ghép các phương án phức tạp.
Làm xáo trộn đơn giản các từ ghi nhớ là không đủ. Các hướng đáng tin cậy hơn bao gồm sao lưu mã hóa đã được đánh giá, khôi phục ngưỡng và ủy quyền thiết bị độc lập, và để người dùng hoàn thành các bài diễn tập khôi phục trước khi gửi số lượng lớn tài sản. Các mảnh sao lưu và đa chữ ký là các lớp khác nhau: cái trước có thể tái kết hợp thành cùng một bí mật trong quá trình khôi phục, trong khi cái sau yêu cầu nhiều người ký độc lập phê duyệt một giao dịch. Các dịch vụ khôi phục không được âm thầm trở thành một khóa chính mới, và một mật khẩu bổ sung cũng không nên trở thành một cái bẫy khác, nơi mất nó đồng nghĩa với mất mát không thể khôi phục.Ví cá nhân và hệ thống ví sàn giao dịch có thể chia sẻ các đặc tả bảo mật cho mô tả giao dịch, yêu cầu ký, hạn chế tài sản và quy trình khôi phục, đồng thời áp dụng các giới hạn và chính sách phê duyệt khác nhau. PSBT của Bitcoin đã cung cấp một định dạng để truyền giao dịch chưa ký giữa các công cụ, và giao diện chung này đáng để tiếp tục xây dựng. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) Điều chung là các yêu cầu bảo mật có thể kiểm tra được; mỗi chuỗi vẫn cần làm rõ các quy tắc thích ứng của riêng mình. Ví nên trình bày rõ ràng chữ ký này sẽ chuyển giao những gì và cấp bao nhiêu quyền hạn tiếp theo cho ai, và các chính sách độc lập nên từ chối các thao tác vượt giới hạn; một trang xác nhận đẹp hơn là không đủ.
III. Đạt được khả năng kiểm chứng với mức tiết lộ tối thiểu cần thiết
Chứng minh rằng một điều kiện được thỏa mãn không phải lúc nào cũng yêu cầu người dùng tiết lộ tất cả dữ liệu cơ bản. Tiết lộ có chọn lọc, chứng minh không tri thức và quyền truy cập kiểm toán được cấp theo yêu cầu nên trở thành các lựa chọn thông thường trong cơ sở hạ tầng. Điều này cũng liên quan đến bảo mật tài sản: danh tính công khai và các mối quan hệ tài sản có thể cung cấp manh mối cho sự lừa dối có chủ đích; dữ liệu mà doanh nghiệp không cần nên được tiết lộ càng ít càng tốt.
Hệ thống thông tin xác thực có thể kiểm chứng của W3C đã có lộ trình kỹ thuật cho việc tiết lộ có chọn lọc; tuy nhiên, việc chứng minh rằng đầu vào là xác thực, rằng thông tin xác thực vẫn còn hiệu lực và cách trạng thái bị thu hồi vẫn cần được làm rõ. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Việc áp dụng chứng minh không tri thức (ZK) không tự động ẩn số tiền và mối quan hệ giao dịch; mở rộng quy mô chứng minh và bảo vệ quyền riêng tư là những mục tiêu khác nhau.
Ví dụ, khi doanh nghiệp chỉ cần xác minh tính đủ điều kiện tham gia, người dùng có thể trình bày một kết luận đủ điều kiện hợp lệ do một tổ chức đáng tin cậy cấp mà không tiết lộ tài liệu tài chính đầy đủ. Khi cần chứng minh rằng một giá trị ẩn thỏa mãn một điều kiện, sau đó có thể sử dụng cơ chế chứng minh phù hợp. Nguồn đáng tin cậy của thông tin xác thực và trạng thái thu hồi của nó vẫn cần được xác minh.
Sáng kiến của tôi là trước tiên làm rõ "ai cần xác minh điều gì", sau đó thiết kế dữ liệu phải được công khai. Những người xác minh tính đủ điều kiện có thể chỉ cần kết luận đủ điều kiện; những người chịu trách nhiệm kiểm toán cụ thể có thể nhận được bằng chứng bị hạn chế. Các ràng buộc có thể kiểm chứng công khai nên giảm thiểu thông tin cá nhân bị phơi bày vĩnh viễn cho mọi người.
IV. Làm cho các dịch vụ giao dịch càng ít phụ thuộc vào lưu ký tập trung càng tốtKhớp lệnh, tìm đường và thanh toán tài sản nên được thiết kế riêng biệt. Một dịch vụ cung cấp điểm vào giao dịch chỉ nên có được các quyền cần thiết để hoàn tất việc thanh toán hiện tại trong phạm vi có thể, để tài sản của người dùng vẫn nằm dưới sự kiểm soát tương ứng của họ trong phần còn lại của thời gian. Các giao thức giao dịch dựa trên ý định hiện có đã khám phá một phần con đường, và ngành có thể tiếp tục hoàn thiện nó. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
Điều người dùng đồng ý phải là các điều kiện thanh toán rõ ràng, bao gồm những gì được trả, những gì nhận được tối thiểu, thời điểm hết hạn và các khoản phí được phép. Sau khi dịch vụ giao dịch bị xâm phạm, kẻ tấn công có thể từ chối dịch vụ, nhưng không thể tùy ý thay đổi các điều kiện này. Các doanh nghiệp vẫn yêu cầu lưu ký tập trung cũng nên tách quyền dự trữ và quyền vận hành, đồng thời giới hạn mức độ phơi nhiễm của ví nóng và giới hạn bổ sung tự động.
IBIT là sản phẩm giao dịch bitcoin của iShares, và thứ giao dịch trên thị trường là cổ phần của nó. Cách sắp xếp của nó cung cấp một ví dụ về cách ly một phần: cổ phần và Bitcoin cơ sở được ghi nhận riêng biệt, và các khóa riêng liên quan cho Số dư Vault (số dư lưu ký) được đặt trong lưu trữ lạnh. Những thay đổi trong hồ sơ giao dịch cổ phần không yêu cầu Bitcoin cơ sở phải di chuyển theo từng giao dịch. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Điều có thể học được từ đây là sự tách biệt giữa quyền giao dịch và quyền định đoạt dự trữ. Số dư Giao dịch (số dư dịch vụ giao dịch) của nó có cách sắp xếp khác, và bản thân việc lưu ký cũng mang lại rủi ro; lưu trữ lạnh phải được kết hợp với chỉ dẫn độc lập và xác minh chữ ký.
Tôi so sánh điểm vào giao dịch với một bộ định tuyến với hy vọng rằng nó có thể được thay thế mà không mang theo một công tắc tổng kiểm soát tất cả tài sản của người dùng. Thanh toán phức tạp hơn chuyển tiếp gói tin, và việc giao tài sản và ủy quyền vẫn cần được xác minh độc lập. Biến một dịch vụ thành không lưu ký rồi cấp cho nó quyền rút tiền không giới hạn sẽ chỉ mang rủi ro tập trung trở lại.
V. Sử dụng kiến trúc phân lớp để cô lập lỗi và duy trì khả năng thay thếChúng ta cần các giao diện định danh và ủy quyền, chính sách tài sản và phương thức xác minh thanh toán có thể phát triển độc lập. Các chuỗi khác nhau có thể giữ mô hình thực thi riêng và kết nối qua các giao diện rõ ràng. Giao diện nên nêu rõ các bảo đảm an ninh và điều kiện của chúng, không chỉ nói "lệnh gọi đã thành công".Kinh nghiệm Internet ủng hộ cách tiếp cận này. Trong RFC 9518, "Centralization, Decentralization, and Internet Standards," Mark Nottingham đặc biệt thảo luận về những tình huống mà tập trung hóa có thể hữu ích, đồng thời phân tích quyền lực và rủi ro mà nó mang lại. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) Đây chính là thái độ đáng học hỏi: để kiến trúc trả lời trách nhiệm nào có thể được tập trung, ở mức độ nào và làm thế nào để ngăn quyền lực đó mở rộng. Một dịch vụ có thể được phép xác định bất thường một cách tập trung trong khi quyền chạm vào tài sản của nó bị giới hạn; người dùng nên có thể chuyển đổi dịch vụ mà không mất chính sách tài sản và hồ sơ xác minh của riêng mình.
Câu hỏi nghiệm thu quan trọng nhất là: sau khi một dịch vụ kinh doanh bị xâm phạm, lớp độc lập nào vẫn có thể từ chối nó? Nếu tất cả các lớp chia sẻ một khóa quản trị, cái gọi là phân lớp chỉ là phân lớp trên sơ đồ triển khai.
Mục tiêu này có thể được xem như năm lớp trách nhiệm: dịch vụ giao dịch gửi yêu cầu, ví thể hiện ý định người dùng, chính sách độc lập giới hạn quyền định đoạt tài sản, thành phần xác minh kiểm tra hoạt động và bằng chứng, và lớp thanh toán thực thi các ràng buộc và cung cấp hồ sơ có thể xác minh. Chúng có thể được triển khai bởi các nhóm khác nhau, và các phụ thuộc cùng điều kiện thất bại của chúng cũng phải được mô tả riêng.
Kiến trúc mục tiêu được bài viết này chủ trương. Lớp thanh toán phải thực thi chính sách tài sản; các lời nhắc trong ví không thể thay thế ràng buộc này. Ký hàng ngày, thay đổi quy tắc và quyền khôi phục cần được tách biệt và chịu kiểm thử vượt qua.
6. Để người dùng tự xác minh nhẹ tài sản của mình
Người bình thường không nên phải lưu trữ và thực thi toàn bộ lịch sử của cả chuỗi để xác minh số dư và biên lai của chính mình; cũng không nên chỉ tin tưởng một máy chủ duy nhất phía sau ví. Satoshi Nakamoto đã đề xuất SPV, xác minh thanh toán đơn giản, trong Mục 8 của whitepaper. BIP-157 của Bitcoin tiếp tục khám phá việc cho phép client tải bộ lọc và tìm các khối liên quan đến chính mình; Ethereum cũng có các thiết kế light client. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Vậy nên vấn đề không phải là chưa từng có ai nghĩ đến, mà là chúng ta vẫn cần xây dựng năng lực xác minh với các điều kiện an ninh rõ ràng vào những chiếc ví người dùng sử dụng hàng ngày.Lấy một chuỗi hỗ trợ chứng minh trạng thái tài khoản làm ví dụ: khi truy vấn số dư, máy chủ nên trả về cả số dư và bằng chứng. Ví tiền trước tiên xác minh một bản tóm tắt khối ngắn, tức là tiêu đề khối, theo quy tắc của chuỗi đó, sau đó kiểm tra xem số dư này có nhất quán với dữ liệu mà bản tóm tắt cam kết hay không. Máy chủ cung cấp câu trả lời, và ví tiền có thể xác minh câu trả lời. SPV của Bitcoin xác minh bằng chứng rằng các giao dịch liên quan đã được đưa vào; nó không thể được sao chép trực tiếp như một bằng chứng số dư. Ví tiền cũng nên hiển thị rõ ràng nơi nó đã đồng bộ hóa đến và thông tin nào đã được xác minh; khi thiếu bằng chứng, dữ liệu cũ hoặc các nguồn xung đột, nó nên cảnh báo hoặc dừng các hoạt động rủi ro cao dựa trên thông tin này, và không được lặng lẽ quay lại tin tưởng mù quáng.
Xác minh nhẹ vẫn có các điều kiện. Chứng minh rằng một giao dịch đã được đưa vào một khối không giống như tự mình kiểm tra rằng tất cả các giao dịch trong khối đều hợp lệ. Các sơ đồ khác nhau có thể dựa vào việc đa số hash power là trung thực, hoặc dựa vào một bản ghi ban đầu đáng tin cậy, tức là một checkpoint; chúng cũng phải đề phòng máy chủ giữ lại dữ liệu hoặc cô lập người dùng trên một bản ghi chuỗi cũ. Việc bản thân truy vấn có làm lộ các địa chỉ mà người dùng quan tâm hay không cũng cần được xử lý. Full node và nhà sản xuất khối không phải là cùng một vai trò; Ethereum ngày nay sử dụng validator thay vì miner để sản xuất khối.
Quan trọng hơn, chứng minh rằng "giao dịch chuyển tiền này thực sự đã xảy ra trên chuỗi" không thể chứng minh rằng "đây chính xác là giao dịch chuyển tiền mà người dùng muốn." Light client không thể thay thế các giới hạn tài sản và kiểm tra chữ ký trước đó. Chúng cho phép người dùng ít phụ thuộc hơn vào một câu trả lời không thể xác minh, trong khi chính sách tài sản đảm bảo rằng ngay cả một chữ ký hợp lệ cũng không thể định đoạt tài sản mà không có giới hạn. Chỉ bằng cách xây dựng cả hai lớp cùng nhau thì năng lực xác minh mới có thể được phân phối giữa các bên tham gia.
7. Xây dựng nhận diện bất thường và xác minh bảo mật như cơ sở hạ tầng công cộng
Trước một giao dịch, ai đó nên kiểm tra xem hoạt động có tuân thủ chính sách tài sản hay không và liệu nó có đột ngột thay đổi hành vi lịch sử hay không. Các bất thường rõ ràng có thể kích hoạt tạm dừng hoặc đánh giá leo thang; mở rộng quyền hạn yêu cầu một con đường độc lập khác. AI có thể tham gia vào việc đánh giá, nhưng không nên nhận được quyền vượt qua các quy tắc cứng.
Đồng thời, chúng ta cần cùng nhau duy trì các trường hợp tấn công, kiểm tra quyền hạn và công cụ xác minh có thể chạy lặp đi lặp lại. Chỉ bằng cách chia sẻ thông số kỹ thuật và bảo tồn các triển khai độc lập và xác minh độc lập thì mới có thể giảm thiểu các lỗi chế độ chung. Các quỹ và sàn giao dịch đã có đầu tư vào bảo mật, chẳng hạn như Sáng kiến Bảo mật Nghìn Tỷ Đô của Quỹ Ethereum. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) Câu hỏi tiếp theo cần đặt ra là liệu khoản đầu tư có thể được chuyển đổi thành cơ sở hạ tầng công cộng mà các nhóm khác cũng có thể áp dụng và kiểm tra hay không.Không một hạng mục công việc nào trong bảy hạng mục này có thể đảm bảo an toàn tuyệt đối. Điều chúng cần mang lại là ranh giới có thể kiểm tra được: trong điều kiện quyền bị xâm phạm nào, tài sản bị phơi bày nhiều nhất là bao nhiêu, phát hiện bất thường nhanh đến mức nào, và việc khôi phục vẫn phụ thuộc vào ai.
Đến đây, có người có thể nói: định hướng nghe có vẻ đúng, nhưng ngành này đã đi được bao nhiêu năm rồi; tái thiết sẽ cần bao nhiêu người và bao nhiêu thời gian? Đây chẳng phải vẫn là chủ nghĩa lý tưởng sao?
Nếu ước tính theo phương thức sản xuất phần mềm trong quá khứ, mối nghi ngờ này rất thực tế. Nhưng đến năm 2026, tôi tin rằng các coding agent và kỹ thuật phần mềm được AI hỗ trợ đã thay đổi năng lực xây dựng mà chúng ta có thể huy động. Coding agent được nhắc đến ở đây là trợ lý lập trình AI có thể đọc và viết mã, gọi công cụ, chạy kiểm thử, và tiếp tục làm việc dựa trên phản hồi trong môi trường phát triển. Người xây dựng đặt mục tiêu, xác định ranh giới an ninh, dùng các công cụ này để triển khai và kiểm tra hệ thống, đồng thời chịu trách nhiệm về kết quả.
Công việc trước đây cần đội ngũ lớn lặp đi lặp lại việc triển khai, thích ứng và bảo trì, nay có thể được các đội nhỏ thử nghiệm với phương pháp kỹ thuật mới này. Một đội phụ trách một tầng, bàn giao thành phần xoay quanh giao diện rõ ràng, sau đó các đội khác kiểm tra và kết hợp chúng. Tổ chức phán đoán kiến trúc của con người, năng lực triển khai của coding agent, và xác minh an ninh độc lập — theo tôi, đây là con đường xây dựng đáng được đánh giá lại một cách nghiêm túc.
Nghiên cứu của Anthropic và PNNL đưa ra một ví dụ cụ thể: trong một môi trường mô phỏng cơ sở hạ tầng trọng yếu có giới hạn, các nhà nghiên cứu báo cáo rằng việc tái dựng cuộc tấn công được rút ngắn từ có thể mất vài tuần xuống còn khoảng ba giờ. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Điều này không thể chứng minh rằng một đội nhỏ đã có thể tái viết toàn bộ ngành một cách an toàn, nhưng nó cho thấy công việc xác minh và công phòng thủ trước đây vốn đắt đỏ có thể có điều kiện chi phí mới.
Một cách tiếp cận tổ chức có thể bắt đầu ngay bây giờ là cùng nhau xây dựng một Build in Public AI Factory. Các chuyên gia trong ngành, học giả và người thực hành công khai viết yêu cầu và đặc tả nghiệm thu (spec), giải thích cần bảo vệ điều gì, những thao tác nào được phép, và những ranh giới nào vẫn phải giữ vững sau khi quyền nào bị xâm phạm, rồi chuyển các yêu cầu này thành kiểm thử nghiệm thu. Các nhóm coding agent đảm nhận phần lớn công việc viết mã, kiểm thử và gỡ lỗi; các đội khác nhau kiểm tra thiết kế và kết quả, và con người chịu trách nhiệm phán đoán và nghiệm thu.Người tham gia có thể đóng góp ý tưởng, máy móc, sức mạnh tính toán và hạn ngạch gọi mô hình, tức là AI token. Các công ty AI và điện toán đám mây cũng có thể hỗ trợ việc xây dựng công cộng này thông qua hạn ngạch mô hình, tài nguyên tính toán và công cụ. Thông số kỹ thuật, mã nguyên mẫu, quy trình tác nhân, môi trường kiểm thử và kết quả xác minh đều có thể trở thành cơ sở hạ tầng được duy trì chung, cho phép nhóm tiếp theo tiếp tục trực tiếp từ đó. Mục tiêu là xây dựng năng lực phát triển thành các cơ sở công cộng có thể tái sử dụng và giảm sự phụ thuộc vào thời gian của bất kỳ một người nào hoặc bất kỳ một nhóm nào.
Kẻ tấn công cũng đang sử dụng AI, và chúng ta không còn lý do gì để bỏ mặc phòng thủ trong các phương thức sản xuất của quá khứ. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Nhưng việc tạo mã nhanh chóng chỉ là điểm khởi đầu. Chỉ bằng cách viết ràng buộc rõ ràng, làm cho các bài kiểm tra có thể chạy lặp đi lặp lại, và làm cho một thành phần có thể kiểm tra và thay thế được, năng lực AI mới có thể được chuyển hóa thành cải tiến cơ sở hạ tầng.
Các nhà xây dựng độc lập làm việc cùng nhau với sự hỗ trợ của các tác nhân lập trình và công cụ AI. Xưởng không gian là một phép ẩn dụ cho việc xây dựng công cộng. Tôi đặc biệt muốn gửi lời kêu gọi này đến những người vẫn còn yêu thích xây dựng. "Hacker" ở đây đề cập đến một người sẵn sàng tìm hiểu cách một hệ thống hoạt động, sẵn sàng chia sẻ những gì họ tìm thấy, và sẵn sàng để người khác kiểm tra công việc của họ. Tinh thần đó từng thúc đẩy Internet tiến lên, và ngày nay nó cũng có thể thúc đẩy Crypto tiến lên.
Tôi không tin rằng ngành này thiếu người thông minh, và tôi không tin rằng ngành Crypto và AI không thể tìm thấy nguồn lực để hỗ trợ công việc này. Điều khó hơn là tổ chức nhân tài, tài trợ và trách nhiệm bền vững cùng nhau. Các quỹ và công ty có năng lực nên sẵn sàng gánh chịu chi phí dài hạn của công việc nền tảng không trực tiếp tạo ra doanh thu nhưng mang lại lợi ích cho tất cả mọi người.
Tôi hy vọng mọi người có thể cùng nhau xây dựng một cơ sở hạ tầng mật mã được chia sẻ toàn cầu. Các mạng lưới và nhóm khác nhau có thể cộng tác dưới các ràng buộc bảo mật chung, mỗi bên triển khai giải pháp của riêng mình và kiểm tra lẫn nhau, và người dùng có thể lựa chọn và di chuyển. Nó có thể bắt đầu với một thành phần duy nhất, nhưng hướng đi phải đủ lớn để chứa toàn bộ ngành cùng xây dựng. Tất cả những người tham gia, bao gồm cả ArcBlock, nên đóng góp công việc có thể xác minh.
Chúng ta nên cùng nhau xây dựng một loại cơ sở hạ tầng mà ngay cả khi một phần nào đó đã bị xâm phạm, tài sản vẫn có ranh giới, các hệ thống khác vẫn có thể từ chối lỗi, và người dùng vẫn có con đường để phục hồi và thoát ra. Mượn tên từ Star Wars, đây là Niềm Hy Vọng Mới của chúng ta. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) Hy vọng đến từ những nhà xây dựng bình thường sẵn sàng hành động, và cũng từ khoảnh khắc này khi các tác nhân lập trình và các phương pháp kỹ thuật mới cho phép họ đảm nhận nhiều công việc xây dựng hơn.Tôi muốn gửi lời mời đến những người xây dựng các dự án như Ethereum, Solana, Bitcoin và XRP Ledger, đến các sàn giao dịch như Binance, Coinbase và Kraken, cũng như đến các đội ngũ ví, giao thức, nghiên cứu bảo mật, AI và điện toán đám mây: hãy bắt đầu bằng một thử nghiệm thí điểm có phạm vi rõ ràng và cùng nhau tạo ra những cải tiến mà các đội ngũ khác có thể áp dụng và kiểm thử.
Các tên được liệt kê chỉ là ví dụ, không theo thứ tự nào. Bất kể quy mô hay con đường kỹ thuật bạn chọn, bạn đều được chào đón tham gia. Lời mời này cũng bao gồm những người xây dựng các con đường kỹ thuật bị phê bình trong bài viết này; cùng nhau cải thiện bảo mật tài sản là điều đáng để vượt qua ranh giới của các hệ sinh thái tương ứng của chúng ta.
Bản thân tôi sẵn sàng tham gia và đóng góp cơ sở hạ tầng, kỹ thuật phần mềm và các thực tiễn cộng tác AI hiện có của chúng tôi. Chúng tôi chỉ là một đội ngũ nhỏ trong ngành, và những gì chúng tôi có thể làm là có hạn. Tôi hy vọng bắt đầu bằng một nguyên mẫu và một bộ kiểm thử có thể lặp lại.
Những người có kinh nghiệm vận hành thực tế có thể cung cấp các kịch bản tấn công đã được khử nhạy cảm, các đội ngũ ví và giao thức có thể triển khai các biện pháp bảo vệ, và các nhà nghiên cứu độc lập có thể thử vượt qua chúng. Mỗi đội ngũ đảm nhận phần mình có thể xử lý, cùng nhau kiểm thử giải pháp và quyết định bước tiếp theo.
Tôi sẵn sàng tham gia tổ chức các yêu cầu về giới hạn và khôi phục tài sản trong bài viết này thành đặc tả công khai đầu tiên, và tôi cũng sẵn sàng đóng góp các thực tiễn kỹ thuật và kỹ thuật liên quan để cùng với các bên tham gia khác xây dựng một AI Factory công khai cho thử nghiệm thí điểm này. Trước tiên hãy chọn một vấn đề rất cụ thể: một khi khóa giao dịch hàng ngày đã bị xâm phạm, làm thế nào vẫn có thể ngăn kẻ tấn công rút cạn ví ngay lập tức? Hãy viết phạm vi tổn thất được phép, thẩm quyền sửa đổi quy tắc và các điều kiện khôi phục vào các bài kiểm thử chấp nhận, sau đó để các tác nhân phát triển triển khai một nguyên mẫu, và để một nhóm tác nhân khác cùng các nhà nghiên cứu độc lập tìm kiếm các đường vòng. Các máy chủ dữ liệu trả về số dư không chính xác, và việc khôi phục sau khi mất thiết bị, cũng có thể dần dần được thêm vào các bài kiểm thử. Những gì nguyên mẫu đạt được, những gì nó thất bại, và những phụ thuộc còn lại, đều nên được giải thích công khai, và bước tiếp theo nên được quyết định dựa trên bằng chứng.
Những ai sẵn sàng tham gia được chào đón đăng lại hoặc trích dẫn công khai sáng kiến này trên X và @mave99a, và nói về vấn đề bạn muốn giải quyết, các trường hợp tấn công đã được khử nhạy cảm, hoặc các nguồn lực bạn có thể đóng góp. Tôi hy vọng cuộc thảo luận diễn ra công khai, để nhiều người xây dựng hơn có thể thấy và tham gia.
Crypto không thể tiếp tục như thế này. Những ai sẵn sàng hợp tác, hãy hành động ngay bây giờ, bắt đầu bằng một cải tiến có thể xây dựng và có thể chịu được kiểm thử.Binance, bài đăng chính thức công bố ban đầu và bản cập nhật chính thức của cuộc điều tra tiếp theo, 2026-10-30; phân tích đa chuỗi của TRM. Bản nháp này đã được xác minh tính đến 2026-10-30; tình trạng điều tra và thu hồi có thể thay đổi. [↩](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. Mức độ tập trung rủi ro của các phụ thuộc dùng chung là đánh giá của tác giả trong bài viết này, không phải kết luận của tài liệu đó. [↩](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, tạo ngày 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, bản in trước arXiv v1; không phải là việc xác định sự cố Binance này. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), các cơ chế sắp xếp thứ tự, các loại khác nhau và tác động tiêu cực; "nên được sửa như một lỗi" là quan điểm kỹ thuật của tác giả về hành vi gây hại cho người dùng. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
Kho tin tức chính thức năm 2026 của PHP; bản cập nhật Danh mục Lỗ hổng Đã bị Khai thác của CISA ngày 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, mô tả chức năng và rủi ro quyền hạn. [↩](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; mô tả hiện tại về hỗ trợ ghép nối linh kiện. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, tuyên bố của nhà cung cấp về một cuộc tấn công trong chuỗi phân phối; Joe Grand, nghiên cứu dịch ngược về cấy ghép phần cứng. Không trình bày các ước tính tổn thất mạng chưa được xác minh như kết luận chắc chắn. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, truy cập 2026-10-30, hồ sơ được cập nhật liên tục về sự cố tháng 7 năm 2026 và biện pháp khắc phục; nâng cấp và di chuyển seed là hai thao tác riêng biệt. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, khôi phục ngưỡng, khả năng tương thích và rủi ro cụm mật khẩu bổ sung. Các cơ chế hiện có là nền tảng để xây dựng, và không có nghĩa là mọi triển khai đều đáng tin cậy. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: Định dạng giao dịch Bitcoin được ký một phần, một định dạng trao đổi cho các giao dịch chưa ký, không phải là đặc tả chiến lược tài sản tổng quát xuyên chuỗi. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Tổng quan về Thông tin xác thực có thể xác minh v1.0, Ghi chú Nhóm ngày 30-07-2026; ghi chú về quyền riêng tư của Ethereum. Tình trạng tiêu chuẩn của các công nghệ được mô tả trong tổng quan là độc lập trong từng trường hợp. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
Tài liệu CoW Protocol, ý định giao dịch và cơ chế solver; bài viết này không đưa ra sự chứng thực bảo mật toàn diện cho bất kỳ triển khai cụ thể nào. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, Báo cáo thường niên IBIT 2025, PDF trang 8–10 về thỏa thuận lưu ký và trang 45 về công bố rủi ro. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Tập trung hóa, Phi tập trung hóa và Tiêu chuẩn Internet, tháng 12-2023, được đệ trình độc lập, RFC thông tin, không phải đặc tả thuộc lộ trình tiêu chuẩn. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Sách trắng Bitcoin Mục 8 Xác minh thanh toán đơn giản; BIP-157: Lọc khối phía máy khách; Ethereum, Máy khách nhẹ. Các máy khách nhẹ khác nhau có phạm vi xác minh và điều kiện tin cậy khác nhau. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Quỹ Ethereum, Công bố Sáng kiến An ninh Nghìn Tỷ Đô la, 14-05-2025. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI bảo vệ cơ sở hạ tầng trọng yếu, 08-01-2026, nghiên cứu trong môi trường hạn chế phối hợp với PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Lập bản đồ các mối đe dọa mạng do AI hỗ trợ, nghiên cứu trên các mẫu lạm dụng thực tế. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: Niềm Hy Vọng Mới (Tập IV), 1977; bài viết này mượn tiêu đề và hình ảnh của sự tự cứu chung. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)