Home / Input Output / cardano-ledger
13 commits this week Jan 14, 2020 - Jan 21, 2020

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.

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).

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.


  • [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]