clet.xyz

The recent release of Cronos v1.8 marks a significant architectural shift, embedding its Block-STM parallel transaction executor directly into the Cosmos SDK’s core transaction runner. While initial reports highlighted this integration, the practical implications for network operators, validators, and decentralized application (DApp) developers are more nuanced than a simple "plug-and-play" upgrade. Crucially, parallel execution remains an opt-in feature, and specific configuration settings must be managed diligently to avoid potential node instability or consensus issues. This strategic move by the Cronos team signals a long-term commitment to enhancing network throughput and scalability, aligning with the broader industry trend towards more efficient blockchain processing.

Understanding Parallel Execution in Blockchain Context

To fully grasp the significance of Cronos v1.8, it is essential to understand the concept of parallel transaction execution. Most traditional blockchains, including early iterations of Ethereum and many Cosmos SDK chains, process transactions sequentially. This means transactions are executed one after another, even if they operate on entirely different parts of the blockchain state. While straightforward to implement and secure, sequential execution inherently limits throughput (transactions per second, TPS), creating bottlenecks as network demand grows.

Parallel execution, on the other hand, allows multiple independent transactions to be processed simultaneously. This dramatically increases the potential TPS of a blockchain. The challenge lies in identifying which transactions are truly independent and which might conflict by attempting to modify the same piece of data (e.g., the same account balance or smart contract storage slot). Block-STM (Software Transactional Memory for Blockchains) is a sophisticated optimistic concurrency control mechanism designed to tackle this. It optimistically executes transactions in parallel, and if conflicts are detected, the conflicting transactions are re-executed until a consistent state is achieved. This approach aims to maximize parallelism while maintaining the deterministic and secure properties of a blockchain. Block-STM variants have gained traction in other high-performance blockchains like Aptos and Sui, underscoring its potential for significant performance gains.

Cronos’ Evolution Towards Enhanced Scalability

Cronos, an EVM-compatible blockchain built on the Cosmos SDK and Ethermint, has consistently aimed to provide a high-performance environment for DApps. Its journey towards parallel execution has been incremental. In previous versions, specifically Cronos v1.7, the parallel execution engine was implemented as a separate library. This go-block-stm package was wired into Ethermint’s STMTxExecutor and had been part of Cronos since its migration to Cosmos SDK v0.50. This setup, while functional, meant that the parallelization logic was an external dependency, potentially complicating maintenance and updates, and requiring a separate reconciliation process with upstream Cosmos SDK changes.

The v1.8.1 release, officially tagged on October 26, represents a fundamental re-architecture. The standalone go-block-stm dependency has been eliminated from the module file. Instead, the Cronos node now directly calls SetBlockSTMTxRunner with txnrunner.NewSTMRunner, which is imported from github.com/cosmos/cosmos-sdk/baseapp/txnrunner—a package residing within the Cosmos SDK itself. This integration elevates the parallel engine from an add-on to an intrinsic component of the underlying framework. The v1.8.1 release operates on a customized fork of Cosmos SDK v0.54, alongside CometBFT v0.39 and go-ethereum v1.16.9, reflecting Cronos’ commitment to leveraging cutting-edge blockchain technologies.

Operational Nuances: Parallel Execution Remains Opt-In

Despite the deep integration, parallel execution is not automatically activated upon upgrading to Cronos v1.8. Node operators who upgrade without modifying their app.toml configuration will find their v1.8 node still processing transactions sequentially. The parallel engine, though present, remains dormant. This cautious approach is likely intended to ensure network stability, allowing operators to transition at their own pace and thoroughly test the new configuration in their specific environments.

To enable Block-STM, operators must explicitly set block-executor = "block-stm" within the [evm] section of their app.toml file. The migration guide clearly states, "block-stm" for parallel execution; "sequential" is the default. This distinction is crucial, as failing to adjust this setting means foregoing the very performance enhancements the upgrade promises.

The recommended configuration for optimal performance and stability, applicable to validators, public RPC nodes, and archive nodes alike, includes three specific lines in the [evm] section of app.toml:

[evm]
block-executor = "block-stm"
block-stm-workers = 0
block-stm-pre-estimate = true

Additionally, the guide advises pairing these settings with specific memiavl storage configurations:

[memiavl]
enable = true
zero-copy = true

The block-stm-workers = 0 setting is particularly noteworthy; in many systems, 0 implies an automatic or default configuration, often utilizing all available CPU cores, thereby maximizing parallel processing capabilities. The block-stm-pre-estimate = true likely enables an initial pass to estimate gas usage or identify potential conflicts, further optimizing the parallel execution process. The zero-copy = true setting for memiavl storage is also vital. While zero-copy = false might seem to offer benefits by re-enabling the SDK address cache, Block-STM inherently disables this cache (sdk.SetAddrCacheEnabled(false)) when active. Therefore, setting zero-copy = false with Block-STM running would only introduce unnecessary data copying on every latest-height read without any corresponding gain, negatively impacting performance.

Critical Configuration Pitfalls and Mitigation Strategies

The Cronos v1.7-to-v1.8 migration guide provides explicit warnings about specific configuration combinations that can lead to severe node instability, including consensus halts and app hash mismatches. These risks do not stem from the parallel engine itself but from interactions with other system settings.

One particularly hazardous combination is running sequential execution while also disabling optimistic execution. The node’s memiavl node cache is only enabled under these precise conditions: block-executor = "sequential" AND disable-optimistic-execution = true. In all other scenarios, the cache size is forcibly set to zero. The danger arises because, on this specific release, an active memiavl node cache can lead to an app hash mismatch, causing the node to fall out of consensus. This happens when CheckTx or latest-height queries read the live state tree simultaneously with a block being written to it. A stale cached value could then cause the node to compute an app hash different from the rest of the network, leading to a halt.

The guide underscores the practical risk: "Sender accounts and balances are read in CheckTx and written in almost every block, so on a busy node the overlap is likely rather than theoretical." The default settings in Cronos v1.8 mitigate this risk because optimistic execution is enabled by default. Thus, an operator who disables optimistic execution and simultaneously leaves Block-STM off (i.e., sequential execution) is creating the exact scenario warned against. For those who absolutely must operate under this specific setup, the guide advises explicitly setting cache-size = 0 to prevent the issue.

Another critical warning concerns regenerating configuration files from scratch. A newly generated app.toml in v1.8 sets mempool.max-txs = -1. If an operator then enables the new app-side mempool (type = "app" in app.toml), the node will fail to start, logging a panic: mempool.type=app is incompatible with NoOpMempool error. This highlights the importance of carefully migrating existing configurations rather than replacing them entirely, or at least meticulously reviewing newly generated files against the migration guide’s recommendations.

Impact on DApp Developers and the Ecosystem

Beyond node operators, Cronos v1.8 introduces several changes that DApp developers need to be aware of, even if they never run a node directly. These changes are largely independent of Block-STM’s parallel execution but are part of the broader v1.8 upgrade package.

• txfee-cap Enforcement: The transaction fee cap is now actively enforced. Developers must ensure their DApps and user interfaces account for this cap to prevent transaction failures, especially for complex operations that might incur higher gas costs.
• Contract and Transaction Changes at Upgrade Height: Developers should anticipate potential changes to contracts and transaction behavior precisely at the upgrade height. Thorough testing and review of existing contracts are recommended to ensure seamless operation post-upgrade.
• Pending-Transaction RPCs: The introduction of a new app-side mempool impacts how DApps monitor pending transactions. Specifically, eth_newPendingTransactionFilter and CometBFT’s /unconfirmed_txs RPC endpoints will return no data when the app-side mempool is active. Developers relying on these methods for bots, wallets, or analytics should transition to using the txpool_* methods, which remain functional. It is also crucial for DApp developers to verify which mempool type their chosen RPC provider is running.
• Per-Transaction Gas Cap: A gas cap of 16,777,216 gas has been implemented in the code. However, this cap is currently dormant and requires a separate governance proposal to be activated. DApp developers should monitor governance discussions for its potential future enforcement, as it could affect very high-computation transactions.

It’s important to reiterate that Block-STM’s parallel execution engine is designed to produce the same deterministic results as sequential execution. When transactions conflict by touching the same storage, Block-STM intelligently re-executes them, which might make them slower in specific, conflicting scenarios but does not alter the final outcome. This ensures that DApps function identically regardless of the underlying execution method, only benefiting from improved overall network throughput.

Broader Implications and Future Outlook

The direct integration of Block-STM into the Cosmos SDK’s transaction runner on Cronos v1.8 is a pivotal development for the entire Cosmos ecosystem. It positions Cronos as a leading example of how Cosmos SDK chains can achieve significant scalability improvements through sophisticated parallelization techniques.

• Enhanced Network Performance: While the exact throughput gains depend on workload and network conditions, parallel execution is designed to dramatically increase the number of transactions a blockchain can process per second. This is crucial for handling peak demand, reducing transaction latency, and supporting a growing ecosystem of DApps and users. The move signals Cronos’ ambition to compete with high-throughput Layer 1 blockchains.
• Simplified Developer Experience (for Core Developers): By moving the parallel execution engine into the SDK, maintenance and synchronization with upstream SDK updates become significantly easier. This reduces the overhead for Cronos core developers and potentially paves the way for other Cosmos SDK chains to adopt similar parallel execution capabilities more readily in the future, fostering a more scalable Cosmos landscape.
• Strengthening the Cosmos SDK: This integration demonstrates the flexibility and extensibility of the Cosmos SDK. As more advanced features like Block-STM become part of the core framework, the SDK’s appeal as a robust platform for building high-performance blockchains grows stronger.
• Future Standardization: This could set a precedent for standardized parallel execution approaches within the Cosmos ecosystem, potentially leading to more interoperable and performant interchain applications.

The v1.8.0 changelog and migration guide collectively emphasize a short checklist for builders before the upgrade, ensuring a smooth transition. The core message is clear: "built into the SDK" describes the engine’s new home, but activating its power requires deliberate configuration. For any given node, parallel execution comes online only when its operator consciously sets block-executor = "block-stm" in app.toml. This upgrade represents a significant leap forward in Cronos’ technical capabilities, promising a more efficient and scalable future for the network, provided operators and developers approach the transition with diligence and attention to detail.