Dear Cosmonauts,

DRUMROLL PLEASE

The development of Cosmos has been — this is an understatement — delayed due to pioneering a highly ambitious task: launch a production-ready pure Proof-of-Stake network with delegation, bonding, and slashing conditions while maintaining the highest degree of decentralization and security in tandem with simulating PoW scarcity and economic incentives, all in-protocol. Phew, that was a mouthful.

We call this class of PoS, Bonded Proof-of-Stake — or BPoS — where BPoS is distinct from, significantly more difficult to implement than, and offers a much higher degree of security than PoS protocols that leverage masternodes as well as DPoS protocols that leverage reputation-as-stake.

The following community update for the month of October describes the Cosmos Network development cycle having reached critical mass. The release of the highly-anticipated Cosmos-SDK v0.25.0 marks a significant milestone along the Cosmos Network roadmap. If you have questions as a validator or as a developer, the information contained in this update might be useful to you.

It can’t be emphasized enough. The v0.25 release that you have been waiting for is a Really Big Deal. And it was worth the wait. It took us 9 weeks of work to finally push this release out, taking up weeks of refactoring, bug fixes, upstream patches from Tendermint Core, and adding features which complete the desired feature set for mainnet release candidate software. The final move before we cut an RC0 is to test the cryptoeconomic layer via the incentivized adversarial testnet à la Game of Stakes. It’s not an exaggeration when people say that what we’re building at Cosmos takes a Herculean amount of effort, diligence, and discipline to deploy.

And today’s the date. It’s showtime, baby.

Note that the Tendermint Bug Bounty Program is still underway and it’s not too late to contribute. Game of Stakes updates are posted on this thread.

Without further ado, the feature-complete software and the associated public testnet you’ve been waiting for have been launched.

Dev Update: Cosmos SDK v0.25.0

Note that we are now on SDK v0.26.0. However, the major feature additions were made on v0.25.0. The following update contextualizes, from bottom to top, the major PRs broken out in Issue #2220: SDK 0.25 / Gaia-9000 Release Checklist.

Debug faults caught in simulation (#2224, #2225)

Summary: We ended up refactoring a lot of the staking logic such that validator updates are applied only at the end of each block. So, as transactions are being run throughout a block, validators might gain/lose delegators and their voting power would change accordingly. But at the EndBlock handler in gaia , we do one iteration, find out the top 100 validators, ensure they’re in the bonded set, which we then pass back to Tendermint.

This removed a lot of the complex optimization logic. You might remember the concept of a “cliff validator”, which caused a lot of bugs. We’ve gotten rid of that. That ended up fixing the faults caught in the simulation framework, which both were related to the cliff validator bug.

EndBlock : EndBlock just means, after all the transactions in a block have executed and applied whatever state changes they were going to apply — or fail — we can perform auxiliary things. Examples of what we might do at EndBlock are: pay inflation, pay the bonded stakers for inflation, or figure out what the Tendermint validator updates need to be, etc.

: just means, after all the transactions in a block have executed and applied whatever state changes they were going to apply — or fail — we can perform auxiliary things. Examples of what we might do at are: pay inflation, pay the bonded stakers for inflation, or figure out what the Tendermint validator updates need to be, etc. Efficiency gains from EndBlock : The main gain doing an EndBlock is that because we know this only happens once per block, we could do things that are less efficient but are simpler. So in this case, we can iterate over 100 validators to determine what to be bonded. We don’t want to do that every transaction because then if there are 50 transactions, we have to iterate over 5000 validators. But it’s okay to do it once per block because we know what the overhead would be: O(1).

Upstream Tendermint Updates

Slashing changes for NextValSet ( #2255 )

Update to Tendermint 0.24 (#2219)

Summary: Tendermint v0.24.0 introduced a concept called NextValSet which delays the application of the updates that the ABCI app sends the SDK through the actual signing validator set by one block. This makes light client syncing safe despite arbitrary validator set changes, because the next validator set is not just implicit, but explicitly signed into the block header as the NextValSet . On the other hand, this delays the validator set updates by one extra block. Because of that, we need to make sure we track slashing periods and unbonding, delegations, and redelegations correctly so that we only slash someone if and only if their voting power contributed to the infraction.

Debug simulation invariant failure (#2162)

TL;DR — The inflation target will be updated once every hour.

Simple flat fee set in config.toml (#1861)

Summary: Previously, we did not have any spam prevention. Anyone can submit transactions with zero fees and validators would just accept them. This was suboptimal. For GoS, we’ve implemented the ability for anyone voting — such as validators or full nodes — to set a minimum fee in their configurations. They will reject any transactions on the p2p layer which do not pay at least that fee.

Transaction simulation, split generate/sign/broadcast (#2204)

Summary: This gives you the ability to use gaia-cli to separately construct, sign, and broadcast transactions. This is useful for many cases. One such case is multi-signatures. If you want to use a multi-sig wallet — which will be supported at launch — to sign a transaction with your friend, you first have to generate the JSON “document” file that you’re going to sign. And you might send that JSON file to a friend. They would download gaia-cli , use their computer to sign it, you two would send each other signatures and then one person would broadcast the transaction of those signatures. This is user-level tooling.

Fee Distribution Module

Piggy bank fee distribution spec ( #1944 )

Piggy bank implementation ( @rigelrozanski ) #2236

Inflation distribution & commission (@rigelrozanski) #2527

Summary: Fee distribution is the set of two modules — distribution and minting — which are responsible for calculating inflation, fees, and most importantly, fee distribution to delegators and validators in proportion to their stake.

This SDK release is the first in-band fee distribution system in the market. It demonstrates a key feature that distinguishes the Cosmos SDK as the most sophisticated framework for building application-specific blockchains (i.e. dAppchains) out there. Meanwhile, it still provides the same flexibility, ease-of-use, and interoperability as you would experience writing smart contract logic hosted on a public, general-purpose blockchain.

Slashing period spec & implementation (#2001 , #2122)

Summary: The slashing period is a concept we are introducing this release, designed to mitigate the effect of successive (arguably redundant) infractions. Getting the incentives and disincentives for malicious behavior is a tricky balancing act. We’re balancing between punishing stakers harshly for endangering network security, and being lenient with stakers for accidental misconfigurations.

Slashing period: a slashing period is the period of time between the moment a validator is bonded until the moment it is unbonded.

Let’s say you misconfigured your HSM on Tendermint and you started double signing every single block. Or maybe your validator consensus signing key is leaked and abused by a hacker. Without the notion of a slashing period, you would have gotten slashed for potentially every single infraction. Each double signing incurs fairly substantial penalties which, added up, could lead to all of your stake getting depleted to zero. Now instead, you only get slashed for the worst infraction within a slashing period.

Validator unbonding state (#2163)

Summary: We track 3 states that a validator can be in with regards to bonding:

A validator can either be bonded where they are in the 100 validator set voting on blocks. They can be unbonded where they are not in the validator set and where they have not been bonded in the past 3 weeks. Or, They can be unbonding, where they are not currently in the validator set but they have recently been in it within the past 3 weeks. Which means, they are still liable for some infractions they might’ve committed but have not yet been discovered.

Summary: When you re-delegate (i.e. change your delegation from one validator to another), the protocol still needs to hold you accountable for things your old validator signed (for up to three weeks in the past). And it needs to keep some data or record in the store so that we can look it up to see if you’re liable if an infraction is discovered. At the end of the three weeks, if no infractions have been found, your re-delegation unbonding period is over, and so the protocol will delete the record.

Summary: Previously, we required a second transaction to complete a re-delegation or an unbonding. This was necessary to clean up records in the store we no longer needed and, in case of unbonding, to receive coins. We got rid of that in favor of an automatic queue.

So now, at the end of an unbonding period, your coins will automatically be released to your account, and re-delegation records will be automatically deleted. We now also automatically remove validators when they are done unbonding.

GenTx -> StdTx refactor (@alessio) #2422

Summary: The validator set is determined by bonding transactions that are included in the genesis file. This is important because the staking token distribution isn’t sufficient to determine the validator set — not all staking token holders will be running validators. Also, if some people who didn’t happen to contribute to the fundraiser still want to run a validator at genesis, they can find delegators to bond to their validators.

Other Software Updates

Newest light client software (Gaia Lite) changes

Associated Issue #2113: Implement Gaia-lite LCD spec

Ledger wallet integrates Cosmos in dev mode

Key Management Service release

The key management integration with Tendermint will enable validators to use YubiHSM2 or Ledger Nano as HSM devices for validator signing.