First tick across the era boundary when translating the ledger/chain-dep state #340

amesgen · 2023-09-07T12:11:41Z

Closes #339, closes IntersectMBO/cardano-ledger#3491

This PR is intended to be reviewed commit by commit, which should all compile and pass all tests individually.

On a high level, this PR changes the way we do cross-era ticking in the HFC from translate-then-tick to tick-then-translate-then-tick for both the ledger state and, for consistency, also for the chain-dep/protocol state. For motivation, see #339, for further directions in this area, see #345.

The first commit enriches an existing test to showcase the problem, it is then fixed in a later commit.

TODO:

Determine whether we need more test, in particular for ChainDepState cross-era ticking. We could do this using actual Cardano blocks.
Do we need more documentation? (Maybe a GHC-style note explaining the overall HFC cross-era ticking approach?)

...consensus-cardano/src/ouroboros-consensus-cardano/Ouroboros/Consensus/Cardano/CanHardFork.hs

nfrisby

First pass 👍

...ros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/State/Types.hs

...consensus-cardano/src/ouroboros-consensus-cardano/Ouroboros/Consensus/Cardano/CanHardFork.hs

ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator.hs

nfrisby · 2023-09-08T13:44:15Z

...oros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Embed/Nary.hs

@@ -205,10 +206,11 @@ injectInitialExtLedgerState cfg extLedgerState0 =

    targetEraLedgerState :: LedgerState (HardForkBlock (x ': xs))
    targetEraLedgerState =
-        HardForkLedgerState $
+        -- TODO discarding ledger events, probably fine?


I would also guess it's fine, but it's slightly tricky since this whole function is an (important) optimization (for the benchmarking team)

I left a justification.

nfrisby · 2023-09-08T13:45:33Z

ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Ledger.hs

+
+-- | Extend the telescope until the specified slot is within the era at the tip
+--
+-- TODO documentation (in particular that this now does ticking!)


TODO agreed!

Should be there now 👍

nfrisby · 2023-09-08T13:47:39Z

ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Ledger.hs

+  -> SlotNo
+  -> HardForkState LedgerState xs
+  -> LedgerResult (LedgerState (HardForkBlock xs)) (HardForkState LedgerState xs)
+extendToSlot  ledgerCfg@HardForkLedgerConfig{..} slot ledgerSt@(HardForkState st) =


I anticipate we should be ticking N times if we do N translations. Do you agree?

And I think I see that natural pairing in howExtend. Would you add a comment there highlighting it?

(Just a note to self: GH labels this Outdated, but the comment isn't there yet.

Should be there now 👍

...oros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Embed/Nary.hs

nfrisby · 2023-09-09T15:59:14Z

...s-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/TPraos.hs

-                    (TPraosState lastSlot st) =
+  projectHorizonView _cfg _lv = TickedTrivial
+
+  -- TODO comment explaining why we're not using the 'SL.tickChainDepState' function


Also TODO: open a PR upstream deleting that function?

I opened #350 for the natural larger task.

We could also go the 'opposite" route and add a property test that our vendored tick function behaves just as the one from ledger (for an interim period until #350 is done).
I locally tested that this works (and that introducing bugs in TPraos tickChainDepState causes the test to fail), but I am not sure if it is worth it:

Click to see compatibility test for TPraos ticking

{-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE NamedFieldPuns #-} {-# LANGUAGE StandaloneDeriving #-} module Test.Consensus.Protocol.TPraos.LedgerCompat (tests) where import qualified Cardano.Ledger.BaseTypes as SL import qualified Cardano.Ledger.Chain as SL import Cardano.Ledger.Crypto import qualified Cardano.Protocol.TPraos.API as SL import Cardano.Slotting.EpochInfo.API (epochInfoEpoch, generalizeEpochInfo) import Data.Functor.Identity import Ouroboros.Consensus.Block import Ouroboros.Consensus.HardFork.History.EpochInfo (toPureEpochInfo) import Ouroboros.Consensus.HardFork.History.Util (addSlots) import Ouroboros.Consensus.Protocol.Abstract import Ouroboros.Consensus.Protocol.TPraos import Test.Cardano.Ledger.Shelley.Utils (testGlobals) import Test.Cardano.Protocol.TPraos.Arbitrary () import Test.QuickCheck import Test.Tasty import Test.Tasty.QuickCheck tests :: TestTree tests = testGroup "TPraos Ledger compat" [ testProperty "tick" testTickCompat ] data TickSetup p = TickSetup { tsConsensusConfig :: Blind (ConsensusConfig p) , tsTickedLedgerView :: Ticked (LedgerView p) , tsSlotNo :: SlotNo , tsChainDepState :: ChainDepState p } instance Crypto c => Arbitrary (TickSetup (TPraos c)) where arbitrary = do initialNonce <- arbitrary let tpraosParams = TPraosParams { tpraosSlotsPerKESPeriod = SL.slotsPerKESPeriod globals , tpraosLeaderF = SL.activeSlotCoeff globals , tpraosSecurityParam = SecurityParam $ SL.securityParameter globals , tpraosMaxKESEvo = SL.maxKESEvo globals , tpraosQuorum = SL.quorum globals , tpraosMaxMajorPV = MaxMajorProtVer $ SL.maxMajorPV globals , tpraosMaxLovelaceSupply = SL.maxLovelaceSupply globals , tpraosNetworkId = SL.networkId globals , tpraosInitialNonce = initialNonce , tpraosSystemStart = SL.systemStart globals } tsConsensusConfig = Blind TPraosConfig { tpraosParams , tpraosEpochInfo = generalizeEpochInfo $ SL.epochInfoPure globals } chainCheckPParams <- SL.ChainChecksPParams <$> arbitrary <*> arbitrary <*> arbitrary tsTickedLedgerView <- fmap TickedPraosLedgerView $ SL.LedgerView <$> arbitrary <*> arbitrary <*> arbitrary <*> arbitrary <*> pure chainCheckPParams slotAlreadyTickedTo <- frequency [ (9 , NotOrigin <$> chooseEnum (0, 1000)) , (1, pure Origin) ] slotOffset <- chooseEnum (0, 200) chainDepState <- SL.ChainDepState <$> arbitrary <*> arbitrary <*> arbitrary let tsChainDepState = TPraosState { tpraosStateLastSlot = slotAlreadyTickedTo , tpraosStateChainDepState = chainDepState } tsSlotNo = slotOffset `addSlots` fromWithOrigin 0 slotAlreadyTickedTo pure TickSetup { tsConsensusConfig , tsTickedLedgerView , tsSlotNo , tsChainDepState } where globals :: SL.Globals globals = testGlobals testTickCompat :: Blind (TickSetup (TPraos StandardCrypto)) -> Property testTickCompat (Blind ts) = consensusImpl === ledgerImpl where consensusImpl = tickedTPraosStateChainDepState $ tickChainDepState cfg tlv tsSlotNo cds ledgerImpl = SL.tickChainDepState (mkShelleyGlobals cfg) (getTickedPraosLedgerView tlv) tickingToNewEpoch (tpraosStateChainDepState cds) tickingToNewEpoch = epochNo (NotOrigin tsSlotNo) /= epochNo (tpraosStateLastSlot cds) where ei = toPureEpochInfo $ tpraosEpochInfo cfg epochNo = runIdentity . epochInfoEpoch ei . fromWithOrigin 0 TickSetup { tsConsensusConfig = Blind cfg , tsTickedLedgerView = tlv , tsSlotNo , tsChainDepState = cds } = ts

amesgen · 2023-09-18T13:06:11Z

ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/Protocol/Abstract.hs

+  -- | A projection of 'LedgerView' containing only what is needed for ticking
+  --
+  -- For single-era protocols, there are further constraints on this type, see
+  -- 'Ouroboros.Consensus.HardFork.Combinator.Abstract.SingleEraBlock.eraTransitionHorizonView'.
+  -- Usually, 'HorizonView' will be a singleton type.
+  --
+  -- For the 'Ouroboros.Consensus.HardFork.Combinator.Basics.HardForkProtocol'
+  -- combinator, this is the same as the 'LedgerView'.
+  type family HorizonView p :: Type


FTR: @nfrisby raised the possibility of moving this out of the generic ConsensusProtocol type class (which would stay as before this PR) and instead into SingleEraProtocol. This seems clearly desirable (less unneeded flexibility in one of our core abstractions), but only if it does not come with too much of its own complexity:

For HorizonView, this seems to work fine, one could move tickChainDepState_ and projectHorizonView into SingleEraProtocol, and require the law tickChainDepState == tickChainDepState_ . projectHorizonView.

The extra Ticked LedgerView argument in the non-tick functions is what is actually causing most of the code changes, but it is a bit unclear a priori how to handle that nicely.

Historical note: The non-tick functions in ConsensusProtocol were actually present in the past (16d61bf#diff-f738455b7b0823897ece16f7b9667badfd57532722a250f27f0f507161d2cf5c), but were removed again due to the additional error calls in the HFC (that are readded in this PR).

The second bullet point is enabled by #354.

The first bullet point will be handled by a82b126.

This adds an extremely simple mechanism that increments protocol versions on era boundaries. The motivation is to showcase that due to how HFC ticking is implemented, this does not do what one would expect. See #340 for a concrete scenario where this behavior is problematic.

jasagredo

I have gone through the commits and I think everything is very clear and properly documented. I have no judgement whether more tests would be needed or not.

dnadales · 2023-09-19T14:21:44Z

ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator.hs

@@ -138,7 +139,8 @@ prop_simple_hfc_convergence testSetup@TestSetup{..} =
    counterexample ("eraSizeA: " <> show eraSizeA) $
    tabulate "epochs in era A" [labelEraSizeA] $
    prop_general args testOutput .&&.
-    prop_allExpectedBlocks
+    prop_allExpectedBlocks .&&.
+    prop_finalProtVers


Just to confirm: we don't add an expected failure here because even if this commit won't be squashed, when bisecting we don't care about compiling the tests? Or do we? 🤔

All tests are passing at all intermediate commits; note that prop_finalProtVers initially just showcases the bug
https://github.com/input-output-hk/ouroboros-consensus/blob/e55c607ba31a9f74a7fa9deb986e47ec60783526/ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator.hs#L361-L368
and is then in a later commit, once the bug is fixed, replaced by the "correct" assertion:
https://github.com/input-output-hk/ouroboros-consensus/blob/3fdf4a2efaad33e7fdee0b99e57c94c96a762e41/ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator.hs#L362-L365
Does that make sense?

I think this is fine, though my initial expectation matches Damian's: that the test would fail until the bug is fixed.

To the broader point: I think it's fine for tests to fail between commits inside of a PR; but must pass before merge.

ouroboros-consensus-cardano/src/byron/Ouroboros/Consensus/Byron/Ledger/Ledger.hs

dnadales · 2023-09-19T14:46:21Z

ouroboros-consensus-cardano/src/shelley/Ouroboros/Consensus/Shelley/ShelleyHFC.hs

@@ -280,6 +282,57 @@ forecastAcrossShelley cfgFrom cfgTo transition forecastFor ledgerStateFrom
               (SL.stabilityWindow (shelleyLedgerGlobals cfgFrom))
               (SL.stabilityWindow (shelleyLedgerGlobals cfgTo))

+translateLedgerStateAcrossShelley ::


I wonder if it'd be worth adding a comment on what's going on in here.

In particular, contributors might be puzzled about the unticking part. Perhaps it's worth replicating here what was discussed in the issue that motivated this change.

Good point, will add a reference to the comment on translateLedgerState for context, and there also #339.

EDIT: see 161bbb9

Maybe a Haddock comment that at least highlights that the below works perfectly fine when eraTo ~ eraFrom.

Maybe a Haddock comment that at least highlights that the below works perfectly fine when eraTo ~ eraFrom.

It doesn't as that would contradict SL.PreviousEra eraTo ~ eraFrom.

dnadales · 2023-09-19T14:57:12Z

ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Ledger.hs

+--  * then translate the ledger state into the new era (using
+--    'translateLedgerState').
+--
+-- The final tick to the given slot does /not/ happen here.


I feel a bit uneasy about the fact that this function has to mention what happens elsewhere. I guess there's no way to avoid it given the current design, but it seems a very delicate piece of logic is scattered around.

Right, in this particular case, it actually happens in the same file above in applyChainTickLedgerResult, will add a reference.

EDIT: see 161bbb9

I could have sworn that I commented in this thread in my Review just now...

My recommendation was ultimately to rename the function extendToEraOfSlot or something like that.

FTR: You are probably referring to #340 (comment)

nfrisby

I've finished a pass. All the commits are very nicely organized. Thank you so much for that.

I sadly still don't feel like I have clarity on what order to merge this with the others, particularly #354

nfrisby · 2023-09-20T13:54:35Z

...s-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/TPraos.hs

+  -- https://iohk.io/en/blog/posts/2021/03/29/the-secure-transition-to-decentralization/
+  -- for additional context.
+  --
+  -- We are not aware of any other


There's an extra line break.

We should recommend in this comment that if some such deployment does in fact exist they could workaround this override in the translateChainDepState function, since that is applied after this "incorrect" tick logic.

nfrisby · 2023-09-20T13:57:52Z

ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator.hs

@@ -138,7 +139,8 @@ prop_simple_hfc_convergence testSetup@TestSetup{..} =
    counterexample ("eraSizeA: " <> show eraSizeA) $
    tabulate "epochs in era A" [labelEraSizeA] $
    prop_general args testOutput .&&.
-    prop_allExpectedBlocks
+    prop_allExpectedBlocks .&&.
+    prop_finalProtVers


I think this is fine, though my initial expectation matches Damian's: that the test would fail until the bug is fixed.

To the broader point: I think it's fine for tests to fail between commits inside of a PR; but must pass before merge.

nfrisby · 2023-09-20T13:58:30Z

ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator/A.hs

+
+      -- | The protocol version. Increments at epoch boundaries whenever
+      -- 'InitiateAtoB' would signal an era transition.
+    , lgrA_protVer :: Word16


I'd recommend using Integer instead of a finite type. No need to introduce the scent of overflows.

nfrisby · 2023-09-20T14:01:35Z

ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator.hs

+        -- should be @'succ' 'initProtVer'@), this is currently not the case.
+        -- Subsequent commits will fix this.
+        all (== initProtVer) finalProtVers
+


Intentional extra newline?

No, will remove 👍

nfrisby · 2023-09-20T14:12:51Z

ouroboros-consensus-diffusion/test/consensus-test/Test/Consensus/HardFork/Combinator/A.hs

+
+      k = lcfgA_k cfg
+
+      firstSlotNextEpoch = runIdentity $ do


My gut tells me there's an existing function for this somewhere...

I only know of the functions in Ouroboros.Consensus.Ledger.Protocol.Util (in particular isNewEpoch), but we can't use them here without shuffling things around as ouroboros-consensus-diffusion does not depend on ouroboros-consensus-protocol. I will keep it like this for now, but we could also start some EpochInfo-related utilities in ouroboros-consensus such that they can be used in both oc-diffusion and oc-protocol.

nfrisby · 2023-09-20T14:58:20Z

ouroboros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Ledger.hs

+-- The final tick to the given slot does /not/ happen here, but rather in
+-- 'applyChainTickLedgerResult' above.
+--
+-- It can be the case that the telescope is extended multiple times, for example


We may need to elaborate on "empty eras". Two flavors:

There are no epochs in the era: eg our benchmarking hacking.

There are epochs in the era but no blocks in any of those epochs: never happens on a healthy Cardano ledger, but some other ledger might allow that 🤷.

Good point, for the example here, I will make it specifically about the zero-epoch eras for benchmarking as that is the most relevant case today.

nfrisby · 2023-09-20T15:07:42Z

...s-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/TPraos.hs

@@ -247,6 +248,14 @@ newtype instance Ticked (SL.LedgerView c) = TickedPraosLedgerView {
      getTickedPraosLedgerView :: SL.LedgerView c
    }

+newtype TPraosHorizonView = TPraosHorizonView {


... want to make this empty?

nfrisby · 2023-09-20T15:09:04Z

...s-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/TPraos.hs

+
+      -- We can't use 'SL.tickChainDepState' as it unnecessarily takes the
+      -- entire 'SL.LedgerView' as an argument. Hence, we inline it here; future
+      -- work should include moving the TPraos logic entirely to Consensus.


Suggested change

-- work should include moving the TPraos logic entirely to Consensus.

-- work should include moving the TPraos logic entirely to the ouroboros-consensus repository.

nfrisby · 2023-09-20T15:11:31Z

...us-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/Praos/Translate.hs

 import qualified Ouroboros.Consensus.Protocol.TPraos as TPraos
 import           Ouroboros.Consensus.Protocol.Translate (TranslateProto (..))

 {-------------------------------------------------------------------------------
  Translation from transitional Praos
 -------------------------------------------------------------------------------}

+instance (c1 ~ c2) => TranslateProto (TPraos c1) (TPraos c2) where


I wonder if the error message would actually be easier to understand if the head was TranslateProto (TPraos c) (TPraos c)?

And same for Praos below.

I would have to play around to find this out, I think the way how it is written here can sometimes be beneficial because it causes instances selection to pick this instance even if it does not (yet) know c1 ~ c2 (a similar example is discussed here).

nfrisby · 2023-09-20T15:12:32Z

...s-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/TPraos.hs

@@ -253,7 +255,7 @@ newtype TPraosHorizonView = TPraosHorizonView {
    }

 newtype instance Ticked TPraosHorizonView = TickedTPraosHorizonView {
-      tickedTpraosHorizonViewExtraEntropy :: SL.Nonce
+      tickedTPraosHorizonViewExtraEntropy :: SL.Nonce


Minor: preferably this diff is squashed into the commit that introduces TickedTPraosHorizonView

nfrisby

I think a82b126 is important.

We should squash it down.

This adds an extremely simple mechanism that increments protocol versions on era boundaries. The motivation is to showcase that due to how HFC ticking is implemented, this does not do what one would expect. See #340 for a concrete scenario where this behavior is problematic.

Trivial generalization that will be used in subsequent commits

In a subsequent commit, we will use this extra information when invoking `State.align`.

Initial motivation for this is the need (in a later commit) to implement the translation of the last *ticked* Byron ledger state to the first Shelley state, which becomes possible as `ByronTransition` is part of the ticked Byron ledger state. Apart from the translation to Shelley, this tip block number is only used to check whether an update proposal became stable, so it makes sense to make it part of `ByronTransition` in any case.

This doesn't actually change any code, and is mostly done to highlight the changes to this function in the next commit.

See #339 for explanation/motivation.

In a single-era context, this change makes no difference for the slot field in the unticked `ChainDepState (T)Praos`, as the slot we last ticked to will always be the slot of the last applied block. However, in a later commit, we will change how the HFC does cross-era ticking, namely by first ticking just across the epoch boundary using the old era's logic, then translating, and then ticking to the target slot using the new era's logic. - Without this change, as the slot in the unticked `ChainDepState` is not update by ticking, we would conclude twice that we are ticking across an epoch, which is incorrect. - With this change, only the first tick considers itself to cross an epoch boundary. Hence, after the translation step, the slot in the unticked `ChainDepState` will *not* contain the slot of the last applied block, but rather the slot just after the era boundary (as we ticked to that slot in the first tick). Note that this is purely an intermediary state in the HFC.

Context: This commit enables changing the HFC protocol logic for ticking. This change is based on the observation that all single-era `ConsensusProtocol`s except TPraos do not actually need the `LedgerView` when ticking at all; they just store it in the `Ticked ChainDepState` such that it can be used by other functions from `ConsensusProtocol`, such as `updateChainDepState` and `checkIsLeader`. Hence, we can introduce a new type family `HorizonView` (that will be set to `()` for all single-era protocols except TPraos), and decompose `tickChainDepState` into `tickChainDepState_` (which now only takes a horizon view instead of a ledger view) and `projectHorizonView` (which allows one to always get a horizon view from a ledger view). TPraos and the HardForkProtocol are just minimally modified to make them compile; they will be adapted in subsequent commits. Co-authored-by: Nicolas Frisby <[email protected]>

This commit minimizes the `HorizonView` for TPraos from the full `LedgerView` to just the extra entropy nonce (a ledger protocol parameter), which is the only part of the `LedgerView` needed for ticking. Co-authored-by: Nicolas Frisby <[email protected]>

Sole motivation is to make HFC protocol ticking analogous to HFC ledger ticking which was already changed in an earlier commit. Co-authored-by: Nicolas Frisby <[email protected]>

amesgen · 2023-10-11T16:48:49Z

Closing for now, see #339 (comment)

amesgen commented Sep 7, 2023

View reviewed changes

...consensus-cardano/src/ouroboros-consensus-cardano/Ouroboros/Consensus/Cardano/CanHardFork.hs Outdated Show resolved Hide resolved

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch 2 times, most recently from fad165f to 5d8e37e Compare September 8, 2023 12:03

nfrisby reviewed Sep 8, 2023

View reviewed changes

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch 3 times, most recently from 223d5e7 to 2948b49 Compare September 8, 2023 14:07

nfrisby force-pushed the amesgen/hfc-tick-translate-tick branch from 7ead180 to 862d6e4 Compare September 9, 2023 15:20

nfrisby reviewed Sep 9, 2023

View reviewed changes

...oros-consensus/src/ouroboros-consensus/Ouroboros/Consensus/HardFork/Combinator/Embed/Nary.hs Outdated Show resolved Hide resolved

nfrisby reviewed Sep 9, 2023

View reviewed changes

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch 2 times, most recently from 0d61028 to d90792b Compare September 11, 2023 12:06

amesgen changed the title ~~First tick across the era boundary when translating the ledger state~~ First tick across the era boundary when translating the ledger/chain-dep state Sep 11, 2023

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch 3 times, most recently from bf6c179 to 4e9939d Compare September 13, 2023 11:16

nfrisby mentioned this pull request Sep 14, 2023

[FEAT] - Generalize how the HFC handles era transitions #345

Open

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch from 4e9939d to 5deb3cc Compare September 15, 2023 14:03

amesgen mentioned this pull request Sep 18, 2023

Move TPraos logic from Ledger into Consensus #350

Open

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch from 5deb3cc to c589290 Compare September 18, 2023 12:13

amesgen commented Sep 18, 2023

View reviewed changes

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch from c589290 to 8608c57 Compare September 19, 2023 08:38

amesgen marked this pull request as ready for review September 19, 2023 09:11

amesgen requested a review from a team as a code owner September 19, 2023 09:11

jasagredo approved these changes Sep 19, 2023

View reviewed changes

dnadales reviewed Sep 19, 2023

View reviewed changes

ouroboros-consensus-cardano/src/byron/Ouroboros/Consensus/Byron/Ledger/Ledger.hs Show resolved Hide resolved

dnadales reviewed Sep 19, 2023

View reviewed changes

dnadales approved these changes Sep 19, 2023

View reviewed changes

nfrisby mentioned this pull request Sep 19, 2023

Move ticked LedgerView out of ticked ChainDepState #354

Closed

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch from 161bbb9 to cbd72f0 Compare September 20, 2023 09:00

nfrisby approved these changes Sep 20, 2023

View reviewed changes

nfrisby requested changes Sep 20, 2023

View reviewed changes

amesgen and others added 11 commits September 21, 2023 13:20

Translate: allow heterogenous translations

e434e34

Trivial generalization that will be used in subsequent commits

Translate: supply the full Bound instead of just the EpochNo

d32e16d

In a subsequent commit, we will use this extra information when invoking `State.align`.

extendToSlot: move to ledger sibling module

899afd4

This doesn't actually change any code, and is mostly done to highlight the changes to this function in the next commit.

HFC ledger cross-era ticking: use tick-translate-tick strategy

5c3a366

See #339 for explanation/motivation.

HFC protocol cross-era ticking: use tick-translate-tick strategy

1a0654e

Sole motivation is to make HFC protocol ticking analogous to HFC ledger ticking which was already changed in an earlier commit. Co-authored-by: Nicolas Frisby <[email protected]>

TOSQUASH isolate HorizonView in SingleEraProtocol

d77452d

amesgen force-pushed the amesgen/hfc-tick-translate-tick branch from a82b126 to d77452d Compare September 21, 2023 13:14

amesgen mentioned this pull request Oct 11, 2023

Change implementation of ticking in the HFC to tick-then-translate-then-tick #339

Closed

amesgen closed this Oct 11, 2023

amesgen deleted the amesgen/hfc-tick-translate-tick branch October 11, 2023 16:49

	-- work should include moving the TPraos logic entirely to Consensus.
	-- work should include moving the TPraos logic entirely to the ouroboros-consensus repository.

First tick across the era boundary when translating the ledger/chain-dep state #340

First tick across the era boundary when translating the ledger/chain-dep state #340

Conversation

amesgen commented Sep 7, 2023 • edited Loading

nfrisby left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amesgen Sep 19, 2023 • edited Loading

Choose a reason for hiding this comment

amesgen Sep 18, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jasagredo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amesgen Sep 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amesgen Sep 19, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nfrisby left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nfrisby left a comment

Choose a reason for hiding this comment

amesgen commented Oct 11, 2023

amesgen commented Sep 7, 2023 •

edited

Loading

amesgen Sep 19, 2023 •

edited

Loading

amesgen Sep 18, 2023 •

edited

Loading

amesgen Sep 19, 2023 •

edited

Loading

amesgen Sep 19, 2023 •

edited

Loading