Finish ledger description

ouroboros-consensus/docs/report/chapters/consensus.tex

@@ -17,9 +17,10 @@ \subsection{The security parameter $k$}
 \label{param:k}
 
 \section{Chain selection}
+\label{chain-selection}
 
 \subsection{Overview}
-\label{chain-selection-overview}
+\label{chain-selection:overview}
 
 Chain selection is the process of choosing between multiple competing chains,
 and is one of the most important responsibilities of a consensus protocol. When
@@ -55,6 +56,7 @@ \subsection{Overview}
 EBBs; see \cref{ebb-chain-selection}.}
 
 \subsection{Interface}
+\label{chain-selection:interface}
 
 \todo{Why separate class?}
 We model chain selection as its own class\footnote{Here and elsewhere we elide
@@ -77,7 +79,7 @@ \subsection{Interface}
 type ChainSelConfig p = ()
 \end{lstlisting}
 
-As mentioned in \cref{chain-selection-overview}, chain selection will only look
+As mentioned in \cref{chain-selection:overview}, chain selection will only look
 at the blocks at the tip of the ledger. Since we are defining consensus
 protocols independent from a concrete choice of ledger, however
 (\cref{decouple-consensus-ledger}), we cannot use a concrete block type.
@@ -128,7 +130,7 @@ \subsection{Interface}
 compareCandidates _ _           = compare
 \end{lstlisting}
 
-\subsection{Full protocol}
+\section{Full protocol}
 \label{class:ConsensusProtocol}
 
 The main class modelling the consensus protocol has chain selection as a
@@ -144,7 +146,8 @@ \subsection{Full protocol}
 consensus protocol, and the second deals with leader selection. We will discuss
 these separately.
 
-\subsubsection{Configuration}
+\subsection{Configuration}
+\label{class:ConsensusProtocol:config}
 
 Each consensus protocol defines its own type of required static
 configuration:\footnote{This is defined as a data family rather than a type
@@ -178,7 +181,8 @@ \subsubsection{Configuration}
 moved from the volatile DB to the immutable DB
 (\cref{immutable-volatile-split}).
 
-\subsubsection{Ledger view}
+\subsection{Ledger view}
+\label{class:ConsensusProtocol:ledgerview}
 
 We mentioned in \cref{overview:ledger} that some consensus protocols may require
 limit information from the ledger; for instance, the Praos consensus protocol
@@ -194,7 +198,8 @@ \subsubsection{Ledger view}
 state of the consensus protocol. We will discuss this state management in more
 detail next.
 
-\subsubsection{Protocol state management}
+\subsection{Protocol state management}
+\label{class:ConsensusProtocol:state}
 
 Each consensus protocol has its own type chain dependent state\footnote{We are
 referring to this as the ``chain dependent state'' to emphasize that this is
@@ -283,7 +288,8 @@ \subsubsection{Protocol state management}
 \todo{How does this relate to the best case == worst case thing? Or to the
 asymptotic attacker/defender costs?}
 
-\subsubsection{Leader selection}
+\subsection{Leader selection}
+\label{class:ConsensusProtocol:leaderselection}
 
 The final responsibility of the consensus protocol is leader selection. First,
 it is entirely possible for nodes to track the blockchain without ever producing
@@ -323,6 +329,40 @@ \subsubsection{Leader selection}
   -> Maybe (IsLeader       p)
 \end{lstlisting}
 
+\section{Connecting a block to a protocol}
+\label{BlockSupportsProtocol}
+
+Although a single consensus protocol might be used with many blocks, any given
+block is designed for a \emph{single} consensus protocol. The following type
+family witnesses this relation:
+%
+\begin{lstlisting}
+type family BlockProtocol blk :: Type
+\end{lstlisting}
+%
+Of course, for the block to be useable with that consensus protocol, we need
+functions that construct the \lstinline!SelectView!
+(\cref{chain-selection:interface}) and \lstinline!ValidateView!
+(\cref{class:ConsensusProtocol:state}) projects from that block:
+%
+\begin{lstlisting}
+class (..) => BlockSupportsProtocol blk where
+  validateView ::
+       BlockConfig blk
+    -> Header blk -> ValidateView (BlockProtocol blk)
+
+  selectView ::
+       BlockConfig blk
+    -> Header blk -> SelectView (BlockProtocol blk)
+\end{lstlisting}
+%%
+The \lstinline!BlockConfig! is the static configuration required to work with
+blocks of this type; it's just another data family:
+%
+\begin{lstlisting}
+data family BlockConfig blk :: Type
+\end{lstlisting}
+
 \section{Permissive BFT}
 \label{bft}
 

ouroboros-consensus/docs/report/chapters/future.tex

@@ -18,3 +18,10 @@ \section{Transaction TTL}
 \label{future:ttl}
 
 Describe that the mempool could have explicit support for TTL, but that right now we don't (and why this is ok: the ledger anyway checks tx TTL). We should discuss why this is not an attack vector (transactions will either be included in the blockchain or else will be chucked out because some of their inputs will have been used).
+
+\section{Block based versus slot based}
+\label{future:block-vs-slot}
+
+\section{Configuration}
+
+What a mess.