Skip to content
Permalink
Browse files

Address review feedback

  • Loading branch information...
edsko committed May 15, 2019
1 parent 33fa26e commit 96c70985080d4ef9c01a45066597dd98721aef69
@@ -438,7 +438,7 @@ instance (PBftCrypto c, SimpleBlockCrypto c')

-- | Praos needs a ledger that can give it the "active stake distribution"
--
-- TODO: Currently out mock ledger does not do this, and just assumes that all
-- TODO: Currently our mock ledger does not do this, and just assumes that all
-- the leaders have equal stake at all times. In a way this is not wrong: it
-- is just a different instantiation of the same consensus algorithm (see
-- documentation of 'LedgerView'). Ideally we'd change this however, but it
@@ -103,12 +103,12 @@ class ( Show (ChainState p)
-- future. This means that for a consensus algorithm that requires the
-- stake distribution such as Praos, the 'LedgerView' for a particular slot
-- must be the "stake distribution for the purpose of leader selection".
-- This "active" stake distribution /can/ be computed for slots in the
-- This "relevant" stake distribution /can/ be computed for slots in the
-- (near) future because it is based on historical stake, not current.
--
-- A somewhat unfortunate consequence of this is that some decisions that
-- ought to live in the consensus layer (such as the decision precisely which
-- historical stake to sample to determine the active stake distribution)
-- historical stake to sample to determine the relevant stake distribution)
-- instead live in the ledger layer. It is difficult to disentangle this,
-- because the ledger may indeed /depend/ on those sampling decisions (for
-- example, reward calculations /must/ be based on that same stake
@@ -124,7 +124,7 @@ class ( Show (ChainState p)
-- be made without modifying the consensus algorithm.
--
-- Note that for the specific case of Praos, whilst the ledger layer provides
-- the active stake distribution, the precise leader election must still live
-- the relevant stake distribution, the precise leader election must still live
-- in the consensus layer since that depends on the computation (and sampling)
-- of entropy, which is done consensus side, not ledger side (the reward
-- calculation does not depend on this).

0 comments on commit 96c7098

Please sign in to comment.
You can’t perform that action at this time.