Nguồn gốc: Beosin
Trong những năm gần đây, các mô hình ngôn ngữ lớn như GPT-4, Claude và Gemini đã chứng minh khả năng hiểu mã mạnh mẽ, đọc hiệu quả các ngôn ngữ hợp đồng thông minh như Solidity, Rust và Go, đồng thời xác định các lỗ hổng kinh điển với các đặc điểm mã riêng biệt, chẳng hạn như tấn công tái nhập và tràn số nguyên. Điều này đã khiến ngành công nghiệp xem xét liệu các mô hình lớn có thể được sử dụng để hỗ trợ hoặc thậm chí thay thế kiểm toán hợp đồng thủ công hay không.
Do các mô hình đa năng thiếu hiểu biết đầy đủ về logic việc kinh doanh của các dự án cụ thể, chúng có tỷ lệ dương tính giả cao khi đối diện các giao thức DeFi phức tạp và dễ bỏ sót các lỗ hổng cần tương tác giữa các hợp đồng hoặc mô hình kinh tế để phát hiện. Sau đó, ngành công nghiệp đề xuất bổ sung cơ chế "Kỹ năng" - đưa các cơ sở kiến thức chuyên biệt, quy tắc phát hiện và bối cảnh việc kinh doanh về bảo mật hợp đồng thông minh vào mô hình đa năng, cung cấp cho mô hình các tiêu chí đánh giá rõ ràng hơn trong quá kiểm toán, thay vì chỉ dựa vào khả năng chung để xác định xem có vấn đề gì với mã nguồn hay không.
Ngay cả với những cải tiến về kỹ năng, kiểm toán bằng AI vẫn có phạm vi ứng dụng được xác định rõ ràng. Nó vượt trội trong việc quét các mẫu lỗ hổng đã biết và kiểm tra kiểu mã, nhưng hiện tại vẫn gặp khó khăn trong việc xử lý hiệu quả các lỗ hổng phức tạp đòi hỏi sự hiểu biết sâu sắc về thiết kế giao thức tổng thể, logic tương tác giữa các hợp đồng hoặc các mô hình kinh tế . Những loại vấn đề này vẫn cần đến các chuyên gia kiểm toán giàu kinh nghiệm, và trong các trường hợp liên quan đến logic tính toán phức tạp, cần có xác minh chính thức để cung cấp các biện pháp bảo vệ mạnh mẽ hơn. Trong bối cảnh đó, Beosin đã xây dựng một mô hình kiểm toán ba cấp: Kiểm tra cơ bản bằng AI được nâng cao kỹ năng + kiểm toán chuyên độ sâu của con người + xác minh chính thức. Mỗi thành phần đều có trọng tâm riêng và bổ sung cho nhau.
I. Giới hạn khả năng kiểm toán của các mô hình AI tổng quát: kiểm thử so sánh có kiểm soát và phân tích trường hợp.
Bài viết này chọn hai loại hợp đồng có mức độ phức tạp khác nhau đáng kể từ thư viện dự án đã được kiểm toán thủ công làm trường hợp thử nghiệm: một loại là các hợp đồng đơn giản với logic tương đối độc lập và ranh giới chức năng rõ ràng. Các dự án này thường là những kịch bản mà các công cụ kiểm toán AI có dữ liệu huấn luyện phong phú nhất và về mặt lý thuyết là có lợi thế nhất; loại còn lại là các hợp đồng phức tạp liên quan đến tương tác đa hợp đồng, máy trạng thái phức tạp hoặc phụ thuộc chéo giao thức. Đây cũng là kịch bản rủi ro cao thường được đề cập nhất khi thảo luận về việc liệu AI có thể thay thế kiểm toán thủ công trong ngành hay không.
Trong quá trình so sánh, chúng tôi đã sử dụng cùng một mã nguồn, trước tiên cho phép AI chạy kiểm toán độc lập để tạo ra báo cáo , sau đó đối chiếu từng dòng với báo cáo kiểm toán của con người. Quá trình tạo ra hai báo cáo hoàn toàn độc lập — kiểm toán con người không hề biết kết quả của AI khi tạo báo cáo, do đó tránh được sự ảnh hưởng lẫn nhau. Cuối cùng, chúng tôi sẽ phân tích kết quả từ bốn khía cạnh sau:
Trường hợp A: Hợp đồng Token tiêu chuẩn (BSC-USDT / BEP20USDT.sol)
Đối với loạt thử nghiệm đầu tiên, chúng tôi đã chọn một hợp đồng token BEP-20 tiêu chuẩn được viết bằng Solidity 0.5.16. Logic của nó tương đối độc lập, ranh giới chức năng rõ ràng và không liên quan đến bất kỳ tương tác nào giữa các hợp đồng. Rủi ro bảo mật chính tập trung vào một số mẫu lỗ hổng phổ biến, đã biết. Về mặt lý thuyết, loại hợp đồng này hiện là kịch bản thuận lợi nhất cho kiểm toán bằng AI — có rất nhiều hợp đồng token tiêu chuẩn như vậy trong dữ liệu huấn luyện và đặc điểm lỗ hổng dựa trên quy tắc của chúng khá rõ ràng.
Trí tuệ nhân tạo (AI) đã tạo ra 6 cảnh báo (2 cảnh báo rủi ro cao, 1 cảnh báo rủi ro trung bình và 3 cảnh báo rủi ro thấp/đề xuất), đây nhìn lên một con số đáng kể. Các cảnh báo rủi ro thấp và đề xuất nhìn chung khá chính xác, bao gồm các vấn đề phổ biến về kiểu lập trình như phiên bản Solidity lỗi thời và việc để lộ biến trạng thái không đúng cách, và có giá trị tham khảo nhất định. Tuy nhiên, cả hai cảnh báo "rủi ro cao" của AI đều bị đánh giá sai. AI đánh dấu quyền tạo tiền của chủ sở hữu và quyền hạn tập trung là các lỗ hổng rủi ro cao — trên thực tế, đối với stablecoin tập trung (như USDT), quyền tạo tiền của chủ sở hữu là một tính năng thiết kế được mong đợi, và đánh giá rủi ro nên dựa trên đánh giá toàn diện có tính đến kiểm soát đa chữ ký, cơ chế quản trị quyền hạn và chiến lược nâng cấp hợp đồng. Tính hợp lý của các cấu trúc quyền hạn như vậy về cơ bản phụ thuộc vào mô hình việc kinh doanh của dự án chứ không phải bản thân mã nguồn . AI thiếu bối cảnh này và chỉ có thể đưa ra phán đoán dựa trên việc khớp mẫu.
Trường hợp thử nghiệm này cho thấy AI có thể nhận diện cấu trúc quyền hạn, nhưng không thể đánh giá liệu các quyền hạn đó có hợp lý khi kết hợp với bối cảnh việc kinh doanh hay không. Do đó, nó trực tiếp đánh dấu quyền tạo USDT của chủ sở hữu hợp đồng loại USDT là "lỗ hổng rủi ro cao". Đây là một phán đoán sai điển hình, tách rời khỏi logic việc kinh doanh thực tế. Những cảnh báo sai như vậy có thể ảnh hưởng đến khả năng đánh giá rủi ro thực sự của nhóm dự án.
Trường hợp B: Hợp đồng việc kinh doanh phức tạp (Giao thức IPC / 2025-02-thu hồi)
Bộ kiểm thử thứ hai đã chọn dự án Giao thức IPC từ báo cáo công khai của nền tảng Code4rena (liên kết báo cáo: code4rena.com/reports/2025-02-recall). Dự án này bao gồm một số thành phần cốt lõi phụ thuộc lẫn nhau như Gateway, SubnetActor và mô hình proxy Diamond. Tính bảo mật của nó phụ thuộc rất nhiều vào sự hiểu biết độ sâu về kiến trúc giao thức tổng thể và logic tương tác giữa các thành phần, đại diện cho một kịch bản điển hình cho các cuộc tấn công giá trị cao trong hệ sinh thái DeFi. Dưới đây là kết quả kiểm toán AI:
Đối với các hợp đồng phức tạp, kiểm toán AI đã tạo ra 3 cảnh báo rủi ro cao và 6 cảnh báo rủi ro trung bình, một khối lượng đầu ra đáng kể. Tuy nhiên, một tỷ lệ đáng kể trong đó được kiểm toán đánh giá là cảnh báo sai — AI đã đưa ra đánh giá rủi ro không chính xác đối với các đoạn mã thiếu ngữ cảnh. Trong khi đó, trong số 9 lỗ hổng cấp độ cao được kiểm toán xác nhận, AI chỉ bao phủ hoàn toàn 1 lỗ hổng, 2 lỗ hổng được phát hiện nhưng xếp hạng của chúng bị hạ thấp đáng kể (thực tế là Cao, AI báo cáo Trung bình), và 6 lỗ hổng còn lại hoàn toàn không được phát hiện. Trong số 4 lỗ hổng cấp độ Trung bình, AI chỉ bao phủ 1 lỗ hổng, và 3 lỗ hổng hoàn toàn bị bỏ sót.
Những lỗ hổng này có một đặc điểm chung: tất cả đều dựa trên suy luận toàn diện về các đường dẫn chuyển đổi trạng thái giữa các thành phần của giao thức, thay vì chỉ khớp mẫu của một hàm duy nhất. Lấy H-01 (tấn công phát lại chữ ký) trong báo cáo kiểm toán thủ công làm ví dụ, đường dẫn khai thác yêu cầu hiểu được ý định thiết kế của việc xác thực đa chữ ký, cách kẻ tấn công xây dựng một tập hợp các chữ ký trùng lặp và cách hành vi này vượt qua ngưỡng tỷ trọng. H-06 (tấn công tái nhập hàm leave()) cũng tương tự: lỗ hổng chỉ tồn tại trong trạng thái quan trọng của quá trình khởi tạo mạng con, đòi hỏi sự hiểu biết về các mối phụ thuộc chéo giữa luồng đặt cược, điều kiện kích hoạt khởi tạo và thời gian của các cuộc gọi bên ngoài. Các lỗ hổng logic sâu tương tự không được ghi lại trong danh sách cảnh báo của AI.
Kết quả cho thấy rằng trong kiểm toán các hợp đồng phức tạp, khả năng kiểm toán của AI nằm ở việc nhận dạng mẫu mã cục bộ, trong khi các lỗ hổng ở cấp độ giao thức có thể bắt nguồn từ sự hiểu sai về logic việc kinh doanh tổng thể. Khi các điều kiện kích hoạt lỗ hổng trải rộng trên nhiều hợp đồng, nhiều trạng thái và nhiều cấp độ gọi hàm, khả năng suy luận hiện tại của AI không đủ để bao quát chúng một cách hiệu quả.
Tóm lại, cả hai trường hợp đều chứng minh rằng kiểm toán AI không phải là vô giá trị — nó đóng góp đáng kể vào việc bao phủ các mẫu lỗ hổng đã biết, kiểm tra kiểu mã và khám phá một số quan điểm độc lập . Tuy nhiên, ranh giới giá trị của nó rất rõ ràng: nó có thể đóng vai trò như một bước quét cơ bản, nhưng không thể được sử dụng trực tiếp như một kết luận bảo mật. Đối với các giao thức phức tạp, việc chỉ dựa vào báo cáo AI để đưa ra phán đoán bảo mật không chỉ bỏ sót các lỗ hổng rủi ro cao mà còn tiêu tốn lượng lớn thời gian sàng lọc đội ngũ do lượng lớn các cảnh báo chất lượng thấp. Đây chính là lý do cốt lõi tại sao Beosin đã thiết lập một cơ sở kiến thức Kỹ năng chuyên dụng và giới thiệu cơ chế mô hình kiểm toán ba bước vào quy trình kiểm toán của mình.
II. Cơ sở kiến thức kỹ năng chuyên dụng: Lộ trình kỹ thuật để nâng cao khả năng kiểm tra cơ bản của AI
Để tích hợp kiểm toán AI vào quy trình kiểm toán cơ bản, điều quan trọng là phải giải quyết tỷ lệ dương tính giả và âm tính giả cao khi kiểm toán các giao thức DeFi thực tế. Cho dù đó là kiểm soát truy cập, cơ chế thanh khoản AMM, xác minh thông điệp cầu nối xuyên chuỗi hay logic thanh lý của giao thức cho vay, AI hiện chỉ thực hiện việc đối sánh đơn giản dựa trên các đặc điểm mã ở cấp độ bề mặt. Nó gặp khó khăn trong việc kết hợp các đặc điểm này với các kịch bản việc kinh doanh cụ thể và logic tấn công/phòng thủ để xác định xem một đoạn mã có vấn đề hay không. Chìa khóa để giải quyết vấn đề này là đưa kinh nghiệm nhiều năm tích lũy của các chuyên gia kiểm toán vào quá trình đánh giá của AI một cách có cấu trúc, mang lại cho nó một mức độ hiểu biết nhất định việc kinh doanh.
Tuy nhiên, điều quan trọng cần làm rõ là ngay cả với những cải tiến về kỹ năng, vai trò của AI trong kiểm toán vẫn không thay đổi. Đối với các vấn đề phức tạp liên quan đến tương tác đa hợp đồng, phân tích mô hình kinh tế và các phương pháp tấn công mới, kiểm toán của con người vẫn không thể thay thế . Vai trò của việc cải tiến kỹ năng là nâng cao chất lượng của các lần quét ban đầu lên mức thực sự hữu ích, trong phạm vi khả năng của AI (chẳng hạn như xác định các mẫu lỗ hổng phổ biến và hiểu logic việc kinh doanh ở mức độ hạn chế), cung cấp kết quả ban đầu có giá trị hơn cho kiểm toán của con người, thay vì tạo ra một loạt cảnh báo không hợp lệ cần phải xem xét lại nhiều lần.
2.1 Trích dẫn từ thực tiễn kiểm toán: Cơ chế xây dựng các quy tắc về kỹ năng
Kho kiến thức Kỹ năng của Beosin bắt nguồn từ hơn 4.000 dự án hợp đồng thông minh đã trải qua kiểm toán thủ công. Các chuyên gia kiểm toán đã tổng hợp và tinh chỉnh lượng lớn các quy tắc này, xác minh và sắp xếp chúng từng bước một. Quá trình hình thành mỗi quy tắc tuân theo quy trình hoàn chỉnh từ phát hiện lỗ hổng đến triển khai quy tắc: sau khi phát hiện các vấn đề bảo mật trong các dự án thực tế, kiểm toán sẽ tái tạo đầy đủ đường dẫn tấn công, phân tích sâu nguyên nhân gốc rễ, xác minh hiệu quả của các giải pháp khắc phục và cuối cùng sắp xếp toàn bộ kiến thức tấn công và phòng thủ này thành các mục quy tắc với các điều kiện đánh giá theo ngữ cảnh, tích hợp chúng vào thư viện Kỹ năng để kiểm toán sau này.
Sau đây là trong đó ví dụ về quy tắc từ thư viện Kỹ năng, bao gồm cấu trúc trên bốn khía cạnh: kiểu lỗ hổng, đường dẫn tấn công, nguyên nhân gốc rễ và các khuyến nghị khắc phục :
[Beosin-AMM_Skill-1] Đã thêm tính năng bỏ qua phát hiện thanh khoản thông qua lệnh chuyển khoản
Mô hình lỗ hổng: Hợp đồng xác định xem hoạt động bổ sung thanh khoản có đang diễn ra hay không bằng cách kiểm tra xem số dư WBNB trong Pair có vượt quá lượng dự trữ hay không (balanceOf >= reserve + required). Việc phát hiện này dựa trên giả định rằng WBNB được thêm vào Pair trước token, nhưng hàm addLiquidityETH của Router luôn chuyển token ERC-20 trước rồi mới đến WETH, và thứ tự chuyển trong hàm addLiquidity được xác định bởi tham số order.
Đường tấn công: Kẻ tấn công chỉ cần sử dụng `addLiquidityETH` (token được chuyển trước) hoặc gọi `addLiquidity(Token, WBNB, ...)` để chuyển token vào cặp trước khi chuyển WBNB. Khi cuộc tấn công xảy ra, WBNB chưa được chuyển đến, `balanceOf == reserve`, và hàm phát hiện trả về false, do đó hoàn toàn vượt qua hạn chế "không thêm thanh khoản".
Nguyên nhân cốt lõi là phương pháp phát hiện dựa trên ảnh chụp nhanh số dư dư cặp giao dịch vốn dĩ không thể phân biệt một cách đáng tin cậy giữa các thao tác swap và thêm thanh khoản ở cấp độ thiết kế. Đây là một khiếm khuyết về kiến trúc chứ không phải là lỗi triển khai.
Giải pháp được đề xuất: Thay đổi hệ thống để cấm các địa chỉ không nằm trong danh sách trắng chuyển tiền trực tiếp đến Pair. Tất cả các giao dịch nên được thực hiện thông qua các chức năng tích hợp sẵn trong hợp đồng, từ đó loại bỏ lỗi cơ bản trong việc phát hiện ảnh chụp nhanh số dư ở cấp độ kiến trúc.
Quy tắc này không chỉ đơn thuần là việc dán nhãn một mẫu mã duy nhất, mà là một phân tích có hệ thống về một loại tấn công: các điều kiện kích hoạt được hình thành như thế nào, kẻ tấn công đi theo con đường nào để vượt qua sự phát hiện, cơ chế phát hiện có những lỗ hổng về mặt kiến trúc ở giai đoạn nào và cần phải khắc phục lỗi ở cấp độ nào.
2.2 Phạm vi của cơ sở kiến thức
Beosin đã phát triển một cơ sở dữ liệu lỗ hổng kỹ năng chuyên biệt bao gồm các công nghệ Web3 phổ biến, bao gồm các loại như Solidity, Rust, Motoko, FunC, Go và ZK . Nội dung cốt lõi của nó được giữ tài sản nội bộ và không được công khai. Cấu trúc mục lục như sau:
Các kỹ năng trong mỗi kho lưu trữ chuyên biệt được quản lý riêng biệt theo loại lỗ hổng. Mỗi quy tắc bao gồm một số, điều kiện kích hoạt, tái tạo đường dẫn tấn công, logic phán đoán theo ngữ cảnh và các đề xuất khắc phục. Toàn bộ kho lưu trữ kỹ năng được liên tục cập nhật khi lần hiện các sự kiện tấn công mới và tích lũy các trường hợp kiểm toán , đảm bảo rằng nó luôn được đồng bộ hóa với hoàn cảnh đe dọa thực tế trên Chuỗi .
2.3 So sánh chất lượng kiểm tra ban đầu sau khi can thiệp bằng kỹ năng
Để định lượng tác động thực tế của thư viện Skill lên chất lượng quét cơ bản, chúng tôi đã sử dụng hai trường hợp thử nghiệm trong Chương 2 làm chuẩn, chạy AI tổng quát và AI được tăng cường bằng Skill trên cùng một mã nguồn, và so sánh kết quả từng mục một.
Trường hợp A: Kết quả so sánh các hợp đồng token tiêu chuẩn (BEP-20)
Trường hợp B: Kết quả so sánh các hợp đồng việc kinh doanh phức tạp (Giao thức IPC)
Kết quả so sánh cho thấy việc đưa Skill vào đã cải thiện đáng kể chất lượng phát hiện cho cả hai loại hợp đồng. Trong các kịch bản hợp đồng token tiêu chuẩn, việc bổ sung khả năng đánh giá ngữ cảnh việc kinh doanh đã loại bỏ hoàn toàn các trường hợp dương tính giả có rủi ro cao. Trong các kịch bản hợp đồng việc kinh doanh phức tạp, phạm vi bao phủ các mẫu lỗ hổng đã biết tăng từ 11% lên 44%, tỷ lệ dương tính giả giảm từ khoảng 55% xuống khoảng 30%, và độ chính xác của việc đánh giá mức độ nghiêm trọng cũng được cải thiện đáng kể. Báo cáo này có thể đóng vai trò như một bước kiểm tra cơ bản, giúp các nhóm dự án xác định trước các lỗi tiềm ẩn trong mã của họ. Mặc dù những vấn đề này sẽ không trực tiếp gây ra tổn thất tài chính trong ngắn hạn, nhưng chúng vẫn có những tác động tích cực quan trọng đối với việc bảo trì và nâng cấp dự án sau này.
Tuy nhiên, dữ liệu cũng cho thấy rõ những hạn chế vốn có của khả năng AI: ngay cả với những cải tiến về kỹ năng, phạm vi bao phủ các lỗ hổng cấp cao trong các hợp đồng phức tạp chỉ đạt 44% . Các lỗ hổng nghiêm trọng đòi hỏi suy luận đường dẫn trạng thái xuyên hợp đồng, phân tích mô hình khích lệ kinh tế hoặc các điều kiện thời gian cụ thể để kích hoạt vẫn vượt xa khả năng quét cơ bản của AI. Đây là lý do cơ bản tại sao chúng tôi vẫn duy trì quy trình kiểm toán thủ công hoàn chỉnh trong quy trình kiểm toán ngay cả sau khi đã áp dụng các cải tiến về kỹ năng.
2.4 Sách trắng) làm dữ liệu đầu vào kiểm toán: Xác minh tính nhất quán giữa việc triển khai mã và mục đích thiết kế
Bên cạnh cơ sở dữ liệu chữ ký lỗ hổng bảo mật, chúng tôi đã bổ sung một khả năng quan trọng vào quy trình kiểm toán của mình: sử dụng Sách trắng của dự án làm dữ liệu đầu vào bổ sung, cho phép trí tuệ nhân tạo (AI) xác minh tính nhất quán giữa việc triển khai mã và thiết kế Sách trắng .
Cụ thể, trước khi bắt đầu kiểm toán mã nguồn, AI sẽ phân tích một cách có Sách trắng của dự án, các thông số kỹ thuật và tài liệu yêu cầu, rút các mô hình nhân vật và quyền hạn, các quy trình việc kinh doanh cốt lõi, định nghĩa ranh giới tin cậy và các ràng buộc hành vi dự kiến để hình thành một bản tóm tắt bối cảnh dự án có cấu trúc. Sau đó, trong suốt quá trình kiểm toán mã nguồn, AI liên tục đối chiếu bối cảnh này để so sánh. Cơ chế này đã mang lại hai kết quả có giá trị trong thực tiễn:
Thứ nhất, đối với các cấu trúc phân quyền trong mã nguồn có vẻ tiềm ẩn rủi ro, nếu Sách trắng đã giải thích rõ ràng mục đích thiết kế và các ràng buộc của chúng, AI sẽ điều chỉnh đánh giá của mình cho phù hợp, từ đó giảm thiểu hiệu quả các cảnh báo sai như vậy.
Thứ hai, nếu có sự khác biệt đáng kể giữa việc triển khai mã và những cam kết trong Sách trắng— ví dụ, nếu cơ chế bảo vệ chống trượt được nêu trong tài liệu không được triển khai trong mã, hoặc nếu các ràng buộc về khung thời gian của quy trình quản trị không được thực hiện chính xác — AI sẽ đưa ra cảnh báo. Những sự không nhất quán giữa mã và tài liệu này rất dễ bị bỏ qua trong quá trình quét mã thông thường, nhưng chúng thường là những lỗ hổng bảo mật tiềm ẩn. Điều này cũng giúp các nhóm dự án tránh được những tình huống mà dự án thể hiện hành vi không nhất quán với kỳ vọng của họ sau khi ra mắt.
III. Mô hình kiểm toán ba lớp: Cùng nhau xây dựng một sự đảm bảo an ninh toàn diện cho hợp đồng thông minh
Một khi hợp đồng thông minh được triển khai trên Chuỗi , hậu quả của bất kỳ lỗ hổng nào thường là không thể khắc phục được. Beosin sử dụng kiểm toán thủ công độ sâu kết hợp với xác minh chính thức làm nền tảng cho việc kiểm toán hợp đồng, tập trung vào việc xác định và báo cáo các vấn đề có khả năng dẫn đến tổn thất tài chính hoặc hoạt động logic bất thường. Đồng thời, chúng tôi đã giới thiệu các kiểm tra cơ bản AI nâng cao dựa trên cơ sở kiến thức Kỹ năng chuyên dụng để giúp khách hàng phát hiện các vấn đề về mã hiện chỉ là lỗi nhưng chưa gây ra thiệt hại thực sự. Dựa trên nền tảng này, Beosin đã xây dựng mô hình kiểm toán ba cấp: kiểm toán thủ công độ sâu , xác minh chính thức và kiểm tra cơ bản AI nâng cao. Thông qua sự hợp tác nhiều lớp của ba yếu tố này, một hệ thống bảo mật toàn diện hơn được hình thành .
3.1 Kiểm toán thủ công chuyên độ sâu và xác minh chính thức: những trụ cột cốt lõi của đảm bảo an ninh
Ưu điểm cốt lõi của kiểm toán thủ công nằm ở sự hiểu biết độ sâu về thiết kế tổng thể của giao thức và khả năng phân tích chủ động rủi ro tiềm tàng từ góc nhìn của kẻ tấn công . Các chuyên gia kiểm toán giàu kinh nghiệm chịu trách nhiệm thực hiện kiểm toán toàn diện ở cấp độ giao thức của các dự án, bao gồm xác minh logic tương tác giữa các hợp đồng, phân tích bề mặt tấn công của bảo mật quỹ, phân tích logic của giao thức trong điều kiện thị trường khắc nghiệt, và xác định cũng như đánh giá các phương pháp tấn công mới. Sự hiểu biết ở cấp độ giao thức về tấn công và phòng thủ này phụ thuộc rất nhiều vào sự tích lũy lâu dài và kinh nghiệm thực tiễn trong hệ sinh thái Web3, điều mà hiện tại không thể thực hiện độc lập ở cấp độ công cụ.
Dựa trên nền tảng này, Beosin sử dụng một Chuỗi nội bộ để chuyển đổi các đánh giá từ kiểm toán thủ công thành các đảm bảo toán học có thể định lượng được. Đối với logic việc kinh doanh cốt lõi được xác nhận bởi các chuyên gia kiểm toán , chẳng hạn như các đường dẫn quan trọng có rủi ro cao nhất như dòng tiền và tính toán giá cả, Beosin tích hợp độ sâu khả năng tạo đặc tả hình thức dựa trên LLM vào Chuỗi xác minh nội bộ của mình, xây dựng một hệ thống khép kín gồm "tạo đặc tả AI → xác minh toàn diện hình thức → tinh chỉnh dựa trên ví dụ phản chứng". Chuỗi này trước tiên sử dụng kho dữ liệu kiểm toán tích lũy của Beosin làm cơ sở kiến thức để mô hình hóa bề mặt tấn công của các đường dẫn rủi ro cao được xác nhận thủ công, hỗ trợ tạo ra một tập hợp ứng viên ban đầu gồm các bất biến hình thức và đặc tả thuộc tính bảo mật. Sau đó, công cụ xác minh hình thức tự động sẽ xác minh toàn diện không gian chuyển đổi trạng thái hoàn chỉnh của hợp đồng. Khi công cụ xác minh phát hiện ra một ví dụ phản chứng, hệ thống sẽ tự động phân biệt giữa hai kịch bản: nếu ví dụ phản chứng xuất phát từ sự sai lệch giữa định nghĩa đặc tả và ngữ nghĩa việc kinh doanh, ngữ cảnh của ví dụ phản chứng sẽ được đưa trở lại mô-đun AI để tinh chỉnh đặc tả, thúc đẩy vòng lặp tiếp theo; Nếu ví dụ phản chứng tương ứng với một đường dẫn có thể khai thác thực sự trong mã hợp đồng, nó sẽ được xuất trực tiếp dưới dạng bằng chứng về lỗ hổng, kèm theo bản sao chép hoàn chỉnh đường dẫn tấn công, để các chuyên gia kiểm toán xác nhận và tiến hành khắc phục. Hai đường dẫn này cùng nhau thúc đẩy sự hội tụ vòng kín cho đến khi được xác nhận về mặt toán học rằng thuộc tính mục tiêu đúng với tất cả các đầu vào có thể. Đường dẫn quan trọng được xác minh bởi cơ chế vòng kín này tạo thành biện pháp phòng thủ mang tính xác định nhất trong toàn bộ hệ thống bảo mật hợp đồng, thu hẹp bề mặt tấn công xuống phạm vi cực kỳ hẹp.
3.2 Kiểm tra cơ bản AI nâng cao: Dịch vụ cảnh báo rủi ro liên tục dành cho nhà phát triển
Trong khi đó, Beosin cũng cung cấp dịch vụ kiểm tra cơ bản nâng cao bằng AI dựa trên cơ sở kiến thức Skill như một dịch vụ độc lập . Không giống như kiểm toán độ sâu do con người thực hiện tập trung vào việc phát hiện các lỗ hổng có rủi ro cao, dịch vụ này được định vị giống như một báo cáo về tình trạng mã nguồn dành cho đội ngũ phát triển. Quét cơ bản bằng AI cung cấp phạm vi bao phủ đầy đủ mã hợp đồng , xác định một cách có hệ thống các vấn đề tiềm ẩn mà hiện tại sẽ không gây ra tổn thất kinh tế trực tiếp nhưng cần sự chú ý của các nhà phát triển trong quá trình bảo trì và lặp lại dự án tiếp theo. Ví dụ bao gồm: việc sử dụng các thư viện phụ thuộc lỗi thời, thiếu khai báo sự kiện quan trọng, các phương pháp phơi bày biến trạng thái không theo chuẩn mực tốt nhất và các mẫu sử dụng gas có thể được tối ưu hóa hơn nữa. Những vấn đề này thường không bị kẻ tấn công khai thác trực tiếp theo logic việc kinh doanh hiện tại, nhưng khi chức năng giao thức mở rộng, mã được tái cấu trúc hoặc các phụ thuộc bên ngoài được cập nhật, một số vấn đề trong đó có thể dần dần phát triển thành các lỗ hổng bảo mật thực sự. Ba lớp này, mỗi lớp có trọng tâm riêng và tiến triển từng bước, cùng nhau tạo nên một hệ thống bảo vệ an ninh hoàn chỉnh cho các dự án Web3.
