Looking at the details a bit further, it seems to me that elders do more work than clients, which is the opposite of what we want.
A quick summary of the basic process weāre looking at
- Number of elders is 5.
- Majority is 3.
- The client needs 3 signatures from 5 elders to make a payment.
- The client does 2 requests to their connected section elders (see Reliable Message Delivery (RMD), using at least 1/3 of the elders, ie 2 elders).
- This is routed to the destination with RMD.
- The destination elders all verify and sign the payment if valid (ie all 5 elders).
- The individual elder signatures are routed back to the client.
- The client combines 3 of the 5 responses.
- The client sends the combined proof as the final payment.
We can look at the workload on two fronts - the bandwidth and the computation.
Looking at bandwidth, due to RMD it seems that client and nodes each require an equal amount of bandwidth both on sending and receiving. Iām not sure whether or not we should say the network does more work than the client here, since each individual node does an equal amount of bandwidth work, but overall the network as a whole does a lot more work than the client. This is a bit of a semantic argument but weāll need to be clear about it if we want to communicate the security model properly. Also worth noting that routing needs 2 nodes per hop but signing needs 5 nodes so thereās another imbalance there favoring the client.
Looking at computation, a quick test script shows the elders do more work than the client. The test has elders creating their individual signatures and the client combining 3 of the 5. The elders each took ~2.5ms to generate a signature and the client took ~0.9ms to combine 3 of the 5. So creating signatures takes much more work than combining signatures, which is a little counter-intuitive. Itās true that combining many signatures takes longer than creating them (in my test combining 6 or more signatures takes longer than creating a single signature), but simply increasing the number of signature shares is not a good way to approach the security model.
Verification of signatures has the same characteristics as bandwidth, since all nodes do the same amount of verification. Maybe thereās even room to drop some verification steps, eg if the client tries to combine signatures without verifying each signature beforehand, the combine operation will fail anyway, acting as the verification for the client. The necessity (or not) of the signature verification step is actually pretty interesting to look at, but is getting off topic.
Iām trying to make a broader point here that if thereās a ratio of 1:5 client:elders we canāt assume it means the client does 5x the work of the elders. We need to measure the actual work done by each. And we should also consider whether we want to be measuring the client:node work ratio or the client:network ratio.
My feeling is we might end up including some spam reduction mechanism for the client like hashcash, except signature-based rather than hash-based. If the client is going to route via X nodes and Y destination elders, impacting a total of (X+Y) nodes, the client should provide a signature showing they did more work than the X+Y nodes end up doing (similar to how hashcash does). Maybe the client:network work ratio is actually not the security parameter we need to focus on, maybe itās something else like current load? I wonāt go too far into details here, but it looks to me like the current spam prevention is not going to work as intended.
Maybe Iāve got some details of the process wrong, but Iām confident the combine signatures process is much faster than the create signature process, which we probably need to account for in our analysis of the node vs client workload.
