Corda State Reissuance: Break Long Transaction Chain to Improve Performance and Privacy

By Ashutosh Meher, Developer Evangelist at R3

Performance is an important aspect of any enterprise software application. Blockchain is seen as the next big thing that could change the way we transact in the near future. However, blockchains are slow. This is one of the major reasons why businesses are skeptical about using a blockchain-based system in a major way.

One major performance setback is the need for backchain validation. It means that in order to validate the current transaction, one must validate the history of the asset involved in the transaction. And since blockchain is a continuously growing chain, you can see where it’s going.

Long backchain and Corda

Transactions in Corda reference input states which are created by the prior transactions. This creates a transaction backchain over time. As the backchain grows, the backchain validation becomes a performance overhead.

To make matters worse, it also poses a privacy concern. Privacy is a major focus area for Corda—it was designed to allow participants in a Corda network to transact privately while benefiting from the advantages of DLT. Thus solving this issue was of utmost importance.

Reissuing states

The solution is rather simple; it just requires a trusted party to reissue the state. The state could simply be exited from the ledger and reissued, as it would purge the transaction backchain and you would have a brand new state with no reference to the historical data.

However, there is a small problem: there is no guarantee that the issuer would reissue the state after it is exited. If the issuer fails to reissue the state (for whatever reason) after the original state is exited, one will be left with no usable instance of the state.

Corda 4.7 introduced a new reissuance functionality that solves this problem. It is achieved by locking the reissued state using Corda’s encumbrance feature. The reissued state can only be unlocked once the original state has been exited.

How it all works

The above diagram represents the series of steps involved in reissuing a state in Corda. To make things simple for developers, Corda provides the reissuance CorDapp which implements most of the functionality. All developers need to do is call the appropriate flow.

• To start with, the requesting party sends a reissuance request to the issuer.
• An optional step might be required if the issuer doesn’t have access to the transaction history. The requesting party could send the transaction history to the issuer for verification purposes.
• The issuer has two options: accept or reject the request.
• The rejection case is pretty simple: the issuer simply rejects the request and no reissuance of the state happens.
• In case the issuer chooses to accept the request, they generate an encumbered copy of the original state. The encumbrance is a locked state with status active. It ensures that the reissued state cannot be spent until the original state is exited.
• Once the reissuance has been accepted, the issuers can exit the original state and proceed to unlock the reissued state, which encumbers the reissued state and allows it to be spent freely.
• There might be a scenario where the original state has been spent after the reissuance request was accepted, which means that the reissued state is outdated. In such a case the reissued state cannot be unlocked and the requesting party can exit the reissued state and create a new reissuance request instead.

Source code

Below is a sample CorDapp that implements a simple reissuance case. Check it out:

https://github.com/corda/samples-java/tree/master/Features/state-reissuance

I hope this answers some of the questions about handling long backchain and improving performance and privacy in Corda. Thanks for reading.