-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem: evm contract can't call native module message #45
Conversation
Codecov Report
@@ Coverage Diff @@
## main #45 +/- ##
==========================================
+ Coverage 21.51% 25.64% +4.13%
==========================================
Files 27 29 +2
Lines 1729 1848 +119
==========================================
+ Hits 372 474 +102
- Misses 1324 1337 +13
- Partials 33 37 +4
Continue to review full report at Codecov.
|
x/cronos/keeper/evmhooks.go
Outdated
} | ||
|
||
func (h BankSendHook) PostTxProcessing(ctx sdk.Context, txHash common.Hash, logs []*ethtypes.Log) error { | ||
for _, log := range logs { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could be cleanup a bit to loop only one time
I think instead of creating 2 hooks (for bank and gravity), you can define another interface which implement EventProcessing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, do you mean to register the log processors into sth like: event_id -> processer
? sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the log/event order make a difference? And in some cases a processor may need to handle multiple events?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just pushed a new implementation.
Will the log/event order make a difference? And in some cases a processor may need to handle multiple events?
Currently we only have one handler for one event, if we need to support more, can change the EventID
method to return an array.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where is decimal conversion
10^8 -> 10^18 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#35
that is handled in this PR
Solution: - implement bank and gravity evm hooks update gomod2nix changelog test contract native call comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
constructor() public ERC20("Bitcoin MAX", "MAX") { | ||
_mint(msg.sender, 100000000000000000000000000); | ||
} | ||
|
||
function test_native_transfer(uint amount) public { | ||
emit __CronosNativeTransfer(msg.sender, amount); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't u have to burn the amount?
imo __CronosNativeTransfer
is not clear for the operation. A transfer imply an origin and a destination.
Here it seems that you are either converting or minting?
It seems more that you are con
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is solely for testing the native call, the semantic of the call is to transfer mapped native token from contract address to recipient.
But because we can't setup token mapping in e2e testing right now, so the test itself is not complete yet (there's a TODO in that).
This is not the e2e testing for the complete bridge yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so maybe __CronosCosmosConvert
or __CronosCosmosMint
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so maybe
__CronosCosmosConvert
or__CronosCosmosMint
?
“Native” stands for native token, “Transfer” is also self explanatory I believe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is also self explanatory I believe?
I dont think so..
"Native" has barely any meaning without context. And using "Transfer" without specifying a sender and destination sounds weird.
If we can't find a proper short term to describe the operation, I would prefer to be very explicit and call the event
"__CronosSendFromContractToAccount(receiver, amount)" instead...
Mind that most smart contract developer won't have deep knowledge about the internal implementation, or cosmos implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I think about it again, can we say "From" is implied because the action is "Send" and we are executing a contract? It is the "Subject" (what token) and "To" that's unclear.
So
___CronosSendXToAccount // Account or Native Account? need to address in the terminology issue
___CronosSendXToEthereum // Send X (From the contract account) To Ethereum
___CronosSendXToIBCChannel
// Similar to Gravity Bridge `SendToCosmos` but be more explicit about the token type
p.s. Having "From" is no harm, my motive is if we think event name is too long then we can think about to trim it or not. I am okay to include it and be more explicit. (Is there any restricting on event name length?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I think about it again, can we say "From" is implied because the action is "Send" and we are executing a contract? It is the "Subject" (what token) and "To" that's unclear.
So
___CronosSendXToAccount // Account or Native Account? need to address in the terminology issue ___CronosSendXToEthereum // Send X (From the contract account) To Ethereum ___CronosSendXToIBCChannel // Similar to Gravity Bridge `SendToCosmos` but be more explicit about the token type
p.s. Having "From" is no harm, my motive is if we think event name is too long then we can think about to trim it or not. I am okay to include it and be more explicit. (Is there any restricting on event name length?)
Looks good to me.
And let's use NativeTokens
for X
for now? or Coins
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe 'X' can be omitted now?
__CronosSendToAccount
__CronosSendToEthereum
__CronosSendToIBCChannel
Even if we add NativeToken
or Coins
, it is not clear which coin is it. We need a proper term to designate the "Coin associated with the contract"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe 'X' can be omitted now?
__CronosSendToAccount
__CronosSendToEthereum
__CronosSendToIBCChannelEven if we add
NativeToken
orCoins
, it is not clear which coin is it. We need a proper term to designate the "Coin associated with the contract"
Looks good too, I suppose we'll have detailed documentation about them as part of the CRC20 standard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#62
opened issue and documented decision so far in it.
x/cronos/keeper/evm_log_handlers.go
Outdated
|
||
denom, found := h.cronosKeeper.GetDenomByContract(ctx, contract) | ||
if !found { | ||
return errors.New("contract is not connected to native token") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking if we could wrap add those errors in the ethereum log, it could be nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add the contract address in the error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking if we could wrap add those errors in the ethereum log, it could be nice
I believe that’s the case, the error returned by hook is saved in the return value of the EVM call.
But I need to double check on the rpc response.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/tharsis/ethermint/blob/main/x/evm/keeper/state_transition.go#L198
Hmm, the detailed error won't appear in the response, the RPC user only sees a fixed error string.
But it do get logged in a logfile as an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay I created a new issue for that #61
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except for the event name convention.
Closes #29
Solution:
👮🏻👮🏻👮🏻 !!!! REFERENCE THE PROBLEM YOUR ARE SOLVING IN THE PR TITLE AND DESCRIBE YOUR SOLUTION HERE !!!! DO NOT FORGET !!!! 👮🏻👮🏻👮🏻
PR Checklist:
make
)make test
)go fmt
)golangci-lint run
)go list -json -m all | nancy sleuth
)Thank you for your code, it's appreciated! :)