Skip to content

Releases: filecoin-project/lotus

v1.28.0-rc3

04 Jul 20:46
69c83c3
Compare
Choose a tag to compare
v1.28.0-rc3 Pre-release
Pre-release

This is the third release candidate of the upcoming MANDATORY Lotus v1.28.0 release, which will deliver the Filecoin network version 23, codenamed Waffle 🧇.

This release candidate sets the calibration network to upgrade at epoch 1779094, corresponding to 2024-07-11T12:00:00Z. This release does NOT set the mainnet upgrade epoch yet, in which will be updated in the final release.

Compared to Lotus v1.28.0-rc2, the Lotus v1.28.0-rc3 introduces the manifest for the "control" nodes for F3 passive testing. This change shouldn't have any impact on production nodes.

☢️ Upgrade Warnings ☢️

If you are running the v1.26.0 or an earlier version of Lotus, please go through the Upgrade Warnings section for the v1.27.* releases, before upgrading to this RC.

  • This upgrade includes an additional migration to the events database. Node operators running Lotus with events turned on (off by default) may experience some delay in initial start-up of Lotus as a minor database migration takes place. See filecoin-project/lotus#12080 for full details.

The Filecoin network version 23 delivers the following FIPs:

Note that we are only doing a "soft launch"/"passive testing" for F3 (Fast Finality) i.e. FIP-0086 in NV23. Please see this doc for more details.

v14 Builtin Actor Bundle

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

lotus state actor-cids --network-version=23
Network Version: 23
Actor Version: 14
Manifest CID: bafy2bzacebq3hncszqpojglh2dkwekybq4zn6qpc4gceqbx36wndps5qehtau

Actor             CID  
account           bafk2bzaced5ecfm56dvtw26q56j4d32yoccyd7ggxn3qdki2enxpqqav45ths
cron              bafk2bzacedpbtttpyvtjncqoyobr63mhqqtlrygbnudhxyp2vha56f626dkfs
datacap           bafk2bzacecded3lcvo7ndsk66samyecw2trnhrgzi7jxsary3sqgopxlk6rku
eam               bafk2bzacecsda4uw7dcu76a27gnrrdcm73tgms7wrte6jbou63vloktkqc5ne
ethaccount        bafk2bzacebu2lcxfmohomjj3umslnylwugf5gssywdq3575tjarta7o227dls
evm               bafk2bzacea4xnekruhfmdnzvzeo6cbf7jsfgco6x5wje2ckwc2ui2ojzcrlgu
init              bafk2bzacedfmsdlewihdcrkdepnfata26nj7akbvexzs3chicujhjf2uxsazc
multisig          bafk2bzacedwx4svscsp6wqqu2vlcunjihvvm4u2jnsqjkwutjhir7dwtl7z6m
paymentchannel    bafk2bzacedbit7oo6lryhbo64uikvtjtfcth6oxwy3eebxerenu2h7rj44n24
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzaced5rlycj7fzpscfc7p3wwxarngwqylqshj7te3uffey5tevunz4we
storagemarket     bafk2bzaceatwbyrec2nnwggxc2alpqve7rl52fmbhqflebuxmmnvg3qckjb7c
storageminer      bafk2bzacecr7ozkdz7l2pq3ig5qxae2ysivbnojhsn4gw3o57ov4mhksma7me
storagepower      bafk2bzacedgeolvjtnw7fkji5kqmx322abv6uls2v34fuml6nw36dvfcw4mtu
system            bafk2bzacederl6tlpieldsn6mkndqwd4wj5orfoqgab6p2klswfn3cjagxwla
verifiedregistry  bafk2bzaceczw2kp6gjjdcjbso7mewp7guik7gr525pal6dotdja2lrct6ok3c

Migration

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 120 epochs before the network upgrade. The migration for the NV23 upgrade is expected to be light with no heavy pre-migrations, here are some expected timings and resource consumption numbers:

  • Pre-Migration is expected to take less then 1 minute
  • The migration is expected to take less then 30 seconds on a node with a NVMe-drive and a newer CPU. For nodes running on slower disks/CPU, it is still expected to take less then 1 minute.

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.

For certain node operators, such as full archival nodes or systems that need to keep large amounts of state (RPC providers), we recommend skipping the pre-migration and run the non-cached migration (i.e., just running the migration at the network upgrade epoch), and schedule for some additional downtime. Operators of such nodes can read the How to disable premigration in network upgrade tutorial.

Dependencies

  • github.com/filecoin-project/go-state-types (v0.14.0-dev -> v0.14.0-rc5)
  • github.com/filecoin-project/filecoin-ffi (v1.27.0-rc2 -> v1.28.0-rc2)
  • ref-fvm4 (as part of filecoin-ffi) (4.2.0 -> 4.3.1)
  • A new github.com/filecoin-project/go-f3 dependency for F3 soft launch (v0.0.2)

Others

  • Soft launch of F3 (#12119)
  • NI-PoRep changes (#12130)
  • Fixes for the ETH events API (#12080)
  • Support for legacy Ethereum transactions (#11969)
  • Ignore market balance after nv23 (#11976)
  • Add finality-related params for eth_getBlockByNumber (#12110)
  • rename Actor.Address to Actor.DelegatedAddress and only use it for f4 addresses (#12155)
  • feat:ec: integrate F3 dynamic manifest #12185

v1.28.0-rc2

04 Jul 20:08
d9c24f6
Compare
Choose a tag to compare
v1.28.0-rc2 Pre-release
Pre-release

This is the second release candidate of the upcoming MANDATORY Lotus v1.28.0 release, which will deliver the Filecoin network version 23, codenamed Waffle 🧇.

This release candidate sets the calibration network to upgrade at epoch 1779094, corresponding to 2024-07-11T12:00:00Z. This release does NOT set the mainnet upgrade epoch yet, in which will be updated in the final release.

☢️ Upgrade Warnings ☢️

  • If you are running the v1.26.x or an earlier version of Lotus, please go through the Upgrade Warnings section for the v1.27.* releases, before upgrading to this RC.
  • This upgrade includes an additional migration to the events database. Node operators running Lotus with events turned on (off by default) may experience some delay in initial start-up of Lotus as a minor database migration takes place. See filecoin-project/lotus#12080 for full details.

The Filecoin network version 23 delivers the following FIPs:

Note that we are only doing a "soft launch"/"passive testing" for F3 (Fast Finality) i.e. FIP-0086 in NV23. Please see this doc for more details.

v14 Builtin Actor Bundle

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

lotus state actor-cids --network-version=23
Network Version: 23
Actor Version: 14
Manifest CID: bafy2bzacebq3hncszqpojglh2dkwekybq4zn6qpc4gceqbx36wndps5qehtau

Actor             CID  
account           bafk2bzaced5ecfm56dvtw26q56j4d32yoccyd7ggxn3qdki2enxpqqav45ths
cron              bafk2bzacedpbtttpyvtjncqoyobr63mhqqtlrygbnudhxyp2vha56f626dkfs
datacap           bafk2bzacecded3lcvo7ndsk66samyecw2trnhrgzi7jxsary3sqgopxlk6rku
eam               bafk2bzacecsda4uw7dcu76a27gnrrdcm73tgms7wrte6jbou63vloktkqc5ne
ethaccount        bafk2bzacebu2lcxfmohomjj3umslnylwugf5gssywdq3575tjarta7o227dls
evm               bafk2bzacea4xnekruhfmdnzvzeo6cbf7jsfgco6x5wje2ckwc2ui2ojzcrlgu
init              bafk2bzacedfmsdlewihdcrkdepnfata26nj7akbvexzs3chicujhjf2uxsazc
multisig          bafk2bzacedwx4svscsp6wqqu2vlcunjihvvm4u2jnsqjkwutjhir7dwtl7z6m
paymentchannel    bafk2bzacedbit7oo6lryhbo64uikvtjtfcth6oxwy3eebxerenu2h7rj44n24
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzaced5rlycj7fzpscfc7p3wwxarngwqylqshj7te3uffey5tevunz4we
storagemarket     bafk2bzaceatwbyrec2nnwggxc2alpqve7rl52fmbhqflebuxmmnvg3qckjb7c
storageminer      bafk2bzacecr7ozkdz7l2pq3ig5qxae2ysivbnojhsn4gw3o57ov4mhksma7me
storagepower      bafk2bzacedgeolvjtnw7fkji5kqmx322abv6uls2v34fuml6nw36dvfcw4mtu
system            bafk2bzacederl6tlpieldsn6mkndqwd4wj5orfoqgab6p2klswfn3cjagxwla
verifiedregistry  bafk2bzaceczw2kp6gjjdcjbso7mewp7guik7gr525pal6dotdja2lrct6ok3c

Migration

All node operators, including storage providers, should be aware that ONE pre-migration is being scheduled 120 epochs before the network upgrade. The migration for the NV23 upgrade is expected to be light with no heavy pre-migrations, here are some expected timings and resource consumption numbers:

  • Pre-Migration is expected to take less then 1 minute
  • The migration is expected to take less then 30 seconds on a node with a NVMe-drive and a newer CPU. For nodes running on slower disks/CPU, it is still expected to take less then 1 minute.

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.

For certain node operators, such as full archival nodes or systems that need to keep large amounts of state (RPC providers), we recommend skipping the pre-migration and run the non-cached migration (i.e., just running the migration at the network upgrade epoch), and schedule for some additional downtime. Operators of such nodes can read the How to disable premigration in network upgrade tutorial.

Dependencies

  • github.com/filecoin-project/go-state-types (v0.14.0-dev -> v0.14.0-rc5)
  • github.com/filecoin-project/filecoin-ffi (v1.27.0-rc2 -> v1.28.0-rc2)
  • ref-fvm4 (as part of filecoin-ffi) (4.2.0 -> 4.3.1)
  • A new github.com/filecoin-project/go-f3 dependency for F3 soft launch (v0.0.2)

Others

  • Soft launch of F3 (#12119)
  • NI-PoRep changes (#12130)
  • Fixes for the ETH events API (#12080)
  • Support for legacy Ethereum transactions (#11969)
  • Ignore market balance after nv23 (#11976)
  • Add finality-related params for eth_getBlockByNumber (#12110)
  • rename Actor.Address to Actor.DelegatedAddress and only use it for f4 addresses (#12155)

v1.28.0-rc1

01 Jul 10:46
85abc61
Compare
Choose a tag to compare
v1.28.0-rc1 Pre-release
Pre-release

This is the first release candidate of the upcoming MANDATORY Lotus v1.28.0 release, which will deliver the Filecoin network version 23, codenamed Waffle 🧇

This release candidate does NOT set a calibration network upgrade epoch, it will be added in the second release candidate, expected to be released July 4th. This release candidate does NOT set the mainnet upgrade epoch yet, which will be updated in the final release.

☢️ Upgrade Warnings ☢️

If you are running the v1.26.0 or an earlier version of Lotus, please go through the Upgrade Warnings section for the v1.27.* releases, before upgrading to this RC.

The Filecoin network version 23 delivers the following FIPs:

Note that we are only doing a "soft launch"/"passive testing" for F3 (Fast Finality) i.e. FIP-0086 in NV23. Please see this doc for more details.

v14 Builtin Actor Bundle

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

lotus state actor-cids --network-version=23
Network Version: 23
Actor Version: 14
Manifest CID: bafy2bzacebq3hncszqpojglh2dkwekybq4zn6qpc4gceqbx36wndps5qehtau

Actor             CID  
account           bafk2bzaced5ecfm56dvtw26q56j4d32yoccyd7ggxn3qdki2enxpqqav45ths
cron              bafk2bzacedpbtttpyvtjncqoyobr63mhqqtlrygbnudhxyp2vha56f626dkfs
datacap           bafk2bzacecded3lcvo7ndsk66samyecw2trnhrgzi7jxsary3sqgopxlk6rku
eam               bafk2bzacecsda4uw7dcu76a27gnrrdcm73tgms7wrte6jbou63vloktkqc5ne
ethaccount        bafk2bzacebu2lcxfmohomjj3umslnylwugf5gssywdq3575tjarta7o227dls
evm               bafk2bzacea4xnekruhfmdnzvzeo6cbf7jsfgco6x5wje2ckwc2ui2ojzcrlgu
init              bafk2bzacedfmsdlewihdcrkdepnfata26nj7akbvexzs3chicujhjf2uxsazc
multisig          bafk2bzacedwx4svscsp6wqqu2vlcunjihvvm4u2jnsqjkwutjhir7dwtl7z6m
paymentchannel    bafk2bzacedbit7oo6lryhbo64uikvtjtfcth6oxwy3eebxerenu2h7rj44n24
placeholder       bafk2bzacedfvut2myeleyq67fljcrw4kkmn5pb5dpyozovj7jpoez5irnc3ro
reward            bafk2bzaced5rlycj7fzpscfc7p3wwxarngwqylqshj7te3uffey5tevunz4we
storagemarket     bafk2bzaceatwbyrec2nnwggxc2alpqve7rl52fmbhqflebuxmmnvg3qckjb7c
storageminer      bafk2bzacecr7ozkdz7l2pq3ig5qxae2ysivbnojhsn4gw3o57ov4mhksma7me
storagepower      bafk2bzacedgeolvjtnw7fkji5kqmx322abv6uls2v34fuml6nw36dvfcw4mtu
system            bafk2bzacederl6tlpieldsn6mkndqwd4wj5orfoqgab6p2klswfn3cjagxwla
verifiedregistry  bafk2bzaceczw2kp6gjjdcjbso7mewp7guik7gr525pal6dotdja2lrct6ok3c

Migration

The NV23 upgrade migration is expected to be extremely light as only FIP-0085 requires a migration. We don't expect null tipsets after the upgrade epoch or heavy block validation times. We will updated this sections once we have run the final benchmarks.

Dependencies

  • github.com/filecoin-project/go-state-types (v0.14.0-dev -> v0.14.0-rc5)
  • github.com/filecoin-project/filecoin-ffi (v1.27.0-rc2 -> v1.28.0-rc2)
  • ref-fvm4 (as part of filecoin-ffi) (4.2.0 -> 4.3.1)
  • A new github.com/filecoin-project/go-f3 dependency for F3 soft launch (v0.0.2)

Others

  • Soft launch of F3 (#12119)
  • NI-PoRep changes (#12130)
  • Fixes for the ETH events API (#12080)
  • Support for legacy Ethereum transactions (#11969)
  • Ignore market balance after nv23 (#11976)
  • Add finality-related params for eth_getBlockByNumber (#12110)
  • rename Actor.Address to Actor.DelegatedAddress and only use it for f4 addresses (#12155)

v1.27.1

25 Jun 02:33
36d9634
Compare
Choose a tag to compare

This release, v1.27.1, is an OPTIONAL lotus release. It is HIGHLY RECOMMENDED for node operators that are building Filecoin index off lotus!

☢️ Upgrade Warnings ☢️

  • This Lotus release completely removes the Legacy Lotus/Lotus-Miner Markets sub-system from the codebase, which was announced to reach EOL on January 31, 2023.
  • The Curio Storage software, designed to simplify the setup and operation of storage providers, has moved to their own Github-repository: https://github.com/filecoin-project/curio.
  • The events subsystem includes some minor correctness fixes and performance improvements. Nodes operators running Lotus with events turned on (off by default) may experience some delay in initial start-up as a minor database migration takes place and the write-ahead log is compacted. See filecoin-project/lotus#11952 and filecoin-project/lotus#12090 for full details.
    • As the events database migration is relatively straightforward in this upgrade, it may be possible to undo the migration for users needing to downgrade specifically from v1.27.1 to v1.27.0, although you are advised to have backups of your Lotus repo before attempting this. Details can be found at: #12073 (comment)

JSON-RPC 2.0 Specification Conformance

The JSON-RPC 2.0 specification requires that a "result" property be present in the case of no error from an API call. This release ensures that all API calls that return a result have a "result" property in the response. This is a behaviour change over Lotus v1.26 and will impact any API call that only has a single error return value, where no error has occurred.

For example, a successful WalletSetDefault in v1.26 would return:

{
  "jsonrpc": "2.0",
  "id": 1
}

As of this change, in conformance with the JSON-RPC 2.0 specification it will return:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": null
}

There is no change in the behaviour when a call returns an error, as the error object will still be present in the response.

New features

Improvements

Dependencies

Lotus-Miner / Curio related changes

Others

Read more

v1.27.1-rc3

20 Jun 14:15
efaa998
Compare
Choose a tag to compare
v1.27.1-rc3 Pre-release
Pre-release

This is the third release candidate of the upcoming optional release of Lotus v1.27.1.

☢️ Upgrade Warnings ☢️

  • This Lotus release completely removes the Legacy Lotus/Lotus-Miner Markets sub-system from the codebase, which was announced to reach EOL on January 31, 2023.
  • The Curio Storage software, designed to simplify the setup and operation of storage providers, has moved to their own Github-repository: https://github.com/filecoin-project/curio.

JSON-RPC 2.0 Specification Conformance

The JSON-RPC 2.0 specification requires that a "result" property be present in the case of no error from an API call. This release ensures that all API calls that return a result have a "result" property in the response. This is a behaviour change over Lotus v1.26 and will impact any API call that only has a single error return value, where no error has occurred.

For example, a successful WalletSetDefault in v1.26 would return:

{
  "jsonrpc": "2.0",
  "id": 1
}

As of this change, in conformance with the JSON-RPC 2.0 specification it will return:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": null
}

There is no change in the behaviour when a call returns an error, as the error object will still be present in the response.

New features

Improvements

Dependencies

Lotus-Miner / Curio related changes

Others

Read more

v1.27.1-rc2

19 Jun 16:58
82e35e9
Compare
Choose a tag to compare
v1.27.1-rc2 Pre-release
Pre-release

This is the second release candidate of the upcoming optional release of Lotus v1.27.1

☢️ Upgrade Warnings ☢️

  • This Lotus release completely removes the Legacy Lotus/Lotus-Miner Markets sub-system from the codebase, which was announced to reach EOL on January 31, 2023.
  • The Curio Storage software, designed to simplify the setup and operation of storage providers, has moved to their own Github-repository: https://github.com/filecoin-project/curio.

JSON-RPC 2.0 Specification Conformance

The JSON-RPC 2.0 specification requires that a "result" property be present in the case of no error from an API call. This release ensures that all API calls that return a result have a "result" property in the response. This is a behaviour change over Lotus v1.26 and will impact any API call that only has a single error return value, where no error has occurred.

For example, a successful WalletSetDefault in v1.26 would return:

{
  "jsonrpc": "2.0",
  "id": 1
}

As of this change, in conformance with the JSON-RPC 2.0 specification it will return:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": null
}

There is no change in the behaviour when a call returns an error, as the error object will still be present in the response.

New features

Improvements

Dependencies

Lotus-Miner / Curio related changes

Others

Read more

v1.27.1-rc1

11 Jun 13:39
6e13eac
Compare
Choose a tag to compare
v1.27.1-rc1 Pre-release
Pre-release

This is the first release candidate of the upcoming optional release of Lotus v1.27.1

☢️ Upgrade Warnings ☢️

There are no upgrade warnings for this release candidate.

JSON-RPC 2.0 Specification Conformance

The JSON-RPC 2.0 specification requires that a "result" property be present in the case of no error from an API call. This release ensures that all API calls that return a result have a "result" property in the response. This is a behaviour change over Lotus v1.26 and will impact any API call that only has a single error return value, where no error has occurred.

For example, a successful WalletSetDefault in v1.26 would return:

{
  "jsonrpc": "2.0",
  "id": 1
}

As of this change, in conformance with the JSON-RPC 2.0 specification it will return:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": null
}

There is no change in the behaviour when a call returns an error, as the error object will still be present in the response.

New features

Improvements

Dependencies

Lotus-Miner / Curio related changes

Others

Read more

v1.27.0

28 May 13:03
2baca01
Compare
Choose a tag to compare

This is an optional feature release of Lotus. Lotus v1.27.0 includes numerous improvements, bugfixes and enhancements for node operators, RPC- and ETH RPC-providers. This feature release also introduces Curio in a 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 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.

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.

Checkout this Github Dicsussion thread for testing Curio in developer network: #11991

New features

Improvements

Read more

v1.27.0-rc3

17 May 07:21
4daac14
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

v1.27.0-rc2

08 May 06:22
bbcad8a
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