It’s time for the February update from the Informal Cosmos Hub team! Last month we were busy with the v8 and v9 upgrades, as well as longer term product planning, and dealing with some small issues.
The V8 upgrade passed and went live in February. It was a smooth upgrade, with zero downtime. However, there were a number of validators that missed the upgrade and so were down for a little while afterwards. It wasn’t enough to actually lead to any downtime of the chain itself, but it did highlight some shortcomings in our process that we have now corrected.
Cosmovisor is a piece of software that validators use to automatically switch the chain to a new binary at the right time to have a successful upgrade. Many validators use Cosmovisor, but some still switch binaries manually. From v1.2.0 onwards, Cosmovisor switched how it deals with capitalization of folders where it looks for the new version of the chain. This caused issues for some validators.
Due to Cosmos Hub block times speeding up slightly during the voting period, the go-live time of v8 shifted earlier by 13 hours. This is a normal thing that can happen on any Cosmos chain. Some validators did not know about this, and so did not upgrade at the right time. All validators should check block heights to stay aware of shifting upgrade times, but to make things easier, we are proactively reaching out to validators going forward to inform them of the latest time estimates for upgrades.
Together with our partners at Hypha, who handle testnets and upgrade releases, we got the v9 release with Replicated Security up for voting, and it passed! This has been discussed extensively elsewhere, so I’ll just link to the proposal. The new code will go live around March 15th.
We are currently putting together the v10 release. We’ll update with further details on what v10 will contain as we get closer to release.
We’ve been working on the necessary code to allow equivocation (double signing etc.) evidence from consumer chains to be verified cryptographically on the Cosmos Hub. The addition of this code will allow us to remove the governance-gating of slashes from consumer chains discussed here.
Working together with the Hermes, Comet, and IBC-Go teams, we found that much of the code required to generate equivocation proofs exists already in Hermes, and much of the code required to verify them exists in IBC-Go. Hopefully this will speed implementation. We will update when we have a concrete implementation plan.
Unfortunately, there has been some spam created in the Cosmos Hub governance proposals. This has taken place in two ways: deposit period spam, and voting period spam. They are different, and I will cover them separately.
Before a proposal goes up for voting, it must first receive a deposit of 250 Atoms. This deposit will be burned if the proposal is vetoed by governance. The deposit is meant to prevent spam proposals from entering the voting period, since spam will be vetoed, costing the spammer a lot of money. In the current design of Cosmos-SDK governance, it is intended that spam proposals will stay in the deposit period and never make it into the voting period.
However, it is possible on many wallets and block explorers to see proposals that are still in the deposit period. Even though part of the intended design of governance originally was there might be spam in the deposit period, it doesn’t look good and there is a little bit more we can do to fix it. By making it so that proposals must be given a certain minimum deposit by the creator of the proposal to even enter the deposit period, we can make it more expensive to submit spam proposals, even in the deposit period. This fix was deployed on Juno and other chains.
This is a change which must be done as part of a coordinated upgrade. We already have the v9 upgrade rolling out soon, so in consultation with Notional and other core teams, we have decided not to call for an emergency upgrade just to fix the deposit period spam issue.
However, our team has worked out a way to fix the issue without a coordinated upgrade. We’ll be releasing a patch soon which can be installed by validators individually without a coordinated upgrade, and will stop the deposit period spam once all validators have installed it.
A spam proposal has recently entered the voting period. This is a completely different matter than what is discussed above. The spammer decided that it was worth paying 250 Atoms ($3000) to get this proposal into the voting period. We encourage you to vote No With Veto on this proposal, so that the spammer loses their funds.