Skip to content

Releases: filecoin-project/lotus

v1.27.0-rc3

17 May 07:21
@rjan90 rjan90
v1.27.0-rc3
4daac14
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.27.0-rc3 Pre-release
Pre-release

This is the third release candidate of the upcoming optional release of Lotus v1.27.0. This feature release includes numerous improvements and enhancements for node operators, RPC- and ETH RPC-providers as well as storage providers. This feature release introduces Curio in Beta release. Check out the Curio Beta release section for how you can get started with Curio.

☢️ Upgrade Warnings ☢️

  • This feature release drops the Raft cluster code experiment from the codebase. This Raft cluster never graduated beyond an experiment, had poor UX (e.g. no way to manage a running cluster, so it didn't provide High Availability), and pulled in a lot of heavy dependencies. We keep the multi-node RPC feature, it is not perfect, but it is useful.
  • Event Database: Two sequential migrations will adjust indexes without altering data or columns, ensuring minimal invasiveness when upgrading to this release. However, these migrations may be time-consuming for nodes with extensive event databases.

Indexers, RPC- and ETH RPC-providers improvements

This release includes a lot of improvements and fixes for indexers, RPC- and ETH RPC-providers. Specifically these PRs:

⭐️ Curio Beta Release ⭐️

Curio, the next generation of Lotus-Miner, also referred to as MinerV2! This release officially transitions Curio into beta and introduces a suite of powerful features designed to enhance your storage operations.

Highlights

  • Curio as MinerV2: Embrace the revolutionary upgrade from Lotus-Miner to Curio. This transition is not just a rebranding—it's an upgrade to a more robust, scalable, and user-friendly version.
  • High Availability: Curio is designed for high availability. You can run multiple instances of Curio nodes to handle similar type of tasks. The distributed scheduler and greedy worker design will ensure that tasks are completed on time despite most partial outages. You can safely update one of your Curio machines without disrupting the operation of the others.
  • Node Heartbeat: Each Curio node in a cluster must post a heartbeat message every 10 minutes in HarmonyDB updating its status. If a heartbeat is missed, the node is considered lost and all tasks can now be scheduled on remaining nodes.
  • Task Retry: Each task in Curio has a limit on how many times it should be tried before being declared lost. This ensures that Curio does not keep retrying bad tasks indefinitely. This safeguards against lost computation time and storage.
  • Polling: Curio avoids overloading nodes with a polling system. Nodes check for tasks they can handle, prioritizing idle nodes for even workload distribution.
  • Simple Configuration Management: The configuration is stored in the database in the forms of layers. These layers can be stacked on top of each other to create a final configuration. Users can reuse these layers to control the behavior of multiple machines without needing to maintain the configuration of each node. Start the binary with the appropriate flags to connect with YugabyteDB and specify which configuration layers to use to get desired behaviour.

Getting Started with Curio

cd lotus
git pull
make clean deps all
sudo make install

On your local-dev-net or calibrationnet lotus-miner machine, initiate:

curio guided-setup

Need More Info?

For detailed documentation and additional information on Curio:

Curio Overview <- insert link
Visit the Curio Official Website insert link

❗Curio is in Beta state, and we recommend our users to run Curio in a testing environment or on the Calibration network for the time being.

New features

Improvements

Read more
Loading

v1.27.0-rc2

08 May 06:22
@rjan90 rjan90
v1.27.0-rc2
bbcad8a
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.27.0-rc2 Pre-release
Pre-release

This is the second release candidate of the upcoming optional release of Lotus v1.27.0. This feature release includes numerous improvements and enhancements for node operators, RPC- and ETH RPC-providers as well as storage providers. This feature release introduces Curio in Beta release. Check out the Curio Beta release section for how you can get started with Curio.

☢️ Upgrade Warnings ☢️

  • This feature release drops the Raft cluster code experiment from the codebase. This Raft cluster never graduated beyond an experiment, had poor UX (e.g. no way to manage a running cluster, so it didn't provide High Availability), and pulled in a lot of heavy dependencies. We keep the multi-node RPC feature, it is not perfect, but it is useful.
  • Event Database: Two sequential migrations will adjust indexes without altering data or columns, ensuring minimal invasiveness when upgrading to this release. However, these migrations may be time-consuming for nodes with extensive event databases.

Indexers, RPC- and ETH RPC-providers improvements

This release includes a lot of improvements and fixes for indexers, RPC- and ETH RPC-providers. Specifically these PRs:

⭐️ Curio Beta Release ⭐️

Curio, the next generation of Lotus-Miner, also referred to as MinerV2! This release officially transitions Curio into beta and introduces a suite of powerful features designed to enhance your storage operations.

Highlights

  • Curio as MinerV2: Embrace the revolutionary upgrade from Lotus-Miner to Curio. This transition is not just a rebranding—it's an upgrade to a more robust, scalable, and user-friendly version.
  • High Availability: Curio is designed for high availability. You can run multiple instances of Curio nodes to handle similar type of tasks. The distributed scheduler and greedy worker design will ensure that tasks are completed on time despite most partial outages. You can safely update one of your Curio machines without disrupting the operation of the others.
  • Node Heartbeat: Each Curio node in a cluster must post a heartbeat message every 10 minutes in HarmonyDB updating its status. If a heartbeat is missed, the node is considered lost and all tasks can now be scheduled on remaining nodes.
  • Task Retry: Each task in Curio has a limit on how many times it should be tried before being declared lost. This ensures that Curio does not keep retrying bad tasks indefinitely. This safeguards against lost computation time and storage.
  • Polling: Curio avoids overloading nodes with a polling system. Nodes check for tasks they can handle, prioritizing idle nodes for even workload distribution.
  • Simple Configuration Management: The configuration is stored in the database in the forms of layers. These layers can be stacked on top of each other to create a final configuration. Users can reuse these layers to control the behavior of multiple machines without needing to maintain the configuration of each node. Start the binary with the appropriate flags to connect with YugabyteDB and specify which configuration layers to use to get desired behaviour.

Getting Started with Curio

cd lotus
git pull
make clean deps all
sudo make install

On your local-dev-net or calibrationnet lotus-miner machine, initiate:

curio guided-setup

Need More Info?

For detailed documentation and additional information on Curio:

Curio Overview <- insert link
Visit the Curio Official Website insert link

❗Curio is in Beta state, and we recommend our users to run Curio in a testing environment or on the Calibration network for the time being.

New features

Improvements

Read more
Loading

v1.27.0-rc1

01 May 08:11
@rjan90 rjan90
v1.27.0-rc1
10f7b6e
Compare
Choose a tag to compare
v1.27.0-rc1 Pre-release
Pre-release

This is the first release candidate of the upcoming optional release of Lotus v1.27.0. This feature release includes numerous improvements and enhancements for node operators, RPC- and ETH RPC-providers as well as storage providers. This feature release introduces Curio in Beta release, check out the Curio Beta release section for how you can get started with Curio.

☢️ Upgrade Warnings ☢️

  • Event Database: Two sequential migrations will adjust indexes without altering data or columns, ensuring minimal invasiveness when upgrading to this release. However, these migrations may be time-consuming for nodes with extensive event databases.
  • This feature release drops the Raft cluster code from the codebase. This Raft cluster never graduated beyond an experiment, had poor UX (e.g. no way to manage a running cluster, so it didn't provide High Availability, and pulled in a lot of heavy dependencies. We keep the multi-node RPC feature, it is not perfect, but it is useful.

Indexers, RPC- and ETH RPC-providers improvements

This release includes a lot of improvements and fixes for indexers, RPC- and ETH RPC-providers. Specifically these PRs:

⭐️ Curio Beta Release ⭐️

Curio, the next generation of Lotus-Miner, also referred to as MinerV2! This release officially transitions Curio into beta and introduces a suite of powerful features designed to enhance your storage operations.

Highlights

  • Curio as MinerV2: Embrace the revolutionary upgrade from Lotus-Miner to Curio. This transition is not just a rebranding—it's an upgrade to a more robust, scalable, and user-friendly version.
  • High Availability: Curio is designed for high availability. You can run multiple instances of Curio nodes to handle similar type of tasks. The distributed scheduler and greedy worker design will ensure that tasks are completed on time despite most partial outages. You can safely update one of your Curio machines without disrupting the operation of the others.
  • Node Heartbeat: Each Curio node in a cluster must post a heartbeat message every 10 minutes in HarmonyDB updating its status. If a heartbeat is missed, the node is considered lost and all tasks can now be scheduled on remaining nodes.
  • Task Retry: Each task in Curio has a limit on how many times it should be tried before being declared lost. This ensures that Curio does not keep retrying bad tasks indefinitely. This safeguards against lost computation time and storage.
  • Polling: Curio avoids overloading nodes with a polling system. Nodes check for tasks they can handle, prioritizing idle nodes for even workload distribution.
  • Simple Configuration Management: The configuration is stored in the database in the forms of layers. These layers can be stacked on top of each other create a final configuration. Users can reuse these layers to control the behaviour of multiple machines without needing to maintain the configuration of each node. Start the binary with the appropriate flags to connect with YugabyteDB and specify which configuration layers to use to get desired behaviour.

Getting Started with Curio

cd lotus
git pull
make clean deps all
sudo make install

On your local-dev-net or calibrationnet lotus-miner machine, initiate:

curio guided-setup

Need More Info?

For detailed documentation and additional information on Curio:

Curio Overview
Visit the Curio Official Website

❗Curio is in Beta state, and we recommend our users to run Curio in a testing environment or on the Calibration network for the time being.

New features

Improvements

Read more
Loading

v1.26.3

23 Apr 00:39
@rjan90 rjan90
v1.26.3
560826d
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.26.3

This is a patch release that addresses high memory load concerns for the Lotus daemon in the coming network migration for network version 22, scheduled on epoch 3855360 - 2024-04-24 - 14:00:00Z.

If your Lotus daemon is running on a machine with less memory and swap than 160GB, you should upgrade to this patch release to ensure you do not encounter any Out-Of-Memory issues during the pre-migration.

Loading

v1.26.2

08 Apr 23:13
@rvagg rvagg
v1.26.2
This tag was signed with the committer’s verified signature.
rvagg Rod Vagg
GPG key ID: C273792F7D83545D
Verified
Learn about vigilant mode.
082a915
Compare
Choose a tag to compare
v1.26.2

This is a mandatory patch release for the Filecoin network version 22 mainnet upgrade, for all node operators.

There is an update in the upgrade epoch for nv22, you can read the full discussion in Slack here.

The new upgrade epoch is scheduled to be on epoch 3855360 - 2024-04-24 - 14:00:00Z. That means:

  • All mainnet node operators that have upgraded to v1.26.x, must upgrade to this patch release before 2024-04-11T14:00:00Z.
  • All mainnet node operators that are on a version lower the v1.26.x, must upgrade to this patch release before 2024-04-24T14:00:00Z.

Please note that releases v1.26.0 and v1.26.1 have been retracted and should not be used prior to the new network version 22 upgrade epoch.

This patch also includes fixes for node operators who want to index builtin-actor events after the nv22 upgrade. Specifically, it ensures the builtin actor event entries are ordered by insertion order when selected (#11834). It also includes a couple Lotus-Miner patch fixes, ensuring that SnapDeals works properly and are using the new ProveReplicaUpdate3 message after the network version 22 upgrade, ensuring that DDO-sectors has the correct sector expirations, as well as DDO-sector visibility in the lotus-miner sectors list cmd.

The information below is copied from the v1.26.0 release notes and relates to inclusions in the v1.26 series:

This is the stable release for the upcoming MANDATORY Filecoin network upgrade v22, codenamed Dragon 🐉, at epoch 3817920 - 2024-04-11 - 14:00:00Z epoch 3855360 - 2024-04-24 - 14:00:00Z The switch to the new Drand-network will happen exactly 120 epochs (1 hour) after the Dragon-upgrade. This switch has been codenamed Phoenix.

The Filecoin network version 22 delivers the following FIPs:

☢️ Upgrade Warnings ☢️

  • This release requires a minimum Go version of v1.21.7 or higher to successfully build Lotus.
  • SPs: Some SPs has encountered a wdpost with the address didn't have enough funds to send message error error when upgrading to this version. Due to #9746 which was introduced in Lotus v1.25.2, SPs must ensure they have a higher FIL amount in their windowPoSt-wallet then the MaxWindowPoStGasFee setting is. Alternetively they can set the MaximizeWindowPoStFeeCap settting to false.

v13 Builtin Actor Bundle

Builtin actor v13.0.0 is used for supporting this upgrade. Make sure that your lotus actor bundle matches the v13 actors manifest by running the following cli after upgrading:

lotus state actor-cids --network-version=22
Network Version: 22
Actor Version: 13
Manifest CID: bafy2bzacecdhvfmtirtojwhw2tyciu4jkbpsbk5g53oe24br27oy62sn4dc4e

Actor             CID  
account           bafk2bzacedxnbtlsqdk76fsfmnhyvsblwyfducerwwtp3mqtx2wbrvs5idl52
cron              bafk2bzacebbopddyn5csb3fsuhh2an4ttd23x6qnwixgohlirj5ahtcudphyc
datacap           bafk2bzaceah42tfnhd7xnztawgf46gbvc3m2gudoxshlba2ucmmo2vy67t7ci
eam               bafk2bzaceb23bhvvcjsth7cn7vp3gbaphrutsaz7v6hkls3ogotzs4bnhm4mk
ethaccount        bafk2bzaceautge6zhuy6jbj3uldwoxwhpywuon6z3xfvmdbzpbdribc6zzmei
evm               bafk2bzacedq6v2lyuhgywhlllwmudfj2zufzcauxcsvvd34m2ek5xr55mvh2q
init              bafk2bzacedr4xacm3fts4vilyeiacjr2hpmwzclyzulbdo24lrfxbtau2wbai
multisig          bafk2bzacecr5zqarfqak42xqcfeulsxlavcltawsx2fvc7zsjtby6ti4b3wqc
paymentchannel    bafk2bzacebntdhfmyc24e7tm52ggx5tnw4i3hrr3jmllsepv3mibez4hywsa2
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzacedq4q2kwkruu4xm7rkyygumlbw2yt4nimna2ivea4qarvtkohnuwu
storagemarket     bafk2bzacebjtoltdviyznpj34hh5qp6u257jnnbjole5rhqfixm7ug3epvrfu
storageminer      bafk2bzacebf4rrqyk7gcfggggul6nfpzay7f2ordnkwm7z2wcf4mq6r7i77t2
storagepower      bafk2bzacecjy4dkulvxppg3ocbmeixe2wgg6yxoyjxrm4ko2fm3uhpvfvam6e
system            bafk2bzacecyf523quuq2kdjfdvyty446z2ounmamtgtgeqnr3ynlu5cqrlt6e
verifiedregistry  bafk2bzacedkxehp7y7iyukbcje3wbpqcvufisos6exatkanyrbotoecdkrbta

Migration

We are expecting a bit heavier than normal state migration for this upgrade due to the amount of state changes introduced with Direct Data Onboarding.

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 120 epochs before the upgrade. It will take around 10-20 minutes for the pre-migration and less than 30 seconds for the final migration, depending on the amount of historical state in the node blockstore and the hardware specs the node is running on. During this time, expect slower block validation times, increased CPU and memory usage, and longer delays for API queries

We recommend node operators (who haven't enabled splitstore discard mode) that do not care about historical chain states, to prune the chain blockstore by syncing from a snapshot 1-2 days before the upgrade.

You can test out the migration by running running the benchmarking a network migration tutorial.

For certain node operators, such as full archival nodes or systems that need to keep large amounts of state (RPC providers), completing the pre-migration in time before the network upgrade might not be achievable. For those node operators, it is recommended to skip the pre-migration and run the non-cached migration (i.e., just running the migration at the exact upgrade epoch), and schedule for some downtime during the upgrade epoch. Operators of such nodes can read the How to disable premigration in network upgrade tutorial.

New features

Tracing API

Replace the CodeCid field in the message trace (added in 1.23.4) with an InvokedActor field.

Before:

{
    "Msg": {
        "From": ...,
        "To": ...,
        ...
        "CodeCid": ... // The actor's code CID.
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

After:

{
    "Msg": {
        "From": ...,
        "To": ...
    }
    "InvokedActor": {         // The invoked actor (ommitted if the actor wasn't invoked).
        "Id": 1234,           // The ID of the actor.
        "State": {            // The actor's state object (may change between network versions).
           "Code": ...,       // The actor's code CID.
           "Head": ...,       // The actor's state-root (when invoked).
           "CallSeqNum": ..., // The actor's nonce.
           "Balance": ...,    // The actor's balance (when invoked).
           "Address": ...,    // Delegated address (FEVM only).
        }
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

This means the trace now contains an accurate "snapshot" of the actor at the time of the call, information that may not be present in the final state-tree (e.g., due to reverts). This will hopefully improve the performance and accuracy of indexing services.

Ethereum Tracing API (trace_block and trace_replayBlockTransactions)

For those with the Ethereum JSON-RPC API enabled, the experimental Ethereum Tracing API has been improved significantly and should be considered "functional". However, it's still new and should be tested extensively before relying on it. This API translates FVM traces to Ethereum-style traces, implementing the OpenEthereum trace_block and trace_replayBlockTransactions APIs.

This release fixes numerous bugs with this API and now ABI-encodes non-EVM inputs/outputs as if they were explicit EVM calls to [handle_filecoin_method][handlefilecoinmethod] for better block explorer compatibility.

However, there are some significant limitations:

  1. The Geth APIs are not implemented, only the OpenEthereum (Erigon, etc.) APIs.
  2. Block rewards are not (yet) included in the trace.
  3. Selfdestruct operations are not included in the trace.
  4. EVM smart contract "create" events always specify 0xfe as the "code" for newly created EVM smart contracts.

Additionally, Filecoin is not Ethereum no matter how much we try to provide API/tooling compatibility. This API attempts to translate Filecoin semantics into Ethereum semantics as accurately as possible, but it's hardly the best source of data unless you need Filecoin to look like an Ethereum compatib...

Read more
Loading

v1.26.1

27 Mar 20:23
@rjan90 rjan90
v1.26.1
9dc9a5c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.26.1

RETRACTED: Due to a change in network version 22 upgrade epoch, Lotus v1.26.1 should not be used prior to the new upgrade epoch. See v1.26.2 release notes for details.

This is a patch release for the Calibration network users. The Calibration network is scheduled for an upgrade to include the two additional built-in actor events to ease the transition and observability of DDO for the ecosystem (#964 and #968).

The agreed-upon epoch between the Filecoin implementer team for the update is 1493854, corresponding to 2024-04-03T11:00:00Z. All Calibration network users need to upgrade to this patch release before that.

Lotus Mainnet Users: For users on the Mainnet, the Lotus v1.26.0 release already includes the aforementioned events in preparation for the Mainnet nv22 upgrade. Therefore, both v1.26.0 and v1.26.1 versions are suitable for use on the Mainnet for the coming network version 22 upgrade.

Loading

v1.26.0

22 Mar 07:19
@rjan90 rjan90
v1.26.0
5f86ff9
Compare
Choose a tag to compare
v1.26.0

RETRACTED: Due to a change in network version 22 upgrade epoch, Lotus v1.26.0 should not be used prior to the new upgrade epoch. See v1.26.2 release notes for details.

This is the stable release for the upcoming MANDATORY Filecoin network upgrade v22, codenamed Dragon 🐉, at epoch 3817920 - 2024-04-11 - 14:00:00Z The switch to the new Drand-network will happen exactly 120 epochs (1 hour) after the Dragon-upgrade. This switch has been codenamed Phoenix.

The Filecoin network version 22 delivers the following FIPs:

☢️ Upgrade Warnings ☢️

  • This release requires a minimum Go version of v1.21.7 or higher to successfully build Lotus.

v13 Builtin Actor Bundle

Builtin actor v13.0.0 is used for supporting this upgrade. Make sure that your lotus actor bundle matches the v13 actors manifest by running the following cli after upgrading:

lotus state actor-cids --network-version=22
Network Version: 22
Actor Version: 13
Manifest CID: bafy2bzacecdhvfmtirtojwhw2tyciu4jkbpsbk5g53oe24br27oy62sn4dc4e

Actor             CID  
account           bafk2bzacedxnbtlsqdk76fsfmnhyvsblwyfducerwwtp3mqtx2wbrvs5idl52
cron              bafk2bzacebbopddyn5csb3fsuhh2an4ttd23x6qnwixgohlirj5ahtcudphyc
datacap           bafk2bzaceah42tfnhd7xnztawgf46gbvc3m2gudoxshlba2ucmmo2vy67t7ci
eam               bafk2bzaceb23bhvvcjsth7cn7vp3gbaphrutsaz7v6hkls3ogotzs4bnhm4mk
ethaccount        bafk2bzaceautge6zhuy6jbj3uldwoxwhpywuon6z3xfvmdbzpbdribc6zzmei
evm               bafk2bzacedq6v2lyuhgywhlllwmudfj2zufzcauxcsvvd34m2ek5xr55mvh2q
init              bafk2bzacedr4xacm3fts4vilyeiacjr2hpmwzclyzulbdo24lrfxbtau2wbai
multisig          bafk2bzacecr5zqarfqak42xqcfeulsxlavcltawsx2fvc7zsjtby6ti4b3wqc
paymentchannel    bafk2bzacebntdhfmyc24e7tm52ggx5tnw4i3hrr3jmllsepv3mibez4hywsa2
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzacedq4q2kwkruu4xm7rkyygumlbw2yt4nimna2ivea4qarvtkohnuwu
storagemarket     bafk2bzacebjtoltdviyznpj34hh5qp6u257jnnbjole5rhqfixm7ug3epvrfu
storageminer      bafk2bzacebf4rrqyk7gcfggggul6nfpzay7f2ordnkwm7z2wcf4mq6r7i77t2
storagepower      bafk2bzacecjy4dkulvxppg3ocbmeixe2wgg6yxoyjxrm4ko2fm3uhpvfvam6e
system            bafk2bzacecyf523quuq2kdjfdvyty446z2ounmamtgtgeqnr3ynlu5cqrlt6e
verifiedregistry  bafk2bzacedkxehp7y7iyukbcje3wbpqcvufisos6exatkanyrbotoecdkrbta

Migration

We are expecting a bit heavier than normal state migration for this upgrade due to the amount of state changes introduced with Direct Data Onboarding.

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 120 epochs before the upgrade. It will take around 10-20 minutes for the pre-migration and less than 30 seconds for the final migration, depending on the amount of historical state in the node blockstore and the hardware specs the node is running on. During this time, expect slower block validation times, increased CPU and memory usage, and longer delays for API queries

We recommend node operators (who haven't enabled splitstore discard mode) that do not care about historical chain states, to prune the chain blockstore by syncing from a snapshot 1-2 days before the upgrade.

You can test out the migration by running running the benchmarking a network migration tutorial.

For certain node operators, such as full archival nodes or systems that need to keep large amounts of state (RPC providers), completing the pre-migration in time before the network upgrade might not be achievable. For those node operators, it is recommended to skip the pre-migration and run the non-cached migration (i.e., just running the migration at the exact upgrade epoch), and schedule for some downtime during the upgrade epoch. Operators of such nodes can read the How to disable premigration in network upgrade tutorial.

New features

Tracing API

Replace the CodeCid field in the message trace (added in 1.23.4) with an InvokedActor field.

Before:

{
    "Msg": {
        "From": ...,
        "To": ...,
        ...
        "CodeCid": ... // The actor's code CID.
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

After:

{
    "Msg": {
        "From": ...,
        "To": ...
    }
    "InvokedActor": {         // The invoked actor (ommitted if the actor wasn't invoked).
        "Id": 1234,           // The ID of the actor.
        "State": {            // The actor's state object (may change between network versions).
           "Code": ...,       // The actor's code CID.
           "Head": ...,       // The actor's state-root (when invoked).
           "CallSeqNum": ..., // The actor's nonce.
           "Balance": ...,    // The actor's balance (when invoked).
           "Address": ...,    // Delegated address (FEVM only).
        }
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

This means the trace now contains an accurate "snapshot" of the actor at the time of the call, information that may not be present in the final state-tree (e.g., due to reverts). This will hopefully improve the performance and accuracy of indexing services.

Ethereum Tracing API (trace_block and trace_replayBlockTransactions)

For those with the Ethereum JSON-RPC API enabled, the experimental Ethereum Tracing API has been improved significantly and should be considered "functional". However, it's still new and should be tested extensively before relying on it. This API translates FVM traces to Ethereum-style traces, implementing the OpenEthereum trace_block and trace_replayBlockTransactions APIs.

This release fixes numerous bugs with this API and now ABI-encodes non-EVM inputs/outputs as if they were explicit EVM calls to handle_filecoin_method for better block explorer compatibility.

However, there are some significant limitations:

  1. The Geth APIs are not implemented, only the OpenEthereum (Erigon, etc.) APIs.
  2. Block rewards are not (yet) included in the trace.
  3. Selfdestruct operations are not included in the trace.
  4. EVM smart contract "create" events always specify 0xfe as the "code" for newly created EVM smart contracts.

Additionally, Filecoin is not Ethereum no matter how much we try to provide API/tooling compatibility. This API attempts to translate Filecoin semantics into Ethereum semantics as accurately as possible, but it's hardly the best source of data unless you need Filecoin to look like an Ethereum compatible chain. If you're trying to build a new integration with Filecoin, please use the native StateCompute method instead.

GetActorEventsRaw and SubscribeActorEventsRaw

FIP-0049 introduced Actor Events that can be emitted by user programmed actors. FIP-0083 introduces new events emitted by the builtin Verified Registry, Miner and Market Actors. These new events for builtin actors are being activated with network version 22 to coincide with Direct Data Onboarding as defined in FIP-0076 which introduces additional flexibility for data onboarding. Sector, Deal and DataCap lifecycles can be tracked with these events, providing visibility and options for programmatic responses to changes in state.

Actor events are available on message receipts, but can now be retrieved from a node using the new GetActorEventsRaw and SubscribeActorEventsRaw methods. These methods allow for querying and subscribing to actor events, respectively. They depend on the Lotus node both collecting events (with Fevm.Events.RealTimeFilterAPI and Fevm.Events.HistoricFilterAPI) and being enabled with the new configuration option Events.EnableActorEventsAPI. Note that a Lotus node can only respond to requests for historic events that it retains in its event store.

Both GetActorEventsRaw and SubscribeActorEventsRaw take a filter parameter which can optionally filter events on:

  • Addresses of the actor(s) emitting the event
  • Specific Fields within the event
  • FromHeight and ToHeight to filter events by block height
  • TipSetKey to restrict events contained within a specific tipset

`GetActo...

Read more
Loading

v1.26.0-rc3

13 Mar 17:48
@rjan90 rjan90
v1.26.0-rc3
bfb3602
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.26.0-rc3 Pre-release
Pre-release

This is the third release candidate of the upcoming MANDATORY Lotus v1.26.0 release, which will deliver the Filecoin network version 22, codenamed Dragon 🐉. This third release candidate brings in multiple storage provider fixes, and cleanups for issues encountered during testing in the Calibration network.

This release candidate only has the calibration network to upgrade set, which happened at epoch 1427974, 2024-03-11T14:00:00Z. This release does NOT set the mainnet upgrade epoch, which will be updated in the final release.

The Filecoin network version 22 delivers the following FIPs:

v13 Builtin Actor Bundle

The actor bundles for the calibration network can be checked as follows:

lotus state actor-cids --network-version=22
Network Version: 22
Actor Version: 13
Manifest CID: bafy2bzacea4firkyvt2zzdwqjrws5pyeluaesh6uaid246tommayr4337xpmi

Actor             CID  
account           bafk2bzaceb3j36ri5y5mfklgp5emlvrms6g4733ss2j3l7jismrxq6ng3tcc6
cron              bafk2bzaceaz6rocamdxehgpwcbku6wlapwpgzyyvkrploj66mlqptsulf52bs
datacap           bafk2bzacea22nv5g3yngpxvonqfj4r2nkfk64y6yw2malicm7odk77x7zuads
eam               bafk2bzaceatqtjzj7623i426noaslouvluhz6e3md3vvquqzku5qj3532uaxg
ethaccount        bafk2bzacean3hs7ga5csw6g3uu7watxfnqv5uvxviebn3ba6vg4sagwdur5pu
evm               bafk2bzacec5ibmbtzuzjgwjmksm2n6zfq3gkicxqywwu7tsscqgdzajpfctxk
init              bafk2bzaced5sq72oemz6qwi6yssxwlos2g54zfprslrx5qfhhx2vlgsbvdpcs
multisig          bafk2bzacedbgei6jkx36fwdgvoohce4aghvpohqdhoco7p4thszgssms7olv2
paymentchannel    bafk2bzaceasmgmfsi4mjanxlowsub65fmevhzky4toeqbtw4kp6tmu4kxjpgq
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzacedjyp6ll5ez27dfgldjj4tntxfvyp4pa5zkk7s5uhipzqjyx2gmuc
storagemarket     bafk2bzaceabolct6qdnefwcrtati2us3sxtxfghyqk6aamfhl6byyefmtssqi
storageminer      bafk2bzaceckzw3v7wqliyggvjvihz4wywchnnsie4frfvkm3fm5znb64mofri
storagepower      bafk2bzacea7t4wynzjajl442mpdqbnh3wusjusqtnzgpvefvweh4n2tgzgqhu
system            bafk2bzacedjnrb5glewazsxpcx6rwiuhl4kwrfcqolyprn6rrjtlzmthlhdq6
verifiedregistry  bafk2bzacednskl3bykz5qpo54z2j2p4q44t5of4ktd6vs6ymmg2zebsbxazkm

Migration

We are expecting a bit heavier than normal state migration for this upgrade due to the amount of state changes introduced with Direct Data Onboarding.

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 120 epochs before the upgrade. It will take around 10-20 minutes for the pre-migration and less than 30 seconds for the final migration, depending on the amount of historical state in the node blockstore and the hardware specs the node is running on. During this time, expect slower block validation times, increased CPU and memory usage, and longer delays for API queries

We recommend node operators (who haven't enabled splitstore discard mode) that do not care about historical chain states, to prune the chain blockstore by syncing from a snapshot 1-2 days before the upgrade.

You can test out the migration by running running the benchmarking a network migration tutorial.

For certain node operators, such as full archival nodes or systems that need to keep large amounts of state (RPC providers), completing the pre-migration in time before the network upgrade might not be achievable. For those node operators, it is recommended to skip the pre-migration and run the non-cached migration (i.e., just running the migration at the exact upgrade epoch), and schedule for some downtime during the upgrade epoch. Operators of such nodes can read the How to disable premigration in network upgrade tutorial.

New features

Improvements

Tracing API

Replace the CodeCid field in the message trace (added in 1.23.4) with an InvokedActor field.

Before:

{
    "Msg": {
        "From": ...,
        "To": ...,
        ...
        "CodeCid": ... // The actor's code CID.
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

After:

{
    "Msg": {
        "From": ...,
        "To": ...
    }
    "InvokedActor": {         // The invoked actor (ommitted if the actor wasn't invoked).
        "Id": 1234,           // The ID of the actor.
        "State": {            // The actor's state object (may change between network versions).
           "Code": ...,       // The actor's code CID.
           "Head": ...,       // The actor's state-root (when invoked).
           "CallSeqNum": ..., // The actor's nonce.
           "Balance": ...,    // The actor's balance (when invoked).
           "Address": ...,    // Delegated address (FEVM only).
        }
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

This means the trace now contains an accurate "snapshot" of the actor at the time of the call, information that may not be present in the final state-tree (e.g., due to reverts). This will hopefully improve the performance and accuracy of indexing services.

Ethereum Tracing API (trace_block and trace_replayBlockTransactions)

For those with the Ethereum JSON-RPC API enabled, the experimental Ethereum Tracing API has been improved significantly and should be considered "functional". However, it's still new and should be tested extensively before relying on it. This API translates FVM traces to Ethereum-style traces, implementing the OpenEthereum trace_block and trace_replayBlockTransactions APIs.

This release fixes numerous bugs with this API and now ABI-encodes non-EVM inputs/outputs as if they were explicit EVM calls to handle_filecoin_method for better block explorer compatibility.

However, there are some significant limitations:

  1. The Geth APIs are not implemented, only the OpenEthereum (Erigon, etc.) APIs.
  2. Block rewards are not (yet) included in the trace.
  3. Selfdestruct operations are not included in the trace.
  4. EVM smart contract "create" events always specify 0xfe as the "code" for newly created EVM smart contracts.

Additionally, Filecoin is not Ethereum no matter how much we try to provide API/tooling compatibility. This API attempts to translate Filecoin semantics into Ethereum semantics as accurately as possible, but it's hardly the best source of data unless you need Filecoin to look like an Ethereum compatible chain. If you're trying to build a new integration with Filecoin, please use the native StateCompute method instead.

GetActorEvents and SubscribeActorEvents

FIP-0049 introduced Actor Events that can be emitted by user programmed actors. FIP-0083 introduces new events emitted by the builtin Verified Registry, Miner and Market Actors. These new events for builtin actors are being activated with network version 22 to coincide with Direct Data Onboarding as defined in FIP-0076 which introduces additional flexibility for data onboarding. Sector, Deal and DataCap lifecycles can be tracked with these events, providing visibility and options for programmatic responses to changes in state.

Actor events are available on message rec...

Read more
Loading

v1.26.0-rc2

07 Mar 11:00
@jennijuju jennijuju
v1.26.0-rc2
4a1a7bd
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.26.0-rc2 Pre-release
Pre-release

This is a release candidate of the upcoming MANDATORY Lotus v1.26.0 release, which will deliver the Filecoin network version 22, codenamed Dragon 🐉.

This release candidate sets the calibration network to upgrade at epoch 1427974, which is 2024-03-11T14:00:00Z
This release does NOT set the mainnet upgrade epoch yet, in which will be updated in the final release.
The Filecoin network version 22 delivers the following FIPs:

v13 Builtin Actor Bundle

The actor bundles for the calibration network can be checked as follows:

lotus state actor-cids --network-version=22
Network Version: 22
Actor Version: 13
Manifest CID: bafy2bzacea4firkyvt2zzdwqjrws5pyeluaesh6uaid246tommayr4337xpmi

Actor             CID  
account           bafk2bzaceb3j36ri5y5mfklgp5emlvrms6g4733ss2j3l7jismrxq6ng3tcc6
cron              bafk2bzaceaz6rocamdxehgpwcbku6wlapwpgzyyvkrploj66mlqptsulf52bs
datacap           bafk2bzacea22nv5g3yngpxvonqfj4r2nkfk64y6yw2malicm7odk77x7zuads
eam               bafk2bzaceatqtjzj7623i426noaslouvluhz6e3md3vvquqzku5qj3532uaxg
ethaccount        bafk2bzacean3hs7ga5csw6g3uu7watxfnqv5uvxviebn3ba6vg4sagwdur5pu
evm               bafk2bzacec5ibmbtzuzjgwjmksm2n6zfq3gkicxqywwu7tsscqgdzajpfctxk
init              bafk2bzaced5sq72oemz6qwi6yssxwlos2g54zfprslrx5qfhhx2vlgsbvdpcs
multisig          bafk2bzacedbgei6jkx36fwdgvoohce4aghvpohqdhoco7p4thszgssms7olv2
paymentchannel    bafk2bzaceasmgmfsi4mjanxlowsub65fmevhzky4toeqbtw4kp6tmu4kxjpgq
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzacedjyp6ll5ez27dfgldjj4tntxfvyp4pa5zkk7s5uhipzqjyx2gmuc
storagemarket     bafk2bzaceabolct6qdnefwcrtati2us3sxtxfghyqk6aamfhl6byyefmtssqi
storageminer      bafk2bzaceckzw3v7wqliyggvjvihz4wywchnnsie4frfvkm3fm5znb64mofri
storagepower      bafk2bzacea7t4wynzjajl442mpdqbnh3wusjusqtnzgpvefvweh4n2tgzgqhu
system            bafk2bzacedjnrb5glewazsxpcx6rwiuhl4kwrfcqolyprn6rrjtlzmthlhdq6
verifiedregistry  bafk2bzacednskl3bykz5qpo54z2j2p4q44t5of4ktd6vs6ymmg2zebsbxazkm

Migration

We are expecting a bit heavier than normal state migration for this upgrade due to the amount of state changes introduced with Direct Data Onboarding.

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 120 epochs before the upgrade. It will take around 10-20 minutes for the pre-migration and less than 30 seconds for the final migration, depending on the amount of historical state in the node blockstore and the hardware specs the node is running on. During this time, expect slower block validation times, increased CPU and memory usage, and longer delays for API queries

We recommend node operators (who haven't enabled splitstore discard mode) that do not care about historical chain states, to prune the chain blockstore by syncing from a snapshot 1-2 days before the upgrade.

You can test out the migration by running running the benchmarking a network migration tutorial.

For certain node operators, such as full archival nodes or systems that need to keep large amounts of state (RPC providers), completing the pre-migration in time before the network upgrade might not be achievable. For those node operators, it is recommended to skip the pre-migration and run the non-cached migration (i.e., just running the migration at the exact upgrade epoch), and schedule for some downtime during the upgrade epoch. Operators of such nodes can read the How to disable premigration in network upgrade tutorial.

New features

Improvements

Tracing API

Replace the CodeCid field in the message trace (added in 1.23.4) with an InvokedActor field.

Before:

{
    "Msg": {
        "From": ...,
        "To": ...,
        ...
        "CodeCid": ... // The actor's code CID.
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

After:

{
    "Msg": {
        "From": ...,
        "To": ...
    }
    "InvokedActor": {         // The invoked actor (ommitted if the actor wasn't invoked).
        "Id": 1234,           // The ID of the actor.
        "State": {            // The actor's state object (may change between network versions).
           "Code": ...,       // The actor's code CID.
           "Head": ...,       // The actor's state-root (when invoked).
           "CallSeqNum": ..., // The actor's nonce.
           "Balance": ...,    // The actor's balance (when invoked).
           "Address": ...,    // Delegated address (FEVM only).
        }
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

This means the trace now contains an accurate "snapshot" of the actor at the time of the call, information that may not be present in the final state-tree (e.g., due to reverts). This will hopefully improve the performance and accuracy of indexing services.

Ethereum Tracing API (trace_block and trace_replayBlockTransactions)

For those with the Ethereum JSON-RPC API enabled, the experimental Ethereum Tracing API has been improved significantly and should be considered "functional". However, it's still new and should be tested extensively before relying on it. This API translates FVM traces to Ethereum-style traces, implementing the OpenEthereum trace_block and trace_replayBlockTransactions APIs.

This release fixes numerous bugs with this API and now ABI-encodes non-EVM inputs/outputs as if they were explicit EVM calls to handle_filecoin_method for better block explorer compatibility.

However, there are some significant limitations:

  1. The Geth APIs are not implemented, only the OpenEthereum (Erigon, etc.) APIs.
  2. Block rewards are not (yet) included in the trace.
  3. Selfdestruct operations are not included in the trace.
  4. EVM smart contract "create" events always specify 0xfe as the "code" for newly created EVM smart contracts.

Additionally, Filecoin is not Ethereum no matter how much we try to provide API/tooling compatibility. This API attempts to translate Filecoin semantics into Ethereum semantics as accurately as possible, but it's hardly the best source of data unless you need Filecoin to look like an Ethereum compatible chain. If you're trying to build a new integration with Filecoin, please use the native StateCompute method instead.

GetActorEvents and SubscribeActorEvents

FIP-0049 introduced Actor Events that can be emitted by user programmed actors. FIP-0083 introduces new events emitted by the builtin Verified Registry, Miner and Market Actors. These new events for builtin actors are being activated with network version 22 to coincide with Direct Data Onboarding as defined in FIP-0076 which introduces additional flexibility for data onboarding. Sector, Deal and DataCap lifecycles can be tracked with these events, providing visibility and options for programmatic responses to changes in state.

Actor events are available on message receipts, but can now be retrieved from a node using the new GetActorEvents and SubscribeActorEvents methods. These methods allow for querying and subscribing to actor events, respectively. They depend on the Lotus node both collecting events (with Fevm.Events.RealTimeFilterAPI and Fevm.Events.HistoricFilterAPI) and being enabled with the new configuration option Events.EnableActorEventsAPI. Note that a Lotus node can only respond to requests for historic events that it retains in its event store.

Both GetActorEvents and SubscribeActorEvents take a filter parameter which can optionally filter events on:

  • Addresses of the actor(s) emitting the event
  • Specific Fields within the event
  • FromHeight and ToHeight to filter events by block height
  • TipSetKey to restrict events contained within a specific tipset

GetActorEvents provides a one-time query for actor events, while SubscribeActorEvents provides a long-lived connection (via websockets) to the Lotus node, allowing for real-time updates on actor events. The subscription can be cancelled by the client at any time.

GetAllClaims and GetAllAlocations

Additionally the methods `GetA...

Read more
Loading

v1.26.0-rc1

05 Mar 18:23
@rjan90 rjan90
v1.26.0-rc1
64b32ad
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.26.0-rc1 Pre-release
Pre-release

This is the first release candidate of the upcoming MANDATORY Lotus v1.26.0 release, which will deliver the Filecoin network version 22, codenamed Dragon 🐉.

This release candidate sets the calibration network to upgrade at epoch 1427974, which is 2024-03-11T14:00:00Z. This release does NOT set the mainnet upgrade epoch yet, in which will be updated in the final release.

The Filecoin network version 22 delivers the following FIPs:

v13 Builtin Actor Bundle

The actor bundles for the calibration network can be checked as follows:

lotus state actor-cids --network-version=22
Network Version: 22
Actor Version: 13
Manifest CID: bafy2bzacea4firkyvt2zzdwqjrws5pyeluaesh6uaid246tommayr4337xpmi

Actor             CID  
account           bafk2bzaceb3j36ri5y5mfklgp5emlvrms6g4733ss2j3l7jismrxq6ng3tcc6
cron              bafk2bzaceaz6rocamdxehgpwcbku6wlapwpgzyyvkrploj66mlqptsulf52bs
datacap           bafk2bzacea22nv5g3yngpxvonqfj4r2nkfk64y6yw2malicm7odk77x7zuads
eam               bafk2bzaceatqtjzj7623i426noaslouvluhz6e3md3vvquqzku5qj3532uaxg
ethaccount        bafk2bzacean3hs7ga5csw6g3uu7watxfnqv5uvxviebn3ba6vg4sagwdur5pu
evm               bafk2bzacec5ibmbtzuzjgwjmksm2n6zfq3gkicxqywwu7tsscqgdzajpfctxk
init              bafk2bzaced5sq72oemz6qwi6yssxwlos2g54zfprslrx5qfhhx2vlgsbvdpcs
multisig          bafk2bzacedbgei6jkx36fwdgvoohce4aghvpohqdhoco7p4thszgssms7olv2
paymentchannel    bafk2bzaceasmgmfsi4mjanxlowsub65fmevhzky4toeqbtw4kp6tmu4kxjpgq
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzacedjyp6ll5ez27dfgldjj4tntxfvyp4pa5zkk7s5uhipzqjyx2gmuc
storagemarket     bafk2bzaceabolct6qdnefwcrtati2us3sxtxfghyqk6aamfhl6byyefmtssqi
storageminer      bafk2bzaceckzw3v7wqliyggvjvihz4wywchnnsie4frfvkm3fm5znb64mofri
storagepower      bafk2bzacea7t4wynzjajl442mpdqbnh3wusjusqtnzgpvefvweh4n2tgzgqhu
system            bafk2bzacedjnrb5glewazsxpcx6rwiuhl4kwrfcqolyprn6rrjtlzmthlhdq6
verifiedregistry  bafk2bzacednskl3bykz5qpo54z2j2p4q44t5of4ktd6vs6ymmg2zebsbxazkm

Migration

We are expecting a bit heavier than normal state migration for this upgrade due to the amount of state changes introduced with Direct Data Onboarding.

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 120 epochs before the upgrade. It will take around 10-20 minutes for the pre-migration and less than 30 seconds for the final migration, depending on the amount of historical state in the node blockstore and the hardware specs the node is running on. During this time, expect slower block validation times, increased CPU and memory usage, and longer delays for API queries

We recommend node operators (who haven't enabled splitstore discard mode) that do not care about historical chain states, to prune the chain blockstore by syncing from a snapshot 1-2 days before the upgrade.

You can test out the migration by running running the benchmarking a network migration tutorial.

For certain node operators, such as full archival nodes or systems that need to keep large amounts of state (RPC providers), completing the pre-migration in time before the network upgrade might not be achievable. For those node operators, it is recommended to skip the pre-migration and run the non-cached migration (i.e., just running the migration at the exact upgrade epoch), and schedule for some downtime during the upgrade epoch. Operators of such nodes can read the How to disable premigration in network upgrade tutorial.

New features

Improvements

Tracing API

Replace the CodeCid field in the message trace (added in 1.23.4) with an InvokedActor field.

Before:

{
    "Msg": {
        "From": ...,
        "To": ...,
        ...
        "CodeCid": ... // The actor's code CID.
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

After:

{
    "Msg": {
        "From": ...,
        "To": ...
    }
    "InvokedActor": {         // The invoked actor (ommitted if the actor wasn't invoked).
        "Id": 1234,           // The ID of the actor.
        "State": {            // The actor's state object (may change between network versions).
           "Code": ...,       // The actor's code CID.
           "Head": ...,       // The actor's state-root (when invoked).
           "CallSeqNum": ..., // The actor's nonce.
           "Balance": ...,    // The actor's balance (when invoked).
           "Address": ...,    // Delegated address (FEVM only).
        }
    }
    "MsgRct": ...,
    "GasCharges": [],
    "Subcalls": [],
}

This means the trace now contains an accurate "snapshot" of the actor at the time of the call, information that may not be present in the final state-tree (e.g., due to reverts). This will hopefully improve the performance and accuracy of indexing services.

Ethereum Tracing API (trace_block and trace_replayBlockTransactions)

For those with the Ethereum JSON-RPC API enabled, the experimental Ethereum Tracing API has been improved significantly and should be considered "functional". However, it's still new and should be tested extensively before relying on it. This API translates FVM traces to Ethereum-style traces, implementing the OpenEthereum trace_block and trace_replayBlockTransactions APIs.

This release fixes numerous bugs with this API and now ABI-encodes non-EVM inputs/outputs as if they were explicit EVM calls to handle_filecoin_method for better block explorer compatibility.

However, there are some significant limitations:

  1. The Geth APIs are not implemented, only the OpenEthereum (Erigon, etc.) APIs.
  2. Block rewards are not (yet) included in the trace.
  3. Selfdestruct operations are not included in the trace.
  4. EVM smart contract "create" events always specify 0xfe as the "code" for newly created EVM smart contracts.

Additionally, Filecoin is not Ethereum no matter how much we try to provide API/tooling compatibility. This API attempts to translate Filecoin semantics into Ethereum semantics as accurately as possible, but it's hardly the best source of data unless you need Filecoin to look like an Ethereum compatible chain. If you're trying to build a new integration with Filecoin, please use the native StateCompute method instead.

GetActorEvents and SubscribeActorEvents

FIP-0049 introduced Actor Events that can be emitted by user programmed actors. FIP-0083 introduces new events emitted by the builtin Verified Registry, Miner and Market Actors. These new events for builtin actors are being activated with network version 22 to coincide with Direct Data Onboarding as defined in FIP-0076 which introduces additional flexibility for data onboarding. Sector, Deal and DataCap lifecycles can be tracked with these events, providing visibility and options for programmatic responses to changes in state.

Actor events are available on message receipts, but can now be retrieved from a node using the new GetActorEvents and SubscribeActorEvents methods. These methods allow for querying and subscribing to actor events, respectively. They depend on the Lotus node both collecting events (with Fevm.Events.RealTimeFilterAPI and Fevm.Events.HistoricFilterAPI) and being enabled with the new configuration option Events.EnableActorEventsAPI. Note that a Lotus node can only respond to requests for historic events that it retains in its event store.

Both GetActorEvents and SubscribeActorEvents take a filter parameter which can optionally filter events on:

  • Addresses of the actor(s) emitting the event
  • Specific Fields within the event
  • FromHeight and ToHeight to filter events by block height
  • TipSetKey to restrict events contained within a specific tipset

GetActorEvents provides a one-time query for actor events, while SubscribeActorEvents provides a long-lived connection (via websockets) to the Lotus node, allowing for real-time updates on actor events. The subscription can be cancelled by the client at any time.

GetAllClaims and GetAllAlocations

Additionally the met...

Read more
Loading