We're proud to announce that Shutter Governance is integrated and usable now for all DAOs using Snapshot!
By implementing Shutter Governance, Snapshot is now bringing shielded voting to Ethereum in the form of partial privacy using threshold encryption. The Shutter team has been working closely with the team at Snapshot on this first implementation of Shutter Governance. If you haven’t already, head on over and read Snapshot’s announcement post!
In this post, we'll dig a little deeper into the details of the implementation and the reasons behind some of the architectural decisions.
Shielded Voting Is Better Voting
We think by default - similarly to how voting works for political elections - all DAO voters for a given DAO vote should be able to access the same information beforehand. Shouldn't we, who are using crypto governance, also have that option?
To be more specific, these are some of the benefits that we're hoping to add to the voting process:
- Pre-voting information symmetry,
- And added layer of censorship resistance,
- partial privacy.
We expect that this results in reduced voter misbehavior and voting apathy, and that it can fix some issues present in specific governance incentive systems.
This might sound a little theoretical, so let’s have a look at these two examples:
- Consider a contentious vote in which a minority is pushing the poll early in one direction. Voters that don't have a strong opinion already formed might see this and think the outcome is already decided. Thus they'll be discouraged from voting and also from researching/forming an opinion. This could then lead to the vote going in favor of the minority due to voter apathy, which would not be a good outcome, given that the goal of the poll is to represent the majority opinion.
- Consider a whale with malicious intent observing and waiting for a vote to play out. Only to come in at the last minute, borrowing/buying just the right amount of tokens needed to sway the vote. And doing this at a time when there's no more time for the rest of the community to react.
In both of these scenarios, having the vote shielded could improve the situation massively. The first example covers how this feature can help with incentivizing people to vote, leading to a higher voter turnout. In the second scenario, we show how shielded voting protects the proposal from manipulation.
Shutter Governance Improves the User Experience of Commit-Reveal Schemes
Having established that shielded voting using a commit-reveal scheme could have immense benefits, the question still remains, why not use a simple commit-reveal scheme like the one ENS uses?
The answer is user experience. In a basic commit-reveal scheme, after the commit, users have to wait until some time has passed and then do the reveal themselves. Dealing with this can make the entire commit-reveal process infeasible. Users having to reveal leads to the pain and cost for the users having to do two transactions, additional UI complexity to account for the waiting period/reminding users, and losing a certain percentage of users who will always forget to reveal.
With Shutter, the reveal is taken care of by the system, and threshold encryption ensures that the trust in central actors is minimal.
Based on Technology by Shutter
At Shutter, we initially developed this technology to take on the task of protecting end-users from malicious MEV, and this remains our core focus. However, after revealing our initial use-case for this technology, external parties approached us for more uses for the tech, including specifically using it for shielded voting.
In our system, the voter only needs to perform a single action of submitting their vote. The keys for encryption and decryption are provided by a group of special nodes called Keypers. Keypers produce encryption keys by running a Distributed Key Generation (DKG) protocol. After the voting period ends, they publish the corresponding decryption key.
The voter commits an encrypted vote using the encryption key created using DKG and provided by the Keypers. The reveal is then performed by the Keypers. They decrypt the votes, revealing the end result of a proposal.
The Shutter system utilizes threshold encryption. Threshold encryption is a technique that enables a group of key holders to provide a cryptographic lock. A lock that can only be opened if at least a certain number of the members collaborate. This ensures that neither a single party nor a colluding minority of Keypers can decrypt anything early. Nor can they stop the DAOs from revealing the results of a vote. As long as a certain number of Keypers (the "threshold") are well-behaved and act honestly, the protocol functions as intended.
Improvements in the User Experience Through Simpler Key Derivation
The goal of a key generation process is to output epoch key pairs consisting of an encryption key and the corresponding decryption key. But, Distributed Key Generation protocols are notoriously inefficient with many participants.
Thus, Shutter uses a two-step process for Distributed Key Generation (DKG). First, a conventional DKG process is carried out, generating the so-called eon key pair. The public key is then broadcast while the secret key remains unknown forever – each Keyper only has a share of it. The eon key generation step takes a relatively long time, but this is acceptable as it takes place only whenever the Keyper set changes.
Votes are not encrypted and decrypted with the eon keys directly but with so-called epoch keys. From a single eon key, an unlimited number of epoch keys can be derived.
To derive the epoch public key, only the eon public key and a unique epoch identifier are needed. In this implementation, the unique epoch identifier is the proposal. Thus, each voter can compute the epoch public key locally to encrypt their transaction. But, the epoch secret key is a composite of shares that at least a threshold of Keypers has to contribute to. Each epoch secret key share is computed from the epoch identifier, and the eon secret key share is only known by the individual Keypers. In total, only a single message per Keyper and epoch has to be published.
Via this process, it is simple for voters to take part, as the key derivation process doesn't require the Keypers. By sending a single transaction, their encrypted vote is submitted to the system.
Are There Any Risks?
The way the shielded voting system is currently implemented should be considered a beta release. There are several reasons for this:
- The underlying threshold encryption implementation is still rather new and, therefore, may contain unknown bugs.
- The infrastructure to communicate the encryption and decryption keys between the Snapshot Hub and the Shutter is equally new.
- In this initial deployment, the Keyper set (the entities collaborating to perform the threshold encryption mechanism) will not be fully decentralized.
What are the consequences of this?
Due to the way threshold encryption works, the only real risk is that a proposal's votes might not be decryptable. We will take every reasonable precaution to prevent this from actually happening.
Also, we do want to emphasize that it is not possible for the Keypers / Shutter to censor votes or otherwise influence an ongoing proposal.
What Else Can Shutter Be Used For?
As was briefly mentioned already above, we initially created Shutter for on-chain transactions with the idea of preventing malicious Maximal Extractable Value (MEV) on Ethereum.
Now Shutter Governance is taking flight with this collaboration with Snapshot. And we recently announced Rolling Shutter, this time for rollups!
Rolling Shutter builds upon our previous efforts of using threshold encryption. However, it implements the DKG scheme directly into Layer 2/rollup sequencer mechanisms in order to protect all dapps deployed on a given rollup by default. This also increases censorship resistance and potentially latency properties of rollups.
Switch to Shielded Voting Now
You can try Shielded Voting for your DAO; any spaces in Snapshot can enable Shielded Voting in the admin settings. After switching to using this feature, all proposals created afterwards will use it, no matter what voting type is selected! And you can just as easily switch back to regular voting between proposals as well.
Tell your DAO to use it
Are you a member of a DAO but not the person in charge of the settings? Let your DAO know that Shielded Voting is available and to use it! Your entire community can now enjoy better voting!
Want to Become a Keyper?
No implementation of Shutter can work without Keypers. Join in running a node and ensuring a large pool of Keypers increases the decentralization of a set.
Drop us an email at contact@shutter.network if you are interested in becoming a Keyper in the future.
