Cardano Updates

Merge #697

697: HasCallStack constraints r=edsko a=edsko

Both sEpoch and rcDCert itself can throw errors, and it’s easier to track those down with a callstack.

Co-authored-by: Edsko de Vries [email protected]

Merge #697

697: HasCallStack constraints r=edsko a=edsko

Both sEpoch and rcDCert itself can throw errors, and it’s easier to track those down with a callstack.

Co-authored-by: Edsko de Vries [email protected]

HasCallStack constraints

Switch secure entropy source from openssl to system entropy

We only use this for key generation so it is simpler and probably better to get entropy straight from the operating system, rather than use OpenSSL’s entropy pool. The OpenSSL one is better suited to generating lots of keys quickly, but we do not need that.

This also lets us drop the dependency on OpenSSL which is a portability benefit.

Follow the secret key generation pattern for AVVM keys

For some reason the AVVM keys were handled differently, in that in the generateSecrets it did not actually generate the secret keys for the AVVM addresses, but instead just generated the seeds that could later be used to deterministically derive the secret keys.

This is unnecessarily complicated and does not followthe established pattern for no good reason. So switch to actually generating the AVVM secret keys in generateSecrets and then just using them later.

This will need some slight changes in the node CLI since it can now dump the AVVM secret keys instead of the seeds, but it appears that these are currently unused anyway.

Remove old method of specifying the genesis generation seed

It now uses a proper entropy source, so we don’t need a separate seed argument. And for use cases that do, they can call the “WithEntropy” variants and choose the whole entropy source, not just the seed.

Add more comments in genesis generation

Clarify that all the code in the module is for generating genesis data for testing or development, and not for production.

Use a sensible entropy source for generateGenesis{Data,Config}

It doesn’t really matter that much since these are only ever used for generating test genesis files and test keys, however it’s still better to do the right thing even if not strictly necessary.

So to use a proper entropy source we need to use MonadRandom and then instantiate it with a proper source. So we generalise generateGenesis{Data,Config} over MonadRandom, renaming them to generateGenesis{Data,Config}WithEntropy. Then we specialise the original ones to IO and us the Cardano.Crypto.Random.runSecureRandom as the entropy source which is suitable for the purpose of key generation.

This means we can still use a pure deterministic “entropy” source for generating mock/dummy examples, but can also use a proper entropy source that’s suitable for key generation (again, even though that’s not strictly necessary since this whole module is only for test configurations).

Use qualified names to clarify crypto entropy source

In the genesis generation we use MonadRandom and getRandomBytes. Since this is used for key generation it’s helpful to make it clear to readers that this is not a normal PRNG but for getting entropy. So we import the names qualified with “Crypto”.

Preparatory code movement in generateGenesisData

Just moving definitions from the where clause into lets in the do block. This will be needed by later steps.

Merge #696

696: Allow software updates to start from version 0 or 1 r=dnadales a=dcoutts

It does not really matter if application versions start from 0 or 1, and the old cardano-sl code allows both. An initial version 0 has been used on the public testnet (but not mainnet), and so it is useful to agree with the old cardano-sl and declare that to be valid.

Also update the comments for the function that does the validation of the versions. The existing comments says that we allow keeping the same version, but the existing code and the formal spec always require an increment of exactly 1. So we correct the comment.

TODO:

• [x] bring the formal and executable specs in line on the 0 vs 1 issue.

Co-authored-by: Duncan Coutts [email protected] Co-authored-by: Damian Nadales [email protected]

Update cabal and nix files.

• Check that a proposed application update is unique among the registered updates, to conform to the specs.
• Bump cardano-ledger-specs version.
• Update license badge in the README.