Reference implementation of the Filecoin protocol, written in Go
OTHER License
Bot releases are hidden (Show)
This is the fourth 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-rc3, the Lotus v1.28.0-rc4
release addresses an issue that allows us to publish Docker builds.
☢️ Upgrade Warnings ☢️
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.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.
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
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:
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.
v0.14.0-dev
-> v0.14.0-rc5
)v1.27.0-rc2
-> v1.28.0-rc2
)ref-fvm4
(as part of filecoin-ffi
) (4.2.0
-> 4.3.1
)github.com/filecoin-project/go-f3
dependency for F3 soft launch (v0.0.2
)eth_getBlockByNumber
(https://github.com/filecoin-project/lotus/pull/12110)Actor.Address
to Actor.DelegatedAddress
and only use it for f4 addresses (https://github.com/filecoin-project/lotus/pull/12155)Published by jennijuju 3 months ago
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.
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.
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
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:
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.
v0.14.0-dev
-> v0.14.0-rc5
)v1.27.0-rc2
-> v1.28.0-rc2
)ref-fvm4
(as part of filecoin-ffi
) (4.2.0
-> 4.3.1
)github.com/filecoin-project/go-f3
dependency for F3 soft launch (v0.0.2
)eth_getBlockByNumber
(https://github.com/filecoin-project/lotus/pull/12110)Actor.Address
to Actor.DelegatedAddress
and only use it for f4 addresses (https://github.com/filecoin-project/lotus/pull/12155)Published by rjan90 3 months ago
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 ☢️
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.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.
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
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:
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.
v0.14.0-dev
-> v0.14.0-rc5
)v1.27.0-rc2
-> v1.28.0-rc2
)ref-fvm4
(as part of filecoin-ffi
) (4.2.0
-> 4.3.1
)github.com/filecoin-project/go-f3
dependency for F3 soft launch (v0.0.2
)eth_getBlockByNumber
(https://github.com/filecoin-project/lotus/pull/12110)Actor.Address
to Actor.DelegatedAddress
and only use it for f4 addresses (https://github.com/filecoin-project/lotus/pull/12155)Published by aarshkshah1992 4 months ago
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.
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.
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
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.
v0.14.0-dev
-> v0.14.0-rc5
)v1.27.0-rc2
-> v1.28.0-rc2
)ref-fvm4
(as part of filecoin-ffi
) (4.2.0
-> 4.3.1
)github.com/filecoin-project/go-f3
dependency for F3 soft launch (v0.0.2
)eth_getBlockByNumber
(https://github.com/filecoin-project/lotus/pull/12110)Actor.Address
to Actor.DelegatedAddress
and only use it for f4 addresses (https://github.com/filecoin-project/lotus/pull/12155)Published by jennijuju 4 months ago
This release, v1.27.1, is an OPTIONAL lotus release. It is HIGHLY RECOMMENDED for node operators that are building Filecoin index off lotus!
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.
trace_transaction
(filecoin-project/lotus#12068)Published by jennijuju 4 months ago
This is the third release candidate of the upcoming optional release of Lotus v1.27.1.
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.
trace_transaction
(filecoin-project/lotus#12068)Contributor | Commits | Lines ± | Files Changed |
---|---|---|---|
Aarsh Shah | 9 | +5710/-35899 | 201 |
Łukasz Magiera | 21 | +1891/-33776 | 335 |
LexLuthr | 9 | +4916/-1637 | 107 |
Phi-rjan | 9 | +3544/-187 | 92 |
Rod Vagg | 15 | +2183/-479 | 164 |
Piotr Galar | 6 | +130/-2386 | 30 |
Andrew Jackson (Ajax) | 6 | +1072/-533 | 63 |
ZenGround0 | 1 | +235/-13 | 3 |
Hubert Bugaj | 3 | +57/-37 | 5 |
Steven Allen | 3 | +25/-15 | 6 |
Peter Rabbitson | 1 | +16/-8 | 4 |
tomfees | 1 | +6/-6 | 5 |
imxyb | 1 | +6/-0 | 1 |
yumeiyin | 1 | +2/-2 | 2 |
galargh | 1 | +2/-2 | 1 |
Published by jennijuju 4 months ago
This is the second release candidate of the upcoming optional release of Lotus v1.27.1
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.
trace_transaction
(filecoin-project/lotus#12068)Contributor | Commits | Lines ± | Files Changed |
---|---|---|---|
Aarsh Shah | 9 | +5710/-35899 | 201 |
Łukasz Magiera | 21 | +1891/-33776 | 335 |
LexLuthr | 9 | +4916/-1637 | 107 |
Phi-rjan | 9 | +3544/-187 | 92 |
Rod Vagg | 15 | +2183/-479 | 164 |
Piotr Galar | 6 | +130/-2386 | 30 |
Andrew Jackson (Ajax) | 6 | +1072/-533 | 63 |
ZenGround0 | 1 | +235/-13 | 3 |
Hubert Bugaj | 3 | +57/-37 | 5 |
Steven Allen | 3 | +25/-15 | 6 |
Peter Rabbitson | 1 | +16/-8 | 4 |
tomfees | 1 | +6/-6 | 5 |
imxyb | 1 | +6/-0 | 1 |
yumeiyin | 1 | +2/-2 | 2 |
galargh | 1 | +2/-2 | 1 |
Published by rjan90 4 months ago
This is the first release candidate of the upcoming optional release of Lotus v1.27.1
There are no upgrade warnings for this release candidate.
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.
trace_transaction
(filecoin-project/lotus#12068)Contributor | Commits | Lines ± | Files Changed |
---|---|---|---|
Aarsh Shah | 9 | +5710/-35899 | 201 |
Łukasz Magiera | 21 | +1891/-33776 | 335 |
LexLuthr | 9 | +4916/-1637 | 107 |
Phi-rjan | 9 | +3544/-187 | 92 |
Rod Vagg | 15 | +2183/-479 | 164 |
Piotr Galar | 6 | +130/-2386 | 30 |
Andrew Jackson (Ajax) | 6 | +1072/-533 | 63 |
ZenGround0 | 1 | +235/-13 | 3 |
Hubert Bugaj | 3 | +57/-37 | 5 |
Steven Allen | 3 | +25/-15 | 6 |
Peter Rabbitson | 1 | +16/-8 | 4 |
tomfees | 1 | +6/-6 | 5 |
imxyb | 1 | +6/-0 | 1 |
yumeiyin | 1 | +2/-2 | 2 |
galargh | 1 | +2/-2 | 1 |
Published by galargh 5 months ago
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.
This release includes a lot of improvements and fixes for indexers, RPC- and ETH RPC-providers. Specifically these PRs:
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.
Checkout this Github Dicsussion thread for testing Curio in developer network: https://github.com/filecoin-project/lotus/discussions/11991
Contributor | Commits | Lines ± | Files Changed |
---|---|---|---|
Rod Vagg | 20 | +55315/-204 | 58 |
Łukasz Magiera | 201 | +16244/-6541 | 647 |
Andrew Jackson (Ajax) | 53 | +15293/-6764 | 394 |
Phi-rjan | 6 | +12669/-4521 | 221 |
LexLuthr | 20 | +5972/-2815 | 120 |
Steven Allen | 22 | +1626/-1264 | 77 |
Piotr Galar | 9 | +790/-412 | 33 |
Aayush Rajasekaran | 4 | +642/-509 | 12 |
Lee | 1 | +601/-533 | 9 |
qwdsds | 3 | +617/-510 | 11 |
Phi | 11 | +551/-83 | 32 |
Jiaying Wang | 5 | +433/-20 | 13 |
Masih H. Derkani | 4 | +350/-101 | 18 |
Aayush | 4 | +143/-76 | 17 |
Aarsh Shah | 3 | +63/-11 | 5 |
jennijuju | 3 | +22/-22 | 12 |
hunjixin | 1 | +21/-14 | 4 |
beck | 2 | +17/-17 | 2 |
tom123222 | 2 | +28/-4 | 2 |
Ian Norden | 1 | +21/-1 | 1 |
ZenGround0 | 1 | +3/-15 | 1 |
shuangcui | 1 | +7/-7 | 6 |
Vid Bregar | 1 | +7/-4 | 2 |
writegr | 1 | +5/-5 | 5 |
Nagaprasad V R | 1 | +9/-0 | 1 |
forcedebug | 1 | +4/-4 | 4 |
parthshah1 | 2 | +6/-1 | 2 |
fuyangpengqi | 1 | +3/-3 | 3 |
Samuel Arogbonlo | 1 | +6/-0 | 2 |
GlacierWalrus | 1 | +0/-6 | 1 |
Aloxaf | 1 | +6/-0 | 2 |
Rob Quist | 2 | +2/-3 | 3 |
wersfeds | 1 | +2/-2 | 1 |
Jon | 1 | +2/-0 | 1 |
0x5459 | 1 | +1/-0 | 1 |
Published by rjan90 5 months ago
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.
This release includes a lot of improvements and fixes for indexers, RPC- and ETH RPC-providers. Specifically these PRs:
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.
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
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.
Contributor | Commits | Lines ± | Files Changed |
---|---|---|---|
Rod Vagg | 20 | +55315/-204 | 58 |
Łukasz Magiera | 201 | +16244/-6541 | 647 |
Andrew Jackson (Ajax) | 53 | +15293/-6764 | 394 |
Phi-rjan | 6 | +12669/-4521 | 221 |
LexLuthr | 20 | +5972/-2815 | 120 |
Steven Allen | 22 | +1626/-1264 | 77 |
Piotr Galar | 9 | +790/-412 | 33 |
Aayush Rajasekaran | 4 | +642/-509 | 12 |
Lee | 1 | +601/-533 | 9 |
qwdsds | 3 | +617/-510 | 11 |
Phi | 11 | +551/-83 | 32 |
Jiaying Wang | 5 | +433/-20 | 13 |
Masih H. Derkani | 4 | +350/-101 | 18 |
Aayush | 4 | +143/-76 | 17 |
Aarsh Shah | 3 | +63/-11 | 5 |
jennijuju | 3 | +22/-22 | 12 |
hunjixin | 1 | +21/-14 | 4 |
beck | 2 | +17/-17 | 2 |
tom123222 | 2 | +28/-4 | 2 |
Ian Norden | 1 | +21/-1 | 1 |
ZenGround0 | 1 | +3/-15 | 1 |
shuangcui | 1 | +7/-7 | 6 |
Vid Bregar | 1 | +7/-4 | 2 |
writegr | 1 | +5/-5 | 5 |
Nagaprasad V R | 1 | +9/-0 | 1 |
forcedebug | 1 | +4/-4 | 4 |
parthshah1 | 2 | +6/-1 | 2 |
fuyangpengqi | 1 | +3/-3 | 3 |
Samuel Arogbonlo | 1 | +6/-0 | 2 |
GlacierWalrus | 1 | +0/-6 | 1 |
Aloxaf | 1 | +6/-0 | 2 |
Rob Quist | 2 | +2/-3 | 3 |
wersfeds | 1 | +2/-2 | 1 |
Jon | 1 | +2/-0 | 1 |
0x5459 | 1 | +1/-0 | 1 |
Published by rjan90 5 months ago
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.
This release includes a lot of improvements and fixes for indexers, RPC- and ETH RPC-providers. Specifically these PRs:
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.
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
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.
Contributor | Commits | Lines ± | Files Changed |
---|---|---|---|
Rod Vagg | 20 | +55315/-204 | 58 |
Łukasz Magiera | 201 | +16244/-6541 | 647 |
Andrew Jackson (Ajax) | 53 | +15293/-6764 | 394 |
Phi-rjan | 6 | +12669/-4521 | 221 |
LexLuthr | 20 | +5972/-2815 | 120 |
Steven Allen | 22 | +1626/-1264 | 77 |
Piotr Galar | 9 | +790/-412 | 33 |
Aayush Rajasekaran | 4 | +642/-509 | 12 |
Lee | 1 | +601/-533 | 9 |
qwdsds | 3 | +617/-510 | 11 |
Phi | 11 | +551/-83 | 32 |
Jiaying Wang | 5 | +433/-20 | 13 |
Masih H. Derkani | 4 | +350/-101 | 18 |
Aayush | 4 | +143/-76 | 17 |
Aarsh Shah | 3 | +63/-11 | 5 |
jennijuju | 3 | +22/-22 | 12 |
hunjixin | 1 | +21/-14 | 4 |
beck | 2 | +17/-17 | 2 |
tom123222 | 2 | +28/-4 | 2 |
Ian Norden | 1 | +21/-1 | 1 |
ZenGround0 | 1 | +3/-15 | 1 |
shuangcui | 1 | +7/-7 | 6 |
Vid Bregar | 1 | +7/-4 | 2 |
writegr | 1 | +5/-5 | 5 |
Nagaprasad V R | 1 | +9/-0 | 1 |
forcedebug | 1 | +4/-4 | 4 |
parthshah1 | 2 | +6/-1 | 2 |
fuyangpengqi | 1 | +3/-3 | 3 |
Samuel Arogbonlo | 1 | +6/-0 | 2 |
GlacierWalrus | 1 | +0/-6 | 1 |
Aloxaf | 1 | +6/-0 | 2 |
Rob Quist | 2 | +2/-3 | 3 |
wersfeds | 1 | +2/-2 | 1 |
Jon | 1 | +2/-0 | 1 |
0x5459 | 1 | +1/-0 | 1 |
Published by rjan90 6 months ago
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.
This release includes a lot of improvements and fixes for indexers, RPC- and ETH RPC-providers. Specifically these PRs:
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.
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
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.
Contributor | Commits | Lines ± | Files Changed |
---|---|---|---|
Rod Vagg | 20 | +55315/-204 | 58 |
Łukasz Magiera | 201 | +16244/-6541 | 647 |
Andrew Jackson (Ajax) | 53 | +15293/-6764 | 394 |
Phi-rjan | 6 | +12669/-4521 | 221 |
LexLuthr | 20 | +5972/-2815 | 120 |
Steven Allen | 22 | +1626/-1264 | 77 |
Piotr Galar | 9 | +790/-412 | 33 |
Aayush Rajasekaran | 4 | +642/-509 | 12 |
Lee | 1 | +601/-533 | 9 |
qwdsds | 3 | +617/-510 | 11 |
Phi | 11 | +551/-83 | 32 |
Jiaying Wang | 5 | +433/-20 | 13 |
Masih H. Derkani | 4 | +350/-101 | 18 |
Aayush | 4 | +143/-76 | 17 |
Aarsh Shah | 3 | +63/-11 | 5 |
jennijuju | 3 | +22/-22 | 12 |
hunjixin | 1 | +21/-14 | 4 |
beck | 2 | +17/-17 | 2 |
tom123222 | 2 | +28/-4 | 2 |
Ian Norden | 1 | +21/-1 | 1 |
ZenGround0 | 1 | +3/-15 | 1 |
shuangcui | 1 | +7/-7 | 6 |
Vid Bregar | 1 | +7/-4 | 2 |
writegr | 1 | +5/-5 | 5 |
Nagaprasad V R | 1 | +9/-0 | 1 |
forcedebug | 1 | +4/-4 | 4 |
parthshah1 | 2 | +6/-1 | 2 |
fuyangpengqi | 1 | +3/-3 | 3 |
Samuel Arogbonlo | 1 | +6/-0 | 2 |
GlacierWalrus | 1 | +0/-6 | 1 |
Aloxaf | 1 | +6/-0 | 2 |
Rob Quist | 2 | +2/-3 | 3 |
wersfeds | 1 | +2/-2 | 1 |
Jon | 1 | +2/-0 | 1 |
0x5459 | 1 | +1/-0 | 1 |
Published by rjan90 6 months ago
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.
Published by rvagg 6 months ago
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:
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 epoch 3817920 - 2024-04-11 - 14:00:00Z
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:
wdpost with the address didn't have enough funds to send message error
error when upgrading to this version. Due to https://github.com/filecoin-project/lotus/pull/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.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
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.
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.
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:
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.
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 eventFields
within the eventFromHeight
and ToHeight
to filter events by block heightTipSetKey
to restrict events contained within a specific tipsetGetActorEventsRaw
provides a one-time query for actor events, while SubscribeActorEventsRaw
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.
A future Lotus release may include GetActorEvents
and SubscribeActorEvents
methods which will provide a more user-friendly interface to actor events, including deserialization of event data.
All configuration options previously under Fevm.Events
are now in the top-level Events
section along with the new Events.EnableActorEventsAPI
option mentioned above. If you have non-default options in [Events]
under [Fevm]
in your configuration file, please move them to the top-level [Events]
.
While Fevm.Events.*
options are deprecated and replaced by Events.*
, any existing custom values will be respected if their new form isn't set, but a warning will be printed to standard error upon startup. Support for these deprecated options will be removed in a future Lotus release, so please migrate your configuration promptly.
Additionally the methods GetAllAllocations
and GetAllClaims
has been added to the Lotus API. These methods lists all the available allocations and claims available in the actor state.
The filplus
commands used for listing allocations and claims have been updated. If no argument is provided to the either command, they will list out all the allocations and claims in the verified registry actor.
The output list columns have been modified to AllocationID
and ClaimID
instead of ID.
lotus filplus list-allocations --help
NAME:
lotus filplus list-allocations - List allocations available in verified registry actor or made by a client if specified
USAGE:
lotus filplus list-allocations [command options] clientAddress
OPTIONS:
--expired list only expired allocations (default: false)
--json output results in json format (default: false)
--help, -h show help
lotus filplus list-claims --help
NAME:
lotus filplus list-claims - List claims available in verified registry actor or made by provider if specified
USAGE:
lotus filplus list-claims [command options] providerAddress
OPTIONS:
--expired list only expired claims (default: false)
--help, -h show help
Commit log for v1.26.2: https://github.com/filecoin-project/lotus/compare/v1.26.1...v1.26.2
Commit log since v1.25.2: https://github.com/filecoin-project/lotus/compare/v1.25.2...v1.26.2
Published by rjan90 7 months ago
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.
Published by rjan90 7 months ago
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:
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
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.
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.
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:
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.
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 eventFields
within the eventFromHeight
and ToHeight
to filter events by block heightTipSetKey
to restrict events contained within a specific tipsetGetActorEventsRaw
provides a one-time query for actor events, while SubscribeActorEventsRaw
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.
A future Lotus release may include GetActorEvents
and SubscribeActorEvents
methods which will provide a more user-friendly interface to actor events, including deserialization of event data.
All configuration options previously under Fevm.Events
are now in the top-level Events
section along with the new Events.EnableActorEventsAPI
option mentioned above. If you have non-default options in [Events]
under [Fevm]
in your configuration file, please move them to the top-level [Events]
.
While Fevm.Events.*
options are deprecated and replaced by Events.*
, any existing custom values will be respected if their new form isn't set, but a warning will be printed to standard error upon startup. Support for these deprecated options will be removed in a future Lotus release, so please migrate your configuration promptly.
Additionally the methods GetAllAllocations
and GetAllClaims
has been added to the Lotus API. These methods lists all the available allocations and claims available in the actor state.
The filplus
commands used for listing allocations and claims have been updated. If no argument is provided to the either command, they will list out all the allocations and claims in the verified registry actor.
The output list columns have been modified to AllocationID
and ClaimID
instead of ID.
lotus filplus list-allocations --help
NAME:
lotus filplus list-allocations - List allocations available in verified registry actor or made by a client if specified
USAGE:
lotus filplus list-allocations [command options] clientAddress
OPTIONS:
--expired list only expired allocations (default: false)
--json output results in json format (default: false)
--help, -h show help
lotus filplus list-claims --help
NAME:
lotus filplus list-claims - List claims available in verified registry actor or made by provider if specified
USAGE:
lotus filplus list-claims [command options] providerAddress
OPTIONS:
--expired list only expired claims (default: false)
--help, -h show help
Published by rjan90 7 months ago
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:
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
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.
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.
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:
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.
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 Events.RealTimeFilterAPI
and 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 eventFields
within the eventFromHeight
and ToHeight
to filter events by block heightTipSetKey
to restrict events contained within a specific tipsetGetActorEvents
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.
All configuration options previously under Fevm.Events
are now in the top-level Events
section along with the new Events.EnableActorEventsAPI
option mentioned above. If you have non-default options in [Events]
under [Fevm]
in your configuration file, please move them to the top-level [Events]
.
While Fevm.Events.*
options are deprecated and replaced by Events.*
, any existing custom values will be respected if their new form isn't set, but a warning will be printed to standard error upon startup. Support for these deprecated options will be removed in a future Lotus release, so please migrate your configuration promptly.
Additionally the methods GetAllAllocations
and GetAllClaims
has been added to the Lotus API. These methods lists all the available allocations and claims available in the actor state.
The filplus
commands used for listing allocations and claims have been updated. If no argument is provided to the either command, they will list out all the allocations and claims in the verified registry actor.
The output list columns have been modified to AllocationID
and ClaimID
instead of ID.
lotus filplus list-allocations --help
NAME:
lotus filplus list-allocations - List allocations available in verified registry actor or made by a client if specified
USAGE:
lotus filplus list-allocations [command options] clientAddress
OPTIONS:
--expired list only expired allocations (default: false)
--json output results in json format (default: false)
--help, -h show help
lotus filplus list-claims --help
NAME:
lotus filplus list-claims - List claims available in verified registry actor or made by provider if specified
USAGE:
lotus filplus list-claims [command options] providerAddress
OPTIONS:
--expired list only expired claims (default: false)
--help, -h show help
Published by jennijuju 7 months ago
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:
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
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.
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.
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:
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.
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 eventFields
within the eventFromHeight
and ToHeight
to filter events by block heightTipSetKey
to restrict events contained within a specific tipsetGetActorEvents
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.
Additionally the methods GetAllAllocations
and GetAllClaims
has been added to the Lotus API. These methods lists all the available allocations and claims available in the actor state.
The filplus
commands used for listing allocations and claims have been updated. If no argument is provided to the either command, they will list out all the allocations and claims in the verified registry actor.
The output list columns have been modified to AllocationID
and ClaimID
instead of ID.
lotus filplus list-allocations --help
NAME:
lotus filplus list-allocations - List allocations available in verified registry actor or made by a client if specified
USAGE:
lotus filplus list-allocations [command options] clientAddress
OPTIONS:
--expired list only expired allocations (default: false)
--json output results in json format (default: false)
--help, -h show help
lotus filplus list-claims --help
NAME:
lotus filplus list-claims - List claims available in verified registry actor or made by provider if specified
USAGE:
lotus filplus list-claims [command options] providerAddress
OPTIONS:
--expired list only expired claims (default: false)
--help, -h show help
Published by rjan90 8 months ago
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:
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
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.
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.
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:
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.
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 eventFields
within the eventFromHeight
and ToHeight
to filter events by block heightTipSetKey
to restrict events contained within a specific tipsetGetActorEvents
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.
Additionally the methods GetAllAllocations
and GetAllClaims
has been added to the Lotus API. These methods lists all the available allocations and claims available in the actor state.
The filplus
commands used for listing allocations and claims have been updated. If no argument is provided to the either command, they will list out all the allocations and claims in the verified registry actor.
The output list columns have been modified to AllocationID
and ClaimID
instead of ID.
lotus filplus list-allocations --help
NAME:
lotus filplus list-allocations - List allocations available in verified registry actor or made by a client if specified
USAGE:
lotus filplus list-allocations [command options] clientAddress
OPTIONS:
--expired list only expired allocations (default: false)
--json output results in json format (default: false)
--help, -h show help
lotus filplus list-claims --help
NAME:
lotus filplus list-claims - List claims available in verified registry actor or made by provider if specified
USAGE:
lotus filplus list-claims [command options] providerAddress
OPTIONS:
--expired list only expired claims (default: false)
--help, -h show help
Published by rjan90 9 months ago
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.
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
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
Lotus-Provider
instances as you want for both WindowPoSt and WinningPOSt.Simplicity
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)
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.
Lotus-Provider
binary, and the HarmonyDB framework.lotus sync wait
, so you can get an estimate for how long until sync is completed.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.mpool miner-select-messages
(filecoin-project/lotus#11253)eth_getLogs
results (#11318) (filecoin-project/lotus#11318)