Token duality

[karlb]

To make token duality work, I needed to add the following things first:

• CeloPrecompiledContract (transfer precompile needs the access to the BlockContext)
• A way to make contract calls during block processing (transfer precompile needs to check the goldTokenAddress in the registry)
• Include the registry in the genesis block (We can't get it into the correct address later)

There are multiple ways to do all of these, so this review is a good place to discuss if I chose a good one or not.

I tried to avoid a few things:

• The SharedEVMRunner which is used for checking the goldTokenAddress in celo-blockchain. It has multiple "DO NOT USE" warnings and reuses EVM objects which are supposed to be single use objects
• Adding custom contract wrappers. I wanted to use abigen, since that is what is used everywhere else. To make that work, I added the CeloBackend (better names welcome!)

To keep rebasing to newer upstream versions, I put most of the new code into celo_ prefixed go files. Only adding the CeloPrecompiledContract required larger changes in the original code.

Part of #1

[palango]

This looks really good, especially nice that you managed to get rid of the SharedEVMRunner. Also really the nice sequence of commits makes it easy to follow through the PR.

• Currently you copied over the contract ABIs by hand, right? So how to get/generate those is still an open question.
• Some test data functions seem to be duplicated (in core/vm/celo_contracts_test.go and tests/fuzzers/bls12381/precompile_fuzzer.go)
• Left some smaller comments/questions inline.
• It's unfortunate that we have to adjust all existing precompiles that don't need state access. I don't see an obvious way to avoid that though (without using reflection, which we probably want to avoid)

[karlb]

Currently you copied over the contract ABIs by hand, right? So how to get/generate those is still an open question.

Yes. I currently imagine something like a small script doing forge build in the optimism repo and the extracting the keys from the build artefacts into the right places. Could even be run by a go:generate line. But we need the contracts in the optimism repo before we can try out anything like that.

Some test data functions seem to be duplicated (in core/vm/celo_contracts_test.go and tests/fuzzers/bls12381/precompile_fuzzer.go)

Well spotted, I didn't realize this. It is the same in celo-blockchain at the moment and I am not sure how to best resolve this. We could move the shared code to a test utils package, but that would increase the diff for tests/fuzzers/bls12381/precompile_fuzzer.go. It is not clear whether that is better than the duplication.

[karlb]

Any idea on whether this is ok? I'm especially unsure about the vmConfig.

[palango]

I was also wondering if we can somehow get the config used from somewhere else.

But it seems simple enough, the only thing I don't understand is Config.EnablePreimageRecording.

[karlb]

It's unfortunate that we have to adjust all existing precompiles that don't need state access. I don't see an obvious way to avoid that though (without using reflection, which we probably want to avoid)

A different approach would be to keep separate precompile lists for CeloPrecompileContracts and normal PrecompileContracts. So instead of 1d67728, we could do 76c68b9, which results in a smaller diff.

> git show 1d67728a2c4fb73aa8b14c700dd66f7a6f7d6f11 --stat
 common/celo_types.go      |  5 +++++
 core/vm/celo_contracts.go | 41 +++++++++++++++++++++++++++++++++++++++++
 core/vm/celo_errors.go    |  9 +++++++++
 core/vm/contracts.go      | 92 ++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------
 core/vm/evm.go            | 12 ++++++------
 5 files changed, 107 insertions(+), 52 deletions(-)

> git show 76c68b93bde3b176aff2df80a012fb22cbba426e --stat
 common/celo_types.go      |  5 +++++
 core/vm/celo_contracts.go | 41 +++++++++++++++++++++++++++++++++++++++++
 core/vm/celo_errors.go    |  9 +++++++++
 core/vm/contracts.go      |  8 ++++++--
 core/vm/evm.go            | 23 +++++++++++++++++------
 5 files changed, 78 insertions(+), 8 deletions(-)

[karlb]

Currently you copied over the contract ABIs by hand, right? So how to get/generate those is still an open question.

I added a script to build and update the contracts from the optimism repo.

I also switched to the version using a separate CeloPrecompileContracts list to reduce the amount of wrapping existing precompiles, as mentioned in the previous comment.

[palango]

Maybe add a todo here or create a new issue so we don't forget to update that.

[palango]

Currently you copied over the contract ABIs by hand, right? So how to get/generate those is still an open question.

I added a script to build and update the contracts from the optimism repo.

I also switched to the version using a separate CeloPrecompileContracts list to reduce the amount of wrapping existing precompiles, as mentioned in the previous comment.

I like that change. I think it makes it clearer what happens and allows us to not change all existing precompiles.

[palango]

Looks good!