Governance - proposal for technical realisation for voting

Hi, is there any progress with the governance?

How do you plan to vote for proposal?

My suggestion is to use knowledge based representative democracy.

Lets define categories eg. Software, Fund, …

Lets allow anybody to forward its voting power to other person by making self transaction with note eg. {“vote”:“v1”,“transfer”:[{“category”:“Software”,power:“10”,"ADDR:“AAAAA…AA”},{“category”:“Software”,power:“90”,"ADDR:“AAAAA…AA”},{“category”:“Fund”,power:“10”,"ADDR:“AAAAA…AA”}]}

This way any address can transfer its voting power to other address…

When there will be some decision to be voted on, lets make the self transaction
{“vote”:“v1”,“decision”:{id:123, “vote”:true}}

Then some algo can count all votes and make the decision to accept the git pull request if sum in favor is greater then sum against.

The calculation can be following:

Acc1 > 90% > Acc2
Acc1 > 10% > Acc3
Acc2 > 20% > Acc4
Acc2 > 80% > Acc5
Acc3 > 100% > Acc1
Acc4 > 100% > Acc3
Acc5 > no tr def

Acc1 Balance 1, Acc2 Balance 10 Acc3 Balance 100, Acc4 Balacne 1000 Acc5 Balance 10000

Use case 1:
Acc4 votes 0, Acc5 votes 1

Acc1 > 90% *(1) > Acc2 > 20% > Acc4 (0) = 1 * 0.9 * 0.2 against
Acc1 > 90% *(1) > Acc2 > 80% > Acc5 (1) = 1 * 0.9 * 0.8 in favor
Acc1 > 10% *(1) > Acc3 > 100% > Acc1 << Deadlock = 0%

Acc2 > 20% > Acc4 (0) = 10 * 0.2 against
Acc2 > 80% > Acc5 (1) = 10 * 0.8 in favor

Acc3 > 100% > Acc1
Acc3 > 100% Acc1 > 90% *(1) > Acc2 > 20% > Acc4 (0) = 100 * 0.9 * 0.2 against
Acc3 > 100% Acc1 > 90% *(1) > Acc2 > 80% > Acc5 (1) = 100 * 0.9 * 0.8 in favor
Acc3 > 100% Acc1 > 10% *(1) > Acc3 > 100% > Acc1 << Deadlock = 0%

Acc4 > Direct vote: 1000 against

Acc5 > Direct vote: 10000 in favor

Sum:
against: 1 * 0,9 * 0,2 + 10 * 0,2 + 100 * 0,9 * 0,2 + 1000 = 2020,18
in favor: 1 * 0,9 * 0,8 + 10 * 0,8 + 100 * 0,9 * 0,8 + 10000 = 10080,72
direct vote: 1000+10000 = 11000
representative vote: 12100.9

Use case 2:
Acc1 votes 0, Acc2 votes 1

Acc1 > Direct vote: 1 against
Acc2 > Direct vote: 10 in favor
Acc3 > 100% > Acc1 : 100 against
Acc4 > 100% > Acc3 > 100% > Acc1 = 1000 against
Acc5 > No vote

Sum:
against: 1 + 100 + 1000 = 1101
in favor: 10
direct vote: 1+10 = 11
representative vote: 1111

Use case 3:
Acc1 votes 0, Acc2 votes 1,Acc3 votes 0, Acc4 votes 1, Acc5 votes 0

Acc1 > Direct vote: 1 against
Acc2 > Direct vote: 10 in favor
Acc3 > Direct vote: 100 against
Acc4 > Direct vote: 1000 in favor
Acc5 > Direct vote: 10000 against

Sum:
against: 1 + 100 + 10000 = 10101
in favor: 1010
direct vote: 11111
representative vote: 11111

1 Like

There is no discussion on governance within the discord, nor here… Do you (algo inc/algo foundation) have private talk without community on this matter now? When do you plan to talk to community about this?

Hi @scholtz - we’ve been working hard in the background on the mechanisms for both the referendum and the main governance voting system. The first stage has been announced today:

1 Like

Are you joking right? From wiki about referendum:

A referendum is a direct and universal vote in which an entire electorate is invited to vote on a particular proposal and can have nationwide or local forms.

Your decision making is

  1. Not universal vote
  2. Not for entire electrorate

Your “Referendum” is decision of KMD node runners what software should be used.

Why dont you make a referendum where any address can send some dummy transaction with the decision?

Who has stake online ? The early backers and exchanges… Are you serious that you want to call this referendum? Will it satisfy you that 50 people will decide the future of algorand network? Why the hack do you call it referendum?

The question is also quite debatable … Is the referendum question: Do you want to stop progress? You have not shown what you want to vote for… Is the question to upgrade to 40k TPS on the table or not?

Btw, all nodes should have automatic upgrades … no?

Or is it about the governance? Do you have alternatives to 1 algo = 1 vote? Do you give poeple the choice? Or is it just early backers to silently take over the algo network as a whole?

Thanks for this - your hard work is appreciated. @scholtz your points are well taken in rebuttal. Rather than responding in the form of questions, it may be helpful to articulate a better referendum according to your perspective. Then, highlight the differences between your referendum and the Algorand referendum.

1 Like

To be clear, this referendum has only 1 task: to approve the Governance Program Proposal. In order to facilitate full community governance, there has to be a way for the current network partners (relay node runners and participation node runners) to signal their support for this program. Once this “one off” vote is completed, the Foundation will work to implement the full community governance proposal as outlined in the proposal document - we expect a significant % of the global Algorand community to participate in the full Governance program, as this program will be run as a 1 or 2 click process from within the wallet. The goal of this exercise, assuming the referendum vote is successful, is to begin to implement decentralization of the governance of the Algorand network from Oct 1st this year.

As Brian ( @bhaney44 ) has pointed out, it you have an alternative proposal for the community governance voting mechanism, we would be very interested to hear and understand that proposal.

2 Likes

I am sorry if I have touched someone, but really referendum is about asking everybody involved not just early backers…

Read the first post in this thread please.

Read the first post in this thread please.

If talking about the general governance voting system, @scholtz’s first post in this thread has a very concrete proposal for improving the decentralization of the governance.

Specifically, his proposal that “any address can transfer its voting power to other address” would allow voters to choose their “representatives”, rather than a central authority choosing the representatives, which would be an improvement over the currently planned Vote-with-the-Foundation option.

There may be some technical and logical challenges that would need to be solved for scholtz’s proposal to be usable (such as dealing with delegates who do not vote, circular delegations leading to no votes being cast, rewards structure with fair handling of such scenarios, etc), but I think it is the right direction.

Additional Proposal

As my two cents, I would propose applying the square-root method (aka the Penrose Method) to all delegated votes, where each voter’s voting weight is the number of algos the voter has plus the square root of the additional votes delegated to that voter. This would apply regardless of whether the exact voting method is the current proposal from Foundation (with the Vote-with-the-Foundation option) or scholtz’s more decentralized version.

The theoretical arguments for the square-root method (from Penrose method - Wikipedia) include the conclusion that proportional allocation (without the square root) would result in “excessive voting powers for the electorates of larger constituencies”. For example, the Foundation in the Vote-with-the-Foundation system would be the one that gains excessive voting powers.

There are also other practical benefits for using this method that may be harder to justify with mathematical or theoretical arguments, but should still be easy to see. For example, if delegating one’s votes is an easier way to earn rewards than casting actual votes, it will be more popular among those users who don’t care about the vote as much and only do it for the rewards.

Votes from people who don’t care about voting would be more random and/or biased (or just be cast to the Foundation because that is the only option) and a less accurate measurement of what these users actually wanted. And if such a bias can be known ahead of time, we should be extra careful of not giving such votes “excessive voting powers” that they otherwise will get if we don’t use the square-root method.

I put my answer to discord message also here…

First, I have suggested the technical type of voting before there was announcment about the referendum, so please do not attach the start of the thread to the technical detail proposed for this referendum.
Secondly, my intention was to make efficient way of decision making for algorand community not related just to governance. If this type of voting would be done, algorand could ask participant any questions and they could have high quality response within a day. I am sure that for more complicated questions there should be time to response longer, but it is about the efficiency.
Third, I was quite disappointed after I have found out about the referendum that you call asking the relay node runners question “the referendum” … where in reality if you would want to call it referendum you should ask all algo owners. If you want to ask relay node runners, call it “Node runners referendum” … so simple, so much confusion caused by this naming… If this vote is just proforma as mors has stated, why dont you name it correctly and make big event from it that you give power from node runners to 1 algo = 1 vote decision making?
Next, I was asking in the thread if you have any progress with implementation of governance which I did not get the response. What should the node runners decide then if we cannot see the technical solution?
Next, community asks for alternative for 1 algo = 1 vote … there has been many proposals, each one ignored by officials… One asks for wallet sqrt algo= 1 vote (I understand that this may lead to increasing voting power if the whales split the wallets) ; Second asks for two bodies to accept the vote … voting for 1 algo = 1 vote is one body, and second body 1 person = 1 vote… I am sure that if you asks people and let them suggest other methods how to limit power of whales so that whales have still significant power but not that much as 1 algo = 1 vote, people will come with ideas…

I would clarify that the specific proposal I shared in this thread would not be as vulnerable to “wallet splitting”, because the square root would only be applied to the number of delegated votes each wallet received, but not to the number of algos the wallet already has.

For example, if a whale with x algos received another y delegated votes, his (her) voting weight would be x+sqrt(y). And if he had split his x algos to two wallets, but people who delegate their votes still delegated them into only one of the whale’s wallets, the whale would still have the same x+sqrt(y) voting weight.

So, unless the whale was able to get people to delegate votes to both of his wallets, he would not gain any voting power by splitting his wallet. This reduces the risk that the mechanism could be gamed, and perhaps the risk could be minimized even further with some minimum level of transparency required for the delegates… (Full KYC for the delegates would obviously eliminate the risk altogether.)

And any voter who decides to delegate their vote instead of voting themselves is not going to intentionally try to “game” the system by splitting their delegated votes in any coordinated manner, because if they cared about maximizing the weight of their votes, they would simply cast their votes directly instead of delegating.

Finally, in the context of “vote with the foundation”, there is no risk at all, because all delegated votes would be in the same bucket and the square root would be applied to the total number of delegated votes.

If I have 1 B in algos

with sqrt I would have 31 622 voting power.

if I split it to ten 100 M wallets, I would have 10000 * 10 = 100 000 voting power…

Am I not understanding something correctly?

I think you are thinking of taking a square root of the number of algos in the wallet, which I have proposed in the past as well, but in this thread I was suggesting a square root of delegated votes only, while keeping the number of algos in the wallet under the “1 algo = 1 vote” rule.

In my suggested formula that you quoted, x+sqrt(y), x is the number of algos in the wallet, and since it’s outside of the square root, it is not impacted by wallet splitting.

In the formula y is the number of votes delegated to that wallet, but since they are already tied to that specific wallet address, the wallet owner can no longer split them to gain extra voting weight…

Ah, I think I see what you might be talking about now… I was assuming each vote could be delegated only once. But if you allow delegated votes to be redelegated (before taking the square root), then the whale could split his delegated votes into multiple wallets…

I’m sure there’s a simple solution to that though, allowing the rule to be applied to re-delegated votes too. Without having had a change to think about it further, I don’t see why the square root couldn’t be applied immediately after votes have been delegated for the first time, to eliminate the benefit from wallet-splitting. Or maybe the square root should be applied each time the votes are delegated or re-delegated…

I dont like the delegation of algos as votes very much because those who does not need the money are more likely to have more votes…

It is because if you have 1 B algos on the account, technically you should not sell it because you would dump the market which might not be in your interest…

On the other side, when you have 1000 Algos, you are more likely that you will need them in the 3 months period.

I believe that only the combination of dual party 1 algo = 1 vote and 1 kyc = 1 vote for approval is the real solution how to make the system fair enough also for small stakers…

The technical solution in the first post is capable of handling this within one voting session as the kyc backed accounts may be marked and we can do the computing of the result for both parties at the end of voting…

At the end I think I do not have enough power to persuade the algorand early backers to give up their power as they own more then half of all algos and can decide anything as they wish… This early distribution is quite a flaw of algorand and the only solution I see is to start new network with fair distribution of algos… I dont want to do this because the patents held by algo inc, but if someone would start it up I might consider running the other relay node so that it is decentralized. It might be good test for algorand to check if the solution can be run decentralized :slight_smile: so that the algo inc cannot sue anyone for braking the patents…

I understand the point and I agree with your concerns about the bigger picture as well, but if delegated voting (with 1 algo being 1 vote) was going to be used, as it is in the current plan from the Foundation, the square root would at least “fix” the weights of these specific votes.

This proposal was intended as an incremental improvement to the current plan, with a hope that it would make it more likely to be considered by the Foundation than a more complete overhaul of the voting system (where KYC and other complications make them unlikely to be adopted by the Foundation).

Or do you not agree that the square root proposal, applied to the delegated votes only, is an improvement over the Foundation’s proposal?

Completely agreed. Algorand is an amazing project theory- and technology-wise, but I just cannot wrap my head around why the distribution of algos was done the way it was done. And I still don’t know if they think of it as a mistake or not. Because if they do, they should be willing to admit it as such, and open a dialogue on how to course-correct in a way that makes Algorand the best long term option among all cryptocurrencies.

I think that possibility to cheat without detection makes this proposal counter productive… From my example if you split it to 10 accounts and you get 3 times more voting power, it is very much doable basically at any level if you are whale, mid or mini algo owner… Simplicity of the foundation proposal is estonishing, and it would work if there is no flaw with early backers…

Nevertheless if someone would create a public private algo network which would be distributed in fair way I still think that there should be two party system, because monopolisation will bring a lot of money to one hands either way and having the other party with vote per person will prevent changing the system in the way that majority of algo owners nor majority of people will not harm it…

Eg there is decision to split money between early backers for running the relay nodes or staking… If you would have monopoly who you would prefer? Btw who knows why the foundation wants to stop standard staking and give up the staking money only with governance rewards… (early backers will have majority there because they have vast algos sitting)

If my proposal was the only change made to Foundation’s proposal, it would not make cheating possible.

In the Foundation’s proposal, the option to “vote with the Foundation” is the only mechanism for Algo-owners to delegate their votes. And therefore the square root would simply be applied to the total number of votes delegated to the Foundation.

I think you are making an argument about a system where (1) votes can be delegated to any Algorand wallet (which is not the current proposal from the Foundation), and (2) where the square root is applied to the algo-balance of each wallet (which is not the proposal I’m making in this thread)? Because under those two conditions, you would be absolutely correct.

Even if the scenario 1 above was used, where votes could be delegated to any Algorand wallet, my proposal is not vulnerable to the method of cheating you are describing.

For example, if I delegated the voting power from all of my algo’s to one of your wallets, you would not be able to increase the voting power you received by splitting your wallet. Only if I delegated 10% of my algos to each of your 10 wallets, then you would gain 3 times the voting power. (This feature could possibly be taken advantage of in some other ways, so I can see why it’s not an ideal solution in this more generic scenario, and so I won’t defend it any further further as a solution to unrestricted delegated voting.)

But anyways, I do agree with you general statement that a voting system that enables cheating without detection would be bad, and quite possibly worse than the uncheatable “1 algo = 1 vote”.

However, as I have shown, my proposal is also equally uncheatable if it is the only change made to the Foundation’s current proposal and the option to “vote with the Foundation”.

Maybe I am missing something… how do you delegate the vote? I thought that you state in some app call that you delegate your full balance to governance… After 3 months you get rewards for minimum balance of algos you managed to keep in your wallet in the period…

The delegation of vote goes to physical person? In the governance proposal was that you can become governor even with one algo… So I think it is about the wallet … no?

And if you can split your wallet to 10 wallets, and put the delegated vote power with sqrt to the governor, why do you consider this not a cheating?

I think I see the misunderstanding now, and looks like we have been talking past each other (possibly due to neither one of us being native English speakers)…

Terminology-wise, my use of the term “delegate” was not referring to Governors committing their algos to governance, or the Governors using these algos to cast their votes. I used the term only to describe a situation where Governors decide not to cast the votes themselves, but want to have someone else vote in their behalf.

In the context of the Foundation’s proposal, therefore, I used “delegated voting” to describe that act of a Governor choosing to “vote with the Foundation”.

I think you used the term “delegate” to describe any Governors’ algos that are committed to governance, including those Governors who vote themselves (without handing their votes over to the Foundation)? Is that correct?

And does this clarify the misunderstanding we had?

I still do not understand…

What is mechanics for voting?

As staking governor you can pass your voting power to Algorand F.

However you do not have to… You should be able to cast votes.

Where comes your sqrt? How do you calculate the result of some vote?

This is how I understood it as well, so I think we both understood the Foundation’s proposal correctly.

Here’s a quick example how it would work with 3 governors, if my sqrt-proposal was added to to the current Foundation proposal.

Governor    Algos committed to governance
A           1000
B           2000
C           8000

If governor A casts his vote directly (i.e. does not delegate to the Foundation), his voting weight is the same as the number of Algos, in this case 1000.

If governors B and C decide to “vote with the Foundation” (i.e. they delegate their votes to the Foundation), then the square root will be applied, and the voting weight of the Foundation is sqrt(2000+8000) = 100.

Notice, that even if C split his wallet into two 4000 algo wallets, it does not change the voting weights, as the weight of the Foundation would then be sqrt(2000+4000+4000) = 100. Similarly, if governor A split his algos into two wallets, it would not change the voting weights, as his votes would have a weight of 500+500 = 1000.