Each peer connection is multiplexed into channels. Each channel can optionally have an associated filter which determines whether the peer already knows of the message. The system is designed to be easily extensible for various applications.
Each peer connection is multiplexed into channels.
<hr/>
### Default channel
@ -12,10 +12,6 @@ The default channel is used to communicate state changes, pings, peer exchange,
<td><b>Channel</b></td>
<td>""</td>
</tr>
<tr>
<td><b>Filter</b></td>
<td>None<br/>Messages in this channel is not filtered.</td>
</tr>
<tr>
<td><b>Messages</b></td>
<td>
@ -38,13 +34,6 @@ The block channel is used to propagate block or header information to new peers
<td><b>Channel</b></td>
<td>"block"</td>
</tr>
<tr>
<td><b>Filter</b></td>
<td>
Custom<br/>
Nodes should only advertise having a header or block at height 'h' if it also has all the headers or blocks less than 'h'. Thus this filter need only keep track of two integers -- one for the most recent header height 'h_h' and one for the most recent block height 'h_b', where 'h_b' <= 'h_h'.
</td>
</tr>
<tr>
<td><b>Messages</b></td>
<td>
@ -55,6 +44,12 @@ The block channel is used to propagate block or header information to new peers
</ul>
</td>
</tr>
<tr>
<td><b>Notes</b></td>
<td>
Nodes should only advertise having a header or block at height 'h' if it also has all the headers or blocks less than 'h'. Thus for each peer we need only keep track of two integers -- one for the most recent header height 'h_h' and one for the most recent block height 'h_b', where 'h_b' <= 'h_h'.
</td>
</tr>
</table>
<hr/>
@ -67,14 +62,6 @@ The mempool channel is used for broadcasting new transactions that haven't yet e
<td><b>Channel</b></td>
<td>"mempool"</td>
</tr>
<tr>
<td><b>Filter</b></td>
<td>
Bloom filter (n:10k, p:0.02 -> k:6, m:10KB)<br/>
Each peer's filter has a random nonce that scrambles the message hashes<br/>
The filter & nonce refreshes every new block<br/>
</td>
</tr>
<tr>
<td><b>Messages</b></td>
<td>
@ -83,6 +70,15 @@ The mempool channel is used for broadcasting new transactions that haven't yet e
</ul>
</td>
</tr>
<tr>
<td><b>Notes</b></td>
<td>
Instead of keeping a perfect inventory of what peers have, we use a lossy filter.<br/>
Bloom filter (n:10k, p:0.02 -> k:6, m:10KB)<br/>
Each peer's filter has a random nonce that scrambles the message hashes.<br/>
The filter & nonce refreshes every new block.<br/>
</td>
</tr>
</table>
<hr/>
@ -95,14 +91,6 @@ The consensus channel broadcasts all information used in the rounds of the Tende
<td><b>Channel</b></td>
<td>"consensus"</td>
</tr>
<tr>
<td><b>Filter</b></td>
<td>
Bitarray filter<br/>
Each validator has a predetermined index in teh bitarray<br/>
Refreshes every new consensus round
</td>
</tr>
<tr>
<td><b>Messages</b></td>
<td>
@ -113,4 +101,10 @@ The consensus channel broadcasts all information used in the rounds of the Tende
</ul>
</td>
</tr>
<tr>
<td><b>Notes</b></td>
<td>
How do optimize/balance propagation speed & bandwidth utilization?
jaekwon
11 years ago