Like herding KFrags

The custody of KFrag material is one of the clunkiest aspects of Ursula state, and is the source of some brittleness for NuCypher. The diligence of wallet management (or, thought of in slightly wider-scoped terms, keystore management) is insufficient to ensure robustness of Policy cohorts. For example, if n - m +1 Ursulas lose their KFrags, it will be of no comfort to Bob that their keystore state is intact.

Instead, we can craft a mechanism wherein Bob can provide, during his journey, all of the cryptographic material required for a given Ursula (for whom this material has been made by Alice specifically to match a trinket-secret pair of Ursula's) to craft and supply his sought-after CFrag. In this scenario, this material is included by Alice in the TreasureMap for Bob to use this way.

This is a solution that we've come to call TreasureMap con KFrags.

Our choices at present

Cryptographically, there are at least two ways to achieve this:

Scenario A: A full KFrag, tantamount to the material currently custodied in Ursula's datastore, is added to each Arrangement in the TreasureMap. The material is encrypted for Ursula.

Scenario B: A more primordial object, an "evaluation index", is stored in the Arrangement. In order for PRE service to be applied, a multi-party computation is required which involves a secret held by Bob. The resulting ethereal state is useful only for the requested operation; subsequent operations require subsequent MPCs.

The state of due diligence

We need to be careful about how we describe this change, especially as node operators pour into our fora seeking clarity on their culpability in the event of downtime or data loss. In particular, I think that describing this solution as "stateless", as it is described in the draft paper, is a mistake. "Stateless" is a already a widely-used (and sometimes well-defined) term that describes a different property. I'm not opposed to turns-of-phrase of course, especially since the meaning of "state" is substantially different for a protocol on a decentralized node fleet as compared with a single node, but even in a decentralized sense, this solution isn't stateless. In fact, the expression of state from the perspective of Alice and Enrico is exactly the same: the available states are null, granted, revoked, expired, etc. Bob too has essentially the same experience, especially in Scenario A - his states in relation to this change are, "I have the map" or "I don't have the map" - the matter of whether it is con KFrag or sing KFrag is immaterial to his state-tracking. And Ursula doesn't experience statelessness as in a network live LivePeer. This part is where the potential danger lies: describing this solution as "stateless" may lead people to believe that even a lapse in keystore diligence is recoverable. A truly stateless Ursula wouldn't be part of a stated policy cohort at all; she'd be able to spin up from whole cloth, with the codebase alone, generate a new keyring, and provide identical service.

Moreover, there is still state directly in the Ursula process that is non-trivial: the matter of whether or not the node has committed to the next period, which nodes, verifications, and fleet states are known, and Treasure Map storage (which, after all, is custody of material which is cryptologically analogous to the KFrag which she stores now).

So Ursula isn't stateless in this situation, but she is state-reduced in such a way that the types of diligence which are due change. So I introduce the phrases "keystore diligence" and "datastore diligence".

The former requires only that the custodian keep track of a secret seed which can be used to generate the entire keystore. The latter requires that material observed during the runtime be stored.

With this change, Ursula's fiduciary responsibility shifts from requiring both keystore diligence and datastore diligence to merely requiring keystore diligence. However, as a civic matter, datastore diligence is still very important for Ursula for several reasons - examples include storing node validity status (and thus refraining from pestering nodes with unnecessary additional verification requests), and, more importantly, storing incidental payloads such as TreasureMaps (see #2222 this stub of a paper which I have begun). Since Ursula's datastore diligence is now only a collective point of failure, we hope that her abstract vested interest in the success of the network is sufficient motivation to do these things.

Both the entire network and individual nodes are still stateful before and after this change.

Unsolved mysteries

• One of the potentially alluring things about this scheme is that Alice can select Ursulas for the Policy without those Ursulas even knowing that they're part of the cohort. She might choose to select a very large number of them, so that Bob can essentially seek service from any group of m Ursulas that he can find. But in such a scenario, how are Ursulas compensated? Currently, all Ursulas in a given policy cohort are published in PolicyManager and paid thusly.