The correct name for this field is 'input' according to the Ethereum specs [0].
However, for the longest time, clients have been using 'data' and servers have been
lenient to accept both, preferring 'input' over 'data' when both appear.
Our lack of support for 'input' had gone unnoticed until go-ethereum decided
to adjust their ethclient implementation to issue eth_call and eth_estimateGas
requests with the 'input' field instead of 'data' [1]. This suddenly broke apps
using this client against Lotus' Eth API.
[0]: https://github.com/ethereum/execution-apis/blob/main/src/schemas/transaction.yaml#L33-L35
[1]: ethereum/go-ethereum#28078
Co-authored-by: raulk <raul.kripalani@gmail.com>
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
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
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.
We'll never get an actor/account deployed to one of these
addresses (although we might get a placeholder). However, converting
such an address to an f4 address is definitely wrong.
This will make `lotus send` mostly just "do what the user wants" in this
case:
1. The user may not explicitly specify a method number.
2. Parameters are automatically cbor-encoded where applicable.
3. The method number is automatically selected based on the
recipient (CreateExternal if sent to the EAM, InvokeEVM otherwise).
1. We do allow deploying with empty initcode.
2. Make sure that the encoded "code" is non-empty, if specified.
Basically, this makes everything consistent (and it's how I specified it
in the FIP).
We now enforce the following rules:
1. No duplicate topics or data.
2. Topics must have 32 byte keys.
3. Topics may not be skipped. (e.g., no t1 & t3 without a t2).
4. Raw codecs.
We _don't_ require that topics/data be emitted in any specific order.
We _skip_ events with unknown keys. We _drop_ events that violate the
above rules.
- Event keys are now t1, t2, t3, t4 for topics; and d for data.
- ref-fvm no longer stores events in the blockstore for us. It just
returns events to the client, who is now responsible for handling
them as it wishes / according to its configuration.
- Add a flag to VMOpts to have the events AMT be written in the blockstore.
- Add a flag to the ChainStore to advertise to the rest of the system
if the ChainStore is storing events.
- Enable that flag if the EthRPC is enabled (can also add an explicit
configuration flag if wanted).
* Refactor: Unify EthTx to FilecoinMessage methods
* Filecoin messages can again be converted to Eth Txs
* All BLS messages should calculated tx hash with unsigned message
* Refactor newEthTxReceipt
* fill in from and to for non-eth transactions
* Hoist nil check out of newEthTxFromMessageLookup
---------
Co-authored-by: Aayush <arajasek94@gmail.com>
Co-authored-by: Raúl Kripalani <raul@protocol.ai>
