Byron.Spec.Ledger.Update

Check whether an update proposal marks a valid update

Find the key that corresponds to the value satisfying the given predicate. In case zero or more than one key is found this function returns Nothing.

Test if a pair is present in a map.

Generate values the given distribution in 90% of the cases, and values at the bounds of the range in 10% of the cases.

This can be used to generate enough extreme values. The exponential and linear distributions provided by hedgehog will generate a small percentage of these (0-1%).

Invert a map which we assert to be a bijection. If this map is not a bijection, the behaviour is not guaranteed.

Examples:

>>> import qualified Data.Map.Strict as Map>>> invertBijection (Map.fromList [('a', 1 :: Int), ('b', 2), ('c', 3)])fromList [(1,'a'),(2,'b'),(3,'c')]

Invert a map

Examples:

>>> import qualified Data.Map.Strict as Map>>> import Byron.Spec.Ledger.Update (invertMap)>>> invertMap (Map.fromList [('a', 1 :: Int), ('b', 2), ('c', 3), ('d', 1)])fromList [(1,fromList "ad"),(2,fromList "b"),(3,fromList "c")]

Given a list of protocol versions and keys endorsing those versions, generate a protocol-version endorsement, or Nothing if the list of endorsements is empty. The version to be endorsed will be selected from those versions that have the most endorsements.

Generate a protocol parameter update from a given set of current protocol-parameters, ensuring the consistency of the new protocol parameters w.r.t. the current ones, according to the canUpdate predicate in the formal specification.

TODO: we can move this into a Generator's module, but first we need to disentangle the dependencies. Moving this to Byron.Spec.Ledger.Update.Generators will cause a circular dependency. I think the rules need to be moved into their own modules.

Generate an endorsement given an update environment and state.

Check whether a protocol version can follow the current protocol version.

Generate a random update proposal id, by picking a large number so that the probability of having an update proposal with that id is nearly zero.

Update the signature of the update proposal.

Generate an optional update-proposal and a list of votes, given an update environment and state.

The update proposal and votes need to be generated at the same time, since this allow us to generate update votes for update proposals issued in the same block as the votes.

These PredicateFailures are all throwable.

Application version

For now we do not have any requirements on metadata.

Protocol parameters.

Protocol version

System tag, this represents a target operating system for the update (e.g. linux, win64, or mac32).

The update interface environment is shared amongst various rules, so we define it as an alias here.

The update interface state is shared amongst various rules, so we define it as an alias here.

Update Proposal Software Version Validation

Update proposal validity

Update proposal

Part of the update proposal which must be signed

Violations on the constraints of the allowed values for new protocol parameters.

S_TryNextRule is a structural PredicateFailure, used to fail from one transition rule to the other. The other PredicateFailures are all throwable.

These PredicateFailures are all "throwable". The disjunction of the rules' preconditions is not True - the PredicateFailures represent False cases.

These PredicateFailures are all throwable.

These PredicateFailures are all "throwable". The disjunction of the rules' preconditions is not True - the PredicateFailures represent False cases.

These PredicateFailures are all throwable.

The 3 non-embedded PredicateFailures here are all structural. The disjuntion of the preconditions is True - one rule either fires or the other does.