In this post, we will explore the inner workings of the transaction lifecycle in Cosmos and CosmWasm and present the newest tooling Range is working on to supercharge advanced transaction analysis. To get there, we need to start from the beginning. What's a blockchain transaction?

Transactions

When users want to interact with an application and modify its state, they create transactions. A transaction consists of one or more messages, each representing a specific action that triggers a state change within the module they belong to. Messages are executed atomically, meaning each message within the transaction must be successfully executed, or the entire transaction will revert, and none of its changes will be committed to the state.

Messages

When a transaction is relayed from the underlying consensus engine to the Cosmos SDK application through the ABCI interface, it is first decoded by BaseApp. Then, each message contained in the transaction is extracted and routed to the appropriate module via BaseApp's MsgServiceRouter so that it can be processed by the module's message service. Messages have a type URL such as /cosmwasm.wasm.v1.MsgExecuteContract, which uniquely identifies the message type and its module association, allowing for the message to be routed to the appropriate module. Each module specifies a message service to which the message is routed. In the example of CosmWasm, the wasm module defines a message server that provides access to the module keeper for specific message types. 

Keepers

Keepers provide access to the modules' state and state-changing functionality.  A simple way of understanding the role of a keeper is to associate it with being the key that provides access to all of the module's state-changing functionality and more. The Wasm module keeper provides functionality that facilitates contract instantiation, execution, migration, etc. Additionally, the Wasm keeper contains references to keepers of other modules, such as the bank module for performing bank coin transfers from within a wasm message execution.

Contract State

A Cosmos SDK application comprises a large set of stores that persist in its state. By default, the main store of Cosmos SDK applications is a multistore, which is a store of stores. Each module declares and manages its own subset of the state within its own key-value store. The Cosmos SDK provides many store types that effectively wrap the key-value store with useful functionality. 

The state of a smart contract is stored in one of these store types provided by the Cosmos SDK called the Prefix Store. The Prefix Store is a wrapper for the KVStore, which provides automatic key-prefixing functionalities. This allows the wasm module to store the state of a contract with a key of ContractKeyPrefix []byte{0x02} appended to the contract address. This prefix store provides an instance of the contract state that is then provided to the WasmVm for execution. 

Wasm Message Execution

Now, let's cover the details of the wasm execution message. After performing validations and setup, the Wasm keeper passes the message, prefix store, and other environment-related fields to the WasmVM. The WasmVM provides high-level Go bindings to all the power inside cosmwasm-vm. Cosmwasm-vm uses the Wasmer engine to execute a given smart contract. It also contains code for gas metering, storing, and caching Wasm artifacts.

Contract message executions can be as simple as a single execute message that updates a state variable to a message that potentially has tens or hundreds of submessages and queries. Currently, there is minimal information provided in events about what occurs during this phase of the message lifecycle. 

Events

Events provide valuable information about the transaction, but solely relying on events is a limited approach to transaction analysis. While events are helpful in the block explorer context, they have downsides. 

Events can be spoofed or created to be purposefully misleading. The creator of the contract can emit any key-value events they wish. This makes it difficult to perform high fidelity because the events cannot be fully trusted. Events themselves are also limited. While the standard Cosmos SDK module and standard CosmWasm contracts emit useful events, it is not practical for them to emit the amount of detailed information that is necessary for advanced analysis. 

Importantly, events are not written in the application state and are not part of the AppHash. This is true in both previous Cosmos SDK and newer versions supporting ABCI++.  The conversation that explains why events are not included in the consensus is thoroughly discussed in this GitHub thread. Ultimately, this means that events cannot be trusted as they have not been validated in consensus.

While the Wasm module does take care to provide standardized events, as contracts get more complex in their interactions, getting a picture of the whole message execution becomes more difficult and unreliable. This is no shortcoming of the module; modules have to emit clear and concise events because it is not reasonable to enforce extra data and computation across the whole network of nodes. 

(Here's an example of events related to an Astroport swap)

Transaction Analysis

At this point, we have covered the main components involved in the execution of the CosmWasm contract. Now, let's talk about this in the context of a blockchain investigation. To understand what happened during a transaction execution, you currently have to rely on events. Events are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallets to track the execution of various messages and index transactions. Similarly, smart contracts emit attributes that are then converted to wasm module events.

As CosmWasm development and experimentation further advance, we expect more advanced contract interactions in which observability of individual message executions, queries, store read/writes, and gas usage is more important than ever.

To illustrate the benefits of advanced transaction analysis, let's consider some real-world scenarios. In a complex DeFi transaction involving multiple smart contracts and cross-chain interactions, It is critical to have a detailed breakdown of each step, including the flow of funds, contract interactions, and queries. When the contract dispatches a query, it is critical to see both the query request and the response. This can help pinpoint points of failure or compromise. 

Advanced Transaction Analysis

With the increasing frequency of on-chain investigations and the growing complexity of transactions, it is essential to extract more detailed information from the network. To achieve this, the most effective approach is to modify the node to inject observability features into the inner workings of the appchain. The primary objective is to offer a comprehensive analysis of the transaction's lifecycle, as described in the previous sections. By injecting observability into the node, investigators can identify potential areas of compromise, gather enriched data for analysis, and facilitate a more thorough understanding of the transaction's execution. This granular level of information empowers investigators to conduct in-depth forensic analysis and uncover valuable evidence in the context of blockchain investigations.

At Range, we are developing a tool called Isotope that fills this void. Isotope is engineered to provide detailed information about a transaction’s inner workings. Isotope will integrate with all the components involved in the transaction lifecycle mentioned above. Isotope will provide matter-of-fact message execution details that shed light on the execution of Cosmos messages, from the transaction level details to the individual store reads and writes.

Advanced transaction analysis tools like Isotope benefit blockchain investigations and have significant implications for smart contract development and auditing. By providing detailed insights into the execution of smart contracts, developers can identify potential optimizations, detect inefficiencies or bugs, and fine-tune their code for better performance and gas usage. Auditors can leverage the granular data provided by Isotope to assess the security and correctness of smart contracts, identifying vulnerabilities and potential attack vectors. Analyzing the inner workings of transactions empowers developers and auditors to build more robust and secure smart contracts, ultimately enhancing the overall reliability and trustworthiness of the blockchain ecosystem.

Advanced Simulation

The Range Simulator provides simulation output in the format of balance changes and events returned from the simulated message execution. The next step is to enrich this data with Isotope. The Range Simulator and Isotope combination will take the IBC Ecosystem to the next level of capabilities when it comes to transaction simulations, providing end users with the ability to have full visibility into the inner workings of their transactions.

(Output from the Range Simulator)

Conclusion

As the demand for increased visibility into the inner workings of complex smart contract interactions within the IBC ecosystem increases, the need for advanced transaction analysis tools becomes increasingly crucial. Traditional methods of analysis relying solely on events have limitations, as they can be spoofed, misleading, and lack the necessary level of detail for comprehensive analysis. By developing tools like Isotope, investigators can gain valuable insights into the transaction lifecycle, enabling them to conduct thorough forensic analysis and uncover potential areas of compromise.