clet.xyz

The Cronos blockchain, an EVM-compatible network built on the Cosmos SDK, has reached a significant milestone with the release of v1.8, officially tagged on October 26. This latest iteration fundamentally rearchitects how its pioneering Block-STM parallel transaction executor is integrated into the core framework. While previous versions relied on an external library, Cronos v1.8 now moves this crucial component directly into the Cosmos SDK’s own transaction runner. This integration represents a strategic advancement aimed at streamlining maintenance and enhancing the protocol’s long-term scalability trajectory. However, the update comes with a critical caveat for node operators and developers: parallel execution is not enabled by default, remaining an opt-in feature, and specific configuration settings, if improperly combined, carry the risk of halting a node or causing consensus mismatches.

Understanding Cronos and the Imperative for Scalability

To fully appreciate the significance of Cronos v1.8, it is essential to understand the underlying architecture of Cronos and the inherent challenges of blockchain scalability. Cronos serves as the Ethereum Virtual Machine (EVM) compatible chain within the Cosmos ecosystem, enabling developers to deploy Solidity smart contracts and dApps familiar to the Ethereum landscape, while leveraging the interoperability and modularity of Cosmos. It utilizes Ethermint, a robust EVM module built for the Cosmos SDK, to achieve this compatibility.

Traditional blockchains, including early iterations of Cronos and Ethereum, typically process transactions sequentially. This "one-after-another" approach, while ensuring deterministic state transitions and simplifying consensus, creates a bottleneck for transaction throughput. As user activity on decentralized applications (dApps) grows, sequential processing leads to network congestion, higher transaction fees, and slower confirmation times. This limitation is a primary impediment to mainstream blockchain adoption.

Parallel execution, therefore, emerges as a vital solution. By identifying and executing independent transactions concurrently, a parallel executor can dramatically increase the number of transactions processed per second (TPS). Block-STM (Software Transactional Memory for Blockchain) is Cronos’s answer to this challenge, designed to optimistically execute transactions in parallel and re-execute them only if conflicts arise. Its introduction marked Cronos as one of the pioneering blockchain networks to implement such advanced parallel processing capabilities.

The Evolution of Parallel Execution: From External Library to Core Integration

The journey of Block-STM on Cronos has been progressive. In Cronos v1.7, the parallel execution engine was facilitated by a separate, standalone library. Specifically, the v1.7.9 codebase integrated Block-STM via Ethermint’s STMTxExecutor, which, in turn, depended on the go-block-stm package. This external package had been a part of Cronos since the chain upgraded to Cosmos SDK v0.50, demonstrating an early commitment to enhancing transaction throughput.

The transition in Cronos v1.8.1, tagged on October 26, marks a fundamental shift in this architecture. With this release, the node no longer relies on the standalone go-block-stm dependency. Instead, the parallel engine is now invoked by calling SetBlockSTMTxRunner with txnrunner.NewSTMRunner, a component imported directly from github.com/cosmos/cosmos-sdk/baseapp/txnrunner. This transaction-runner package is an intrinsic part of the Cosmos SDK itself. The removal of the external dependency from the module file signifies a deeper embedding of Block-STM into the core framework. This architectural change aligns Cronos more closely with the upstream Cosmos SDK, reducing the overhead associated with maintaining separate libraries, simplifying upgrades, and potentially paving the way for other Cosmos SDK chains to adopt similar parallel execution paradigms more easily in the future. The v1.8.1 release operates on Cronos’s fork of Cosmos SDK v0.54, CometBFT v0.39, and go-ethereum v1.16.9, reflecting a comprehensive update across its foundational components.

Opt-In, Not Default: A Critical Distinction for Node Operators

Despite the deep integration, a crucial point for all Cronos node operators is that parallel execution is not the default mode of operation in v1.8. The network’s default executor continues to process transactions sequentially, one at a time. The parallel engine only activates when a specific configuration setting is explicitly modified.

In the app/app.go file, the node checks whether the block-executor setting in the [evm] section of app.toml is set to the string "block-stm". If this value is not present or is set to anything else (e.g., "sequential"), the node will revert to the SDK’s default, sequential transaction runner. This means that a node operator who simply upgrades their Cronos software to v1.8 without making any changes to their app.toml will continue to run a node that processes blocks one transaction at a time. While this approach ensures backward compatibility and prevents unexpected disruptions, it also means that the significant speed gains and throughput improvements associated with Block-STM will not be realized until the configuration is adjusted.

The migration guide explicitly states this: "block-stm" for parallel execution; "sequential" is the default. This emphasizes that the parallel engine is present and available, but its activation is a conscious choice for the operator. The guide further recommends a specific configuration for all node roles—validators, public RPC nodes, and archive nodes alike—to fully leverage the benefits: Block-STM on, zero-copy = true, and optimistic execution on.

Navigating the Configuration Landscape: Risks and Best Practices

Enabling parallel execution requires modifying three specific lines within the [evm] section of the app.toml file:

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

These settings should be paired with specific memiavl storage configurations to optimize performance and prevent potential issues:

[memiavl]
enable = true
zero-copy = true

The zero-copy = true setting is particularly important. Setting it to false offers minimal benefit, as Block-STM inherently disables the SDK’s address cache (by calling sdk.SetAddrCacheEnabled(false) when active). Therefore, running Block-STM with zero-copy = false would merely introduce unnecessary data copying for every latest-height read without providing any compensatory advantage.

Critical Configuration Pitfalls: What Breaks and Why

While the parallel engine itself is designed for robustness, the risks in Cronos v1.8 lie in specific combinations of other configuration settings. Node operators must exercise extreme caution to avoid these pitfalls:

1. Sequential Execution Plus Disabled Optimistic Execution: This is the most significant warning in the migration guide. The memiavl node cache is only enabled when both block-executor = "sequential" and disable-optimistic-execution = true are set. In any other scenario, the code forces the cache size to zero. The guide explicitly warns that, in this release, enabling this cache can "halt the node with an app hash mismatch." This critical vulnerability arises because CheckTx and latest-height queries can read from the live state tree concurrently with a block being written. If a stale cached value is then used, the subsequent block might compute a different application hash compared to the rest of the network, leading to a consensus failure and a node halt. The guide highlights the practical reality of this 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 avoid this danger because optimistic execution is enabled by default. Any operator who disables optimistic execution and leaves Block-STM off (i.e., sequential execution) is running the precise configuration combination that the guide warns against. For those who absolutely must run this specific setup, the explicit recommendation is to set cache-size = 0 to mitigate the risk.

2. Regenerating Config Files from Scratch: The migration guide also issues a strong warning against regenerating config.toml or app.toml from scratch. A freshly generated app.toml often defaults mempool.max-txs to -1. If an operator also enables v1.8’s new app-side mempool by setting type = "app" in the [mempool] section, the node will fail to start and log a panic error: panic: mempool.type=app is incompatible with NoOpMempool. This highlights the importance of carefully migrating existing configurations rather than replacing them entirely.

Changes DApp Developers Will Feel Without Touching a Node

The v1.8 upgrade introduces several significant changes that will impact dApp developers, even if they never operate a Cronos node directly:

• txfee-cap is Now Enforced: Previously, the txfee-cap might not have been strictly enforced in all scenarios. With v1.8, this cap is now actively enforced, meaning transactions exceeding the defined fee limit will be rejected. Developers must ensure their dApps account for this enforcement to prevent transaction failures.
• Contracts and Transactions Changing at the Upgrade Height: As with many major blockchain upgrades, certain contract behaviors or transaction types might experience subtle changes precisely at the upgrade height. Developers should review the full changelog and migration guide for any specific contract or transaction-related modifications that could affect their dApps, especially those interacting with core protocol functionalities.
• Pending-Transaction RPCs Impacted by App-Side Mempool: Cronos v1.8 introduces a new app-side mempool. Under this new system, traditional RPC methods like eth_newPendingTransactionFilter and CometBFT’s /unconfirmed_txs will no longer return pending transactions. However, the txpool_* methods will continue to function. This change is crucial for bots, wallets, and monitoring services that rely on observing pending transactions. Developers must verify which mempool their chosen RPC provider is running and adjust their tools accordingly.
• A Per-Transaction Gas Cap: A new per-transaction gas cap of 16,777,216 gas has been implemented within the code. However, it’s important to note that this cap is not yet active. It requires a separate governance proposal and vote to be formally applied to the network. Developers should be aware of its impending activation and factor it into their future smart contract design and transaction estimations.

It is crucial to emphasize that none of these developer-facing changes are dependent on whether Block-STM is enabled. The parallel engine is designed to produce the exact same deterministic results as sequential execution. When transactions inevitably touch the same storage, they are re-executed to maintain correctness, which might make them temporarily slower but does not alter the final outcome.

Broader Implications for the Cronos Ecosystem

The integration of Block-STM into the Cosmos SDK represents more than just a technical upgrade; it’s a strategic move with far-reaching implications for the entire Cronos ecosystem:

• Enhanced Performance and Scalability: By making parallel execution more robust and easier to maintain, Cronos is poised to significantly boost its transaction throughput. This increased capacity can lead to lower transaction costs, faster confirmation times, and a smoother user experience, particularly during periods of high network activity.
• Reduced Maintenance and Development Overhead: Integrating Block-STM directly into the SDK streamlines the development and maintenance process for the Cronos core team. This allows them to allocate more resources to other innovations and ensures better compatibility with future Cosmos SDK upgrades.
• Attraction for DApp Developers: A more scalable and efficient blockchain is inherently more attractive to dApp developers. The potential for higher TPS and lower fees can encourage new projects to build on Cronos, fostering a more vibrant and diverse ecosystem.
• Paving the Way for Cosmos SDK: Cronos’s successful integration of parallel execution into the Cosmos SDK could serve as a blueprint or inspiration for other Cosmos SDK-based chains. This could accelerate the adoption of advanced scalability solutions across the broader Cosmos ecosystem.
• Risk Management: The explicit warnings about configuration risks highlight a mature approach to software development, emphasizing stability and security. By clearly outlining potential pitfalls, the Cronos team empowers operators to make informed decisions and prevent network disruptions.

Looking Ahead: The Path to Widespread Adoption

While Block-STM is now an integral part of Cronos’s SDK implementation, its full potential will only be realized as more node operators opt-in and the ecosystem adapts to the new capabilities. The current default of sequential execution ensures a cautious and stable transition, but the clear recommendations from the Cronos team suggest a strong desire for widespread adoption of parallel processing.

The v1.8.0 changelog and the migration guide provide a concise checklist for builders preparing for the upgrade, emphasizing the need to review all configuration settings meticulously. The core message remains clear: "built into the SDK" describes where the engine’s code now resides, not an automatic change in how a node operates. For any given node, parallel execution is only active if its operator consciously sets block-executor = "block-stm" in app.toml. This deliberate approach underscores Cronos’s commitment to both innovation and operational stability as it continues to evolve as a leading EVM-compatible blockchain.