Closed bkase closed 3 years ago
Igor-Tselkovskiy
commented
3 years ago Right, I understand. The more the node works according to the formula, the more chances I have of getting a share from the fund? But what if I'm not on the gold list of the top 100 validators who were allowed to get a share of the fund?
Vgk88
commented
3 years ago Good initiative. I think that GFMs should be active block producers.
web3validator
commented
3 years ago I am supported it. These requirements do not seem to be strict.
bingble
commented
3 years ago Agree, GFMs should participate in the network with staking or delegating. In the meantime, if they can get reasonable returns, they will be glad to do that without additional requirement.
BostonMike0643
commented
3 years ago what recourse do GFM's that are delegating have if their staking provider is not performing (it's out of their control other than to remove the delegation and reassign it to another better performer or take on themselves. I would assume that those GFM's won't be subjected to a forfeiture for something wildly out of their control?
bkase
commented
3 years ago @bkase where can we see in the the mina code that mina foundation actually can revoke our tokens? Thx!
As soon as there is code, y’all will be able to review it. Perhaps even a community member will contribute it! It’s just a matter of scanning the relevant staking ledger json files to manipulate the ledger for the hardfork. Should be pretty straightforward and very easy to audit.
bkase
commented
3 years ago what recourse do GFM's that are delegating have if their staking provider is not performing (it's out of their control other than to remove the delegation and reassign it to another better performer or take on themselves. I would assume that those GFM's won't be subjected to a forfeiture for something wildly out of their control?
It is on the GFM. You do control who you are delegating to, if you notice they are not performing properly, you must redelegate to someone who is. 11months gives you plenty of time to notice and time to cover the latency.
Adding any special cases introduces some form of centralization in my mind. If the terms above are accepted by the community, these will be part of the protocol through these hard forks.
BostonMike0643
commented
3 years ago what recourse do GFM's that are delegating have if their staking provider is not performing (it's out of their control other than to remove the delegation and reassign it to another better performer or take on themselves. I would assume that those GFM's won't be subjected to a forfeiture for something wildly out of their control?
It is on the GFM. You do control who you are delegating to, if you notice they are not performing properly, you must redelegate to someone who is. 11months gives you plenty of time to notice and time to cover the latency.
Adding any special cases introduces some form of centralization in my mind. If the terms above are accepted by the community, these will be part of the protocol through these hard forks.
Thanks for this. So it will be very useful to a provider scorecard metric (maybe someone is already working on such) to help weed through the good vs. bad services.
yourbuddyconner
commented
3 years ago As soon as there is code, y’all will be able to review it. Perhaps even a community member will contribute it! It’s just a matter of scanning the relevant staking ledger json files to manipulate the ledger for the hardfork. Should be pretty straightforward and very easy to audit.
So the foundation will be revoking grants by modifying the ledger at a hard fork, this seems like bad incentive alignment at best and dangerous at worst.
jrwashburn
commented
3 years ago I was wondering how the revocation would occur -- I guess a fork is a way to do it since we don't have contracts. I'm curious about these details and what it entails - does it continue the existing ledger + inject a series of adjustments? I understand there is no code, but don't understand the conceptual idea. What does a hard fork that would slash an account look like? What if we don't vote for it and stay on the old fork, etc. Is there somewhere to read about this and get up to speed? I haven't seen planned forks every 6 months. I realize it may be late for these questions, but I think we should have a better understanding of what is planned here.
koen84
commented
3 years ago If you are delegating, the account you are delegating towards must produce blocks in proportion to the number of GFMs participating.
Does this not forget to take into account the impact on block production chances from non-GFM delegations (say foundation delegation) ? As such this risks stimulating centralisation ?
It is also very important we don't disincentivize GFMs to run their own block producing nodes.
The burden of manual (and untransparent) delegation reward calculation and distribution might be a significant threat to that goal. Furthermore this might supercharge the (typical) tension between blockproducers and delegators.
spdd
commented
3 years ago I'm running BP on Zenitn and see Next block will be produced in: None in this epoch... checking at in 14d. This is a very little chance to produce a block in month. Please take a look at Solana network, Solana Foundation have delegated proportional to all 500 mainnet node operators and they are running stake-o-matic script that doing delegations betwen epochs based on validator's performance. Or give a chance for little block producers to buy tokens to be competitive.
argonau7
commented
3 years ago Block production has been erratic recently. However, in earlier testnets, this was not the case and blocks would show up within a few days. I expect the network to get up to speed down the line and make it possible for everyone interested to produce a block in time. What I would really like to see though, is a reconsideration of where the Foundation delegates their stake. I had great troubles producing blocks (I produced 3) during testnet because my setup wasn't sufficient, despite official documents stating otherwise. Only at one final Q&A was it confirmed that the 16GB setup was, in fact, insufficient. I have now upgraded to a multiple of that and Testworld as well as Zenith have been running extremely well with great uptime, including lots of snarks. I kinda feel robbed of the opportunity to get a Foundation delegation. Had I known I'd have invested more capital in getting a better server but at the time, this wasn't suggested. In terms of GFM members who run a node vs those who don't and simply delegate - I feel that there should be a premium for those early validators. After all, that was the actual expectation for GFM members in the first place. Delegating is fine, but it kinda defeats the point of us staying through thick and thin with the various Testnets and learning how to run a Mina node.
A1exashka
commented
3 years ago I do not share the enthusiasm for the described initiative. Taking care of decentralization, the team centralizes the ability to manage the ledger. This is contrary to the basic principles of blockchain. This is no longer a test network, this is a Mainnet! if there is no confidence in the existing model, then it is not necessary to launch the network, but to continue the tests. No one should have that kind of power in the blockchain, not even developers. The community should be stimulated with economic measures, not with a whip. If the economy does not work and does not stimulate block producers poorly, then it is necessary to change the economy, and not beat someone for the edification of others. You can always delegate tokens to a professional producer and not worry about anything, and not be afraid for anything.This is a demotivating factor for non-professional block producers, and also does not encourage delegating a stake to small / unpopular producers (despite the fact that the authors of the idea are striving exactly the opposite). Proposal works against decentralization. Being afraid of losing tokens, I simply delegate them to Gareth so as not to lose them at all, because I am sure that no matter what happens, grants will not be taken away from Gareth and his delegates. Is it decentralization? Honestly, I am shocked by this proposal. I ask those who also do not share the team's proposal, be sure to speak.
EmrePiconbello
commented
3 years ago It is on the GFM. You do control who you are delegating to, if you notice they are not performing properly, you must redelegate to someone who is. 11months gives you plenty of time to notice and time to cover the latency.
Adding any special cases introduces some form of centralization in my mind. If the terms above are accepted by the community, these will be part of the protocol through these hard forks.
I agree with your statement my issue was when stuff like that publicly introduced. I know it was in terms but looks like the majority of the people didn't read it. Either way when stuff like that comes up people just got scared of losing and tend towards delegating to a single point because of fear. Even though that's not how it should be and you share and make announcements like delegating towards a single validator is less beneficial still you will get that result. That's something I observe over chains and I don't see it's changing here.
A1exashka
commented
3 years ago what recourse do GFM's that are delegating have if their staking provider is not performing (it's out of their control other than to remove the delegation and reassign it to another better performer or take on themselves. I would assume that those GFM's won't be subjected to a forfeiture for something wildly out of their control?
It is on the GFM. You do control who you are delegating to, if you notice they are not performing properly, you must redelegate to someone who is. 11months gives you plenty of time to notice and time to cover the latency.
Adding any special cases introduces some form of centralization in my mind. If the terms above are accepted by the community, these will be part of the protocol through these hard forks.
if I, as a delegator, do not receive enough rewards from a block producer, I will find another block producer. It's a healthy economic reason. Why other measures for this? If you scare me, I'll just delegate my stake to Gareth - it's calmer. I'm not even talking about block producers who can be intimidated by such a proposal. They also delegate their stake to Gareth) the road to hell is paved with good intentions ;)
iAmMichaelConnor
commented
3 years ago It is also very important we don't disincentivize GFMs to run their own block producing nodes
GFMs are disincentivized. Based on rough calculations, it's a better financial decision to delegate 66k tokens than to run one's own block producer, just by comparing the costs of running a node vs the fees being charged by staking services. For 66k tokens to incentivise block production, the Mina market cap would need to be around $5.5bn at launch. (More details on discord https://discord.com/channels/484437221055922177/692040190608277534/812063672356307004 - lots of assumptions detailed).
ZoltarSeven
commented
3 years ago I think it would be good to specify the meaning of " via a post from the Mina Foundation". Does that mean an Email to each affected GFM, does it mean a post in the #announcement channel on Discord or any other #channel ?
Also, I think it would be great to give 1 or better 2 clear examples with concrete numbers for "The delegation rule" that demonstrate when someone would forfeit their stake. Otherwise I expect to see confused questions on the horizon, better make it very very obvious and not too abstract.
yourbuddyconner
commented
3 years ago @iAmMichaelConnor That channel on discord is private, could you please copy-paste the referenced material here?
bkase
commented
3 years ago Hey all, I'm a little busy for the next hour or so, but afterwards I'll process and respond to everything -- including that new issue #7982 that references this one. Thanks for all the feedback!
bkase
commented
3 years ago Hey everyone, thanks for your feedback on this proposal. I'd like to clarify a few points raised in the comments section. Please let me know if you feel like I accidentally skipped your feedback:
I will update the initial post to provide clarity here: The initial foundation delegations are only in place for the first 60 days, afterwards they will most likely change delegations based on performance of eligible nodes on the network — and this performance notion will take into account metrics, such as uptime, that are not subject to the same randomness as block production. I encourage all block producers to compete for these slots. Stay tuned for a communication from the foundation on how this process will work. (by the way, I'm not a part of the foundation myself, so I can't speak on their behalf!)
There were a few questions around staking requirements which I'd like to address. The aim of the Genesis grants are to help with decentralization and running of the Mina network. It's important to remember that these 66k token grants were offered with strict requirements and everyone who accepted that grant agreed to the terms of the staking requirement before accepting it. The protocol does not have any sort of slashing condition for typical block producers on the network. The protocol does revoke the 66k token grant given to Genesis Founding Members in the event that they don't participate and all GFMs were notified that they must meet the staking requirement both in the onboarding forms and on the kickoff calls.
The purpose of this consultation is to request feedback on how the requirements that you all agreed to are enforced. The idea of the staking requirements should not be a surprise to anyone — the details of how to enforce it are what we're talking about here. This process is not about introducing a form of slashing for participants in the network
The Foundation or developers or any specific privileged group isn't doing anything w.r.t. genesis token grant revocation — the best thing for the protocol is for the community to vote with its stake to modify the ledger at a hardfork by the process that we agree on here. The intention of this consultation with the community is to figure out details and get alignment so we don't have a large "Mina classic" fork early on.
Manual delegation reward calculation and distribution should not disincentivize GFMs to run their own nodes. If anything, it should incentivize this behavior. What it does do is create more effort for a node to accept delegations and properly compensate those delegating, but this information can be wholly transparent: as a person delegating your stake, only delegate to an entity who is describing how they will pay you rewards. Remember, this is just the beginning — the initial launch of our network — the community may decide that the most important protocol improvement is automating delegation payouts and incentivize protocol upgrades to make that happen.
The quote "via a post from the Mina Foundation": This means an email to each affected GFM member — I will clarify at the top. Email seems better than a public Discord message so we don't shame those who haven't yet met the requirement too noisily, it's not part of one of the core values of Mina — Respect — to do something like this.
Here are some which I'll add to the top as well:
Regarding: https://github.com/MinaProtocol/mina/issues/7982
I've closed this so we can keep our conversation in a single issue — I believe EmrePiconbello accurately addressed all the points here, and with the extra details above in this post everything should be answered. One bit I'd like to highlight is that the odds of not being chosen due to multiple productions in the same slot is taken into account in the probability calculations at the top of this doc. I'll reiterate: There is an overwhelming probability that you will produce a block in 11 months on the canonical chain with 66k tokens. The canonical chain here means what the "green" blocks mean in Minaexplorer.
bkase
commented
3 years ago It is also very important we don't disincentivize GFMs to run their own block producing nodes
GFMs are disincentivized. Based on rough calculations, it's a better financial decision to delegate 66k tokens than to run one's own block producer, just by comparing the costs of running a node vs the fees being charged by staking services. For 66k tokens to incentivise block production, the Mina market cap would need to be around $5.5bn at launch. (More details on discord discord.com/channels/484437221055922177/692040190608277534/812063672356307004 - lots of assumptions detailed).
Based on these assumptions, it does seem that w.r.t. delegating, if your hardware is in the cloud, in the short term, you could lose out on rewards. However, keep in mind, this is just the very beginning of the network. First of all, O(1) Labs is prioritizing reducing hardware requirements for block producers in Q2 this year — we hope this allows everyone to rely on cheaper hardware setups. Second, with regards to incentives, perhaps it's worth revisiting one's motivation for getting into the Mina network this early — it's not necessarily just about the specific rewards from Day 1. It could also about building your brand, proving yourself as a block producer either to gain delegations yourself, or to just improve your credibility for future discussions on the protocol or any applications on top of it.
bkase
commented
3 years ago I was wondering how the revocation would occur -- I guess a fork is a way to do it since we don't have contracts. I'm curious about these details and what it entails - does it continue the existing ledger + inject a series of adjustments? I understand there is no code, but don't understand the conceptual idea. What does a hard fork that would slash an account look like? What if we don't vote for it and stay on the old fork, etc. Is there somewhere to read about this and get up to speed? I haven't seen planned forks every 6 months. I realize it may be late for these questions, but I think we should have a better understanding of what is planned here.
Ah sorry, I missed parts of this one:
This would entail burning the tokens in these accounts when constructing the post-hardfork ledger. Thanks for raising; I shared more details about the burning above.
Re: the 6month planned forks -- Expect further communication soon, but yes within the short future, every 6month for planned hard fork upgrades seems reasonable (it is consistent with other network launches such as Cosmos)
See the above post to cover the rest
Igor-Tselkovskiy
commented
3 years ago Hi brendon, here's a couple more questions:
I am launching a block producer with a rate of 66k tokens. Without any delegation - my chances are very small compared to the rest of the participants. But I still have them, suppose I produce 3-5 blocks in a year, but what if they don't get into the chain? All red ... Then it turns out I have been online all year long - but I will still be punished, and by chance. (Can this be taken into account like that?) If the blocks were not added to the main chain ...
The question arising from this, in the production of 3-5 (perhaps more blocks per year, there can be no payback on equipment. Accordingly, for gfm that raise their nodes to VPS - this is already unprofitable, there is simply no incentive to become a block producer. Then they have delegate their coins so as not to fall under the whip and not lose all their funds. But the network will not consist of 1000 gfm that should become block producers - but of service staking. Because only they can make a payback. Is this Mina's goal is to leave only those nodes that can pay for themselves and the network will consist of 100 nodes ... All the conditions that are now in effect or will be in effect only force the delegation of their coins.
An automatic script is definitely needed, which will redistribute the fund delegation on the basis of uptime and blocks. The best option would be for all nodes that are gfm and have launched a producer block. If they violate the conditions of uptime and the production of blocks in 60 days (you can do less - but here it probably depends on the era), delegation from them is removed partially or completely. And then it is redistributed further equally to all participants. This is what they all want, every participant who wants to launch a block producer wants to have an equal chance of producing a block compared to the rest (not taking into account staking services)
An excellent example has already been mentioned by delegating the Solana fund to all validators of the main network.
EmrePiconbello
commented
3 years ago @Igor-Tselkovskiy
1)I just want to clear something as explained in your case in number 1 you just need to create 1 valid block for a year it shouldn't be that hard. 2) I can't speculate over price and profitability etc. everyone should consider these by themselves. 3)About automation and example of solana. It can be done for sure but it's much more complicated on this end. On mina there is no record of block producers since any account with balance can be block producer.
bkase
commented
3 years ago The 99.98% calcuation takes into account the odds that the blocks are on the canonical chain -- you can read more about this in my other replies. If we were to include blocks off the canonical chain, a GFM would be able to cheat and say "I had a block it just wasn't canonical, look" but actually create that block at the last minute.
I think I covered this https://github.com/MinaProtocol/mina/issues/7944#issuecomment-782340631
As I mentioned above, the foundation is deciding independently the mechanisms for reassigning delegations every 60 days. I'm not a member of the Foundation myself, so I don't have much to comment on here. I've dug up Emre from O(1) Labs' response to you in Discord because I think it's relevant (with his permission):
Hi Igor - for operational reasons, 120 is the maximum Foundation and its entities can delegate to. Honestly this is already quite a bit of a stretch. If you'll remember the initial proposal was 20, which was updated to 120 per feedback from community.
Also there is no limit to how much can be decentralized. What if we increase 120 to 250, is that enough? 500, 1,000? One can argue it's never enough...
I would like to emphasize that this is not a permanent delegation. Blockchains are long lived networks so in the years to come, these delegations won't be relevant. Launch of mainnet is only the beginning, and we gotta start from somewhere. We ask that everyone stays patient, and works to decentralize further together as a community.
Also to add more - Mina empowers maximal decentralization over time per its design. Let's not pigeonhole ourselves to how many BPs are delegated to at the launch of the network. Other PoS networks have to overcome much more fundamental challenges, such as being limited to 100 validators. Mina is already so much further ahead
bkase
commented
3 years ago @Igor-Tselkovskiy
1)I just want to clear something as explained in your case in number 1 you just need to create 1 valid block for a year it shouldn't be that hard. 2) I can't speculate over price and profitability etc. everyone should consider these by themselves. 3)About automation and example of solana. It can be done for sure but it's much more complicated on this end. On mina there is no record of block producers since any account with balance can be block producer.
thanks @EmrePiconbello ! I didn't see your reply when I started drafting mine
Igor-Tselkovskiy
commented
3 years ago @Igor-Tselkovskiy
1)I just want to clear something as explained in your case in number 1 you just need to create 1 valid block for a year it shouldn't be that hard. 2) I can't speculate over price and profitability etc. everyone should consider these by themselves. 3)About automation and example of solana. It can be done for sure but it's much more complicated on this end. On mina there is no record of block producers since any account with balance can be block producer.
Igor-Tselkovskiy
commented
3 years ago @bkase I understood this about the fund, I say that it would be the preferred option for everyone, as it seems to me. But I am still confused by the chance that all the blocks I produced may turn out to be red. It's not difficult to make a green block, but out of 10 blocks in a year, all of them turned out to be red, I can not influence the creation of blocks in time, so that I can deceive you and create a red block in the last minute ...
bkase
commented
3 years ago I want to respond to a comment from @mobileink from Discord that I think is interesting:
Reworded: Since we're using block production as a proxy for uptime which is a proxy for participation, why not measure uptime directly and skip a step?
It boils down to uptime being a metric that is inherently centralized to measure. The only information on-chain is blocks produced: Uptime has to be measured separately, and who is the steward of this information? There is too much centralization introduced.
The foundation delegation program can use an uptime sampling mechanism because the foundation can have its own database of uptime information and is making its own decisions about whom to delegate to. We do not want the staking requirement here to be something relying on any centralized measurement metric.
bkase
commented
3 years ago But I am still confused by the chance that all the blocks I produced may turn out to be red. It's not difficult to make a green block, but out of 10 blocks in a year, all of them turned out to be red, I can not influence the creation of blocks in time, so that I can deceive you and create a red block in the last minute ...
Let me rephrase: The odds of all the blocks your producing turn out red in 11months with 66k tokens is upper-bounded by 0.02%.
You can deceive me because everyone's view of the chain will have different "red blocks" (orphans) depending on the network topology at the moment. I can retroactively make an orphan block and claim that other nodes on the network didn't see it. Remember, we don't want to rely on a centralized service even one as trustworthy as Minaexplorer :)
iAmMichaelConnor
commented
3 years ago Really interesting discussion :)
It boils down to uptime being a metric that is inherently centralized to measure. The only information on-chain is blocks produced: Uptime has to be measured separately, and who is the steward of this information? There is too much centralization introduced.
This is a tricky one. The whole motivation behind this thread is to delete user funds according to a centralised contract between each GFM and O(1) labs. A contract is a contract, that's fine. But hard-forking a blockchain to delete balances because a centralised party (O(1) labs) will need to carry out the terms of an off-chain, centralised contract, is arguably not decentralisation. Therefore, perhaps the measure for carrying out those contractual terms needn't be decentralised either?
A centralised method of measuring uptime certainly has the benefit that truthful block producers won't be 'slashed' based on bad luck.
A smart contract would also have been good for the purpose of carrying out this conditional distribution of funds. Funds could have remained under the control of the company executing the airdrop contract (O(1) labs), and only released if staking criteria were met (data which could be fed in via an oracle).
Suppose, in 11 months' time, the decentralised community disagrees with this proposed hard fork to delete certain users' funds. Can O(1) labs allow that? Or do they need to force the hard fork to ensure the terms of an off-chain contract are being adhered to? If it's the latter, then that's possibly not decentralisation. Baking the contractual terms of a single contract into a blockchain at the protocol level raises lots of interesting discussions.
Disclaimer: I'm not saying I disagree with the GFM contract; those who signed up to it signed up to it and that's fine. The method of execution of it's terms are what are being debated here. I just enjoy these thought exercises. I'll be running a block producer regardless :). I think the tech is exciting and I'm looking forward to exploring what snapps I can build on Mina. But I do think there's an ideological contradiction somewhere, that's important to point out.
EmrePiconbello
commented
3 years ago 1) The hard fork already carried out for the updates and if the community doesn't support it fork can split that's not a centralized thing. Everyone can fork a chain. You just need the support of a group to do that. Outside a lot of project being fork from each other, there is like +30 btc forks and much more which is not known by the majority of the public.
2) In this system you just need to create a 1 block in an 11 month period with 66k stake. I don't see that happening since you need to be very unlucky over and over again. Also, there is no slashing that's not slashing. It's just about the terms of the genesis.
3) Smart contract is not available on mina yet. Even if it's supported chain can't keep up with the uptime data of every gfm that's not a feasible solution since that will cripple the network and create a huge and constant load. Since the chain is not optimized for throughput that's not viable. In the end, it's a more centralized process if you do it over smart contract than fork since fork requires support while smart contract way is not and fully controlled by centralized data and entity.
4) If something like that happens and they are not the majority they can fork off to their chain but I don't see that anywhere near likely.
riokresnawan
commented
3 years ago Right, I understand. The more the node works according to the formula, the more chances I have of getting a share from the fund? But what if I'm not on the gold list of the top 100 validators who were allowed to get a share of the fund?
THANK YOU, TERIMA KASIH SUKSMA
riokresnawan
commented
3 years ago THANK YOU for information issue suksma, terima kasih
iAmMichaelConnor
commented
3 years ago Thanks for those points @EmrePiconbello. As I say, it's a really tricky one :)
The T&Cs say: "
"
Within those confines, maybe @bkase 's excellently written proposal is the best we can do, because the Mina Protocol only has access to limited data. But the staking requirement in the agreement isn't to "produce a block". The staking requirement is merely "to stake". Perhaps the inability for the Mina Protocol to accurately enforce the actual staking requirement is a problem?
(Btw I didn't choose to write that stuff in all capital letters. It was a copy-paste. I'm not angry :) )
IANAL. And I'm still forming a view (views are my own). Very helpful discussion :)
dheeraj07
commented
3 years ago very insightful discussion here! It's good that you guys decided to change the foundation delegation every 60 days.
And regarding this point mentioned by @bkase - "opt-in to the foundation delegation program", how do someone can register in this program? Yet to be decided by the Foundation?
yourbuddyconner
commented
3 years ago Very much agree with @iAmMichaelConnor here, it's less about whether it's technically feasible and more about whether it's appropriate for the foundation of a decentralized protocol to be enforcing a centralized agreement via a hard fork.
The argument of "Oh well, anyone can hard fork the network, if you don't like it you can just go fork it yourself." is a really weak counter for this because the Foundation's main goal is presumably maintaining the health of the decentralized network for the majority of people.
If instead it's about protecting the investment of a a handful of tokens disbursed to Genesis Founding Members, this makes a lot more sense. IMO, hard forks should not be abused for centralized purposes, and should benefit everyone on the protocol equally. At the most extreme we should see a bugfix reverting erroneously minted tokens, as was the case for Bitcoin in the 184B BTC Bug. Even then that was out of complete necessity, not premeditated like this is.
Brandon is just the messenger here, and he is doing a wonderful job of collating the arguments and responding to them. For that I thank him!
Igor-Tselkovskiy
commented
3 years ago The fund will not move (not now at least), it is not possible to find out whether there were red blocks in a year or not, since they can be forged Then why can't you make a decentralized staking service for all nodes? I will explain
I want to stake at a rate of 5%, but they are different for all participants from 1 to 10% (mostly) And so I stake 66,000 at 5% commission to Gareth. Where 30% (19800) is issued as a delegation to Gareth, the remaining 70% (46200) is divided equally into the remaining nodes, which were registered as gfm or staking services. at the moment there are 308 of them - 150 tokens each. Each epoch, all nodes (more precisely, the built-in bot in the protocol) will calculate the profit from staking, so the gareta node must pay according to Brandon's formula, according to the distributed received amount of staking of 30% minus the commission 5%, the rest according to 150 tokens minus the commission 5%, regardless of the rate they set (here you can still think) Since a lot of calculations are happening then. Record data for steaks by eras. Each epoch is recorded information from staking, you can only the last two and constantly overwrite them - indicating the slot where the block was created. Epoch Reward Slot Amount New Balance Percent Change APR 152 66096000 ◎ 2.805875294 ◎ 2512.358484964 0.11% 13.27% 151 65664000 ◎ 3.190714218 ◎ 2509.552609670 0.13% 15.11% 150 65232000 ◎ 3.829171599 ◎ 2506.361895452 0.15% 18.16%
This solves the following problems 1 - The problems of delegating the majority of users to one service or person are solved, since the balance will be divided into other participants - validators. 2 - % of winning blocks will be increased for all, depending on the balance, more equal chances for all 3 - People do not need to worry and calculate the number of points that they should receive every month and worry about choosing the majority and re-choosing who to stake their tokens so as not to lose them. Staking involves entrusting the management of funds to this person and not worry about them while any payments come. As soon as the payments stop, you can redefine the choice.
The only thing that needs to be calculated is whether the brandon coefficient will be higher than 1 in this way, and at what moment it will be lower. Everything should be done on full automation, without the participation of metrics - only records in the main chain, which can always be obtained.
bkase
commented
3 years ago Thank you everyone for more thoughtful responses -- if it's alright, I'll respond again to everything on Monday 👍
dewrin
commented
3 years ago Previously I chose to delegate, if this is how I will run the node myself. after all, should we be punished / lost 66k tokens without the owner's fault. should be punished for the disadvantage?
bkase
commented
3 years ago Again, this is really great feedback, thank you! Here's another perspective for you to consider:
The reason why we created the Genesis program is to ensure the protocol is decentralized and secure from day one, and to offer committed participants a starting point for their BP; to our knowledge no other blockchain network has provided such large token grants to participants. And these grants were given to increase decentralization at network launch. The tokens are not a gift, and it's in everyone's best interest that these token grants are actively taking part in consensus so that they can help the network. Tokens must produce blocks or delegate to maximize decentralization. Not enforcing the terms here would pose a danger to decentralization as a big chunk of tokens could end up not being utilized.
There was some talk regarding other ways we could enforce the contract — we believe this process as outlined above is the best way to enforce it. This approach allows us to involve the community and not rely on alternative enforcement mechanisms. Yes, our network isn't able to use a smart contract to enforce this at Mainnet launch, but even if we could: Isn't this approach preferable to relying on a smart contract that O(1) Labs would have "godmode" admin rights on? Smart contracts typically have backdoors so that they are upgradable in the case of an error, and we're suggesting a policy to be performed at a hard fork. It's worth remembering that the Foundation isn't the one enforcing this during hardfork — in fact, the Foundation is delegating their voting power. The hardfork just means we're putting it up for a vote, and the Foundation isn't voting themselves, you all are, this gives more power to the community.
My understanding is that the Foundation will provide details on how this works and how to register in the next week or so.
yourbuddyconner
commented
3 years ago I think this clarifies things wonderfully, thanks @bkase!
Madbustazz
commented
3 years ago All clear thank you!
bkase
commented
3 years ago Thanks for the feedback and discussion everyone! I'm closing this and we'll come out with official comms on this soon!
yourbuddyconner
commented
2 years ago This issue has been mentioned on MinaResearch. There might be relevant details there:
Changelog:
===
Background
According to the terms of the Genesis Founding Member agreement, you must be participating in the network with your stake (either staking or delegating). The following is a procedure for enforcing participation.
Spirit
The spirit of this mechanism of enforcement is to incentivize GFMs in this agreement to participate to help the network stay decentralized. We do not want GFMs to lose unvested assets unfairly. As such, we choose to be careful with the threshold for getting your tokens revoked. It is also very important we don't disincentivize GFMs to run their own block producing nodes.
We also strongly recommend GFMs who are producing blocks to opt-in to the foundation delegation program. If you perform better than your peers, you will receive a large delegation from the foundation or O(1) treasuries and keep 5% of the earnings from that delegation -- which in turn will enable you to earn more tokens and produce blocks more often.
Process
At every planned hard fork, which will be at least six months apart for the first four years of the network's execution (starting 11 months in); we observe archive data specifying the staking ledgers and blocks over the last 11 months (anchored around a block at most 12 blocks back from the tip, for ensuring canonicity). If you are running a block producer, you must have at least one block on the canonical chain over this period. If you are delegating, the account you are delegating towards must produce blocks in proportion to the amount of stake being used. Those who are at risk of not meeting this requirement will be warned at least every month (after at least 6months of data) via an email from the Mina Foundation.
If you do not meet this requirement, your tokens will be burned in the following manner: The "amount" field will be changed to zero and all vesting-related timing info will be stripped from the account. This is a good mechanism because it makes consensus slightly more efficient by removing these non-participatory tokens from circulation entirely.
The rest of this document proposes why one block in 11 months is a good, safe, fair metric for block producers and provides more detail around the delegation rules. In addition, we mention tooling that will be built to support this process.
The Block production rule
Block production is probabilistic. We don't know for sure who will win which slots or whose blocks will make it on the canonical chain. The probabilistic nature means choosing the "average" as a cut-off point is not ideal; this means around half of block producers won't meet the cut-off, even if they were performing perfectly.
Since there are more than 600 genesis members, we want to be as confident as possible that we won't have any unfair forfeitures. See some computations below (note: 12 months Math is shown in the screenshot):
via https://keisan.casio.com/exec/system/1180573198
With 66k MINA tokens, over 11 months of data at the current network protocol constants, there is a 99.98% probability that someone operating their node properly will produce a block on the canonical chain. This means that there is an overwhelming probability you will create a block in that time. This also means that the longer your node is offline, the higher the likelihood your tokens will be forfeited.
The delegation rule
Many GFMs are choosing to delegate rather than produce blocks themselves. In order to ensure the network remains decentralized (ie. we don't want to incentivize all GFMs to delegate to the same account), we want to avoid scenarios such as a flat rate for delegations, as more stake delegated means more blocks.
The metric is instead the following:
For every slot a GFM is delegating to an account, each GFM receives (their stake / total stake) points. Over 11 months, the points must sum over 1 to prevent forfeiture. This also applies to GFMs who are being delegated to by other accounts -- you'll note that this is the same as the block production rule if there is only one account delegating (aka you have a self Hot/Cold setup)
Here are a few examples:
Why is this a good metric: It scales with participation fairly. For example, if two GFMs pool their stake, then they need to make two blocks. It also scales with time delegated; if someone only delegates for a bit, but not when a block is produced, then the scaling factor makes sure that their stake didn't count and everyone gets more points. Delegation smooths out the variance so you pay a fee for the privilege of less variance.
Note 1: We cannot use the winnerAccount field to fairly measure this metric as when there is more than one winner, it would be economically disadvantageous for a block producer to select the resulting one randomly. They should pick the "better" VRF result. (The current implementation just does "first winner").
Tooling
O(1) Labs will provide tooling that consumes a PostgreSQL archive database and staking ledger JSON dump files over a time period of 11 months (or fewer for warning purposes). It will implement the logic stated above and can be used for warning and at the official hardforks.