deploy: 34d26ff1aa

print.html

@@ -1901,7 +1901,7 @@ return queue.pop
 <p>Implementations can implement certain &quot;capabilities&quot;, such as serving old block headers or being a parachain bootnode.</p>
 <p>The discovery mechanism of RFC #8 is extended to be able to discover nodes of specific capabilities.</p>
 <h2 id="motivation-4"><a class="header" href="#motivation-4">Motivation</a></h2>
-<p>The Polkadot peer-to-peer network is made of nodes. Not all these nodes are equal. Some nodes store only the headers of recently blocks, some nodes store all the block headers and bodies since the genesis, some nodes store the storage of all blocks since the genesis, and so on.</p>
+<p>The Polkadot peer-to-peer network is made of nodes. Not all these nodes are equal. Some nodes store only the headers of recent blocks, some nodes store all the block headers and bodies since the genesis, some nodes store the storage of all blocks since the genesis, and so on.</p>
 <p>It is currently not possible to know ahead of time (without connecting to it and asking) which nodes have which data available, and it is not easily possible to build a list of nodes that have a specific piece of data available.</p>
 <p>If you want to download for example the header of block 500, you have to connect to a randomly-chosen node, ask it for block 500, and if it says that it doesn't have the block, disconnect and try another randomly-chosen node.
 In certain situations such as downloading the storage of old blocks, nodes that have the information are relatively rare, and finding through trial and error a node that has the data can take a long time.</p>
@@ -1920,11 +1920,12 @@ People interested in accessing the archive of the chain.</p>
 <li><strong>Archive provider</strong>. This capability is a superset of <strong>History provider</strong>. In addition to the requirements of <strong>History provider</strong>, an implementation with this capability must be able to serve call proofs and storage proof requests of any block since the genesis up until and including their currently finalized block.</li>
 <li><strong>Parachain bootnode</strong> (only for relay chains). An implementation with this capability must be able to serve the network request described in RFC 8.</li>
 </ul>
+<p>More capabilities might be added in the future.</p>
 <p>In the context of the <em>head of chain provider</em>, the word &quot;recent&quot; means: any not-finalized-yet block that is equal to or an ancestor of a block that it has announced through a block announce, and any finalized block whose height is superior to its current finalized block minus <strong>16</strong>.
 This does <em>not</em> include blocks that have been pruned because they're not a descendant of its current finalized block. In other words, blocks that aren't a descendant of the current finalized block can be thrown away.
-A gap of blocks is required due to race conditions: when a node finalizes a block, it takes some time for its peers to be made aware of this, during which they might send requests concerning older blocks. The exact gap is arbitrary.</p>
+A gap of blocks is required due to race conditions: when a node finalizes a block, it takes some time for its peers to be made aware of this, during which they might send requests concerning older blocks. The choice of the number of blocks in this gap is arbitrary.</p>
 <p>Substrate is currently by default a <strong>head of chain provider</strong> provider. After it has finished warp syncing, it downloads the list of old blocks, after which it becomes a <strong>history provider</strong>.
-If Substrate is instead configured as an archive node, then it downloads the state of all blocks since the genesis, after which it becomes an <strong>archive provider</strong>, <strong>history provider</strong>, and <strong>head of chain provider</strong>.
+If Substrate is instead configured as an archive node, then it downloads all blocks since the genesis and builds their state, after which it becomes an <strong>archive provider</strong>, <strong>history provider</strong>, and <strong>head of chain provider</strong>.
 If blocks pruning is enabled and the chain is a relay chain, then Substrate unfortunately doesn't implement any of these capabilities, not even <strong>head of chain provider</strong>. This is considered as a bug that should be fixed, see <a href="https://github.com/paritytech/polkadot-sdk/issues/2733">https://github.com/paritytech/polkadot-sdk/issues/2733</a>.</p>
 <h3 id="dht-provider-registration"><a class="header" href="#dht-provider-registration">DHT provider registration</a></h3>
 <p>This RFC heavily relies on the functionalities of the Kademlia DHT already in use by Polkadot. You can find a link to the specification <a href="https://github.com/libp2p/specs/tree/master/kad-dht">here</a>.</p>

proposed/0059-nodes-capabilities-discovery.html

@@ -217,7 +217,7 @@
 <p>Implementations can implement certain &quot;capabilities&quot;, such as serving old block headers or being a parachain bootnode.</p>
 <p>The discovery mechanism of RFC #8 is extended to be able to discover nodes of specific capabilities.</p>
 <h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
-<p>The Polkadot peer-to-peer network is made of nodes. Not all these nodes are equal. Some nodes store only the headers of recently blocks, some nodes store all the block headers and bodies since the genesis, some nodes store the storage of all blocks since the genesis, and so on.</p>
+<p>The Polkadot peer-to-peer network is made of nodes. Not all these nodes are equal. Some nodes store only the headers of recent blocks, some nodes store all the block headers and bodies since the genesis, some nodes store the storage of all blocks since the genesis, and so on.</p>
 <p>It is currently not possible to know ahead of time (without connecting to it and asking) which nodes have which data available, and it is not easily possible to build a list of nodes that have a specific piece of data available.</p>
 <p>If you want to download for example the header of block 500, you have to connect to a randomly-chosen node, ask it for block 500, and if it says that it doesn't have the block, disconnect and try another randomly-chosen node.
 In certain situations such as downloading the storage of old blocks, nodes that have the information are relatively rare, and finding through trial and error a node that has the data can take a long time.</p>
@@ -236,11 +236,12 @@ People interested in accessing the archive of the chain.</p>
 <li><strong>Archive provider</strong>. This capability is a superset of <strong>History provider</strong>. In addition to the requirements of <strong>History provider</strong>, an implementation with this capability must be able to serve call proofs and storage proof requests of any block since the genesis up until and including their currently finalized block.</li>
 <li><strong>Parachain bootnode</strong> (only for relay chains). An implementation with this capability must be able to serve the network request described in RFC 8.</li>
 </ul>
+<p>More capabilities might be added in the future.</p>
 <p>In the context of the <em>head of chain provider</em>, the word &quot;recent&quot; means: any not-finalized-yet block that is equal to or an ancestor of a block that it has announced through a block announce, and any finalized block whose height is superior to its current finalized block minus <strong>16</strong>.
 This does <em>not</em> include blocks that have been pruned because they're not a descendant of its current finalized block. In other words, blocks that aren't a descendant of the current finalized block can be thrown away.
-A gap of blocks is required due to race conditions: when a node finalizes a block, it takes some time for its peers to be made aware of this, during which they might send requests concerning older blocks. The exact gap is arbitrary.</p>
+A gap of blocks is required due to race conditions: when a node finalizes a block, it takes some time for its peers to be made aware of this, during which they might send requests concerning older blocks. The choice of the number of blocks in this gap is arbitrary.</p>
 <p>Substrate is currently by default a <strong>head of chain provider</strong> provider. After it has finished warp syncing, it downloads the list of old blocks, after which it becomes a <strong>history provider</strong>.
-If Substrate is instead configured as an archive node, then it downloads the state of all blocks since the genesis, after which it becomes an <strong>archive provider</strong>, <strong>history provider</strong>, and <strong>head of chain provider</strong>.
+If Substrate is instead configured as an archive node, then it downloads all blocks since the genesis and builds their state, after which it becomes an <strong>archive provider</strong>, <strong>history provider</strong>, and <strong>head of chain provider</strong>.
 If blocks pruning is enabled and the chain is a relay chain, then Substrate unfortunately doesn't implement any of these capabilities, not even <strong>head of chain provider</strong>. This is considered as a bug that should be fixed, see <a href="https://github.com/paritytech/polkadot-sdk/issues/2733">https://github.com/paritytech/polkadot-sdk/issues/2733</a>.</p>
 <h3 id="dht-provider-registration"><a class="header" href="#dht-provider-registration">DHT provider registration</a></h3>
 <p>This RFC heavily relies on the functionalities of the Kademlia DHT already in use by Polkadot. You can find a link to the specification <a href="https://github.com/libp2p/specs/tree/master/kad-dht">here</a>.</p>