Should SafeDAO use Shielded Voting on Snapshot?
More info about Shielded Voting by Shutter Network below.
Shutter brings shielded voting to Snapshot
Should SafeDAO use Shielded Voting on Snapshot?
More info about Shielded Voting by Shutter Network below.
Shutter brings shielded voting to Snapshot
good question, I’ll have to look more into shutter!
at face value it looks neat and useful
Shielded voting seems like a promising idea.
I’m in favor of using a shielded voting scheme.
I found Snapshot’s write-up helpful to understand what this looks like for the voter.
gM @0xSafeUser, thank you for bringing this up i do belive that there should be privacy for voting on snapshots.
Based on my experience from the 1inch DAO snapshot and 1ip 10 the Shutter implementation isn’t worth a try now there were several Bugs during the voting, which haven’t counted our total delegated voting power. So I would wait for implementing changes to a critical infra of the DAO
The question of whether we would want to build SafeDAO’s governance on the Shutter implementation is a good point that has also been raised by Guardians before: The network of nodes that is used to decrypt voter choices is currently not really decentralized, but mostly run by Shutter itself. This poses the question whether this adds a risk of centralisation, single point of failure, attack vectors or other risks. It also brings up the question of when we would consider the Shutter solution to be ‘sufficiently decentralised’.
Another aspect to consider which was also brought up before by Guardians is that shielded voting would prevent us from (easily) seeing whether a proposal has met quorum yet. Especially in the early days of SafeDAO (and when a proposal is less controversial than SEP-2), we may struggle to reach quorum at times and may risk missing quorum by not seeing it before the end of the proposal and not activating others to vote. On the other hand, you could argue that others will be more likely to vote if nobody can be sure whether quorum has been met, so that voter participation may in fact be higher than if the quorum was visible. Technically, it would be possible to calculate whether quorum has been met, but that is currently not natively supported in Shutter’s/Snapshot’s UI.
@0xBaer already mentioned this helpful blog post by Snapshot. This post by Shutter is also quite informative.
Given all that, what’s everybody’s take on the risks and opportunities, pros and cons?
Personally, I still need to weigh the pros and cons. But, I do think the concept appears rather smart and would be beneficial to SAFE governance.
Thank you for outlining tradeoffs @theobtl!
Given this seems to be a nice-to-have feature and the multiple important questions posed above I’d be in favor of holding off until more research is done on the centralization of the Shutter ecosystem.
Would love to chime in here, I’m Nathan and I’m the ecosystem lead at Snapshot.
I’d like to bring some clarity on a valid point brought forward about quorum. Currently, the issue with quorum comes from the fact that the best we can do is give an estimation of the current state of quorum, not the actual number. The reason why is that we can’t know for sure that all the votes are valid before the end of the proposal, so some votes might actually not be counted. We could imagine bringing it back, but with a warning, if you think that’s necessary for adoption.
Luis here from Shutter. So cool to see this being brought up organically, we’d love to see SafeDAO use shielded voting!
I think the concerns around some of features not being fully fleshed out are valid, but will be addressed very shortly (the issue that 1inch faced was resolved by Snapshot a couple of weeks ago, I think the quorum can be brought back easily)
On the keyper decentralization: While the goal for the keyper set ultimately is to be selected and maintained by a DAO, we want to approach this in a practical, progressively decentralised way. This is why we’re currently building a list of interested keypers, basically a small set of trusted individuals or institutions which will form the initial set.
We’d love to work with SafeDAO on this in 2 ways: 1) it would be awesome to get a feel from your community on how many keypers would be considered decentralised enough for now and 2) maybe there are interested community members from Safe that would like to run keypers (obviously not too many, as that would ultimately then create a conflict of interest)
Keep in mind, because we’re using threshold encryption, we only have to trust that a subset (a configurable threshold) of those keypers needs to be honest.
Oh, wow. Interesting! I wasn’t aware of that. Thank you for the details kind ser
Ouuuuu, can’t wait
I dig what shutter is doing
Thanks @NathanVDH and @Luis for chiming in here.
For anyone still making up their mind, Nathan‘s/Snapshot‘s and Luis‘/Shutter‘s Snapshot Space tomorrow will be a good opportunity to learn more and discuss:
thank you for the heads up!
Very good! It"s good project
I share the same sentiment. I favor shielded voting, but It’s too early to use Shutter’s tools: the technology and centralization risks are too high at the moment. Let’s revisit in a year.
I think that’s a good idea
In the Snapshot Twitter Space last year it was discussed how to best approach the topic of shielded voting for the SafeDAO. There is a consensus that shielded voting provides a benefit to the general voting process, but there are some technical limitations (which have also been outlined in this post)
The best way that was identified to evaluate shielded voting was to create a Subspace on Snapshot that uses shielded voting via Shutter. A first step would be to define such a Subspace and how it ties into the current SEP process. As this is quite some overhead this step is unlikely to be taken immediately.
Another point that was discussed is pushing forward the decentralization of the Keyper network. Mid-term this is something the SafeDAO (and potentially the Safe foundation) should support by running a Keyper. Another proposal here would be to support this via a grant (e.g. every Keyper that participated in a shielded vote could be rewarded). But this is out of scope for this proposal and should be discussed separately.
Shielded voting could be proved a great idea.
Great to see shielded voting now supporting quorum, kudos to @Luis and the Shutter team!
When it comes to using shielded voting in SafeDAO, @rimeissner’s points summarised here remain.
A lot of questions around the purpose of SafeDAO and its scope of governance are still moving pieces, and implementing the right tools (like shielded voting) of course depends on the requirements of the former.
To move forward here and see if SafeDAO wants to adopt shielded voting, I’d say we could either wait for the next requirements-induced sub-space (e.g., sub-space for constitutional amendments or other short-/medium-term, formal use cases).
Alternatively, to move quicker, we could opt for an informal/inofficial use case. This could be any generic test space, although it would be hard to get authentic voting participation there. The best option that comes to mind is the inofficial, but practically used Snapshot space for temperature checks, most recently used by @Daniel.
Daniel and others, wdyt, would the temperature check-Snapshot space be a good candidate for trying out shielded voting?