cygnusv
commented
1 year ago Notes from @jMyles:
Justin Myles Holmes — Today at 3:42 PM I hear @dnunez point out that the scope directly in front of us with regard to cohort refresh is dynamic DKG participation, and that we are well-advised to avoid pitfalls that arise from broader approaches that fall outside that scope, such as handling very large corrupting events. @arj points out that our current "stateless" cohort approach is plausibly still viable for legacy use cases.
(Though I want to say, I think that it is confusing to call DKG participants "Ursula") @dnunez points out that, for cohort refresh that relies on creation of new "shares" through participation of the cohort (I'd call this style of refresh "covenant refresh"), the political design needs to be such that the portion which we rely upon for honesty (eg, the majority) must remain available for the refresh to even be possible.
(Perhaps to put it another way: a failing subset becomes a problem not only for service delivery, but because at a certain size it also makes refresh unavailable) I want to point out: participants bearing the original DKG ritual (what is popularly called "the ceremony") can presumably create additional valid frags if they come back online.
We may of course want to make this difficult or impossible, or we may want to make it easy, or we may want to make this a tuneable parameter. @arj points out that the ease of orchestrating unlawful collusion turns on several factors outside cohort size, such as verifiable randomness in sampling. "What prompts cohort refresh?" asks @arj.
Among the discussion he sees arising from this:
Of course the core impetus is unbinding.
But is there also a reason to carve forward-compatibility with refresh by fiat of the original "summoner"? ( annnnd @dnunez runs headlong into one of the two reasons that I think "shares" is an undesirable word for fragment material ) @dnunez points out that liveness challenge, and related slashing, is, replete with air quotes, "very easy" as a means for Alice to take the temperature of a cohort.
I'll point out that a malicious node may choose to respond properly to a challenge, but still pretend to be offline at service time. @dnunez also introduces the idea that challenge failure on-chain can itself prompt the transaction that requests cohort refresh. 💥 @arj has goosebumps, chills down his spine, and a call to run for the door His qualm: the prospect of an exodus appears to threaten the stability mechanism of cohort refresh, perhaps reminiscent of the FUD re: the Shanghai 32 eth staking protocol. @Caruso asks about the impact of "staker-by-staker" as a way of counting heads for the purpose of refresh. @arj points out that such a scheme might encourage Sybil'ing. @arj asks us to come to the point of this whole thing:
After all, is availability even a near-term concern with respect to rollout? We don't necessarily need to solve that to push this thing out the door. @dnunez responds by pointing out the terminal nature of cohort deterioration. @arj points out that there are two discrete types of cohort deterioration, and that we need to be cautious about conflating them: one is from ordinary unbinding, pursuant to the protocol, while the other is the more chaotic and bizarre unlawful disappearance. @arj asserts that the former is way easier than the latter.
(I'm not sure I agree.) @dnunez also asks what's so different.
@arj points out that there are differences insofar as slashing or another disincentive is needed to reduce incidence of the latter, and that this introduces complexity.
@dnunez points out that, slashing aside, the cryptological machinery needed to replace a member of a cohort appears to be identical.
@arj agrees, and clarifies that his thrust is to point out that the detection and incentive structure of unlawful disappearance (let's say "truancy"?) is a bigger problem that doesn't need to be solved in very near-term.
@dnunez agrees. (I know I'm oversimplifying on account of velocity) @derek points out that the specific Sybil attack in which one party successfully selects itself to replace its node is much less likely in an environment of robust random sampling.
@arj agrees, and goes further to point out that random beacon utilization in sampling has other benefits, known and unknown. @derek wonders about the relationship between cohort size and cost for refresh.
He carefully tip-toes into the notion that unbinders need to cover the cost of cohort refresh arising from their departure. @dnunez points out that the cost for cohort members who remain in the covenant (people whom @arj pointed out earlier are at risk of being punished for good behavior) is dependent on the exact transactions required by the protocol, and that it might be possible to have an in-band refund for such members. (long-form discussion about longevity incentives for individual nodes)
piotr — Today at 4:28 PM Some of the PSS / DPSS schemes (Ferveo, CHURP, DyCAPS) assume BFT security model and I think that simplifies the reasoning about their properties
Justin Myles Holmes — Today at 4:32 PM @dnunez wonders about action items stemming from this discussion.
@arj: what burdens does state maintenance introduce?
@dnunez: At a minimum, it means changing from mere custody of a secret to actually baking up the results of a runtime on a regular basis, etc. Justin Myles Holmes — Today at 4:39 PM @arj muses about whether various tunable parameters with respect to cohort refresh granularity can create sufficiently onerous incentives to make collusion sufficiently difficult to disincentivize it, without needing to add additional cryptographic safeguards. What @arj suggests is a sort of cryptological (but not cryptographic) variant of forward secrecy
arjunhassard
Discussion/Update Nov 30th
Dynamic Committees
Maximizing collusion friction
Availability
Cost of cohort refresh
Long-term commitment to network & overall node population
Statefulness baggage
Collusion orchestration friction
@jMyles thanks for your live-noting, I've included lots of your sentences here ^