TS Interfaces for signature-mpc

[fl0ydj]

Hey! We have been starting to migrate our code to the new interfaces on sign-ia-wasm branch but honestly working with the TS interfaces is super tedious and not ready for production. Right now we ended up copying the whole folder and patching every function. I think there are good solutions to the issues we have been having.

Issues

• too many transactions
  • a lot of times you do multiple transactions which could be combined in one (e.g. sendUserShareToSuiPubKey could be 4 tx rn or something)
  • also when I want to send 5 user shares at once I should be able to do all of this in one tx
• inefficient data fetching
  • within the typescript functions you are doing a lot of fetching in a waterfall like manner.
  • when combining flows a lot of these don't even make sense to fetch multiple times
• every interface requires keypair
  • the interfaces shouldnt take the keypair directly → this would ensure compatibility with sponsored transactions, biometric keypair retrieval etc and enhance security
  • some interfaces shouldn’t need keypair at all e.g. getEncryptedUserSharesObjID (if it doesnt exist and should be created, it should be another function)
• direct calling of wasm functions
  • in react native, we load the wasm in a separate webview environment and communicate with it using async messaging. This means we can't directly call the wasm functions and the interface for us is async

Suggested solutions

Transactions

Utilize the Transactionblock class for all common flows or introduce a wrapper around it:

• the flows should be synchronous functions on the transaction block object e.g. tx.sendUserShareToSuiPubkey
• the interfaces should allow for flexibility (e.g. the user can pass in the encryption key themselves or you get it from the keypair in a standard way on prepare)
• resolving any references, calling the wasm etc should happen in the build step
  • you can add all the necessary references to the blockData object
  • you can resolve them in the #prepare function and also call the wasm here
  • sui is doing this for object(ObjectId) for example, where they fetch the object ref with version etc at build (https://github.com/aeon-protocol/dwallet-network/blob/a1fc2e7c47aa9d506660d9f7135950e5e677d8dc/sdk/typescript/src/builder/TransactionBlock.ts#L309, https://github.com/aeon-protocol/dwallet-network/blob/a1fc2e7c47aa9d506660d9f7135950e5e677d8dc/sdk/typescript/src/builder/TransactionBlock.ts#L806)
• the build function should take a Wasm object with all the necessary functions (see wasm section below)
• the keypair is only required at execution and can be used to resolve any inputs where the address is required
• the pallier keypair can also be constructed at build time
• for flows which require multiple transactions (signing/dkg), you can provide a reference implementation utilizing the new transaction block interfaces

Wasm

Introduce a wasm interface which is used as an abstraction layer for the wasm calls

• passed as an argument to the build function on the transaction block
• all function calls in the interface should be async
• you can provide a standard implementation of the interface calling the underlying wasm and we could substitute this with our async messaging as required

Happy to also contribute to implementing this @ycscaly @omersadika

[fl0ydj]

Also, on the onchain interfaces, it would be great if functions which create a shared object could returns its ID/related data so that commands can be chained together in a ptb. E.g. if register_encryption_key would return the ID of the key, and set_active_encryption_key would take ID and key_owner_address instead of the whole object, both could be called in the same ptb.