Tóm tắt: Vào ngày 3 tháng 11 năm 2025, sàn giao dịch phi tập trung Balancer V2 đã gặp phải sự cố bảo mật nghiêm trọng nhất trong lịch sử, dẫn đến việc đánh cắp tài sản từ 116,6 triệu đô la đến 128,6 triệu đô la. Những kẻ tấn công đã khai thác lỗ hổng trong các hợp đồng thông minh của Balancer V2 liên quan đến cơ chế swap /mất cân bằng, rút tiền thành công khỏi các nhóm thanh khoản trên nhiều blockchain , bao gồm mạng chủ Ethereum, Arbitrum, Base và Optimism . Cuộc tấn công lần không chỉ phơi bày các lỗ hổng bảo mật lâu đời trong kiến trúc Balancer V2 mà còn tiết lộ rủi ro hệ thống trong việc triển khai giao thức Chuỗi chéo. Lỗ hổng cốt lõi của cuộc tấn công lần liên quan đến các lỗi trong cơ chế kiểm tra hợp đồng thông minh của Balancer V2, đặc biệt là việc xác minh không đầy đủ khi xử lý các hoạt động swap và trạng thái số dư nhóm. Ngược lại, Balancer V3 đã tránh được tác động của cuộc tấn công lần bằng cách giới thiệu bộ lưu trữ tạm thời (EIP-1153), kiến trúc Vault được cải tiến và các cơ chế bảo mật nghiêm ngặt hơn. Những kẻ tấn công có thể phát động các cuộc tấn công vào nhiều Chuỗi cùng lúc chủ yếu là do Balancer V2 triển khai cùng một mã hợp đồng thông minh trên blockchain khác nhau, khiến cùng một lỗ hổng có thể khai thác trong mọi hoàn cảnh triển khai. I. Giới thiệu 1.1 Tổng quan về bối cảnh Balancer là một giao thức Automated Nhà Tạo Lập Thị Trường (AMM) quan trọng trong hệ sinh thái DeFi, cung cấp cơ sở hạ tầng thanh khoản quan trọng cho tài chính phi tập trung kể từ khi ra mắt vào năm 2020. Là một giao thức thanh khoản có thể lập trình, Balancer cho phép người dùng tạo các nhóm tùy chỉnh chứa tối đa tám token khác nhau và hỗ trợ tỷ trọng linh hoạt. Trước cuộc tấn công, Balancer đã quản lý hơn 750 triệu đô la trong Tổng giá trị bị khóa (TVL), trong đó hơn 350 triệu đô la được giữ trên mạng chủ Ethereum. Tuy nhiên, vào sáng sớm ngày 3 tháng 11 năm 2025, công ty bảo mật blockchain PeckShield lần đầu tiên phát hiện ra dòng tiền bất thường chảy ra và sau đó, nhiều cơ quan bảo mật, bao gồm cả Nansen, đã xác nhận rằng Balancer V2 đang bị tấn công trên quy mô lớn. Báo cáo ban đầu cho thấy thiệt hại là 70,9 triệu đô la, nhưng khi cuộc tấn công tiếp tục, ước tính cuối cùng đã tăng lên từ 116,6 triệu đô la đến 128,6 triệu đô la, khiến nó trở thành một trong những sự cố bảo mật nghiêm trọng nhất trong không gian DeFi vào năm 2025. Tài sản bị đánh cắp chủ yếu bao gồm 6.851 osETH (khoảng 26,86 triệu đô la), 6.590 WETH (khoảng 24,5 triệu đô la) và 4.260 wstETH (khoảng 19,3 triệu đô la). 1.2 Mục tiêu phân tích Báo cáo này nhằm mục đích cung cấp lần phân tích kỹ thuật toàn diện về cuộc tấn công Balancer V2, đi sâu vào nguyên nhân gốc rễ của lỗ hổng hợp đồng thông minh, cơ chế tấn công, đường lan truyền Chuỗi chéo và mối tương quan của nó với các lỗ hổng DeFi khác. Thông qua phân tích có hệ thống về sự khác biệt về kiến trúc giữa Balancer V2 và V3, chúng tôi sẽ tiết lộ lý do tại sao V3 có thể tránh được cuộc tấn công lần và cung cấp tham khảo có giá trị cho thiết kế bảo mật trong tương lai của các giao thức DeFi. Hơn nữa, báo cáo này sẽ đánh giá mức độ phức tạp về mặt kỹ thuật của việc khắc phục lỗ hổng và đề xuất các giải pháp khả thi cũng như các biện pháp phòng ngừa. 1.3 Phương pháp nghiên cứu Nghiên cứu này sử dụng phương pháp phân tích toàn diện thông tin từ nhiều nguồn, tích hợp dữ liệu giám sát thời gian thực từ các công ty bảo mật blockchain , báo cáo chính thức sau sự cố, kết quả nghiên cứu học thuật và các trường hợp lỗ hổng bảo mật lịch sử. Bằng cách so sánh và phân tích mã hợp đồng thông minh của các phiên bản Balancer khác nhau, xem xét hồ sơ giao dịch trên Chuỗi và nghiên cứu các sự kiện bảo mật tương tự như giao thức AMM, chúng tôi đã xây dựng một khuôn khổ phân tích kỹ thuật toàn diện. Nghiên cứu tham khảo báo cáo phân tích từ các tổ chức bảo mật có thẩm quyền như PeckShield, SlowMist và BlockSec, cũng như tài liệu chính thức và Sách trắng kỹ thuật của Balancer. II. Chi tiết kỹ thuật về lỗ hổng hợp đồng thông minh Balancer V2 2.1 Tổng quan về kiến trúc cốt lõi của Balancer V2 Khi Balancer V2 được ra mắt vào năm 2021, nó đã giới thiệu một thiết kế kiến trúc mang tính cách mạng. Đổi mới cốt lõi của nó nằm ở việc tách biệt hoàn toàn việc quản lý token khỏi logic nhóm. Thiết kế này được triển khai thông qua một hợp đồng Vault duy nhất, đóng vai trò là trung tâm điều khiển cho tất cả các nhóm Balancer, chịu trách nhiệm quản lý tất cả các hoạt động nắm giữ, kế toán và chuyển giao token. Kiến trúc "phân tách các mối quan tâm" này về mặt lý thuyết sẽ mang lại tính bảo mật và hiệu quả cao hơn, vì các hoạt động token nhạy cảm được tập trung trong một hợp đồng kiểm toán nghiêm ngặt. Trong kiến trúc ba lớp của Balancer V2, hợp đồng Router đóng vai trò là điểm vào của giao thức, tiếp nhận các yêu cầu giao dịch của người dùng và định tuyến chúng đến Vault. Hợp đồng Vault duy trì sổ cái số dư token cho tất cả các nhóm và sử dụng các lệnh delegatecall để gọi các hợp đồng nhóm cụ thể nhằm thực hiện các phép tính swap. Bản thân hợp đồng nhóm không nắm giữ bất kỳ token nào; nó chỉ chịu trách nhiệm triển khai logic đường cong định giá cụ thể (chẳng hạn như công thức tích hằng số cho các nhóm có trọng số hoặc bất biến StableSwap cho các nhóm ổn định). Thiết kế này cho phép Balancer hỗ trợ nhiều loại nhóm, bao gồm nhóm có trọng số, nhóm ổn định, nhóm tuyến tính và nhóm ổn định có thể cấu hình. 2.2 Cơ chế swap và các vấn đề mất cân bằng Cơ chế swap của Balancer V2 là một chức năng cốt lõi của toàn bộ giao thức, cho phép người dùng trao đổi bất kỳ hai token trong một nhóm. Trong hoạt động bình thường, hàm swap tính toán số lượng token cần trao đổi hoặc nhận được theo công thức bất biến của nhóm và sau đó cập nhật sổ cái nội bộ trong Vault. Tuy nhiên, quy trình có vẻ đơn giản này thực sự ẩn chứa những thách thức quản lý trạng thái phức tạp, đặc biệt là khi xử lý các giao dịch đa bước nhảy và hoán đổi hàng loạt. Cuộc tấn công lần có thể đã khai thác một lỗ hổng xác thực trong hoạt động swap, tương tự như lỗ hổng lỗi làm tròn mà Balancer gặp phải vào năm 2023. Trong cuộc tấn công năm 2023, những kẻ tấn công đã phát hiện ra rằng khi các nhóm tuyến tính xử lý một lượng rất nhỏ các giao dịch hoán đổi token, một số giá trị đầu ra bị xóa về 0 do làm tròn xuống, nhưng token đầu vào tương ứng vẫn được thêm vào số dư ảo của nhóm. Sự bất đối xứng này cho phép những kẻ tấn công đơn phương thêm giá trị vào nhóm, do đó thao túng tỷ giá hối đoái. Mặc dù lỗ hổng năm 2023 đã được vá vào thời điểm đó, nhưng cuộc tấn công năm 2025 cho thấy các lỗ hổng tương tự hoặc liên quan có thể tồn tại trong cơ chế swap cốt lõi của Balancer V2. Cơ chế Imbalance ban đầu được thiết kế để đảm bảo nhóm vẫn bất biến sau một hoạt động swap, nhưng trên thực tế, có thể có vấn đề do xử lý không đúng các điều kiện biên. Khi xử lý các loại token đặc biệt (chẳng hạn như token lãi, token được điều chỉnh lại hoặc token ), sổ cái nội bộ của nhóm có thể bị lệch so với số dư token thực tế. Kẻ tấn công có thể lợi dụng sự lệch này để thao túng trạng thái của nhóm thông qua các chuỗi giao dịch được thiết kế cẩn thận, cuối cùng là rút giá trị vượt quá mức đóng góp thực tế của nó. 2.3 Chức năng Kiểm tra Hợp đồng Thông minh Bị Lỗi Theo báo cáo sơ bộ, nguyên nhân gốc rễ của cuộc tấn công lần là "kiểm tra hợp đồng thông minh bị lỗi". Mô tả này chỉ ra những thiếu sót trong việc xác thực tính hợp lệ của hoạt động swap của Balancer V2. Trong các triển khai AMM mạnh mẽ, cần thực hiện các kiểm tra bất biến nghiêm ngặt sau lần thay đổi trạng thái để đảm bảo các thuộc tính cốt lõi của nhóm được duy trì. Tuy nhiên, việc triển khai Balancer V2 có thể đã bỏ sót hoặc làm suy yếu các kiểm tra này tại một số điểm quan trọng. Cụ thể, các vấn đề có thể phát sinh trong các lĩnh vực sau: Thứ nhất, Vault cần theo dõi luồng token ròng giữa nhiều nhóm khi xử lý các hoạt động batchSwap. Nếu một bước xác thực không thành công trong quy trình quyết toán phức tạp này, kẻ tấn công có thể xây dựng một chuỗi giao dịch có vẻ hợp lệ nhưng thực chất lại vi phạm các bất biến của nhóm. Thứ hai, tương tác giữa các nhóm tuyến tính và các nhóm ổn định có thể cấu hình liên quan đến các phép tính tỷ giá hối đoái phức tạp và quản lý lượng cung ứng ảo; bất kỳ vấn đề về độ chính xác hoặc xử lý sai các điều kiện biên trong các phép tính này đều có thể bị khai thác. Thứ ba, cơ chế lưu trữ bộ nhớ đệm số dư token của Vault trong một số trường hợp có thể trả về dữ liệu lỗi thời, khiến các hoạt động tiếp theo dựa trên các trạng thái không chính xác. Phân tích lỗ hổng bảo mật lịch sử cho thấy một vấn đề cơ bản: cuộc tấn công token giảm phát mà Balancer gặp phải vào năm 2020 đã phơi bày một vấn đề cơ bản: giao thức giả định rằng tất cả các hoạt động transferFrom token ERC20 sẽ chuyển một số tiền cụ thể chính xác, nhưng trên thực tế, một số token lại phát sinh phí chuyển khoản. Mặc dù vấn đề cụ thể này đã được khắc phục, các mô hình "dựa trên giả thuyết" tương tự có thể xuất hiện trở lại ở những nơi khác. Cuộc tấn công năm 2025 có thể liên quan đến các giả định không chính xác về một số trường hợp ngoại lệ, cho phép kẻ tấn công bỏ qua các kiểm tra bảo mật bằng các đầu vào được chế tạo cẩn thận. 2.4 Tái tạo luồng tấn công Dựa trên dữ liệu giao dịch Chuỗi và phân tích của các cơ quan an ninh, chúng tôi có thể tái tạo luồng chung của cuộc tấn công. Trước tiên, kẻ tấn công nhận Khoản vay nhanh lớn từ các nền tảng như dYdX , cho phép chúng thao túng số tiền khổng lồ trong một giao dịch duy nhất mà không thực sự sở hữu tài sản này. Tiếp theo, kẻ tấn công sử dụng tính năng batchSwap của Vault để cẩn thận xây dựng sê-ri các hoạt động hoán đổi có vẻ bình thường nhưng thực chất lại khai thác các lỗ hổng xác thực. Chìa khóa của cuộc tấn công nằm ở việc thao túng trạng thái nội bộ của nhóm để tạo ra sự không nhất quán với số dư token thực tế. Điều này có thể đạt được theo những cách sau: Đầu tiên, bằng cách sử dụng các kết hợp token cụ thể và đường dẫn hoán đổi để kích hoạt các điều kiện biên của Vault, khiến một số kiểm tra xác thực bị bỏ qua hoặc trả về kết quả không chính xác. Thứ hai, bằng cách khai thác các lỗ hổng tính toán tỷ giá hối đoái trong các nhóm ổn định tuyến tính hoặc có thể cấu hình, tạo ra các lỗi làm tròn thông qua khối lượng hoán đổi cực nhỏ hoặc cực lớn. Thứ ba, bằng cách xây dựng các đường dẫn hoán đổi vòng tròn giữa nhiều nhóm, khuếch đại lợi nhuận bằng cách khai thác chênh lệch tỷ giá hối đoái và độ trễ thời gian giữa các nhóm khác nhau. Sau khi thao túng thành công trạng thái nhóm, những kẻ tấn công đã thực hiện rút tiền, rút nhiều giá trị hơn số tiền chúng thực sự gửi. Những giao dịch mất cân bằng rõ ràng này đã vượt qua xác minh do sai sót trong các lần kiểm tra quyết toán cuối cùng của Vault. Cuối cùng, những kẻ tấn công đã hoàn trả Khoản vay nhanh và chuyển tài sản bị đánh cắp đến các địa chỉ ví mới được tạo. Đáng chú ý, những ví này không có số dư ETH nào được sử dụng để trả phí gas trước cuộc tấn công, cho thấy những kẻ tấn công đã sử dụng một số hình thức hoạt động hàng loạt hoặc giao dịch meta để bỏ qua các yêu cầu thanh toán gas thông thường. 2.5 Tính liên quan của các lỗ hổng lịch sử Lịch sử sử bảo mật của Balancer cung cấp bối cảnh quan trọng để hiểu cuộc tấn công lần . Cuộc tấn công token vào tháng 6 năm 2020 là sự cố bảo mật lớn đầu tiên của Balancer, gây ra thiệt hại khoảng 500.000 đô la. Những kẻ tấn công đã khai thác một giả định sai lầm trong hành vi chuyển token ERC20 của Balancer: giao thức cho rằng transferFrom(amount) luôn chuyển chính xác số token, nhưng token(như STA) khấu trừ phí 1% cho lần chuyển. Bằng cách trao đổi WETH và STA liên tục, những kẻ tấn công dần dần làm cạn kiệt số dư STA trong nhóm, đồng thời thao túng tỷ giá hối đoái bằng cách khai thác sự không khớp giữa sổ cái nội bộ và số dư thực tế. Lỗ hổng lỗi làm tròn vào tháng 8 năm 2023 đại diện cho một vectơ tấn công tinh vi hơn. Lỗ hổng này ảnh hưởng đến Boosted Pools của Balancer V2, nơi những kẻ tấn công phát hiện ra rằng khi thực hiện các giao swap rất nhỏ trong các nhóm tuyến tính, số tiền đầu ra có thể bị xóa về 0 do làm tròn xuống, trong khi token đầu vào vẫn sẽ làm tăng số dư dư ảo. Bằng cách khai thác điều này, những kẻ tấn công có thể thao túng tỷ giá hối đoái của BPT (token nhóm Balancer), do đó mua tài sản trong nhóm với giá thấp hơn giá thị trường. Cuộc tấn công lần gây ra thiệt hại khoảng 2,1 triệu đô la, trong đó Balancer mất 1 triệu đô la và giao thức fork Beethoven X mất 1,1 triệu đô la. Cuộc tấn công vào tháng 11 năm 2025 có thể là sự tiến hóa hoặc kết hợp của các lỗ hổng bảo mật lịch sử này. Những kẻ tấn công có thể đã phát hiện ra một cách mới để kích hoạt các lỗi sổ cái hoặc thao túng tỷ giá hối đoái tương tự, hoặc tìm thấy một điều kiện biên chưa được phát hiện trước đó. Điều quan trọng là, mặc dù đội ngũ Balancer đã triển khai các bản sửa lỗi sau lần cuộc tấn công, nhưng một số lỗ hổng cơ bản trong kiến trúc cơ bản dường như vẫn chưa được giải quyết hoàn toàn. Điều này cho thấy vấn đề không chỉ đơn thuần là một lỗi mã cụ thể mà có thể liên quan đến các điểm yếu mang tính hệ thống trong thiết kế kiến trúc V2. III. So sánh sự khác biệt về bảo mật giữa Balancer V2 và V3 3.1 Đổi mới kiến trúc của Balancer V3 Balancer V3 đại diện cho một sự thay đổi cơ bản trong triết lý thiết kế của giao thức. Ra mắt vào cuối năm 2024, giao thức này nhằm mục đích giải quyết nợ kỹ thuật và lỗ hổng bảo mật tích tụ trong V2. Những cải tiến cốt lõi của V3 xoay quanh kiến trúc Vault được chuẩn hóa hơn, hỗ trợ riêng cho lưu trữ tạm thời và các cơ chế bảo mật mạnh mẽ hơn. Những cải tiến này không chỉ nâng cao hiệu suất và tính linh hoạt của giao thức mà quan trọng hơn là tăng cường bảo mật cơ bản. Cải tiến quan trọng nhất của V3 là việc áp dụng hoàn toàn lưu trữ tạm thời được giới thiệu trong EIP-1153. Cơ chế lưu trữ mới này sử dụng các mã lệnh TLOAD và TSTORE, cho phép dữ liệu tồn tại trong vòng đời của một giao dịch duy nhất và được tự động xóa sau khi giao dịch kết thúc. So với lưu trữ bền vững truyền thống, lưu trữ tạm thời giảm đáng kể chi phí gas , và quan trọng hơn, nó tự động ngăn chặn một số loại tấn công reentrancy. Trong V3, tất cả các trạng thái giao dịch trung gian đều được theo dõi thông qua lưu trữ tạm thời, khiến các hợp đồng bên ngoài không thể đọc được các trạng thái không nhất quán trong quá trình thực hiện giao dịch, do đó về cơ bản ngăn chặn một số vectơ tấn công. V3 cũng giới thiệu hệ thống kế toán theo chế độ "til", theo dõi các thay đổi số dư ròng trên sê-ri các hoạt động trong một giao dịch duy nhất và chỉ thực hiện quyết toán cuối cùng vào cuối giao dịch. Phương pháp này không chỉ cải thiện hiệu suất gas mà còn tăng cường bảo mật bằng cách đảm bảo tính nguyên tử của tất cả các thay đổi trạng thái trung gian. Nếu bất kỳ bước nào trong giao dịch bị lỗi, toàn bộ chuỗi hoạt động sẽ được khôi phục, không để lại trạng thái không nhất quán. Điều này trái ngược hoàn toàn với các vấn đề thực thi cục bộ có thể xảy ra trong một số tình huống nhất định trong V2. 3.2 So sánh các Cơ chế Bảo mật Cốt lõi Về mặt quản lý số dư token , V2 và V3 sử dụng phương pháp khác nhau về cơ bản. Vault của V2 lưu trữ số dư token của mỗi nhóm dưới dạng ánh xạ độc lập và sử dụng cơ chế lưu trữ đệm tinh vi để tối ưu hóa mức tiêu thụ gas. Tuy nhiên, cơ chế lưu trữ đệm này có thể trả về dữ liệu đã hết hạn trong một số trường hợp ranh giới nhất định, đặc biệt là khi xử lý token token lãi hoặc được rebase. V3 đảm bảo tính nguyên tử của các bản cập nhật đối với số dư token nhóm cơ sở và nguồn cung BPT bằng cách triển khai Vault dưới dạng hợp đồng ERC20 đa token, quản lý gốc tất cả token nhóm Balancer (BPT). Thiết kế này loại bỏ khoảng thời gian số dư và nguồn cung không đồng bộ có thể xảy ra trong V2. Về mặt bảo vệ chống lại sự nhập lại, phương pháp của V3 toàn diện và hiện đại hơn. V2 sử dụng trình sửa đổi nonReentrant truyền thống để ngăn chặn các cuộc tấn công nhập lại, nhưng phương pháp này có một lỗ hổng tinh vi: cái gọi là "sự nhập lại chỉ đọc". Một giao thức bên ngoài có thể gọi hàm truy vấn công khai của nó trong khi Vault đang "mở khóa", đọc các trạng thái trung gian không nhất quán và đưa ra quyết định dựa trên thông tin giá không chính xác. V3 hoàn toàn chặn đường tấn công này thông qua các cờ lưu trữ tạm thời và kiểm tra trạng thái nghiêm ngặt hơn. Bất kỳ thao tác nào cố gắng truy vấn trạng thái Vault trong quá trình thực hiện giao dịch đều bị từ chối trừ khi sử dụng một mẫu truy vấn rõ ràng. Tỷ giá hối đoái và xử lý độ chính xác là một điểm khác biệt quan trọng khác. V2 sử dụng các hệ số mở rộng để chuẩn hóa token có chữ số thập phân khác nhau, nhưng phép biến đổi này có thể dẫn đến mất độ chính xác hoặc tràn trong những trường hợp cực đoan. Vault của V3 tự động điều chỉnh tất cả số dư token về 18 chữ số thập phân thống nhất để tính toán và được tích hợp độ sâu với các nhà cung cấp tỷ giá hối đoái, hỗ trợ sẵn tài sản sinh lãi như Token Đặt Thanh Khoản (LST). Quan trọng hơn, V3 triển khai chiến lược làm tròn "ưu tiên giao thức" trong tất cả các phép toán: số tiền đầu ra được làm tròn xuống (để tránh trả quá nhiều) và số tiền đầu vào được làm tròn lên (để tránh trả quá ít). Nguyên tắc đơn giản nhưng quan trọng này thấm nhuần toàn bộ cơ sở mã, ngăn chặn hiệu quả sự tái diễn của các lỗ hổng lỗi làm tròn như lỗ hổng năm 2023. 3.3 Cách V3 tránh được cuộc tấn công lần Sự sống sót của V3 trong cuộc tấn công lần chủ yếu là nhờ các cải tiến bảo mật nhiều lớp. Đầu tiên, hệ thống kế toán tạm thời theo dõi chặt chẽ tất cả các luồng token trong mọi giao dịch thông qua các hàm _supplyCredit(), _takeDebt() và _accountDelta(). Các hàm này đảm bảo rằng sự thay đổi ròng trong tất cả token phải bằng 0 khi kết thúc giao dịch; bất kỳ sự mất cân bằng nào cũng sẽ dẫn đến việc hoàn nguyên giao dịch. Các lỗi xác minh có thể tồn tại trong V2 sẽ được loại bỏ trong V3 bằng lần kiểm tra cuối cùng bắt buộc này. Thứ hai, Vault của V3 tính toán lại số dư nhóm và tỷ giá hối đoái tại các điểm quan trọng trong mỗi hoạt động nhóm, đặc biệt là sau khi thực hiện bất kỳ Hooks nào. Điều này ngăn chặn hooks độc hại hoặc có lỗi tấn công logic nhóm chính thông qua khả năng nhập lại hoặc thao túng trạng thái. Các biện pháp phòng thủ của V2 về vấn đề này yếu hơn, có khả năng cho phép một số chuỗi tương tác được thiết kế đặc biệt bỏ qua xác minh. Thứ ba, V3 giới thiệu giới hạn số tiền giao dịch tối thiểu (_MINIMUM_TRADE_AMOUNT và _MINIMUM_WRAP_AMOUNT), giúp ngăn chặn các cuộc tấn công kích hoạt lỗi làm tròn hoặc điều kiện biên thông qua các giao dịch cực nhỏ. Biện pháp phòng thủ đơn giản nhưng hiệu quả này trực tiếp giải quyết các cuộc tấn công thao túng vi mô mà V2 đã lần gặp phải trong lịch sử . Cuối cùng, cơ sở mã V3 đã trải qua kiểm toán bảo mật và xác minh chính thức có hệ thống hơn. Đội ngũ giao thức đã công khai cơ sở mã để cộng đồng xem xét trước khi phát hành V3 và hợp tác với một số công ty bảo mật hàng đầu trong kiểm toán cạnh tranh. Văn hóa phát triển "ưu tiên bảo mật" này, cùng với các bài học kinh nghiệm từ các lỗ hổng bảo mật lịch sử của V2, đã cho phép V3 tránh được nhiều cạm bẫy bảo mật tiềm ẩn trong giai đoạn thiết kế. 3.4 Thách thức về lộ trình nâng cấp và khả năng tương thích Mặc dù V3 có những lợi thế đáng kể về bảo mật, việc di chuyển từ V2 lên V3 không phải là một nâng cấp hợp đồng đơn giản mà đòi hỏi phải triển khai lại giao thức hoàn chỉnh và di chuyển thanh khoản. Quá trình này phải đối mặt với nhiều thách thức. Thứ nhất, V2 và V3 không tương thích về mặt API và cấu trúc dữ liệu, và các ứng dụng DeFi tích hợp Balancer yêu cầu sửa đổi mã lượng lớn để hỗ trợ V3. Thứ hai, nhà cung cấp thanh khoản cần rút tiền từ các pool V2 và gửi lại vào các pool V3, một quá trình liên quan đến chi phí giao dịch và phân mảnh thanh khoản tạm thời. Một vấn đề nghiêm trọng hơn nằm ở tính chất không thể tạm dừng của các pool V2. Balancer V2 triển khai cơ chế "cửa sổ tạm dừng", cho phép tạm dừng hoạt động của pool và người dùng rút tiền khi phát hiện ra lỗ hổng khẩn cấp. Tuy nhiên, cửa sổ này sẽ hết hạn sau một khoảng thời gian nhất định và pool không thể bị tạm dừng sau đó. Hơn nữa, các loại pool cũ hơn (chẳng hạn như một số pool tuyến tính) hoàn toàn không hỗ trợ chức năng tạm dừng. Điều này có nghĩa là khi phát hiện ra lỗ hổng, đội ngũ giao thức không thể thực thi bảo vệ cho tất cả tiền của người dùng và chỉ có thể dựa vào việc người dùng rút tiền kịp thời. Cuộc tấn công năm 2025 có thể đã khai thác các pool cũ hơn, không thể tạm dừng này. Về mặt kỹ thuật, giải pháp triệt để nhất là từ bỏ hoàn toàn V2 và buộc toàn bộ thanh khoản phải chuyển sang V3. Tuy nhiên, điều này khó đạt được trong hoàn cảnh phi tập trung vì đội ngũ giao thức không thể buộc người dùng hành động. Một giải pháp thực tế hơn là triển khai các bản vá khẩn cấp trên V2; mặc dù điều này không thể loại bỏ hoàn toàn các điểm yếu về kiến trúc, nhưng ít nhất nó có thể chặn các vectơ tấn công đã biết. Trong khi đó, khích lệ(như phần thưởng token hoặc chia sẻ phí giao dịch cao hơn) khuyến khích nhà cung cấp thanh khoản tự nguyện di chuyển sang V3. IV. Phân tích cơ chế tấn công chuỗi Chuỗi 4.1 Kiến trúc triển khai Chuỗi chéo của Balancer Là một giao thức đa chuỗi , Balancer triển khai phiên bản V2 của mình trên nhiều mạng blockchain , bao gồm mạng chủ Ethereum, Arbitrum, Optimism, Base, Polygon và Avalanche . Chiến lược đa chuỗi này nhằm mục đích tận dụng lợi thế của các mạng khác nhau: Ethereum cung cấp tính bảo mật và thanh khoản cao nhất, các mạng Layer 2 như Arbitrum và Optimism cung cấp chi phí giao dịch thấp hơn, trong khi Chuỗi khác như Polygon và Avalanche thu hút các cộng đồng người dùng và hệ sinh thái ứng dụng cụ thể. Về mặt kỹ thuật, Balancer triển khai các phiên bản hợp đồng thông minh độc lập nhưng gần như giống hệt nhau trên mỗi Chuỗi. Mô hình triển khai "sao chép và dán" này rất phổ biến trong lĩnh vực DeFi vì nó đơn giản hóa việc phát triển và bảo trì: cùng một mã kiểm toán có thể được sử dụng lại trên nhiều mạng, về mặt lý thuyết cung cấp các đảm bảo bảo mật nhất quán. Mã bytecode của hợp đồng Vault, hợp đồng Pool và hợp đồng Router gần như giống hệt nhau trên Chuỗi khác nhau, chỉ có một số khác biệt nhỏ về các tham số triển khai (chẳng hạn như thanh khoản ban đầu hoặc địa chỉ quản trị). Một tính năng chính của kiến trúc này là tính độc lập giữa các Chuỗi. Mỗi phiên bản Balancer trên mỗi Chuỗi có nhóm thanh khoản và số dư token độc lập riêng, và chúng không giao tiếp trực tiếp với nhau. Thị phần thanh khoản của người dùng trong nhóm Balancer trên Ethereum không thể được sử dụng trực tiếp trên Arbitrum trừ khi được chuyển qua cầu nối xuyên chuỗi. Sự cô lập này giúp hạn chế sự lây lan rủi ro trong các trường hợp bình thường, nhưng khi đối diện các lỗ hổng ở cấp độ hợp đồng thông minh, tính độc lập này trở thành một điểm yếu mang tính hệ thống. 4.2 Rủi ro hệ thống của cùng một mã nguồn Đặc điểm đáng báo động nhất của cuộc tấn công lần là khả năng ảnh hưởng đến nhiều blockchain cùng lúc. Kẻ tấn công không cần phải phát triển các khai thác khác nhau cho mỗi Chuỗi; Thay vào đó, chúng có thể sử dụng gần như cùng một tập lệnh tấn công để thực thi lặp đi lặp lại trên tất cả các mạng đã triển khai Balancer V2. Mô hình "xây dựng một lần, tấn công mọi nơi" này bắt nguồn từ việc sử dụng cùng một mã trong các triển khai xuyên Chuỗi. Khi một lỗ hổng hợp đồng thông minh tồn tại trong logic mã lõi, lỗ hổng đó sẽ được sao chép trong tất cả các phiên bản triển khai bằng cùng một mã. Trong trường hợp của Balancer V2, cả hợp đồng Ethereum Vault và hợp đồng Arbitrum Vault đều chứa cùng một lỗ hổng xác minh swap. Khi kẻ tấn công phát hiện và xác minh một lỗ hổng nhắm vào mạng chủ Ethereum , chúng có thể lặp lại cùng một cuộc tấn công trên Chuỗi tương thích EVM khác chỉ bằng cách sửa đổi địa chỉ hợp đồng mục tiêu và điều chỉnh các tham số gas . Rủi ro hệ thống này được gọi là "điểm lỗi đơn" trong bảo mật phần mềm truyền thống, nhưng tác động của nó còn sâu sắc hơn nhiều trong hoàn cảnh blockchain . Do tính bất biến của hợp đồng thông minh, ngay cả khi lỗ hổng được phát hiện trên một Chuỗi và bản sửa lỗi được phát triển, nó cũng không thể được áp dụng nhanh chóng cho tất cả Chuỗi. Mỗi Chuỗi cần phải triển khai độc lập một phiên bản hợp đồng mới và di chuyển thanh khoản, một quá trình có thể mất vài ngày hoặc thậm chí vài tuần. Trong thời gian này, những kẻ tấn công có nhiều thời gian để tiếp tục khai thác trên Chuỗi chưa vá. Nghiêm trọng hơn, sự đồng thời của các cuộc tấn công Chuỗi làm khuếch đại tổn thất tài chính. Nếu lỗ hổng chỉ ảnh hưởng đến một blockchain duy nhất, những kẻ tấn công bị giới hạn bởi thanh khoản khả dụng và chi phí gas trên Chuỗi đó. Tuy nhiên, khi một cuộc tấn công có thể được thực hiện đồng thời trên nhiều Chuỗi, tổng thiệt hại có thể gấp nhiều lần so với một Chuỗi lần. Trong cuộc tấn công Balancer, mặc dù mạng chủ Ethereum chịu tổn thất lớn nhất (khoảng 91 triệu đô la), nhưng các khoản lỗ bổ sung trên Arbitrum, Base và Optimism đã đẩy tổng số tiền vượt mốc 100 triệu đô la. 4.3 Chiến lược phối hợp Chuỗi chéo của kẻ tấn công Phân tích dữ liệu Chuỗi cho thấy những kẻ tấn công đã thể hiện trình độ kỹ thuật cao và lập kế hoạch tỉ mỉ. Các cuộc tấn công được phát động gần như đồng thời trên nhiều Chuỗi, cho thấy rằng những kẻ tấn công đã sử dụng các tập lệnh tự động hoặc mạng bot để phối hợp hành động của chúng. Sự phối hợp này rất quan trọng để tối đa hóa lợi nhuận , vì đội ngũ giao thức có thể triển khai các biện pháp phòng thủ (chẳng hạn như tạm dừng nhóm hoặc cảnh báo người dùng) trên Chuỗi khác khi phát hiện ra cuộc tấn công vào một Chuỗi . Những kẻ tấn công có thể đã xác thực khai thác trước trên các mạng thử nghiệm hoặc sidechain có chi phí thấp hơn để đảm bảo tính chính xác và độ tin cậy của logic tấn công. Sau đó, chúng chọn phát động cuộc tấn công trong thời gian thanh khoản tương đối thấp để giảm rủi ro bị phát hiện bởi các hệ thống giám sát thời gian thực. Việc xây dựng các giao dịch tấn công cho thấy những kẻ tấn công đã hiểu sâu sắc về các cơ chế nội bộ của Balancer V2, cho phép chúng tính toán chính xác số lượng token và thứ tự trao đổi cần thiết để kích hoạt lỗ hổng bảo mật. Đặc biệt đáng chú ý là sự tập trung của những kẻ tấn công vào việc tối ưu hóa gas . Trong một hoàn cảnh như mạng chủ Ethereum, nơi chi phí gas cao, những kẻ tấn công đã sử dụng nhiều kỹ thuật khác nhau để giảm chi phí giao dịch, bao gồm các hoạt động hàng loạt, sử dụng hiệu quả Khoản vay nhanh và hợp lý hóa Chuỗi gọi hợp đồng. Trên các mạng Layer 2, mặc dù chi phí gas thấp hơn, những kẻ tấn công vẫn tối ưu hóa cấu trúc giao dịch để tối đa hóa hệ số biên lợi nhuận của lần cuộc tấn công. Tính chuyên nghiệp này cho thấy cuộc tấn công có thể được dàn dựng bởi một đội ngũ giàu kinh nghiệm, chứ không phải một hacker đơn lẻ. Chiến lược chuyển tiền sau cuộc tấn công cũng cho thấy một tư duy Chuỗi chéo. Tài sản bị đánh cắp đã nhanh chóng được phân tán đến nhiều địa chỉ ví mới được tạo và sau đó tẩy trắng thông qua nhiều con đường khác nhau. Một số tiền vẫn nằm trên Chuỗi gốc và được trao đổi thông qua sàn giao dịch phi tập trung, trong khi những khoản tiền khác được chuyển đến các mạng khác thông qua cầu nối xuyên chuỗi. Chiến lược phân tán này làm tăng độ khó trong việc theo dõi và đóng băng tiền, đồng thời cung cấp cho kẻ tấn công nhiều kênh kiếm tiền. 4.4 Thách thức về quản trị bảo mật của các giao thức chuỗi Chuỗi Cuộc tấn công lần làm nổi bật những thách thức độc đáo mà các giao thức chuỗi Chuỗi phải đối mặt về mặt quản trị bảo mật. Trong hoàn cảnh Chuỗi đơn, đội ngũ giao thức có thể tập trung vào việc giám sát trạng thái của một mạng và phản ứng nhanh chóng với các bất thường. Tuy nhiên, trong hoàn cảnh đa chuỗi , các tài nguyên giám sát bị phân tán, trong khi bề mặt tấn công mở rộng theo cấp số nhân. Đội ngũ Balancer cần giám sát hơn một chục mạng blockchain cùng lúc, mỗi mạng có thời gian khối, mô hình giao dịch và đặc điểm hành vi người dùng riêng. Cơ chế ứng phó sự cố cũng phức tạp hơn trong hoàn cảnh Chuỗi chéo. Khi phát hiện một cuộc tấn công trên một Chuỗi, đội ngũ cần nhanh chóng đánh giá xem tất cả Chuỗi có bị đe dọa hay không và sau đó phối hợp các biện pháp phòng thủ đa chuỗi. Tuy nhiên, như đã đề cập trước đó, một số nhóm cũ thiếu chức năng tạm dừng, khiến việc phòng thủ toàn cầu ở cấp độ giao thức trở nên bất khả thi. Đội ngũ chỉ có thể thông báo cho người dùng thông qua phương tiện truyền thông xã hội và cảnh báo giao diện người dùng, nhưng việc phụ thuộc vào sáng kiến của người dùng này có hiệu quả hạn chế trong các tình huống tấn công đang phát triển nhanh chóng. Nâng cấp mã và triển khai bản vá cũng đầy thách thức trong hoàn cảnh chuỗi Chuỗi . Ngay cả khi một phiên bản mới của hợp đồng được phát triển để khắc phục các lỗ hổng, việc triển khai nó trên tất cả Chuỗi vẫn đòi hỏi lượng lớn công sức và sự phối hợp. Mỗi Chuỗi có thể có các yêu cầu triển khai, biến động giá gas và tắc nghẽn mạng khác nhau. Quan trọng hơn, nâng cấp yêu cầu bỏ phiếu quản trị trên tất cả Chuỗi(nếu giao thức sử dụng quản trị phi tập trung) và tốc độ tham gia quản trị và bỏ phiếu có thể rất khác nhau giữa Chuỗi khác nhau. Về lâu dài, ngành DeFi cần phát triển các mô hình bảo mật mới để giải quyết những thách thức của việc triển khai Chuỗi chéo. Một số hướng khả thi bao gồm: triển khai các hệ thống giám sát và cảnh báo chuỗi Chuỗi có khả năng phát hiện hành vi bất thường trên một Chuỗi và tự động kích hoạt các biện pháp phòng thủ trên Chuỗi khác; Phát triển các công cụ xác minh chính thức để chứng minh toán học các hợp đồng thông minh trước khi triển khai, đảm bảo rằng các thuộc tính bảo mật cốt lõi được đáp ứng trên tất cả Chuỗi; thiết lập các liên minh bảo mật xuyên Chuỗi để cho phép các giao thức khác nhau chia sẻ thông tin tình báo về mối đe dọa và các chiến lược phòng thủ; và khám phá các kiến trúc mô-đun cho phép các bản vá bảo mật được áp dụng nhanh chóng cho tất cả Chuỗi thông qua các hợp đồng proxy nâng cấp . V. Các nghiên cứu điển hình về lỗ hổng trong các giao thức DeFi tương tự 5.1 Các vấn đề bảo mật phổ biến của các giao thức AMM Các giao thức Automated Nhà Tạo Lập Thị Trường ( AMM) đóng nhân vật trung tâm trong hệ sinh thái DeFi, nhưng logic toán học phức tạp và quản lý trạng thái của chúng khiến chúng trở thành mục tiêu chính của những kẻ tấn công. Bằng cách phân tích các lỗ hổng lịch sử trong các giao thức AMM chính như Balancer, Uniswap và Curve, chúng ta có thể xác định một số vấn đề bảo mật thường gặp, gốc rễ của chúng thường nằm ở sự phức tạp vốn có của chính mô hình AMM. Các cuộc tấn công reentrancy là một trong những mối đe dọa dai dẳng nhất đối với các giao thức AMM. Mặc dù khái niệm về các cuộc tấn công reentrancy đã được biết đến rộng rãi kể từ các cuộc tấn công DAO, nhưng tính đặc thù của AMM khiến việc phòng thủ trở nên phức tạp hơn. Năm 2023, Balancer đã phải chịu một dạng tấn công reentrancy cụ thể - "reentrancy chỉ đọc". Trong cuộc tấn công này, thay vì nhập lại hàm sửa đổi trạng thái, hợp đồng độc hại gọi các hàm truy vấn chỉ đọc của nó (chẳng hạn như getPoolTokens) khi Vault ở trạng thái không nhất quán. Các giao thức bên ngoài sử dụng nhóm Balancer làm oracle giá có thể đọc dữ liệu giá không chính xác, dẫn đến các quyết định sai lầm trong giao thức của chính chúng. Lỗ hổng trình biên dịch Vyper mà Curve Finance gặp phải vào năm 2023 về cơ bản là một vấn đề reentrancy: một lỗi trình biên dịch khiến các decorator @nonreentrant của các hàm khác nhau sử dụng các khóa độc lập, khiến reentrancy liên hàm có thể xảy ra. Mất độ chính xác và lỗi làm tròn là một mối đe dọa nghiêm trọng khác. Các giao thức AMM bao gồm lượng lớn các phép chia và phép nhân, yêu cầu chuyển đổi đơn vị khi xử lý token có chữ số thập phân khác nhau. Trong cuộc tấn công Boosted Pools của Balancer vào năm 2023, kẻ tấn công đã thao túng tỷ giá hối đoái BPT một cách có hệ thống bằng cách khai thác hành vi làm tròn xuống của các nhóm tuyến tính khi xử lý các số tiền cực nhỏ. Tương tự, Giao thức Velodrome đã bị tấn công do lỗi làm tròn trong tính toán bất biến: khi x*y nhỏ hơn 1e18, một biến trung gian bị đặt về 0, khiến việc xác minh hằng số tích không thành công và cho phép kẻ tấn công làm trống nhóm. Những trường hợp này chứng minh rằng ngay cả những vấn đề xử lý độ chính xác tưởng chừng như nhỏ nhặt cũng có thể bị khuếch đại thành các lỗ hổng nghiêm trọng trong một chuỗi tấn công được thiết kế tốt. Thao túng giá là một thách thức về mặt cấu trúc mà các giao thức AMM đối diện. Vì giá của một nhóm hoàn toàn được xác định bởi tỷ lệ token nội bộ của nhóm, nên bất kỳ hoạt động nào có thể thay đổi đáng kể tỷ lệ này đều có thể khiến giá lệch khỏi thị trường. Mặc dù những sai lệch như vậy thường được các nhà đầu cơ chênh lệch giá nhanh chóng điều chỉnh, nhưng kẻ tấn công có thể khai thác khoảng thời gian ngắn ngủi này trong một số trường hợp nhất định. Khoản vay nhanh làm giảm đáng kể rào cản đối với các cuộc tấn công thao túng giá vì kẻ tấn công không cần lượng lớn để tạm thời tác động đến trạng thái của nhóm. Trong sự cố token PancakeSwap BH năm 2023, kẻ tấn công đã sử dụng Khoản vay nhanh để trao đổi BH với mức giá cực thấp và sau đó rút thanh khoản khỏi một nhóm cụ thể với mức giá bị thổi phồng, thu về 1,27 triệu đô la. 5.2 So sánh Độ sâu Lỗ hổng Trình biên dịch Curve Finance Vyper Cuộc tấn công vào Curve Finance vào tháng 7 năm 2023 cung cấp một nghiên cứu điển hình quan trọng để hiểu tác động của các lỗ hổng ở cấp độ trình biên dịch. Nguyên nhân gốc rễ của cuộc tấn công lần không nằm ở logic mã của giao thức Curve, mà nằm ở một lỗi nghiêm trọng trong trình biên dịch Vyper (phiên bản v0.2.15, v0.2.16 và v0.3.0). Lỗi này khiến tất cả các hàm sử dụng trình trang trí `@nonreentrant` được gán các khe lưu trữ độc lập, thay vì dùng chung một khóa theo Key do nhà phát triển chỉ định. Điều này có nghĩa là ngay cả khi hai hàm khai báo sử dụng cùng một khóa reentrant, trình biên dịch thực sự tạo các khóa độc lập cho chúng, khiến khả năng reentrancy giữa các hàm có thể xảy ra. Kẻ tấn công đã khai thác lỗ hổng này để tấn công nhiều nhóm thanh khoản Curve, đặc biệt là nhóm pETH/ETH. Luồng tấn công bao gồm việc đầu tiên gọi hàm `remove_liquidity` của nhóm, hàm này sẽ gửi ETH đến người dùng (kích hoạt một lệnh gọi bên ngoài). Trong điều chỉnh hồi của lệnh gọi bên ngoài này, kẻ tấn công nhập lại và gọi hàm `add_liquidity`. Mặc dù cả hai hàm đều sử dụng decorator `@nonreentrant("lock")`, nhưng do lỗi trình biên dịch, chúng thực sự sử dụng các khóa khác nhau, do đó lệnh gọi lần không bị chặn. Bằng cách nhập lại `add_liquidity` trước khi cập nhật trạng thái bằng `remove_liquidity`, kẻ tấn công đã có thể thao túng nhóm dựa trên trạng thái lỗi thời, cuối cùng đánh cắp khoảng 11 triệu đô la từ nhóm pETH/ETH. Trường hợp này có một số điểm tương đồng và hàm ý quan trọng với tình huống Balancer. Thứ nhất, cả hai đều liên quan đến các cơ chế bảo mật có vẻ hoàn thiện(khóa reentrancy của Curve và kiểm tra xác minh của Balancer) nhưng lại có sai sót trong quá trình triển khai thực tế. Thứ hai, cả hai lỗ hổng đều không dễ dàng bị phát hiện bằng kiểm toán thông thường vì chúng liên quan đến các điều kiện biên hoặc vấn đề với Chuỗi cơ bản. Thứ ba, lần cuộc tấn công đều cho thấy cách kẻ tấn công có thể lợi dụng Khoản vay nhanh và các chuỗi giao dịch phức tạp để khuếch đại tác động của các lỗ hổng trong hoàn cảnh DeFi hiện đại. Tuy nhiên, trường hợp Curve cũng cho thấy một điểm khác biệt quan trọng: khi lỗ hổng bắt nguồn từ trình biên dịch chứ không phải mã ứng dụng, bản sửa lỗi trở nên phức tạp hơn nhiều. Đội ngũ Curve phải đợi cộng đồng Vyper phát hành bản sửa lỗi trước khi biên dịch lại và triển khai tất cả các hợp đồng bị ảnh hưởng. Ngược lại, nếu lỗ hổng Balancer V2 bắt nguồn từ logic hợp đồng (thay vì các công cụ cơ bản), về mặt lý thuyết, bản vá có thể được phát triển và triển khai nhanh hơn nhiều. Tuy nhiên, như chúng ta sẽ thảo luận trong phần khắc phục, nâng cấp của Balancer V2 và cửa sổ tạm dừng đã hết hạn khiến việc khắc phục nhanh chóng trở nên khó khăn ngay cả khi đã xác định được sự cố. 5.3 Bài học từ các cuộc tấn công cầu nối xuyên chuỗi Mặc dù bản thân Balancer không phải là cầu nối xuyên chuỗi, nhưng các cuộc tấn công vào cầu nối xuyên chuỗi cung cấp những bài học quý giá để hiểu được rủi ro bảo mật của các triển khai chuỗi Chuỗi . Ronin vào tháng 3 năm 2022 là một trong hacker lớn nhất trong lịch sử crypto , gây thiệt hại 620 triệu đô la. Những kẻ tấn công đã chiếm được năm trong số chín private key của trình xác thực thông qua các cuộc tấn công kỹ thuật xã hội và Phishing , qua đó giành quyền kiểm soát cơ chế đa chữ ký của cầu nối. Khía cạnh gây sốc nhất của cuộc tấn công lần là nó chỉ được phát hiện sáu ngày sau khi xảy ra, một sự chậm trễ cho phép kẻ tấn công có đủ thời gian để chuyển và tẩy trắng tiền. Vụ tấn công trị giá 320 triệu đô la vào Cầu Wormhole vào tháng 2 năm 2022 bắt nguồn từ một lỗ hổng trong logic xác minh hợp đồng thông minh. Những kẻ tấn công phát hiện ra rằng chức năng xác minh chữ ký của cầu nối có thể bị bỏ qua, cho phép chúng đúc token wETH không có tài sản thế chấp trên Solana . Nguyên nhân gốc rễ của lỗ hổng này nằm ở những giả định không chính xác về mô hình lập trình độc đáo Solana , làm nổi bật một rủi ro quan trọng trong việc triển khai Chuỗi chéo: sự khác biệt về hoàn cảnh thực thi và mô hình bảo mật trên blockchain khác nhau có thể khiến mã bảo mật trên một Chuỗi trở nên dễ bị tấn công trên chuỗi khác. Chuỗi tấn công Cầu Nomad vào tháng 8 năm 2022 đã chứng minh một "vụ cướp hỗn loạn". Do lỗi khởi tạo trong quá nâng cấp hợp đồng, bất kỳ ai cũng có thể rút tiền từ cầu nối. Sau khi kẻ tấn công đầu tiên phát hiện và khai thác lỗ hổng, các giao dịch của chúng đã bị công khai trên blockchain , dẫn đến hàng trăm kẻ bắt chước (bao gồm cả bot MEV và người dùng thông thường) bắt chước chúng, cuối cùng dẫn đến vụ đánh cắp khoảng 200 triệu đô la chỉ trong vài giờ. Trường hợp này chứng minh rằng trong hoàn cảnh minh bạch của blockchain , một khi lỗ hổng bị khai thác công khai, tác động của nó có thể lan rộng nhanh chóng. Những trường hợp cầu nối xuyên chuỗi này cung cấp một số thông tin chi tiết để hiểu các cuộc tấn công Balancer. Thứ nhất, mặc dù quản lý private key không phải là nguyên nhân gốc rễ của các vấn đề của Balancer, nhưng nó làm nổi bật rủi ro của các điểm kiểm soát tập trung. Một số chức năng quản trị của Balancer (chẳng hạn như nhóm tạm dừng) yêu cầu quyền truy cập đặc quyền, và nếu các quyền này bị lạm dụng hoặc rò rỉ, nó có thể gây ra hậu quả nghiêm trọng. Thứ hai, tầm quan trọng của logic xác minh hợp đồng thông minh là rất quan trọng trong cả hai loại giao thức. Cho dù đó là xác minh chữ ký của cầu nối hay xác minh swap của AMM, bất kỳ lỗ hổng nào cũng có thể bị khai thác. Thứ ba, giá trị của việc giám sát chủ động và phản ứng nhanh là không thể phủ nhận. Nếu Ronin Bridge có hệ thống giám sát tốt hơn, tổn thất có thể đã được giảm đáng kể. 5.4 Những thách thức dai dẳng của Token và ERC20 không chuẩn Cuộc tấn công token giảm phát mà Balancer phải chịu vào năm 2020 không chỉ là sự cố bảo mật lớn đầu tiên của giao thức mà còn đại diện cho một thách thức dai dẳng mà toàn bộ không gian DeFi phải đối diện: làm thế nào để xử lý an toàn token ERC20 không chuẩn. Về mặt lý thuyết, tiêu chuẩn ERC20 xác định cách thức hoạt động của các hợp đồng token, nhưng trên thực tế, nhiều token triển khai nhiều đặc điểm không chuẩn khác nhau có thể không tương thích với các giả định của giao thức DeFi. Bên cạnh token giảm phát, các giao thức DeFi cũng cần xử lý nhiều loại token không chuẩn khác. Token Rebase (chẳng hạn như Ampleforth) định kì điều chỉnh số dư của tất cả người nắm giữ , điều này có thể dẫn đến sự không khớp giữa sổ cái nội bộ của nhóm AMM và số dư thực tế. Token có phí giao dịch (chẳng hạn như một số token quản trị) khấu trừ một tỷ lệ phần trăm nhất định từ lần giao dịch, tương tự như token giảm phát nhưng có cơ chế khác. Token địa chỉ kép (như TUSD) có thể có nhiều địa chỉ hợp đồng trỏ đến cùng tài sản, khiến giao thức xử lý chúng không chính xác như token khác nhau. Hàm transfer hoặc transferFrom của một số token không trả về giá trị boolean hoặc luôn trả về true (bất kể thao tác có thành công hay không), vi phạm tiêu chuẩn ERC20 nhưng vẫn được sử dụng rộng rãi. Uniswap V3 nêu rõ trong tài liệu hướng dẫn rằng nó không hỗ trợ một số loại token không chuẩn, đặc biệt là token có phí chuyển khoản. Hợp đồng bộ định tuyến của giao thức giả định rằng transferFrom sẽ chuyển một số tiền chính xác được chỉ định; nếu giao dịch thực tế ít hơn dự kiến, các tính toán swap tiếp theo sẽ không chính xác. Tương tự, mặc dù token được rebased có thể được sử dụng trong các pool Uniswap V3, nhà cung cấp thanh khoản có thể phải đối mặt với tổn thất không thể khắc phục được vì pool không tự động điều chỉnh để phản ánh các thay đổi số dư. Những trường hợp này làm nổi bật một nguyên tắc bảo mật cơ bản: không đưa ra các giả định chưa được xác minh về các phụ thuộc bên ngoài. Trong hoàn cảnh hợp đồng thông minh, "tin tưởng nhưng xác minh" thậm chí còn chưa đủ—giao thức nên "không tin tưởng và thực thi xác minh". Đối với các tương tác token, điều này có nghĩa là số tiền thực tế được chuyển cần được kiểm tra sau lần transferFrom, thay vì giả định nó bằng số tiền được yêu cầu. Đối với các truy vấn số dư, cần cân nhắc khả năng rebase hoặc các cơ chế thay đổi số dư khác. Đối với các lệnh gọi bên ngoài, cần giả định rằng chúng có khả năng được nhập lại và cần triển khai các biện pháp phòng thủ phù hợp. Balancer V3 đã có những cải tiến đáng kể về mặt này. Bằng cách sử dụng thư viện SafeERC20 của OpenZeppelin, V3 thực hiện các kiểm tra bảo mật bổ sung trên tất cả các tương tác token. Giao thức cũng giới thiệu danh sách trắng token và hệ thống xếp hạng rủi ro, cho phép quản trị kiểm soát các loại token được hỗ trợ. Quan trọng hơn, kiến trúc của V3 hỗ trợ gốc token yield và rebase token thông qua các wrapper ERC4626, giúp xử lý chính xác các hành vi không chuẩn, chuyển đổi chúng thành một giao diện chuẩn mà giao thức có thể xử lý an toàn. 5.5 Kỹ thuật chính xác: Các vectơ tấn công bị đánh giá thấp Sự phổ biến của các cuộc tấn công mất độ chính xác và lỗi làm tròn trong không gian DeFi là đáng lo ngại vì chúng thường không được coi là lỗ hổng bảo mật"thực sự". Các nhà phát triển có thể cho rằng rằng việc mất một vài wei do số tiền cực kỳ nhỏ là chấp nhận được, nhưng kẻ tấn công có thể tích lũy lợi nhuận đáng kể thông qua hàng nghìn hoặc hàng triệu lần lỗ nhỏ. Cuộc tấn công Balancer 2023 là một ví dụ phản bác kinh điển cho suy nghĩ này, trong đó kẻ tấn công đã khai thác một cách có hệ thống các lỗi làm tròn, gây ra thiệt hại hơn 2 triệu đô la. Gốc rễ của các vấn đề về độ chính xác thường nằm ở những hạn chế của chính ngôn ngữ Solidity. Solidity không hỗ trợ số học dấu phẩy động; tất cả các số thập phân phải được biểu diễn dưới dạng số nguyên (bằng cách nhân với lần của 10). Khi thực hiện phép chia, kết quả bị cắt cụt thay vì làm tròn, dẫn đến hành vi làm tròn xuống mặc định. Điều này có thể không đáng kể trong các phép tính một bước đơn giản, nhưng trong các thuật toán nhiều bước phức tạp (chẳng hạn như công thức định giá trong AMM), lỗi có thể tích lũy hoặc được khuếch đại. Một rủi ro cụ thể trong Balancer V2 bắt nguồn từ tính linh hoạt cực độ được hỗ trợ của nó. Giao thức cho phép tạo các nhóm chứa tối đa tám token, token thông báo có thể có các chữ số thập phân khác nhau (từ 0 đến 18 hoặc nhiều hơn). Khi tính toán liên quan đến việc hoán đổi nhiều token, giao thức yêu cầu lần phép chuyển đổi đơn vị, lần phép chuyển đổi có thể gây ra mất độ chính xác. Kẻ tấn công có thể rút giá trị một cách có hệ thống từ nhóm bằng cách tối đa hóa các khoản mất mát này thông qua các tổ hợp token và đường dẫn hoán đổi cụ thể. Việc phòng thủ chống lại các cuộc tấn công độ chính xác đòi hỏi một phương pháp đa lớp. Thứ nhất, tác động của độ chính xác phải được xem xét khi thiết kế các công thức toán học, lựa chọn các thuật toán giảm thiểu các bước tính toán trung gian. Thứ hai, phải triển khai một chiến lược làm tròn nhất quán, đảm bảo rằng hướng làm tròn luôn có lợi cho giao thức, chứ không phải người dùng (hoặc kẻ tấn công). Nguyên tắc "làm tròn theo giao thức trước" của Balancer V3 thể hiện phương pháp này. Thứ ba, đặt ngưỡng số lượng hoạt động tối thiểu để ngăn chặn các điều kiện biên bị kích hoạt bởi các số lượng cực nhỏ. Thứ tư, sử dụng các phép tính trung gian có độ chính xác cao hơn (ví dụ: sử dụng số nguyên 256 bit cho các phép tính, ngay cả khi kết quả cuối cùng chỉ yêu cầu 128 bit), sau đó chỉ làm tròn ở bước cuối cùng. Xác minh hình thức đặc biệt có giá trị trong việc phát hiện các vấn đề về độ chính xác. Thông qua chứng minh toán học, có thể xác minh rằng một số bất biến nhất định của giao thức được duy trì dưới tất cả các đầu vào khả dĩ, bao gồm cả các trường hợp biên cực đoan. Ví dụ, có thể chứng minh rằng tổng giá trị của nhóm (được đo lường theo một chuẩn mực nhất định) sẽ không giảm sau bất kỳ chuỗi swap(ngoại trừ chi phí dự kiến). Nếu bất biến này bị vi phạm, dù chỉ một lượng rất nhỏ, công cụ xác minh chính thức sẽ phát hiện và báo cáo. 3 tháng 11, 2025 - Tác giả X @OutageVictfzev Việc tạo ra điều này không hề dễ dàng, hãy thích và chia sẻ.
