Add cli query utxo support to filter by tx in
By new --tx-in flag.
By new --tx-in flag.
pQueryUTxOWhole = pure QueryUTxOWhole
<> Opt.help "Filter by Cardano address(es) (Bech32-encoded)."
pQueryUTxOByTxIn :: Parser QueryUTxOFilter
pQueryUTxOByTxIn = QueryUTxOByTxIn . Set.fromList <$> some pByTxIn
pByTxIn :: Parser TxIn
Opt.option (readerFromParsecParser parseTxIn)
( Opt.long "tx-in"
<> Opt.metavar "TX-IN"
<> Opt.help "Filter by transaction input (TxId#TxIx)."
pFilterByStakeAddress :: Parser StakeAddress
Opt.option (readerFromParsecParser parseStakeAddress)
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]>
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]>
Now that several of the ledger lib type famalies are injective.
It is not Alonzo aware. We have a decent replacement. It would be nice to also deprecate estimateTransactionFee, but we cannot just yet.