Problem: not possible to cancel SendToEthereum transactions (fixes #389)

[thomas-nguy]

👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻

Solve this issue #389

PR Checklist:

• Have you read the CONTRIBUTING.md?
• Does your PR follow the C4 patch requirements?
• Have you rebased your work on top of the latest master?
• Have you checked your code compiles? (make)
• Have you included tests for any non-trivial functionality?
• Have you checked your code passes the unit tests? (make test)
• Have you checked your code formatting is correct? (go fmt)
• Have you checked your basic code style is fine? (golangci-lint run)
• If you added any dependencies, have you checked they do not contain any known vulnerabilities? (go list -json -m all | nancy sleuth)
• If your changes affect the client infrastructure, have you run the integration test?
• If your changes affect public APIs, does your PR follow the C4 evolution of public contracts?
• If your code changes public APIs, have you incremented the crate version numbers and documented your changes in the CHANGELOG.md?
• If you are contributing for the first time, please read the agreement in CONTRIBUTING.md now and add a comment to this pull request stating that your PR is in accordance with the Developer's Certificate of Origin.

Thank you for your code, it's appreciated! :)

[codecov]

Codecov Report

Merging #532 (01eae9e) into main (f223294) will increase coverage by 1.92%.
The diff coverage is 79.16%.

@@            Coverage Diff             @@
##             main     #532      +/-   ##
==========================================
+ Coverage   39.91%   41.83%   +1.92%     
==========================================
  Files          30       30              
  Lines        1596     1690      +94     
==========================================
+ Hits          637      707      +70     
- Misses        913      929      +16     
- Partials       46       54       +8     

Impacted Files	Coverage Δ
x/cronos/types/contracts.go	56.00% <20.00%> (-9.00%)	⬇️
x/cronos/keeper/evm_log_handlers.go	82.39% <81.08%> (-2.05%)	⬇️
x/cronos/keeper/evm.go	58.00% <100.00%> (ø)

[thomas-nguy]

Without having to migrate all existing contract, it is possible to create a wrapper over the CRC20 to be able to call __CronosSendToEthereum and have a separate supply from the original CRC20

It would be cleaner to remove send_to_ethereum from the CRC20.sol and remove the _v2 here however this might change the bytecode of the original CRC20 standard (even though nobody is using this method now)

Any opinion @tomtau @yihuang

[yihuang]

Agree with the standard extension, and deprecate the send_to_ethereum from the original one.
But existing contracts still need to migrate code to support the gravity bridge, right?

[thomas-nguy]

another idea is to have a wrapper over exsting CRC20 contract to be able to add the ability to bridge.
For example having ETH_VVS will be a wrapper of VVS.sol and expose send_to_ethereum and wrapping/unwrapping functions
The 1-1 supply control will be guarantee by the smart contract

[tomtau]

I'd suggest documenting these architectural decisions: https://github.com/crypto-org-chain/cronos/blob/main/docs/architecture/adr-template.md + getting some feedback from dApp developers on it

[yihuang]

another idea is to have a wrapper over exsting CRC20 contract to be able to add the ability to bridge. For example having ETH_VVS will be a wrapper of VVS.sol and expose send_to_ethereum and wrapping/unwrapping functions The 1-1 supply control will be guarantee by the smart contract

it's still a contract migration, the client need to use a different contract address, but internally it reuse the old contract to avoid state migration, right?
I think dapps could have multiple solutions to do this, sometimes even have the upgradability build-in.

[thomas-nguy]

the client need to use a different contract address, but internally it reuse the old contract to avoid state migration

Why does it need to use old contract? Mapping between gravitydenom <-> contract address will be done on the wrapped contract.
The drawback is that to be able to send to ethereum, one needs to wrap its token first (or unwrap for the opposite direction) but that can be integrated seeminglessly by the Dapp

[yihuang]

I see, you mean a 1-to-1 token wrapping contract, I guess for erc20, user will need to do a) approve, b) swap, c) send_to_ethereum, right?

[yihuang]

LGTM in general, only some minor suggestions.

[thomas-nguy]

client/docs/statik/statik.go

this is modified after running gofmt -s -w .

[yihuang]

LGTM