Community wallet governance protocol change
Abstract
This paper proposes changing aspects of the governance protocol written by Ubiubi2018 and chosen by the Idena network. These changes are meant to optimize the current protocol which has been running since epoch #89.
Changes
1. Change delegate status time period
The time period delegates are elected should be changed to 3 months instead of 3 epochs. The day on which Epoch #95 begins will be used as a fixed point. Every 3 months when this day arrives, a new round of delegates is elected.
Suggested by Syd
Motivation
Idena’s epoch duration is not fixed and can change easily at low network sizes. Considering the network could continue shrinking, the epochs may get shorter. This will make the duration of each round more stable.
2. Remove voting deposit requirement
The current version of the governance protocol asks for every oracle to have a voting deposit mandatory. This should be completely removed.
Motivation
The voting deposit was never used due to technical difficulties in setting oracles up. After IIP-5 was introduced the calculation formula for the voting deposit was not feasible anymore as Idena miners no longer have equal mining rewards. Previous delegates agreed to not set up oracles with voting deposits and this feature was never used.
3. Adjust oracle parameters
a) Oracles must be set up as “polls” instead of “making decision” — rewarding everyone voting
b) Oracles must be network-wide if there are enough funds available
c) Oracle prize pool has to be set at 100 iDNA (or 2% of the Oracle creation fee if it is not network-wide)
d) The owner fee has to be set to 0%
f) Vote counting period has to be set to 3 days (12960 blocks)
Motivation
a) With the voting deposit not being used, oracles don’t need to be set to “making decision”. This type of oracle needs to be used for certifying facts (for example: “Did person X do the work described in paper Y?”). When an oracle is set like this, only people voting with the majority are rewarded, the others being penalized due to certifying something untrue. Even if these oracles are created in order to make a decision, everyone should be rewarded regardless of their vote, encouraging users to vote what they actually want to vote, not what they think will win. Decisions still have to acquire 51% of the votes, but the oracles will reward everyone voting.
b) IIP-5 allows oracles to have an owner address set. This makes it safe to create network-wide oracles using community funds. There is no reason for an oracle to not include the entire network (besides funds availability).
c) The original paper describing this governance was written before the oracles were modified. It mentioned a 98% Owner fee which would translate to a 2% Prize Pool. After oracles were modified the Owner fee purpose was changed and the Prize Pool became a separate parameter. 100 iDNA Prize Pool is calculated as 2% of 5000 iDNA (oracle creation deposit). The outcome remains the same, this change only clarifies the protocol in accordance with new network changes.
d) The owner fee should be 0 due to the oracle changes mentioned above. This means if someone voluntarily adds coins to the prize pool of an oracle, this surplus will be distributed to the voters.
f) This parameter was not mentioned in the original governance paper.
4. Adjust oracle creation time
Currently, oracles have to be created 1 week before a validation session and end 1 hour into the new epoch. This requirement helps oracles get more votes.
Oracles may be created anytime during the epoch at least one week before the end of the epoch and must end 2 hours after the validation start time (15:30 UTC currently).
If an epoch lasts less than a week, an oracle may start at any time but must have a voting period of at least one week.
Specification
To achieve precision oracles will be created with the “Start time” parameter filled in with a time allowing for the setup (funding the oracle by delegates) to be completed in time. The oracle should be ready to go when this time arrives.
For example, we want to set an oracle voting starting on 23rd September at 13:30 UTC (exactly one week before validation) and will set the voting period to 7 days and 2 hours (30600 blocks). We create the oracle one day before (or about how much time it will take for 3 delegates to sign necessary transactions) and set the start time to 23rd September 13:30 UTC.
Notes:
- The time introduced here is in the timezone of the one setting it.
- Someone has to manually launch the voting when this time is due.
This is just a proposed solution to achieve precision when creating oracles to better achieve the timeframes presented in the protocol.
Motivation
Oracles should be able to be started earlier to make it easier to set up votings for funding proposals without concentrating all setup work in one day every epoch. This flexibility still allows for a high or even higher turnout.
Ending oracles 2 hours after the start of the validation is a more predictable parameter to set compared to 1 hour into a new epoch since validation time may vary. Usually, validations take around 1 hour, so ending oracles 2 hours after the start of validation will easily accommodate this.
5. Define the random selection process of delegates
The original paper describes choosing 5 delegates out of a pool of applicants randomly. The process was not defined.
Steps
- Define a list of candidates (list of addresses).
- Sort the list alphabetically in ascending order.
- Choose a future block number that is at least 1000 blocks away.
- Once it is available, use the first 3 bytes of the chosen block’s hash to determine a winning candidate: these 3 bytes represent a number that is the first winner’s number in the list defined above; since this number is bigger than the list of candidates, when we have counted to the end of the list, we begin to count again from top to bottom.
- Wait for another 4 blocks and repeat the procedure each time to determine the remaining delegates.
- Any collision is solved by multiplying the block’s first 3 bytes by 2, 3, 4… etc. until the collision is solved.
Note: Only 5 blocks are used for the election, collisions are solved by multiplying the bytes of the same blocks that caused the collisions.
This set of steps is inspired by the Idena Flip Reporting Lottery (Epoch #75).
Motivation
Establish a procedure for determining random delegates out of a pool of applicants. This will also allow creating a script since the procedure is now formally described.
This is the procedure that has been used so far, but it wasn’t officially written.
6. Public application for community delegates
The original paper describes the application process happening in a restricted discord channel to humans only. Applications should take place in a public channel. This does not mean users without human status can apply!
Motivation
This creates more transparency for other community members. Elections never happened in a restricted channel like described, but this was never officially removed from the paper.
Protocol migration plan
If successfully voted by at least 200 people, the changes described in this paper will immediately come into effect with the exception of the first change (1. Change delegate status time period) which will be valid starting with Epoch #95.