Executing Signers

[hayes-mysten]

Proposal for executing signers

Current state

Today transactions are primarily executed in 3 ways:

1. Dapps execute transactions through the signAndExecuteTransaction hook, which executes transactions through the wallet standard
2. SDKs and backends execute transactions with the client using the client.signAndExecuteTransaction method
3. Dapps build transactions, sign with a wallet (or zklogin/enoki signer) and then pass the transaction to a backend to execute sponsored transactions

These patterns have lead to some inconsistencies and incompatibilities in our SDKs.

Goals

Some things we would like future versions of our SDKs to be able to do:

• SDKs should work just as well with wallets as they do with signers
• Transactions in dapps when connected to a wallet should be executed in the wallet for transactions executed by the dapp, including those executed by SDKs
• Transaction sponsorship should be composable in a way that works seamlessly with wallets, signers, and all SDKs
• Transaction execution should be customizable, so that SDKs can seamlessly work with the caching or parallel transaction executors
• Transactions executed in the wallet should defer transaction construction so it happens in the wallet

Solution

To execute transactions, SDKs need both a Signer and a Client. The signer produces the signature, and the client is used to build the transaction and executes it.

Today, the Client is a SuiClient, but is being replaced with a more limited CoreClient instead. The CoreClient and still be used to build and execute transactions, but will not have a signAndExecuteTransaction method.

We can instead add a signAndExecuteTransaction method the the base Signer class, which will take the transaction, and the CoreClient as arguments. The base Signer will implement this by calling transaction.build({ client }) to build the transaction, signing it with it's own signTransaction method, and then executing it with the CoreClient.

This by itself does not change much, but if SDKs all use signer.signAndExecuteTransaction instead of client.signAndExecuteTransaction, we can provide various executing signer implementations to customize the transaction execution process.

WalletSigner

The most important of these will be a new WalletSigner exposed from dapp-kit that will enable signing/executing with the currently connected wallet/account. This signer would implement the normal signTransaction and signPersonalMessage methods using the corresponding wallet-standard features, but would also implement a custom signAndExecuteTransaction method that uses the signAndExecuteTransaction wallet-standard feature.

As long as SDKs are updated to use signer.signAndExecuteTransaction instead of client.signAndExecuteTransaction, SDKs will automatically work with this new wallet signer, and transactions will be executed in the wallet instead of the dapp when using the WalletSigner.

SponsoredSigner

A sponsored signer could be implemented as:

export class SponsoredSigner extends Signer {
	#signer: Signer;
	constructor(signer: Signer) {
		super();
		this.#signer = signer;
	}

	async sign(bytes: Uint8Array): Promise<Uint8Array> {
		return this.#signer.sign(bytes);
	}

	getKeyScheme() {
		return this.#signer.getKeyScheme();
	}

	getPublicKey() {
		return this.#signer.getPublicKey();
	}

	async signAndExecuteTransaction({transaction, client }: SignAndExecuteOptions) {
		const sponsoredBytes = await getSponsoredTransactionBytes(transaction);
		const signature = await this.#signer.sign(sponsoredBytes);
		return executeSponsoredTransaction(sponsoredBytes, signature);
	}
}

This allows any signer to be used with a sponsorship flow, by wrapping it with a SponsoredSigner.

Custom executors

Custom executors that parallelize execution, or cache transaction effects could work the same way, by wrapping another signer with custom execution logic.

Signers in dapp-kit

Dapp-kit methods like signAndExecuteTransaction could also accept signer instances to customize execution, defaulting to the WalletSigner if no signer is provided.

Alternatively, we could omit methods like signAndExecuteTransaction from dapp-kit, and instead only expose the WalletSigner from dapp-kit, so both dapps and SDKs always directly use the WalletSigner instead.

Problems to solve

Execution results

The biggest problem with this proposal is the return type of the signAndExecuteTransaction method. Today, SDKs are tied to the JSON RPC response of signAndExecuteTransaction, which can accept a number of options to customize the returned data.

I think the ideal answer would be to base this on the new Core executeTransaction method. The downside of this is that a WalletSigner would not currently get the same data from the signAndExecuteTransaction feature.

We could query for the transaction in the WalletSigner after execution, but this would be less efficient.

Does this belong in dapp-kit?

Should WalletSigner be part of dapp-kit, or should we just add a lower level implementation on top of the wallet standard that dapp-kit also consumes?