Merge branch 'nc/ledger-int' of github.com:input-output-hk/ouroboros-…

…network into nc/ledger-int

ouroboros-consensus/src/Ouroboros/Consensus/Ledger/Mock.hs

@@ -50,6 +50,7 @@ import           Data.FingerTree (Measured (measure))
 import qualified Data.IntMap.Strict as IntMap
 import           Data.Map (Map)
 import qualified Data.Map.Strict as Map
+import           Data.Maybe (mapMaybe)
 import           Data.Proxy
 import           Data.Set (Set)
 import qualified Data.Set as Set
@@ -459,12 +460,30 @@ instance (SimpleBlockCrypto c')
   anachronisticProtocolLedgerView (EncNodeConfig _ pbftParams) _ _
     = Just $ slotUnbounded pbftParams
 
+-- | 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
+-- 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
+-- may not be worth it; it would be a bit of work, and after we have integrated
+-- the Shelley rules, we'll have a proper instance anyway.
 instance ( PraosCrypto c, SimpleBlockCrypto c')
       => ProtocolLedgerView (SimpleBlock (ExtNodeConfig AddrDist (Praos c)) c') where
-  protocolLedgerView (EncNodeConfig _ addrDist) (SimpleLedgerState u _) =
-      relativeStakes $ totalStakes addrDist u
+  protocolLedgerView (EncNodeConfig _ addrDist) _ =
+      equalStakeDistr addrDist
+  anachronisticProtocolLedgerView (EncNodeConfig _ addrDist) _ _ =
+      Just $ slotUnbounded $ equalStakeDistr addrDist
+
+equalStakeDistr :: AddrDist -> StakeDist
+equalStakeDistr = IntMap.fromList
+                . mapMaybe (nodeStake . snd)
+                . Map.toList
+  where
+    nodeStake :: NodeId -> Maybe (Int, Rational)
+    nodeStake (RelayId _) = Nothing
+    nodeStake (CoreId i)  = Just (i, 1)
 
-  anachronisticProtocolLedgerView = error "TODO: write up discussion with Jared, Nicholas and Duncan"
 
 instance (PraosCrypto c, SimpleBlockCrypto c')
       => ProtocolLedgerView (SimpleBlock (WithLeaderSchedule (Praos c)) c') where

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

@@ -92,6 +92,44 @@ class ( Show (ChainState    p)
   type family IsLeader p :: *
 
   -- | Projection of the ledger state the Ouroboros protocol needs access to
+  --
+  -- The 'LedgerView' is a summary of the state of the ledger that the consensus
+  -- algorithm requires to do its job. Under certain circumstances the consensus
+  -- algorithm may require the 'LedgerView' for slots in the past (before the
+  -- current tip of the chain) or in the (near) future (beyond the tip of the
+  -- current chain, without having seen those future blocks yet).
+  --
+  -- This puts limitations on what the 'LedgerView' can be. For example, it
+  -- cannot be the "current stake distribution", since it is of course
+  -- impossible to compute the current stake distibution for a slot in the
+  -- 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
+  -- (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)
+  -- 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
+  -- distribution).
+  --
+  -- There are also some /advantages/ to moving these sorts of decisions to the
+  -- ledger layer. It means that the consensus algorithm can continue to
+  -- function without modifications if we decide that the stake distribution for
+  -- leader selection should be based on something else instead (for example,
+  -- for some bespoke version of the blockchain we may wish to use a committee
+  -- instead of a decentralized blockchain). Having sampling decisions in the
+  -- ledger layer rather than the consensus layer means that these decisions can
+  -- 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
+  -- 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).
   type family LedgerView p :: *
 
   -- | Validation errors