INITIAL PROPOSAL: Crypto.org Chain v4 network upgrade

[lezzokafka]

Authors and Credit

Crypto.org Chain Team and Community

Status

DRAFT

Proposal

Dear community members,

We are thrilled to announce the proposal for the next major upgrade of the Crypto.org chain to v4,
v4.2.1 chain-main which has been released recently.

This proposes a network upgrade for the Crypto.org Chain crypto-org-chain-mainnet-1. This implies that validators and full nodes must upgrade their chain-maind binary from the current v3.3.9. to the latest v4 binary at a specific block height if the network upgrade proposal is passed, which is v4.2.1 at the time of writing.

The tentatively scheduled date for this upgrade will be 7th February 2023.

This major upgrade contains the most recent developments on the Crypto.org Chain, including interchain accounts, IBC fees to incentivize relayers, NFT transfers via IBC, and x/group. Interchain Accounts are the main support feature, enabling cross-chain account management via IBC.

This new binary v4.2.1 also contains the following module updates: Cosmos SDK 0.46.7, ibc-go 5.1.0, go 1.19.4 and Tendermint 0.34.24.

Additionally, we propose to set the minimum validator commission for delegation to 5% in order for validators to sustain running their infrastructure in the long-term, as opposed to now there is no minimum commission and a lot of "gamification" is possible by validators. This parameter update is included in this software upgrade and will be effective at the point of the upgrade.

What is this upgrade about?

Interchain Accounts
Interchain Accounts implements the ICS-27 protocol on the Cosmos SDK, simplifying the process of handling ICS standards for IBC transactions. The key feature of Interchain Accounts is that it enables cross-chain account management built on IBC. It allows one chain to create new interchain accounts on other chains, relay transactions to these interchain accounts, and submit them to the target blockchain. Hence it allows controlling the accounts via IBC transactions. You can learn more on the Cosmos Interchain Accounts page.

NFT transfer module
The NFT transfer module allows users to transfer NFT’s via IBC using ICS-721. This application layer standard describes a protocol for transferring non-fungible tokens between chains connected with IBC, which preserves asset non-fungibility, & asset ownership limits the impact of Byzantine faults and requires no additional permissions.

IBC Fee middleware
We integrated IBC Fee middleware for incentivising relayers for IBC transfers. The Fee Middleware module is designed to allow ICS29 fee payments in this. It is built with the assumption that sender chains are the source of incentives. The Fee Middleware module enables addresses to be registered with each party involved in relaying the packet on the source chain. The fees will be paid to each party at the end of each packet lifecycle.

Cosmos SDK 0.46

• Support for the x/group module

The simplification of keys and fee management started in 0.43 with x/feegrant and x/authz is now finished in 0.46 with the new module x/group. x/group provides the functionality to define on-chain groups of people that can execute arbitrary messages based on agreed-upon rules. A simple use case is on-chain multisigs, and x/group can also be used to build more complex DAOs.

• Message-based governance proposals

To align x/gov and x/group, this release introduces a new protobuf format cosmos.gov.v1. Instead of defining gov router proposal handlers, the v0.46 gov execution model will be based on SDK.Msg. Generally, a sender’s signature is required when executing messages through a transaction. Now one can directly initiate a governance proposal with the message directly executed by the gov module itself, as long as the voting is passed for that specific proposal. The messages become a list of sdk. Msg that will be executed if the proposal passes.

Other than the major updates above, there is the deprecation of the x/supply module, including its CLI and gRPC. Finally, security changes were implemented, including swagger UI security fixes and an upgraded CodeQL scanning pipeline. A detailed changelog of Cosmos SDK can be found here.

Minimum commission rate
After discussions held on Github and the discord validator channel amongst the validators, there is a consensus for a minimum commission rate. With this minimum fee, we can prevent further gamification of the zero commissions rate, causing honest validators to fall out of the top 100 active validator set. Setting a minimum commission fee will also help further decentralize the voting power, support validator long-term economic stability, maintain infrastructure quality, and reduce validator churn.

According to our calculations, considering the current state of validators and delegators reward distribution, a minimum commission will entail approximately a ~3% reward redistribution from delegators to validators. This means:

For delegators, change from the current 94% -> 91%
For validators, vary from the current 5.8% -> 8.6% (see footnote 1)

For example, assuming the staking APY is 10.88% and you delegated to a 0% commission validator. Now when the minimum commission becomes 5%, the new APY will become approximately 10.88% * 0.95 = 10.34%

Next step

After further discussion and suggestion to this proposal, an on-chain network upgrade governance proposal will be raised, and the following items summarize the voting options and what it means for the proposal:

YES: You approve the upgrade proposal to continue with the upgrade to v4.2.1
NO: You disapprove of the proposal in its current form. Feel free to give feedback and suggestions on how to improve the proposal.
NO (VETO): You veto the entire motivation for the proposal, are strongly opposed to its implementation, and will exit the network if passed. You are signaling the proposers should not create a follow-up proposal.
ABSTAIN: You are impartial to the outcome of the proposal.

Conclusion

This upgrade brings important improvements to the Crypto.org chain, such as Interchain accounts, NFT transfer module, IBC fee middleware, key component upgrades, and a minimum commission rate parameter change to support the long-term development and quality of our validator infrastructure.

We would love to hear from you! You are welcome to leave comments here in this post.

---

References:

https://github.com/crypto-org-chain/chain-main/releases/tag/v4.2.1
https://github.com/cosmos/cosmos-sdk/releases/tag/v0.46.0
https://github.com/cosmos/cosmos-sdk/blob/release/v0.46.x/CHANGELOG.md
#861

Special thanks to @zkaizhi 's contribution to drafting this proposal

Footnote

1. Calculation 1. Calculate the current APY for the top 100 validators. 2,. According to their current commission fee, calculate the % rewards delegator and % rewards validator 3. Now re-calculate but adjust the commission fee with a min of 5%, which only impacts those with a lower commission fee. The minimum commission of 5% aligns with what other chains in the Cosmos ecosystem, such as Juno, Evmos, and Osmosis have set.

[Terra854]

It looks good so far. Just one thing I would like to add on to the proposal, I would like it to ask all validators to reduce the timeout configs in config.toml so that everyone is using the new timings. That way, we can reduce the blocktimes further towards the targeted 5s.

# How long we wait for a proposal block before prevoting nil
timeout_propose = "3s"
# How much timeout_propose increases with each round
timeout_propose_delta = "500ms"
# How long we wait after receiving +2/3 prevotes for “anything” (ie. not a sing>
timeout_prevote = "1s"
# How much the timeout_prevote increases with each round
timeout_prevote_delta = "500ms"
# How long we wait after receiving +2/3 precommits for “anything” (ie. not a si>
timeout_precommit = "1s"
# How much the timeout_precommit increases with each round
timeout_precommit_delta = "500ms"
# How long we wait after committing a block, before starting on the new
# height (this gives us a chance to receive some more precommits, even
# though we already have +2/3).
timeout_commit = "3s"

The config changes will take effect on the next chain-maind start which will be during the upgrade at the latest

[zkaizhi]

A short update on the upcoming chain v4 upgrade.

• A new tentatively proposed upgrade date is scheduled for 22nd February 2023.

• As there was a mandatory ibc-go version upgrade, the Crypto.org chain will need to be upgraded to ibc-go v5.2.0, which is now included in release v4.2.2.

• However as this ibc-go v5.2.0 included a breaking change on the previous version of the dry-run network, we needed to perform some additional testing on an upgraded croeseid dry-run network to make sure IBC transfers will behave as expected before being able to upgrade to v4.2.2.