The problem is that the choices are not fungible: It is not clear how one is supposed to combine the answers to the questions.
There is one thing that is fungible: ZEC!
I suggest polling the distribution from 0-1 year, 1-2 year, 2-3 year and 3-4 year (or simply 0-4 year).
Protocol
The ZF creates a shielded address for each potential recipient of the block reward (including the miners).
For example, with the ECC, ZF and ZCG we would have 4 addresses: zECC, zZF, zZCG and zMINER.
Every voter casts a vote by sending a transaction for exactly a total of 0.01 ZEC to these addresses (they can split the amount as they want). Any transaction that sends less or more is disqualified
[1].
At the end of the voting period, the ZF reveals the full viewing keys so that anyone can check the transactions.
The final amount in these addresses determines the reward allocation[2].
How does the ZF prevent double and unauthorized voting?
With Zero Knowledge Proofs…
Setup
The ZF generates a random voting key v_i for each authorized voter. Then they build a merkle tree. This tree has root r and each voting key v_i has a position \rho_i and a merkle path \pi_i. The ZF sends to each voter i their key information: (v_i, \rho_i, \pi_i).
Vote
The voter i calculates their vote id as V_i = \text{PRF}(v_i) and adds a memo containing V_i to their vote transaction.
Also, they generate a ZKP of the statement:
Given the primary input of
- r
- V_i
there is an auxiliary input:
- \rho_i
- \pi_i
- v_i
such as:
- Merkle Path Validity: (\pi_i, \rho_i) is a valid Merkle Path from v_i to r;
- Vote Id integrity: V_i = \text{PRF}(v_i)
The ZF
- rejects invalid votes when the ZKP does not validate;
- rejects double voting when V_i is used twice.