add supervision and start functional tests
Signed-off-by: Roland Kuhn <[email protected]>
Signed-off-by: Roland Kuhn <[email protected]>
feat: add header validation to amaru-ledger sync
Signed-off-by: Simon Gellis <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
- Clarify names outside of the ledger and add comments explaining what the config parameters stands for. - Reduce the default number of arenas to 1; we aren't parellalizing anything at the moment, so there's no point. - Move where we create the arena; it's not a concern of the upper layers (I would even be tempted to move it further down the line, inside the ledger state creation) - DO NOT EXPOSE arena settings to end-users. This is not a configuration we want to bother users with. This is something we have to fine-tune as implementors. Signed-off-by: KtorZ <[email protected]>
- Avoid duplicating sorting logic between 'Redeemers' and
'OrderedRedeemer'. The Ord instance on the latter already carry the
sorting logic, so we can
- Store redeemers in an 'inverted' BTreeMap:
- This works because we know redeemer values are unique (different
tags and indexes; although I admittedly haven't controlled that we
have a test for it in the rules that would correctly rule out
duplications).
- Doing this, we reduce the number of traversals we have to do on
the redeemers, everything is much more streamlined.
- We also allow near-instant lookups of redeemers, instead of having
search them by tag & index in O(n).
- Factor out the common instance for ToPlutusData between V2 and V3;
generally speaking, we should avoid duplicating instances where
possible. We use a parameterized trait for that reason!
Signed-off-by: KtorZ <[email protected]>
Signed-off-by: KtorZ <[email protected]>
The FIXME is in fact unecessary; we need not to use the exact same version as uplc-turbo; in fact, that's an issue for the dependency constraint solver to solve. We should even be able to use different versions so long as they are compatible. Signed-off-by: KtorZ <[email protected]>
Signed-off-by: KtorZ <[email protected]>
Less confusing of a name with clearer intent (providing Ord instances). Using Cow also works well here to avoid unnecessary clones, since we already have lifetimes on TxInfo anyway. Also moved into its own module, to keep the ongoing pattern in the kernel for newly introduced types. Signed-off-by: KtorZ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>
Signed-off-by: yHSJ <[email protected]>