Gas/Security-Bit cho chữ ký PQ trên Máy ảo Ethereum (EVM): Tập dữ liệu + Phương pháp luận

avatar
Ethereum Research
Bài viết này được dịch máy
Xem bản gốc

Gas trên mỗi Bit bảo mật: một tiêu chuẩn được chuẩn hóa cho chữ ký PQ trên Máy ảo Ethereum (EVM)

Chúc mọi người kỳ nghỉ lễ vui vẻ!

Tiếp nối cuộc thảo luận về chữ ký AA / Yêu cầu bình luận Ethereum (ERC)-4337 / PQ trong chủ đề này :

Cuối cùng, tôi đã tìm ra một mảnh ghép còn thiếu mà cứ liên tục xuất hiện một cách ngầm định:

Chúng ta không có đơn vị chuẩn hóa nào để so sánh các lược đồ chữ ký khác nhau ở các cấp độ bảo mật khác nhau trên Máy ảo Ethereum (EVM).

Hầu hết các phép so sánh đều sử dụng "gas trên mỗi lần xác minh", nhưng điều đó ngầm trộn lẫn các yếu tố sau:

  • các mục tiêu bảo mật khác nhau (ví dụ: ECDSA ~128 Bit so với các lược đồ PQ Cat3/Cat5),

  • các bề mặt kiểm chứng khác nhau (EOA so với Yêu cầu bình luận Ethereum (ERC)-1271/AA),

  • và đôi khi là các phạm vi đánh giá hiệu năng khác nhau (chỉ xác minh thuần túy so với toàn bộ quy trình HandleOps).

Điều đó khiến việc trả lời các câu hỏi kỹ thuật cơ bản như sau trở nên khó khăn:
“Liệu ML-DSA-65 có khả thi trên Máy ảo Ethereum (EVM) so với Falcon, với những giả định cụ thể?”

Những gì tôi đã xây dựng

Một phòng thí nghiệm đánh giá hiệu năng nhỏ + bộ dữ liệu với nguồn gốc rõ ràng và các tiêu chí bảo mật cụ thể:

Kho lưu trữ: GitHub - pipavlo82/gas-per-secure-bit: Đo hiệu năng gas trên mỗi Bit bảo mật cho chữ ký PQ và VRF.

Ý tưởng cốt lõi:

 gas_per_secure_bit = gas_verify / security_bits

Tôi cố ý trình bày hai mẫu số , bởi vì cả hai quan điểm đều hữu ích:

Chỉ số A — Chuẩn hóa cơ sở (cơ sở 128 Bit )

Câu hỏi này trả lời cho câu hỏi: “Chi phí cho mỗi đơn vị cơ bản 128 Bit là bao nhiêu?”

 gas_per_128b = gas_verify / 128

Điều này không có nghĩa là mọi hệ thống đều an toàn ở mức 128 Bit ; đây chỉ là một công cụ lập ngân sách/chuẩn hóa.

Chỉ số B — Bits tương đương về bảo mật (quy ước đã công bố)

Câu hỏi này trả lời cho câu hỏi: “Mỗi ' Bit bảo mật' có chi phí bao nhiêu theo một quy ước chuẩn hóa đã được công bố?”

 gas_per_sec_equiv_bit = gas_verify / security_equiv_bits

Hiện tại, tôi sử dụng quy ước rõ ràng sau đây cho chữ ký:

Cơ chế Danh mục NIST (nếu có) bảo mật_tương_bằng_bit
ECDSA (secp256k1) — 128
ML-DSA-65 (FIPS-204, Loại 3) 3 192
Falcon-1024 (Loại 5) 5 256

Tôi sử dụng một ánh xạ đơn giản Cat{1,3,5} → {128,192,256} làm quy ước chuẩn hóa đã được công bố (mở lòng đón nhận các quy ước tốt hơn từ cộng đồng).

Lưu ý: security_equiv_bits là một quy ước chuẩn hóa được công bố để so sánh. Nó không phải là bằng chứng bảo mật và không phải là giá trị “Bits” do NIST cung cấp.

Nguồn danh mục:

Nguồn gốc và khả năng tái tạo

Tất cả các số liệu hiện tại đều là ảnh chụp nhanh gas trong một lần chạy duy nhất (không tính trung bình) với đầy đủ thông tin nguồn gốc:
repo , commit , bench_name , chain_profile và trường notes .

Không có phép tính trung bình ẩn, không có lựa chọn "tốt nhất trong số N" — chỉ là những ảnh chụp nhanh có thể tái tạo mà người khác có thể chạy lại.

Kết quả (ảnh chụp nhanh hiện tại)

Biểu đồ ( Bits tương đương bảo mật)

SVG thô (khuyến nghị):

https://raw.githubusercontent.com/pipavlo82/gas-per-secure-bit/main/docs/gas-per-sec-equiv-bit-chart.svg

Trang GitHub:

https://github.com/pipavlo82/gas-per-secure-bit/blob/0b126bc2d2ee82f6f25c91b565106b243d4b077c/docs/gas-per-sec-equiv-bit-chart.svg

(Các băng ghế này không có cùng bề mặt; hãy xem đây là một tập dữ liệu được chuẩn hóa, chứ không phải là một bảng xếp hạng duy nhất.)

Một vài hàng quan trọng (chuẩn hóa cơ sở — chia cho 128)

Sơ đồ / ghế dài Gas gas_per_128b Ghi chú
ECDSA ecrecover 21.126 165 Đường cơ sở cổ điển; không an toàn PQ (Shor)
Falcon getUserOpHash 218.333 1.705 AA nguyên thủy nhỏ
ML-DSA-65 PreA (đường dẫn nóng riêng biệt) 1.499.354 11.714 lõi tính toán được tối ưu hóa
Falcon xác minh đầy đủ 10.336.055 80.751 PQ xác minh đầy đủ
ML-DSA-65 xác minh POC 68.901.612 538.294 POC từ đầu đến cuối

Chuẩn hóa tương đương về bảo mật (chia cho security_equiv_bits)

Sơ đồ / ghế dài Gas bảo mật_tương_bằng_bit gas_per_sec_equiv_bit
Falcon getUserOpHash 218.333 256 853
ML-DSA-65 PreA 1.499.354 192 7.809
Falcon xác minh đầy đủ 10.336.055 256 40.375
ML-DSA-65 xác minh POC 68.901.612 192 358.863

Điều gây ấn tượng mạnh nhất với tôi:

  • ML-DSA-65 PreA có mức tiêu hao khoảng ~ 7.809 gas / Bit tương đương bảo mật (tương đương Cat3).

  • Quá trình xác minh đầy đủ Falcon-1024 đạt khoảng ~ 40.375 gas / Bit tương đương bảo mật (tương đương Cat5).

Đó là sự khác biệt khoảng 5,2 lần đối với những chiếc ghế dài cụ thể đó.

Đây không phải là nhận định "ML-DSA vượt trội hơn Falcon về mọi mặt"; mà là một nhận định hẹp hơn:
Một số bề mặt xác minh ML-DSA có thể trở nên thân thiện hơn với EVM nếu bạn tránh tính toán lại cấu trúc công khai phức tạp on-chain.

“PreA” nghĩa là gì (và tại sao nó làm thay đổi bức tranh)

Trong quy trình xác minh ML-DSA tiêu chuẩn, phần lớn chi phí thực chất là:
ExpandA + chuyển đổi ma trận công khai sang miền NTT.

Đường dẫn “PreA” cô lập lõi số học nóng (A·z − c·t₁ trong miền NTT) bằng cách chấp nhận A_ntt được tính toán trước và liên kết nó với CommitA để ngăn chặn việc thay thế ma trận.

Trong hệ thống của tôi, A_ntt được tạo ra từ khóa công khai ( rho ) và sau đó được liên kết thông qua CommitA để ngăn chặn việc thay thế.

Đây là một điểm thiết kế kỹ thuật rõ ràng (đặc biệt trong bối cảnh AA): chuyển cấu trúc công khai lớn Ngoài chuỗi, nhưng vẫn giữ nó được liên kết bằng mật mã.

Sơ đồ phân tích sơ bộ (dây dẫn hiện tại):

  • Tính toán đầy đủ compute_w với ExpandA+NTT(A) on-chain : ~64,8 triệu gas

  • Lõi nhân ma trận cô lập (PreA): ~1,5 triệu gas

Triển khai:

Tại sao điều này lại quan trọng đối với AA / Yêu cầu bình luận Ethereum (ERC)-7913

Trong AA (Alcoholics Anonymous - Hội những người nghiện rượu ẩn danh), đơn vị mà bạn quan tâm hiếm khi là "xác minh một chữ ký riêng lẻ".
Bạn quan tâm đến các bề mặt ABI ổn định và khả năng so sánh giữa các ứng viên .

Yêu cầu bình luận Ethereum (ERC)-7913 cung cấp một giao diện xác minh chung.

Giả định của tôi: nếu chúng ta muốn việc áp dụng PQ được thiết kế một cách có chủ đích (chứ không phải dựa vào phỏng đoán), chúng ta cần:

  • một lược đồ chuẩn mực chung,

  • các mẫu số an ninh rõ ràng,

  • và các bề mặt tương đương (kiểm chứng thuần túy so với quy trình AA).

Mọi câu hỏi/phản hồi đều được hoan nghênh.

1) Kết nối dây Hash/XOF trên Máy ảo Ethereum (EVM)
Đối với các triển khai Máy ảo Ethereum (EVM) : chúng ta muốn (a) kết nối SHAKE tuân thủ nghiêm ngặt FIPS, (b) các biến thể không tuân thủ dựa trên Keccak, hay (c) các triển khai chế độ kép với nhãn rõ ràng trong tập dữ liệu?

2) Phương pháp đo lường kép có hợp lý không?
Chuẩn hóa đường cơ sở rất hữu ích cho việc lập ngân sách; Bits tương đương về bảo mật rất hữu ích cho việc đánh giá hiệu quả trung thực trên mỗi đơn vị bảo mật. Có ai phản đối việc báo cáo cả hai không?

3) Các lựa chọn tiêu chuẩn hóa PreA
Trong bối cảnh của AA, cách tiếp cận nào là ít tệ nhất?

  • dữ liệu cuộc gọi (lớn nhưng không lưu trạng thái),

  • dung lượng lưu trữ cho mỗi khóa,

  • biên dịch trước,

  • Kết hợp với liên kết CommitA?

Hướng dẫn nhanh về khả năng tái tạo

 git clone https://github.com/pipavlo82/gas-per-secure-bit cd gas-per-secure-bitRESET_DATA=0 MLDSA_REF= "feature/mldsa-ntt-opt-phase12-erc7913-packedA" \./scripts/run_vendor_mldsa.shRESET_DATA=0 ./scripts/run_ecdsa.shQA_REF=main RESET_DATA=0 ./scripts/run_vendor_quantumaccount.sh tail -n 20 data/results.csv

Cảm ơn vì đã đọc — Tôi rất sẵn lòng tiếp nhận những góp ý về quy ước, cách thức xây dựng mô hình mối đe dọa tốt hơn, và các đề xuất về những lược đồ/bề mặt nào nên thêm vào tiếp theo.

Liên kết


Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
Thêm vào Yêu thích
Bình luận
Nội dung liên quan