chore(deps): bump bls from v5.3.0 to v6.0.1 in /native/bls_nif

[dependabot]

Bumps bls from v5.3.0 to v6.0.1.

Release notes

Sourced from bls's releases.

Rick In A Vat In The Garage

Summary

This low-priority patch release fixes a few minor issues in the recent major release v6.0.0. If you have not yet upgraded to Lighthouse v6.0.0, we recommend skipping v6.0.0 and going straight to v6.0.1. These release notes provide a full description of the changes in v6.0.0 and v6.0.1, referred to collectively as v6.0.x.

Lighthouse v6.0.x includes new features and optimisations which are backwards-incompatible with Lighthouse v5.x.y.

After many months of testing, v6.0.x stabilises hierarchical state diffs, resulting in much more compact archive nodes! This long-awaited feature was also known as on-disk tree-states, and was available for pre-release testing in Lighthouse v5.1.222-exp.

Other notable changes in v6.0.x include:

• Removal and deprecation of several old CLI flags. Some flags will need to be removed in order for Lighthouse to start, see below for a full list.
• Improved beacon node failover and prioritisation in the validator client.
• Support for engine_getBlobsV1 to speed up import and propagation of blobs.
• Optimised peer discovery and long-term subnet subscription logic.
• New commands for lighthouse validator-manager.
• Improved light client support. Enabled via --light-client-server.
• SSZ by default for blocks published by the VC.

Compared to v6.0.0, this release includes several bugfixes:

• Fix an issue with attestation subnet subscriptions not being tracked correctly (sigp/lighthouse#6682).
• Fix the /lighthouse/nat API and NAT metrics (sigp/lighthouse#6677).
• Prevent sync from getting stuck on certain lookups (sigp/lighthouse#6658).
• Quality-of-life improvements for archive node users (sigp/lighthouse#6669, sigp/lighthouse#6668).

⚠️ Breaking Changes ⚠️

Upgrading to Lighthouse v6.0.x should be automatic for most users, but you must:

• Remove any unsupported CLI flags (see below), and
• Be aware of the one-way database migration and the changes to archive nodes.

Once you upgrade a beacon node to Lighthouse v6.0.x, you cannot downgrade to v5.x.y without re-syncing.

⚠️ Database Migration ⚠️

The beacon node database migration for v6.0.x is applied automatically upon upgrading. No manual action is required to upgrade.

There is no database downgrade available. We did not take this choice lightly, but in order to deliver hierarchical state diffs, a one-way database migration was simplest. If you do find yourself wanting to downgrade, re-syncing using checkpoint sync is highly recommended as it will get the node back online in just a few minutes.

For Archive Nodes

The migration enables hierarchical state diffs which necessitates the deletion of previously stored historic states. If you are running an archive node, then all historic states will be deleted upon upgrading. If you would like to continue running an archive node, you should use the --reconstruct-historic-states flag so that state reconstruction can restart from slot 0.

If you would like to change the density of diffs, you can use the new flag --hierarchy-exponents which should be applied the first time you start after upgrading. We have found that the hierarchy-exponents configuration does not greatly impact query times which tend to be dominated by cache builds and affected more by query ordering. We still recommend avoiding parallel state queries at the same slot, and making use of sequential calls where possible (e.g. in indexing services). We plan to continue optimising parallel queries and cache builds in future releases, without requiring a re-sync.

For more information on configuring the hierarchy exponents see the updated documentation on Database Configuration in the Lighthouse book.

| Hierarchy Exponents | Storage requirement | Sequential slot query | Uncached query |

... (truncated)

Commits

• 0d90135 Release v6.0.1 (#6659)
• c3a0757 Correct /nat API for libp2p (#6677)
• f3b7888 Compact more when pruning states (#6667)
• 775fa67 Stuck lookup v6 (#6658)
• 4946343 Fix subscribing to attestation subnets for aggregating (#6681) (#6682)
• fc0e0ae Prevent reconstruction starting prematurely (#6669)
• b7ffcc8 Fix: Docker CI to use org tokens (#6655)
• b2590bc Tweak reconstruction batch size (#6668)
• 3b8254a Correct flakey CI tests (#6646)
• e9ec67e Fix Kurtosis, web3signer and cargo-audit for CI (#6671)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)