deploy: 4d0a344326

print.html

@@ -1444,7 +1444,7 @@ the pallet design as it stands, this is very unlikely.</li>
 <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>
 <p>In a nutshell, on a specific node the current authority-discovery protocol publishes Kademila DHT records at startup and periodically. The records contain the full address of the node for each authorithy key it owns. The node tries also to find the full address of all authorities in the network by querying the DHT and picking up the first record it finds for each of the authority id it found on chain.</p>
-<p>The authority discovery DHT records use the protobuf protocol and the current format is specified <a href="https://github.com/paritytech/polkadot-sdk/blob/313fe0f9a277f27a4228634f0fb15a1c3fa21271/substrate/client/authority-discovery/src/worker/schema/dht-v2.proto#L4">here</a>. This RFC proposese extending the schema in a backwards compatible manner by adding a new optional <code>creation_time</code> field to <code>SignedAuthorityRecord</code> which nodes can use to determine which of the record is newer.</p>
+<p>The authority discovery DHT records use the protobuf protocol and the current format is specified <a href="https://github.com/paritytech/polkadot-sdk/blob/313fe0f9a277f27a4228634f0fb15a1c3fa21271/substrate/client/authority-discovery/src/worker/schema/dht-v2.proto#L4">here</a>. This RFC proposese extending the schema in a backwards compatible manner by adding a new optional <code>creation_time</code> field to <code>AuthorityRecord</code> and nodes can use this information to determine which of the record is newer.</p>
 <p>Diff of <code>dht-v3.proto</code> vs <code>dht-v2.proto</code></p>
 <pre><code>@@ -1,10 +1,10 @@
  syntax = &quot;proto3&quot;;
@@ -1452,34 +1452,31 @@ You can find a link to the specification <a href="https://github.com/libp2p/spec
 -package authority_discovery_v2;
 +package authority_discovery_v3;
 
-@@ -13,11 +13,21 @@
+ // First we need to serialize the addresses in order to be able to sign them.
+ message AuthorityRecord {
+ 	repeated bytes addresses = 1;
++	// Time since UNIX_EPOCH in nanoseconds, scale encoded
++	TimestampInfo creation_time = 2;
+ }
+
+ message PeerSignature {
+@@ -13,11 +15,17 @@
  	bytes public_key = 2;
  }
 
 +// Information regarding the creation data of the record
 +message TimestampInfo {
-+	// Time since UNIX_EPOCH in nanoseconds, scale encoded
++       // Time since UNIX_EPOCH in nanoseconds, scale encoded
-+	bytes timestamp = 1;
++       bytes timestamp = 1;
-+	// A signature of the creation time.
-+	bytes signature = 2;
 +}
 +
- // Then we need to serialize the authority record and signature to send them over the wire.
- message SignedAuthorityRecord {
- 	bytes record = 1;
- 	bytes auth_signature = 2;
- 	// Even if there are multiple `record.addresses`, all of them have the same peer id.
- 	PeerSignature peer_signature = 3;
-+	// Information regarding the creation data of this record.
-+	TimestampInfo creation_time = 4;
- }
 </code></pre>
 <p>Each time a node wants to resolve an authorithy ID it will issue a query with a certain redundancy factor, and from all the results it receives it will decide to pick only the newest record. Additionally, the nodes that answer with old records will be updated with the newer record.</p>
 <h2 id="drawbacks-2"><a class="header" href="#drawbacks-2">Drawbacks</a></h2>
 <p>In theory the new protocol creates a bit more traffic on the DHT network, because it waits for DHT records to be received from more than one node, while in the current implementation we just take the first record that we receive and cancel all in-flight requests to other peers. However, because the redundancy factor will be relatively small and this operation happens rarerly, every 10min, this cost is negligible.</p>
 <h2 id="testing-security-and-privacy-1"><a class="header" href="#testing-security-and-privacy-1">Testing, Security, and Privacy</a></h2>
 <p>This RFC's implementation https://github.com/paritytech/polkadot-sdk/pull/3786 had been tested on various local test networks and versi.</p>
-<p>With regard to security the creation time will be signed with the authority id key, so there is no way for other malicious nodes to manipulate this field without the received node observing.</p>
+<p>With regard to security the creation time is wrapped inside SignedAuthorityRecord wo it will be signed with the authority id key, so there is no way for other malicious nodes to manipulate this field without the received node observing.</p>
 <h2 id="performance-ergonomics-and-compatibility-1"><a class="header" href="#performance-ergonomics-and-compatibility-1">Performance, Ergonomics, and Compatibility</a></h2>
 <p>Irrelevant.</p>
 <h3 id="performance"><a class="header" href="#performance">Performance</a></h3>

proposed/0091-dht-record-creation-time.html

@@ -218,7 +218,7 @@
 <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>
 <p>In a nutshell, on a specific node the current authority-discovery protocol publishes Kademila DHT records at startup and periodically. The records contain the full address of the node for each authorithy key it owns. The node tries also to find the full address of all authorities in the network by querying the DHT and picking up the first record it finds for each of the authority id it found on chain.</p>
-<p>The authority discovery DHT records use the protobuf protocol and the current format is specified <a href="https://github.com/paritytech/polkadot-sdk/blob/313fe0f9a277f27a4228634f0fb15a1c3fa21271/substrate/client/authority-discovery/src/worker/schema/dht-v2.proto#L4">here</a>. This RFC proposese extending the schema in a backwards compatible manner by adding a new optional <code>creation_time</code> field to <code>SignedAuthorityRecord</code> which nodes can use to determine which of the record is newer.</p>
+<p>The authority discovery DHT records use the protobuf protocol and the current format is specified <a href="https://github.com/paritytech/polkadot-sdk/blob/313fe0f9a277f27a4228634f0fb15a1c3fa21271/substrate/client/authority-discovery/src/worker/schema/dht-v2.proto#L4">here</a>. This RFC proposese extending the schema in a backwards compatible manner by adding a new optional <code>creation_time</code> field to <code>AuthorityRecord</code> and nodes can use this information to determine which of the record is newer.</p>
 <p>Diff of <code>dht-v3.proto</code> vs <code>dht-v2.proto</code></p>
 <pre><code>@@ -1,10 +1,10 @@
  syntax = &quot;proto3&quot;;
@@ -226,34 +226,31 @@ You can find a link to the specification <a href="https://github.com/libp2p/spec
 -package authority_discovery_v2;
 +package authority_discovery_v3;
 
-@@ -13,11 +13,21 @@
+ // First we need to serialize the addresses in order to be able to sign them.
+ message AuthorityRecord {
+ 	repeated bytes addresses = 1;
++	// Time since UNIX_EPOCH in nanoseconds, scale encoded
++	TimestampInfo creation_time = 2;
+ }
+
+ message PeerSignature {
+@@ -13,11 +15,17 @@
  	bytes public_key = 2;
  }
 
 +// Information regarding the creation data of the record
 +message TimestampInfo {
-+	// Time since UNIX_EPOCH in nanoseconds, scale encoded
++       // Time since UNIX_EPOCH in nanoseconds, scale encoded
-+	bytes timestamp = 1;
++       bytes timestamp = 1;
-+	// A signature of the creation time.
-+	bytes signature = 2;
 +}
 +
- // Then we need to serialize the authority record and signature to send them over the wire.
- message SignedAuthorityRecord {
- 	bytes record = 1;
- 	bytes auth_signature = 2;
- 	// Even if there are multiple `record.addresses`, all of them have the same peer id.
- 	PeerSignature peer_signature = 3;
-+	// Information regarding the creation data of this record.
-+	TimestampInfo creation_time = 4;
- }
 </code></pre>
 <p>Each time a node wants to resolve an authorithy ID it will issue a query with a certain redundancy factor, and from all the results it receives it will decide to pick only the newest record. Additionally, the nodes that answer with old records will be updated with the newer record.</p>
 <h2 id="drawbacks"><a class="header" href="#drawbacks">Drawbacks</a></h2>
 <p>In theory the new protocol creates a bit more traffic on the DHT network, because it waits for DHT records to be received from more than one node, while in the current implementation we just take the first record that we receive and cancel all in-flight requests to other peers. However, because the redundancy factor will be relatively small and this operation happens rarerly, every 10min, this cost is negligible.</p>
 <h2 id="testing-security-and-privacy"><a class="header" href="#testing-security-and-privacy">Testing, Security, and Privacy</a></h2>
 <p>This RFC's implementation https://github.com/paritytech/polkadot-sdk/pull/3786 had been tested on various local test networks and versi.</p>
-<p>With regard to security the creation time will be signed with the authority id key, so there is no way for other malicious nodes to manipulate this field without the received node observing.</p>
+<p>With regard to security the creation time is wrapped inside SignedAuthorityRecord wo it will be signed with the authority id key, so there is no way for other malicious nodes to manipulate this field without the received node observing.</p>
 <h2 id="performance-ergonomics-and-compatibility"><a class="header" href="#performance-ergonomics-and-compatibility">Performance, Ergonomics, and Compatibility</a></h2>
 <p>Irrelevant.</p>
 <h3 id="performance"><a class="header" href="#performance">Performance</a></h3>