CHIPs discussion phase: Intent-centric Automation Cosmos SDK module on Cosmos Hub

Intent-centric Automation Cosmos SDK module on Cosmos Hub: Enabling orchestration of Interchain actions and more Greetings Cosmos Hub Community! We’re excited to introduce the Intent-centric Automation (IA) Cosmos SDK module. The IA module enables condition-based automation of Cosmos messages on connected IBC chains. This module allows for coordination and orchestration of interchain actions in an effective, permissionless and trust-minimized manner. We have been researching and developing automation logic in Cosmos SDK module code since 2021. We are currently developing our automation module to become a generalized framework for handling all kinds of intent-centric blockchain actions. We want to get the community’s perspective on the idea of launching the IA module on the Cosmos Hub. Therefore we encourage you to bring up your thoughts, feedback and any questions you may have. What is intent-centric automation? Our definition of intent-centric automation is a combination of an intent: a clearly formulated or planned purpose and automation: an automatically controlled operation. In crypto, we want to perform such actions with no counterparty risk and in a permissionless…

Excerpt (1199 of 10410 characters). Read the whole post on the forum ↗

Glad to see you guys move to a fee-per-tx based system. You have our support to bring this module to the hub!

This is really cool. How far along is the module development?

@tknox35 Thanks for your reply!

The core automation logic, covering features like Interchain Account automation, fee structures, execution history tracking, and basic conditional logic, has been successfully implemented. We’ve also conducted thorough testing with both unit and integration tests to ensure reliability.

Currently, we’re looking at expanding the module to include more advanced features. We’ve already incorporated key governance parameters, focusing on fees, and are exploring additional safeguards to limit trigger executions within specific periods. Future developments include introducing sophisticated condition-based logic with conditional operands and enabling the reuse of message outputs for new actions.

This looks like pretty solid work to me. However, one concern I have is that this will put maintenance and security load on the Cosmos Hub since it is a native Cosmos-SDK module.

Smart contract based solutions (perhaps one running on Neutron) would not have this issue. You compared that briefly and my main takeaway is that a smart contract based solution could use more gas. Is this really an issue? How much more gas is needed? How much impact will this have on users? Are there any other benefits of the native approach?

If we do decide to take the native Cosmos-SDK approach that you recommend, how much maintenance will this need? How big of a codebase will it be, and how tightly will it integrate with Cosmos-SDK internals? I know it’s really tough to estimate this stuff, but I’m trying to get a sense of how hard it will be for someone to update it to new SDK versions.

@jtremback Thank you for your perspective. There are several factors to consider when it comes to performance. The ability to efficiently iterate on a queue block by block is important from a UX perspective. There’s a high fixed computational effort associated with calling a virtual machine (VM) on a recurring basis. With the SDK-native approach, the module directly accesses the EndBlock, eliminating the additional effort of calling into a VM to access the logic. In addition, our SDK approach offers the advantage of making calls directly with native message handling and directly access IBC post-packet handling. In contrast, a privileged smart contract solution would access the Cosmos SDK message handler and route ICA packets by sending messages from the smart contract code, accessing route logic through the wasm VM bindings, and the CosmWasm Cosmos SDK module. ICA packet acknowledgements and timeouts would have to call into a VM again to be added to the trigger history. Thus, the IA module approach reduces complexity and is more efficient in each step in the execution process. We view having low computational complexity as an important advantage over to a privileged smart…

Excerpt (1194 of 3134 characters). Read the whole post on the forum ↗

danieljd: Measuring and comparing gas cost is not possible as it’s part of FinalizeBlock and not calculated in Endblock/BeginBlock functions. Why isn’t gas cost a factor? Don’t different types of jobs have different resource requirements, and thus require gas metering? (As an aside, I noticed you have something about 1 ATOM above, but I’m kind of confused on whether this is a fixed cost). If there is gas metering, then isn’t the cost of running jobs of primary concern to the people creating them, and can’t the efficiency of your solution vs. a smart contract solution be evaluated as gas costs to be paid by users? Given that you are proposing a pretty high 1 ATOM fee, it seems like there is some latitude for computation to be somewhat expensive. danieljd: In the next phases of the CHIPs process, we could consider providing ongoing maintenance support for the module, ensuring compatibility with new Cosmos SDK releases expected to be implemented in the Cosmos Hub repository for the foreseeable future. For example, for up to 5 years and covering up to 7 Cosmos SDK upgrades. It’s important to note that our maintenance support would include patches and fixes,…

Excerpt (1198 of 1773 characters). Read the whole post on the forum ↗

jtremback: Why isn’t gas cost a factor? Don’t different types of jobs have different resource requirements, and thus require gas metering? (As an aside, I noticed you have something about 1 ATOM above, but I’m kind of confused on whether this is a fixed cost). If there is gas metering, then isn’t the cost of running jobs of primary concern to the people creating them, and can’t the efficiency of your solution vs. a smart contract solution be evaluated as gas costs to be paid by users? Good point. Most of the execution sequence is fixed, so the fixed cost could be main cost per execution from a user’s point of view. Currently the module has a fixed fee per execution, and a flexible fee per execution that is based on the interval. The flexible fee can be expanded to also factor in this logic. This is part of our work around adding comparative functions and message reply-based logic. We can indeed use the gas meter for determining the flex fee. It’s not possible to determine the differences in efficiency because a such a smart contract system is hypothetical. Also, gas meter consumption can be customized, which is also implemented in the x/wasm module. Gas in CosmWasm…

Excerpt (1199 of 2704 characters). Read the whole post on the forum ↗

danieljd: It’s not possible to determine the differences in efficiency because a such a smart contract system is hypothetical. Fair enough. Maybe someone else can chime in with a real example of a CosmWasm automation system. @Elijah and @JakeHartnell - are you aware of any? Also, I know that @zaki_iqlusion 's Sommelier is largely based on endblock automation (IIRC?), although I think not CosmWasm. Maybe he has some input here as well. danieljd: Currently the module has a fixed fee per execution, and a flexible fee per execution that is based on the interval. The flexible fee can be expanded to also factor in this logic. This is part of our work around adding comparative functions and message reply-based logic. We can indeed use the gas meter for determining the flex fee. danieljd: Our proposed idea is to have a fixed fee for local messages of 0.1 ATOM and having a higher 1 ATOM fee for interchain actions. One of the main target groups for interchain actions can be protocols. The higher fee accounts for IBC relay cost and and can be offset by the benefits of automation by the IA module for protocols (examples in first post). Why not…

Excerpt (1197 of 1238 characters). Read the whole post on the forum ↗

jtremback:

Why not just charge based on gas metering alone?

Gas metering alone (flexible fee) can work. The fixed/flat fee per execution can be set to 0.
We came up with this type of fee as a way to prevent network congestion and at the same time bring value to the community pool, whereas with the flexible fee we aim to reward the Hub’s participants for providing computational resources. This flexible fee per execution is directed to the fee pool.