yeah, my biggest concern with delegation , well in particular with allowing liquid staking providers to also participate in xgov. There is supposedly some mechanics to prevent single entity for passing stuff, but imo it still elaves a lot of angles for exploit. I wonder how we’ll progress on that front tbh
2 Likes
Has there been any update on this? I am keen to understand the nuts and bolts of how voting will be conducted. In particular, has there been further advancements on the issue of mitigating potential manipulation? I have several ideas, but without knowing what the existing plan is, it is difficult to red team it or make suggestions.
2 Likes
@GhostOfMcAfee we are in the design phase of the framework, basically the idea would be the following: a proposal is approved if ALL these conditions are met:
- A quorum of all xGov Voting Committee is reached, counting 1 Address 1 vote, independently from the actual preference (Yes or No): 10% of total voters could be an example.
- A weighted quorum of all xGov Voting Committee is reached, counting 1 “Algo” 1 vote, independently from the actual preference (Yes or No): 20% of total voting power could be an example.
- The relative Majority of Approved over Rejected is reached.
The first two requirements are necessary to measure the “relevance” of the Proposal: if no sufficient xGovs are interested, even a super (irrelevant) majority should not decide on behalf of the rest.
The particular thresholds for the different categories (Small, Medium, Big) are still to be decided, with the understanding that the bigger the requested amount is, the larger the threshold should be.
3 Likes
With respect to the quorum, what is the gatekeeping mechanism to ensure there is not a sybil attack designed to prevent passage? I understand that the weighted quorum in terms of total votes helps prevent sybil attack designed to pass suspect proposals (since you still must have the Algo stake needed to pass), but what would prevent a person from spinning up hundreds or thousands of bots and voting “no” just to prevent passage of certain measures?
Thanks
3 Likes
Let me stress that the first two requirements, the quorums, are necessary but not sufficient: the real vote is by stake, that is a proposal passes if it receives the majority of the votes (50% +1 of the voters by stake) of xGovs which actually participate. So a sybil attack won’t have an effect on the passing of the proposal, it could have only the effect in increasing the “relevance” of the Proposal but, since there is also the quorum in the stake, this effect is limited.
1 Like
Right. But my question was about using a Sybil attack to prevent proposals from passing. Couldn’t I spin up a huge botnet to ensure proposals never get the requisite relevancy? If so, what’s the mechanism that makes that less likely.
1 Like
The huge botnet cannot prevent proposals, because the quorums are measured on the number of xGovs voting on that particular proposal, independently from the actual Yes or No. What a huge botnet could do is “fake” attention, that is let an “irrelevant” proposal pass one of the quorum, but then, in order to pass, the proposal must have also the weight quorum and the relative majority in the vote, therefore the power of a malicious botnet is somewhat limited. On the contrary, the same quorum is effective in preventing a big whale (or a consortium of few big whales) from “forcing” a proposal to pass even if there is no interest from a decent fraction of the xGov population, i.e. few xGovs participate in the vote.
1 Like
What if I make a massive botnet that always votes, but always votes “no”?
1 Like
A massive botnet that participates in consensus with enough Algos to produce blocks to be able to qualify for xGov… I’d be more concerned about a massive botnet participating in consensus and potentially coming offline at the same time, tbh.
So, it might be time for us to think about creating an xGov code of conduct. Perhaps, in this code of conduct we could stipulate that an xGov must be a person who, as an example:
(a) is a willing participant; (b) must never intend to vote in a way that tries to "programatically manipulate the system" - for example by creating a botnet that votes for them or blocks proposals; and (c) who is willing to always consider the progress of the ecosystem.
Now, that might be hard to monitor, but if we were to ever identify that it is happening, it would be within the rules to remove those accounts.
It would be fair game to try to convince other xGovs to vote yes/no by arguing the pros/cons of proposals, of course.
@GhostOfMcAfee have you seen this issue on other chains? How do you think we could solve it?
3 Likes
Accounts going offline does not concern me as much because consensus is all based on stake. A bunch of low stake accounts going offline will not impact much there. The reason why I worried about it in the context of xGov is that the new xGov system has a portion that is not stake weighted and thus is subject to a sybil attack. The secondary requirement of stake weighted voting ensures a sybil does not result in passage, but it could still (a) help a proposal always get to round 2 or (b) play mischief by denying proposals the opportunity to advance.
If there is a way to remove accounts, then I think this could be adequate. The thing you wouldn’t want is for this to just be a game of whack-a-mole. So, I think it’s better to have something in place to make it less likely in the first instance. Running a botnet for these purposes is not entirely cost free. But, there are things you can do to increase that cost or make it easier to identify bad actors.
For instance, is there any requirement that voters in the “account based” stage (that is, the part that is not stake weighted) actually must have proposed some minimum number of blocks (as opposed to merely being online)? If there isn’t, then I can just cram a bunch of 1 Algo accounts on the same machine. Each partkey adds a bit of a response delay, so above a certain amount (~4 partkeys) the node doesn’t vote as expected. But, if I don’t care about actually voting/proposing in consensus on those accounts (because there is no minimum proposal requirement), I could add thousands of them to a single hardware or cloud node.
I think you could mitigate this by either (1) requiring a certain minimum threshold of proposals to actually vote in the “account based” stage; or (2) making telemetry a requirement for participating in xGov and flagging nodes that have too many accounts on the same GUID (assuming that is possible). I would be interested in hearing what smarter people than me think about those options.
Edit: The goal here would be to make it so that a person has to actually spin up a bunch of different machines to vote multiple accounts. It does not prevent it entirely, but it makes it so the cost is no longer trivial.
No. But I also am not as heavily involved in other chains. However, I am firm believer that anything in crypto should operate from the assumption that if a thing can be exploited, it will be exploited unless there is a sufficient deterrent to doing so. Everything must be Red Teamed.
3 Likes
i am quite lost now… do we have already definition who is the xgov?
is it group of kyc’ed persons?
is it any account that produces blocks on algorand?
by producting the block you mean voting in the consensus?
is it somehow related to account that was active in the xgov pilot 1?
Is there some google doc or something that would describe the pilot 2 of the xgov system?
2 Likes
If this proposal is still current, it is quite strange as no wise person would willingly just hold algorand on his account if he can deposit it to folks and receive the interest yield from borrowing, in the future interest yield from participation rewards, or just swaping to galgo, or if person is even smarter he should maximize his yield from TDR rewards and get like 20-50% APY.
If you want to count the blocks produced by online stake, it means you are giving all power to xgov to whales who do not care about yield, and to protocols that aggregate the algos in smart contracts. This is great for whales to accumulate more algos through grants program. If that is the goal so be it, but please stop calling it expert governance.
2 Likes
@GhostOfMcAfee I asked @trekianov to expand on how the voting qualification will work, as he is writing the doc that describes it.
AFAIK, voting power will be established by the number of blocks proposed in a given period. So, merely having an account online without proposing blocks will not work in this case.
Hi @Ludo Answering with a quote from the OP on this thread 
Once we move from governance rewards to consensus rewards, the first new cohort of xGovs will be available to block producers. Anyone can produce blocks, not just whales, but - yes - the more stake the more blocks, so bigger accounts will have an advantage. That is not very different from what we have now, where voting power is based on the rewards received which is directly related to the amount of Algos the account committed to governance.
No, grant proposers are the only accounts that will require KYC.
Yes, and yes.
Unsure at this point, but likely when we switch to the new platform we will have to close all the current xGov pools and pay out the rewards.
You’re the biggest recipient of the grants program to date…
2 Likes
@GhostOfMcAfee here it is an extract from the Documentation we are creating:
xGov Voting Committee selection: Backward accountability
The xGov Voting Committee selection is based on a “backward accountability” mechanism.
A snapshot of past block proposers SHALL be taken every B_r blocks to select the xGov Voting Committee.
An xGov Voting Committee is identified by the snapshot block B*.
Example: suppose B* is Block 39000000 and the range B_r is 3M blocks (approximately equivalent to 3 months of blocks).
Let’s take a range of B_r blocks, with a snapshot block B_{n}, then B_{n+1}=B_{n}*+B_r
Any block proposer in the past B_r block range could be selected as a member of the xGov Voting Committee, with the exclusion of the Algorand Foundation.
Voting Power
The Voting Power of each xGov Voting Committee is calculated independently.
- A snapshot of the Ledger is taken every B_r blocks;
- Block proposers of past B_r block are listed, counting 1 vote per proposed block;
- Total votes are, by definition, V_b=B_r (1 block proposal, 1 vote);
- Votes associated with blocks proposed by the Algorand Foundation (V_a) are deducted;
- The voting power of the xGov Voting Committee is V=V_b - V_a.
The xGov voting committee is going to be refreshed every B_r blocks (around every quarter) with a new calculation.
We have made some analysis on the last months of produced blocks and this process would create an xGov list of around 400 participants, excluding the Foundation Addresses. We are confident that once the Consensus Incentivization is in place, the final list of Block Proposers will increase in size and hetereogeneity.
2 Likes
I wonder, how many of those are the accounts at folks finance which are incentivized to be online.
How many of those are AMM smart contracts, gAlgo, mAlgo, or others which aggregates the algos in one account.
Have you done some analysis on how many current xgov governors will stop becoming xgov governors? In count and stake?
2 Likes
@Adri @StephaneBarroso
I will not comment the KYC, but rather ask what else will change in the submission process? Because I do have some concerns on current system.
There seems to be a very low threshold on what is actually asked of an applicant to include in the proposal.
Technical project descriptions, budgets with timeframes are quite common to demand from an application everywhere else I’ve had experience with, but for some reason it is not so in xGov. It is perplexing to find many proposals meager on content, precise deliveries and persuasive arguments, but still require to be evaluated by expert governors.
Consequently, those proposals are not bound by concrete deliveries by any reasonable measure of what one would expect. A half measure proposal will then be able to deliver half measures if possible, and we all know it has happened before and happening right now. AF seems to be paralyzed to enact on said deliveries, and I wonder if this is an effort to avoid conflict.
We can argue and be creative about the decentralized voting mechanism itself, but isn’t it true, that the submission gates are still controlled by AF, as well as payment on delivery?
I find it naïve to wave it away to the “code is law” paradigm if that is the case, and instead I urge AF to get more involved and more demanding of the proposals and their deliveries.
Even if the above quote is admittedly taken out of context, I find it illustrative of the general point I’m trying to make. Algorand community is small enough and at the same time extremely engaged and sum positive, that we don’t have to let math algorithms have priority over the social algorithms of the ecosystem. We could, but we don’t have to.
There is very little dissension within the community, which is a quite unique and valuable atmosphere and allows for concepts, such as outlined by Fisherman, to have a high likelihood of succeeding.
Math and blockchain promise to be trustless where trust is difficult to achieve, but one need not overindulge in these things, in places where trust is present.
I will leave the critique of KYC and block based voting system to others, who already have given great comments on the matter.
3 Likes
Hi @HMP, thanks for your comments. We have been discussing deliverables verification internally and I have added it as a topic for voting session 4’s retrospective.
In the new platform proposals will be added via a form and we can certainly be more mindful of the information required to deem a proposal valid.
There’s also the anti-spam mechanism, where a percentage of the total amount asked must be deposited by the applicant at the time the proposal is created. If the proposal does not meet the criteria, it is deleted and the deposit is slashed with the funds transferred to the overall pot. If the proposal is accepted, the applicant will get their deposit back.
I couldn’t agree with you more about how excellent our community is and my understanding is that the new version we launch is not a “finished product”. Continuous improvement based on community discussions is very much part of this programme.
3 Likes
It’s okay to have less xGovs. We must strive to find the balance between quality and quantity.
6 Likes