Confirm activity: problem definition, threat model, analysis of potential solutions

[GhadaAlmashaqbeh]

The goal of this issue cover the following:

• Agree on the formulation/description of the confirm activity problem; define the problem and what should a solution achieve.
• Outline a threat model for this problem (i.e., what we consider a plausible threat/attack in practice to defend against).
• Discuss the potential of existing ideas (namely, A skeleton-logic proposal for another economic model of grant (probabilistic micropayments) #15 and Ratcheting Re-Encryption State Channel) as well as PCD, CoSi-based, chellenge/open-based (see here) , and under what assumptions they solve/do not solve the problem.

[cygnusv]

IMO, the most important goals of the NuCypher network wrt to this problem are:

1. Honest participants should obtain service from the network. This means:
   • Alices should be able to grant a policy, and nodes that are not responsive for granting should be penalized
   • Bobs should be able to retrieve re-encrypted capsules
2. Lazy Ursulas must not receive subsidies
3. Lazy Ursulas must not receive service fees

Note the order of these problems. Also, if you ask me, the "difference in importance" between them is an order of magnitude: in other words, I mostly care about Goal 1, something about Goal 2, and not really much about Goal 3.

One could ask, how different are goals 2 and 3 from goal 1? Well, let's say, that I don't care much that:

• A lazy Ursula is getting rewards as long as it's not disrupting Alice's experience when sampling nodes for policies
• A lazy Ursula that is part of some policy is getting rewards as long as it's not used by Bob
  In other words, I could live with a lazy Ursula that is risky enough to be offline without being sampled for policies, and/or not being asked for service by a Bob, AND NOT BEING CAUGHT.

With respect to goals 2 and 3, during the next months, the most pressing problem regarding rewards (either subsidies or service fees) is guaranteeing that lazy Ursulas don't get staking rewards, IMO. There's not going to be enough use for service fees being economically relevant. In addition, the service fees problem is something that will be solved naturally when subsidies are no longer representative: it won't be economically rational to be lazy.

[GhadaAlmashaqbeh]

Based on that (and the team discussion we had) these are the main conclusions:

• Regarding problem definition: what we care about now is availability of Ursulas. So it is more like confirm that Ursula serves Bob once it receives a request. I would call it confirm availability rather than confirm service activity.

• Regarding the threat model: we do not consider (at least for now) collusion between Bob and Ursula a practical threat. Meaning that cases when Bob may pretend that it got service from Ursula (while it does not get anything) is not an issue (we do not suspect this will be of any importance and there is no motivation to do it given that the work Ursula does for re-encryption is minimal).

• Regarding the solutions we have: all of them are for confirm service activity not availability. Micropayments and the ratcheting one may work for confirm service activity assuming that collusion of Bob and Ursula is not a threat. The rest (PCD/CoSi/challenge-open) do not assume that, they work regardless of the collusion/trust assumptions about the parties, which fits better open access and trustless work environments. So we will keep them for now and revisit at a later stage of the network.

[GhadaAlmashaqbeh]

I do not think I agree with the sentence "In addition, the service fees problem is something that will be solved naturally when subsidies are no longer representative: it won't be economically rational to be lazy.".

Since there is a financial motivation, cases like collusion between Bob and Ursula (the one mentioned above, which is accounting attacks, Bob pretend to be served and Ursula collect payments for free) could be of a practical importance. So I suspect it will be solved naturally without deploying additional countermeasures.

Again, it is early for this issue, we need to collect data from the system and track the participants' behavior once the subsidies disappear to assess the situation.

[cygnusv]

Since there is a financial motivation, cases like collusion between Bob and Ursula (the one mentioned above, which is accounting attacks, Bob pretend to be served and Ursula collect payments for free) could be of a practical importance. So I suspect it will be solved naturally without deploying additional countermeasures.

This greatly depends on the payment model: either per-policy or per-request.
If Ursulas are paid per-policy, i.e., for the duration of the policy regardless the number of requests, then there's no incentive for them on trying to increase Bob's traffic or to collude with Bobs: they're going to be paid anyway. In this scenario, the only concern is ensuring that honest Bobs obtain service.

On the other hand, in a per-request payment model, then Ursulas have incentives to somehow increase the traffic. For example, they can ask Bob to retrieve many times, and split the fees; in this case, the traffic is completely legitimate and there's nothing we could about that. BTW, the problem of ensuring that honest Bob get service persists.

One aspect that we haven't brought to this discussion yet is who pays: so far we've assume that in all cases it's Alice. That makes sense in a per-policy payment model (i.e., the current one). However, in a per-request model perhaps we should just make Bob, the requester, pay; in that case, collusions disappear naturally. If you think about it, a scenario where some party A pays, and some parties B and C decide how and when to spend that money is screaming for misuse.

Having said that, I think that, for traction purposes, a model where Alice pays is preferably, as it has the less friction for users, overall.

[GhadaAlmashaqbeh]

Yup! for this I said it is still early to make decisions now. The full model is not clear, who pays/when/etc. So it could be solved naturally or it may need additional mechanisms to enforce honest behavior.

Also, I would not be surprised if we end up with a mixed or hybrid model where for some policies Alice pays while for others Bob pays, for high traffic polices it will be pay per request while for low traffic ones pay based on duration, and other interesting use patterns. But still, we need more data about the usage of the network/etc. to give a more educated opinion.

[arjunhassard]

@cygnusv The order of the goals you laid out makes sense. One of the premises of all this work is that the incentive/disincentive of (3), plus the possibility of a link to (2), can be harnessed to take us closer to achieving (1). Indeed, a sub-premise of this is that Bobs, relative to Alices, are in a better position to police Ursulas given that their interactions are far more frequent. Both these premises may prove to be faulty starting points.

As for subsidies, while I completely agree that they cause or exacerbate lazy Ursula-related issues (see second and third bullet points in #13), I agree with @GhadaAlmashaqbeh that the availability problem will not melt away post-subsidies, for these additional reasons:

Firstly, given that currently fee income is contingent only on the number and duration of policies held (and periodic checking in), there is a weak but real economic rationale for accepting policies but ignoring access requests, since being online 24/7 constitutes the majority of some Ursula's costs. The critical downside of this cost-saving strategy is not being selected for fresh sharing policies, which may be unpredictable. We should investigate sharpening this stick with extremely time-sensitive selection and response.

Secondly, free market forces are not a panacea, particularly early on when the market is thin and fragile. Unless we edit our model, the post-subidy era will arrive off the back of the subsidy era, with all its flaws – imagine, for example, a scenario in which the most economically inefficient/unsustainable operations now control the most stake. Moreover, the nature of the product itself is unfavourable to an unregulated free market solution – customers tend not to be tolerant of failure when it comes to access control / key management (i.e. it's not a 'no-win, no-fee' kind of service), it is non-trivial for Ursulas to differentiate themselves based on a provable track record, and the 'random team' nature of the service means that reliable Uruslas can be grouped with and let down by unreliable counterparts.

As a side note; even if the absence of subsidies fixed this, network users would have to wait an awfully long time. The new minting schedule aims to avoid a low-revenue era by maximising the overlap between meaningful subsidies and meaningful fees, as long as this unfolds within the first 6-7 years. The previous model would also see us waiting 4-6 years for a free market, but likely with greater market distortion by this point (see previous paragraph).