* 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>
* release the read lock earlier as it is not needed for chaincomputebasefee
* chain/messagepool/selection.go change to read lock in SelectMessages
* tighten up locks in chain/messagepool/repub.go and two questions on whether curTsLks are needed as comments
* include suggestion from @Jorropo to preallocate our msgs array so that we only need to make a single allocation
* mp.pending should not be accessed directly but through the getter
* from @arajasek: just check whether the sender is a robust address (anything except an ID address is robust) here, and return if so. That will:
be faster
reduce the size of this cache by half, because we can drop mp.keyCache.Add(ka, ka) on line 491.
* do not need curTslk and clean up code comments
We have observed that EthGetTransactionCount is one of the hotspots
on Glif production notes, and we are seeing regular 10-20 second
latencies when calling this rpc method.
I tracked the high latency spikes and they were correlated when
we were running ExecuteTipSet while following the chain.
To address this, we should not rely on tipset computation to get
nounce and instead look at the parent tipset and then count the
messages sent from the 'addr'.
However, we're leaving the default at 1.25x for backwards compatibility, for now.
Also:
1. Actually use the configured replace fee ratio.
2. Store said ratios as percentages instead of floats. 1.25, or 1+1/(2^2),
can be represented as a float. 1.1, or 1 + 1/(2 * 5), cannot.
fixes#10415
