Corda — Can transaction batching benefit performance?

Yes, you got it correct. Transaction batching is possible in Corda Flow (please don’t confuse it with Bitcoin Transaction Block). This is not officially recommended by Corda, but it can be achieved. The transaction batching exploration was conducted to measure performance benefits and guess what…. it really worked !!!!

In Corda, each Flow thread carries a business transaction, which creates a new state by either consuming the old state or issuing a new state. This state can be batched at the application level and sent to Corda Flow so that all the transactions can be committed by making use of a single Flow thread. Let’s see how this works.

Two ways to batch transactions in Flow:

1. Single transaction builder creating multiple states.
2. Multiple transaction builder for multiple states.

Single Transaction Builder

For this exploration, we will use the sample example of IOUState. Let’s create multiple IOUStates for a single transaction builder as shown below. The only assumption here is we have the common type of transaction batched together.

Single transaction builder

This will work perfectly fine, until a single transaction fails due to contract verification. Single transaction failure will affect the whole transaction batch and all the transactions will be lost.

Since all the parties involved in the transaction batch need to have visibility of their respective transaction, therefore we need to add all the parties as the participants to the transaction builder. Now this disrupts the core feature of Corda, which is sharing data on a need to know basis. This can also lead to increase in transaction commit time as states will revolve around all the parties in the batch to commit the transaction in their vault.

Conclusion: Transaction batching with single transaction builder can be achieved by assuming all transactions will pass the contract verification; and have the same set of participants, so the transaction visibility is provided to all, without breaking the core feature of data sharing on a need to know basis.

Multiple transaction builder

Let’s create multiple transaction builder to solve the transaction visibility issue and provide more flexibility to Flow in terms of transaction execution. This exploration can be further split into 2 categories.

Create multiple transaction builders in linear style, as described below:

Multiple transaction builder

Although this solves the transaction visibility issues, it retains the batch failure if one or more transaction fails due to contract verification. Here, the developer is again bound to create a batch of fixed set of transactions with the overhead of code duplication. This code duplication and creation of multiple objects can add more latency to the batch processing.

The second and the best approach is to loop through the transaction batch. This will resolve the transaction failure due to contract verification issue and catch all the contract verification failures. We created transaction Flow with a simple for-loop to create multiple transaction builders. Each Flow will return a list of Signed and Failed transactions. All the contract failures will be handled with TransactionVerificationException, and return to the application via return Pair(sucessTx , failedTx) as described below.

Multiple transaction builder with exception handling

Benchmarking Time!

Benchmarking was conducted to compare the performance of single flow with a single business transaction vs single flow with multiple business transactions. In our case, we bundled 10 transactions in a single Flow. The network was built on a VM with 2 Cores CPU and 4 GB RAM for each participant.

The result was quite striking, as for 150 transactions batched in a single Flow thread, we noticed a small performance gain.

The parallel flow execution by using 5 clients for 150 transactions completed in 208sec, whereas the 10 batched transactions (15 flows) with 5 clients took only 175sec.

Note: Experiments were conducted only for issuance flow where we don’t consume any prior states. These findings will differ based on type of transactions, number of participants and number of contract verification rules.

Feel free to shout out for any suggestions or improvements.
Happy Learning !!!