# Gossip Protocol Notes ## Desired Properties * nodes can broadcast transactions that will be reliably gossiped to the miners. * nodes can tune their contribution level to match the computing resources they have available. ## Radius Approach A: Define `radius` as the positive integer distance between the `node_id` and the `transaction.hash`. ```python node_id_as_int = int.from_bytes(node_id, 'big') txn_hash_as_int = int.from_bytes(transaction_hash, 'big') distance = abs(node_id_as_int - txn_hash_as_int) ``` B: Let nodes on the network specify their radius to each other. This is a value that can change over the course of a connection. C: Nodes are only expected to relay transactions that fall within their radius. D: Nodes prioritize their peer pool connections such that their connected peers fully *cover* the portion of the transaction keyspace that the node's radius covers. ### Control Flow Nodes can use `radius` as a control flow knob. Reducing their radius reduces how many transactions flow towards them. Increasing the radius increases how many transactions flow towards them. ### Peer Selection Nodes prioritize their peer pool connections as follows: 1. Ensure that the section of the transaction keyspace that the node is interested in is fully covered. 2. Ensure that any remaining part of the keyspace is covered. 3. Find peers that add redundancy to the coverage of the part of the keyspace the node's radius covers. Additionally, nodes prioritize peer connections with radius values similar to their own. The "emergent" topology of this network should be such that: 1. The majority of peers are within the keyspace covered by the node's `radius` 2. Connected peers are more likely to have a similar `radius` ### Problem: DOS mitigation Nodes with a radius that does not cover the full network have an incomplete view of the transaction pool. Multiple conflicting transactions from the same sender with the same `nonce` but different hashes will land in random different parts of the network. The result is that nodes with a small enough radius not have visibility into the other conflicting transactions. Once these transactions hit nodes with a large enough radius they will be filtered down with the extra ones evicted. This allows an attacker to flood the edges of the network where the lightest weight nodes live with more transaction volume than they would be able to introduce normally. Assuming the lightest nodes have an average radius of 5% of the keyspace, we could expect as many as 20x transactions to be passing around at the edge of the network. Intuition suggests that the effect of this attack would be predominantly felt by the light nodes, and should be reduced as traversal brings transactions into nodes with larger radius values. ### Problem: evicting invalid transactions Suppose the network has two transactions `A` and `B` which are both from the same sender and have the same `nonce`. Once `A` has been included, `B` should be dropped from the network. A stateless node who's radius only exposes them to `B` will not be able to detect that `B` is no longer valid as they do not have the state. Solution 1: Nodes can drop transactions who's proofs are too old. Small radius nodes shouldn't need to persist the transactions for a long time as their role is more as relays to ensure other light nodes can get their transactions into the core of the network. Solution 2: Nodes in the middle could send updated proofs for a transaction back along the wire when an invalid transaction is encountered. This might be a DOS vector against full nodes since proof production comes at a cost, but invalid transactions are effectively free. This also requires some strong-ish guarantee that these proofs will make their way back out to the edge of the network which would require some form of re-broadcasting... and probably introduces new DOS vectors since disceminating the proof might be another amplification attack vector.