Merge PFB and Tx Namespaces

[cmwaters]

Summary

Parent Issue: https://github.com/celestiaorg/celestia-app/issues/2977

This is a proposal to merge the two celestia state machine specific namespaces into a single namespace. This is to be done by modifying the square construction mechanism to populate the TxNamespace with all transaction types including those with PFBs.

Problem Definition

This is meant to address the current emergent problems from when we originally separated into two namespaces:

• A sdk.Tx that has a PFB is not allowed any other sdk.Msg
• PFBs can not use authz
• PFBs are ordered behind non PFBs thus they are dropped first instead of the lowest priority transaction
• The reshuffling messes with nonces making it difficult to have multiple transactions by the same sender in a single block.

Proposal

Create a new square construction protocol (v2 of the go-square repo). That places all transactions in TxNamespace and no longer uses the PFBNamespace.

[musalbas]

If I recall correctly, the reason why we separated them into different namespaces in the first place was because we needed to domain-separate the PFB transactions so it's easier to parse by sovereign ZK rollups, as requested by Sovereign SDK. How would this proposal effect that? cc @preston-evans98

[nashqueue]

Note that this might break the FBSS construction, or at least make it more complicated.

[preston-evans98]

Thanks for flagging @musalbas!

Having all of the PFBs in a separate namespace is nice for parsing (because we can avoid parsing irrelevant transactions), but is not strictly required. IIRC, the core issue with the previous implementation was that standard transactions and PFBs had separate encodings but were not domain separated. That meant that it was impossible to guarantee that a parser was actually recovering the transactions with the appropriate type.

That being said, this change will require significant breaking changes to the sov SDK adapter and will significantly reduce efficiency unless #3316 is also merged - in which case the impact is completely removed.

[adlerjohn]

My understanding is #3316 was planned to go in at the same time (i.e. in the same release) as #3315. You can quote me on this if that ends up not being the case so we can make it the case.

[adlerjohn]

@nashqueue why would this break FBSS?

[evan-forbes]

@cmwaters this is not in v3, correct?

[rootulp]

Correct. Ref: https://github.com/celestiaorg/go-square/blob/6be96324999598f641bdb20ef0fb7043cece4d95/builder.go#L181-L183