Thanks for replying, my post is a mere suggestion I’m not ripping the incentive paper apart or saying we shouldn’t do incentives at all.
I’ll get back to you on where I saw the map but it’s a suggestion. The idea was that if it’s already in the map it can be used for suspension also
Actually these are sort of questions that should be asked, discussed and written about. It’s a tectonic shift as you’ve and 3 months to deliberate might not be enough. I’m particularly concerned how it might even affect liveness so I’m glad you are asking these questions. Bandwidth cost might increase even more so with p2p.
My assertion is just from observation and a rational actor. A rational actor won’t burn money for nothing, we’ve already posited in the paper that there’s not enough stake because people aren’t incentivized by getting rewarded. So if they aren’t getting rewarded because their stake doesn’t suffice they’ll drop is what I’m thinking. Also they’ll be suspended eventually
Maybe I should have been more clear, I’m not saying it’s going to change the floor what I meant was it’ll decrease their chances of winning a block which determines if you get the reward. So when their chances are decreased to the point of not making enough proposals they might drop off for the same reasons as previously stated. Or they’ll top up their stake which secures the network
Those who don’t meet the minimum currently will top up to meet the minimum because if they don’t they aren’t getting the piece of the pie. It won’t make sense for rational actor because other validators who meet the minimum stake and beyond are getting more of the pie.
By enshrined I meant that the minmax should be algorithmically determined if possible. I didn’t put the keyword possible. If we leave it to the whims of whoever it might be gamed or taken advantaged of. We still don’t know how they are going to be determined though, what ideas are being explored. If I recall correctly you said they can be changed. Changed how? According to what metric?
I don’t know why I’m getting the feeling that you think I’m challenging you or your mad or something. your response is like God from the book of Job. No I’m not challenging you to anything I’m making suggestions and spitting out ideas that’s what I thought the forum was for. A braindead peasant like me may not be technical enough to even make suggestions but every now and they do make good stuff. Far too often those considered to be in the know make irreversible mistakes and take actions that have unforseen repercussions. History is littered with examples.
And as a mere suggestion, what do you think of the post just above this, your humble good citizen and servant
I was able to find the pieces of code that might be helpful and could be applied for suspended accounts if feasible. In the block there’s a list of proposed updates to expired online accounts as noted on line 139 - 148 in block.go under bookkeeper
Also in ledger/eval.go the function generateExpiredOnlineAccountsList() “creates the list of the expired participation accounts by traversing over the
modified accounts in the state deltas and testing if any of them needs to be reset.”
These were the lines of code i recall and that’s why i said what i said ealier on, i may be wrong. Do you have any idea why it might not similarly work for suspended accounts. of course it’s not going to be a copy paste but i’ll like to know more.
As i was looking for the list i noticed the code for suspended accounts might already be taking this direction. I haven’t looked too much in the absentee code, but a peasant like me can do a tiny little reading into this great body of work to find out. Thanks for all you do and to the entire team
You’re very welcome. I value your opinion and the time you’ve taken to give feedback. I didn’t mean for my tone to come across dismissive or impatient.
Potentially it can, the concern is, does incentives cause a Cambrian explosion in node runners yielding a large data set which must be held for precise handling of absenteeism. We can do imprecise handling without holding all accounts in memory. The floor bounds this data set.
I agree, but rather than relying on this presumption a floor is safer.
I agree it would be nice but there is some complexity in doing so, the ceiling being dynamic could cause cascades, as the network removes misbehaving participants.
By governance, guided by ATAC.
That’s why we are in consultation with the community, wrote the paper and encourage PRs.
Thanks, as mentioned above the concern is bounding growth in this set, rather than accessing it.
I think much from the algorand side will not change. Algod node can have multiple online accounts, so on one node you can run multiple “aggregated pooling contracts”.
The thing is that it seems that only online accounts with 30k+ algo will receive the reward (as seen in GP10 decision), so more people will aggregate it this way.
And I think the Algorand Technologies, nor AF is not building this “aggregated pooling contract” as they focus on the P2P thing, but i may be wrong.
Great idea! They say after 5 accounts performance may take a hit. John mentioned they may multi-thread that part later so more online accounts can be handled in parallel on a multi-core CPU. Either way it will be really hard to find users who will be willing to sign the registration transaction (and send it via email?). The user experience of pooling will be shitty without the smart contract. Ideally the protocol-core would allow a user to stake under a node without the need of a smart contract. Also, if users stake could be locked this would help push up price and security of the chain.
I fear that the consensus mechanism will fundamentally change the game theory, and over time change Algorand in unpredictable and undesirable ways. Is there a chain with consensus incentives that does not trend toward centralizing? A cap on participation doesn’t change the centralized power of pool operators. As soon as running nodes has a monetary incentive, the monetary incentive will eventually take over the network.
While Algorand currently desires low fees, as soon as nodes are being run primarily for the reward, then node operators will want to increase that reward. The average person will never have the ability or desire to run a node, but they will put their assets to use for yield. All of the incentive will naturally align for pools, provide people with yield, have motive for increased profit, and ultimately have the Algorand development decisions in the hands of the pool owners. They will have motive, and power, to drive development of Algorand to increase their own profits. The profit motive will drive Algorand development in the future, and fees will be raised accordingly.
I still believe in the original game theory of people (businesses) running nodes because they benefit from securing the network for the chain they use for their business. Any business with moderate dependency on the chain will need to have one or more nodes running locally just for reliable and fast transactions. Which on that note, splitting up stake across multiple nodes in an enterprise might not be ideal, perhaps there can be a way to utilize a single participation stake for multiple nodes.
Anyone who needs the chain for their business case, will need a reliable node to transact with. The primary problem is that a transaction node does not need to engage in consensus, so the existing incentives for nodes is there, and people look for things like nodely, or run the node locally to transact. If non-participating nodes were eliminated, the game theory would kick in without the need to alter the fundamental motive of running a node. Perhaps find a way to tie transaction rate to a single node with the participation stake so that the more you need to transact with a node, the more stake you will need for consensus.
I understand that it’s not happening as well as hoped, and maybe it would never, but those who run for purely monetary gain will drive decisions based on that. Perhaps there is another way to incentivize.
Personally I’ve run a node for a while, but I never set it to participate until recently, because why would I. I have yet to build anything monetizable and I get no benefit from looking into participating. But adding participation wasn’t all that difficult, it still was an additional task without much reason to do.
But there is incentive to run a node, just not to participate. Everyone needs to transact, the incentive is there, but right now the protocol allows you to run a node without participation, and that is what mostly happens.
We know there is demand for transacting, we know this leads to distributed nodes, and we know that the motive for transacting is aligned with the health of the network and protocol development. So why not tie that demand for transactions into consensus somehow? Make it so that there is no such thing as non-participating nodes, so that when you run a node you must have a participating account, and even make the transaction volume to a given node be a factor of the amount of online stake. The more transactions on the chain, the higher the stake requirement is for transacting, which also is necessarily participating in consensus.