Add OpenZeppelin ERC20 transfers integration test

[ed255]

• Add a test contract of a basic ERC20 Token using the OpenZeppelin
  implementation.
• Add WETH9 base contract (not used yet in the integration tests)
• Introduce three integration testing blocks:
  • 1 tx: failed ERC20 transfer
  • 1 tx: successful ERC20 transfer
  • 4 txs: interleaved successful and failed ERC20 transfers
• Add macros in circuit_input_builder and circuits integration tests to
  define tests of each testing block easily.

Resolve #404

---

NOTE: The folder integration-tests/contracts/vendor/openzeppelin-contracts/ is a subtree repository from https://github.com/OpenZeppelin/openzeppelin-contracts.git and so there's no need to review any file from that folder.

[lispc]

great job! Btw I finished end2end contract call proving using Greeter.sol ( set_value & retrieve ).

scroll-tech#120

( bus-mapping of sstore & sload / is_zero / shr / calldataload are needed and implemented there) .

I am going to test & debug ERC20 contracts here next week!!!

[ed255]

Here's a summary of the output from running the tests:

• The failure ERC20 transfer doesn't seem to use any more currently unimplemented opcodes than the successful transfer.
• Used opcodes not implemented in bus-mapping nor evm circuit: SHA3, SSTORE, LOG3
• Used opcodes not implemented in evm circuit: ISZERO, CALLDATASIZE, CALLDATALOAD, SHR (I think some of them are implemented but are missing from the OpcodeId to ExecutionState conversion in witness.rs from evm_circuit)

[ed255]

great job! Btw I finished end2end contract call proving using Greeter.sol ( set_value & retrieve ).

scroll-tech#120

( bus-mapping of sstore & sload / is_zero / shr / calldataload are needed and implemented there) .

I am going to test & debug ERC20 contracts here next week!!!

That's great! 🎉 Looking forward to incorporate the changes in your PR as well :)

[CPerezz]

Everything looks good!

I maybe would have all of the contract stuff as a git sub-tree or sub-module (Highly encourage sub-tree) so that we are always in sync with these files and are easy to update.

WDYT @ed255 ??

Aside from that (which is not mandatory, just a quuestion) LGTM!!

Nice work!!!! 🥳

[lispc]

if we disable SHA3 & LOG3 ( I use dummy op which have no real constraints), multi ERC20 transfer including both success and failure can be proved now in my draft branch. scroll-tech#127

[ed255]

I maybe would have all of the contract stuff as a git sub-tree or sub-module (Highly encourage sub-tree) so that we are always in sync with these files and are easy to update.

Thanks for the suggestion! I originally thought about using git submodule, but then I just copied the files we needed. But I think it's cleaner if we keep the original structure, so I just added the openzeppelin-contracts repository as a git subtree!

[CPerezz]

I maybe would have all of the contract stuff as a git sub-tree or sub-module (Highly encourage sub-tree) so that we are always in sync with these files and are easy to update.

Thanks for the suggestion! I originally thought about using git submodule, but then I just copied the files we needed. But I think it's cleaner if we keep the original structure, so I just added the openzeppelin-contracts repository as a git subtree!

I would maybe add a README with some instructions/info about the fact that this is a sub-tree, how to update it (in case needed) etc..

WDYT @ed255 ?

[ed255]

I would maybe add a README with some instructions/info about the fact that this is a sub-tree, how to update it (in case needed) etc..

Thanks for the suggestion! I've added a README in 7a0c1d3

[adria0]

@CPerezz @ed255 I think that it will be better if we use gitmodules, mainly because in #382 also needs to import a repo that is really big https://github.com/ethereum/tests, and will be nice to have a unique way to import other sources.

I've been using submodules and works for me, but maybe git sub-tree has some kind of property that makes better to use in this project.

[ed255]

@CPerezz @ed255 I think that it will be better if we use gitmodules, mainly because in #382 also needs to import a repo that is really big https://github.com/ethereum/tests, and will be nice to have a unique way to import other sources.

I've been using submodules and works for me, but maybe git sub-tree has some kind of property that makes better to use in this project.

I would also prefer to switch to submodules. I think it's much cleaner because we're not introducing so many files into our repository, and we just add a pointer to an external repository.
Also this submodule is only used for integration testing which has it's own setup, so most of the people can just not init the submodule and they'll be fine. Only when running the integration test we need the submodule initialized, but the integration test is controlled via a run.sh script so we can automate that.

[CPerezz]

@ed255 @adria0 Makes sense to go on the sub-module way if we don't need to edit any of the files that we will have in the sub-module.

Also, take into account that any changes done in the sub-module will always follow master/HEAD and so we will not be able to change anything if a new addition/modification goes against us.

[ed255]

I've replaced the subtree by a submodule!

@ed255 @adria0 Makes sense to go on the sub-module way if we don't need to edit any of the files that we will have in the sub-module.

Yeah we don't need to edit any file from the external repository. And even if we had to touch some files in there, I'd prefer forking the external repo, doing the edit in the fork, and having a submodule pointing to our fork, just to keep things clean and separated.

Also, take into account that any changes done in the sub-module will always follow master/HEAD and so we will not be able to change anything if a new addition/modification goes against us.

I think that's not the case! When adding a submodule the commit id is stored, so everyone gets the same revision. Updates are manual. See 558141a where the commit id for the openzeppelin-contracts is stored in our repository.