deploy: 4795e10

internals.html

@@ -168,18 +168,17 @@ <h1 class="menu-title">AlephBFT</h1>
                         <h2 id="5-alephbft-internals"><a class="header" href="#5-alephbft-internals">5 AlephBFT Internals</a></h2>
 <p>To explain the inner workings of AlephBFT it is instructive to follow the path of a unit: from the very start when it is created to the moment when its round is decided and it's data is placed in one of the output batches. Here we give a brief overview and subsequently go more into details of specific components in dedicated subsections.</p>
 <ol>
-<li>The unit is created by one of the node's <code>Creator</code> component -- implemented in <code>src/creation/</code>. Creator sends a notification to an outer component.</li>
-<li>The newly created unit is filled with data, session information and a signature. This is done in <code>src/runway.rs</code> which then sends it to <code>src/member.rs</code> Subsequently 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>src/member.rs</code> and immediately send to <code>src/runway.rs</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 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>src/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>src/reconstruction/dag.rs</code>.</li>
-<li>Dag units are passed to a component called the <code>Extender</code> -- see the files in <code>src/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>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>
 </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>
-<p>Since the creator does not have access to the <code>DataIO</code> object and to the <code>Keychain</code> it is not able to create the unit &quot;fully&quot;, for this reason it only chooses parents, the rest is filled by the <code>Runway</code>.</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="53-reconstruction"><a class="header" href="#53-reconstruction">5.3 Reconstruction</a></h3>

print.html

@@ -526,18 +526,17 @@ <h3 id="34-alephbft-sessions"><a class="header" href="#34-alephbft-sessions">3.4
 <div id="chapter_begin" style="break-before: page; page-break-before: always;"></div><h2 id="5-alephbft-internals"><a class="header" href="#5-alephbft-internals">5 AlephBFT Internals</a></h2>
 <p>To explain the inner workings of AlephBFT it is instructive to follow the path of a unit: from the very start when it is created to the moment when its round is decided and it's data is placed in one of the output batches. Here we give a brief overview and subsequently go more into details of specific components in dedicated subsections.</p>
 <ol>
-<li>The unit is created by one of the node's <code>Creator</code> component -- implemented in <code>src/creation/</code>. Creator sends a notification to an outer component.</li>
-<li>The newly created unit is filled with data, session information and a signature. This is done in <code>src/runway.rs</code> which then sends it to <code>src/member.rs</code> Subsequently 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>src/member.rs</code> and immediately send to <code>src/runway.rs</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 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>src/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>src/reconstruction/dag.rs</code>.</li>
-<li>Dag units are passed to a component called the <code>Extender</code> -- see the files in <code>src/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>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>
 </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>
-<p>Since the creator does not have access to the <code>DataIO</code> object and to the <code>Keychain</code> it is not able to create the unit &quot;fully&quot;, for this reason it only chooses parents, the rest is filled by the <code>Runway</code>.</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="53-reconstruction"><a class="header" href="#53-reconstruction">5.3 Reconstruction</a></h3>