Merge pull request #101 from gmalouf/dynamic-specs-update

Dynamic Filter Timeout, Period 0 Deadline Timeout, State Proof Blockhash Attestment

dev/abft.md

@@ -46,9 +46,11 @@ Parameters
 
 \newcommand \FilterTimeout {\mathrm{FilterTimeout}}
 
+\newcommand \DeadlineTimeout {\mathrm{DeadlineTimeout}}
+
 The protocol is parameterized by the following constants:
 
- - $\lambda, \lambda_0, \lambda_f, \Lambda$ are values representing durations of time.
+ - $\lambda, \lambda_{0min}, \lambda_{0max}, \lambda_f, \Lambda, \Lambda_0$ are values representing durations of time.
  - $\delta_s, \delta_r$ are positive integers (the "seed lookback" and
    "seed refresh interval").
 
@@ -58,12 +60,23 @@ $2\delta_s\delta_r$.
 We define $\FilterTimeout(p)$ on period $p$ as follows:
 
   - If $p = 0$:
-    - $\FilterTimeout(p) = 2\lambda_0$
+    The $\FilterTimeout(p)$ is calculated dynamically based on the lower 95th percentile of observed 
+    lowest credential per round arrival times. 
+
+    - 2$\lambda_{0min} <= \FilterTimeout(p) <= 2\lambda_{0max}$
   - If $p \ne 0$:
     - $\FilterTimeout(p) = 2\lambda$
 
-Algorand sets $\delta_s = 2$, $\delta_r = 80$, $\lambda = 2$ seconds,
-$\lambda_0 = 1.5$ seconds, $\lambda_f = 5$ minutes, and $\Lambda = 17$ seconds.
+We define $\DeadlineTimeout(p)$ on period $p$ as follows:
+
+  - If $p = 0$:
+    - $\DeadlineTimeout(p) = \Lambda_0$
+  - If $p \ne 0$:
+    - $\DeadlineTimeout(p) = \Lambda$
+
+
+Algorand sets $\delta_s = 2$, $\delta_r = 80$, $\lambda = 2$ seconds, $\lambda_{0min} = 0.25$ seconds, 
+$\lambda_{0max} = 1.5$ seconds, $\lambda_f = 5$ minutes, $\Lambda = 17$ seconds, and $\Lambda_0 = 4$ seconds.
 
 Identity, Authorization, and Authentication
 ===========================================
@@ -804,11 +817,11 @@ A player may also update its step after receiving a timeout event.
 On observing a timeout event of $\FilterTimeout(p)$ for period $p$, the player sets
 $s := \Cert$.
 
-On observing a timeout event of $\max\{4\lambda, \Lambda\}$, the
+On observing a timeout event of $\DeadlineTimeout(p)$ for period $p$, the
 player sets $s := \Next_0$.
 
 On observing a timeout event of
-$\max\{4\lambda, \Lambda\} + 2^{s_t}\lambda + r$ where
+$\DeadlineTimeout(p) + 2^{s_t}\lambda + r$ where
 $r \in [0, 2^{s_t}\lambda]$ sampled uniformly at random, the player sets
 $s := s_t$.
 
@@ -817,10 +830,10 @@ $$
 \begin{aligned}
   &N((r, p, s, \sbar, V, P, \vbar), L, t(\FilterTimeout(p), p))
  &&= ((r, p, \Cert, \sbar, V, P, \vbar), L', \ldots) \\
-  &N((r, p, s, \sbar, V, P, \vbar), L, t(\max\{4\lambda, \Lambda\}, p))
+  &N((r, p, s, \sbar, V, P, \vbar), L, t(\DeadlineTimeout(p), p))
  &&= ((r, p, \Next_0, \sbar, V, P, \vbar), L', \ldots) \\
   &N((r, p, s, \sbar, V, P, \vbar), L,
-     t(\max\{4\lambda, \Lambda\} + 2^{s_t}\lambda + r, p))
+     t(\DeadlineTimeout(p) + 2^{s_t}\lambda + r, p))
  &&= ((r, p, s_t, \sbar, V, P, \vbar), L', \ldots).
  \end{aligned}
 $$
@@ -1050,8 +1063,8 @@ Recovery
 
 On observing a timeout event of
 
- - $T = \max\{4\lambda, \Lambda\}$ or
- - $T = \max\{4\lambda, \Lambda\} + 2^{s_t}\lambda + r$ where
+ - $T = \DeadlineTimeout(p)$ or
+ - $T = \DeadlineTimeout(p) + 2^{s_t}\lambda + r$ where
    $r \in [0, 2^{s_t}\lambda]$ sampled uniformly at random,
 
 the player attempts to resynchronize and then broadcasts*

dev/crypto.md

@@ -345,7 +345,7 @@ where:
 - _StateProofPK_ is a 512-bit string representing the participant's merkle signature scheme commitment.
 
 
-## Signature format 
+## Signature format
 
 Similarly to the participant commitment, the state proof scheme requires a commitment
 to a signature array. Leaf hashing is done in the following manner:

dev/ledger.md

@@ -35,7 +35,7 @@ The Algorand Ledger is parameterized by the following values:
    Currently defined as 10,000.
  - $\delta_{x_{\min}}$ and $\delta_{x_{\max}}$, the minimum and maximum number
    of rounds needed to prepare for an upgrade.  Currently respectively defined
-   as 10,000 and 150,000.
+   as 10,000 and 250,000.
  - $\delta_x$, the default number of rounds needed to prepare for an upgrade.
    Currently defined as 140,000.
  - $\omega_r$, the rate at which the reward rate is refreshed.
@@ -551,7 +551,9 @@ offline as part of applying the block changes to the ledger.
 A light block header is a structure contains a subset of fields from Algorand's  _block header_.
 Light block header contains the following components:
 
-- The block's _seed_, under msgpack key `s`.
+- The block's _seed_, under msgpack key `0`.
+
+- The block's _hash_, under msgpack key `1`.
 
 - The block's _genesis hash_, under msgpack key `gh`.
 

overview/latex/appendix/ParameterTable.tex

@@ -32,10 +32,14 @@
  \hline
  $\lambda (seconds)$ & 2\\
  \hline
- $\lambda_0 (seconds)$ & 1.5\\
+ $\lambda_{0min} (seconds)$ & 0.25\\
+ \hline
+ $\lambda_{0max} (seconds)$ & 1.5\\
  \hline
  $\Lambda (seconds)$ & 17\\
  \hline
+ $\Lambda_0 (seconds)$ & 4\\
+ \hline
  $\lambda_f (seconds)$ & 300\\
  \hline
 \end{tabular}

overview/latex/sections/DetailedConsensus.tex

@@ -70,9 +70,13 @@ \subsection{Timing Parameters}
 
 \item $\lambda$: intuitively corresponds to the time that it takes a small message (e.g. a vote) to propagate in good network conditions.
 
-\item $\lambda_0$: intuitively corresponds to the time that it takes a small message (e.g. a vote) to propagate under ideal network conditions for period $0$, failling back to $\lambda$ in future periods if $\lambda_0$ was not sufficient to make progress.
+\item $\lambda_{0min}$: corresponds to the minimum amount of time the dynamic algorithm must allow for a small message (e.g. a vote) to propagate under ideal network conditions for period $0$, failing back to $\lambda$ in future periods if calculated duration was not sufficient to make progress.
 
-\item $\Lambda$: intuitively corresponds to the time it takes a big message (e.g. a block) to propagate in good network conditions.
+\item $\lambda_{0max}$: corresponds to the maximum amount of time the dynamic algorithm will allow for a small message (e.g. a vote) to propagate under ideal network conditions for period $0$, failing back to $\lambda$ in future periods if the calculated duration was not sufficient to make progress.
+
+\item $\Lambda$: intuitively corresponds to the time it takes a big message (e.g. a block) to propagate in reasonable network conditions.
+
+\item $\Lambda_0$: intuitively corresponds to the time it takes a big message (e.g. a block) to propagate in good network conditions for period $0$, failing back to $\Lambda$ in future periods if $\Lambda_0$ was not sufficient to propagate the block.
 
 \item $\lambda_f$: the frequency at which the fast partition recovery steps are repeated.