Release Notes Cronos Testnet v0.9.0-beta Upgrade
After the last binary upgrade blog post where we explored what the Cronos Testnet v0.7.0 upgrade entailed, the Cronos development team has worked hard to build a newer version to introduce more features to Cronos Chain. The later version of Cronos v0.8.1 upgraded the Cosmos SDK on the Cronos testnet and integrated with the IAVL v0.19 upgrade. This introduced a new index that improves performance.
As of now, some major progress has been made for v0.9.0-beta. V0.9.0-beta1 is the first beta release of the next major breaking version; V0.9.0-beta2 includes additional changes like interchain accounts retraction and swagger doc enhancement.
This Cronos Testnet v0.9.0-beta upgrade represents as a step ahead of the mainnet upgrade and opens the opportunity to introduce these new options to our community in such a way that our DApp projects and other users can explore and test out the newly developed features on the testnet first.
In this blog post, we will explore the significant upgrades and all the latest features in the new beta versions.
App DB Backend
For completeness and better UX of the node host, the team will simultaneously support both rocksdb (except arm mac binary) and goleveldb in one single binary from v0.9.0-beta onwards. This can be configured in the app.toml with the app-db-backend field.
Prioritised Mempool
V0.9.0-beta1 is based on the updated Ethermint Cosmos-SDK 0.46 which enables mempool prioritisation. The prioritised mempool brings with it useful features like canceling transactions if they cannot be processed within a designated period. The transaction priority is determined by the effective priority fee calculated by the EIP-1559 feemarket. It sorts transactions according to EIP-1559, including both ETH transactions and Cosmos transactions.
For native Cosmos SDK transactions, the gas price computed with the current fee/gas field is used as the feeCap, and the tipFeeCap needs to be provided with the ExtensionOptionDynamicFeeTx. If there are no extension options provided, the tipFeeCap defaults to max int/value.
Validators need to use the v1 mempool to enable this feature. However, the current priority mempool has a limitation in that it only processes one transaction (the SDK transaction) per sender in the new proposed block. Thus, validators may need to send a batch of ETH transactions to be able to process in the same block at the current stage. Overall V1 is a middle solution and prioritized mempool will no longer be needed by the SDK with the advent of ABCI++ when Cosmos-SDK ADR-60 is accepted.
In addition, the patch to the hermes (the rust version of IBC relayer) to support the prioritised mempool is yet to be merged. This would allow the support of custom extension options to specify max_priority_price in Ethermint dynamic fee tx. The team is working on this merger and is always taking into consideration community feedback.
Gas Refund Logic
The existing fee charging logic is calculated using gas_used * gas_price and all unused gas fees are refunded. Ever since this new proposal was made, the team has been working to control the minimum amount of gas that is charged. This should be proportional to the GasLimit of the transaction. The main point of this is that if the actual gas used is far from the transaction’s gas limit, the unused gas is partially refunded rather than in full.
Therefore, a new gas refund logic has been implemented in this update. A minimum gas charge is now in place and set to 50% of the gas limit. With this new gas refund logic, more fees are charged when the unrealistic gas limit is set for a specific transaction. And the overall transactions in a block are less likely to be rejected.
For instance, if the gas limit is set to 100, while only 1 is used, 99 is refunded based on the current gas mechanism. The new gas refund logic requires a minimum charge of 50. Therefore, if the gas limit is set at 100 and only 30 is used, 50 will be refunded instead of 70. That’s because the minimum gas charge is 50. However, if more than 50 is used, the gas refund logic remains unchanged. For example, if the gas limit is 100 and 60 is used, 40 will be refunded.
This deters users from creating large numbers of transactions with high gas limits, as it increases the cost of transaction spamming with high gas limits, which lowers the block utilisation rate. Also, this new gas logic increases the actual cost of producing the transaction congestion because of the minimum gas charge. As mentioned above, overall block utilization is improved and the new transactions in a block are less likely to be rejected under this gas logic.
Custom Tx Indexer
In order to save disk space for the full nodes, a custom Ethereum tx indexer has been implemented. The full nodes will need to enable it in app.toml with the json-rpc.enable-indexer field. The existing node will also need to run the command cronosd index-eth-tx to manually index the legacy blocks, which helps avoid resyncing from scratch. We recommend that developers check if json rpc can still run normally after enabling the new custom tx indexer.
IBC Incentivisation
The final update we would like to share is the upcoming changes on IBC incentivisation. Currently, when the sender initiates an IBC transfer, they only need to pay for the gas fee on the blockchain that they are using but not for the receiver side as the second set of gas fees are paid for by relayers. The new update offers an option for the sender to set a gas fee for the relayer. The relayer can optionally choose to receive the fee when the transfer is successfully performed. This incoming update is supported on the chain but not on the relayer yet.
What’s Next
We are looking forward to seeing how these major changes on the v0.9.0 upgrade would benefit the Cronos chain and our ecosystem as well as your feedback on it!
If you would like to share your thoughts or any questions about the Cronos chain and this upgrade, please reach out to us via the #cronos-testnet channel on the Cronos & Crypto.org Discord server or by email to contact@cronoslabs.org.
