A Deep Dive into the Colony Foundation Protocol - Dr. Aron Fischer and Elena Dimitrova

so I'm gonna want to talk to you about colony a part of colony today but let's start with what is colony colony is a governance platform for decentralized governance what it means is we've got this great thing the severan blockchain and we want to use it to enable us to coordinate amongst ourselves so that we can collaborate and work together on common projects and distributed governance means we can do this without a boss the authority is with the community and you know we can all share in each other's work and contribute yes so the contracts underpinning this will be open source 100% on the etherium platform it's for developers in the sense that we can anyone can develop apps on top of it and use our governance platform we are building an app the guys are building a great app here's a quick preview it's a beautiful task management interface allowing us to you know work on larger projects together and keep track of who does what and today we're talking more about the theorem side of things so the governance is designed to be fluid we don't want every little step' to be proposal discussion vote because with that level of bureaucracy you'll never get anything done it should be you know the focus on getting stuff done and making things easy however there always has to be an option to force a vote on something when there is disagreement so the vote is sort of a security back you know last resort and today we're going to discuss this little element the our voting procedure so the colony voting protocol so you know traditional democratic view voting is one person one vote it's an improvement from our previous model of one man one vote but it's not really useful on the internet because we don't know what a person is so the closest thing we have is a user account but we can't do one user account one vote because well unless we have very strict control over who gets to open a user account one person can open many accounts and vote many times and this is a double voting attack called a Sybil attack so our first requirement is no double voting in colony the voting will be reputation based if you do a lot of good work for a colony your votes will be worth more because you have contributed more to the tool and your peers have valued your work and this reputation score is something you earn it's stuck into your account based on how good you are how good your work is but the system the voting system is far more generic it works with any token it work could be weighted with whatever you want to weigh it with so we're gonna know demonstrate the token weighted generic token weighted voting protocol so vote token waiting why do we do it because it solves the civil attack problem it does this because voting weight is distributed not by account but by something which has real value so what matters is how many tokens you have and not how many accounts the tokens are in you know just think voting with one Benjamin is the same as voting with twenty Lincoln's because the total weight you know it's it should be the same token weighted voting does have some you know subtleties it's not as easy as you are the first thing the main question is what happens with the tokens when you vote and can you move them so if we use the tokens to votes if you transfer your tokens to vote we need to keep track of you know sending tokens back and that's a lot of overhead but more importantly it limits us to a single vote at a time so here's why that's true so if user has tokens and is asked to vote yes or no and then the user votes by sending the tokens maybe a vote for yes well if the users ask something else then the user cannot vote a second time not until the first poll is closed and all the tokens are returned so because of this it's not really usable so the other option is we just send a message and we remember what you voted and how many tokens you had but you don't actually have to transfer the tokens themselves well in this case we have a new double voting problem because if a user to vote on a yes/no question we just send a message and we remember how you voted the user can open in your new account move the tokens and vote again and again and again so that's not useful either so to stop this we can well we can keep track of all the movements of the tokens and try to adjust the vote or another method is we can just stop the transfers and this is a common approach it's called token locking works like this user is asked to vote user votes by sending a message and then the tokens are locked the user cannot move them to a new account so it cannot double vote they can still vote on another question by sending a new message that works fine there's no problem so that's great when both of those votes are finished the tokens are unlocked and the user can move them again so why is this not the solution the problem here is that you might want to do something else with your tokens you might want to sell them you might want to move them and so there's a liquidity cost associated with voting you might think I really want to vote yes but maybe I shouldn't vote just yet because I might still want to sell tokens and you wait so you have an incentive not to vote or at least not until the last moment and that means the result of the poll is not accurate it measures something wrong the incentives aren't aligned so we don't want that we don't want students enters yes another issue all the votes are public you can see on the blockchain what's going on so you might come and say I want to vote yes and then yeah everyone else is voting no maybe I should vote no - this is a very common effect and it defeats the wisdom of the crowds effect so running tallies must be secret it's a third requirement and our last requirement is based on well here this following question always comes up why can't we just collect everyone's votes and evaluate them all at once then we don't have any locking or any transfers and that would be fine except we can't add up an arbitrary long list of votes because of the gas limit so we want our voting to be scalable to arbitrarily number of votes and simultaneous polls so let me introduce the basic idea of our voting protocol doesn't have the Sybil attack because it's token weighted it also prevents trans for token transfer double voting by having the locking mechanism but it's one where there is no student sentence there's no liquidity costs because you have control of your tokens at all time votes are secret so there's no wild while they're open so there's no bandwagon voting and it scales as I mentioned so here's the basic idea users vote by sending messages which are masked so they're secret nobody can see how you vote you've committed to the vote about its secret and you can move your tokens nothing is locked there's no liquidity cost associated with voting when the poll closes at that moment your account is locked however you can immediately unlock your account again all you have to do is send a message to unlock your vote so there's never a time period when you want to access your tokens but you can't because as soon as they're locked that's the moment you can unlock and also the unlocking transaction is what adds your vote to the total so there's no gas limit problem with adding arbitrarily number of votes so that's the basic idea there's a whole lot of things we need to keep track of like how many votes how many polls have you taken part in you know which ones are open which ones are closed and to determine whether your account is locked at this particular time what do you do with incoming tokens for locked account the good news is all of these problems are solved and we have a working implementation and to present that implementation here's Colony developer Alana Dimitrova hi so I'm going to focus on the key concept in our implementation which is solidity based the first one I want to highlight is that of the storage data structure basically we use for vote secrets this is a double linked list and it's used to store the unrevealed vote secrets for a user it is each item there contains in addition to the vault secret itself contains the poll ID and the poll close time free to vote it is ordered by the poll close time as you can see two key things about it and adding items to it when they use the votes is first of all the sorting of it so keeping the list sorted is delegated to the user so the user when they vote they need to tell us wearing that list I vote will go and secondly the we've made the decision to basically add an extra item to that list which is the zeroed item at the start we solved a lot of edge cases for us as we don't no longer have to worry about which is the first item in the list how many items that least had so it eliminated a lot of edge cases simplified our code a great deal so those were the two key things the second purpose of the doubling list is to be able to answer the key question of whether an address is locked and we do that by simply comparing the now timestamp of the current block to the first item in that list and the poll close time there so in the cases where we do have a vote for user which hasn't been revealed yet for a bowl which has already closed that user account is locked so in that case is address locked is true in all other cases where we have no items in the list or where all polls are still open that address is open still and not locked so in the world is address locked is useful is in the transfer functions of the token contract so token contracts follow the ERC number 20 standard which you've heard about a number of times today and that has a transfer function which essentially transfers the balance from a sender to recipient we've modified that to make two extra calls if I can get this to work so the first thing the transfer function does in our case is check whether the sender addresses lock in the cases where a sender has an unrevealed vote they need to go and reveal we actually failed that transfer Cole and we don't allow them to do that in the cases where the recipients address is locked however we do allow the transfer to go through but instead of updating their current running balance and making the tokens available to them we update them on hold balance which is an additional item in the token contract where tokens just sit and wait for the recipient to actually unlock their account so the reveal vote transaction is where kind of it all comes together so when the user reveals a vote they've previously submitted the first thing we do because it's a token weighted voting implementation we query the balance of tokens for that user because we'll need that later then we go and do some validity checks of whether the poll has already closed and whether the vote secret they're giving us is actually valid and if that's the case we remove the item from the doubling list with so earlier then we need to add up the total tally of the vote the poll option that they voted for so for example if a user has a thousand tokens and they voted YES in a particular poll the yes vote Toto is incremented by a thousand in that step and this is know that this is only the case when a poll hasn't been resolved yet so when an admin hasn't taken a total tally of the options if a poll has been resolved by the final counter in we no longer update the total tally but we do do the next step which is important which is to release their tokens so if a user address is no longer locked at the end of that reveal vote transaction we transfer their own hold balance to the current balance in the token contract and make the tokens available to them so release tokens is a function we've implemented as an extension to the token to the token contract the Easter dress lock can still return true because a user can have other unrevealed votes in there in the double linked list that we saw earlier so it could be the case they voted a number of times and a number of these polls have closed and they're only just revealing the first of the many closed poll votes so this is just a high-level view of the implementation we are writing a series of blog articles that basically will outline that a great deal and these are the contact details for us so we blog along on blog de comida i/o and I also wanted to show the team and to let you know that we are expanding so if you're interested come talk to us and that's it I'm gonna give a minute back