The first Keyper Selection Process was successfully concluded, with ten protoDAO members voting on the 13 proposals we received.
Before the vote, we communicated that a majority would be required for a proposal to be approved into the Keyper set.
With three proposals receiving precisely a 50% approval rating, we would now like to ask the protoDAO members for their opinion on whether this is a successful selection for these proposals. They do not explicitly fulfill the requirement of a majority or at least 51% approval, but it would be good to discuss this topic among the members. This would only be applicable to this first vote and would not have to necessarily also act as a precedent for future votes.
So if you are a protoDAO member, especially if you voted not to approve the proposals of Julian, Shaoyang, and Luehrs.eth, we would like to hear what you think about this.
Actually, at this momnet which is really early stage (security and other stuff are not settled) I think ppl/insituation who have rich experience of node operation are more expected. That’s why I didnot vote for them.
From a technical perspective, what would be the difference between having 10 keypers or 13 keypers? And also what would be the consequence of potential down time for a keyper? My personal thinking was that more is better early on, but I might be wrong.
Imho people who got 50% of the votes should get in the set, I think that’s what commoners (non-math wizzes) understood inititally.
More generally, I think the protoDAO should give more people a chance to run nodes and then potentially kick keypers quickly from the set if they underperform in their duties (e.g. low uptime).
All things being equal, having more keypers only improves security: If the threshold is 2/3, then up to 1/3 can be offline and the system is still ok. That is, with 10 keypers 3 can be offline, with 13 it’s 4. Of course, if the additional keypers are less reliable, this could cancel out the effect or even make it worse (think if the additional keypers would be consistently offline, they would already fill 3 of the 4 offline “spots” all the time).
If the concern is potentially lower reliability of “solo keypers”, then a good compromise could be to accept them but also reduce the threshold from 67% to 60%. This would mean 5 out of 13 could be offline. The downside is that it makes collusion easier: “Only” 8 instead of 9 out of 13 have to collude to compute decryption keys early. But at this early stage I’m not very concerned about this.
Personally, I voted positively on all proposals on the assumption that all potential keypers considered in the first vote were following the project in its very early stages.
I’ve been in the team’s shoes with other networks (trying to balance institutional validator sets with individuals) and I think it’s generally a good idea to try and spread out the group where possible.
It’s easy enough to remove them from the active set if they are acting maliciously or not meeting their uptime obligations.
I’d expect anyone selected to participate should be able to point at a historical record of very high uptime. Validator uptime stats and performance are easily verifiable. This could be a straightforward requirement as it also speaks to a certain level of competence.
Aside from uptime and malicious behavior, are there any other risks to smaller entities participating? I ask because I would certainly be a “solo keyper”, but based on my history I have no concerns about uptime or benevolence. That said, while I passionately hope to contribute, I would prioritize the health of the project above my own participation if necessary.
I would second that we should be as much inclusive as possible of anyone’s participation. Be it institutional or sole. And having a certain kind of geographical diversity in term of where node operators are based are also good.
My concern/ lack of knowledge is also how much risk could a note pose to the network and what kind of fail-safe Shutter have, should one node malfunction.
Did not vote for all proposals also due to some of them are quite simple, therefore we don’t have much information about them.
After thinking about it for some time, I think that the applicants receiving 50% should be included too. The argument @jannik makes is good and having more keypers gives us a bit higher margin for error. @tatu@luis will there be a vote to decide on this or should we try to reach a consensus here?
Based on the discussion here, we feel that the overall sentiment is in favor of also including the three Keypers in the first set that received a 50% approval rating in the vote.
Thus, we will take the steps to include these proposals in the set. And to allow a proper governance process to take place, should any Shutter protoDAO member wish to initiate a vote on this topic, we implore you to do so.
Summary
We will go forward including all 13 proposals that were included in the first Keyper Selection Process for the first Keyper set.
In case any of the Shutter protoDAO members strongly disagrees and wishes to initiate a governance process and a vote for the three proposals that received a 50% approval rating in the vote, should create a new vote/proposal at the protoDAO Snapshot space by Friday, the 8th of September 11 AM CEST.
Thank you for considering 50% votes in the first set.
I completely understand the concerns raised. The Shutter Keyper needs a reliably running Keyper set in order to function well as pointed out by jannik.
In order to introduce my experience a bit more, I have run web3 infrastructure for several years, especially Brainbot related projects like the Raiden Network, Trustlines and Beamer Bridge. Besides that, throughout the years I have run different automated software, like liquidation bots to help secure protocols like Maker and Reflexer, additionally I’m experienced in running nodes for staking for a couple of years.
Thank you for giving me the chance to help bootstrapping the Keyper Network for Shutter, a project which I believe has a very important purpose in the Ethereum ecosystem. I’ convinced to be a reliable partner for the project.