Terra Core v0.4.1
- Terraform Labs
- November 23, 2020
- Terraform Labs is recommending a “soft fork” upgrade of Terra Core software to v0.4.1 (Columbus-4.1). This update applies to all relevant parties within the Terra ecosystem, including validators, exchanges, and service providers.
- This “soft fork” upgrade is scheduled to be executed at blockheight
Fri Jan 01 2021 09:00:00 GMT+0000 (UTC)). Official guidance for relevant parties regarding exact upgrade procedures will follow separately.
- The rationale for this intermediary update is to better support Terra smart contracts and Dapps that are scheduled to ship in 2021 :
- Core v0.4.1 now includes a new CosmWasm contract caching layer, which enhances contract read and write performance on the Terra blockchain by 100x.
- Core v0.4.1 includes a CosmWasm logging whitelist feature. This allows node operators to specify a whitelist of contracts addresses to emit logs locally, saving on disk space.
- Core v0.4.1 increases the CosmWasm
MaxContractMsgSizelimitation from 1kB to 4kB.
- Core v0.4.1 addresses a low-severity issue with the CosmWasm
stakingquerier that prevents current delegation state from being queried correctly.
Terra’s Columbus-4 network upgrade was successfully completed on October with a focus on CosmWasm smart contracts, with a few production-ready contracts already running on top of the Terra network - including Terraswap, an AMM dex contract inspired by Uniswap.
However, as we continue on building contracts that are much more complex on top of CosmWasm - including bLuna staking derivatives and Anchor money market contracts - we are increasingly facing issues with the current implementation of CosmWasm on Terra. Those issues and limitations include:
- CosmWasm currently fires
FileSystemCache.load_with_backendevery time a contract is called, which then calls Wasmer to fetch bytecode from disk directly. However, as described with CosmWasm issue #603 this is a significant performance bottleneck, even compared with interpretation-based runtimes such as
geth-evm. While a module level in-memory cache was introduced as of CosmWasm v0.12.0 (CosmWasm pull request #607) to mitigate this problem, cherry-picking is required to avoid breaking changes as Terra’s CosmWasm layer is based off v0.10.1.
MaxContractMsgSizeof 1kB is defined per contract call, which may pose a problem with larger contract calls such as interchain asset transfers.
- The Wasm staking querier is initialized before the staking keeper, which results in staking-related state queries always returning nil (Terra Core issue #428).
The primary focus with Terra Core v0.4.1 is to address the issues mentioned above, thus significantly improving support for much more complicated contracts like bLuna and Anchor.
- CosmWasm cache update (Terra Core pull request #426): backport & cherry-pick relevant CosmWasm cache changes from CosmWasm v0.12.0. This update significantly improves CosmWasm contract reads and writes, as a separate, in-memory LRU cache layer now acts as a buffer between disk and Wasmer (thus not being required to access disk every contract execution).
- WASM logging whitelist (Terra Core pull request #413): Previously, all on-chain contract execution logs were locally saved for anyone running Terra Core node software, which was a considerably large storage overhead. This change allows node operators to specify a list of contracts they want to log, instead of storing everything on disk.
- add wasm execute msg size limit update (Terra Core pull request #433): Increase the MaxContractMsgSize parameter from 1kB to 4kB, which improves compatibility with larger contract calls (including interchain token transfer bridges).
- [Bugfix] Register wasm queriers after staking keeper initialization (Terra Core pull request #427): bLuna contracts have dependencies on delegation state queries, as they are structurally essential to redeem bLuna back to Luna. This bugfix fixes an issue with queriers being initialized before the actual staking keeper it is querying on. Initially redemption features of bLuna contracts will be disabled before this soft fork update is applied; a blockheight condition will enable this feature with the v0.4.1 update simultaneously.