Skip to content

Releases: filecoin-project/lotus

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
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
Assets 8
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
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
Assets 8
Loading

v1.25.2

11 Jan 15:38
@rjan90 rjan90
v1.25.2
f51f83b
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.25.2

This is an optional but highly recommended feature release of Lotus, as it includes fixes for synchronizations issues that node operators have experienced.

This feature release also introduces the new Lotus-Provider binary in its alpha testing phase, as well as the ability to call external PC2-binaries during the sealing process - read more about these features in the highlights section.

☢️ Upgrade Warnings ☢️

  • You might see a install: cannot stat './lotus-provider': No such file or directory error when running sudo make install building from source. It will not cause any issues, but you can get rid of the error by running make lotus-provider

⭐️ Highlights ⭐️

Lotus-Provider

The feature release ships the alpha release of the new Lotus-Provider binary, together with its initial features - High Availability of WindowPoSt and WinningPoSt.

So what is so exciting about Lotus-Provider:

High Availability

  • You can run as many Lotus-Provider instances as you want for both WindowPoSt and WinningPOSt.
  • You can connect them to as many clustered Yugabyte instances as you want to. This allows for an NxN configuration where all instances can communicate with all others.
  • You have the option to connect different instances to different chain daemons.

Simplicity

  • Once the configuration is in the database, setting up a new machine with Lotus-Provider is straightforward. Simply start the binary with the correct flags to find YugabyteDB and specify which configuration layers it should use.

Durability

  • Lotus-Provider is designed with robustness in mind. Updates to the system are handled seamlessly, ensuring that performance and stability are maintained when taking down machines in your cluster for updates.

Read more about Lotus-Provider in the documentation here. And check out the how you can migrate from Lotus-Miner to Lotus-Provider here. (Only recommended in testnets while its in Alpha)

External PC2-binaries

In this feature release, storage providers can call external PC2-binaries during the sealing process. This allows storage providers to leverage the SupraSeal PC2 binary, which has been shown to improve sealing speed in the PC2-phase. For instance, our current benchmarks show that an NVIDIA RTX A5000 card was able to complete PC2 in approximately 2.5 minutes.

We have verified that SupraSeal PC2 functions properly with Committed Capacity (CC) sectors, both SyntheticPoReps and non-Synthetic PoReps. However calling SupraSeal PC2 with deal sectors is not supported in this feature release.

For more information on how to use SupraSeal PC2 with your lotus-worker, as well as how to use feature, please refer to the documentation.

New features

  • feat: sturdypost work branch (filecoin-project/lotus#11405)
    • Adds the Lotus-Provider binary, and the HarmonyDB framework.
  • feat: worker: Support delegating precommit2 to external binary (filecoin-project/lotus#11185)
    • Allows for delegating PreCommit2 to an exteranl binary.
  • feat: build: Add SupraSeal-PC2 binary script (filecoin-project/lotus#11430)
    • Adds a script for building the SupraSeal-PC2 binary easily.
  • Feat: daemon: Auto remove existing chain if importing chain file or snapshot (filecoin-project/lotus#11277)
    • Auto removes the existing chain when importing a snapshot.
  • feat: Add ETA to lotus sync wait (#11211) (filecoin-project/lotus#11211)
    • Adds a ETA indicator to lotus sync wait, so you can get an estimate for how long until sync is completed.
  • feat: mpool/wdpost: Maximize feecap config (filecoin-project/lotus#9746)
    • Adds a Maximixe FeeCap Config
  • feat: Add lotus-bench cli option to stress test any binary (filecoin-project/lotus#11270)
    • Enables the Lotus-Bench to run any binary and analyze their latency and histogram distribution, track most common errors, perform stress testing under different concurrency levels and see how it works under different QPS.
  • feat: chain import: don't walk to genesis - 2-3x faster snapshot import (#11446) (filecoin-project/lotus#11446)
    • Improves Snapshot import speed, by not walking back to genesis on import.
  • feat: metric: export Mpool message count (filecoin-project/lotus#11361)
    • Adds the mpool count as a prometheus metric.
  • feat: bench: flag to output GenerateWinningPoStWithVanilla params (filecoin-project/lotus#11460)

Improvements

Read more
Assets 8
Loading

v1.25.2-rc1

09 Dec 15:42
@jennijuju jennijuju
v1.25.2-rc1
4e5dfe8
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.25.2-rc1 Pre-release
Pre-release

This is the first release candidate of the upcoming optional release of Lotus v1.25.2, which was bumped from the previous v1.25.1-rc1 with the hot fix (see v1.24.1 & v1.25.1 for more details)..

This feature release includes numerous improvements and enhancements for node operators, ETH RPC-providers and storage providers.

☢️ Upgrade Warnings ☢️

There are no upgrade warnings as of this first release candidate.

⭐️ Highlights ⭐️

Lotus-Provider

The feature release ships the alpha release of the new Lotus-Provider binary, together with its initial features - High Availability of WindowPoSt and WinningPoSt.

Over the next couple of days, we will build up a catalogue of documentation for how you can test out Lotus-Provider. Once out, they will be linked in this section here, and sent as an update in the relevant Slack channels. If you are interested in testing out Lotus-Provider in your setup on the Calibration network feel free to reach out to us in the #fil-lotus-dev channel.

So what is so exciting about Lotus-Provider:

High Availability

  • You can run as many Lotus-Provider instances as you want for both WindowPoSt and WinningPOSt.
  • You can connect them to as many clustered Yugabyte instances as you want to. This allows for an NxN configuration where all instances can communicate with all others.
  • You have the option to connect different instances to different chain daemons.

Simplicity

  • Once the configuration is in the database, setting up a new machine with Lotus-Provider is straightforward. Simply start the binary with the correct flags to find YugabyteDB and specify which configuration layers it should use.

Durability

  • Lotus-Provider is designed with robustness in mind. Updates to the system are handled seamlessly, ensuring that performance and stability are maintained when taking down machines in your cluster for updates.

External PC2-binaries

In this release candidate, storage providers have the ability to call external PC2-binaries during the sealing process. This allows storage providers to leverage the SupraSeal PC2 binary, which has been shown to improve sealing speed in the PC2-phase. For instance, our current benchmarks show that an NVIDIA RTX A5000 card was able to complete PC2 in approximately 2.5 minutes.

We have verified that SupraSeal PC2 functions properly with Committed Capacity (CC) sectors that are non-Synthetic, and with SyntheticPoReps that is introduced in the upcoming nv21-version.

However, we have encountered errors when using SupraSeal PC2 with deal sectors. As a result, we advise against using SupraSeal PC2 through the lotus-worker with deal sectors in the sealing pipeline, except in testing environments. We plan to update this guideline in future release candidates, once we have a fix for deal sectors.

For more information on how to use SupraSeal PC2 with your lotus-worker, as well as how to perform benchmarks using this feature, please refer to the documentation.

New features

  • feat: sturdypost work branch (filecoin-project/lotus#11405)
    • Adds the Lotus-Provider binary, and the HarmonyDB framework.
  • feat: worker: Support delegating precommit2 to external binary (filecoin-project/lotus#11185)
    • Allows for delegating PreCommit2 to an exteranl binary.
  • feat: build: Add SupraSeal-PC2 binary script (filecoin-project/lotus#11430)
    • Adds a script for building the SupraSeal-PC2 binary easily.
  • Feat: daemon: Auto remove existing chain if importing chain file or snapshot (filecoin-project/lotus#11277)
    • Auto removes the existing chain when importing a snapshot.
  • feat: Add ETA to lotus sync wait (#11211) (filecoin-project/lotus#11211)
    • Adds a ETA indicator to lotus sync wait, so you can get an estimate for how long until sync is completed.
  • feat: mpool/wdpost: Maximize feecap config (filecoin-project/lotus#9746)
    • Adds a Maximixe FeeCap Config
  • feat: Add lotus-bench cli option to stress test any binary (filecoin-project/lotus#11270)
    • Enables the Lotus-Bench to run any binary and analyze their latency and histogram distribution, track most common errors, perform stress testing under different concurrency levels and see how it works under different QPS.
  • feat: chain import: don't walk to genesis - 2-3x faster snapshot import (#11446) (filecoin-project/lotus#11446)
    • Improves Snapshot import speed, by not walking back to genesis on import.
  • feat: metric: export Mpool message count (filecoin-project/lotus#11361)
    • Adds the mpool count as a prometheus metric.
  • feat: bench: flag to output GenerateWinningPoStWithVanilla params (filecoin-project/lotus#11460)

Improvements

Read more
Assets 8
Loading

v1.25.1

09 Dec 14:48
@jennijuju jennijuju
v1.25.1
924af42
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.25.1

This is a highly recommended PATCH RELEASE. The patch release fixes the issue were node operators trying to catch up sync were unable to sync large message blocks/epochs due to an increased number of messages on the network.

This patch release allows for up to 10k messages per block. Additionally, it introduces a limit on the amount of data that can be read at once, ensuring the system can handle worst-case scenarios.

Improvements

Assets 8
Loading

v1.24.1

09 Dec 12:30
@rjan90 rjan90
v1.24.1
5da807c
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.24.1

This is a highly recommended PATCH RELEASE. The patch release fixes the issue were node operators trying to catch up sync were unable to sync large message blocks/epochs due to an increased number of messages on the network.

This patch release allows for up to 10k messages per block. Additionally, it introduces a limit on the amount of data that can be read at once, ensuring the system can handle worst-case scenarios.

Improvements

Assets 8
Loading

v1.25.1-rc1

05 Dec 21:54
@rjan90 rjan90
v1.25.1-rc1
2d75cc5
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.25.1-rc1 Pre-release
Pre-release

This is the first release candidate of the upcoming optional release of Lotus v1.25.1. This feature release includes numerous improvements and enhancements for node operators, ETH RPC-providers and storage providers.

☢️ Upgrade Warnings ☢️

There are no upgrade warnings as of this first release candidate.

⭐️ Highlights ⭐️

Lotus-Provider

The feature release ships the alpha release of the new Lotus-Provider binary, together with its initial features - High Availability of WindowPoSt and WinningPoSt.

Over the next couple of days, we will build up a catalogue of documentation for how you can test out Lotus-Provider. Once out, they will be linked in this section here, and sent as an update in the relevant Slack channels. If you are interested in testing out Lotus-Provider in your setup on the Calibration network feel free to reach out to us in the #fil-lotus-dev channel.

So what is so exciting about Lotus-Provider:

High Availability

  • You can run as many Lotus-Provider instances as you want for both WindowPoSt and WinningPOSt.
  • You can connect them to as many clustered Yugabyte instances as you want to. This allows for an NxN configuration where all instances can communicate with all others.
  • You have the option to connect different instances to different chain daemons.

Simplicity

  • Once the configuration is in the database, setting up a new machine with Lotus-Provider is straightforward. Simply start the binary with the correct flags to find YugabyteDB and specify which configuration layers it should use.

Durability

  • Lotus-Provider is designed with robustness in mind. Updates to the system are handled seamlessly, ensuring that performance and stability are maintained when taking down machines in your cluster for updates.

External PC2-binaries

In this release candidate, storage providers have the ability to call external PC2-binaries during the sealing process. This allows storage providers to leverage the SupraSeal PC2 binary, which has been shown to improve sealing speed in the PC2-phase. For instance, our current benchmarks show that an NVIDIA RTX A5000 card was able to complete PC2 in approximately 2.5 minutes.

We have verified that SupraSeal PC2 functions properly with Committed Capacity (CC) sectors that are non-Synthetic, and with SyntheticPoReps that is introduced in the upcoming nv21-version.

However, we have encountered errors when using SupraSeal PC2 with deal sectors. As a result, we advise against using SupraSeal PC2 through the lotus-worker with deal sectors in the sealing pipeline, except in testing environments. We plan to update this guideline in future release candidates, once we have a fix for deal sectors.

For more information on how to use SupraSeal PC2 with your lotus-worker, as well as how to perform benchmarks using this feature, please refer to the documentation.

New features

  • feat: sturdypost work branch (filecoin-project/lotus#11405)
    • Adds the Lotus-Provider binary, and the HarmonyDB framework.
  • feat: worker: Support delegating precommit2 to external binary (filecoin-project/lotus#11185)
    • Allows for delegating PreCommit2 to an exteranl binary.
  • feat: build: Add SupraSeal-PC2 binary script (filecoin-project/lotus#11430)
    • Adds a script for building the SupraSeal-PC2 binary easily.
  • Feat: daemon: Auto remove existing chain if importing chain file or snapshot (filecoin-project/lotus#11277)
    • Auto removes the existing chain when importing a snapshot.
  • feat: Add ETA to lotus sync wait (#11211) (filecoin-project/lotus#11211)
    • Adds a ETA indicator to lotus sync wait, so you can get an estimate for how long until sync is completed.
  • feat: mpool/wdpost: Maximize feecap config (filecoin-project/lotus#9746)
    • Adds a Maximixe FeeCap Config
  • feat: Add lotus-bench cli option to stress test any binary (filecoin-project/lotus#11270)
    • Enables the Lotus-Bench to run any binary and analyze their latency and histogram distribution, track most common errors, perform stress testing under different concurrency levels and see how it works under different QPS.
  • feat: chain import: don't walk to genesis - 2-3x faster snapshot import (#11446) (filecoin-project/lotus#11446)
    • Improves Snapshot import speed, by not walking back to genesis on import.
  • feat: metric: export Mpool message count (filecoin-project/lotus#11361)
    • Adds the mpool count as a prometheus metric.
  • feat: bench: flag to output GenerateWinningPoStWithVanilla params (filecoin-project/lotus#11460)

Improvements

Read more
Assets 2
Loading

v1.25.0

22 Nov 13:46
@jennijuju jennijuju
v1.25.0
7e6b20c
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.25.0

This is a highly recommended feature release of Lotus. This optional release supports the Filecoin network version 21 upgrade, codenamed Watermelon 🍉, in addition to the numerous improvements and enhancements for node operators, ETH RPC-providers and storage providers.

The Filecoin network upgrade v21, codenamed Watermelon 🍉, is at epoch 3469380 - 2023-12-12T13:30:00Z

The full list of protocol improvements delivered in the network upgrade can be found here.

☢️ Upgrade Warnings ☢️

  • Read through the changelog of the mandatory v1.24.0 release. Especially the Migration and v12 Builtin Actor Bundle sections.
  • Please remove and clone a new Lotus repo (git clone https://github.com/filecoin-project/lotus.git) when upgrading to this release.
  • This feature release requires a minimum Go version of v1.20.7 or higher to successfully build Lotus. Go version 1.21.x is not supported yet.
  • EthRPC providers, please check out the new tracing API to Lotus RPC

⭐️ Highlights ⭐️

Unsealing bugfixes and enhancements

This feature release introduces significant improvements and bugfixes with regards to unsealing, and ensures that unsealing operates as one would expect. Consequently, unsealing of all sector types (deal sectors, snap-sectors without sector keys, and snap-sectors with sector keys) now all function seamlessly.

Some additional unsealing improvements are:

  • Unsealing on workers with only sealing paths works. 🎉
  • Transferring unsealed files to long-term storage upon successful unsealing. ➡️
  • Ensuring no residual files in sealing paths post a successful unsealing operation. 🧹

SupraSeal C2

Lotus-workers can now be built to leverage the SupraSeal C2 sealing optimizations in your sealing pipeline. The code optimizations are currently behind the FFI_USE_CUDA_SUPRASEAL feature flag. We advice users to test this feature on a test-network, before trying to use it on the mainnet. Users can test out the feature by building their lotus-workers by exporting the FFI_USE_CUDA_SUPRASEAL=1 enviroment variable, and building from source. For questions about the SupraSeal C2 sealing optimizations, reach out in the #fil-proofs or the #dsa-sealing slack channel.

New features

Improvements

Dependencies

Read more
Assets 8
Loading

v1.24.0

22 Nov 10:49
@aarshkshah1992 aarshkshah1992
v1.24.0
7c09348
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.24.0

This is the stable release for the upcoming MANDATORY Filecoin network upgrade v21, codenamed Watermelon 🍉, at epoch 3469380 - 2023-12-12T13:30:00Z.

The Filecoin network version 21 delivers the following FIPs:

Full list of the other protocol improvements we are delivering can be found here.

☢️ Upgrade Warnings ☢️

This feature release requires a minimum Go version of v1.20.7 or higher to successfully build Lotus. Go version 1.21.x is not supported yet.

v12 Builtin Actor Bundles

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

./lotus state actor-cids --network-version 21
Network Version: 21
Actor Version: 12
Manifest CID: bafy2bzaceapkgfggvxyllnmuogtwasmsv5qi2qzhc2aybockd6kag2g5lzaio

Actor             CID  
datacap           bafk2bzacebpiwb2ml4qbnnaayxumtk43ryhc63exdgnhivy3hwgmzemawsmpq
paymentchannel    bafk2bzacectv4cm47bnhga5febf3lo3fq47g72kmmp2xd5s6tcxz7hiqdywa4
storagemarket     bafk2bzacedylkg5am446lcuih4voyzdn4yjeqfsxfzh5b6mcuhx4mok5ph5c4
storagepower      bafk2bzacecsij5tpfzjpfuckxvccv2p3bdqjklkrfyyoei6lx5dyj5j4fvjm6
cron              bafk2bzacechxjkfe2cehx4s7skj3wzfpzf7zolds64khrrrs66bhazsemktls
eam               bafk2bzaceb3elj4hfbbjp7g5bptc7su7mptszl4nlqfedilxvstjo5ungm6oe
ethaccount        bafk2bzaceb4gkau2vgsijcxpfuq33bd7w3efr2rrhxrwiacjmns2ntdiamswq
reward            bafk2bzacealqnxn5lwzwexd6reav4dppypquklx2ujlnvaxiqk2tzstyvkp5u
verifiedregistry  bafk2bzacedudgflxc75c77c6zkmfyq4u2xuk7k6xw6dfdccarjrvxx453b77q
evm               bafk2bzacecmnyfiwb52tkbwmm2dsd7ysi3nvuxl3lmspy7pl26wxj4zj7w4wi
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
storageminer      bafk2bzacedo75pabe4i2l3hvhtsjmijrcytd2y76xwe573uku25fi7sugqld6
system            bafk2bzacebfqrja2hip7esf4eafxjmu6xcogoqu5xxtgdg7xa5szgvvdguchu
account           bafk2bzaceboftg75mdiba7xbo2i3uvgtca4brhnr3u5ptihonixgpnrvhpxoa
init              bafk2bzacebllyegx5r6lggf6ymyetbp7amacwpuxakhtjvjtvoy2bfkzk3vms

Migration

We are expecting a heavier than normal state migration for this upgrade due to the amount of state changes introduced for miner sector info. (This is a similar migration as the Shark upgrade, however, we have introduced a couple of migration performance optimizations since then for a smoother upgrade experience.)

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 180 epochs before the upgrade, around 2023-12-12T12:00:00Z. It will take around 20-30 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 (during our testing, it topped out about 20% RAM(htop) on a 1TiB box).

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.

Note to full archival node operators: you may expect it takes some time for the node to complete the final migration, during this period your node will fall out of sync and your chain service may have some disruption. However, you can expect the node to catch up soon after the migration completes. You can test out the migration by running the following on your node in offline mode:

  1. lotus chain head | head -n1
  2. Stop Lotus daemon
  3. ./lotus-shed migrate-state --repo=[path-to-your-lotus-repo] 21 [output-of-step-1]

You can check out the tutorial for benchmarking the network migration here.

BREAKING CHANGE

There is a new protocol limit on how many partition could be submited in one PoSt - if you have any customized tooling for batching PoSts, please update accordingly.

New features

Improvements

Dependencies

Snapshots

The Forest team at Chainsafe has launched a brand new lightweight snapshot service that is backed up by forest nodes! This is a great alternative service along with the fil-infra one, and it is compatible with lotus! We recommend lotus users to check it out here!

Assets 8
Loading

v1.25.0-rc5

16 Nov 20:04
@jennijuju jennijuju
v1.25.0-rc5
44c27f7
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.25.0-rc5 Pre-release
Pre-release

This is the fifth release candidate of the upcoming OPTIONAL release Lotus v1.25.0. This optional release also supports the Filecoin network version 21 upgrade, codenamed Watermelon 🍉, in addition to the numerous improvements and enhancements for node operators, ETH RPC-providers and storage providers.

❗ Mainnet Upgrade Date Update

Mainnet upgrade date has been adjusted due to the rescope of nv21 & retesting on test network, as well as giving the community enough time to upgrade their infrastructure.

The new date and epoch for the Mainnet nv21 upgrade has therefore been set to epoch 3469380 - 2023-12-12T13:30:00Z.

FIP0070 descoped for nv21

FIP0070: Allow SPs to move partitions between deadlines was originally scoped for network version 21. However, during the testing on calibrationnet testing, this FIP has proven to be quite error prune to implement due to the complexity of the protocol and a couple bugs were discovered.

As the path to resolving this bug is not yet clear, core devs have decided to descope FIP-0070 from the upcoming nv21 upgrade ensure the security and stability of the network post upgrade.

Calibration WatermelonFix2

For the calibration network, the descoping of FIP0070 means that we will need to do another CodeCID migration to drop FIP0070 from nv21, and to get the test network into a state which will be similar to when the mainnet upgrades to nv21.

This migration will happen at epoch 1108174 - 2023-11-21T13:00:00Z.

Make sure to upgrade you calibration network nodes and storage providers to v1.24.0-rcx & ^ before this epoch.

☢️ Upgrade Warnings ☢️

  • Please remove and clone a new Lotus repo (git clone https://github.com/filecoin-project/lotus.git) when upgrading to this version.
  • This feature release requires a minimum Go version of v1.20.7 or higher to successfully build Lotus. Go version 1.21.x is not supported yet.
  • EthRPC providers, please check out the new tracing API to Lotus RPC

⭐️ Highlights ⭐️

Unsealing bugfixes and enhancements

This feature release introduces significant improvements and bugfixes with regards to unsealing, and ensures that unsealing operates as one would expect. Consequently, unsealing of all sector types (deal sectors, snap-sectors without sector keys, and snap-sectors with sector keys) now all function seamlessly.

Some additional unsealing improvements are:

  • Unsealing on workers with only sealing paths works. 🎉
  • Transferring unsealed files to long-term storage upon successful unsealing. ➡️
  • Ensuring no residual files in sealing paths post a successful unsealing operation. 🧹

SupraSeal C2

Lotus-workers can now be built to leverage the SupraSeal C2 sealing optimizations in your sealing pipeline. The code optimizations are currently behind the FFI_USE_CUDA_SUPRASEAL feature flag. We advice users to test this feature on a test-network, before trying to use it on the mainnet. Users can test out the feature by building their lotus-workers by exporting the FFI_USE_CUDA_SUPRASEAL=1 enviroment variable, and building from source. For questions about the SupraSeal C2 sealing optimizations, reach out in the #fil-proofs or the #dsa-sealing slack channel.

New features

Improvements

Read more
Assets 8
Loading