Regenerate tex, pdf and diff pdf

Author: drskalman

runtime-environment-spec/polkadot_re_spec.tex

@@ -80,7 +80,7 @@
   {\Large Protocol Specification}
 }
 
-\date{November 4, 2019}
+\date{November 5, 2019}
 
 \maketitle
 
@@ -721,9 +721,9 @@ \chapter{State Transition}\label{chap-state-transit}
 executing ordered set of instructions. These instructions are known as
 {\tmem{extrinsics}}. In Polkadot, the execution logic of the state-transition
 function is encapsulated in Runtime as defined in Definition
-\ref{defn-state-machine}. Runtime is presented as a Wasm blob in(if?) ordered
-be easily upgradable. Nonetheless, the Polkadot Runtime Environment needs to
-be in constant interaction with Runtime. The detail of such interaction is
+\ref{defn-state-machine}. Runtime is presented as a Wasm blob in order to be
+easily upgradable. Nonetheless, the Polkadot Runtime Environment needs to be
+in constant interaction with Runtime. The detail of such interaction is
 further described in Section \ref{sect-entries-into-runtime}.
 
 In Section \ref{sect-extrinsics}, we specify the procedure of the process
@@ -797,12 +797,12 @@ \subsection{Loading the Runtime Code \ \ }\label{sect-loading-runtime-code}
 \end{notation}
 
 The initial runtime code of the chain is embedded as an extrinsics into the
-chain initialization JSON file and is submitted to Polkadot RE (see Section
-\ref{sect-genisis-block}).
+chain initialization JSON file (representing the genesis block) and is
+submitted to Polkadot RE (see Section \ref{sect-genisis-block}).
 
-Subsequent calls to the runtime have the ability to call the storage API (see
-Section \ref{sect-runtime-api}) to insert a new Wasm blob into runtime storage
-slot to upgrade the runtime.
+Subsequent calls to the runtime have the ability to, in turn, call the storage
+API (see Section \ref{sect-re-api}) to insert a new Wasm blob into runtime
+storage slot to upgrade the runtime.
 
 \subsection{Code Executor}
 
@@ -880,29 +880,42 @@ \subsubsection{The Return Value from a Runtime
 
 \section{Extrinsics}\label{sect-extrinsics}
 
-The block body consists of an array of extrinsics. Nonetheless, Polkadot RE
-does not specify or limit the internals of each extrinsics. From Polkadot RE
-point of view, each extrinsics is simply a SCALE-encoded byte array (see
-Definition \ref{defn-scale-byte-array}).
+The block body consists of an array of extrinsics. In a broad sense
+exterinsics are data from outside of the state which can trigger the state
+transition. This section describe the specification of extrinsics and their
+inclusion in the block.
 
 \subsection{Preliminaries}
 
+The extrinsics are dividedd into two main categories defined as follows:
+
 \begin{definition}
-  \label{defn-account-key}{\tmstrong{Account key $(\tmop{sk}^a,
-  \tmop{pk}^a)$}} is a pair of Ristretto SR25519 used to sign extrinsics among
-  other accounts and blance-related functions.
+  {\tmstrong{Transaction extrinsics}} are extrinsics which are signed using
+  either of the key types described in section \ref{sect-cryptographic-keys}
+  and broadcasted between the nodes. {\tmstrong{Inherents extrinsics}} are
+  unsigned extrinsics which are generated by Polkadot RE and only included in
+  the block produced by the node itself. They are broadcasted as part of the
+  produced block rather than being gossiped as individual extrinsics
 \end{definition}
 
-\subsection{Extrinsics Submission}
+Polkadot RE does not specify or limit the internals of each extrinsics and
+those are dealt with by the Runtime. From Polkadot RE point of view, each
+extrinsics is simply a SCALE-encoded byte array (see Definition
+\ref{defn-scale-byte-array}).
+
+\subsection{Transactions}
 
-Extrinsic submission is made by sending a {\tmem{Transactions}} network
+\subsubsection{Transaction Submission}
+
+Transaction submission is made by sending a {\tmem{Transactions}} network
 message. The structure of this message is specified in Section
 \ref{sect-msg-transactions}. Upon receiving a Transactions message, Polkadot
-RE decodes the transaction and calls \tmverbatim{validate\_trasaction} runtime
-function, defined in Section \ref{sect-rte-validate-transaction}, to check the
-validity of the extrinsic. If \tmverbatim{validate\_transaction} considers the
-submitted extrinsics as a valid one, Polkadot RE makes the extrinsics
-available for the consensus engine for inclusion in future blocks.
+RE decodes and decouple the transactions and calls
+\tmverbatim{validate\_trasaction} Runtime entry, defined in Section
+\ref{sect-rte-validate-transaction}, to check the validity of each of received
+transaction. If \tmverbatim{validate\_transaction} considers the submitted
+transaction as a valid one, Polkadot RE makes the transaction available for
+the consensus engine for inclusion in future blocks.
 
 \subsection{Transaction Queue}
 
@@ -911,12 +924,12 @@ \subsection{Transaction Queue}
 transactions are submitted to the node through the {\tmem{transactions}}
 network message specified in Section \ref{sect-msg-transactions}. Upon
 receiving a transactions message, Polkadot RE separates the submitted
-transactions in the transactions message into individual extrinsics and passes
-them to the Runtime by executing Algorithm \ref{algo-validate-transactions} to
-validate and store them for inclusion into future blocks. To that aim,
-Polkodot RE should keep a {\tmem{transaction pool{\index{transaction pool}}}}
-and a {\tmem{transaction queue}}{\index{transaction queue}} defined as
-follows:
+transactions in the transactions message into individual transactions and
+passes them to the Runtime by executing Algorithm
+\ref{algo-validate-transactions} to validate and store them for inclusion into
+future blocks. To that aim, Polkodot RE should keep a {\tmem{transaction
+pool{\index{transaction pool}}}} and a {\tmem{transaction
+queue}}{\index{transaction queue}} defined as follows:
 
 \begin{definition}
   The {\tmstrong{Transaction Queue}} of a block producer node, formally
@@ -933,7 +946,7 @@ \subsection{Transaction Queue}
 \custombinding{4}{\noindent}\begin{tabular}{l}
   \hline
   \tmtextsc{Algorithm  4. }
-  \label{algo-validate-transactions}{\tmname{Validate-Extrinsics-and-Store}}($M_T
+  \label{algo-validate-transactions}{\tmname{Validate-Transactions-and-Store}}($M_T
   :$Transaction Message)\\
   \hline
 \end{tabular}
@@ -1011,6 +1024,33 @@ \subsection{Transaction Queue}
 
 \hrulefill{\medskip}
 
+\subsubsection{Inherents}
+
+Block inherent data represent the totality of inherent extrinsics included in
+each block. In general, these data are collected or generated by Polkadot RE
+and handed to Runtime for inclusion in the block. Table
+\ref{tabl-inherent-data} lists these inherent data, their identifiers, and
+types.
+
+\begin{table}[h]
+  \begin{tabular}{lll}
+    \hline
+    Identifier & Type  & Description\\
+    \hline
+    timstap0 & u64 & Unix epoch time in number of seconds\\
+    babeslot & u64 & Babe Slot Number\tmrsup{\ref{defn-epoch-slot}}\\
+    \hline
+  \end{tabular}
+  \caption{\label{tabl-inherent-data}List of inherent data}
+\end{table}
+
+\begin{definition}
+  \label{defn-func-inherent-data}The function
+  {\tmname{Block-Inherents-Data($B_n$)}} return the inherent data defined in
+  Table \ref{tabl-inherent-data} corresponding to Block $B$ as a SCALE encoded
+  dictionary as defined in Definition \ref{defn-scale-list}.
+\end{definition}
+
 \section{State Replication}\label{sect-state-replication}
 
 Polkadot nodes replicate each other's state by syncing the history of the
@@ -1139,33 +1179,6 @@ \subsubsection{Justified Block Header}
   authorities, which have voted for the block to be stored and is formally
   referred to as $A (B)$. An authority Id is 32bit.
 \end{itemize}
-
-\subsubsection{Block Inherent Data}
-
-Block inherent data represent the totality of extrinsics included in each
-block. In general, these data are collected or generated by Polkadot RE and
-handed to Runtime for inclusion in the block. Table \ref{tabl-inherent-data}
-lists these inherent data, their identifiers, and types.
-
-\begin{table}[h]
-  \begin{tabular}{lll}
-    \hline
-    Identifier & Type  & Description\\
-    \hline
-    timstap0 & u64 & Unix epoch time in number of seconds\\
-    babeslot & u64 & Babe Slot Number\tmrsup{\ref{defn-epoch-slot}}\\
-    \hline
-  \end{tabular}
-  \caption{\label{tabl-inherent-data}List of inherent data}
-\end{table}
-
-\begin{definition}
-  \label{defn-func-inherent-data}The function
-  {\tmname{Block-Inherents-Data($B_n$)}} return the inherent data defined in
-  Table \ref{tabl-inherent-data} corresponding to Block $B$ as a SCALE encoded
-  dictionary as defined in Definition \ref{defn-scale-list}.
-\end{definition}
-
 \subsubsection{Block Body}\label{sect-block-body}
 
 The Block Body consists of array extrinsics each encoded as a byte array. The
@@ -1463,9 +1476,10 @@ \subsection{Preliminaries}
   are indexed sequentially, and we refer to the $n^{\tmop{th}}$ epoch since
   genesis by $\mathcal{E}_n$. Each epoch is divided into equal length periods
   known as block production {\tmstrong{slots}}, sequentially indexed in each
-  epoch. The index of each slot is called {\tmstrong{slot number}}. Each slot
-  is awarded to a subset of block producers during which they are allowed to
-  generate a block.
+  epoch. The index of each slot is called {\tmstrong{slot number}}. The equal
+  length duration of each slots is called the {\tmstrong{slot duration}} and
+  indicated by $\mathcal{T}$. Each slot is awarded to a subset of block
+  producers during which they are allowed to generate a block.
 \end{definition}
 
 \begin{notation}
@@ -1606,6 +1620,9 @@ \subsection{Slot Number Calculation}
 
 \hrulefill{\medskip}
 
+$\mathcal{T}$ is the slot duration defined in Definition
+\ref{defn-epoch-slot}.
+
 \subsection{Block Production}
 
 At each epoch, each block producer should run Algorithm
@@ -1681,7 +1698,7 @@ \subsection{Block Production}
 
 {\state{{\tmname{Add-Digest-Item}}($B_s$,Seal,$S_B$)}}
 
-{\state{{\tmname{Broadcast-Block}}($B_s, H_{\tmop{BABE}} (B_s)$)}}}}
+{\state{{\tmname{Broadcast-Block}}($B_s$)}}}}
 
 \hrulefill{\medskip}
 
@@ -1692,9 +1709,10 @@ \subsection{Epoch Randomness}\label{sect-epoch-randomness}
 
 At the end of epoch $\mathcal{E}_n$, each block producer is able to compute
 the randomness seed it needs in order to participate in the block production
-lottery in epoch $\mathcal{E}_{n + 2}$. The computation of the seed is
-described in Algorithm \ref{algo-epoch-randomness} which uses the concept of
-epoch subchain described in Definition \ref{defn-epoch-subchain}.
+lottery in epoch $\mathcal{E}_{n + 2}$. For epoch 0 and 1, the randomness seed
+is provided in the genesis block. The computation of the seed is described in
+Algorithm \ref{algo-epoch-randomness} which uses the concept of epoch subchain
+described in Definition \ref{defn-epoch-subchain}.
 
 \custombinding{10}{\noindent}\begin{tabular}{l}
   \hline
@@ -1848,9 +1866,6 @@ \subsection{Blocks Building Process}\label{sect-block-building}
 
 {\algorithmic{{\state{$P_B \leftarrow_{}${\tmname{Head($C_{\tmop{Best}}$)}}}}
 
-{\state{$H_h (P_B) \leftarrow${\tmname{Call-Runtime-Entry}}$\left(
-\text{\tmverbatim{block\_hash\_from\_id}}, H_i (P_B) \right)$}}
-
 {\state{$\tmop{Head} (B) \leftarrow$($H_p \leftarrow H_h (P_B), H_i \leftarrow
 H_i (P_B) + 1, H_r \leftarrow \phi, H_e \leftarrow \phi, H_d \leftarrow
 \phi$)}}
@@ -1881,7 +1896,7 @@ \subsection{Blocks Building Process}\label{sect-block-building}
 {\state{{\tmname{Drop(Ready-Extrinsic-Queue,$E$)}}{\END}{\END}}}
 
 {\state{$\tmop{Head} (B) \leftarrow${\tmname{Call-Runtime-Entry}}$\left(
-\text{\tmverbatim{finalize\_block}}, E \right)${\END}}}}}
+\text{\tmverbatim{finalize\_block}}, B \right)${\END}}}}}
 
 \hrulefill{\medskip}
 
@@ -2295,6 +2310,41 @@ \section{Randomness}\label{sect-randomness}
 
 \section{VRF}\label{sect-vrf}
 
+\section{Cryptographic Keys}\label{sect-cryptographic-keys}
+
+Various type keys are used in Polkadot to prove the identity of the actor. In
+the following section we specify the detail of those keys and comment on their
+usage
+
+\begin{definition}
+  \label{defn-account-key}{\tmstrong{Account key $(\tmop{sk}^a,
+  \tmop{pk}^a)$}} is a key pair of type of either of schemes listed in Table
+  \ref{tabl-account-key-schemes}:
+  {\center{\begin{table}[h]
+    \begin{tabular}{ll}
+      \hline
+      Key scheme & Description\\
+      \hline
+      SR25519 & \\
+      ED25519 & \\
+      secp256k1 & Only for outgoing transfer transaction\\
+      \hline
+    \end{tabular}
+    \caption{\label{tabl-account-key-schemes}List of public key scheme which
+    can be used for an account key}
+  \end{table}}}
+  Account key can be used to sign transactions among other accounts and
+  blance-related functions.
+\end{definition}
+
+\begin{definition}
+  {\tmstrong{Controller key}} {\todo{TBS}}
+\end{definition}
+
+\begin{definition}
+  {\tmstrong{Session key}} {\todo{TBS}}
+\end{definition}
+
 \chapter{Auxiliary Encodings}\label{sect-encoding}
 
 \section{SCALE Codec}\label{sect-scale-codec}