# Decoupling Swap from Settlement

## Problem Statement
In the current implementation of Swap, bandwidth allocation and monetary settlement of outstanding Swap balance are unnecessarily tightly coupled:
* Nodes can only connect to the network with a deployed chequebook contract
* Once a node runs out of funds and reaches its threshold in the p2p accounting can no longer use the connection without replenishing its chequebook (otherwise it will be disconnected).

As interactions with the Ethereum blockchain have become very expensive, there is no realistic expectation to earn enough funds through Swap for it to be worth settling on the blockchain, resulting in all settlements with cheques to be essentially worthless. This means that running a Swarm node will never be profitable and it exposes node to a vulnerability emmanating from the fact that received cheques are worthless for honest nodes, but outgoing cheques are valuable.

~~situation where either the disconnect thresholds should be raised to levels rendering them entirely meaningless or to disbalanced p2p connections becoming permanently unusable (or even disconnected) due to outstanding balance.
Furthermore, the using the chequebook contract as a means of micropayment exposes nodes to fraud to the amount of their outstanding cheques that cannot be economically cashed.~~

Thus:
* Joining the network requires a non-trivial investment of funds
* without any realistic perspective of earning it back
* while being vulnerable to losing the funds.
~~* Disbalanced network use renders p2p connections permanently unusable.~~

## Solution Proposal
* Allow nodes without chequebooks to join the network.
* Consuming nodes getting close to the disconnect threshold should stop requesting before they get disconnected. To make the experience smoother, the node may throttle back requests gradually, but it is not necessary.
* Outstanding Swap balances should be gradually "forgiven", i.e. there should be a time-based automatic settling irrespective of traffic or payment.

## Rationale
The above changes will allow for and incentivize reasonable behavior even without any monetary settlement, which can be added later when the details of dealing with high transaction costs and mismatched outstanding balances will be worked out.

Without any monetary settlement, light nodes that only consume bandwidth will see their balances run up to the disconnect thresholds of their peers after which the bandwidth they can use (due to the time-based reduction of outstanding balances) slows to a trickle. Full nodes have a higher allowance per time since the income they earn from serving can be directly used to request chunks themselves.

~~Thus, they are incentivized to either consume at a very low rate or to distribute their load between many peers. *Note: for this to work, the number of peers sharing the same IP address should be limited.*~~
For a node to be able to consume at a higher rate, it must serve requests by other nodes, i.e. be a fully synced storer node, with the appropriate Kademlia connections to other such nodes.

## Considerations
### 1. Incentivizes many connections
Since the time-based allowance is defined per peer connection, a node can increase it overall bandwidth allocation per time by increasing the number of connections. Currently, this incentive does not exist.
This may cause in problem in the sense that all nodes that are in the network have already filled the total number of nodes to whom they want to be connected, a node who is new in the network and wants to start using Swarm and build up a Kademlia topology might not find connections, as everybody is already at full capacity. Differentiating between new nodes and nodes that say that they are new is not trivial.

### 2. Incentivizes running many nodes
As in 1, having more connections allows you to have more bandwidth allowance per time. Getting more connections is also possible by simply running more nodes and combine the bandwidth allowance of these nodes.
Unlike 1, the amount of bandwidth allowance that can be achieved with this strategy is unbounded, leaving Swarm vulnerable for a DDOS attack.

### 3. Pull sync vulnerability
Bringing online a Swarm node will be now without a cost. Pull syncing is costly from the nodes that are already in the network (it requires a lot of bandwidth and computation to help another node become a full node). Previously, the burden to deploy a chequebook was also a grace, in the sense that we could reasonably expect that full nodes with a chequebook were comitted to stay in the Swarm network and it was costly to trigger a lot of pull syncing by bringing online many nodes.
The solution space is similar as 2.

### 4. Forwarder nodes
Nodes that pretend to be full storer nodes but do not actually store everything in their neighborhood, just forward requests may be marginally profitable, but they do not actually create any value for the network; it is just additional latency and a point of failure.