Preparing and Signing Transactions Using External Party

High-level Signing Process

The basic steps of preparing and signing a transaction using an external party are as follows:

1. Creating a command - You start by simply creating a command.

2. Preparing the transaction - You send the command to the blockchain RPC, offered by your node, to prepare the transaction.

3. Validating the transaction - You inspect the transaction and decide whether to sign it.

4. Signing the transaction - Once validated, you sign the transaction hash using your private key (typically with ECDSA/EdDSA).

5. Submitting the transaction - You submit the signed transaction to be executed.

6. Observing the transaction - You observe the blockchain until the transaction is committed.

In the examples below, the SDK examples use the Pint app which comes pre-installed with the validator and the cURL examples show the underlying HTTP requests using Canton Coin following a token standard transfer.

How do I quickly execute a ping Command?

The following example uses the Ping app to show the whole transaction flow.

Below shows how to quickly execute a ping command against yourself on Splice LocalNet:

import {
    WalletSDKImpl,
    localNetAuthDefault,
    localNetLedgerDefault,
    localNetTopologyDefault,
    createKeyPair,
} from '@canton-network/wallet-sdk'
import { v4 } from 'uuid'
import { LOCALNET_SCAN_API_URL } from '../config.js'

// it is important to configure the SDK correctly else you might run into connectivity or authentication issues
const sdk = new WalletSDKImpl().configure({
    logger: console,
    authFactory: localNetAuthDefault,
    ledgerFactory: localNetLedgerDefault,
    topologyFactory: localNetTopologyDefault,
})

console.log('SDK initialized')

await sdk.connect()
console.log('Connected to ledger')

await sdk.userLedger
    ?.listWallets()
    .then((wallets) => {
        console.log('Wallets:', wallets)
    })
    .catch((error) => {
        console.error('Error listing wallets:', error)
    })

const keyPair = createKeyPair()
await sdk.connectTopology(LOCALNET_SCAN_API_URL)

console.log('generated keypair')
const allocatedParty = await sdk.topology?.prepareSignAndSubmitExternalParty(
    keyPair.privateKey
)
sdk.userLedger?.setPartyId(allocatedParty!.partyId)
console.log('Create ping command')
const createPingCommand = sdk.userLedger?.createPingCommand(
    allocatedParty!.partyId!
)
sdk.userLedger?.setPartyId(allocatedParty!.partyId!)

console.log('Prepare command submission for ping create command')
const prepareResponse = await sdk.userLedger?.prepareSignAndExecuteTransaction(
    createPingCommand,
    keyPair.privateKey,
    v4()
)

Creating a Command

Commands are the intents of an user on the validator, there are two kinds of commands: CreateCommand and ExerciseCommand.

The CreateCommand is used to create a new implementation of a template with the given arguments and can result in one or more new contracts being created. The ExerciseCommand takes an existing contract and exercises a choice on it, which also can result in new contracts being created.

In the Canton Network, it is often necessary to need to include input data when creating commands which needs to be read from the ledger. For example, which UTXOs to include in a transfer. This is private data which you read from your own node. It’s also often necessary to include contextual information in a transfer. For example, information about a particular asset which you don’t get from your own node - you get from an API provided by the asset issuer. See here <https://github.com/global-synchronizer-foundation/cips/blob/main/cip-0056/cip-0056.md> for more information.

The general process for forming a transaction is:

1. Call your own node’s RPC to get the current ledger end (think “latest block”)

2. Call your own node’s RPC to get relevant private data at ledger end (e.g. wallet’s holdings)

3. Call app/token specific APIs to get context information (e.g. mining round contracts)

4. Assemble the data into the full command using the OpenAPI/JSON or gRPC schemas.

In the examples below, the SDK example uses the AdminWorkflow inside the a validator to create a simple ping command. The ping command is sent to a recepient party who can then exercise the pong choice on the created contract (thereby archiving it). In the cURL example, we show the steps above gaining information from a validator and context information from the Canton Coin scan API.

The Wallet SDK allow us to build such a command easily:

SDKcURL

import {
    WalletSDKImpl,
    localNetAuthDefault,
    localNetLedgerDefault,
} from '@canton-network/wallet-sdk'

const sdk = new WalletSDKImpl().configure({
    logger: console,
    authFactory: localNetAuthDefault,
    ledgerFactory: localNetLedgerDefault,
})
await sdk.connect()

const receiver = 'target-of-ping-party'

const command = sdk.userLedger?.createPingCommand(receiver)

For the SDK ping example, the underlying code that creates the command is:

createPingCommand(partyId: string) {
        return [
            {
                CreateCommand: { // we are performing a CreateCommand
                    templateId: '#AdminWorkflows:Canton.Internal.Ping:Ping', //template id of the ping contract
                    createArguments: { // the arguments to the ping contract
                        id: v4(), // an unique id for the ping. Here we use the JS uuid library to generate a v4 UUID
                        initiator: this.partyId, //our party id
                        responder: partyId, //the party we are pinging
                    },
                },
            },
        ]
    }

Preparing the Transaction

Now that we have a command we need to prepare the transaction by calling a node’s RPC API which will return an unsigned transaction. It must be a validator which hosts the party initiating the transaction as private information is needed to construct the transaction. This is unlike other chains where you construct the transaction fully offline using an SDK. A transaction is a collection of commands that are atomic, meaning that either all commands succeed or none of them do.

Note: contractId’s are pinned as part of prepare step, the execution of the transfer will only go succeed if the contractId’s haven’t been archived between preparation and execution steps.

To prepare a transaction we need to send the commands to the ledger.

SDKcURL

import {
    WalletSDKImpl,
    localNetAuthDefault,
    localNetLedgerDefault,
} from '@canton-network/wallet-sdk'
import { v4 } from 'uuid'

const sdk = new WalletSDKImpl().configure({
    logger: console,
    authFactory: localNetAuthDefault,
    ledgerFactory: localNetLedgerDefault,
})

await sdk.connect()

const receiver = 'target-of-ping-recieving-party'

const command = sdk.userLedger?.createPingCommand(receiver)

const transaction = await sdk.userLedger?.prepareSubmission(
    command, //the prepared ping command
    v4() //a unique deduplication id for this transaction
)

The return type is an unsigned transaction if the combination of the commands are possible, otherwise an error is returned. The transaction can then be visualised and signed by the party.

Validating the Transaction

The result from the prepare step is an encoded protobuf message and easily decoded and inspected to go through a policy engine, for example. The transaction is returned alongside with the hash that needs to be signed. If the validator is not controlled by you, then it might be a good idea to validate that the transaction is what you expect it to be. You can use the Wallet SDK to visualize the transaction as described in the Visualizing a transaction section.

On top of visualizing the transaction, it’s also important to compute the transaction hash yourself and confirm that it matches the hash of the transaction provided by the validator from the prepare step.

The hash can be computed using the Wallet SDK:

import { TopologyController } from '@canton-network/wallet-sdk'

const transaction = {
    preparedTransaction: 'encoded-transaction-bytes-base64',
    preparedTransactionHash:
        'hash-of-the-encoded-transaction-that-needs-to-be-signed',
    hashingSchemeVersion: 'hashing-scheme-version',
}

const hash = TopologyController.createTransactionHash(
    transaction.preparedTransaction
)

You can then compare the hash with the transaction.preparedTransactionHash to ensure they match.

Signing the Transaction

Once the transaction is validated, the hash retrieved from the prepare step can be signed using the private key of the party.

Below shows an example in the Wallet SDK and using cURL commands:

SDKcURL

import { signTransactionHash } from '@canton-network/wallet-sdk'

const transaction = {
    preparedTransaction: 'encoded-transaction-bytes-base64',
    preparedTransactionHash:
        'hash-of-the-encoded-transaction-that-needs-to-be-signed',
    hashingSchemeVersion: 'hashing-scheme-version',
}

const privateKey = 'your-private-key-here'

const signature = signTransactionHash(
    transaction.preparedTransactionHash,
    privateKey
)

Submitting the Transaction

Once the transaction is signed, it can be executed on the validator. You can observe completions by seeing the committed transactions. If they don’t appear on your ledger, you are guaranteed some response, and you can keep retrying; signed transactions are idempotent. Finality usually takes 3-10s.

SDKcURL

import {
    localNetAuthDefault,
    localNetLedgerDefault,
    WalletSDKImpl,
} from '@canton-network/wallet-sdk'
import { v4 } from 'uuid'

const sdk = new WalletSDKImpl().configure({
    logger: console,
    authFactory: localNetAuthDefault,
    ledgerFactory: localNetLedgerDefault,
})

await sdk.connect()

const transaction = {
    preparedTransaction: 'encoded-transaction-bytes-base64',
    preparedTransactionHash:
        'hash-of-the-encoded-transaction-that-needs-to-be-signed',
    hashingSchemeVersion: 'hashing-scheme-version',
}
const publicKey = 'your-public-key-here'
const signature = 'your-signed-transaction-hash-here'

sdk.userLedger?.executeSubmission(transaction, signature, publicKey, v4())