crypto: add intent signing struct

[joyqvq]

a rework of https://github.com/MystenLabs/sui/pull/2116/files with https://github.com/bmwill/sui/commit/f5b8026a436eeff3fa0c7f61f369ede1b8683a1f?diff=unified

[bmwill]

Thanks @joyqvq for resurrecting this. I think that before we look at getting this merged that we should revisit some parts of the intent scheme since I believe they should actually be rolled into some of our core structures. Specifically we need to add a chain_id to all transactions and for forward-compatibility reasons we may want to augment the serialized format of our core data structures, essentially baking in a part of the "intent" (the name of the struct) into the actual serialized payload of an object.

[joyqvq]

Thanks @joyqvq for resurrecting this. I think that before we look at getting this merged that we should revisit some parts of the intent scheme since I believe they should actually be rolled into some of our core structures. Specifically we need to add a chain_id to all transactions and for forward-compatibility reasons we may want to augment the serialized format of our core data structures, essentially baking in a part of the "intent" (the name of the struct) into the actual serialized payload of an object.

add a chain_id to all transactions by transaction you mean struct TransactionEnvelope?

[bmwill]

Specifically to TransactionData

[joyqvq]

Specifically to TransactionData

talked to @kchalkias offline, we decide that we do NOT want to include chain id in the transaction data bc we assume object id are guaranteed to be unique and collision resistant as they are derived from the chain id from genesis.

instead, we will have user sign over IntentMessage - this will be a breaking change that we park till after private testnet stabilizes.

[github-actions[bot]]

💳 Wallet Extension has been built, you can download the packaged extension here: https://github.com/MystenLabs/sui/actions/runs/3205505034#artifacts

[bmwill]

We may end up needing to do something slightly different with ChainId (as this is something that we probably want to exist onchain in some capacity) but we can iterate on that later

[joyqvq]

We may end up needing to do something slightly different with ChainId (as this is something that we probably want to exist onchain in some capacity) but we can iterate on that later

Good point, I have been trying this out in a draft PR. I think this could live in AuthorityState and also expose a get_chain_id endpoint that client software can query for. User can select network/chain_id in wallet for signing.

Going to land this one for now, (since no methods is actually using intent), and iterate on the followup PRs.