deploy: 1a33470

internals.html

@@ -170,17 +170,17 @@ <h2 id="5-alephbft-internals"><a class="header" href="#5-alephbft-internals">5 A
 <ol>
 <li>The unit is created by one of the node's <code>Creator</code> component -- implemented in <code>creation/</code>. Creator sends the produced unit to <code>runway/</code>, which then sends it to <code>member.rs</code>.</li>
 <li>A recurring task of broadcasting this unit is put in the task queue. The unit will be broadcast to all other nodes a few times (with some delays in between).</li>
-<li>The unit is received by another node -- happens in <code>member.rs</code> and immediately send to <code>runway/</code> where it passes some validation (signature checks etc.). If all these checks pass and the unit is not detected to be a fork, then it is placed in the <code>UnitStore</code> -- the <code>store</code> field of the <code>Runway</code> struct.</li>
-<li>The idea is that this store keeps only <strong>legit units</strong> in the sense defined in <a href="how_alephbft_does_it.html#25-alerts----dealing-with-fork-spam">the section on alerts</a>. Thus no fork is ever be put there unless coming from an alert.</li>
-<li>At a suitable moment the units from the store are further moved to a component responsible for reconstructing the explicit parents for these units -- implemented in <code>reconstruction/parents.rs</code>.</li>
-<li>Each unit whose parents are successfully decoded, is added to the &quot;Dag&quot;. Each unit in the Dag is legit + has all its parents in the Dag. This is ensured by the implementation in <code>reconstruction/dag.rs</code>.</li>
-<li>Dag units are passed to a component called the <code>Extender</code> -- see the files in <code>extension/</code>. The role of the extender is to efficiently run the <code>OrderData</code> algorithm, described in the <a href="how_alephbft_does_it.html">section on AlephBFT</a>.</li>
-<li>Once a unit's data is placed in one of batches by the <code>Extender</code> then its path is over and can be safely discarded.</li>
+<li>The unit is received by another node -- happens in <code>member.rs</code> and immediately send to <code>runway/</code> for further processing in <code>validation.rs</code>.</li>
+<li>Validation checks signatures and basic unit properties, plus catches forks. This means that only <strong>legit units</strong>, in the sense defined in <a href="how_alephbft_does_it.html#25-alerts----dealing-with-fork-spam">the section on alerts</a>, are sent further. Thus no fork is ever passed on unless coming from an alert.</li>
+<li>The units are further moved to a component responsible for reconstructing the explicit parents for these units -- implemented in <code>reconstruction/parents.rs</code>.</li>
+<li>Each unit whose parents are successfully decoded, is passed on to <code>reconstruction/dag.rs</code>, which ensures that units are passed on only when their parents already were. They are then put in a store in <code>runway/</code>. Each unit in the store is legit + has all its parents in the store.</li>
+<li>Such units are passed to a component called the <code>Extender</code> -- see the files in <code>extension/</code>. The role of the extender is to efficiently run the <code>OrderData</code> algorithm, described in the <a href="how_alephbft_does_it.html">section on AlephBFT</a>.</li>
+<li>Once a unit's data is placed in one of batches by the <code>Extender</code> then its path is over, although we keep it in the runway store to be able to send it to other nodes on request.</li>
 </ol>
 <h3 id="51-creator"><a class="header" href="#51-creator">5.1 Creator</a></h3>
 <p>The creator produces units according to the AlephBFT protocol rules. It will wait until the prespecified delay has passed and attempt to create a unit using a maximal number of parents. If it is not possible yet, it will wait till the first moment enough parents are available. After creating the last unit, the creator stops producing new ones, although this is never expected to happen during correct execution.</p>
-<h3 id="52-unit-store-in-runway"><a class="header" href="#52-unit-store-in-runway">5.2 Unit Store in Runway</a></h3>
-<p>As mentioned, the idea is that this stores only legit units and passes them to the reconstructing component. In case a fork is detected by a node <code>i</code>, all <code>i</code>'s units are attached to the appropriate alert.</p>
+<h3 id="52-validation"><a class="header" href="#52-validation">5.2 Validation</a></h3>
+<p>The validation process consists of checking basic properties of units (correct number of parents, correct session etc.), the signatures, and whether the unit is a fork based on the units that the node either already has or at least started processing. As mentioned, the idea is that only legit units are passed to the reconstructing component. In case a fork by a node <code>i</code> is detected, all of <code>i</code>'s units are attached to the appropriate alert, so that other nodes can accept them as legit.</p>
 <h3 id="53-reconstruction"><a class="header" href="#53-reconstruction">5.3 Reconstruction</a></h3>
 <p>The next step is to reconstruct the structure of the Dag from the somewhat compressed information in the units.</p>
 <h4 id="531-parents"><a class="header" href="#531-parents">5.3.1 Parents</a></h4>
@@ -192,7 +192,7 @@ <h4 id="531-parents"><a class="header" href="#531-parents">5.3.1 Parents</a></h4
 </ol>
 <p>In any case the reconstruction triggers a request to <code>Member</code> to download the full list of the unit's parent hashes, so that the ambiguity is resolved. Once a response is received by <code>Member</code> then it is passed back to the reconstruction so that it can &quot;decode&quot; the parents and proceed.</p>
 <h4 id="532-dag"><a class="header" href="#532-dag">5.3.2 Dag</a></h4>
-<p>The units parents might, for many reasons, not be reconstructed in an order agreeing with the Dag order, i.e. some of their ancestors might not yet be reconstructed. The Dag component ensures that units are only added to the Dag after their parents were already added, and thus any units emitted by this component are in an order agreeing with the Dag order.</p>
+<p>The units parents might, for many reasons, not be reconstructed in an order agreeing with the Dag order, i.e. some of their ancestors might not yet be reconstructed. The Dag component ensures that units are only added to the store after their parents were already added, and thus any units emitted by this component are in an order agreeing with the Dag order.</p>
 <h3 id="54-extender"><a class="header" href="#54-extender">5.4 Extender</a></h3>
 <p>The <code>Extender</code>'s role is to receive Dag units (in an order agreeing with the Dag order) and extend the output stream. Towards this end it elects the <code>Head</code> for each <code>round</code>. Such an election works by going through candidate units from this round either eliminating them or eventually electing one. Votes are computed and cached for each candidate until a decision on it is made, after which the election moves on to the next round (if elected as <code>Head</code>) or to the next unit (otherwise). After electing every <code>Head</code> the <code>Extender</code> deterministically orders all its unordered ancestors and the <code>Head</code> itself and returns the resulting batch.</p>
 

print.html

@@ -528,17 +528,17 @@ <h3 id="34-alephbft-sessions"><a class="header" href="#34-alephbft-sessions">3.4
 <ol>
 <li>The unit is created by one of the node's <code>Creator</code> component -- implemented in <code>creation/</code>. Creator sends the produced unit to <code>runway/</code>, which then sends it to <code>member.rs</code>.</li>
 <li>A recurring task of broadcasting this unit is put in the task queue. The unit will be broadcast to all other nodes a few times (with some delays in between).</li>
-<li>The unit is received by another node -- happens in <code>member.rs</code> and immediately send to <code>runway/</code> where it passes some validation (signature checks etc.). If all these checks pass and the unit is not detected to be a fork, then it is placed in the <code>UnitStore</code> -- the <code>store</code> field of the <code>Runway</code> struct.</li>
-<li>The idea is that this store keeps only <strong>legit units</strong> in the sense defined in <a href="how_alephbft_does_it.html#25-alerts----dealing-with-fork-spam">the section on alerts</a>. Thus no fork is ever be put there unless coming from an alert.</li>
-<li>At a suitable moment the units from the store are further moved to a component responsible for reconstructing the explicit parents for these units -- implemented in <code>reconstruction/parents.rs</code>.</li>
-<li>Each unit whose parents are successfully decoded, is added to the &quot;Dag&quot;. Each unit in the Dag is legit + has all its parents in the Dag. This is ensured by the implementation in <code>reconstruction/dag.rs</code>.</li>
-<li>Dag units are passed to a component called the <code>Extender</code> -- see the files in <code>extension/</code>. The role of the extender is to efficiently run the <code>OrderData</code> algorithm, described in the <a href="how_alephbft_does_it.html">section on AlephBFT</a>.</li>
-<li>Once a unit's data is placed in one of batches by the <code>Extender</code> then its path is over and can be safely discarded.</li>
+<li>The unit is received by another node -- happens in <code>member.rs</code> and immediately send to <code>runway/</code> for further processing in <code>validation.rs</code>.</li>
+<li>Validation checks signatures and basic unit properties, plus catches forks. This means that only <strong>legit units</strong>, in the sense defined in <a href="how_alephbft_does_it.html#25-alerts----dealing-with-fork-spam">the section on alerts</a>, are sent further. Thus no fork is ever passed on unless coming from an alert.</li>
+<li>The units are further moved to a component responsible for reconstructing the explicit parents for these units -- implemented in <code>reconstruction/parents.rs</code>.</li>
+<li>Each unit whose parents are successfully decoded, is passed on to <code>reconstruction/dag.rs</code>, which ensures that units are passed on only when their parents already were. They are then put in a store in <code>runway/</code>. Each unit in the store is legit + has all its parents in the store.</li>
+<li>Such units are passed to a component called the <code>Extender</code> -- see the files in <code>extension/</code>. The role of the extender is to efficiently run the <code>OrderData</code> algorithm, described in the <a href="how_alephbft_does_it.html">section on AlephBFT</a>.</li>
+<li>Once a unit's data is placed in one of batches by the <code>Extender</code> then its path is over, although we keep it in the runway store to be able to send it to other nodes on request.</li>
 </ol>
 <h3 id="51-creator"><a class="header" href="#51-creator">5.1 Creator</a></h3>
 <p>The creator produces units according to the AlephBFT protocol rules. It will wait until the prespecified delay has passed and attempt to create a unit using a maximal number of parents. If it is not possible yet, it will wait till the first moment enough parents are available. After creating the last unit, the creator stops producing new ones, although this is never expected to happen during correct execution.</p>
-<h3 id="52-unit-store-in-runway"><a class="header" href="#52-unit-store-in-runway">5.2 Unit Store in Runway</a></h3>
-<p>As mentioned, the idea is that this stores only legit units and passes them to the reconstructing component. In case a fork is detected by a node <code>i</code>, all <code>i</code>'s units are attached to the appropriate alert.</p>
+<h3 id="52-validation"><a class="header" href="#52-validation">5.2 Validation</a></h3>
+<p>The validation process consists of checking basic properties of units (correct number of parents, correct session etc.), the signatures, and whether the unit is a fork based on the units that the node either already has or at least started processing. As mentioned, the idea is that only legit units are passed to the reconstructing component. In case a fork by a node <code>i</code> is detected, all of <code>i</code>'s units are attached to the appropriate alert, so that other nodes can accept them as legit.</p>
 <h3 id="53-reconstruction"><a class="header" href="#53-reconstruction">5.3 Reconstruction</a></h3>
 <p>The next step is to reconstruct the structure of the Dag from the somewhat compressed information in the units.</p>
 <h4 id="531-parents"><a class="header" href="#531-parents">5.3.1 Parents</a></h4>
@@ -550,7 +550,7 @@ <h4 id="531-parents"><a class="header" href="#531-parents">5.3.1 Parents</a></h4
 </ol>
 <p>In any case the reconstruction triggers a request to <code>Member</code> to download the full list of the unit's parent hashes, so that the ambiguity is resolved. Once a response is received by <code>Member</code> then it is passed back to the reconstruction so that it can &quot;decode&quot; the parents and proceed.</p>
 <h4 id="532-dag"><a class="header" href="#532-dag">5.3.2 Dag</a></h4>
-<p>The units parents might, for many reasons, not be reconstructed in an order agreeing with the Dag order, i.e. some of their ancestors might not yet be reconstructed. The Dag component ensures that units are only added to the Dag after their parents were already added, and thus any units emitted by this component are in an order agreeing with the Dag order.</p>
+<p>The units parents might, for many reasons, not be reconstructed in an order agreeing with the Dag order, i.e. some of their ancestors might not yet be reconstructed. The Dag component ensures that units are only added to the store after their parents were already added, and thus any units emitted by this component are in an order agreeing with the Dag order.</p>
 <h3 id="54-extender"><a class="header" href="#54-extender">5.4 Extender</a></h3>
 <p>The <code>Extender</code>'s role is to receive Dag units (in an order agreeing with the Dag order) and extend the output stream. Towards this end it elects the <code>Head</code> for each <code>round</code>. Such an election works by going through candidate units from this round either eliminating them or eventually electing one. Votes are computed and cached for each candidate until a decision on it is made, after which the election moves on to the next round (if elected as <code>Head</code>) or to the next unit (otherwise). After electing every <code>Head</code> the <code>Extender</code> deterministically orders all its unordered ancestors and the <code>Head</code> itself and returns the resulting batch.</p>
 <div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h2 id="6-reliable-broadcast"><a class="header" href="#6-reliable-broadcast">6 Reliable Broadcast</a></h2>