This will re-execute tipsets to forcibly re-compute and store events
when they're missing. This is effectively lazy backfilling of events.
NOTE: This _won't_ backfill the index itself, it'll just give us the
events.
fixes#11335
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).
