Cardano Updates

3261: Move override support for max tx capacities into the ProtocolInfo constructors r=nfrisby a=nfrisby

Fixes #3235 (again).

See the individual commit messages, some of which are extensive.

Co-authored-by: Nicolas Frisby <[email protected]>

This has a few small benefits

  * define's TxMeasure `leq` via the pointwise minimum

  * removes the redundancy of specifying the `pointwiseMin` method per ledger
    instead of per 'Measure'

  * avoids the need for type applications, which let's us re-use the <=
    operator

and two large benefits

  * creates an opportunity for more use of deriving

  * the top-bounded meet-semilattice foundation means that `noOverrides` can be
    implemented as `top`; we don't need it to be a function from the (dynamic!)
    ledger limits anymore.

We had previously decided on a function because it made it trivial to override
only parts of the ledger-derived capacity. However, we simplified the override
representation (no more `NP`) and a interface that uses the static `top`
instead of the dynamic "current ledger capacity" is more appropriate for a
interface used for static configuration.

In other words, the function space was "too big" for the following reasons.

  * in practice, these values are parsed from a file, and I doubt the Node Team
    wants to parse functions anytime soon

  * we do not anticipate the node operator wanting to vary their override
    depending on the ledger capacity

The 'Measure' class's lattice semantics let us remove the function space
without losing any convenience.

Co-authored-by: Pawel Szulc <[email protected]>

This is important because it is an accumulator.

The previous commit was a renamed that enabled simpler local names; no longer
need to avoid shadowing.

This avoids confusion with `maxCapacity` from the `TxLimits` type class.

 enter the commit message for your changes. Lines starting

A couple weeks ago, Edsko's insight set us on the path: the abstract Consensus
layer need not know about the limits on the size of block. That is ledger
specific; so only the atomic ledgers' (Byron, Shelley, etc -- not the
HardForkBlock) forge functions needed to query and enforce that limit.

We later realized that this same insight applies to the user-submitted
overrides of the ledger limits: the abstract Consensus layer receives a
`ProtocolInfo` structure from the downstream user. That includes `BlockForging`
structures, which include partial applications of the atomic forge functions.
When the downstream user builds the `ProtocolInfo`, they can supply the user's
overrides there, so that the abstract layer is never involved.

As a result, the `maxTxCapacityOverride` field is now vestigial.

This may seem like splitting hairs, since we _also_ provide a convenience
interface for creating `ProtocolInfo` (and hence `BlockForging`) values. But
it'll pay off to keep the separable concern separated. EG The abstract
Consensus layer interface works only at the top-level `blk` type, which meant
we would have needed a representation of overrides for `HardForkBlock`. The
`ProtocolInfo` convenience interface, however, is not abstract, and so it can
pass the right overrides to the right atomic forge functions as its building up
the inputs (eg `NP` values) for the abstract interface. So now the
`HardForkBlock` logic need not include anything at all about overrides (it
simply knows how to combine lists of `BlockForging`, which now handles
everything appropriately).

Co-authored-by: Pawel Szulc <[email protected]>

3278: Update Win32-network dependency r=coot a=coot

Fixes #3271


Co-authored-by: Marcin Szamotulski <[email protected]>

Fixes #3271

This has a few small benefits

  * define's TxMeasure `leq` via the pointwise minimum

  * removes the redundancy of specifying the `pointwiseMin` method per ledger
    instead of per 'Measure'

  * avoids the need for type applications, which let's us re-use the <=
    operator

and two large benefits

  * creates an opportunity for more use of deriving

  * the top-bounded meet-semilattice foundation means that `noOverrides` can be
    implemented as `top`; we don't need it to be a function from the (dynamic!)
    ledger limits anymore.

We had previously decided on a function because it made it trivial to override
only parts of the ledger-derived capacity. However, we simplified the override
representation (no more `NP`) and a interface that uses the static `top`
instead of the dynamic "current ledger capacity" is more appropriate for a
interface used for static configuration.

In other words, the function space was "too big" for the following reasons.

  * in practice, these values are parsed from a file, and I doubt the Node Team
    wants to parse functions anytime soon

  * we do not anticipate the node operator wanting to vary their override
    depending on the ledger capacity

The 'Measure' class's lattice semantics let us remove the function space
without losing any convenience.

Co-authored-by: Pawel Szulc <[email protected]>

This is important because it is an accumulator.

The previous commit was a renamed that enabled simpler local names; no longer
need to avoid shadowing.

This avoids confusion with `maxCapacity` from the `TxLimits` type class.

 enter the commit message for your changes. Lines starting

A couple weeks ago, Edsko's insight set us on the path: the abstract Consensus
layer need not know about the limits on the size of block. That is ledger
specific; so only the atomic ledgers' (Byron, Shelley, etc -- not the
HardForkBlock) forge functions needed to query and enforce that limit.

We later realized that this same insight applies to the user-submitted
overrides of the ledger limits: the abstract Consensus layer receives a
`ProtocolInfo` structure from the downstream user. That includes `BlockForging`
structures, which include partial applications of the atomic forge functions.
When the downstream user builds the `ProtocolInfo`, they can supply the user's
overrides there, so that the abstract layer is never involved.

As a result, the `maxTxCapacityOverride` field is now vestigial.

This may seem like splitting hairs, since we _also_ provide a convenience
interface for creating `ProtocolInfo` (and hence `BlockForging`) values. But
it'll pay off to keep the separable concern separated. EG The abstract
Consensus layer interface works only at the top-level `blk` type, which meant
we would have needed a representation of overrides for `HardForkBlock`. The
`ProtocolInfo` convenience interface, however, is not abstract, and so it can
pass the right overrides to the right atomic forge functions as its building up
the inputs (eg `NP` values) for the abstract interface. So now the
`HardForkBlock` logic need not include anything at all about overrides (it
simply knows how to combine lists of `BlockForging`, which now handles
everything appropriately).

Co-authored-by: Pawel Szulc <[email protected]>