feat: add EVM precompiles

[ivokub]

Closes #466.

Even if we have many primitives, then this PR is introducing tightly coupled circuits for using with EVM precompiles. The goal is that we can take verbatim precompile call arguments and return whatever implementations would return.

Still WIP, but starting a draft PR for discussions on interfaces etc. Need to fix #484 as with test engine right now get errors where shouldn't.

More specifically:

• ECRecover - will have several variations with and without Keccak hashing the public key. Without hashing will rely on the prover to perform the hashing. But for consistency with the package promise will add variant with Keccak hashing. Mostly done, need to add a few in-circuit checks.
• sha256 - lower priority right now.
• identity - pointless
• expmod - definitely needs rangechecking. I assume will be most complicated. Plan is to use Montgomery multiplication and textbook square-and-mul algorithm.
• BN254 add - need to implement compatible interface.
• BN254 scalar mul - need to implement compatible interface.
• BN254 pairing - need to implement compatible interface.
• Blake2

Tasks:

• right now for testing ECRecover I have a local version of gnark-crypto which outputs compatible signatures (with v). Need to polish the implementation and merge in gnark-crypto for better maintainability.

[ivokub]

Precompiles done. Will update the stats in the corresponding issues.

Will do rest of the precompiles later (modexp, SHA256, Blake, RipeMD)

[ivokub]

@yelhousni, ping

[yelhousni]

LGTM! apart from the 08-bnpairing.go where I think the precompile does not return the pairing value but just checks it is equal to 1 (there is no support of Fp12 arithmetic in EVM).

[ivokub]

Resolved the comments. Right now didn't refactor ECRecover into std/signature/ecdsa as it would have made the implementation a lot more messy.

If re-checking code, then I would particularly point to ECPair test. I tried to define a succeeding test.

[yelhousni]

If re-checking code, then I would particularly point to ECPair test. I tried to define a succeeding test.

Suggested edit for ECPair test to use random points each time:

diff --git a/std/evmprecompiles/bn_test.go b/std/evmprecompiles/bn_test.go
index ed1cfb24..74815562 100644
--- a/std/evmprecompiles/bn_test.go
+++ b/std/evmprecompiles/bn_test.go
@@ -133,9 +133,8 @@ func TestECMulCircuitFull(t *testing.T) {
 }
 
 type ecpairCircuit struct {
-	P        [2]sw_bn254.G1Affine
-	Q        [2]sw_bn254.G2Affine
-	Expected sw_bn254.GTEl
+	P [2]sw_bn254.G1Affine
+	Q [2]sw_bn254.G2Affine
 }
 
 func (c *ecpairCircuit) Define(api frontend.API) error {
@@ -148,10 +147,19 @@ func (c *ecpairCircuit) Define(api frontend.API) error {
 func TestECPairCircuitShort(t *testing.T) {
 	assert := test.NewAssert(t)
 	_, _, p1, q1 := bn254.Generators()
+
+	var u, v fr.Element
+	u.SetRandom()
+	v.SetRandom()
+
+	p1.ScalarMultiplication(&p1, u.BigInt(new(big.Int)))
+	q1.ScalarMultiplication(&q1, v.BigInt(new(big.Int)))
+
 	var p2 bn254.G1Affine
 	var q2 bn254.G2Affine
 	p2.Neg(&p1)
 	q2.Set(&q1)
+
 	err := test.IsSolved(&ecpairCircuit{}, &ecpairCircuit{
 		P: [2]sw_bn254.G1Affine{sw_bn254.NewG1Affine(p1), sw_bn254.NewG1Affine(p2)},
 		Q: [2]sw_bn254.G2Affine{sw_bn254.NewG2Affine(q1), sw_bn254.NewG2Affine(q2)},

[yelhousni]

@ivokub I applied the edit in the last commit + removed Expected sw_bn254.GTEl which is not used anymore after PairingCheck() use.

[yelhousni]

Should we merge this PR or wait for the remaining precompiles?

[ivokub]

Should we merge this PR or wait for the remaining precompiles?

Looks good, I'll merge. Rest of the precompiles takes a bit time and is less important, so can do in another PR.