Back to top
  • 공유 Chia sẻ
  • 인쇄 In
  • 글자크기 Cỡ chữ
URL đã được sao chép

Lỗ hổng xác minh native của SP1 được sửa trong bản 6.8.1, vá mainnet sau khi phát hành

Sơ đồ và trang mã minh họa việc xác minh chiều tensor / TokenPost.ai

Lỗ hổng trong đường xác minh native bằng Rust của SP1 V6 có thể khiến bằng chứng cho một lần thực thi sai vẫn được chấp nhận. Succinct đã sửa các phiên bản bị ảnh hưởng và áp dụng bản vá cho Prover Network đang vận hành trên mainnet.

Trong thông báo bảo mật công bố ngày 11 tháng 10 năm 2026, Succinct xếp lỗ hổng ở mức nghiêm trọng “Cao” (High). Các gói bị ảnh hưởng là sp1_hypercube, sp1_prover và sp1_sdk; các phiên bản bị ảnh hưởng nằm trong khoảng từ 6.0.0 đến 6.8.0. Bản sửa lỗi là phiên bản 6.8.1.

Vấn đề phát sinh khi đọc dữ liệu bằng chứng: hệ thống không kiểm tra số phần tử được lưu trong tensor có bằng tích các giá trị chiều đã khai báo hay không. Tensor là cấu trúc chứa dữ liệu nhiều chiều; số phần tử lưu trữ phải bằng tích các giá trị của từng chiều.

Bộ xác minh trước đây không kiểm tra hai giá trị này có khớp nhau hay không. Một số bước xác minh sử dụng các giá trị chiều đã khai báo mà không kiểm tra lại số phần tử được lưu. Vì vậy, nếu người tạo bằng chứng độc hại gửi tensor không nhất quán, các bước khác nhau có thể xử lý những phần khác nhau của cùng một tensor.

Succinct cho biết trong trường hợp đó, bằng chứng cho một lần thực thi sai có thể vượt qua xác minh native bằng Rust. Đây là mô tả về tác động kỹ thuật của lỗ hổng; chưa có trường hợp khai thác công khai nào được xác nhận.

Đối tượng bị ảnh hưởng là các bằng chứng Core và Compressed được gửi trực tiếp đến bộ xác minh native có lỗ hổng. Các ứng dụng nhận bằng chứng từ bên ngoài không đáng tin cậy qua đường này có thể bị ảnh hưởng.

Vào thời điểm phát hiện lỗ hổng, trường hợp triển khai bị ảnh hưởng được nêu trong thông báo là Prover Network trên mainnet do Succinct vận hành, nơi nhận bằng chứng từ các bên chứng minh bên thứ ba. Chưa xác định được liệu dịch vụ nào khác có bị ảnh hưởng hay không.

Đường xác minh Groth16 và Plonk dựa trên Solidity không bị ảnh hưởng. Các đường này dùng bằng chứng có định dạng cố định nên không xử lý tensor Rust gây ra vấn đề. Bằng chứng Compressed cũng không bị ảnh hưởng trong đường xác minh của thư viện này nếu kết quả tổng hợp cuối cùng là bằng chứng Groth16 hoặc Plonk.

SP1 là máy ảo không kiến thức (zkVM), dùng để chứng minh việc thực thi các chương trình như Rust được biên dịch bằng LLVM. Trong hướng dẫn về chương trình SP1 trên Immunefi, Succinct mô tả cấu trúc cho phép nhà phát triển tạo và xác minh bằng chứng thực thi chương trình.

Vấn đề lần này giới hạn ở lỗi thiếu kiểm tra hình dạng tensor trong một đường xác minh native bằng Rust cụ thể của V6, không ảnh hưởng đến toàn bộ SP1. Trước đó, Arbitrum đã tạo bằng chứng không kiến thức cho các khối mainnet thực tế bằng SP1, theo bài viết trước của TokenPost.

Succinct đã sửa lỗi bằng cách đối chiếu số phần tử lưu trữ với tích các giá trị chiều đã khai báo khi đọc tensor, đồng thời kiểm tra hình dạng thực tế của tensor trong quá trình xác minh native. Sau khi phát hành phiên bản 6.8.1, công ty đã triển khai bộ xác minh đã vá trên Prover Network mainnet.

Người dùng mạng này không cần thay đổi tích hợp. Succinct khuyến nghị các đơn vị tự vận hành bộ xác minh native bằng Rust và nhận bằng chứng không đáng tin cậy cập nhật lên phiên bản 6.8.1.

<Bản quyền ⓒ TokenPost, nghiêm cấm sao chép và phân phối trái phép>

Phổ biến nhất

Các bài viết liên quan khác

Bình luận 0

Mẹo bình luận

Bài viết tuyệt vời. Mong có bài tiếp theo. Phân tích xuất sắc.

0/1000

Mẹo bình luận

Bài viết tuyệt vời. Mong có bài tiếp theo. Phân tích xuất sắc.
1