Skip to content
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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Conversation

stevenlanders
Copy link
Contributor

@stevenlanders stevenlanders commented May 29, 2024

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:

  • the address lookup functions will resort to direct casting if no association is found in db
  • AssociateTx type is removed
  • No pubkey-based association will be established for either EVM txs or Cosmos txs
  • No association will be set for new EVM code
  • Legacy association logic is still supported in trace endpoints

Testing performed to validate your change

unit tests

x/evm/keeper/address.go Outdated Show resolved Hide resolved
@codchen codchen marked this pull request as ready for review May 30, 2024 06:09
Copy link

codecov bot commented May 30, 2024

Codecov Report

Attention: Patch coverage is 76.66667% with 28 lines in your changes are missing coverage. Please review.

Project coverage is 60.90%. Comparing base (1702e4e) to head (cbef8fc).

Additional details and impacted files

Impacted file tree graph

@@            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     
Files Coverage Δ
aclmapping/evm/mappings.go 92.17% <100.00%> (+3.09%) ⬆️
app/antedecorators/gasless.go 83.45% <ø> (+5.28%) ⬆️
evmrpc/association.go 58.33% <100.00%> (+27.49%) ⬆️
evmrpc/server.go 86.61% <100.00%> (ø)
precompiles/bank/bank.go 58.09% <100.00%> (+1.41%) ⬆️
precompiles/distribution/distribution.go 52.47% <100.00%> (+3.82%) ⬆️
precompiles/gov/gov.go 55.78% <100.00%> (+3.31%) ⬆️
precompiles/staking/staking.go 67.69% <100.00%> (+4.38%) ⬆️
precompiles/wasmd/wasmd.go 63.80% <100.00%> (+1.93%) ⬆️
x/evm/ante/error.go 100.00% <ø> (ø)
... and 21 more

... and 3 files with indirect coverage changes

@stevenlanders stevenlanders changed the title [POC] associate via bytes conversion [EVM] associate via bytes conversion May 30, 2024

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)
Copy link
Collaborator

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

Copy link
Collaborator

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?

Copy link
Collaborator

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"}]'
Copy link
Collaborator

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?

Copy link
Collaborator

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 {
Copy link
Collaborator

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?

Copy link
Collaborator

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)

Copy link
Collaborator

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 {
Copy link
Collaborator

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?

Copy link
Collaborator

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

Copy link
Collaborator

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 {
Copy link
Collaborator

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.

Copy link
Collaborator

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 yet
  • addressNow 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

Copy link
Collaborator

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()
Copy link
Collaborator

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())?

Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants