I agree… my assumption was that the online stake is also voting in consensus…
Ibu, can you pinpoint me to the source code where you have the tracking mechanism on which account is actually online and participating please?
Can anyone confirm if Folks Finance is currently really the only protocol that supports participation in consensus?
Gard has stated multiple times in the past that it enables participation in consensus as well, e.g. in this Reddit post. It is also an option on their dApp. However, here have been made conflicting statements about this.
If you count wallets as well, the AWallet has support to make account online on one click without need to run the node: https://www.youtube.com/watch?v=cSJjmnzvvLY
No, I am asking only about DeFi protocols that would fall under the scope of these measures. I assumed this was implied by the topic being discussed here.
Hey Bunsan. Any project could build tools for consensus participation, and the system would be much better with more options. Algorand users should have the choice to shop around and choose the solution which works best for them. At its core, consensus incentives should encourage more people to join consensus and more devs to build around it, which would help strengthen Algorand’s security. As a developer of a large dApp, it would be cool to see a different approach if you have a unique idea.
Sure, but I have feeling that some people are more equal to the foundation than others.
I have built consensus improvement tools and see who are we speaking about that will get all the funds to redistribute them?
So is your solution open source or not? Perhaps its good time to make it open source…
It is really baffling that the Foundation would support Measure 6 as it can endanger the security of the network.
As pointed out by @Swaggelwander, the protocol would lose a large portion of online stake when gALGO redemption opens, endangering the network, especially since it happens at predictable times.
The problem is that majority of Governors are not familiar enough with these details to make informed decisions.
Moreover, the fact that the methodology of monitoring the “good” node behavior is not precisely defined together with the measure raises additional concerns.
While considering number of block proposals might seem to be a good and simple solution, it is insufficient to define “good” behavior.
A node can propose empty blocks to reduce its computational burden. This will cause a buildup of transaction backlog.
Furthermore, depending on the frequency of reward distribution, observing just the number of proposed blocks favors large stakers as small stakers propose very few blocks, which would lead to centralization of the stake.
The problem is so complex that the core protocol developers are needing multiple months to come up with a solution that would not endanger the protocol.
It would be imprudent to transfer this responsibility to multiple smaller individual teams that likely do not know all the intricacies of how the protocol operates.
Incentives to do this is so minimal that noone will build his own algod node to do it… Algo protocol works so efficiently that it does not consumes basically any cpu…
Also notice that there is group of many nodes that compose a block… If single node proposes empty blocks it will not pass. Also the vote on block it is split to two phases block creation and voting on the block.
I would say that they are busy with other things and that the release of algod takes a lot of time because of testing and perhaps audits.
Perhaps this is applies to you but might not be to others who want to maximize their rewards.
In the end, it is necessary to remove parts of the existing algod node and not having to build one’s own from scratch.
Even though algod indeed has a relatively small HW usage, it is not negligible.
By basing the rewards solely on proposed blocks, a lot of other functionality can be removed (e.g. voting on blocks), freeing up resources and making node running more profitable by actually not helping the network.
This statement is not well-formulated. Each proposed block is composed by a single node. In a round, there usually are multiple blocks proposed. The protocol narrows the proposals down to a single proposed block, which is later certified. An empty block is a valid block and would pass the process as any other block proposal (as explained e.g. by Joe Polny in a Twitter space around 31:00).
Presumably, the challenge is not only implementation into algod but also figuring out how to define and monitor “good” node behavior that is robust against various attack vectors that arise from incentivization of participation.
If this part were already solved, then Algorand Inc. should publish their solution already now and this measure would not require individual projects to come up with their own solutions for this.
This part is done already for example by metrika
https://app.metrika.co/algorand/dashboard/consensus-participation?tr=1d
- Accounts Not Proposing as Expected
- Accounts Not Voting as Expected
Also Folks claim to do it, so I tried to ask if they can be so kind and open source their solution
Creating incentives for consensus will likely bring a lot more ALGO online to participate. If a chunk of that ALGO is participating through Liquid Governance, some of that might go offline in the time between quarters. However, it seems unlikely that the participation in consensus would decrease to lower than the current level, meaning the likely bare minimum is that, at points, the security will drop to the level it’s at now. As you’ve suggested to not change the system, do you consider the current level of participation to be secure enough already?
Without changing the system at all, the chain’s security status will remain stagnant for the forseeable future, and that might be an issue.
The main takeaway, from this entire thread… (If I understood this thread correctly)
Algorand Inc and foundation are working together to create a reward system for participating in general Consensus at the protocol level.
Once this system hits main net, correct me if I am wrong, then we don’t have to use any dapps to participate in consensus right?
Participating in consensus should be something that occurs and gets done independent of any Dapps, apps, companies, firms, etc.
Using a third party App (for algorand consensus) renders the whole concept and idea of General Consensus useless.
Why don’t we just wait 9 months or a bit longer for it to get implemented on the protocol level? This would make the most sense.
What’s the rush? What train are we catching?
The main takeaway, from this entire thread… (If I understood this thread correctly)
Algorand Inc and foundation are working together to create a reward system for participating in general Consensus at the protocol level.
Once this system hits main net, correct me if I am wrong, then we don’t have to use any dapps to participate in consensus right?
Participating in consensus should be something that occurs and gets done independent of any Dapps, apps, companies, firms, etc.
Using a third party App (for algorand consensus) renders the whole concept and idea of General Consensus useless.
Why don’t we just wait 9 months or a bit longer for it to get implemented on the protocol level? This would make the most sense.
What’s the rush? What train are we catching?
I personally think that this proposal, besides pointing in the right direction, that is trying to address the current issue of low online stake, has already succeeded in one goal: understanding if this is a major concern for the community, and the answer is definitely yes. Is it a perfect solution? Of course it’s not, the protocol level should be the way, but this implies a delicate intervention that takes time and effort that currently is not predictable (probably beyond a 6 months horizon). In my opinion this agile mid-term solution has the size (1M) that can be right enough to encourage Governors to step into Consensus and therefore gauging the actual adoption that can be obtained through these kind of incentives, which shall be extended to all classes of Governors once the solidity of the approach is thoroughly tested during its first iteration.
not correct…
DApps must have support to allow to submit tx to make the dapp address or escrows controlled by the dapp in the online state… So DApps who did not implement this will not be able to make their stake online, and any incentives in 9 months when AF will incentivize online stake will not be received by them
At the moment only Folks, and maybe Gard protocol allows in their smart contracts the keyreg transaction which tells blockchain that for this number of round i set my account balance to online state and the specific algod server will protect for me the blockchain
i would like to see the question to incentivize concensus on the global level now in the GP8, but if heads of AF will not allow this, i will be happy to see some incentive taken at least from the DeFi budget and moved for this purpose…
i believe that any algo which is in online state is much better than algo in offline state… lets start 10B algos online iniciative … there is no reason why person should have his account in offline mode (if he can set for free the public algod node he trusts)
as soon as more money can be made VCs will come in imho, BC especially loves to farm rewards
Such conclusions should be drawn with extreme caution. A completely valid case can be made that the new incentives will drive existing node runners to move their non-DeFi stake to (your) DeFi platform, subjecting an even larger portion of the online stake to these predictable fluctuations that endanger the security of the network. There even exist substantial precedents supporting this argument from when the Governance rewards shifted from vanilla to DeFi and the DeFi platforms did not yet support participation in consensus.
My view is that as a community we’re not getting very much out of the Governance rewards program. Current programming squanders both time and financial resources (42 million ALGO each quarter). Allocating a significant amount of ALGO purely dedicated toward answering a handful of questions every quarter, some of which are repeated on a quarterly basis - we ought to strive for input in the most efficient way possible and more than a handful of issues every three months.
For example, wouldn’t the concept of Measure 5 be most efficient were we to simply use a sliding scale and have the community select their desired defi rewards once and simply take the weighted average of the setting, rather than ask it across multiple quarters in pursuit of the same ideal allocation, thus burning through far more than 42m ALGO? So, it can feel like it’s just wasting both time and ALGO this way.
Why can’t running a one-click node be a prerequisite to earning your quarterly governance rewards right now, not in six months or 12 months etc. I hate to be a wet blanket, but it just feels like we’re squandering various forms of resources. I’d love to see more of a sense of urgency.
Doing this in the allotted time frame is simply not possible.
Then let’s do it the right way, create an approach for the general Algorand community, create a proper wrapped asset standard for consensus participation and push for its adoption within the general DeFi ecosystem. If this is something we seriously want to do, then we have to coordinate a talk with the Foundation and see how we build this, who builds this and how it fits in our general DeFi ecosystem. From a strong base-layer like this we can build innovative approaches to consensus participation, not from simply giving out rewards and hoping for the best.
Feels like that sometimes, even though I know it’s not the intention.
Then don’t offload it to just DeFi because you end up with a middle of the road solution. It either won’t attract enough consensus to be significant or if it does it becomes an attack vector. That’s bad design and we shouldn’t encourage it.
I suppose the rush is that we’re in essence dependant on the Foundation for consensus at the moment. But again, they know and are working on it, Inc knows and are working on it, we should open up the conversation with them and come up with an ecosystem-wide solution before we start incentives. We’re putting the cart before the horse.
That’s exactly my problem with the proposal. There’s nothing more permanent than a temporary solution. If this measure is moderately successful, then better ones won’t be given the time of day, or alternatively we’ll have standard-fracturing and a loss on UX (this is without opening the aforementioned REAL security concerns with it) and if it’s not we just pissed away 1M Algos on an experiment (mind you, half of what was allotted to our XGov program). What’s worse is that if we see a moderate response to it, we might get the brilliant idea of pushing this program even further in which case it will cause a serious problem to our base-layer.
Again, I’m only so passionate about this because I see it as a clearly flawed system that should NOT be supported in anyway. I understand that all the parties involved have Algorand’s success as their main objective, and that the intentions are noble, but this is a mistake and I can’t be more against it.