AI tăng cường bảo mật hợp đồng thông minh như thế nào? Chia sẻ thực tế từ mô hình tổng quát đến mô hình ba cuộc kiểm toán

Nguồn gốc: Beosin

Trong những năm gần đây, GPT-4, Claude, Gemini Những mô hình ngôn ngữ lớn như vậy đã có khả năng hiểu mã mạnh mẽ, có thể đọc tốt hơn các ngôn ngữ hợp đồng thông minh như Solidity, Rust và Go, đồng thời cũng có thể xác định các lỗ hổng cổ điển với các đặc điểm mã rõ ràng như tấn công reentrancy và tràn số nguyên. Điều này khiến ngành bắt đầu suy nghĩ: Liệu các mô hình lớn có thể được sử dụng để hỗ trợ hoặc thậm chí thay thế việc kiểm tra hợp đồng thủ công không?

Do mô hình chung chưa hiểu đầy đủ về logic kinh doanh của các dự án cụ thể nên khi đối mặt với các giao thức DeFi phức tạp, tỷ lệ dương tính giả cao và rất dễ bỏ sót các lỗ hổng yêu cầu phát hiện ra các mô hình kinh tế hoặc tương tác chéo hợp đồng. Sau đó, ngành đề xuất kế hoạch bổ sung cơ chế "Kỹ năng" - trên cơ sở mô hình lớn chung, đưa vào cơ sở kiến ​​thức đặc biệt, quy tắc phát hiện và bối cảnh kinh doanh để bảo mật hợp đồng thông minh, để mô hình có cơ sở phán đoán rõ ràng hơn trong quá trình kiểm tra, thay vì chỉ dựa vào khả năng chung để đánh giá xem có vấn đề với mã hay không.

Ngay cả khi bổ sung tính năng nâng cao Kỹ năng, kiểm toán AI vẫn có phạm vi ứng dụng rõ ràng. Nó có khả năng quét các mẫu lỗ hổng đã biết và kiểm tra thông số mã, nhưng vẫn khó 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 mô hình kinh tế. Những vấn đề như vậy vẫn đòi hỏi các chuyên gia kiểm toán có kinh nghiệm phải chịu trách nhiệm và trong các tình huống liên quan đến logic tính toán phức tạp, cần phải đưa ra xác minh chính thức để mang lại sự đảm bảo mạnh mẽ hơn. Trong bối cảnh đó, Beosin đã xây dựng mô hình ba cuộc kiểm tra gồm kiểm tra cơ bản AI nâng cao kỹ năng + kiểm tra chuyên sâu thủ công + xác minh chính thức. Mỗi người trong số ba người đều có trọng tâm riêng và bổ sung cho nhau.

1. Ranh giới khả năng kiểm tra của các mô hình AI nói chung: thử nghiệm 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ó sự khác biệt lớn về độ phức tạp từ thư viện dự án đã hoàn thành kiểm tra thủ công làm trường hợp thử nghiệm: một loại là 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. Loại dự án này thường có dữ liệu đào tạo của công cụ AI Audit là phong phú nhất và có lợi nhất về mặt lý thuyế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 nhiều hợp đồng, máy trạng thái phức tạp hoặc phụ thuộc nhiều giao thức. Đây cũng là kịch bản rủi ro cao được nhắc đến nhiều nhất khi ngành thảo luận “liệu ​​AI có thể thay thế kiểm toán thủ công hay không”.

Khi so sánh, chúng tôi đã sử dụng chính xác cùng một cơ sở mã, trước tiên hãy để AI chạy kiểm tra một cách độc lập, sau đó tạo báo cáo rồi căn chỉnh từng báo cáo với báo cáo kiểm tra thủ công. Quá trình tạo ra hai báo cáo hoàn toàn không can thiệp lẫn nhau - kiểm toán viên con người hoàn toàn không biết kết quả của AI khi phát hành báo cáo, tránh ả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 mã thông báo tiêu chuẩn (BSC-USDT / BEP20USDT.sol)

Đối với đợt thử nghiệm đầu tiên, chúng tôi đã chọn 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 của nó rõ ràng và không liên quan đến bất kỳ tương tác hợp đồng chéo nào. Các rủi ro bảo mật chính tập trung vào một số chế độ dễ bị tổn thương phổ biến và đã biết. Loại hợp đồng này hiện là kịch bản chiếm ưu thế nhất về mặt lý thuyết đối với việc kiểm tra AI - có rất nhiều hợp đồng mã thông báo tiêu chuẩn như vậy trong dữ liệu đào tạo và các đặc điểm dễ bị tổn thương thường xuyên cũng tương đối rõ ràng.

AI đưa ra tổng cộng 6 cảnh báo (2 rủi ro cao, 1 rủi ro trung bình, 3 rủi ro/đề xuất thấp), khá ấn tượng về số lượng. Các mục được đề xuất và có rủi ro thấp về cơ bản là chính xác, bao gồm các vấn đề về đặc tả mã phổ biến như phiên bản Solidity lỗi thời và phương pháp hiển thị biến trạng thái và có giá trị tham chiếu nhất định. Tuy nhiên, cả kết quả đầu ra “rủi ro cao” của AI đều tạo thành những đánh giá sai lầm. AI đánh dấu quyền khai thác của chủ sở hữu và quyền tập trung là các lỗ hổng có rủi ro cao - trên thực tế, đối với stablecoin tập trung (loại USDT), quyền khai thác của chủ sở hữu là một phần của thiết kế dự kiến ​​và việc đánh giá rủi ro phải được kết hợp với kiểm soát đa chữ ký, cơ chế quản lý quyền và chiến lược nâng cấp hợp đồng để đưa ra đánh giá toàn diện. Tính hợp lý của loại cấu trúc quyền này về cơ bản phụ thuộc vào mô hình kinh doanh của dự án hơn là bản thân mã. 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ể xác định cấu trúc quyền, nhưng không thể đánh giá liệu các quyền đó có hợp lý hay không dựa trên bối cảnh kinh doanh, vì vậy chủ sở hữu hợp đồng USDT đã thay đổi. Quyền đúc tiền được đánh dấu trực tiếp là "lỗ hổng có nguy cơ cao". Đây là một đánh giá sai điển hình khác với logic kinh doanh thực tế - kiểu báo cáo sai này có thể cản trở việc đánh giá rủi ro thực sự của bên dự án.

Trường hợp B · Hợp đồng kinh doanh phức tạp (Giao thức IPC / 2025-02-recall)

Bộ thử nghiệm thứ hai đã chọn dự án Giao thức IPC trong báo cáo công khai nền tảng Code4rena (liên kết báo cáo: code4rena.com/reports/2025-02-recall). Dự án chứa nhiều thành phần cốt lõi phụ thuộc lẫn nhau như chế độ proxy Gateway, SubnetActor và Diamond. Bảo mật phụ thuộc nhiều vào sự hiểu biết sâu sắc 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. Đây là kịch bản điển hình cho các cuộc tấn công có giá trị cao trong hệ sinh thái DeFi. Sau đâ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 đã đưa ra tổng cộng 3 cảnh báo rủi ro cao và 6 cảnh báo rủi ro trung bình, không hề thua kém về mặt hiệu quả khối lượng đầu ra. Nhưng một tỷ lệ đáng kể bị kiểm toán viên đánh giá là dương tính giả—AI đưa ra đánh giá rủi ro không chính xác về các đoạn mã thiếu ngữ cảnh. Đồng thời, trong số 9 lỗ hổng Cấp cao được kiểm toán viên xác nhận, AI chỉ che phủ hoàn toàn 1, 2 lỗ hổng khác được phát hiện nhưng bị đánh giá thấp hơn đáng kể (thực tế là Cao, AI báo cáo là Trung bình), còn 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, 1 lỗ hổng đã được AI che phủ và 3 lỗ hổng hoàn toàn bị thiếu.

Đặc điểm chung của các lỗ hổng này là chúng đều dựa vào lý do hoàn chỉnh về đường dẫn chuyển đổi trạng thái nhiều thành phần của giao thức, thay vì khớp mẫu trên một chức năng duy nhất. Lấy H-01 (chữ ký lại) trong báo cáo kiểm tra thủ công làm ví dụ. Cách khai thác lỗ hổng bảo mật đòi hỏi phải hiểu mục đích thiết kế của xác minh đa chữ ký, cách kẻ tấn công xây dựng một bộ chữ ký trùng lặp và cách hành vi này vượt qua ngưỡng trọng lượng. Điều tương tự cũng đúng với cuộc tấn công vào lại chức năng H-06 (leave()): lỗ hổng chỉ tồn tại ở trạng thái quan trọng của bootstrap mạng con và cần phải hiểu sự phụ thuộc chéo giữa chuyển giao cam kết, điều kiện kích hoạt bootstrap và thời gian gọi bên ngoài. Các lỗ hổng logic sâu tương tự không được ghi vào danh sách cảnh báo AI.

Kết quả này được thể hiện trong quá trình kiểm tra hợp đồng phức tạp: AI Khả năng kiểm tra nằm ở khả năng nhận dạng mẫu của mã cục bộ, trong khi các lỗ hổng ở cấp độ giao thức có thể dẫn đến sai lệch trong hiểu biết về hoạt động kinh doanh tổng thể logic. Khi các điều kiện kích hoạt của 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 độ cuộc gọi, thì khả năng suy luận hiện tại của AI không thể giải quyết lỗ hổng đó một cách hiệu quả.

Dựa trên hai trường hợp, kiểm tra AI không phải là không có giá trị - Nó đóng góp đáng kể trong việc bao quát các mẫu lỗ hổng đã biết, kiểm tra đặc tả mã và phát hiện một số quan điểm độc lập. Nhưng ranh giới giá trị của nó rất rõ ràng: nó có thể được sử dụng như một bản quét cơ bản, nhưng nó không thể được sử dụng trực tiếp như một kết luận an toàn. Đố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 đánh giá bảo mật sẽ không chỉ bỏ sót các lỗ hổng có mức độ rủi ro cao hơn mà còn mất nhiều thời gian sàng lọc cho nhóm do có một số lượng lớn cảnh báo chất lượng thấp. Đây là lý do cốt lõi tại sao Beosin thiết lập cơ sở kiến ​​thức Kỹ năng độc quyền và đưa cơ chế ba chế độ kiểm tra vào quy trình kiểm tra.

2. Cơ sở kiến ​​thức kỹ năng độc quyền: Lộ trình kỹ thuật để cải thiện việc kiểm tra đường cơ sở của AI

Để kết hợp kiểm tra AI vào quy trình kiểm tra kiểm tra cơ sở, cần phải giải quyết vấn đề về tỷ lệ dương tính giả và âm tính giả cao khi kiểm tra các giao thức DeFi thực. Cho dù đó là quản lý quyền, cơ chế thanh khoản AMM, xác minh thông báo cầu nối chuỗi hay logic thanh lý của thỏa thuận cho vay, AI hiện chỉ có thể thực hiện khớp đơn giản dựa trên đặc điểm bề mặt của mã. Rất khó để kết hợp các kịch bản kinh doanh cụ thể với logic tấn công và phòng thủ để xác định liệu có vấn đề với một đoạn mã hay không. Cốt lõi của việc giải quyết vấn đề này là đưa kinh nghiệm được các chuyên gia kiểm toán tích lũy trong nhiều năm vào quy trình phán đoán AI một cách có cấu trúc để nó có thể có những khả năng hiểu biết kinh doanh nhất định.

Nhưng điều cần phải rõ ràng là ngay cả khi các cải tiến Kỹ năng được đưa ra, vị trí của AI trong kiểm toán sẽ không thay đổi. Đối với các vấn đề phức tạp liên quan đến tương tác nhiều hợp đồng, phân tích mô hình kinh tế và các phương thức tấn công mới, việc kiểm tra thủ công vẫn không thể thay thế. Vai trò của Skill là cải thiện chất lượng quét sơ bộ lên mức thực sự hữu ích trong phạm vi mà AI có thể xử lý (chẳng hạn như xác định các mẫu lỗ hổng phổ biến và hiểu biết hạn chế về logic kinh doanh), cung cấp kết quả sơ bộ có giá trị hơn cho kiểm tra thủ công, thay vì tạo ra một loạt cảnh báo không hợp lệ cần được sàng lọc nhiều lần.

2.1 Trích từ thực tiễn kiểm toán: Cơ chế xây dựng quy tắc Kỹ năng

Nền tảng kiến ​​thức Skill của Beosin đến từ hơn 4.000 dự án hợp đồng thông minh đã hoàn thành kiểm tra thủ công. Nó được các chuyên gia kiểm toán tóm tắt và tóm tắt, tinh chỉnh và xác minh từng mục một. Việc hình thành từng quy tắc sẽ hoàn tất toàn bộ quá trình từ phát hiện lỗ hổng đến thực hiện quy tắc: sau khi kiểm toán viên phát hiện ra vấn đề bảo mật trong một dự án thực, anh ta sẽ khôi phục hoàn toàn đường tấn công, tiến hành phân tích chuyên sâu về nguyên nhân gốc rễ, xác minh xem kế hoạch sửa chữa có hiệu quả hay không và cuối cùng sắp xếp toàn bộ tập hợp kiến ​​thức tấn công và phòng thủ này vào các mục quy tắc với các điều kiện phán đoán theo ngữ cảnh và kết hợp chúng vào thư viện Kỹ năng cho các lệnh kiểm tra tiếp theo.

Sau đây là mẫu quy tắc trong thư viện Kỹ năng, bao gồm cấu trúc theo bốn chiều: chế độ lỗ hổng, đường dẫn tấn công, nguyên nhân cốt lõi và đề xuất sửa chữa:

[Beosin-AMM_Skill-1] Thêm tính năng phát hiện thanh khoản để bỏ qua theo trình tự chuyển

Chế độ dễ bị tổn thương:Hợp đồng kiểm tra xem số dư WBNB trong Cặp có vượt quá mức dự trữ hay không (balanceOf >= dự trữ + bắt buộc) để xác định xem đó có phải là thanh khoản hay không thao tác bổ sung. Việc phát hiện này dựa trên giả định rằng WBNB chuyển đến Cặp trước mã thông báo, nhưng chức năng addLiquidityETH của Bộ định tuyến được cố định để chuyển mã thông báo ERC-20 trước rồi đến WETH và thứ tự truyền của hàm addLiquidity được xác định theo thứ tự của các tham số.

Đườ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, ...) để thực hiện chuyển Token sang cặp trước WBNB. Tại thời điểm phát hiện, WBNB vẫn chưa đến, BalanceOf == dự trữ và chức năng phát hiện trả về sai, do đó bỏ qua hoàn toàn hạn chế "không thêm thanh khoản".

Nguyên nhân cơ bản: Phương pháp phát hiện dựa trên ảnh chụp nhanh số dư Cặp đôi vốn không thể phân biệt một cách đáng tin cậy các hoạt động hoán đổi và bổ sung thanh khoản ở cấp thiết kế. Đây là một lỗ hổng kiến ​​trúc chứ không phải là lỗi triển khai.

Đề xuất sửa chữa: Thay vào đó, các địa chỉ không nằm trong danh sách trắng bị cấm chuyển tiền trực tiếp đến Pair. Tất cả các giao dịch được hoàn thành thông qua các chức năng tích hợp của hợp đồng, loại bỏ lỗ hổng cơ bản trong việc phát hiện ảnh chụp nhanh số dư từ cấp độ kiến ​​trúc.

Quy tắc này không phải là việc gắn nhãn đơn giản cho một mẫu mã đơn lẻ mà là sự kết hợp có hệ thống của một loại tấn công: cách cấu thành các điều kiện kích hoạt, đường dẫn mà kẻ tấn công thực hiện để vượt qua sự phát hiện, trong đó cơ chế phát hiện có lỗi kiến ​​trúc và cần can thiệp ở cấp độ nào để sửa chữa.

2.2 Phạm vi bao phủ của cơ sở tri thức

Beosin hiện đã hình thành một thư viện lỗ hổng kỹ năng đặc biệt bao gồm nền tảng công nghệ Web3 chính thống, bao gồm Solidity, Rust, Motoko, FunC, Go và ZK và các danh mục chính khác. Nội dung cốt lõi của nó không được tiết lộ cho công chúng dưới dạng tài sản cốt lõi nội bộ và cấu trúc thư mục như sau:

Các kỹ năng trong mỗi thư viện đặc biệt được quản lý riêng biệt theo loại lỗ hổng. Mỗi quy tắc bao gồm số lượng, điều kiện kích hoạt, khôi phục đường dẫn tấn công, logic phán đoán ngữ cảnh và đề xuất sửa chữa. Toàn bộ thư viện Kỹ năng sẽ tiếp tục lặp lại với sự xuất hiện của từng sự kiện tấn công mới và tích lũy các phiên bản kiểm toán, đảm bảo rằng nó luôn được đồng bộ hóa với môi trường mối đe dọa thực sự trên chuỗi.

2.3 So sánh chất lượng kiểm tra cơ bản sau khi can thiệp Kỹ năng

Để định lượng tác động thực tế của thư viện Kỹ năng đến chất lượng của các lần 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 điểm chuẩn, chạy AI chung và AI nâng cao Kỹ năng trên cùng một cơ sở mã và so sánh kết quả theo từng mục.

Trường hợp A · Kết quả so sánh hợp đồng mã thông báo tiêu chuẩn (BEP-20):

Trường hợp B · Hợp đồng kinh doanh phức tạp (Giao thức IPC) Kết quả so sánh:

Kết quả so sánh cho thấy sau khi giới thiệu Skill, chất lượng phát hiện của cả hai loại hợp đồng đã được cải thiện đáng kể. Trong kịch bản hợp đồng mã thông báo tiêu chuẩn, do việc bổ sung khả năng phán đoán bối cảnh kinh doanh, các thông tin sai lệch có rủi ro cao đã được loại bỏ hoàn toàn; trong kịch bản hợp đồng kinh doanh phức tạp, mức độ bao phủ của 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 còn khoảng 30% và độ chính xác của phán đoán mức độ nghiêm trọng cũng được cải thiện đáng kể. Báo cáo này có thể được sử dụng làm kiểm tra cơ bản để giúp nhóm dự án hiểu trước các lỗi trong mã. 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 thời điểm hiện tại nhưng chúng vẫn sẽ có tác động tích cực quan trọng đến việc bảo trì và nâng cấp dự án sau này.

Tuy nhiên, dữ liệu cũng bộc lộ rõ ​​ràng ranh giới cố hữu của khả năng AI: Ngay cả sau khi bổ sung tính năng nâng cao Kỹ năng, mức độ 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 sâu đòi hỏi lý luận về lộ trình trạng thái theo hợp đồng chéo, phân tích mô hình khuyến khích 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 đường cơ sở của AI. Đây là lý do cơ bản tại sao chúng tôi vẫn giữ lại liên kết kiểm tra thủ công hoàn chỉnh trong quy trình kiểm tra sau khi giới thiệu các cải tiến Kỹ năng.

2.4 Sách trắng làm đầu vào kiểm tra: Xác minh tính nhất quán giữa việc triển khai mã và mục đích thiết kế

Ngoài thư viện chữ ký về lỗ hổng bảo mật, chúng tôi cũng đã bổ sung một khả năng quan trọng cho quy trình kiểm tra: sử dụng sách trắng của dự án làm đầu vào bổ sung, cho phép AI xác minh tính nhất quán giữa triển khai mã và thiết kế sách trắng.

Cụ thể, trước khi quá trình kiểm tra mã bắt đầu, AI sẽ phân tích một cách có hệ thống sách trắng, thông số kỹ thuật và tài liệu yêu cầu của dự án, trích xuất mô hình cấp phép vai trò, quy trình 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 ​​để tạo thành một bản tóm tắt bối cảnh dự án có cấu trúc. Sau này, trong suốt quá trình kiểm tra mã, AI sẽ tiếp tục tham chiếu chéo với bối cảnh này. Cơ chế này đã mang lại hai loại kết quả có giá trị trong sử dụng thực tế:

Thứ nhất, đối với các cấu trúc cấp phép có vẻ rủi ro trong mã, nếu mục đích thiết kế và các ràng buộc đã được nêu rõ ràng trong sách trắng, AI sẽ điều chỉnh phán đoán của mình cho phù hợp, từ đó giảm thiểu các kết quả dương tính giả đó một cách hiệu quả.

Thứ hai, nếu có sai lệch đáng kể giữa việc triển khai mã và lời hứa trong sách trắng, chẳng hạn như cơ chế chống trượt được nêu trong tài liệu không được triển khai trong mã hoặc các ràng buộc về khoảng thời gian của quy trình quản trị không được thực thi chính xác, AI sẽ đưa ra cảnh báo tương ứng. Loại mâu thuẫn này giữa mã và tài liệu dễ bị bỏ qua trong quá trình quét mã thông thường nhưng nó thường tiềm ẩn những rủi ro bảo mật. Nó cũng giúp nhóm dự án tránh được những hành vi không phù hợp với mong đợi sau khi dự án thực sự được triển khai.

3. Chế độ kiểm tra ba lần: hợp tác xây dựng sự đảm bảo hoàn chỉnh về bảo mật hợp đồng thông minh

Sau khi hợp đồng thông minh được triển khai trên chuỗi, cái giá phải trả cho 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 chuyên sâu thủ công + xác minh chính thức làm cơ sở cho kiểm toán hợp đồng, tập trung vào việc phát hiện và báo cáo các vấn đề có thể dẫn đến mất tiền hoặc hoạt động logic bất thường. Đồng thời, chúng tôi đã giới thiệu tính năng kiểm tra cơ bản AI nâng cao dựa trên cơ sở kiến ​​thức Kỹ năng độc quyền để giúp khách hàng phát hiện các vấn đề về mã trước đó mà hiện chỉ là lỗi và chưa gây ra tác hại thực sự. Trên cơ sở đó, Beosin đã xây dựng mô hình kiểm tra ba bước bao gồm kiểm tra chuyên sâu thủ công + xác minh chính thức + kiểm tra cơ sở AI nâng cao. Thông qua sự hợp tác nhiều lớp giữa ba bên, một hệ thống đảm bảo an ninh toàn diện hơn đã được hình thành.

3.1 Kiểm tra chuyên sâu thủ công và xác minh chính thức: 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 tra thủ công nằm ở sự hiểu biết sâu sắc về thiết kế tổng thể của giao thức và khả năng phân tích chủ động các rủi ro tiềm ẩn từ quan điểm của kẻ tấn công. Các chuyên gia kiểm toán có kinh nghiệm chịu trách nhiệm thực hiện kiểm toán cấp giao thức toàn diện cho 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 về bảo mật quỹ, phân tích logic giao thức trong điều kiện thị trường khắc nghiệt cũng như xác định và phán đoán các phương thức tấn công mới. Sự hiểu biết về tấn công và phòng thủ ở cấp độ giao thức 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 tế của hệ sinh thái Web3 và nó không thể được hoàn thành một cách độc lập ở cấp độ công cụ.

Trên cơ sở này, Beosin sử dụng chuỗi công cụ nội bộ để chuyển đổi kết luận đánh giá của quá trình kiểm tra thủ công thành đảm bảo toán học có thể định lượng. Đối với logic kinh doanh cốt lõi đã được các chuyên gia kiểm toán xác nhận, chẳng hạn như: dòng vốn, tính toán giá và các đường dẫn quan trọng khác có rủi ro cao nhất, Beosin đã tích hợp sâu khả năng tạo thông số kỹ thuật chính thức do LLM điều khiển vào chuỗi công cụ xác minh nội bộ và xây dựng một công cụ vòng kín gồm "tạo thông số kỹ thuật AI → xác minh toàn diện chính thức → sàng lọc dựa trên phản ví dụ". Chuỗi công cụ trước tiên sử dụng kho dữ liệu kiểm tra được Beosin tích lũy 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 có rủi ro cao được xác nhận thủ công và hỗ trợ tạo ra tập ứng cử viên ban đầu gồm các thông số kỹ thuật thuộc tính bảo mật và bất biến chính thức; sau đó, công cụ xác minh chính thức tự động tiến hành 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 mẫu phản biện, hệ thống sẽ tự động phân biệt giữa hai loại tình huống: Nếu mẫu mẫu đó bắt nguồn từ sự sai lệch giữa định nghĩa đặc tả và ngữ nghĩa nghiệp vụ, thì bối cảnh mẫu phản biện sẽ được trả về mô-đun AI để tinh chỉnh đặc tả và thúc đẩy vòng lặp tiếp theo; nếu ví dụ mẫu tương ứng với đường dẫn có thể khai thác thực sự của mã hợp đồng, thì nó sẽ được xuất trực tiếp dưới dạng bằng chứng về lỗ hổng bảo mật, với bản tái tạo đường dẫn tấn công hoàn chỉnh, để các chuyên gia kiểm toán xác nhận và theo dõi sửa chữa. Cùng với nhau, hai đường dẫn này thúc đẩy sự hội tụ vòng kín cho đến khi thuộc tính đích được xác nhận về mặt toán học là đúng cho tất cả các đầu vào có thể có. Đường dẫn quan trọng được xác minh bởi cơ chế vòng kín này tạo thành tuyến phòng thủ chắc chắn nhất trong toàn bộ hệ thống bảo mật hợp đồng, nén bề mặt tấn công xuống một phạm vi cực kỳ hẹp.

3.2 Kiểm tra cơ sở 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

Đồng thời, Beosin cũng cung cấp kiểm tra cơ sở AI nâng cao dựa trên nền tảng kiến ​​thức Kỹ năng như một dịch vụ độc lập cho khách hàng. Không giống như kiểm tra chuyên sâu thủ công tập trung vào việc tìm kiếm các lỗ hổng có rủi ro cao, dịch vụ này được định vị gần hơn với báo cáo tình trạng mã dành cho nhóm phát triển. Quét cơ sở AI sẽ bao gồm đầy đủ mã hợp đồng và phân loại một cách có hệ thống các vấn đề tiềm ẩn hiện không trực tiếp gây thiệt hại kinh tế nhưng đòi hỏi 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 sau này. Ví dụ: việc sử dụng các thư viện phụ thuộc đã lỗi thời, thiếu phần khai báo sự kiện quan trọng, các phương pháp hiển thị biến trạng thái không tuân thủ các phương pháp hay nhất và các kiể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 kinh doanh hiện tại, nhưng với việc mở rộng các chức năng giao thức, xây dựng lại mã hoặc cập nhật phụ thuộc bên ngoài, một số vấn đề này có thể dần dần phát triển thành rủi ro bảo mật thực sự. Mỗi cấp độ trong số ba cấp độ đều có trọng tâm riêng và tiến triển từng bước, cùng nhau xây dựng một hệ thống đảm bảo hoàn chỉnh về tính bảo mật cho các dự án Web3.