Tác giả: Chuyên gia nghiên cứu bảo mật Beosin Saya & Bryce
1. Bằng chứng không có kiến thức là gì
Zero-Knowledge Proof (ZKP) là một khái niệm mật mã có thể được sử dụng để chứng minh tính xác thực của một tuyên bố mà không tiết lộ bất kỳ thông tin cụ thể nào về tuyên bố đó. Trong bằng chứng không có kiến thức, người chứng minh có thể chứng minh cho người xác minh rằng một tuyên bố nhất định là đúng và người xác minh chỉ nhận được một kết quả: chấp nhận tuyên bố đó là đúng hoặc từ chối nó mà không biết chi tiết cụ thể của bằng chứng.
Khái niệm này có thể được giải thích bằng một ví dụ đơn giản. Giả sử có hai người, một người là người chứng minh và một người là người kiểm chứng. Người chứng minh muốn chứng minh cho người xác minh rằng anh ta biết mật khẩu bí mật mà không tiết lộ mật khẩu đó. Theo cách truyền thống, người chứng minh có thể cho người xác minh biết mật khẩu là gì, nhưng trong bằng chứng không có kiến thức, người chứng minh có thể sử dụng một giao thức đặc biệt để chứng minh cho người xác minh rằng anh ta biết tính chính xác của mật khẩu mà không cần tiết lộ mật khẩu.
Hiện tại, các thuật toán hệ thống chứng minh không có kiến thức phổ biến bao gồm zk-SNARK, zk-STARK, BulletProofs, v.v.
2. Ứng dụng ZKP trong blockchain
Trong công nghệ blockchain, ZKP có nhiều ứng dụng khác nhau, như cải thiện quyền riêng tư, cải thiện khả năng mở rộng và bảo mật, v.v. Dưới đây là một số ứng dụng chính của ZKP trong blockchain:
1 Bảo vệ quyền riêng tư:
Blockchain là công khai, có nghĩa là bất kỳ ai cũng có thể xem tất cả các giao dịch trên chuỗi. Tuy nhiên, đôi khi người dùng có thể muốn giữ kín thông tin giao dịch của mình. ZKP cho phép người dùng chứng minh rằng họ có đủ tiền để giao dịch mà không cần phải tiết lộ tổng số tiền của mình. Điều này giúp tăng cường đáng kể việc bảo vệ quyền riêng tư của người dùng. Ví dụ: Zcash là một loại tiền điện tử sử dụng công nghệ chứng minh không có kiến thức, cho phép người dùng ẩn người gửi, người nhận và số tiền giao dịch.
2 Nén tính toán và mở rộng chuỗi khối:
Khả năng mở rộng chuỗi khối là một thách thức, đặc biệt là trong các ứng dụng quy mô lớn. ZKP có thể được sử dụng để giảm gánh nặng cho các nút và cải thiện khả năng mở rộng của toàn bộ hệ thống. Bằng cách sử dụng ZKP để xác minh tính hợp lệ của các giao dịch, các nút không cần xem toàn bộ lịch sử giao dịch, do đó giảm gánh nặng lưu trữ và xử lý.ZK Rollup, hiện được sử dụng rộng rãi nhất, là một giải pháp khả năng mở rộng được thiết kế để cải thiện Ethereum và các lĩnh vực khác Thông lượng và hiệu quả của mạng blockchain. Nó kết hợp các ưu điểm của công nghệ Rollup và ZKP để cung cấp các giải pháp mở rộng ứng dụng phi tập trung (DApps) hiệu suất cao. Trên mạng Ethereum truyền thống, mỗi giao dịch cần được xác minh và ghi lại trên blockchain, điều này dẫn đến sự chậm trễ và chi phí xử lý giao dịch cao. ZK Rollup nhóm và nén một số lượng lớn giao dịch thành một khối duy nhất và ZKP được sử dụng để chứng minh tính hợp lệ của các giao dịch hàng loạt nhằm đảm bảo tính chính xác và bảo mật của giao dịch.
3 Xác thực:
Bằng chứng không có kiến thức có thể được sử dụng để xác minh danh tính người dùng mà không tiết lộ thông tin cá nhân nhạy cảm. Ví dụ: một người có thể sử dụng bằng chứng không có kiến thức để chứng minh với mạng rằng họ đáp ứng yêu cầu về độ tuổi nhất định hoặc có chứng nhận nhất định mà không tiết lộ tuổi chính xác hoặc thông tin nhận dạng khác.
4 Lưu trữ phi tập trung:
Máy chủ có thể chứng minh cho người dùng rằng dữ liệu của họ đang được lưu giữ an toàn và không có nội dung dữ liệu nào bị rò rỉ.
Nói chung, bằng chứng không có kiến thức của **blockchain có ứng dụng rộng rãi trong bảo vệ quyền riêng tư, nén và mở rộng máy tính, xác minh danh tính, lưu trữ phi tập trung, v.v. Nó cung cấp nhiều chức năng và tùy chọn hơn cho công nghệ blockchain, đồng thời thúc đẩy sự phát triển và ứng dụng blockchain trong các lĩnh vực khác nhau. **
3. Tấn công chi tiêu gấp đôi trong các ứng dụng ZKP
zk-SNARK (Đối số kiến thức không tương tác ngắn gọn không có kiến thức) là một công nghệ dựa trên bằng chứng không có kiến thức có thể chứng minh tính xác thực của một tuyên bố mà không tiết lộ thông tin thực. Đây là một công nghệ chứng minh không có kiến thức rất hiệu quả, có thể tạo và xác minh bằng chứng trong thời gian rất ngắn đồng thời bảo vệ quyền riêng tư và bảo mật nên được sử dụng rộng rãi. Tuy nhiên, với sự mở rộng của các ứng dụng, tính bảo mật của nó ngày càng thu hút nhiều sự chú ý hơn. Chúng tôi đã phát hiện ra lỗ hổng chung của nó cách đây không lâu: nếu phạm vi giá trị của tham số đầu vào trong hàm xác minh không được xác minh chính xác trong dự án ZKP, kẻ tấn công có thể giả mạo nhiều đầu vào để vượt qua xác minh, gây ra cuộc tấn công chi tiêu gấp đôi. Tác động của cuộc tấn công này rất rộng, liên quan đến nhiều thuật toán zk-SNARK bao gồm: groth16, plonk, v.v. và lỗ hổng này tồn tại trong nhiều ngôn ngữ phát triển như Solidity và js. Lỗ hổng này lần đầu tiên được phát hiện bởi Poma trên dự án Semaphore bằng chứng không có kiến thức và hai ví dụ về các giao dịch được thực hiện thành công đã được đưa ra, như trong hình bên dưới:
Nguyên tắc tấn công cụ thể của lỗ hổng này là nếu bạn muốn tạo và xác minh bằng chứng zk-SNARK trong Ethereum, bạn cần sử dụng mạch đường cong elip trường hữu hạn F_p-arithmetic, trong đó giá trị p được sử dụng để xác định phạm vi của trường hữu hạn đường cong elliptic nên mạch có phạm vi giá trị đầu vào là [0,1,…,p-1]. Các đường cong khác nhau có giá trị p khác nhau:
Đường cong BN254 được xác định trong EIP-196 (còn được gọi là đường cong ALT_BN128):
p = 21888242871839275222246405745257275088548364400416034343698204186575808495617
Circom2 giới thiệu hai số nguyên tố mới, đường cong BLS12-381:
p = 52435875175126190479447740508185965837690552500527637822603658699938581184513
và plink2:
18446744069414584321
Semaphore sau đó đã xác nhận và vá lỗ hổng này, đồng thời các thư viện zk như ZoKrates và snarkjs cũng đồng loạt thực hiện sửa chữa khẩn cấp. Tuy nhiên, các nhà nghiên cứu bảo mật của Beosin nhận thấy rằng hiện tại chưa có giải pháp thống nhất nào cho vấn đề này. thư viện. Phạm vi dữ liệu hợp lệ không được xác minh rõ ràng trong logic nghiệp vụ bên ngoài, mã hợp đồng được tạo bởi Circom và Tornado.Cash xác minh rõ ràng SNARK_SCALAR_FIELD trong hàm xác minh. Đây là một giải pháp khó hiểu và không nhất quán. Nó có thể gây ra rắc rối và rủi ro bảo mật đối với nhiều bên dự án zk DApp mới, vì vậy chúng tôi hy vọng sẽ sử dụng một cách tiêu chuẩn hóa để giải quyết vấn đề này.
4. Tấn công chi tiêu gấp đôi trong ERC-1922
Hiện tại, Ethereum có tiêu chuẩn liên quan đến zk là EIP-1922, trong đó giới thiệu giao diện tiêu chuẩn hợp đồng Verify để xác minh zk-SNARK, mã cụ thể như sau:
pragma Solidity ^0.5.6;/// @title EIP-XXXX zk-SNARK Tiêu chuẩn xác minh/// @dev Xem /// Lưu ý: mã định danh ERC-165 cho giao diện này là 0xXXXXXXXXX./// ⚠️ TODO: Tính toán giao diện ID giao diện ERC1922 /* là ERC165 */ { /// @notice Kiểm tra các đối số của Proof, thông qua đường cong elip /// các hàm ghép nối. /// @dev /// PHẢI trả về true nếu Bằng chứng vượt qua tất cả các kiểm tra (tức là Bằng chứng là /// hợp lệ). /// PHẢI trả về false nếu Bằng chứng không vượt qua tất cả các bước kiểm tra (tức là nếu /// Bằng chứng không hợp lệ). /// @param bằng chứng A zk-SNARK. /// @param đầu vào Đầu vào công khai đi kèm với Bằng chứng. /// @param verifyKeyId Mã định danh duy nhất (được người xác minh này biết /// hợp đồng) cho Khóa xác minh mà Bằng chứng tương ứng. /// @return result Kết quả của phép tính xác minh. Đúng /// nếu Bằng chứng hợp lệ; sai nếu không. hàm verify(uint256[] calldata proof, uint256[] calldata input, bytes32 verifyKeyId) trả về bên ngoài (kết quả bool);}
Trong số đó, các loại biến đầu vào và bằng chứng chứng minh không có kiến thức là uint256[]. Loại biến này hiện là hoạt động đường cong elip được sử dụng phổ biến nhất trong thuật toán ZKP. Tuy nhiên, bảo vệ bảo mật tương ứng không được thêm vào giao diện này, vì vậy hãy tăng gấp đôi -các cuộc tấn công chi tiêu cũng tồn tại.
5. Giải pháp ERC-7520
Dựa trên những vấn đề trên, Beosin đã đề xuất EIP-7520 để ngăn chặn loại rủi ro bảo mật này. Cụ thể, tất cả các dự án DApp sử dụng công nghệ zk trong hệ sinh thái Ethereum đều phải triển khai giao diện này trong hợp đồng xác minh tuân thủ để sử dụng các tiêu chuẩn thống nhất và an toàn. xác minh phạm vi hợp lệ trên tất cả các đầu vào. Giao diện cụ thể như sau:
pragma Solidity ^0.5.6;/// @title EIP-XXXX zk-SNARK đầu vào công khai Tiêu chuẩn xác minh/// Lưu ý: mã định danh ERC-165 cho giao diện này là 0xXXXXXXXXX./// ⚠️ VIỆC CẦN LÀM: Tính toán mã định danh giao diệngiao diện EIP7520 /* là ERC165 & ERC1922 */ { /// @notice Kiểm tra các đối số của Đầu vào nằm trong trường vô hướng /// @dev /// PHẢI trả về true nếu Đầu vào vượt qua kiểm tra phạm vi (tức là Đầu vào là /// hợp lệ). /// PHẢI trả về false nếu Đầu vào không vượt qua kiểm tra phạm vi (tức là nếu /// Đầu vào không hợp lệ). /// @param đầu vào Đầu vào công khai đi kèm với Bằng chứng. /// @param p Đầu vào công khai đi kèm với đường cong. hàm verifyPublicInput(uint256[] input,uint256 p) trả về bên ngoài (kết quả bool)；}
Hàm verifyPublicInput là cốt lõi của tiêu chuẩn này, ý nghĩa cụ thể của các tham số liên quan như sau:
đầu vào: được định nghĩa là loại uint256[], biểu thị các tham số tín hiệu công cộng liên quan đến chức năng xác minh trong dự án ZKP
*p: Được xác định là loại uint256, giá trị này tương ứng với giá trị p của đường cong elliptic được sử dụng trong thuật toán
Sau đây sẽ so sánh hai tình huống triển khai và không triển khai giao diện EIP-7520, nhằm vào các biểu hiện khác nhau của cuộc tấn công này, để chỉ ra những rủi ro cho các bên tham gia dự án:
1 Giả sử chúng ta trực tiếp sử dụng mã hợp đồng verify để xác minh mà không gọi verifyPublicInput của giao diện eip này, mã cụ thể như sau:
hàm verify(uint[] đầu vào bộ nhớ, Proof bộ nhớ proof) trả về khung nhìn bên trong (uint) { VerifyingKey bộ nhớ vk = verifyKey(); require(input.length + 1 == vk.IC.length,"verifier-bad-input"); // Tính tổ hợp tuyến tính vk_x Pairing.G1Point bộ nhớ vk_x = Pairing.G1Point(0, 0); for (uint i = 0; i < input.length; i++) vk_x = Pairing.addition(vk_x, Pairing.scalar_mul(vk.IC[i + 1], input [i] )); vk_x = Pairing.addition(vk_x, vk.IC [0] ); if (!Pairing.pairingProd4( Pairing.negate(proof.A), proof.B, vk.alfa1, vk.beta2, vk_x, vk.gamma2, proof.C, vk.delta2 )) return 1; trả về 0;}
Ảnh chụp màn hình kết quả thử nghiệm ban đầu chứng minh rằng quá trình xác minh đã vượt qua:
Đồng thời, bốn chứng chỉ sau có thể bị giả mạo và cũng có thể vượt qua quá trình xác minh, gây ra cuộc tấn công chi tiêu gấp đôi:
Sử dụng một trong các bằng chứng giả mạo, kết quả xác minh như sau:
2 Nếu giao diện verifyPublicInput trong eip này được gọi, bằng chứng giả mạo ở trên sẽ không thể xác minh. Một phần mã hợp đồng như sau. Để biết chi tiết còn lại, vui lòng tham khảo Triển khai tham khảo:
hàm verifyx(uint[] đầu vào bộ nhớ, Bằng chứng bộ nhớ bằng chứng, byte32 verifyKeyId,uint256 p) trả về công khai (uint){ require(verifyPublicInput(inputs,p),"verifier-over-snark-scalar-field"); require(verify(input,proof,verificationKeyId),"xác minh thất bại"); trả về true;}hàm verifyPublicInput(uint256[] input,uint256 p) chế độ xem nội bộ trả về (bool) { for (uint i = 0; i < input.length; i++) { require(input < p,"verifier-gte-snark -trường vô hướng"); } trả về đúng;}
Kết quả thực nghiệm được thể hiện ở hình dưới đây:
Tóm lại, có thể thấy rằng nếu giao diện này không được sử dụng để xác minh tính hợp lệ của phạm vi giá trị tín hiệu công cộng thì có thể có nguy cơ xảy ra các cuộc tấn công chi tiêu gấp đôi. **
Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Giải thích chi tiết về dự thảo ERC-7520: bảo vệ tấn công tràn đầu vào công cộng zk-SNARK
Tác giả: Chuyên gia nghiên cứu bảo mật Beosin Saya & Bryce
1. Bằng chứng không có kiến thức là gì
Zero-Knowledge Proof (ZKP) là một khái niệm mật mã có thể được sử dụng để chứng minh tính xác thực của một tuyên bố mà không tiết lộ bất kỳ thông tin cụ thể nào về tuyên bố đó. Trong bằng chứng không có kiến thức, người chứng minh có thể chứng minh cho người xác minh rằng một tuyên bố nhất định là đúng và người xác minh chỉ nhận được một kết quả: chấp nhận tuyên bố đó là đúng hoặc từ chối nó mà không biết chi tiết cụ thể của bằng chứng.
Khái niệm này có thể được giải thích bằng một ví dụ đơn giản. Giả sử có hai người, một người là người chứng minh và một người là người kiểm chứng. Người chứng minh muốn chứng minh cho người xác minh rằng anh ta biết mật khẩu bí mật mà không tiết lộ mật khẩu đó. Theo cách truyền thống, người chứng minh có thể cho người xác minh biết mật khẩu là gì, nhưng trong bằng chứng không có kiến thức, người chứng minh có thể sử dụng một giao thức đặc biệt để chứng minh cho người xác minh rằng anh ta biết tính chính xác của mật khẩu mà không cần tiết lộ mật khẩu.
Hiện tại, các thuật toán hệ thống chứng minh không có kiến thức phổ biến bao gồm zk-SNARK, zk-STARK, BulletProofs, v.v.
2. Ứng dụng ZKP trong blockchain
Trong công nghệ blockchain, ZKP có nhiều ứng dụng khác nhau, như cải thiện quyền riêng tư, cải thiện khả năng mở rộng và bảo mật, v.v. Dưới đây là một số ứng dụng chính của ZKP trong blockchain:
1 Bảo vệ quyền riêng tư:
Blockchain là công khai, có nghĩa là bất kỳ ai cũng có thể xem tất cả các giao dịch trên chuỗi. Tuy nhiên, đôi khi người dùng có thể muốn giữ kín thông tin giao dịch của mình. ZKP cho phép người dùng chứng minh rằng họ có đủ tiền để giao dịch mà không cần phải tiết lộ tổng số tiền của mình. Điều này giúp tăng cường đáng kể việc bảo vệ quyền riêng tư của người dùng. Ví dụ: Zcash là một loại tiền điện tử sử dụng công nghệ chứng minh không có kiến thức, cho phép người dùng ẩn người gửi, người nhận và số tiền giao dịch.
2 Nén tính toán và mở rộng chuỗi khối:
Khả năng mở rộng chuỗi khối là một thách thức, đặc biệt là trong các ứng dụng quy mô lớn. ZKP có thể được sử dụng để giảm gánh nặng cho các nút và cải thiện khả năng mở rộng của toàn bộ hệ thống. Bằng cách sử dụng ZKP để xác minh tính hợp lệ của các giao dịch, các nút không cần xem toàn bộ lịch sử giao dịch, do đó giảm gánh nặng lưu trữ và xử lý.ZK Rollup, hiện được sử dụng rộng rãi nhất, là một giải pháp khả năng mở rộng được thiết kế để cải thiện Ethereum và các lĩnh vực khác Thông lượng và hiệu quả của mạng blockchain. Nó kết hợp các ưu điểm của công nghệ Rollup và ZKP để cung cấp các giải pháp mở rộng ứng dụng phi tập trung (DApps) hiệu suất cao. Trên mạng Ethereum truyền thống, mỗi giao dịch cần được xác minh và ghi lại trên blockchain, điều này dẫn đến sự chậm trễ và chi phí xử lý giao dịch cao. ZK Rollup nhóm và nén một số lượng lớn giao dịch thành một khối duy nhất và ZKP được sử dụng để chứng minh tính hợp lệ của các giao dịch hàng loạt nhằm đảm bảo tính chính xác và bảo mật của giao dịch.
3 Xác thực:
Bằng chứng không có kiến thức có thể được sử dụng để xác minh danh tính người dùng mà không tiết lộ thông tin cá nhân nhạy cảm. Ví dụ: một người có thể sử dụng bằng chứng không có kiến thức để chứng minh với mạng rằng họ đáp ứng yêu cầu về độ tuổi nhất định hoặc có chứng nhận nhất định mà không tiết lộ tuổi chính xác hoặc thông tin nhận dạng khác.
4 Lưu trữ phi tập trung:
Máy chủ có thể chứng minh cho người dùng rằng dữ liệu của họ đang được lưu giữ an toàn và không có nội dung dữ liệu nào bị rò rỉ.
Nói chung, bằng chứng không có kiến thức của **blockchain có ứng dụng rộng rãi trong bảo vệ quyền riêng tư, nén và mở rộng máy tính, xác minh danh tính, lưu trữ phi tập trung, v.v. Nó cung cấp nhiều chức năng và tùy chọn hơn cho công nghệ blockchain, đồng thời thúc đẩy sự phát triển và ứng dụng blockchain trong các lĩnh vực khác nhau. **
3. Tấn công chi tiêu gấp đôi trong các ứng dụng ZKP
zk-SNARK (Đối số kiến thức không tương tác ngắn gọn không có kiến thức) là một công nghệ dựa trên bằng chứng không có kiến thức có thể chứng minh tính xác thực của một tuyên bố mà không tiết lộ thông tin thực. Đây là một công nghệ chứng minh không có kiến thức rất hiệu quả, có thể tạo và xác minh bằng chứng trong thời gian rất ngắn đồng thời bảo vệ quyền riêng tư và bảo mật nên được sử dụng rộng rãi. Tuy nhiên, với sự mở rộng của các ứng dụng, tính bảo mật của nó ngày càng thu hút nhiều sự chú ý hơn. Chúng tôi đã phát hiện ra lỗ hổng chung của nó cách đây không lâu: nếu phạm vi giá trị của tham số đầu vào trong hàm xác minh không được xác minh chính xác trong dự án ZKP, kẻ tấn công có thể giả mạo nhiều đầu vào để vượt qua xác minh, gây ra cuộc tấn công chi tiêu gấp đôi. Tác động của cuộc tấn công này rất rộng, liên quan đến nhiều thuật toán zk-SNARK bao gồm: groth16, plonk, v.v. và lỗ hổng này tồn tại trong nhiều ngôn ngữ phát triển như Solidity và js. Lỗ hổng này lần đầu tiên được phát hiện bởi Poma trên dự án Semaphore bằng chứng không có kiến thức và hai ví dụ về các giao dịch được thực hiện thành công đã được đưa ra, như trong hình bên dưới:
Nguyên tắc tấn công cụ thể của lỗ hổng này là nếu bạn muốn tạo và xác minh bằng chứng zk-SNARK trong Ethereum, bạn cần sử dụng mạch đường cong elip trường hữu hạn F_p-arithmetic, trong đó giá trị p được sử dụng để xác định phạm vi của trường hữu hạn đường cong elliptic nên mạch có phạm vi giá trị đầu vào là [0,1,…,p-1]. Các đường cong khác nhau có giá trị p khác nhau:
Đường cong BN254 được xác định trong EIP-196 (còn được gọi là đường cong ALT_BN128):
p = 21888242871839275222246405745257275088548364400416034343698204186575808495617
Circom2 giới thiệu hai số nguyên tố mới, đường cong BLS12-381:
p = 52435875175126190479447740508185965837690552500527637822603658699938581184513
và plink2:
18446744069414584321
Semaphore sau đó đã xác nhận và vá lỗ hổng này, đồng thời các thư viện zk như ZoKrates và snarkjs cũng đồng loạt thực hiện sửa chữa khẩn cấp. Tuy nhiên, các nhà nghiên cứu bảo mật của Beosin nhận thấy rằng hiện tại chưa có giải pháp thống nhất nào cho vấn đề này. thư viện. Phạm vi dữ liệu hợp lệ không được xác minh rõ ràng trong logic nghiệp vụ bên ngoài, mã hợp đồng được tạo bởi Circom và Tornado.Cash xác minh rõ ràng SNARK_SCALAR_FIELD trong hàm xác minh. Đây là một giải pháp khó hiểu và không nhất quán. Nó có thể gây ra rắc rối và rủi ro bảo mật đối với nhiều bên dự án zk DApp mới, vì vậy chúng tôi hy vọng sẽ sử dụng một cách tiêu chuẩn hóa để giải quyết vấn đề này.
4. Tấn công chi tiêu gấp đôi trong ERC-1922
Hiện tại, Ethereum có tiêu chuẩn liên quan đến zk là EIP-1922, trong đó giới thiệu giao diện tiêu chuẩn hợp đồng Verify để xác minh zk-SNARK, mã cụ thể như sau:
pragma Solidity ^0.5.6;/// @title EIP-XXXX zk-SNARK Tiêu chuẩn xác minh/// @dev Xem /// Lưu ý: mã định danh ERC-165 cho giao diện này là 0xXXXXXXXXX./// ⚠️ TODO: Tính toán giao diện ID giao diện ERC1922 /* là ERC165 */ { /// @notice Kiểm tra các đối số của Proof, thông qua đường cong elip /// các hàm ghép nối. /// @dev /// PHẢI trả về true nếu Bằng chứng vượt qua tất cả các kiểm tra (tức là Bằng chứng là /// hợp lệ). /// PHẢI trả về false nếu Bằng chứng không vượt qua tất cả các bước kiểm tra (tức là nếu /// Bằng chứng không hợp lệ). /// @param bằng chứng A zk-SNARK. /// @param đầu vào Đầu vào công khai đi kèm với Bằng chứng. /// @param verifyKeyId Mã định danh duy nhất (được người xác minh này biết /// hợp đồng) cho Khóa xác minh mà Bằng chứng tương ứng. /// @return result Kết quả của phép tính xác minh. Đúng /// nếu Bằng chứng hợp lệ; sai nếu không. hàm verify(uint256[] calldata proof, uint256[] calldata input, bytes32 verifyKeyId) trả về bên ngoài (kết quả bool);}
Trong số đó, các loại biến đầu vào và bằng chứng chứng minh không có kiến thức là uint256[]. Loại biến này hiện là hoạt động đường cong elip được sử dụng phổ biến nhất trong thuật toán ZKP. Tuy nhiên, bảo vệ bảo mật tương ứng không được thêm vào giao diện này, vì vậy hãy tăng gấp đôi -các cuộc tấn công chi tiêu cũng tồn tại.
5. Giải pháp ERC-7520
Dựa trên những vấn đề trên, Beosin đã đề xuất EIP-7520 để ngăn chặn loại rủi ro bảo mật này. Cụ thể, tất cả các dự án DApp sử dụng công nghệ zk trong hệ sinh thái Ethereum đều phải triển khai giao diện này trong hợp đồng xác minh tuân thủ để sử dụng các tiêu chuẩn thống nhất và an toàn. xác minh phạm vi hợp lệ trên tất cả các đầu vào. Giao diện cụ thể như sau:
pragma Solidity ^0.5.6;/// @title EIP-XXXX zk-SNARK đầu vào công khai Tiêu chuẩn xác minh/// Lưu ý: mã định danh ERC-165 cho giao diện này là 0xXXXXXXXXX./// ⚠️ VIỆC CẦN LÀM: Tính toán mã định danh giao diệngiao diện EIP7520 /* là ERC165 & ERC1922 */ { /// @notice Kiểm tra các đối số của Đầu vào nằm trong trường vô hướng /// @dev /// PHẢI trả về true nếu Đầu vào vượt qua kiểm tra phạm vi (tức là Đầu vào là /// hợp lệ). /// PHẢI trả về false nếu Đầu vào không vượt qua kiểm tra phạm vi (tức là nếu /// Đầu vào không hợp lệ). /// @param đầu vào Đầu vào công khai đi kèm với Bằng chứng. /// @param p Đầu vào công khai đi kèm với đường cong. hàm verifyPublicInput(uint256[] input,uint256 p) trả về bên ngoài (kết quả bool)；}
Hàm verifyPublicInput là cốt lõi của tiêu chuẩn này, ý nghĩa cụ thể của các tham số liên quan như sau:
Sau đây sẽ so sánh hai tình huống triển khai và không triển khai giao diện EIP-7520, nhằm vào các biểu hiện khác nhau của cuộc tấn công này, để chỉ ra những rủi ro cho các bên tham gia dự án:
1 Giả sử chúng ta trực tiếp sử dụng mã hợp đồng verify để xác minh mà không gọi verifyPublicInput của giao diện eip này, mã cụ thể như sau:
hàm verify(uint[] đầu vào bộ nhớ, Proof bộ nhớ proof) trả về khung nhìn bên trong (uint) { VerifyingKey bộ nhớ vk = verifyKey(); require(input.length + 1 == vk.IC.length,"verifier-bad-input"); // Tính tổ hợp tuyến tính vk_x Pairing.G1Point bộ nhớ vk_x = Pairing.G1Point(0, 0); for (uint i = 0; i < input.length; i++) vk_x = Pairing.addition(vk_x, Pairing.scalar_mul(vk.IC[i + 1], input [i] )); vk_x = Pairing.addition(vk_x, vk.IC [0] ); if (!Pairing.pairingProd4( Pairing.negate(proof.A), proof.B, vk.alfa1, vk.beta2, vk_x, vk.gamma2, proof.C, vk.delta2 )) return 1; trả về 0;}
Ảnh chụp màn hình kết quả thử nghiệm ban đầu chứng minh rằng quá trình xác minh đã vượt qua:
Đồng thời, bốn chứng chỉ sau có thể bị giả mạo và cũng có thể vượt qua quá trình xác minh, gây ra cuộc tấn công chi tiêu gấp đôi:
Sử dụng một trong các bằng chứng giả mạo, kết quả xác minh như sau:
2 Nếu giao diện verifyPublicInput trong eip này được gọi, bằng chứng giả mạo ở trên sẽ không thể xác minh. Một phần mã hợp đồng như sau. Để biết chi tiết còn lại, vui lòng tham khảo Triển khai tham khảo:
hàm verifyx(uint[] đầu vào bộ nhớ, Bằng chứng bộ nhớ bằng chứng, byte32 verifyKeyId,uint256 p) trả về công khai (uint){ require(verifyPublicInput(inputs,p),"verifier-over-snark-scalar-field"); require(verify(input,proof,verificationKeyId),"xác minh thất bại"); trả về true;}hàm verifyPublicInput(uint256[] input,uint256 p) chế độ xem nội bộ trả về (bool) { for (uint i = 0; i < input.length; i++) { require(input < p,"verifier-gte-snark -trường vô hướng"); } trả về đúng;}
Kết quả thực nghiệm được thể hiện ở hình dưới đây:
Tóm lại, có thể thấy rằng nếu giao diện này không được sử dụng để xác minh tính hợp lệ của phạm vi giá trị tín hiệu công cộng thì có thể có nguy cơ xảy ra các cuộc tấn công chi tiêu gấp đôi. **