Transaction Chaining Method about gno HOT 4 CLOSED

I recommend utilizing the current transaction batch/composition logics, which appear to be the "gno way" approach. This can be accomplished by creating batch-oriented contracts accessible to all through maketx call or by directly using maketx run.

You can find the pull request for the maketx run feature here: #1001. Additionally, there is an example where 10 calls to the tests realm are simulated in a single for loop here: https://gist.github.com/moul/ccf1e2aff64e7a1f0c5ca5e2d98d7e9a. Since it's Gno, you have the flexibility to implement any desired logic, efficiently.

I recommend delaying the discussion of creating a pseudolanguage for advanced transaction parsing within the mempool. Let's first identify the limitations of the current system. After that, we can focus on improving and expanding the mempool. It's important to keep the mempool simple, fast, and efficient.

Here are some suggestions to proceed:

• Prioritize integrating maketx run into the SDKs (js/ts and Go).
• Consider writing wrappers to simplify contract development, allowing you to focus on specific code segments instead of writing full contracts. This approach would be similar to how q_eval works but with multiline support.
• Consider developing a wrapper that generates a maketx run based on your intended calls. This reminds me of the composition logic in Python's Alchemy library, which functions as an "ORM" for transactions.
• Think about developing p/xxx libraries to support common patterns for chaining conditional transactions.

from gno.

Let's close it :) can always open a new one should you have a usecase where MsgRun does not satisfy your needs.

from gno.

Does manfred's answer satisfy your question/problems? Are there action items on this issue? @notJoon

from gno.

@thehowl Oh, yes I think it's best to make it a function for now. no follow up action-item yet. should I close this issue or leave it open?

from gno.