- Pulls in the latest version of `kubo-api-client` (extracted from kubo
0.27.0).
- Update go-libp2p to v0.33.0
- Update boxo to v0.18.0
- Update go-graphsync to v0.16.0
Now that 1.22 is out. Libp2p will also be dropping support for 1.20
soon (if it hasn't already?) so it can _finally_ stop supporting
specific compiler versions (we can stop caring so much about the
"maximum" supported go version).
Also explicitly limit how many bytes we're willing to read in one go
such that we're capable of reading a worst-case tipset (like, really,
never going to happen worst-case). Previously, this wasn't an issue.
However, we've bumped the max number of messages from 8,192 to 150,000
and need to limit allocations somewhere else.
Also explicitly limit how many bytes we're willing to read in one go
such that we're capable of reading a worst-case tipset (like, really,
never going to happen worst-case). Previously, this wasn't an issue.
However, we've bumped the max number of messages from 8,192 to 150,000
and need to limit allocations somewhere else.
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".
In #11212, we added the necessary logic to download the params
automatically. However, we're not taking advantage of CI caching.
Here, we configure CI to cache these params.
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
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
1. Implement a pass-through for garbage collection on the idstore.
2. Fix the `lotus-shed state-prune` command.
NOTE: the new performance of running a full prune will be significantly
less as this version doesn't batch. However, it should now actually
_work_ and most users will be using the splitstore anyways.
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
Update the test-vectors repo to the "last" release. This release deletes
most of the code (that depended on an ancient version of lotus anyways)
as we now rely on the "fvm" test vectors for all but historical tests.
Unfortunately, we can't _yet_ merge the schema branch. But we will in a
moment. But this at least fixes go-state-types
These dependencies were based on branches which no longer exist.
1. Switch to go-multicodec as the source of multicodec code information.
This gives us a central, generated source of multicodec codes.
2. Use this library inside the VM and shapshot logic to consistently
allow CBOR, in addition to DagCBOR.
3. Remove the hard-coded CBOR constant.
- Updates to wasmtime 10.
- Unifies some dependencies between fvm v2 and v3 (slightly smaller
binary).
- Supports instance pool oversubscription when FVM concurrency is
enabled. This should allow users to specify high concurrency values
without running out of address space.
Previously, we'd use the current head if not otherwise specified, even
when the user specified a epoch. Now:
1. If the user specifies nothing, we use head head's epoch.
2. If the user specifies a tipset and no epoch, we use that tipset and
the epoch of that tipset.
3. If the user specifies an epoch and no tipset, use the tipset at that
epoch (based on the current head).
4. Finally, if the user species both, use both (allowing the
epoch/tipset to disagree).
This fixes the flakyness by:
1. Disconnecting the client from the miner before submitting the
message. That way, we force it to get stuck in the message pool.
2. Removing the logic that asks lotus for the "latest" block. We have
other tests that exercise "latest".
fixes#10824
This reverts commit 8b2208fd9a, reversing
changes made to 2db6b12b78.
Unfortunately, this is rather tricky code. We've found several issues so
far and, while we've fixed a few, there are outstanding issues that
would require complex fixes we don't have time to tackle right now.
Luckily, this code isn't actually needed by the main Filecoin chain
which relies on consensus fault reporting to handle equivocation. So we
can just try again later.
- Increase epoch times to give the miners a chance to see each other's
blocks.
- Wait longer for a multi-block tipset.
- Reduce the initial wait (we're increasing the block times and I don't
really feel like waiting around).
* fix: sync: fail sync instead of logging if we sync the wrong chain
* fix: sync: write headers in the correct order
Just in case. This shouldn't be necessary, but we might as well.
* fix: minus minus
* fix: do put the tipset
Put != Persist
And fix the message to account for the fact that we now reject _old_
blocks along with new ones.
We frequently receive "out of date" blocks in hello messages from
syncing and/or out of sync nodes. This isn't an error.
This will reject blocks in pubsub validation if they're either:
1. Too far into the future (5 blocks beyond the expected head).
2. Too far into the past (before finality with respect to our current
head).
Specifically:
1. We were previously rejecting future blocks in the sync logic, but not
in pubsub itself.
2. We never used to check if a block was too _old_.
Motivation: Blocks that are too new/too old can cause us to perform
quite a bit of unnecessary work.
The function/parameter were poorly named and should never have been
exposed. "GC" confidence should always be the same, this parameter
doesn't let us actually set the _confidence_, just the point before
which we no longer support reverts.
fixes#10706
Technically, the block validator caught this panic. But it's pointless
because we have a _real_ mechanism to return the validation reason,
which we should have been using.
In general, panicing like this is a very bad idea because it's
non-obvious and, in this case, completely undocumented.
Conditions always call "unlock" so we can't safely use the condition
with both the read and write side of lock. So we might as well revert
back to a regular lock.
fixes#10616
This is now "FVM" native. Changes include:
1. Don't treat "trace" messages like off-chain messages. E.g., don't
include CIDs, versions, etc.
2. Include IPLD codecs where applicable.
3. Remove fields that aren't filled by the FVM (timing, some errors,
code locations, etc.).
This change:
1. Introduces new "limited" API endpoints for EthGetTransactionByHash
and EthGetTransactionReceipt that accept lookback-limits.
2. Implements the gateway version of these API endpoints by calling the
limited variants with the default message search lookback limit.
fixes#10412
Instead:
1. Use the receipt from the message search.
2. Re-compute the gas fees that would have been charged.
fixes#10418
Co-authored-by: raulk <raul.kripalani@gmail.com>
Now that this API is _much_ faster, we're more likely to "catch up" to
the head faster than it can stabilize. I'm pretty sure the test was
intended to be written this way anyways.
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.
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
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
This is now "FVM" native. Changes include:
1. Don't treat "trace" messages like off-chain messages. E.g., don't
include CIDs, versions, etc.
2. Include IPLD codecs where applicable.
3. Remove fields that aren't filled by the FVM (timing, some errors,
code locations, etc.).
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).
Unfortunately, we need to execute the message twice to get this (unless
we want to change some APIs). But it's unlikely to be a performance
issue and will definitely help people debug failures.
* fix: eth: correctly decode EthGetStorageAt output
We cbor-encode it. Also:
1. Actually use the passed block param.
2. Check if the target actor is an EVM actor to avoid nonsense outputs.
fixes https://github.com/filecoin-project/ref-fvm/issues/1621
Otherwise we may, e.g., try to estimate gas on a message to an f4
address before the nv18 migration.
I'm _not_ checking the "prior messages" here as this is just a sanity
check.
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).
* fix: stmgr: make the tipset and height agree when estimating gas
Specifically re-execute all messages in the current tipset, tacking the new
message onto the end. That way, the epoch is the epoch of the current tipset.
We could try to "make" a fake block and use that, but that's unlikely to
work well.
* fix: stmgr: only apply tipset messages for CallWithGas
* fix: itest: window post dispute
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.
Steven Allen
