[lklimek]

Basic explanation

What this does: Proposes retiring old on-disk Platform state and quorum formats. Loading one returns a migration instruction instead of decoding it.

Value: Removes the C++ bls-signatures dependency from the default production node. Tests and explicit mocks builds still use it.

Risks: This intentionally prevents direct startup from older databases and snapshots. The proposed migration is to run Platform v4.0.0 on the database and successfully commit at least one block before upgrading. The complete upgrade path has not been tested.

Draft for developer consultation — not ready to merge. Decide whether to require that intermediate migration or retain compatibility readers/adapters. This proposal removes the whole Platform-state V0 reader, including its non-BLS fields; retaining the historical schema with an explicit failing decoder is also a discussion point.

Issue being fixed or feature implemented

Targets v5.1-dev, which includes the BLS backend migration from #5320 and retains historical storage support. This PR isolates the compatibility-policy decision from that migration.

Production uses of the separate C++ BLS crate are in old storage readers. v4.0.0 writes Platform-state V1 and quorum-storage V2, while still being able to read older records.

What was done?

• Remove Platform-state V0 and quorum-storage V0/V1 readers and conversions.
• Keep their enum positions reserved with an uninhabited UnsupportedLegacyBlsStorage payload. Its decoder immediately returns an error directing the operator to v4.0.0; it does not parse the old payload or panic.
• Preserve Platform-state V1/V2 and quorum-storage V2 tags, layouts and serialized bytes.
• Remove bls-signatures from default features; retain it for tests and the explicit mocks feature.
• Test rejection of old testnet/devnet records and owned/borrowed quorum decoding. Keep a supported-format fixture serialized before reader removal and check the existing serialization hash.

In-place changes to shipped generations

This changes local database compatibility, not block execution rules. Serialization already writes supported formats for all protocol versions. The proposed rejection applies when loading old records, including outer Platform-state V0 records; no version table or protocol activation changes are introduced.

How Has This Been Tested?

• cargo test -p drive-abci --lib --all-features --locked platform_types: 133 tests, covering legacy errors, preserved supported tags and byte round trips.
• cargo clippy -p drive-abci --all-targets --all-features --locked -- --no-deps -D warnings.
• cargo clippy -p drive-abci --lib --locked -- --no-deps -D warnings verifies the default production configuration.
• Historical quorum fixtures retain coverage of supported V2 records and fixed 48-byte key encoding; V1 fixtures assert the intended upgrade error.
• Formatting and whitespace checks.
• The normal/build dependency tree for default drive-abci excludes bls-signatures and bls-dash-sys.

No full replay or end-to-end v1.0 → v4.0.0 → this branch upgrade was run. Tests prove decoder behavior and supported serialization compatibility, not the complete operational migration procedure.

Breaking Changes

Direct loading of Platform-state V0 and quorum-storage V0/V1 databases/snapshots becomes unsupported. Operators must first have v4.0.0 successfully commit a block on that database; merely launching the binary is insufficient.

The title omits ! because the repository reserves it for consensus-breaking changes.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed
• If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

🕓 Review not started yet because this PR is a draft.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit ad2252a. Normal review starts when eligible; priority review starts as soon as a slot is available.