-
Notifications
You must be signed in to change notification settings - Fork 808
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
[EVM] associate via bytes conversion #1706
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1706 +/- ##
==========================================
+ Coverage 60.69% 60.90% +0.20%
==========================================
Files 370 368 -2
Lines 27279 26930 -349
==========================================
- Hits 16558 16402 -156
+ Misses 9585 9433 -152
+ Partials 1136 1095 -41
|
|
||
if err := ante.Preprocess(ctx, evmMsg); err != nil { | ||
return []sdkacltypes.AccessOperation{}, err | ||
} | ||
ops := []sdkacltypes.AccessOperation{} | ||
ops = appendRWBalanceOps(ops, state.GetCoinbaseAddress(ctx.TxIndex())) | ||
sender := evmMsg.Derived.SenderSeiAddr | ||
sender := evmKeeper.GetSeiAddress(ctx, evmMsg.Derived.SenderEVMAddr) |
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.
we should be able to remove this ACLMapping behavior given that parallelv1 is no longer used, its either OCC or synchronous
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.
would these still be used by OCC to guesstimate potential conflicts?
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.
we've disabled that since it didn't show any realistic gains in high conflict scenarios and was only adding latency to happy paths:
https://github.com/sei-protocol/sei-cosmos/blob/8dd4adcf7553c056ee338dabb155bdf03821a99d/tasks/scheduler.go#L291
@@ -46,6 +46,9 @@ override_genesis '.app_state["gov"]["tally_params"]["threshold"]="0.5"' | |||
override_genesis '.app_state["gov"]["tally_params"]["expedited_quorum"]="0.9"' | |||
override_genesis '.app_state["gov"]["tally_params"]["expedited_threshold"]="0.9"' | |||
|
|||
# evm config | |||
override_genesis '.app_state["evm"]["address_associations"]=[{"sei_address":"sei1m9qugvk4h66p6hunfajfg96ysc48zeq4m0d82c","eth_address":"0xF87A299e6bC7bEba58dbBe5a5Aa21d49bCD16D52"},{"sei_address":"sei1cjzphr67dug28rw9ueewrqllmxlqe5f0awulvy","eth_address":"0x70997970C51812dc3A010C7d01b50e0d17dc79C8"}]' |
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.
are these older style of associated addresses for testing coverage?
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
@@ -56,6 +58,54 @@ func NativeSendTxCmd() *cobra.Command { | |||
return cmd | |||
} | |||
|
|||
func SendCastSeiAddrTxCmd() *cobra.Command { |
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 should basically be a no-op right? as in, is this intended solely for testing a self-send? if so how is this different from doing seid tx evm send <cast-addr> <amount> --from admin
?
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.
say admin
's true sei address is seiABC
and true evm address is 0xXYZ
: seid tx evm send <cast-addr> <amount> --from admin
would be an EVM tx with an EVM sig that decodes to the true evm address 0xXYZ
. The direct cast address of it sei(0xXYZ)
doesn't have any fund to send because funds are under seiABC
. This new command is a cosmos tx that sends from seiABC
to sei(0xXYZ)
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.
understood, ty for exaplanation
addressThen := b.keeper.GetSeiAddress(statedb.Ctx(), msg.From) | ||
addressNow := b.keeper.GetSeiAddress(b.ctxProvider(LatestCtxHeight), msg.From) | ||
if !addressThen.Equals(addressNow) { | ||
if err := ante.NewEVMPreprocessDecorator(b.keeper, b.keeper.AccountKeeper()).AssociateAddresses(statedb.Ctx(), addressNow, msg.From, nil); err != nil { |
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.
why are we associating the address with addressNow since now any association is implicit, right? I dont know that I fully understand this edge case, is it where you want to simulate a tx on an old block height prior to this change so previously it would have registered the old style associaton, but because NOW the logic is different, we associate the new correct address instead? If so, I still dont understand why we need to explicitly associate as opposed use the implicit casting?
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 for legacy association created before this change. addressThen
is the sei address before THAT legacy association happened. What we are doing here is basically checking if this tx, back in time, caused a legacy association, and reproduce that if so.
I think the var name might be what's confusing: addressNow
doesn't mean the current way of address association, rather it means the association of the address in the latest DB, and it could be a legacy one
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.
ahh gotcha, yeah the addressNow
name was confusing me
addressThen := b.keeper.GetSeiAddress(statedb.Ctx(), msg.From) | ||
addressNow := b.keeper.GetSeiAddress(b.ctxProvider(LatestCtxHeight), msg.From) | ||
if !addressThen.Equals(addressNow) { | ||
if err := ante.NewEVMPreprocessDecorator(b.keeper, b.keeper.AccountKeeper()).AssociateAddresses(statedb.Ctx(), addressNow, msg.From, nil); err != nil { |
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 don't fully understand this logic, is the intention to allow simulating txs on older blocks where a tx would have associated the old way? I'm not fully understanding the relationship here between oldAddress and newAddress and how its needed here.
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.
see above. An example would be:
- tx T created a legacy association for account 0xXYZ at height 100
- latest height is 200
- when we trace T, we start with the state at height 99
addressThen
here would be the association of 0xXYZ at height 99, which is the direct cast because T hasn't materialized yetaddressNow
here would be the association at height 200, which would be the legacy association as it's set on height 100- since those two are different, we know an address association is set on height 100 (and only a legacy association can cause the difference), so we simulate it here
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.
ty for explanation
addr, ok := k.GetSeiAddress(ctx, evmAddress) | ||
if ok { | ||
return addr | ||
return evmAddress.Bytes() |
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.
do we not need to do something like sdk.AccAddress(evmAddress.Bytes())
?
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.
it's cast implicitly
} | ||
return sdk.AccAddress(evmAddress[:]) | ||
return bz |
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.
same here?
11da3de
to
70b1cfd
Compare
70b1cfd
to
1178979
Compare
1178979
to
cbef8fc
Compare
Describe your changes and provide context
Going forward, we will stop supporting address association based on pubkey derivation, but use direct casting for all accounts who haven't already established pubkey-based association. Existing pubkey-based association will still be respected. Namely the following changes are made:
Testing performed to validate your change
unit tests