The soft opt-out feature is currently being tested - I would not be surprised if it is already going to be an option for consumer chains launching 
One thing that I want to point out to all respondents so far is that I am totally on-board with code-based solutions in the long-term! My heart lives in that ‘surveying the site’ section where we talk about code-based ideas for solving the problem over time. But no argument will convince me that the development work of designing, creating, and testing a new feature (new param, new way for a module to work, etc) is fast enough to address the issue I see with scaling up Replicated Security.
I want something short-lived and renewable if need-be: Something like a 4 month tranche controlled by a trusted multisig until we actually have the information from seeing these consumer chains in action. We can’t possibly know what things will look like until it’s active, and I do not believe we can develop a code-based solution fast enough to protect our validator set.
@gh0st - remember that the penalty for downtime on a consumer chain is jailing, not slashing! Not that this is necessarily a consolation if you are opposed to a project itself but I want to be very clear about which penalties apply to what!
Again my biais is that everything will eventually balance out by itself and we should all think about sustainability. […] I believe everything balances out by nature.
I don’t understand this perspective - if the set will eventually balance itself out, why hasn’t it? It seems like it is growing even more centralized, imo, and we see that in more traditional economies as well.
I like this alternate route you’re proposing, but I would put it more in the long-term strategy group than in the patch solution that ‘breaking ground’ is intended to be. Anything involving engineering or new features/parameters inevitably involves a spec, dev work, testing. I think this potential solution is up there with changing the UI, imposing a delegation cap, etc. All good ideas, all things that take time in which the smaller validators might no longer be around to benefit from it.
So what do we do in the meantime to tide our validator set over until we have a longer and more sustainable solution?
sounds like taking money from the ‘rich’,
It’s our community pool - it belongs to ATOM holders and we just raised the tax to provide even more resources for that pool. We can disagree about whether the raised tax was a good idea or ‘taking from the rich’ but it happened, and now we have money we are all able to suggest a use for.
I don’t think the CBI idea is ‘taking’ money from anyone at all. I’d like to use it to help the validators who keep the Hub alive to while we get the Hub’s main product offering (Replicated Security) off the ground.
@Cosmic_Validator - I don’t agree with these criteria necessarily. My hope is that CBI is specifically to benefit validators who are invested in Replicated Security and working to contribute to this feature.
A team that is not incurring the additional costs of Replicated Security (by not running consumer nodes) doesn’t need a subsidy. They are already getting consumer chain rewards without running a node. To me, this seems like a sensible either/or: You get the consumer chain rewards either way but if you run a node, the Hub helps you out with a subsidy because you’re contributing to the feature.
And I will refer to what I wrote to Ephemeral - there are tons of good longer term solutions. But good engineering takes time and we have two consumer chains looking to launch in the next few months. Engineering introduces delays as well, as we have to write specs, design a way to check all these criteria, build the feature, and thoroughly test it out. Developers are people - the dev process is just as full of delays as a multisig distribution.
But the things you’ve raised as criteria are just as easily checkable by a person as a piece of code. If I were on the multisig (which I don’t really want to be, because mutisig transactions are such a pain lol), and I put up a spreadsheet with a timestamp and say “This is when I checked all the criteria and this is what I found”. That person can check the exact same things that code checks, but the difference is that a human can already do it, whereas the code doesn’t exist yet, hasn’t been designed, hasn’t been tested, and would need to be developed and then deployed onto the Hub (which takes a long time). For something like a tranche of 4 months of CBI while we wait to see how our first consumer chains do, that seems very reasonable and low risk to me.
I don’t disagree that something like modifying the distribution module is a good idea - it’s one of the other things we proposed in the essay. But it happens on a different timeline than the community spend idea, and I think it’s important to have one fast thing while we figure out slower solutions.
@adintium - Consumer chains do have a fix on their end, it’s the soft opt-out that Neutron is already testing out. As an ATOM holder, I’m not interested in solely relying on consumer chains to solve a Hub-centric issue. We’re the ones offering Replicated Security as a product feature and I think it’s our job to make sure it’s sustainable for us. As I said - it benefits the Hub to have a healthy and diverse validator set.
Abra and I talked a lot about whether an open public competition is really the best method for strengthening the Hub’s product offering. Hopefully he’ll chime in - he had some really good thoughts on the matter.