Skip to content

DO NOT MERGE: Update to crypton == 1.1 and replace memory package with ram - #1292

Draft
erikd wants to merge 6 commits into
masterfrom
erikd/crypton+ram
Draft

DO NOT MERGE: Update to crypton == 1.1 and replace memory package with ram#1292
erikd wants to merge 6 commits into
masterfrom
erikd/crypton+ram

Conversation

@erikd

@erikd erikd commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Context

The package crypton < 1.1 depends on memory and >= 1.1 depends on ram. This does not affect consensus directly, but has a huge impact on the whole stack, ledger, consensus and node all need to be changed/fixed at once.

The commits in this PR will be used on an experiment branch of cardano-node to make sure everything works.

How to trust this PR

Highlight important bits of the PR that will make the review faster. If there are commands the reviewer can run to observe the new behavior, describe them.

Checklist

  • Commit sequence broadly makes sense and commits have useful messages
  • New tests are added if needed and existing tests are updated. See Running tests for more details
  • Self-reviewed the diff
  • Changelog fragment added in .changes/

erikd added 6 commits August 13, 2026 16:12
The package `crypton < 1.1` depends on `memory` and `>= 1.1` depends on
`ram`. By dropping the dependency on `memory` and adding the dependency
on `ram` we are effectively changing to `crypton >= 1.1`.
This change required due to dependence on cardano-crypto-class which in
turn was required to support crypton >= 1.1.
validation had no version bound in cardano-api.cabal. Its 1.2.2 release
(uploaded between the two Hackage index-states this crypton migration
spans) is a complete rewrite to a lens/profunctor-optics based API, which
dropped Valid.toEither/Valid.liftError used by
Cardano.Api.Tx.Internal.Sign.decodeShelleyBasedWitness.

Capping validation to <1.2 to keep that old API is not an option: the
ouroboros-consensus changes pulled in by the cabal.project SRP had
already migrated Ouroboros.Consensus.Shelley.Ledger.Mempool to the new
validation >=1.2 API (view Data.Validation.either) themselves, and
validation is a single globally-resolved package across the whole build
plan, so pinning it down for cardano-api's sake breaks
ouroboros-consensus-cardano instead.

Rewrite decodeShelleyBasedWitness to use only the primitives that are
stable across both API generations (the Valid.Failure/Valid.Success
constructors and the Semigroup/Monoid instances), and pin
validation ^>=1.2 to reflect what the build already requires
transitively.
…hanges

cardano-crypto-class-2.5.0.0 removed BLS12381SignContext's constructors
from export in favour of the pre-built minSigPoPDST/minVerKeyPoPDST
values, which broke Leios.hs's provisional reconstruction of that
context (already flagged there with a TODO anticipating this exact
change). Use Crypto.minSigPoPDST directly now that it's available.

The same version bump renamed cardano-crypto-class:testlib's
prop_cbor_with -> prop_cbor_fixed_sized, prop_cbor_direct_vs_class ->
prop_cbor_fixed_sized_vs_class, and added _fixed_sized variants of
prop_raw_serialise/prop_size_serialise built on FixedSizeCodec directly.
Switch Test.Cardano.Api.Crypto to the new names/variants, following on
from "Update all DSIGN operations to FixedSizeCodec ops".
…ic.hs

cardano-addresses' master (pulled in by the cabal.project SRP, needed for
its own crypton >=1.1/ram migration) vendored its own copy of
Cardano.Crypto.Wallet to drop the cardano-crypto/memory dependency,
rather than re-exporting cardano-crypto's module as before. Its XPrv is
now a distinct type from the Crypto.HD.XPrv ("Cardano.Crypto.Wallet",
from the standalone cardano-crypto package) that SigningKey constructors
expect.

Bridge the two via the same 96-byte compact raw format both sides
already implement (Cardano.Address.Derivation.xprvToBytes round-tripped
through Cardano.Api.Crypto.Ed25519Bip32.xPrvFromBytes) rather than
changing what type SigningKey wraps, so the on-disk/wire key format is
unaffected.
Copilot AI lite review requested due to automatic review settings August 13, 2026 06:42
@erikd
erikd requested a review from disassembler as a code owner August 13, 2026 06:42
@erikd
erikd marked this pull request as draft August 13, 2026 06:42

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the cardano-api/cardano-rpc stack to support the crypton >= 1.1 ecosystem shift (notably the memoryram dependency change) and adjusts crypto serialization code to use the newer fixed-size raw encoding APIs. It also adds temporary cabal.project pins/allow-newer to align a set of upstream packages for an experiment branch.

Changes:

  • Migrate DSIGN/KES/VRF/BLS raw key/signature (de)serialization to Cardano.Binary.FixedSizeCodec (rawEncodeFixedSized / rawDecodeFixedSized).
  • Bridge cardano-addresses’ vendored XPrv to cardano-crypto’s XPrv via the shared 96-byte compact format.
  • Update Cabal dependencies (bounds + ram replacement) and add temporary cabal.project pins/allow-newer for upstream compatibility during the migration.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
cardano-rpc/src/Cardano/Rpc/Server/Internal/UtxoRpc/Type/Tx.hs Encode vkey witnesses using fixed-size raw encoding.
cardano-rpc/src/Cardano/Rpc/Server/Internal/UtxoRpc/Type/Byron.hs Encode Byron bootstrap witness vkeys using fixed-size raw encoding.
cardano-rpc/cardano-rpc.cabal Bump crypto/binary deps and switch memoryram in lib + tests.
cardano-api/test/cardano-api-test/Test/Cardano/Api/Crypto.hs Update crypto serialization properties to fixed-size codec helpers.
cardano-api/src/Cardano/Api/Tx/Internal/Sign.hs Adapt witness decoding to newer validation API and use fixed-size sig decoding.
cardano-api/src/Cardano/Api/Key/Internal/Praos.hs Switch KES/VRF raw bytes serialization to fixed-size codec APIs.
cardano-api/src/Cardano/Api/Key/Internal/Mnemonic.hs Convert derived XPrv from cardano-addresses to cardano-crypto format via bytes.
cardano-api/src/Cardano/Api/Key/Internal/Leios.hs Switch BLS raw bytes serialization to fixed-size codec APIs; update PoP context constant usage.
cardano-api/src/Cardano/Api/Key/Internal.hs Switch many key roles’ raw bytes serialization to fixed-size codec APIs.
cardano-api/src/Cardano/Api/Crypto/Ed25519Bip32.hs Provide FixedSizeCodec instances and CBOR via encodeFixedSized/decodeFixedSized.
cardano-api/cardano-api.cabal Update dependency bounds, remove memory, add ram, bump validation.
cabal.project Add temporary allow-newer + source-repository-package pins for the migration.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread cabal.project
Comment on lines +177 to +185
allow-newer:
cardano-ledger-mary:cardano-crypto-class,
cardano-ledger-shelley:cardano-crypto-class,
cardano-ledger-binary:cardano-crypto-class,
cardano-ledger-core:cardano-crypto-class,
cardano-protocol:cardano-crypto-class,
cardano-protocol-tpraos:cardano-crypto-class,
kes-agent:cardano-crypto-class,
kes-agent-crypto:cardano-crypto-class,
Comment thread cabal.project
Comment on lines +168 to +176
-- TEMPORARY: switching to crypton >= 1.1 (which depends on `ram` instead of
-- `memory`) needs cardano-crypto-class-2.6.0.0 (the first version depending
-- on crypton ^>=1.1 and `ram`), but the released ouroboros-consensus-3.0.1.0
-- pins `cardano-crypto-class ^>=2.3`, which excludes it. The blocks below
-- replicate the (draft, do-not-merge) upstream fix in
-- https://github.com/IntersectMBO/ouroboros-consensus/pull/2213, which widens
-- ouroboros-consensus's bound to also allow cardano-crypto-class-2.6.0.0 and
-- pulls in the handful of other packages that need to move in lockstep with
-- it. Remove all of this once these land upstream and a release picks them up.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants