@Spaydh hi, any update on that matter?
can you share explorer link, to see the validators who took part in the rehearsals?
1 Like
Update on the public rehearsal:
- Rehearsal-1 (Neutron) successfully launched
- A bug on the Provider chain led Rehearsal-1 to halt at block 779
The bug that led to the halt has been identified and replicated. It allowed an incorrect validator set to be passed from the Provider to the Consumer, leading CometBFT/Tendermint to panic.
A consumer-side patch has already been developed and will be deployed on testnet shortly. A provider-side patch will likely be needed, and may require a coordinated network upgrade.
The bug prematurely ended the tests that were being conducted on Rehearsal-1. Two additional rehearsals will therefore be organized:
- Public rehearsal: Thursday 13th of April
- Final rehearsal: Tuesday 18th of April, 4PM UTC
Every Cosmos Hub validator is warmly encouraged to participate in the final rehearsal next week to ensure consumer chain launches are as smooth and successful as possible. You may join through the Cosmos Network discord in the #replicated-security-testnet channel. Ask @lexa, @uditvira or @dante for the âICSâ and âReplicated Securityâ roles if your team does not already have it
This, unfortunately, will cause a slight delay to the proposal going on-chain. Assuming the final rehearsal is successful, the proposal should go live next week.
Huge thanks to the @HyphaCoop and Replicated Security teams at @informalinc for their rapid response and support in identifying and resolving the issue.
Replicated Security is a new, bleeding-edge technology, which should be handled with care. Every bug found on testnet makes the Hub and all consumer chains safer. Rehearsal-1 has just saved a future consumer chain from an unexpected halt.
4 Likes
Centralized entities who want NTRN are welcome to buy the tokens from community members 
4 Likes
Thank you for the update.
It is good that the bug was found. I am sure everyone appreciates why this rightly moves the timeline back.
1 Like
Iâve written a Swiss booklet for this proposal with help from @Spaydh and @uditvira. The intent is to build on the fine governance work started by Sacha Saint-Leger and address some of the common questions Iâve seen arise on the forum and elsewhere on this proposal.
6 Likes
Another rehearsal was successfully held yesterday. The bug has been been successfully crushed
5 Likes
The final rehearsal of Neutronâs launch is set to take place on Tuesday 18th of April, 4PM UTC. The proposal is expected to be submitted on-chain shortly afterwards if the rehearsal is successful.
Every Cosmos Hub validator is warmly encouraged to participate in the final rehearsal next week to ensure consumer chain launches are as smooth and successful as possible.
You may join through the Cosmos Network discord in the #replicated-security-testnet channel. Ask @lexa, @uditvira or @dante for the âICSâ and âReplicated Securityâ roles if your team does not already have it.
Announcements and important reminders will be posted in the Interchain Security announcements channel
Information for all the testnet chains is available in the testnets repository.
For newcomers to the replicated security testnet, first get some tokens from the faucet.
Then with those tokens, join the provider chain as a validator by following these instructions.
A proposal to launch Neutron on the testnet will be published with the spawn time for the rehearsal chain set to April 18, 4PM UTC. It will include details of the final binary and a partial genesis file (without âCCV stateâ, i.e., cross-chain validation state) in the testnets repository. At the spawn time, the final genesis will become available. This will also be published to the testnets repository, along with seeds and peers.
After the spawn time has been reached, validators can start their neutron binaries with the final genesis file, updated to include the final CCV state. Once blocks are being produced, a relayer between the two chains (provider and rehearsal chain) will be started by our team. Anyone else may also choose to run a relayer, but this is not required. Once the relayer is running, the correct propagation of validator set changes will be verified. Validators can themselves verify this with the neutrond q tendermint-validator-set command
If validators join earlier that day, Hypha will attempt to decentralize the stake on the testnet so that we can more closely replicated the mainnet launch event.
5 Likes
With this soft opt-out feature, several scenarios are possible depending on several variables:
-
This feature seems critical to maintain a decentralized and healthy validator set in the Cosmos Hub so thanks @jtremback. Without this feature, after several consumer chains are onboarded, many validators would likely not be able to cover these additional costs, especially in the current market conditions
-
Delegators will be receiving the rewards from consumer chains, but they will not be covering any costs to run the additional nodes. So, delegators would be happy with many consumer chains to receive more rewards, while validators need to consider the balance of costs and revenues
-
With the soft opt-out feature, it is mentioned that validators opting out from the bottom 5% of voting power would still earn a âsmall shareâ of the consumer chains rewards, however the value of this share is critical
-
If this share is the same as for validators running consumer chain nodes, then likely all validators eligible to soft opt-out would do it. The advantage is that delegators wouldnât centralize more the stake in the top 95% voting power to maximize rewards from consumer chains
-
If validators from the bottom 5% voting power decide to opt-out but then they receive significantly less consumer chain rewards than validators in the top 95% voting power, this could likely lead to further stake centralization in the top 95% voting power or forcing the bottom 5% not to opt-out anyway to avoid losing delegators chasing larger consumer chain rewards
-
These dynamics might be less obvious with the first consumer chain onboarded, but once there are several consumer chains these issues could become critical. In fact these ideas could be used to not only avoid further stake centralization but to improve the decentralization of the Cosmos Hub. Ideas were mentioned before of a variable multiplier of staking rewards, being higher for the smaller validators to encourage more staking with them. This could be implemented with consumer chain rewards, creating a scale of rewards distribution in an inversely proportional way to voting power, so delegators would be encouraged to stake with smaller validators leading to a more balanced and decentralized validator set, what do you think @jtremback @Spaydh?
To clarify: the soft-opt out as currently designed does not affect rewards distribution at all. Whether or not they opt-out, all validators will receive rewards proportional to their stake. The share is only described as âsmallâ because ~75 validators share 5% of the rewards pie.
Modifying the distribution mechanism is a powerful idea and weâve been discussing mechanisms with Informal and others, but itâs also important to realize it could have strong adverse effects.
For example, weighting revenue towards the bottom of the set could incentivize Sybil attacks (large vals/holders could break into multiple smaller validators to capture multiple spots at the bottom of the list, kicking out honest validators). This might not be too much of a concern if only the consumer chain revenue is distributed with the new method as the majority of the yield will still come from ATOM inflation early on but should still be considered carefully by the Hub Community.
2 Likes
Many thanks for the clarifications. Modifying the distribution mechanism indeed involves a lot of complexities and risks but also if done properly some potential advantages as well. Here are some thoughts:
-
Firstly, as you mention âthis might not be too much of a concern if only the consumer chain revenue is distributed with the new method as the majority of the yield will still come from ATOM inflationâ so sybil attacks would not be highly incentivized since the distribution mechanism modification would be only for a consumer chain
-
Other consumer chains may keep the current distribution mechanism so overall there could be an offsetting effect, and again not incentivizing sybil attacks
-
The modification of the distribution mechanism of a consumer chain doesnât have to be a large change, just a small multiplier to encourage decentralization and staking with the smallest validators. Such a small multiplier may have important positive effects for decentralization improvements but not so much to encourage sybil attacks
-
The current 175 Cosmos Hub active validator set is well established and it is very easy to see and detect a new sybil validator, since their governance participation would be very low, moreover it should be easy to identify whether it is an honest new validator or a sybil from one of the large Cosmos Hub validators, and actions could be taken accordingly by governance
-
Assuming this distribution mechanism modification is implemented by Neutron, then the smallest validators will attract more delegation, increase in the ranking and as they increase the multiplier reduces, so this would be like a decaying curve of new delegations as they go higher in the ranking with a lower multiplier. Then the new smallest validators will repeat this process, and so on. This could lead to a much more balanced and decentralized validator set. Then, the value proposition of RS wouldnât be just the security measured by the total value staked in the Cosmos Hub, but also the great decentralization of this stake, making 1/3 or 2/3 attacks much more complex, and hence the Cosmos Hub RS would become much more attractive to many projects
Once again, Iâm not against any of these ideas, but theyâre unrelated to the Neutron proposal. How the hub handles the fees it receives from ICS is for the hub to decide, not the consumer chains. A separate network upgrade proposals can be made to add the required logic to the Hub.
5 Likes
Hey @Cosmic_Validator , @lexa and I will soon be releasing an essay that explores the design space around this and why itâs important. Just wanted to mention it here because we can have a dedicated space on the forum to pursue this workstream & related conversation in that thread.
Thanks for your thoughtful comments here and will be looking forward to continuing the convo in there as soon as the essay is out.
2 Likes
We just published it 
I do think there are a lot of interesting possibilities in this design space, but itâs fundamentally a Hub issue as itâs about our own validator set.
3 Likes
The proposal has been submitted on-chain and is currently in the deposit stage:
https://ping.pub/cosmos/gov/792
5 Likes
The proposal has entered the voting period. If youâre ready to cast your vote, you can do so here:
Interchain Explorer by Cosmostation
Proposal #792 | Cosmos Hub | Keplr Dashboard
Ping Dashboard
Interchain Governance
4 Likes
Proposal #792 was accepted, Neutron may launch between the 8th and 21st of May (until the Hubâs light-client trust period expires).
Given that a security upgrade was conducted on the Hub today (Monday 8th), the coordinated launch time has been moved to Wednesday 10th of May.
1 Like
Pretty Proposals. Iâm very sorry for my late response. Still onboard with this project" I voted yes for this and itâs has been approved right from now.
The cosmos hub needs to adopt as many VMs as possible, Neutron was the first step in the right direction, by adopting more VMs we can only grow cosmos developer community, no other chain has such a diverse ecosystem as cosmos.