* refactor: make GetEmbeddedBuiltinActorsBundle take network bundle name
* update calibnet actor bundle to v12.0.0-rc.2, but include v12.0.0-rc.1 as calibrationnet-buggy.car
* wip: calibnet unbork migration
* calibnet: add buggy miner actor CID to actorMeta
* fix incorrect buggy calibnet manifest
* make UpgradeWatermelonFixHeight a build param
* calibnet patch: check whether network is calibration from init actor state
* add sanity checks to the v12 calibnet patch upgrade
* address review
* refactor: make GetEmbeddedBuiltinActorsBundle take network bundle name
* update calibnet actor bundle to v12.0.0-rc.2, but include v12.0.0-rc.1 as calibrationnet-buggy.car
* wip: calibnet unbork migration
* calibnet: add buggy miner actor CID to actorMeta
* fix incorrect buggy calibnet manifest
* make UpgradeWatermelonFixHeight a build param
* calibnet patch: check whether network is calibration from init actor state
* add sanity checks to the v12 calibnet patch upgrade
* address review
* refactor: make GetEmbeddedBuiltinActorsBundle take network bundle name
* update calibnet actor bundle to v12.0.0-rc.2, but include v12.0.0-rc.1 as calibrationnet-buggy.car
* wip: calibnet unbork migration
* calibnet: add buggy miner actor CID to actorMeta
* fix incorrect buggy calibnet manifest
* make UpgradeWatermelonFixHeight a build param
* calibnet patch: check whether network is calibration from init actor state
* add sanity checks to the v12 calibnet patch upgrade
* address review
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
The sequence number used for replay detection was being updated before message validation confirmed that the message originated from the correct host. This would allow one host A to create a message with the ID of another host B that could then update the cached sequence number for B. While the message from A would fail validation and be ignored, the cached sequence number for B would get updated. This would lead to a temporary DoS for host B as its messages were incorrectly rejected as replays.
This fixes the issue by setting the cached sequence number after message validation.
Introduce nv21 skeleton for local testing:
- Use local go-state-types with actor_version_checklist changes: https://github.com/filecoin-project/go-state-types/blob/master/actors_version_checklist.md
- Imports mock v12-actors bundle
- Define upgrade heights
- Generate adapters
- Add upgrade schedule and migration
- Add actorstype to the NewActorRegistry in /chain/consensus/computestate.go
- Add upgrade field to api/types.go/ForkUpgradeParams
- Add upgrade to node/impl/full/state.go
- Add network version to chain/state/statetree.go
- make jen
- make docsgen-cli
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.
Introduce nv21 skeleton for local testing:
- Use local go-state-types with actor_version_checklist changes: https://github.com/filecoin-project/go-state-types/blob/master/actors_version_checklist.md
- Imports mock v12-actors bundle
- Define upgrade heights
- Generate adapters
- Add upgrade schedule and migration
- Add actorstype to the NewActorRegistry in /chain/consensus/computestate.go
- Add upgrade field to api/types.go/ForkUpgradeParams
- Add upgrade to node/impl/full/state.go
- Add network version to chain/state/statetree.go
- make jen
- make docsgen-cli
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.
