jMyles
commented
3 years ago I think that this is a really, really good idea that will dramatically improve the network.
I lean toward favoring Scenario A. But I want to fully understand all of the implications of Scenario A compared with Scenario B above.
Here's a discussion on the topic: https://ptb.discordapp.com/channels/411401661714792449/411401661714792451/750697760906543205
To my eye, the only clearly established, concrete, tangible benefit we've uncovered for Scenario B is that the KFrag material will be smaller. That may be very important - bloated TreasureMaps are a threat.
But smaller KFrags come with a cost of Bob needing to perform computation, which concerns me. This precludes the possibility of a state-reduced Bob (ie, Bob being able to send a designee bot around to gather CFrags, even if his keys are in cold storage). It also may hamper performance if Bob is a small device.
Today's KFrags are compact enough to fit in a map without a problem in my estimation.
I also prefer the simplicity of Scenario A: no changes are required in pyUmbral, and Ursula's logic remain quite similar.
But whichever we choose, I think that this is a great motion for the network, and I am in favor of immediate movement on it.
vepkenez
cygnusv
KPrasch
Like herding KFrags
The custody of
KFragmaterial is one of the clunkiest aspects ofUrsulastate, 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, ifn - m +1Ursulas 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
mUrsulas that he can find. But in such a scenario, how are Ursulas compensated? Currently, all Ursulas in a given policy cohort are published inPolicyManagerand paid thusly.