News: We’ve updated our voting mechanism
As we move towards the public release of the Aventus Network, and continue working on our Proof-of-Stake solution, we thought we’d update you on a big change we’ve made regarding how users stake AVT for governance voting.
Let’s look at what went down.
TL:DR; Where previously each holder was required to maintain two separate funds (a pain, we know), we’ve now unified the funds into one, making everyone’s life a lot easier.
First, a bit of background
Originally, the Aventus protocol called for users to hold two funds: a deposit fund and a stake fund, and to continually choose how to apportion their AVT between the two.
The purpose of the deposit fund was to maintain an AVT balance for use within the protocol, where chunks could be locked up to cover various system-based deposit costs such as registering roles, placing member challenges, etc. This was a fairly liquid mechanism; users could top up freely and withdraw (unlocked) amounts when they wanted, but that meant the deposit fund could not be used to gauge the weight of a user’s votes. That’s because there was no way to ensure they wouldn’t alter their fund between the end of a vote (when the balance should count) and the time they revealed (when it actually was counted).
Which is why we needed a separate stake fund: to determine the weight of a holder’s votes. The stake fund could also be topped up, but only before any outstanding votes had entered their reveal period. Withdrawals could then only happen after all of that user’s outstanding votes had been revealed.
The vote reveal mechanic itself was (and still is) required because it is impossible to automatically reveal encrypted votes — this is due to the transactional and public nature of the Ethereum blockchain. As such, each holder must manually reveal their own vote by calling a method to confirm their original intention. They have 1 week to do this. Any votes that remain unrevealed after the week has elapsed are discounted, but in the original system their associated stake funds would remain locked until their votes were revealed.
You see, the state of the funds was managed by a dynamic linked list structure, which needed to be cleared completely before funds could be unlocked. This architecture meant that we could:
- allow AVT holders to vote on multiple matters at the same time
- let holders choose when they wanted to reveal each individual vote
- ensure a consistent weighting of their votes across all matters
Which all follows fairly logically, but is a roundabout way of doing things, isn’t it? So, not wanting to cause our users any undue hassle, and to ensure the weight of all their AVT can be realised, we decided that it was best to upgrade the protocol and merge the two funds into one.
Then, a problem
Before we could get stuck into actually reprogramming the protocol, we needed to figure out how to maintain the integrity of our two fund system.
On the one hand; with a single, liquid fund an AVT holder could cast their vote then change the weighting of that vote after the voting period had ended, but before they actually revealed their vote. They could do this tactically — by moving AVT funds between different accounts before revealing their associated votes — or by having an AVT balance altered automatically — if, say, they won a challenge in the intervening time. On the other hand; locking funds while voting was underway would prevent deposits and withdrawals being made, or winnings/losses being accumulated and then stacked against the vote.
The solution was clear: we needed a ‘snapshot’ of the entire system to be taken at the precise moment each voted ended. That way it would neither matter when votes were revealed, nor what their weightings had since become, as their value at vote-end was known. If that were possible, funds could be moved around freely, at any time, and could not be double spent and/or altered in relation to any votes. But to solve that problem, we needed an efficient means of storing and retrieving every single consecutive state of the system’s AVT balances.
Here’s how we did it
We began by logging every AVT account balance change (deposit/withdrawal/transfer) along with a corresponding timestamp of when that change occurred, thereby creating a complete history of every account’s balance. This was implemented using a virtual array structure, only adding the gas cost of 3 storage writes to the overall transaction cost.
That account balance history could then be searched whenever a user revealed their vote in order to determine what their balance had been at the vote-end timestamp. To do this we employed a simple binary search, performed whenever a vote-reveal was called. This proved very efficient in terms of speed and gas, but does fail if the user has previously made an enormous amount of AVT transactions. 10781 * the age of the known universe transactions, to be precise. We’re popular, but not that popular.
All of which means we have done away with the two fund system (hurrah!), while retaining our secure voting mechanism, and allowing users to transfer their unlocked funds however they like, whenever they want.
Bonus: we were also able to remove the cumbersome and complex DLL library and the various split fund methods, which both simplified the codebase and improved usability significantly. A win all round, I think you’ll agree.
