* changelog for trace_transaction
* adding boilerplate for trace_transaction to /api/
* add eth trace transaction proxy and mock api
* trace tx boilerplate
* trace transaction implementation - under construction
* fix types for eth trace transaction
* trace_transaction implemented
* golint and handle transaction not found
* gofmt
* ran make docsgen
* pointer bugfix and make docsgen
* tx.BlockNumber is nil when the transaction is still in the mpool/pending and there is no trace for pending transactions
* check eth trace transaction happy case and two error cases - tx not found and tx pending in itests
* simplify error msg check for gh action fail
---------
Co-authored-by: Michael Seiler <michaelseiler@Michaels-Laptop.local>
* poc for eth legacy tx
* print statements
* finished
* tests work
* remove print statements
* Remove all print statements
* remove extraneous changes
* cleaned up code and interface
* run make jen
* dont duplicate signature
* go mod tidy and remove prints
* clean up tests
* test for conversion
* changes as per review
* more unit tests for legacy txns
* Apply suggestions from code review
Co-authored-by: Rod Vagg <rod@vagg.org>
* address review comments from Rodd
* changes as per zen's 2nd review
* go mod tidy
* feat: ETH compatibility in Filecoin : Support EIP-155 Ethereum transactions in Filecoin (#11970)
* itests passing for 155 tx
* first working version for EIP-155 transactions
* green itest
* add docs
* tests
* remove print stmt
* remove print stmt
* validate signature
* changes as per zen's review
* correct signature verification
* gate tx by Network Version
* handle arajsek review
* fix imports order
* fix lint
* dont lock in mpool for network gating ETH messages
* sender can be an ID address
---------
Co-authored-by: Rod Vagg <rod@vagg.org>
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
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.
