零知识证明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"）。同时，在其指导网页中也指出，Groth16算法存在可加工性攻击问题——即攻击者可利用已知的valid proof再加工出不同的valid proof，详细描述如下：

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算法少一半多。