Move all tx stuff into x/tx go.mod

[amaury1093]

Summary

Move all tx stuff into x/tx go.mod

Problem Definition

We currently have tx-related logic and types inside:

• types/tx
• x/auth/tx
• root tx (not anymore)
• client/tx (move to client/v2/tx, see Move all tx stuff into x/tx go.mod #14600 (comment))

This is confusing.

Proposal

During our last SDK call, we decided to concentrate all these above into a new x/tx go mod.

[amaury1093]

One problem I envision is: a lot of tx stuff depends on cosmos/cosmos-sdk/types, e.g. sdk.Context. Do we want to:

1. put everything in x/tx already now, but this new go module will depend on the root sdk
2. cherry-pick stuff into x/tx as we go, so that it doesn't depend on the root sdk, and keep this issue as a long-term goal as we clean the repo up.

Maybe 2 is a cleaner approach.

[alexanderbez]

We did have consensus on x/tx, right?

[julienrbrt]

A small point about the docs: they will need to be moved as well and possibly improved to explain the package as a whole (that will do much more):

• https://docs.cosmos.network/main/modules/auth/tx
• https://github.com/cosmos/cosmos-sdk/blob/main/docs/pre.sh#L15

Another possible thing to think about is the package name. Given that we go for the whole path for packages living under x/ (as of x/nft and x/circuit), we may want to do the same for tx for consistency (instead of using cosmossdk.io)

[amaury1093]

So I took at look at what can be put into x/tx today... not much:

• We can't move x/auth/tx's sign mode handlers because they depend on sdk.*:
  • sdk.Tx, needs Move away from Tx interfaces (sdk.Tx, sdk.FeeTx...) #10347
  • sdk.Msg, maybe we can remove completely with Protobuf Any Interface Redesign #10368?
  • sdk.TxDecoder and sdk.TxEncoder, we can remove those completely I guess, if we drop the StdTx stuff.
  • sdk.AccAddress, we can probably use strings here
  • sdk.Coins, needs coins to be somewhere else first, probably core/coins
  • also depend on cryptotypes.PubKey, a potential solution is Protobuf Any Interface Redesign #10368.
• types/tx stuff are mostly just ValidateBasic methods, so can't be moved to x/tx
• types/tx/signing can't be moved because they depend on x/tx. Also Make signing types less confusing #6896

In conclusion, this issue is probably an clean-up Epic in itself.

The alternative is to do 1 in #14600 (comment), i.e. have a cyclic go mod dependency between root sdk and x/tx, like we do for groups.

[alexanderbez]

#10368 will allow us to cross off many of the sub-points in the first point, right?

[amaury1093]

#10368 will allow us to cross off many of the sub-points in the first point, right?

Yeah I think so. But did we decide on a solution for #10368? Also, I'm not 100% sure if it's dependent on ADR-054 or if they are orthogonal.

[aaronc]

I would modify the original proposal slightly to propose that client related tx stuff (that depends on x/tx) goes in client/v2/tx to separate state machine and client stuff a bit more.

[tac0turtle]

lots of this was done by @kocubinski, can we close this isse?

[aaronc]

We still don't have ante handlers or client support migrated

[tac0turtle]

now i believe this is closed