report: Ledger Database

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

@@ -284,12 +284,12 @@ \subsection{Protocol state management}
 
 Re-applying previously-validated blocks happens when we are replaying blocks
 from the immutable database when initialising the in-memory ledger state
-(\cref{ledgerdb:initialisation}). It is also useful during chain selection
-(\cref{chainsel}): depending on the consensus protocol, we may end up switching
-relatively frequently between short-lived forks; when this happens, skipping
-expensive checks can improve the performance of the node. \todo{How does this
-relate to the best case == worst case thing? Or to the asymptotic
-attacker/defender costs?}
+(\cref{ledgerdb:on-disk:initialisation}). It is also useful during chain
+selection (\cref{chainsel}): depending on the consensus protocol, we may end up
+switching relatively frequently between short-lived forks; when this happens,
+skipping expensive checks can improve the performance of the node. \todo{How
+  does this relate to the best case == worst case thing? Or to the asymptotic
+  attacker/defender costs?}
 
 \subsection{Leader selection}
 \label{consensus:class:leaderselection}

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

@@ -47,8 +47,8 @@ \section{Serialising for storage}
 
 \begin{itemize}
 \item Blocks
-\item The extended ledger state (\cref{storage:extledgerstate}) which is the
-  combination of:
+\item The extended ledger state (see \cref{storage:extledgerstate} and
+  \cref{ledgerdb:on-disk}) which is the combination of:
   \begin{itemize}
   \item The header state (\cref{storage:headerstate})
   \item The ledger state\todo{link?}