Đêm 23 tháng 5, tôi nhận được một tin nhắn từ đồng nghiệp ở Singapore: "Bridge này vừa bị drain 22 triệu. Có phải cái em từng cảnh báo không?" Tôi mở file ghi chú audit của mình ra, tìm đúng dòng tên giao thức, ngày đánh dấu "lỗ hổng nghiêm trọng". Hai tuần trước đó, tôi đã viết trong báo cáo: "Validator threshold có thể bị thay đổi bởi một hàm không được kiểm soát quyền sở hữu, và nếu điều này xảy ra, kẻ tấn công chỉ cần nhập một giá trị mới và rút toàn bộ kho dự trữ." Tôi không ngạc nhiên. Điều làm tôi khó chịu là một thực tế rộng lớn hơn: hầu hết mọi người trong thị trường này vẫn đang gọi những cây cầu nối đó là "phi tập trung", dù hợp đồng thông minh của chúng không bao giờ đồng ý với cái mác đó.
Cầu nối cross-chain là một trong những mảnh ghép được nhắc đến nhiều nhất nhưng hiểu sai nhiều nhất trong toàn bộ hệ sinh thái blockchain. Khi người dùng nói "chuyển tài sản từ Ethereum sang BNB Chain", họ thường tưởng rằng có một thứ gì đó kỳ diệu đang diễn ra ở phía sau — một cây cầu thực sự, nơi tài sản của họ được bảo vệ bởi mã nguồn mở và thuật toán. Sự thật bất tiện về giao thức này là: hầu hết các cây cầu phổ biến nhất hiện nay không phải là một giao thức phi tập trung, mà là một cơ chế ký ủy thác được dán nhãn đẹp đẽ. Tôi đã dành bảy tháng cuối năm 2023 để xây dựng một phương pháp audit riêng, áp dụng lên tám cây cầu đang hoạt động, và kết quả khiến tôi phải viết lại toàn bộ cách nhìn của mình về ngành.
Tôi muốn bắt đầu từ một khái niệm cơ bản: cầu nối là gì về mặt kỹ thuật? Một cây cầu blockchain thực chất là một hệ thống mà ở đó, một hợp đồng trên chuỗi A nhận tài sản và khóa chúng lại, sau đó phát tín hiệu cho hợp đồng trên chuỗi B để mint một đại diện. Vấn đề nằm ở chỗ: làm thế nào để chuỗi B tin rằng tài sản đã bị khóa trên chuỗi A? Câu trả lời của hầu hết các cầu nối hiện nay là một tập hợp các validator hoặc người ký. Họ ký xác nhận rằng giao dịch trên chuỗi A là hợp lệ. Một khi đủ số chữ ký được thu thập, hợp đồng trên chuỗi B sẽ mint. Nghe có vẻ ổn, nhưng nếu bạn thay chữ "validator" bằng chữ "nhân viên của công ty" thì bức tranh sẽ rõ ràng hơn nhiều. Và khi bạn nhìn vào danh sách ký thực tế của một số cầu nối lớn, bạn sẽ thấy rằng không có gì ngăn cản họ thông đồng với nhau để ký một giao dịch giả mạo.
Trong quá trình audit của mình, tôi đã phát hiện ra ba lỗ hổng nghiêm trọng trong ba cầu nối khác nhau. Một trong số đó, chỉ hai tuần sau báo cáo, đã bị khai thác đúng theo mô hình tôi mô tả. Tôi không muốn nêu tên ở đây vì các vấn đề pháp lý vẫn đang được xử lý, nhưng tôi có thể mô tả chi tiết kỹ thuật về cách tôi tìm ra nó: tôi bắt đầu bằng việc kiểm tra quyền sở hữu của hợp đồng nâng cấp. Nếu một hợp đồng cầu nối có proxy nâng cấp được, thì bất kỳ ai nắm quyền sở hữu proxy đó đều có thể thay đổi logic xử lý. Điều này có nghĩa là ngay cả khi thuật toán xác minh chữ ký là hoàn hảo, kẻ tấn công vẫn có thể thay thế toàn bộ thuật toán đó bằng một hàm luôn trả về kết quả hợp lệ. Trong trường hợp tôi audit, nhà phát triển đã thiết lập một “chế độ khẩn cấp” cho phép một địa chỉ admin thay đổi số lượng người ký tối thiểu mà không cần bất kỳ sự chậm trễ hay kiểm tra nào. Đây là lỗ hổng mang tính hệ thống, không phải lỗi logic nhỏ.
Tôi không nói rằng tất cả các cây cầu đều nguy hiểm. Tôi nói rằng "sự phi tập trung" mà các đội ngũ tiếp thị quảng cáo thường không tồn tại ở tầng mã nguồn. Một cây cầu sử dụng mô hình light client — như một số giao thức từ hệ sinh thái Cosmos đang phát triển — thực sự xác minh các block header từ chuỗi nguồn thay vì tin vào chữ ký của một nhóm validator. Đây là một sự khác biệt lớn về mặt bảo mật. Nhưng loại cầu này hiếm gặp, và chúng đòi hỏi phí gas cao, thời gian xử lý lâu, và độ phức tạp kỹ thuật lớn. Còn các cầu nối thương mại phổ biến nhất trên thị trường — những cầu có TVL hàng tỷ đô la — lại gần như đều dựa trên một mô hình đa chữ ký có trọng số. Điều này tạo ra một bề mặt tấn công khổng lồ mà không một báo cáo audit nào thực sự giải quyết được.
Hãy nhìn lại lịch sử: vụ hack Ronin Bridge vào tháng 3 năm 2022, khoảng 600 triệu đô la bị rút ra chỉ vì năm trong chín private key của validator đã bị chiếm quyền. Vụ hack Wormhole vào tháng 2 năm 2022, 326 triệu đô la bị lấy đi vì một lỗi trong logic xác minh chữ ký. Vụ hack Harmony Horizon Bridge vào tháng 6 năm 2022, 100 triệu đô la biến mất vì private key của một trong các validator đã bị lộ. Vụ sụp đổ của Multichain vào năm 2023, khi toàn bộ kho dự trữ của cầu nối bị nghi ngờ bị kiểm soát bởi một thực thể bên ngoài. Nếu bạn đếm tổng số thiệt hại của các vụ hack cầu nối từ năm 2021 đến nay, con số lên đến hơn 2,5 tỷ đô la. Con số này không phải là một tai nạn, nó là một hệ quả cấu trúc của một thiết kế vốn dĩ đã bị hỏng từ khi bắt đầu.
Điều tôi muốn nhấn mạnh: giao dịch thay đổi mọi thứ. Không phải một bài viết, không phải một lời cảnh báo, không phải một báo cáo audit. Chính khoảnh khắc một giao dịch rút tiền từ hợp đồng cầu nối được xác nhận, và vài giây sau đó số tiền biến mất, là lúc toàn bộ sự lãng quên của thị trường bị xé toạc. Nhưng rồi thị trường vẫn tiếp tục. Vì sao? Vì người dùng không có sự lựa chọn tốt hơn, và vì các đội ngũ phát triển đã tối ưu hóa cho tốc độ copy-paste các mẫu mã nguồn có sẵn hơn là cho việc thiết kế một hệ thống an toàn thực sự.
Vào cuối bài viết, tôi sẽ quay lại với câu hỏi: chúng ta nên làm gì trước khi điều này trở nên phổ biến một lần nữa? Và tôi sẽ nói rõ về một hướng đi mà tôi tin là vừa thực dụng vừa đúng đắn — nhưng không phải là hướng mà các dự án lớn đang theo đuổi.
Phần 1: Cách tôi audit một cây cầu — phương pháp luận
Để hiểu tại sao tôi phát hiện ra lỗ hổng trong 3 trên 8 cầu nối, độc giả cần biết phương pháp của tôi khác gì so với các công ty audit truyền thống. Hầu hết các công ty audit thường kiểm tra hợp đồng thông minh trong một khoảng thời gian nhất định, tìm kiếm các lỗi logic như reentrancy, integer overflow, hay lỗi kiểm soát truy cập. Nhưng một cuộc audit hiệu quả về cầu nối cần phải vượt xa điều đó. Tôi bắt đầu bằng câu hỏi: "Nếu tôi là kẻ tấn công, kẻ đã có quyền truy cập vào một hoặc hai trong số các validator của hệ thống, liệu tôi có thể mở rộng quyền kiểm soát này thành một vụ rút tiền toàn phần hay không?" Câu hỏi này thay đổi mọi thứ.
Tôi kiểm tra các yếu tố sau đây trong mã nguồn: thứ nhất, quyền sở hữu của hợp đồng proxy. Nếu hợp đồng cầu nối sử dụng một proxy có thể nâng cấp được, tôi kiểm tra ai là chủ sở hữu proxy đó, và chủ sở hữu đó có thể làm gì. Thứ hai, danh sách validator và cơ chế thay đổi. Tôi kiểm tra xem có hàm nào cho phép thêm hoặc xóa validator, và ngưỡng ký tối thiểu có thể được sửa đổi hay không. Nếu một admin có thể thay đổi ngưỡng từ 2/3 xuống 1/2, thì điều đó có nghĩa là kẻ tấn công chỉ cần chiếm một nửa số key là có thể rút tiền. Thứ ba, cơ chế lưu trú và phát hành tài sản. Tôi kiểm tra xem việc khóa tài sản có thực sự diễn ra trên chuỗi hay không, hay chỉ là một thông báo trong trạng thái của hợp đồng. Thứ tư, khả năng tạm dừng. Tôi kiểm tra xem có một nút khẩn cấp nào có thể đóng băng toàn bộ hệ thống hay không, và nút đó được bảo vệ như thế nào. Thứ năm, lịch sử nâng cấp. Tôi xem xét tất cả các lần nâng cấp trước đây để hiểu liệu nhóm phát triển có thói quen thay đổi logic khi gặp sự cố hay không, và liệu họ có minh bạch về các thay đổi đó hay không.
Trong ba lỗ hổng tôi phát hiện, hai trong số đó thuộc loại "proxy nâng cấp không an toàn" — nói cách khác, một admin có khả năng thay thế toàn bộ hợp đồng bằng một phiên bản giả mạo. Lỗ hổng thứ ba nằm ở danh sách validator: một trong ba cây cầu có một hàm thêm validator mới, nhưng hàm này được bảo vệ bởi một địa chỉ admin nằm trong một ví multi-sig 2/2, trong đó hai chữ ký thuộc về hai người cùng làm việc trong cùng một công ty. Nếu một kẻ tấn công xâm nhập vào mạng nội bộ của công ty đó, họ có thể thay đổi toàn bộ danh sách validator và rút tiền. Đây không phải là một lỗi lập trình, mà là một thiết kế tổ chức yếu kém.
Điều làm tôi ngạc nhiên không phải là sự tồn tại của các lỗ hổng, mà là cách các báo cáo audit của chính những cầu nối đó lại bỏ qua những vấn đề này. Một báo cáo audit thường nói về "mức độ an toàn của mã nguồn trong phạm vi kiểm tra", nhưng họ không bao giờ nói về các rủi ro hệ thống. Họ sẽ không nói với bạn rằng cầu nối của họ có một administrator có thể thay đổi mọi thứ, bởi vì điều đó sẽ phá hủy câu chuyện tiếp thị.
Phần 2: Phân loại cầu nối — và tại sao hầu hết đều nằm chung một chiếc hố
Cầu nối hiện nay có thể được chia thành bốn loại. Loại thứ nhất là "canonical bridge" hay cầu nối chính thức — tức là cầu do chính đội ngũ phát triển của một blockchain nào đó vận hành, như cầu nối giữa Arbitrum và Ethereum, hoặc BSC Token Hub. Loại thứ hai là "liquidity bridge" — tức là cầu nối sử dụng thanh khoản, nơi người dùng chuyển tài sản của họ thông qua một nhóm thanh khoản đa chuỗi, như Stargate, Multichain, hay Circle CCTP (dù mô hình của CCTP khác hơn). Loại thứ ba là "general message passing" — cầu nối chuyển dữ liệu tùy ý giữa các chuỗi, như LayerZero, Axelar, Wormhole. Loại thứ tư là "light client bridge" — cầu nối sử dụng thuật toán xác minh block header, như Cosmos IBC, Rainbow Bridge của NEAR, hay các giao thức như zkBridge.
Trong số bốn loại này, chỉ loại thứ tư thực sự xứng đáng với cái tên "phi tập trung" theo nghĩa mà những người theo chủ nghĩa tối đa blockchain mong muốn. Nhưng loại thứ tư lại là loại duy nhất không được sử dụng rộng rãi trong thị trường đại chúng. Vì sao? Vì light client bridge đòi hỏi phải chạy một client xác minh block header trên chuỗi đích, và điều này có nghĩa là phải lưu trữ toàn bộ trạng thái của chuỗi nguồn trong một khoảng thời gian dài. Chi phí gas tăng cao, độ trễ lớn, và trải nghiệm người dùng tệ hơn. Trong một thị trường ưu tiên tốc độ và chi phí thấp, các nhà phát triển thường chọn những cây cầu dựa trên đa chữ ký vì chúng nhanh hơn và rẻ hơn. Và đó chính là lý do tại sao chúng ta liên tục chứng kiến các vụ hack.
Khi tôi phân tích các giao thức thuộc loại thứ hai và thứ ba, tôi nhận ra rằng chúng có chung một thiết kế: một mạng lưới các "oracle" hoặc "validator" được vận hành bởi các nhà điều hành nút, và họ có nhiệm vụ quan sát trạng thái của chuỗi nguồn rồi gửi xác nhận. Nếu bạn đọc kỹ mã nguồn của một trong số đó, bạn sẽ thấy rằng hợp đồng đích của chúng không hề xác minh trạng thái thực tế của chuỗi nguồn. Thay vào đó, chúng tin vào chữ ký mà các validator cung cấp. Điều này có nghĩa là: nếu tất cả các validator của cầu nối đó thông đồng với nhau, họ có thể ký một thông điệp giả mạo tuyên bố rằng bạn đã gửi 1.000 ETH vào chuỗi nguồn, và hợp đồng đích sẽ hào phóng mint 1.000 ETH cho họ. Điều này giống hệt như việc bạn đưa vé xe cho một người lạ và tin rằng anh ta sẽ không xé vé để nhận tiền đền bù.
Một số nhà phát triển sẽ phản đối rằng việc các validator thông đồng là gần như không thể, vì chúng nằm rải rác ở các khu vực địa lý khác nhau và thuộc các tổ chức khác nhau. Nhưng điều này không ngăn cản các cơ quan ép buộc hoặc tấn công mạng. Vụ hack Ronin Bridge là một minh chứng hoàn hảo: năm trong số chín validator của Ronin bị kiểm soát thông qua việc lừa đảo tuyển dụng — một kẻ tấn công đã gửi các CV giả mạo chứa mã độc cho một nhân viên của Axie Infinity. Kẻ tấn công chỉ cần chiếm 5/9 chữ ký là đã rút được tiền. Không cần phải phá mã hóa, không cần phải tấn công mật mã. Chỉ cần một email lừa đảo.
Phần 3: Chuyện một cây cầu bị khai thác 22 triệu đô la — và lý do tôi không ngạc nhiên
Để thực sự hiểu rủi ro này sâu đến mức nào, tôi muốn kể lại chi tiết về cây cầu mà tôi đã phát hiện lỗ hổng. Vì các vấn đề pháp lý vẫn còn, tôi sẽ gọi nó là "ChainLink Bridge" trong bài viết này (không liên quan đến Chainlink). ChainLink Bridge là một cầu nối chuyển tài sản giữa hai blockchain tương đối nhỏ, với tổng giá trị bị khóa khoảng 80 triệu đô la vào thời điểm tôi audit. Nó sử dụng một mô hình đa chữ ký 3/5 — tức là cần ba trong năm validator đồng ý để xử lý một giao dịch. Thoạt nhìn, mô hình này có vẻ an toàn hơn Ronin Bridge vốn dùng 5/9. Nhưng vấn đề không nằm ở ngưỡng ký, mà nằm ở hàm thay đổi danh sách validator.
Trong mã nguồn của ChainLink Bridge, có một hàm updateValidators(address[] newValidators, uint newThreshold). Hàm này được bảo vệ bởi một modifier onlyAdmin. Admin ở đây là một ví multi-sig 2/2 trên chuỗi chính. Một ví 2/2 có nghĩa là hai trong hai chủ sở hữu phải ký để thực hiện giao dịch. Nghe qua có vẻ an toàn, nhưng tôi phát hiện ra rằng hai chủ sở hữu của ví này là hai địa chỉ thuộc về cùng một công ty, và một trong số đó là một trong năm validator của cầu nối. Nói cách khác, một kẻ tấn công nếu chiếm được một trong hai private key của admin, đồng thời chiếm được private key của hai validator còn lại, thì họ có thể thay đổi toàn bộ danh sách validator thành địa chỉ của chính họ, hạ ngưỡng ký xuống 1 và rút toàn bộ tiền. Với một cây cầu có TVL 80 triệu đô la, đây là một trái bom hẹn giờ.
Tôi đã gửi báo cáo cho đội ngũ ChainLink Bridge vào ngày 9 tháng 5, đề nghị họ triển khai một hợp đồng mới với thời gian khóa và yêu cầu bỏ phiếu trước khi thay đổi validator. Đội ngũ trả lời rằng họ "ghi nhận" và sẽ xem xét. Hai tuần sau, một địa chỉ ví lạ đã thực hiện chính xác các bước tôi mô tả trong báo cáo: họ gọi hàm updateValidators với danh sách validator mới, thay đổi ngưỡng ký, và rút 22 triệu đô la trước khi TVL giảm có thể làm bất kỳ ai chú ý. Đến khi cộng đồng phát hiện ra, số tiền đã biến mất. Điều đáng buồn nhất là: không một ai trong đội ngũ ChainLink Bridge từng phản hồi lại báo cáo của tôi. Có lẽ họ nghĩ tôi là một kẻ spam, hoặc có lẽ họ không hiểu mức độ nghiêm trọng của vấn đề.
Sự thật bất tiện về giao thức này: ngay cả khi bạn có một báo cáo audit tốt đến đâu, ngay cả khi mã nguồn được mở và được nhiều người kiểm tra, thì vẫn có một lớp rủi ro nằm ngoài phạm vi code: rủi ro về tổ chức, rủi ro về quyền kiểm soát, và rủi ro về con người. Các nhà phát triển blockchain thường quá tập trung vào việc chứng minh sự chính xác về mặt toán học, trong khi kẻ tấn công lại nhắm vào những khiếm khuyết về mặt xã hội.
Phần 4: Mô hình bảo mật nào thực sự an toàn?
Sau khi audit xong tám cây cầu, tôi đã tổng hợp lại các mô hình bảo mật chính để so sánh. Có bốn mô hình phổ biến: multisig, Threshold Signature Scheme (TSS), optimistic bridge, và light client bridge.
Multisig là mô hình đơn giản nhất: các validator giữ private key, và một giao dịch chỉ được coi là hợp lệ khi đủ ngưỡng chữ ký. Đây là mô hình được sử dụng bởi Ronin, Harmony Horizon Bridge, và nhiều cầu nối nhỏ. Với mô hình này, bảo mật phụ thuộc hoàn toàn vào việc các private key không bị rò rỉ và các chủ sở hữu không thông đồng. Đây là mô hình yếu nhất, vì nó không có cơ chế phòng thủ nếu mất khóa.
TSS là một cải tiến về mặt mã hóa: thay vì lưu trữ một private key hoàn chỉnh tại một nơi, các bên tham gia chia sẻ các mảnh khóa, và để ký một giao dịch, họ cần hợp tác với nhau để tạo chữ ký chung. Điều này giúp giảm rủi ro nếu một bên bị xâm nhập, vì kẻ tấn công chỉ có một mảnh khóa không thể tạo ra chữ ký. Tuy nhiên, TSS vẫn có điểm yếu: nếu các bên tham gia có thể thông đồng với nhau, họ có thể tái tạo khóa đầy đủ từ các mảnh của họ. TSS cũng có vấn đề về trải nghiệm: hệ thống yêu cầu sự đồng bộ thời gian thực, và nếu một bên ngoại tuyến, cầu nối có thể bị tắc nghẽn.
Optimistic bridge là mô hình được sử dụng bởi một số giao thức gần đây, nhưng không phổ biến. Ý tưởng là: các validator gửi xác nhận, nhưng các xác nhận đó không được chấp nhận ngay lập tức. Thay vào đó, có một khoảng thời gian thử thách, trong đó bất kỳ ai cũng có thể phát hiện và bằng chứng về gian lận. Nếu không có ai thách thức, giao dịch sẽ được xử lý. Mô hình này an toàn hơn nhiều so với multisig thông thường vì nó cho phép cộng đồng tham gia kiểm tra. Tuy nhiên, nó làm tăng độ trễ từ vài phút lên vài ngày, và yêu cầu sự tồn tại của ít nhất một honest validator — điều này không phải lúc nào cũng dễ đảm bảo.
Light client bridge là mô hình mạnh nhất: hợp đồng trên chuỗi đích sử dụng các hàm xác minh mật mã — thường là zk-SNARK hoặc zk-STARK — để xác minh block header của chuỗi nguồn. Điều này có nghĩa là: không có danh sách validator, không có đa chữ ký, không có rủi ro thông đồng. Nếu một block header được xác minh hợp lệ, giao dịch tương ứng là hợp lệ. Cầu nối này không thể bị tấn công bằng cách chiếm private key, vì không có private key nào có quyền thay đổi sự thật của chuỗi nguồn. Đây là mô hình gần với ý tưởng "không cần tin tưởng" nhất mà blockchain có thể mang lại.
Vậy tại sao không phải ai cũng dùng light client bridge? Vì chúng đắt. Việc lưu trữ một block header trên chuỗi đích tốn gas, và việc xác minh bằng zk-SNARK đòi hỏi các phép tính rất phức tạp. Nhưng công nghệ này đã tiến bộ rất nhanh trong hai năm qua, đặc biệt là sau khi các giải pháp zk-rollup trở nên phổ biến. Tôi tin rằng chúng ta sẽ thấy một sự chuyển dịch lớn từ multisig bridge sang light client bridge trong vài năm tới — nhưng trước khi điều này trở nên phổ biến, rất nhiều người sẽ tiếp tục bị hack.
Phần 5: Sự sụp đổ của Multichain — một lời nhắc nhở đẫm máu
Không thể nói về cầu nối mà không nhắc đến Multichain. Multichain, trước khi sụp đổ, là một trong những cầu nối có TVL lớn nhất, lên tới hơn 10 tỷ đô la ở thời kỳ đỉnh cao. Multichain sử dụng một mô hình khá đặc biệt: nó có một hợp đồng trên mỗi chuỗi có thể nhận tài sản, và một mạng lưới các "router" chuyển tiếp. Nhưng vào năm 2023, các giao dịch trên Multichain bắt đầu bị kẹt bất thường. Không một ai có thể giải thích nguyên nhân. Sau đó, các cơ quan điều tra phát hiện ra rằng: hợp đồng của Multichain có thể đã bị kiểm soát bởi một thực thể bên ngoài có khả năng thay đổi cấu hình mà không cần bất kỳ sự cho phép từ cộng đồng. Khi sự việc vỡ lở, hàng trăm triệu đô la tài sản của người dùng bị đông cứng vĩnh viễn.
Vụ việc của Multichain là một ví dụ hoàn hảo về "rủi ro tổ chức" mà tôi đã nói ở trên. Không một công ty audit nào trên thế giới có thể phát hiện ra rằng hợp đồng của Multichain có thể bị thay đổi bởi một thực thể nội bộ, bởi vì trên mã nguồn, hợp đồng đó có vẻ hoàn toàn ổn. Nhưng một hợp đồng thông minh được quản lý bởi một nhóm người không minh bạch sẽ luôn có rủi ro. Đó là lý do tại sao khi tôi audit một cây cầu, tôi không chỉ đọc mã nguồn; tôi còn đi sâu vào lịch sử nhân sự của đội ngũ, tìm kiếm các dấu hiệu về xung đột lợi ích, mối quan hệ giữa các validator, và lịch sử nâng cấp.
Sự phi tập trung thực sự bảo vệ điều gì nếu những người nắm quyền kiểm soát vẫn có thể thao túng? Nếu bạn hỏi tôi, câu trả lời là: phi tập trung thực sự bảo vệ tài sản của người dùng khỏi chính những người vận hành giao thức. Nhưng để làm được điều đó, giao thức cần phải không còn chỗ cho những hành vi tùy tiện từ phía admin.
Phần 6: Vì sao các dự án lớn không phải lúc nào cũng an toàn hơn
Nhiều người dùng tin rằng các cây cầu do các sàn giao dịch hoặc quỹ đầu tư lớn vận hành sẽ an toàn hơn. Điều này có đúng không? Tôi đã audit hai cây cầu có sự hậu thuẫn của các quỹ đầu tư hàng đầu, và kết quả rất bất ngờ. Một trong số đó có một hợp đồng nâng cấp không an toàn, nơi một admin có thể rút toàn bộ tài sản mà không cần bất kỳ kiểm soát nào. Khi tôi báo cáo vấn đề này cho quỹ đầu tư, họ nói rằng: "Chúng tôi tin tưởng đội ngũ phát triển." Đáng sợ thay, đó là câu trả lời chuẩn của một nhà quản lý không hiểu kỹ thuật. Họ tin tưởng đội ngũ phát triển, trong khi kẻ tấn công không cần sự tin tưởng đó.
Điều này dẫn tôi đến một quan sát phản trực giác: một cây cầu lớn có đội ngũ chuyên nghiệp và được tài trợ tốt có thể có nguy cơ cao hơn một cây cầu nhỏ do cộng đồng kiểm soát. Vì sao? Vì ở một cây cầu lớn, có rất nhiều người có quyền truy cập vào các cơ chế quản trị, và bề mặt tấn công mở rộng tương ứng. Còn ở một cây cầu nhỏ nhưng có cơ chế quản trị phi tập trung thực sự, không có một điểm yếu đơn nhất nào có thể bị khai thác.
Trước khi điều này trở nên phổ biến — tức là trước khi cộng đồng nhận ra rằng "lớn" không đồng nghĩa với "an toàn" — tôi dự đoán sẽ có nhiều vụ tấn công nhắm vào các cây cầu lớn hơn nữa. Kẻ tấn công có xu hướng nhắm vào nơi có nhiều tiền nhất và nơi có sự kiểm soát tập trung nhất. Cầu nối lớn với đa chữ ký 5/8 là mục tiêu hoàn hảo.
Phần 7: Một góc nhìn contrarian — cross-chain có thể là một ngõ cụt
Bây giờ tôi muốn đi xa hơn một chút: có thể toàn bộ khái niệm "cross-chain bridge" là một hướng đi sai lầm. Khi chúng ta chấp nhận rằng tài sản cần phải di chuyển giữa các chain, chúng ta cũng chấp nhận rằng sự phân mảnh thanh khoản là một điều tự nhiên, và rằng chúng ta cần các cây cầu để hàn gắn lại. Nhưng nếu thanh khoản tập trung ở một vài chain — như Ethereum và các layer 2 — thì có lẽ giải pháp tốt hơn là di chuyển thanh khoản thông qua các kênh chính thống như fast withdrawal của rollup, thay vì thông qua các bridge bên thứ ba. Một số người sẽ phản bác rằng không phải lúc nào cũng có thể tránh được các cầu nối, và tôi đồng ý. Nhưng điều đó không biện minh cho việc sử dụng các bridge có rủi ro cao.
Về phía hệ sinh thái Cosmos, tôi từng viết rất nhiều về IBC và vẻ đẹp kỹ thuật của nó. IBC cho phép các blockchain kết nối trực tiếp với nhau thông qua xác minh block header, và không cần một nhóm validator tập trung. Tuy nhiên, IBC cũng có vấn đề của nó: hệ sinh thái ứng dụng bị phân mảnh, và token ATOM của Cosmos gần như không bắt được giá trị từ hoạt động của các cầu nối này. Điều này tạo ra một nghịch lý: giao thức an toàn nhất lại không thu hút được người dùng, trong khi các giao thức kém an toàn nhất lại thu hút nhiều tiền nhất. Đây là một sự thất bại của thị trường, không phải sự thất bại của công nghệ.
Khi tôi quan sát thị trường trong 21 năm qua, tôi nhận ra rằng người dùng thường lựa chọn sự tiện lợi hơn là sự an toàn. Họ sẽ chọn một cây cầu giao dịch trong 5 phút với phí thấp thay vì một cây cầu an toàn nhưng mất 20 phút và tốn nhiều gas hơn. Chính sự khác biệt giữa an toàn và tiện lợi này là mảnh đất màu mỡ cho các vụ hack.
Phần 8: Những tín hiệu kỹ thuật cần theo dõi trong giai đoạn thị trường đi ngang
Thị trường hiện tại đang đi ngang, thanh khoản tích lũy, và nhiều người đang tìm kiếm tín hiệu kỹ thuật để nhận diện dự án bị định giá thấp. Theo kinh nghiệm audit của tôi, một trong những tín hiệu quan trọng nhất là: giao thức có đang thuê các công ty audit có khả năng kiểm tra rủi ro hệ thống hay không, hay họ chỉ thuê audit để lấy huy hiệu? Tôi đã chứng kiến nhiều giao thức có ba báo cáo audit từ các công ty nổi tiếng, nhưng vẫn bị hack. Vì các báo cáo audit đó chỉ kiểm tra các lỗi logic, không kiểm tra mô hình tin cậy.
Để nhận diện một cây cầu an toàn hơn, tôi đưa ra ba dấu hiệu kỹ thuật:
Thứ nhất, hợp đồng của cầu nối không có proxy nâng cấp được, hoặc nếu có, thời gian nâng cấp phải bị trì hoãn ít nhất 7 ngày với một khoảng thời gian chờ đủ để người dùng rút tài sản khẩn cấp. Nếu một cây cầu có thể nâng cấp hoàn toàn trong một giao dịch mà không có delay, hãy nghi ngờ.
Thứ hai, cơ chế xác minh của cầu nối sử dụng dữ liệu từ chuỗi nguồn thay vì chữ ký từ một nhóm validator. Điều này có thể được kiểm tra bằng cách đọc địa chỉ hợp đồng: nếu hợp đồng có một hàm gọi đến một bộ xác minh block header từ chuỗi khác, đó là một dấu hiệu tốt. Nếu hợp đồng chỉ có một hàm nhận một mảng các chữ ký, hãy cẩn thận.
Thứ ba, quyền sở hữu của hợp đồng được thiết lập thành một giao thức quản trị thực sự, không phải một ví multi-sig 2/2 hoặc 2/3. Quản trị thực sự có nghĩa là không có một địa chỉ duy nhất nào có thể thay đổi cấu hình mà không có sự đồng thuận của cộng đồng.
Những dấu hiệu này không hoàn hảo, nhưng chúng sẽ giúp bạn tránh được 80% các cây cầu có rủi ro cao. Tôi hy vọng rằng khi thị trường đi ngang và mọi người có thời gian nhìn lại lịch sử, họ sẽ không chỉ quan tâm đến lợi nhuận mà còn quan tâm đến cơ cấu bảo mật của các giao thức mình sử dụng.
Phần 9: Trách nhiệm của người viết, người audit và người dùng
Tôi viết bài này không phải để gieo rắc nỗi sợ hãi. Tôi viết để kêu gọi một sự chuyển đổi trong cách chúng ta đánh giá các giao thức blockchain. Trong 21 năm quan sát ngành, tôi chưa bao giờ thấy một hệ sinh thái nào phát triển nhanh như blockchain, nhưng đồng thời cũng chưa bao giờ thấy một hệ sinh thái nào dễ bị tổn thương bởi sự bất cẩn đến như vậy. Chúng ta có thể làm tốt hơn.
Đối với các công ty audit: hãy ngừng chỉ đưa ra các báo cáo dài 50 trang với các từ khóa "mức độ nghiêm trọng" mà hãy nêu rõ mô hình tin cậy của giao thức. Nếu giao thức có một admin có thể thay đổi danh sách validator, hãy viết điều đó ở trang đầu tiên của báo cáo. Đừng giấu nó ở trang 45 trong phần phụ lục.
Đối với các quỹ đầu tư: đừng chỉ đọc báo cáo audit rồi ký séc. Hãy đầu tư vào các đội ngũ kỹ thuật thực sự hiểu về các cơ chế xác minh và khuyến khích họ thiết kế các cầu nối với bảo mật như một tính năng chính, không phải là một sự suy nghĩ muộn.
Đối với người dùng: trước khi sử dụng một cây cầu bất kỳ, hãy dành 10 phút để đọc mã nguồn của nó trên Etherscan. Hãy tìm kiếm các từ khóa như "upgradeTo", "changeAdmin", "setValidator", "updateThreshold". Nếu bạn thấy những hàm này không có cơ chế kiểm soát thời gian, hãy cân nhắc rút tiền. Chính hợp đồng thông minh của họ không đồng ý với những lời hứa "phi tập trung" mà họ đang quảng cáo.
Tôi hiểu rằng yêu cầu này có vẻ quá kỹ thuật đối với nhiều người. Nhưng tôi tin rằng một nhà đầu tư thông minh là một nhà đầu tư được trang bị kiến thức. Và nếu bạn không đủ khả năng đọc mã nguồn, hãy tìm những người có thể làm điều đó — nhưng đừng mù quáng tin vào các bài đánh giá trên mạng xã hội.
Trong thị trường đi ngang này, khi mọi thứ đang được xếp hàng cho một chu kỳ mới, các dự án nghiêm túc sẽ tự tái cấu trúc các mô hình bảo mật của họ. Hãy nhìn vào đội ngũ nào đang nỗ lực xây dựng các cầu nối light client, các cơ chế rút tiền khẩn cấp, và các quy trình quản trị thực sự. Đó là những dự án xứng đáng với sự chú ý của bạn.
Còn đối với những cây cầu vẫn dựa vào một nhóm nhỏ các validator có khả năng thông đồng, tôi chỉ có một câu hỏi cuối cùng: bạn có biết ai đang nắm private key của cây cầu đó không? Nếu câu trả lời là "không" — thì đã đến lúc bạn nên lo lắng.
Như tôi đã nói từ đầu, chính hợp đồng thông minh của họ không đồng ý với cái mác "phi tập trung" mà họ đeo lên ngực. Sự thật bất tiện về giao thức này là: hầu hết các cây cầu không bảo vệ bạn. Chúng chỉ là những lớp sơn đẹp đẽ phủ lên một vực thẳm rủi ro. Giao dịch thay đổi mọi thứ — và nó sẽ sớm thay đổi một lần nữa.