 I 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, this Ethereum 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 we can all share in each other's work and contribute. Yes, so the contracts underpinning this will be open source, 100% on the Ethereum platform. It's for developers in the sense that 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 work on larger projects together and keep track of who does what. And today we're talking more about the Ethereum 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 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-backed last resort. And today we're gonna discuss this little element, the our voting procedure. So the colony voting protocol. So, 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 Sible 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, and your peers have valued your work. And this reputation score is something you earn. It's stuck to 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 could be weighted with whatever you want to weigh it with. So we're gonna demonstrate the token weighted, generic token weighted voting protocol. So token weighting, why do we do it? Because it solves the Sible attack problem. It does this because voting weight is distributed not by accounts, 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. Just think voting with one Benjamin is the same as voting with 20 Lincolns because the total weight, it should be the same. Token weighted voting does have some subtleties. It's not as easy as you at first think. The main question is what happens with the tokens when you vote and can you move them? So if we use the tokens to vote, so if you transfer your tokens to vote, we need to keep track of 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 user has asked 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 or no question would just send a message and we remember how you voted, the user can open a 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. The 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, that'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 student incentives. 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 you say yeah, everyone else is voting no, maybe I should vote no too. This is a very common effect and it defeats the wisdom of the crowd's effect. So running tallies must be secret. It's our 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 civil attack because it's token weighted. It also prevents transfer, token transfer double voting by having a locking mechanism but it's one where there is no student incentives, there's no liquidity costs because you have control of your tokens at all time. Votes are secret so there's no, 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 and nobody can see how you vote. You've committed to the vote but it's 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 polls have you taken part in, 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 Elena Dimitrova. Hi. So I'm going to focus on the key concepts 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 link list and it's used to store the unrevealed vote secrets for a user. It is each item there contains in addition to the vote secret itself contains the poll ID and the poll close time for each vote. It is ordered by the poll close time. As you can see, and two key things about it and adding items to it when a user 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 where in that list their vote will go. And secondly, we've made the decision to basically add an extra item to that list which is the zeroed item at the start which solved a lot of edge cases for us as we no longer had to worry about which is the first item in the list, how many items that list had. So it eliminated a lot of edge cases and simplified our code a great deal. So those were the two key things. The second purpose of the double link 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 a user which hasn't been revealed yet for a poll 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 where this 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 address is locked. In the cases where a sender has an unrevealed vote, they need to go and reveal. We actually fail that transfer call and we don't allow them to do that. In the cases where recipient 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 an 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 double link list we saw earlier. Then we need to add up the total tally of 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 total is incremented by a thousand in that step. And this is not 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, i.e. the final counts are in, we no longer update the total tally but we 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 on 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 contract. The e-s address locked can still return true because a user can have other unrevealed votes in the double link 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 the 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 a lot on blog.colley.io 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.