# Node Ageing

## Benefits and drawbacks

### Benefits

1. Node ageing should effectively prevent Sybil attacks. Since a new node in a section will have a low age, targetting that section with further nodes won't give any advantages, as succeeding in adding new malicious nodes to a section will result in relocating nodes that we previously managed to put there. On the other hand, it is unfeasible to wait for all our nodes in a section to age - firstly because it will take a long time for high ages, and secondly because they will be redistributed across random sections during the ageing process.

### Drawbacks

1. Relocating nodes causes additional churn, and data relocation.
2. Loss of age (or safecoin) upon disconnection might encourage centralisation (centralised farming would provide better internet connections and more reliable power).

## Potential issues, proposals for extensions

### Zero-cost attacks

If it is profitable to run a node and the payment in Safecoin can be withdrawn at any time, running a large share of the network is effectively free, and an attacker could earn and sell Safecoin at a profit and then, once they have lots of nodes with sufficient age, perform the attack.

It might make sense to reduce the age or even require a complete restart whenever Safecoin are withdrawn, so that it is guaranteed that an old node still has a large stake in the network, and is actually risking its own investment by attacking.

TBD: Is it feasible to even merge the notions of the age of the node and the amount of Safecoin farmed by that node?
Or would proof-of-stake even make more sense, instead of node ageing? If it is about the stakes in the network anyway, you could e.g. be required to pay a collateral before joining. You would need to commit that and whether you joined the network or not you would only get it back after e.g. a month. If you join, you are relocated only once. After the month, you are removed from the network, receive your collateral and the earned Safecoin, and can start again.

### Double votes and 50% quorum

If contradictory votes can cause harm, as is the case with the [current mechanism in data manager](https://gist.github.com/michaelsproul/aac77a71f737633d603461932bd915fc) as well as the consensus mechanism proposed in [Data Chains, Part 1](https://forum.safedev.org/t/data-chains-part-1/597/31), then the intersection of two quora can already exploit that: If both sets `Q` and `R` of nodes are quora, then if `Q ∩ R` votes for _both_ contradictory messages/blocks `a` and `b`, and the correct nodes of `Q \ R` vote for `a`, and the correct nodes of `R \ Q` vote for `b`, then both accumulate.

So the choice of the quorum definition must take into account that, given an attacker controlling a subset `A` of a group or section `S`:
* If `A` is a quorum, the attacker can choose any decision.
* If `S \ A` is not a quorum, the attacker can prevent any decision.
* If there are quora `Q` and `R` such that `Q ∩ R` is a subset of `A`, the attacker can potentially cause conflicting decisions to be both accepted.

That means that the definition needs to be chosen such that it is unfeasible to control either a quorum, or the complement of a quorum or the intersection of two quora.

With ">50% node count _and_ >50% weight" there is still a chance that such an intersection contains only a single node. E.g. if there are nodes 1 to 9, with weights 1 to 9, then the sum of the weights is 45, then {1, 2, 4, 7, 9} and {1, 3, 5, 6, 8} are both quora, and intersect only in {1} (so the attacker doesn't even need to control an old node).

There are alternative consensus algorithms, however, in which double-voting cannot cause harm, e.g. [Practical Synchronous Byzantine Consensus](https://arxiv.org/pdf/1704.02397.pdf), although those make synchronicity assumptions about the network. With that kind of algorithm, the only requirement is that there cannot be two disjoint quora. That would be satisfied by the proposed 50% value.

### Using node ages as weights in voting

While the idea itself seems to be good, we need to take care not to allow an attacker to gain a quorum in a section by just letting a small number of nodes sit around ageing. This means that any notion of a quorum using ages as weights will need to independently take into account the plain number of nodes that are voting (as already suggested in the RFC).

However, placing thresholds on *both* age and node count does increase the likelihood of stalling. If *either* of the age total or node total for a vote is insufficient, it will fail. This is an instance of the classic safety vs. liveness tradeoff. One option might be to require >1/2 or >2/3 of nodes, and a *smaller* proportion of age.

On the other hand there is an argument for using 2^A instead of the node age A itself as the weight, since that is what is proportional to the performed work: Getting a node to age 10 is 50 times more work than getting 10 nodes to age 1.

### Joining and relocation message flow

The RFC text isn't fully up-to-date with the current resource proof implementation. But extending that to take relocation into account shouldn't be difficult: Essentially, relocation should work in exactly the same way as joining, except that no proxy is needed (the old section takes its place) and the node age is increased.

The old section `S` would send an `ExpectCloseNode(age, old_pub_key)` message to the new section `T`, which would respond with a `RelocateResponse`. The node would then disconnect, generate a name in the required range, restart and in its `CandidateIdentify` include a signature of its new name with its old key.

### Measuring a node

The RFC suggests that neighbouring groups can evaluate a node's performance. However, messages are always forwarded to only one member of the neighbouring group, which can prove that it received the message, but not that it didn't receive the message.

This should still even out, however: If the neighbouring nodes each measure their subjective perception of the node's performance, the median of that value should then be hard to manipulate.

### Influencing the block hash with a new node's name

A joining node can now freely choose its name from a given interval, and can thereby influence the link block's hash, which is used as a source of randomness to determine who is relocated to which other section.

It would be safer to include more randomness to determine who relocates from where to where. By getting all the nodes in the section to sign something like the joining node's ID or the latest block hash, and taking the XOR of all the signatures we should be able to generate a better random value that can't be predicted by the attacker.

In general, deriving randomness from the *structure* of the network is insufficient protection from an attacker with good knowledge of the network as they may have a node in every section.

### Other minor suggested changes

* Possibly the age should not be part of the name itself but of the link blocks, since it is only meaningful in the context of the whole section or group.
* Halving the age after failing to relocate seems harsh; since the age only grows logarithmically, it might be fairer to just subtract 1, which already halves the corresponding proof of work.

## Conclusions

* Node ageing is compatible with the Data Chains Part 1 proposal.
* Depending on the exact consensus algorithm used, the quorum definition should be:
* **Sync BFT**: Majority of nodes AND majority of age.
* **Async BFT (PBFT)**: 2/3 supermajority of nodes AND 2/3 supermajority of age.