refactor!: Using the MsgEthereumTx interface in the rpc module#854
refactor!: Using the MsgEthereumTx interface in the rpc module#854nowooj wants to merge 9 commits into
Conversation
|
@nowooj a few conflicts here |
| @@ -27,7 +27,7 @@ func (d TxListenerDecorator) AnteHandle(ctx sdk.Context, tx sdk.Tx, simulate boo | |||
| if ctx.IsCheckTx() && !simulate && d.pendingTxListener != nil { | |||
| for _, msg := range tx.GetMsgs() { | |||
| if ethTx, ok := msg.(*evmtypes.MsgEthereumTx); ok { | |||
There was a problem hiding this comment.
Why are we leaving some *evmtypes.MsgEthereumTx as pointers instead of the interface?
There was a problem hiding this comment.
I thought that newly execute tx, for example tx coming through ante handler or mempool, would always use the latest evmtypes.MsgEthereumTx
a1d6fed to
3da79d3
Compare
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days-before-close if no further activity occurs. |
45c9e3f to
4c48768
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #854 +/- ##
==========================================
+ Coverage 63.24% 65.80% +2.55%
==========================================
Files 332 332
Lines 23969 23743 -226
==========================================
+ Hits 15160 15624 +464
+ Misses 7173 6951 -222
+ Partials 1636 1168 -468
🚀 New features to boost your workflow:
|
|
@greptile review |
Greptile SummaryThis PR introduces a new
Confidence Score: 3/5Not safe to merge as-is due to a potential runtime panic and an inverted architectural dependency. Two P1 findings: a runtime panic risk from
Important Files Changed
|
| if ethMsg.Raw.To() == nil { | ||
| contractAddress = crypto.CreateAddress(ethMsg.GetSender(), ethMsg.Raw.Nonce()) | ||
| if tx.To() == nil { | ||
| contractAddress = crypto.CreateAddress(common.Address(ethMsg.GetFrom().Bytes()), tx.Nonce()) |
There was a problem hiding this comment.
Unsafe slice-to-array conversion may panic
common.Address(ethMsg.GetFrom().Bytes()) is a Go 1.20 slice-to-array conversion that panics at runtime if len(GetFrom().Bytes()) < 20. While msg.From is normally 20 bytes, an uninitialized or malformed message (e.g., msg.From == nil) will cause a nil-dereference / bounds panic here, whereas the old ethMsg.GetSender() would safely return a zero address. Since GetSender() is not part of IMsgEthereumTx, use the safe helper instead:
| contractAddress = crypto.CreateAddress(common.Address(ethMsg.GetFrom().Bytes()), tx.Nonce()) | |
| contractAddress = crypto.CreateAddress(common.BytesToAddress(ethMsg.GetFrom().Bytes()), tx.Nonce()) |
| protov2 "google.golang.org/protobuf/proto" | ||
|
|
||
| evmapi "github.com/cosmos/evm/api/cosmos/evm/vm/v1" | ||
| "github.com/cosmos/evm/rpc/types/interfaces" |
There was a problem hiding this comment.
Inverted dependency: core domain imports RPC layer
x/vm/types (core domain) now imports rpc/types/interfaces (API/RPC layer). This inverts the normal layering direction — RPC packages should depend on domain types, not the reverse. Any consumer that uses x/vm/types without the RPC stack will now transitively pull in the entire rpc/types/interfaces package. The interface definition should live in a neutral package (e.g. inside x/vm/types itself, or a standalone types/interfaces under the vm module) so the domain layer stays independent of the RPC layer.
| type IMsgEthereumTx interface { | ||
| FromEthereumTx(tx *ethtypes.Transaction) | ||
| FromSignedEthereumTx(tx *ethtypes.Transaction, signer ethtypes.Signer) error | ||
| GetFrom() sdk.AccAddress | ||
| GetGas() uint64 | ||
| GetEffectiveFee(baseFee *big.Int) *big.Int | ||
| AsTransaction() *ethtypes.Transaction | ||
| GetSenderLegacy(signer ethtypes.Signer) (common.Address, error) | ||
| AsMessage(baseFee *big.Int) *core.Message | ||
| UnmarshalBinary(b []byte, signer ethtypes.Signer) error | ||
| } |
There was a problem hiding this comment.
Interface includes unused mutating methods
FromEthereumTx, FromSignedEthereumTx, and UnmarshalBinary are construction/mutation methods. None of the consumers in the rpc module (query paths in comet_to_eth.go, tx_info.go, utils.go, events.go) ever call these methods via the interface — they only call AsTransaction(), GetFrom(), GetGas(), and GetSenderLegacy(). Including write methods in a read-oriented query interface violates the Interface Segregation Principle, makes it harder to satisfy the interface with a read-only wrapper, and leaks implementation concerns into the abstraction.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
fix: remove Hash() func for backward compatibility
4c48768 to
cfab9c8
Compare
aljo242
left a comment
There was a problem hiding this comment.
ci has not run: fork pr, all workflows action_required. also 34 commits behind main.
Hash() removal is a bundled breaking change: the pr description acknowledges this was kept for ethermint backward compat. removing it breaks any downstream calling .Hash() directly on *MsgEthereumTx. move this to a separate pr with an explicit changelog entry.
undocumented behavioral change in contract address derivation: comet_to_eth.go:299 changes ethMsg.GetSender() (recovered from signature) to ethMsg.GetFrom() (stored field). these should be equivalent for well-formed txs, but the difference isn't documented and could silently produce wrong contract addresses for edge cases. needs a comment or test confirming equivalence.
GetSenderLegacy in interface but unused: no call site in this diff uses it through the interface -- either document why it's required or remove it.
@aljo242 Thanks, addressed the actionable parts.
|
Description
This code doesn't cover all MsgEthereumTx implementations within the rpc module, but it does cover the query part. This code can be expanded and structured into a completely independent code structure.
Removing Hash() hasn't important to do with the PR, but it was added for backward compatibility since ethermint uses Hash as a variable.
Closes: #853
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
mainbranch