Amazing!
That’s where I’m split between a larger reward pool and a smaller one.
contracts V2 could be a good timing for that.
what do you mean? you saying we should reduce the pool size for SSV holders?
To tell the truth there are benefits for a big and fancy pool, but also to a smaller one with an option to go big and fancy in the future.
I’m leaning more into a smaller pool for now but come contracts v2 go bigger and fancier.
Running through a bunch of scenarios with the current simulator, 192k SSV is the minimum to make sense in some scenarios. Thinking about it, I’m in favor of 320k SSV and would support that. So let’s make a bold move.
Still, my only concern is that we do it ‘first time right’. I’d feel better if we do the following:
IMO, this will not delay the testnet but surely will reveal how all of our ideas work in reality, and nobody has to panic.
One thing I’m slightly concerned about is not so much about absolute numbers for the reward, etc., but instead on how much small independent operators (arguably the ones that bring infrastructural decentralization to the mix) like DAppNode users will be able to capture.
My main worry is that a linear reward function for the operators will result in splitting the pot mostly among the big operators. That means that big operators that concentrate huge amounts of validators will end up gobbling up all the rewards, resulting in valuable insights gotten from smaller but dedicated operators being “underpaid”.
That said, there’s no reason why someone holding more validators should not get paid more, but maybe we could use a logarithmic formula that gives higher rewards for the first validators and then the reward for each marginal validator added decreases. That would mean that DAppNode users only running a modest amount of validators would opt to this bigger pot for their first validators and big operators could also get rewarded for testing with more validators.
This might be a pretty good point. Maybe we shouldn’t be looking at an incentivized testnet as the one shot before mainnet launch, since as of today there are a few fixes and improvements that need to be developed before such mainnet. Forgive me if this is already been talked somewhere else - but I agree that in order to keep testers engaged we could do a program now, but we shouldn’t discard the possibility of doing another incentivized test when the product is feature complete.
I agree with that. @fod @arielzimroni we should change the spec to that IMO
TLDR: I think we’re conflicted about the objectives of this, and with agreed upon objectives, these decisions about the details will probably become very clear. Smaller rewards would show appreciation to the existing community, and I think they would go a long way to motivate participants to keep the testnet robust, maybe with some small growth as a bonus. Larger rewards would do all that plus be a “marketing initiative” with the goal of spreading awareness of the project and growing the community. I favor the latter, but that’s just my opinion, and I will support whatever the community decides.
–At lower rewards, I think the SSV holder pool won’t really accomplish anything, since for most (smaller) holders, the rewards probably aren’t even enough to incentivize moving SSV from an exchange to a wallet, let alone buying as a new user. The likely effect of this simply becomes throwing the already active community members a few more SSV. That’s fine, and I’m sure we’d all appreciate those rewards. But if the intention of this is to encourage new users to join in and maybe buy SSV, then I think the larger reward is needed. With smaller rewards, I’d question why we have the SSV holder pool at all… although I guess it serves as a good abuse prevention mechanism.
–Therefore I think we need to answer “Do we want this to serve as a major marketing effort right now?” If the answer to that is “no”, then keeping rewards small is probably the way to go. But if the answer is “yes”, then I think larger rewards are necessary (at least for the validators/SSV holders pool… operators have different economics).
In my opinion, now is the right time to start marketing (I prefer a constant push until launch). There’s probably much more to say about marketing and general strategy and such… But currently, few people in crypto seem to be aware of this project, even fewer understand the value of it (the typical reaction I see is negative), and our community is still on the small side. I also believe community growth is very important for this project, especially since the ETH world has not yet decided that SSV/DVT is the favored staking standard, and since SSV is open-source and we’ll probably need to compete against copycats in the future (a robust community will be our main protection). In addition, I think community growth is a feedback loop, so growing the community now will help us later (e.g. more people talking about SSV, more people contributing/building, better image/reputation, etc.).
–Trying to play devil’s advocate: If we agree that using this for marketing is a good idea, then what’s the advantage of postponing?.. Maybe we feel unprepared now in regards to the early state of the testnet or our current lack of marketing materials, and we would fail to capitalize on this as well as we could in a couple of months? It seems like we do feel a bit unprepared, so I understand the desire to do a couple of months with smaller rewards first. I’m expecting an explosion of questions and noise. And our marketing materials are currently lacking. But I think this is ok. The community can handle most of the noise, and the marketing content seems to be around the corner. The testnet itself still has a few quirks that will frustrate and confuse some people, but I think that will be a constant throughout development as changes are made. I think we have the essential features finished. And I think the rewards program design (with the addition of the logarithmic function applied to operators) seems solid, even if it’s not optimal. With that said, postponing to get more prepared seems ok too, but then I think it’s important to ask what needs to be finished to feel more prepared. Sounds like we would wait until V2? (consider your estimate of that schedule) It’s not too hard to justify waiting 1-2 months, but I have a much harder time if it is more likely to be 3-4+ months… to me that would seem like a wasted opportunity.
And maybe looking at this as THE marketing initiative of the upcoming months is the wrong perspective? Marketing can be done in many ways, and we could use other approaches instead. But so far, we’ve had a hard time spreading the word and gaining acceptance. Without another plan, I think the testnet still seems like the best approach. But also… I’m just an engineer with no prior experience in marketing or community development 
–As suggested in a few variations, if it would make everyone feel better to have a trial/preparation period, a decent alternative might be to declare the larger reward program but prepend a smaller rewards for the first month (16k SSV for the first month, 320k for the following four months). That would give us time to assess and make adjustments if needed, without the stakes being so high.
I agree with that. @fod @arielzimroni we should change the spec to that IMO
Definitely! I completely agree with this.
I think we are all in agreement about:
Question is, should we do it now or in 2 months say?
I was thinking about staying with 64K but make it for 2 months, during those 2 months we will asses and make a longer term program which will take us through mainnet and beyond (a robust testnet is needed after mainnet, especially after). Say additional 600K SSV until year end (or something along those lines)
WYT?
I feel like a ton of discussion is happening around creating and optimizing the rewards structure. But not a lot going into the other pieces that create this relationship or feedback loop from the validator side of things.
Having gone through this process in August/Sept when the alpha tool was first released, I can say that registering validators (not 10 min of work for non-technical users btw, esp now if you have to initiate holding SSV) for the testnet, only to have them (5 out of 5, all with “verified” operators including @Voss-DAppNode) be slashed and exited, was fairly annoying and led to me not registering any more or following the discussions. There was essentially no way to add value.
At that point in time there was no feedback loop or relationship - to evaluate operator performance, communicate with operators, any visibility into the network, or a way for validators to discuss operators amongst themselves. So, fine, it’s alpha - forgivable. But how about now?
On the community call, I heard more of the same, discussion of rewards distribution and bad actors and modeling things optimally. But only one sentence of “Oh the explorer will have a performance score for every operator.” ???
As a validator the things I care about still seem to be lacking or missing: evaluating operator performance in an efficient and multi-factor way (see cardano pools for examples: cardanoscan.io, adapools.org), comparing multiple operators on basic metrics, the ability to quickly change operators, the ability to communicate with operators, the ability to crowdsource information quickly from other validators (how I found Blox in the first place was on Reddit), risk-less staking (if my chosen set of operators bites the dust, my validator is slashed and exited? if you want retail users to be interested, why is there no fail-safe?). Unless you’re saying these are already solved in the explorer, but just invisible to current users?
I’m very confused about how the current tool set available to a validator - the current explorer, Discord, and the dao - would enable someone to effectively navigate this “relationship” with operators and manage a validator with any real purpose.
I support that. 2 months (or until V2?) at the 64k rate (16k per month), with the expectation of a larger and longer-term testnet with rewards close to the 320k rate (80k per month) following the first phase.
I support it too Having testnet incentives last into and beyond mainnet from the get-go sounds like a good idea.
Agree with you, the initial lack of slashing protection was quite frustrating to watch validators get slashed. You had terrible luck to get 100% of your validators slashed! But as you note, forgivable for alpha. And Alon wrote a medium article to assure people that the issue was not fundamental to SSV design. Thankfully that is all behind us, now that slashing protection has been included since v0.1.4 
I think what you are rightfully observing here is still the alpha stage of node operator performance metrics. I agree there could be more detailed ways to evaluate operators on performance, but the “% attended duties” metric is, for now, the early version. Even being able to easily scan/sort node operators by current performance measure would be a great add to the explorer. 0NEinfra is looking at taking on a role to create and make available to the community some helpful features to complement the current ssv explorer, e.g., a Grafana-like dashboard to sort/plot your chosen node operators’ performance over time. As is the case with most dev work, it is not quite trivial scope, but we could do this if it helps take some work off the Blox team’s plates and gives better visibility to the community.
The ability to change operators, appears to require a new smart contract and thus might be for the next version of test-net and not a possible enhancement to the current one (correct, @alonmuroch?)
Ability to communicate with operators, crowdsource information from other validators - should we be leveraging other platforms? Genuinely asking - how are the other networks doing that? Knowing which ones are preferred besides discord would be helpful input for the ambassadors to step in to help here. Of course, operator responsiveness will quickly separate the ones who can provide a reliable service from the rest.
Finally, I think the risk of an operator or all four pooping out is always there in a decentralized network but SSV/DVT is designed to prevent exactly such situations from harming the validator. As @BenAffleck shared in this thread, 2/4 operators being down causes a validator to not attest and to leak value (slowly enough to not really matter even if not corrected in a couple of days) but not get penalized (slashed = BAAAD situation from acting maliciously, but not just being off-line). Obviously, I would be pissed if that small value leak happened to my main-net validator but the loss of a few dollars would not break bank for a validator owner. I am sure SSV.network will have plenty of ways to monitor and alert us for such a situation when we are at in main net, and a switch out of the non-performing nodes would be a quick action to take then.
I think this is just a skeleton of the tool set that we will need, but my vote is to proceed as-is, even if in a limited way now. That way we continue learning and breaking things so fixes can be implemented for next the round.
I fully support this approach.
Also, very good thoughts from @h.m.23-0NEinfra, and very valid points from @captnapalm. I like this kind of constructive discussion.
Let’s make it happen now!
Thanks for your thoughts. Sounds like I’m being impatient. And yes, my vote is also to proceed fast, break stuff, etc.
My intention was more to surface the validator point of view so that the scope of that work doesn’t get lost in the technical noise or the rewards design, since the goal of the testnet is slightly more overarching.
That’s great. Is the operator software version available via the explorer? That seems like critical info to surface.
Still early days everywhere, and I only have limited experience with other chains. But I’ve seen that the competition forces operators to advertise - with websites, usually layering on additive content/articles or tools to help the community and draw interest to their operations. Usually operators sort out their own communication, over Telegram for instance. I expect at some point Blox and SSV will further separate their comms platforms when it’s appropriate, so maybe that will be enough to house bulk operator notifications and user support for a while.
Nice, sounds like a dao proposal. Maybe the emphasis over time will be for the SSV dao to approve such projects like a mini-Ethereum Foundation.
Will be switched on after contracts V2
That would be amazing to see for SSV. I think once rewards are introduced this will occur naturally.
I totally agree we need more tools, some are being developed by blox and hopefully more of them will be created by other devs.
I think the DAO should grant significant grants to that direction, I’d be happy to support it!
I like this format too