Previously, we weren't checking the "to" address. I've also re-ordered
the operations in this function to make it easier to reason about them.
It'll have a slight runtime cost (we _always_ ABI-encode the parameters,
then throw away the result if it turns out we're actually dealing with
an Ethereum transaction), but it's _much_ simpler.
Correctly handle "unresolvable" to/from addresses in top-level messages in the Ethereum API. Specifically:
1. Fail if we can't resolve the from address. As far as I can tell, this should be impossible (the message statically couldn't have been included in the block if the sender didn't exist).
2. If we can't resolve the "to" address to an ID, use "max uint64" as the ID (`0xff0000000000000000000000ffffffffffffffff`). This will only happen if the transaction was reverted. It'll be a little confusing, but the alternative is to (a) use an empty address (will look like a contract creation, which is definitely wrong) or (b) use a random/hashed address which will likely be more confusing as it won't be "obviously weird".
When translating "native" messages to Ethereum transactions, correctly handle parameters:
1. If the message looks like a valid "create external", treat it as a contract creation.
2. If it looks like a valid EVM invocation, decode it as such.
3. Otherwise, ABI-encode the parameters to make them look like a "handle_filecoin_method" call. This
will help chain explorers recognize these messages.
Part of #11355
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
We added this check as a self-test to make sure that the message indices
in our trace matched up with those in the block. Unfortunately, this
only works for blocks on the main-chain, and breaks tracing of uncle
blocks (and tracing of head).
* chore: eth: move & rename input/output encoding functions
These are shared functions, so I'm moving them to the utils library.
* fix: eth: correctly encode and simplify native input/output encoding
When generating eth traces, we encode "native" message inputs/outputs
to "solidity ABI" by formatting the inputs/outputs the same way we do in
FEVM's "handle_native_method". However, we had quite a few bugs with the
implementation:
1. We were right-aligning 64bit values in 256bit words, instead of
left-aligning (as we should given that these values are big-endian).
2. The return-value encoding wasn't correctly handling lengths.
This patch:
1. Fixes those bugs.
2. Deduplicates the logic (we're doing _basically_ the same thing in
both cases).
3. Removes all error paths (these functions can't fail).
We were computing this based on the max block gas, but this is
incorrect. The new value isn't entirely correct either (we should
probably compute an average of the gas used in each block in the
tipset?), but it's good enough.
fixes#10515
All these cases here are actually errors and returning `nil` makes this
hard to debug. We likely returned nil in the past to be "best effort"
but, as far as I can tell, we should only hit these error cases if
something is actually wrong.
part of #11325
After changing in prev commit to use to ethereum addresses the
comparison does not make sense against builtin actors. This
fixes that by storing also the filecoin addresses in each trace
Also renamed filecoin related fields to Filecoin prefix.
Also remove requirement call to InvokeContract needed to come
from a evm actor
Introduce nv21 skeleton for local testing:
- Use local go-state-types with actor_version_checklist changes: https://github.com/filecoin-project/go-state-types/blob/master/actors_version_checklist.md
- Imports mock v12-actors bundle
- Define upgrade heights
- Generate adapters
- Add upgrade schedule and migration
- Add actorstype to the NewActorRegistry in /chain/consensus/computestate.go
- Add upgrade field to api/types.go/ForkUpgradeParams
- Add upgrade to node/impl/full/state.go
- Add network version to chain/state/statetree.go
- make jen
- make docsgen-cli
Fixes: #10814
This PR updates the following RPC methods according to EIP-1898
specs.
The following RPC methods are affected:
- eth_getBalance
- eth_getStorageAt
- eth_getTransactionCount
- eth_getCode
- eth_call
Note that eth_getBlockByNumber was not included in this list in
the spec although it seems it should be affected also?
Currently these methods all accept a blkParam string which can be
one of "latest", "earliest", "pending", or a block number (decimal
or hex). The spec enables caller to additionally specify a json
hash which can include the following fields:
- blockNumber EthUint64: A block number (decimal or hex) which is
similar to the original use of the blkParam string
- blockHash EthHash: The block hash
- requireCanonical bool) If true we should make sure the block is
in the canonical chain
Since the blkParam needs to support both being a number/string and
a json hash then this to properly work we need to introduce a new
struct with pointer fields to check if they exist. This is done
in the EthBlockParamByNumberOrHash struct which first tries to
unmarshal as a json hash (according to eip-1898) and then fallback
to unmarshal as string/number.
