Release v0.23.0

[cwgoes]

• Updated all relevant documentation (docs/)
• Updated all relevant code comments
• Wrote tests
• Updated CHANGELOG.md
• Updated cmd/gaia and examples/

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[codecov]

Codecov Report

Merging #1769 into master will decrease coverage by <.01%.
The diff coverage is 63.63%.

@@            Coverage Diff             @@
##           master    #1769      +/-   ##
==========================================
- Coverage   60.64%   60.63%   -0.01%     
==========================================
  Files         119      119              
  Lines        6906     6917      +11     
==========================================
+ Hits         4188     4194       +6     
- Misses       2479     2484       +5     
  Partials      239      239

[alexanderbez]

When will this be ready for review/release?

[cwgoes]

Waiting on a decision from governance on the testnet (whether or not to stop gaia-7001, dump state, and start gaia-7002), and the genesis block for gaia-7002.

[jackzampolin]

Looks like this release will also need to include the fix for the bug that stopped gaia-7001

[cwgoes]

Also @zmanian mentioned wanting to change proposal period and maybe other governance parameters.

[jackzampolin]

I propose we use the release checklist here #1803 for the first time here.

[cwgoes]

#1805 and #1801 both should be cherry-picked into this branch once merged.

[adrianbrink]

Since some parameters, such as liveness slashing, aren't defined in the genesis.json file, it would be great if we can make them default values within the code so that all our future testnets can be released with them.

Below is a list of proposed parameters for gaia-7002. Please comment on them and add to them. I'll keep the list in this comment up to date based on comment.

• Safety Slashing: 20%

  • somewhat more severe punishment than liveness slashing

• Safety Unbonding: 0 blocks (immediate)

  • no reason to keep them around, they can always rebond if they have fixed it

• Liveness Slashing: 10%

  • given that people have a long time to fix the issue we should punish them rather hard for liveness faults

• Livness Unbonding: 20,000/40,000

  • this provides people with 24 hours to fix their setup
  • it models a realistic scenario and allows them to practise responding to pager duty, ...

• Jail: 10 seconds

  • ideally this should be 0, but we want to test it
  • there is no reason from preventing people to come back online as quickly as possible, since we want to keep the iterations short

• Block times: 5 seconds

  • provide fast responsiveness, yet lessen the burden on new nodes syncing

[kwunyeung]

I think the jail time is too short. The revoked validator doesn't realize the jail time before he can unrevoke.

How about some other parameters like begin/complete mature time for unbond and redelegation?

Others are good!

[iammelea]

Please add more steaks to the validators more up-line, like me for example, and to others good validators for not stay in 65% 66% 67% 66%,
My plans are create another new validator fro test and delegate to this new validator, and i go to delegate to others validators if i see they are up time in good way and unboned if they are of-line, like real life practice. and i need tokens for give away if the faucet is down. thanks

[mattharrop]

I like the proposed values. I think @zmanian proposed purging validators that did not delegate any steak in gaia-7001 from genesis. I would be happy with this, or perhaps being a bit less aggressive and only purge the validators who never came online at all. With a cap of 128 validators for gaia-7002, this would leave plenty of room for non-genesis validators.

[cfl0ws]

@adrianbrink Do you have definitions for each of the parameters, especially the two types of slashing?

Based on my inferred definitions, the parameters feel like a beneficial starting point.

Additional comments/questions -

• The slashing feels relative, although it's not clear to what, e.g. 10% is "rather hard", compared to what?

• 24 hours feels fair to get a validator back online.

("Pager" duty brings back bad memories of actually carrying a pager and laptop w/dial-up connection :) )

• I'm not clear on the purpose of "jail", especially if it's so short.

• This all assumes rebonding works;)

• How does a 5s block time compare to previous testnets?

• I agree with @iammelea 's suggestion re: more steaks for "reliable" validators, to prevent getting stuck at 67%, we could set an expectation that if the network becomes stable, then those w/more steaks are expected to delegate a % of them to others.

[jackzampolin]

@mattharrop I think that is the current plan.

[KamuelBob]

Those settings look good.

@kwunyeung +1 for adding unbond & redelegate mature times.

For the 10% liveness slashing, can someone please confirm my understanding that once a validator triggers the 20000/40000, the slashing (10%) happens once as they unbond, and then when they unrevoke, the counter will be reset for a fresh 40000 blocks. I haven't had a chance to go through the code and check.

Edit: I was right. Answer discussed here:
https://forum.cosmos.network/t/slashing-logic-for-vote-signing/567/6

[kwunyeung]

@KamuelBob the 10% slashing happens when you missed 20000/40000 blocks. At the same time, your shares are unbonded and your validator will be revoked. After waiting for the jail time, you can unrevoke your validator. Your remaining shares will be bonded back.

[jaekwon]

@KamuelBob: For the 10% liveness slashing, ... once a validator triggers the 20000/40000, the slashing (10%) happens once as they unbond, and then when they unrevoke, the counter will be reset for a fresh 40000 blocks.

@kwunyeung: the 10% slashing happens when you missed 20000/40000 blocks. At the same time, your shares are unbonded and your validator will be revoked. After waiting for the jail time, you can unrevoke your validator. Your remaining shares will be bonded back.

Maybe tomorrow afternoon PDT we can test this quickly internally by hand with reasonable (temporary-internal) parameters before we officially launch the testnet... unless there's an argument not to do so.