fix: eth: use the correct state-tree when resolving addresses #11387
Conversation
|
Based on #11385, merge that first. |
| tx, err := ethtypes.EthTxFromSignedEthMessage(smsg) | ||
| if err != nil { | ||
| return ethtypes.EmptyEthHash, err | ||
| return ethtypes.EthHash{}, xerrors.Errorf("failed to convert from signed message: %w", err) | ||
| } | ||
| return ethTx.Hash, nil | ||
|
|
||
| return tx.TxHash() |
There was a problem hiding this comment.
This does the same thing as the old code, this new code just makes it clear that there's no state access.
| @@ -84,13 +85,18 @@ func (m *EthTxHashManager) ProcessSignedMessage(ctx context.Context, msg *types. | |||
| return | |||
| } | |||
|
|
|||
| ethTx, err := newEthTxFromSignedMessage(ctx, msg, m.StateAPI) | |||
| ethTx, err := ethtypes.EthTxFromSignedEthMessage(msg) | |||
There was a problem hiding this comment.
Again, I'm just removing the state access (this is always a message from an EthAccount, so we never need to look at the state to resolve addresses).
Stebalien
force-pushed
the
steb/fix-eth-addr-lookup
branch
from
17bd1f9 to
1802f3f
Compare
| return ethtypes.EthTx{}, xerrors.Errorf("failed to resolve Ethereum address: %w", err) | ||
| } | ||
|
|
||
| tx.From = fromAddr |
There was a problem hiding this comment.
This should be fine I guess since we are now setting From inside ethtypes.EthTxFromSignedEthMessage
There was a problem hiding this comment.
Yeah, that was the idea.
|
|
||
| err = m.TransactionHashLookup.UpsertHash(ethTx.Hash, msg.Cid()) | ||
| err = m.TransactionHashLookup.UpsertHash(txHash, msg.Cid()) |
There was a problem hiding this comment.
Were we inserting the wrong hash into eth_tx_hashes?
There was a problem hiding this comment.
No, I'm just refactoring this to make it clear that it doesn't access any state.
We need to always use the state-tree from the tipset _after_ the message executed. If we use any other state-tree, we might not find the address we're trying to resolve. This change also has some implication for pending messages: there's no guarantee we'll be able to generate a 0x-style address for a pending native message. So, instead of trying, I've removed support for pending native messages from the Eth API. Messages from EthAccounts will still work, and native messages will still show up in blocks/traces, they just won't show up as "pending". Which should affect exactly nobody. I'm also taking this opportunity to cleanup some edge-cases: 1. Pass contexts where appropriate. 2. Remove all state access from `ethTxHashFromSignedMessage`. Part of #11355
Stebalien
force-pushed
the
steb/fix-eth-addr-lookup
branch
from
9f9990f to
c0c3614
Compare
Related Issues
Part of #11355
Proposed Changes
We need to always use the state-tree from the tipset after the message executed (i.e., the state-tree produced by executing the tipset). If we use any other state-tree, we might not find the address we're trying to resolve.
This change also has some implication for pending messages: there's no guarantee we'll be able to generate a 0x-style address for a pending native message. So, instead of trying, I've removed support for pending native messages from the Eth API. Messages from EthAccounts will still work, and native messages will still show up in blocks/traces, they just won't show up as "pending". Which should affect exactly nobody.
I'm also taking this opportunity to cleanup some edge-cases:
ethTxHashFromSignedMessage.Checklist
Before you mark the PR ready for review, please make sure that:
<PR type>: <area>: <change being made>fix: mempool: Introduce a cache for valid signaturesPR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, testarea, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps