Jul 20, 1-2 AM (6)
Jul 20, 2-3 AM (7)
Jul 20, 3-4 AM (7)
Jul 20, 4-5 AM (23)
Jul 20, 5-6 AM (15)
Jul 20, 6-7 AM (26)
Jul 20, 7-8 AM (48)
Jul 20, 8-9 AM (33)
Jul 20, 9-10 AM (29)
Jul 20, 10-11 AM (20)
Jul 20, 11-12 PM (15)
Jul 20, 12-1 PM (45)
Jul 20, 1-2 PM (30)
Jul 20, 2-3 PM (40)
Jul 20, 3-4 PM (28)
Jul 20, 4-5 PM (8)
Jul 20, 5-6 PM (8)
Jul 20, 6-7 PM (4)
Jul 20, 7-8 PM (5)
Jul 20, 8-9 PM (19)
Jul 20, 9-10 PM (12)
Jul 20, 10-11 PM (18)
Jul 20, 11-12 AM (8)
Jul 21, 12-1 AM (20)
Jul 21, 1-2 AM (6)
Jul 21, 2-3 AM (14)
Jul 21, 3-4 AM (15)
Jul 21, 4-5 AM (18)
Jul 21, 5-6 AM (27)
Jul 21, 6-7 AM (15)
Jul 21, 7-8 AM (49)
Jul 21, 8-9 AM (45)
Jul 21, 9-10 AM (20)
Jul 21, 10-11 AM (40)
Jul 21, 11-12 PM (20)
Jul 21, 12-1 PM (42)
Jul 21, 1-2 PM (26)
Jul 21, 2-3 PM (15)
Jul 21, 3-4 PM (20)
Jul 21, 4-5 PM (6)
Jul 21, 5-6 PM (13)
Jul 21, 6-7 PM (9)
Jul 21, 7-8 PM (5)
Jul 21, 8-9 PM (6)
Jul 21, 9-10 PM (13)
Jul 21, 10-11 PM (14)
Jul 21, 11-12 AM (9)
Jul 22, 12-1 AM (13)
Jul 22, 1-2 AM (11)
Jul 22, 2-3 AM (3)
Jul 22, 3-4 AM (5)
Jul 22, 4-5 AM (7)
Jul 22, 5-6 AM (12)
Jul 22, 6-7 AM (10)
Jul 22, 7-8 AM (18)
Jul 22, 8-9 AM (18)
Jul 22, 9-10 AM (40)
Jul 22, 10-11 AM (34)
Jul 22, 11-12 PM (35)
Jul 22, 12-1 PM (31)
Jul 22, 1-2 PM (18)
Jul 22, 2-3 PM (39)
Jul 22, 3-4 PM (24)
Jul 22, 4-5 PM (27)
Jul 22, 5-6 PM (21)
Jul 22, 6-7 PM (15)
Jul 22, 7-8 PM (9)
Jul 22, 8-9 PM (10)
Jul 22, 9-10 PM (12)
Jul 22, 10-11 PM (8)
Jul 22, 11-12 AM (8)
Jul 23, 12-1 AM (12)
Jul 23, 1-2 AM (7)
Jul 23, 2-3 AM (10)
Jul 23, 3-4 AM (5)
Jul 23, 4-5 AM (7)
Jul 23, 5-6 AM (14)
Jul 23, 6-7 AM (24)
Jul 23, 7-8 AM (26)
Jul 23, 8-9 AM (22)
Jul 23, 9-10 AM (28)
Jul 23, 10-11 AM (16)
Jul 23, 11-12 PM (20)
Jul 23, 12-1 PM (33)
Jul 23, 1-2 PM (15)
Jul 23, 2-3 PM (14)
Jul 23, 3-4 PM (39)
Jul 23, 4-5 PM (14)
Jul 23, 5-6 PM (7)
Jul 23, 6-7 PM (6)
Jul 23, 7-8 PM (3)
Jul 23, 8-9 PM (18)
Jul 23, 9-10 PM (13)
Jul 23, 10-11 PM (2)
Jul 23, 11-12 AM (3)
Jul 24, 12-1 AM (5)
Jul 24, 1-2 AM (7)
Jul 24, 2-3 AM (2)
Jul 24, 3-4 AM (2)
Jul 24, 4-5 AM (1)
Jul 24, 5-6 AM (3)
Jul 24, 6-7 AM (5)
Jul 24, 7-8 AM (3)
Jul 24, 8-9 AM (4)
Jul 24, 9-10 AM (4)
Jul 24, 10-11 AM (1)
Jul 24, 11-12 PM (6)
Jul 24, 12-1 PM (6)
Jul 24, 1-2 PM (2)
Jul 24, 2-3 PM (4)
Jul 24, 3-4 PM (7)
Jul 24, 4-5 PM (1)
Jul 24, 5-6 PM (1)
Jul 24, 6-7 PM (1)
Jul 24, 7-8 PM (1)
Jul 24, 8-9 PM (20)
Jul 24, 9-10 PM (22)
Jul 24, 10-11 PM (3)
Jul 24, 11-12 AM (2)
Jul 25, 12-1 AM (2)
Jul 25, 1-2 AM (7)
Jul 25, 2-3 AM (2)
Jul 25, 3-4 AM (3)
Jul 25, 4-5 AM (4)
Jul 25, 5-6 AM (20)
Jul 25, 6-7 AM (4)
Jul 25, 7-8 AM (8)
Jul 25, 8-9 AM (2)
Jul 25, 9-10 AM (8)
Jul 25, 10-11 AM (7)
Jul 25, 11-12 PM (7)
Jul 25, 12-1 PM (7)
Jul 25, 1-2 PM (6)
Jul 25, 2-3 PM (12)
Jul 25, 3-4 PM (28)
Jul 25, 4-5 PM (6)
Jul 25, 5-6 PM (2)
Jul 25, 6-7 PM (5)
Jul 25, 7-8 PM (14)
Jul 25, 8-9 PM (7)
Jul 25, 9-10 PM (2)
Jul 25, 10-11 PM (3)
Jul 25, 11-12 AM (2)
Jul 26, 12-1 AM (4)
Jul 26, 1-2 AM (3)
Jul 26, 2-3 AM (4)
Jul 26, 3-4 AM (4)
Jul 26, 4-5 AM (3)
Jul 26, 5-6 AM (5)
Jul 26, 6-7 AM (7)
Jul 26, 7-8 AM (43)
Jul 26, 8-9 AM (21)
Jul 26, 9-10 AM (12)
Jul 26, 10-11 AM (54)
Jul 26, 11-12 PM (66)
Jul 26, 12-1 PM (43)
Jul 26, 1-2 PM (41)
Jul 26, 2-3 PM (40)
Jul 26, 3-4 PM (32)
Jul 26, 4-5 PM (16)
Jul 26, 5-6 PM (9)
Jul 26, 6-7 PM (11)
Jul 26, 7-8 PM (15)
Jul 26, 8-9 PM (4)
Jul 26, 9-10 PM (12)
Jul 26, 10-11 PM (3)
Jul 26, 11-12 AM (4)
Jul 27, 12-1 AM (2)
Jul 27, 1-2 AM (10)
2,450 commits this week Jul 20, 2021 - Jul 27, 2021
consensus: implement TxLimits via the cardano-base:measures package
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]il.com>
consensus: remove maxTxCapacityOverride from the NodeKernel
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]>