[Feature]: unordered tx: client-supplied unique identity

cosmos / cosmos-sdk

:chains: A Framework for Building High Value Public Blockchains :sparkles:

https://cosmos.network/

Apache License 2.0

6.19k stars 3.58k forks source link

[Feature]: unordered tx: client-supplied unique identity #21134

Open yihuang opened 1 month ago

yihuang commented 1 month ago

Inspired by ton network highload v3 wallet type

Currently, we record the transaction hashes for replay protection, which is quite heavy. One alternative solution is to let the user provide an integer-based unique ID, the integer set could be encoded much more efficiently and can be stored in the account storage, instead of globally.

Positives

Avoid tx hash malleability issue: https://github.com/cosmos/cosmos-sdk/issues/19291
The storage overhead is per account, and we can charge the account for the storage accupation, and incentive them to release in time. The assumption here is only a small part of the accounts (the "enterprise" ones) will heavily use this feature.
Unordered accounts can choose to support different maximum TTL, as long as they pay for the storage overhead.

Negatives

The storage is written into the chain state, so increase the chain state, but the overhead can be compensated by charging the account.

tac0turtle commented 1 month ago

hmm i understand the client side benefits but it makes it stateful and would conflict with ordered txs. Using offchain indexing seems like the better approach for seeing how many txs are per account

yihuang commented 1 month ago

Using offchain indexing seems like the better approach for seeing how many txs are per account

yeah, I think the sequence issue is insignificant, I removed it and changed the issue to focus on the client-side id.

hmm i understand the client side benefits but it makes it stateful and would conflict with ordered txs.

I added the positives/negatives section for discussion, what do you mean by the conflicts with ordered txs? If an account is moved to unordered mode, it can't be ordered at the same time, but the other accounts can still be ordered.

It's kind of like ibc channels, the ordered/un-ordered semantics is per-channel, rather than per-message.

tac0turtle commented 1 month ago

in this design the clients need to have knowledge of previous IDs to avoid sending a different tx with the same ID correct? also would we not need to store all the IDs used, meaning we have to do a state lookup instead of a file look up?

yihuang commented 1 month ago

in this design the clients need to have knowledge of previous IDs to avoid sending a different tx with the same ID correct?

Yes, at least within the range of ttl, the same id can't be used again.

for some "enterprise" wallet, they already have requests recorded in dbs which probably has assigned an unique id for each request, that id can be used here directly.
For "stateless" wallets, they can maintain a local in-memory state, on startup, it should be initialized with the on-chain state on startup.
Or use some timestamp based unique id algorithm https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake.

also would we not need to store all the IDs used, meaning we have to do a state lookup instead of a file look up?