零知識證明libSnark中Groth16演算法的優劣——可加工性攻擊問題
Groth16相比於PGHR13和GM17實現,具有一定的時間和空間優勢,具體可參考:
libsnark中有對snark的不同實現方法做了效能對比:
ZoKrates中採用的是Ethereum支援的ALT_BN128曲線,同時也對這三種方法做了實現,預設採用的是Groth16(已用Rust語言重寫,若需使用--proving-scheme pghr13
或--proving-scheme gm17
,則需使用C++語言 的libsnark庫,編譯時需指定相應的features cargo -Z package-features build --release --package zokrates_cli --features="libsnark"
G16 malleability
When using G16, developers should pay attention to the fact that an attacker seeing a valid proof can very easily generate a different but still valid proof. Therefore, depending on the use case, making sure on chain that the same proof cannot be submitted twice may not be enough to guarantee that attackers cannot replay proofs. Mechanisms to solve this issue include:1.signed proofs
2.nullifiers
3.usage of an ethereum address as a public input to the program
4.usage of non-malleable schemes such as GM17
注意:
若使用非預設的g16演算法,則在./zokrates setup --proving-scheme pghr13
,./zokrates generate-proof --proving-scheme pghr13
及./zokrates export-verifier --proving-scheme pghr13
panic
錯誤。
另,也可檢視proof.json
檔案驗證,groth16
演算法所生成的proof檔案中所含的field elements
數量要比pghr13
演算法少一半多。