Anonymous MACI (aMACI) reduces trust assumptions of MACI. An aMACI operator is unable to link votes to users after the users deactivate and re-register their MACI voting keys, ensuring anonymity. This reduction in trust assumptions provides users with the flexibility to hire third-party operators for their aMACI rounds without needing to fully trust them. In theory, anyone could become an aMACI operator for another’s aMACI rounds — an important feature that was not available in the original MACI protocol.
aMACI operation requires computational power and operational capacity. To ensure that third-party operators provide robust services, incentives are necessary. The best way to achieve this is by creating a free and decentralized market of aMACI operators, allowing the most capable operators to emerge through competition. Every aMACI operator's on-chain track records will help round owners to evaluate operators' past performances.
On the other hand, aMACI rounds could be time-sensitive, time-consuming, and of high stakes. An underperforming aMACI operator could lead to devastating results for the rounds. We also want aMACI operators to take responsibility for the individual rounds they manage. This means that the operators need to facilitate key deactivation / re-registration as well as complete the tally / validation correctly and in time.
These goals can be achieved via token economics.
Decentralized aMACI Operation via Operator Incentives
Every aMACI round requires a certain amount of computation power and operational capacity to manage the aMACI process, including handling key deactivation and registration processes, tallying votes, and generating and validating zero-knowledge proofs for message_processing
and vote_tallying
.
In particular, the operator must ensure that (1) key deactivation and registration are completed on time, (2) votes are correctly tallied, and (3) zero-knowledge proofs are generated and validated in a timely manner.
If all operations are performed correctly and on time, the operator should be rewarded accordingly. The reward amount is proportional to the scale of the voting round.
When an aMACI round is deployed, the cost to run it depends on the circuit size and the number of aMACI messages to be processed. These operations are deterministic, so it is possible to calculate the operating cost of a round based on predefined rules. Since DORA token is the base currency of Dora Vota, which hosts all aMACI rounds, DORA will correspond to the per-message processing cost at a given aMACI circuit size. The details will be made available later in Dora Vota's mainnet documentation.
Operator Accountability via Round Insurance
There are two ways that a round operator could fail to provide service during a round.
- The operator misses one or multiple scheduled
deactivate_message
operations. - The operator fails to meet a reasonable tally timeline or does not deliver zero-knowledge proofs to validate the results.
In the first case, anonymity cannot be fully preserved. If all deactivate_message
operations are missed, then the aMACI round deteriorates to a MACI round. In the second case, the round will completely fail. Therefore, healthy aMACI operation should avoid both of the above scenarios.
In a crypto-economic system, accountability is ensured through economic stakes. In this case, we could create an aMACI round insurance policy on Dora Vota to enforce accountability. Each aMACI operator can optionally make a deposit as "round insurance". The deposit amount represents the maximum funds that can be claimed in the event of failed aMACI operations. To claim the loss, the round owner pays a premium upfront and claim an amount based on the loss ratio.
The round insurance functions as follows:
-
Calculate the max compensation amount from an operator's deposit by substracting the amount already locked up for other aMACI rounds from the deposit.
-
Round owner pays a premium of no more than
max_compensation * loss_ratio
. -
Lock up the compensation amount determined by
premium / loss_ratio
on Dora Vota. -
Compensation amount is locked up until the successful completion of the current aMACI round. After that, the remaining amount is unlocked, and the slashed amount is compensated to the round owner for underperformance.
The deposit can ensure aMACI operator accountability during both the voting period and the tallying period.
-
During
voting_period
. A linear slashing can be imposed on an aMACI operator for failing to process one or multipledeactivate_message
in time. -
During
vote_tally_period
. The tally period is also time-sensitive. The time for an operator to provide zero-knowledge proofs and validate an aMACI round can be determined by the designated circuit size and the actual messages posted on-chain. In the worst case, if the round operator cannot provide valid zero-knowledge proofs and the round becomes moribund, the total insured amount should be slashed and paid out to the round owner as compensation.
There are other design details to be decided, such as how loss ratio is calculated and how the insured amount will be divided between the deactivate_message
operations and the vote_tally_period
. These are out of the scope of this post but will be covered in the upcoming documentation following the Dora Vota mainnet launch.
In conclusion, operator incentives will help create a free market of aMACI operators, while round insurance will enforce accountability and secure individual round operations. When a round selects its operator, it first examines the operator’s past performance and then chooses one with sufficient insurance funds based on the economic significance of the round. Purchasing round insurance is optional, but a high-stake aMACI round will likely choose to do so. Therefore, a well-performing third-party aMACI operator with a sufficient insurance deposit will be well-positioned to host large-scale aMACI rounds.