Stellar Protocol version 10 is going to be released soon. This release brings several changes to the distributed exchange, and introduces a new BumpSequenceOperation.
Bump sequence has been in the work since last October and it was added to simplify writing complex Stellar smart contract workflows. The operation allows to bump forward the sequence number of the source account of the operation. If the sequence number specified in the bump sequence operation is less than the account current sequence number, then the account sequence number will be unaffected. In practice, it means Stellar now includes a no-op operation.
Let’s now look at two use cases for the bump sequence operation.
The first use case for the bump sequence operation is to invalidate previously disseminated transactions that have not yet been submitted to the network (for example because they have a minimum time bound). A Stellar transaction to be valid has to have sequence number that is the successor of the current account sequence number. Increasing the account sequence number will make the network reject all transactions submitted that have a sequence number less than the new one.
In the following diagram, we see two possible workflows for a Stellar account: at the top every transactions increases the sequence number by one to n+t, while at the bottom a single transaction bumps the sequence number to n+k, where n+k > n+t.
As we previously discussed, using a target sequence number that is less than the current one will result in a transaction that does not change the account sequence number. This is what is called a no-op.
This use of the bump sequence operation can be used to add a specific account to the required list of signers of a transaction.
Let’s consider an example smart contract C where we have two pre-authorized transactions: one to merge C into A (call it #1), and one to merge C into B (call it #2). The weights are as follows:
and the thresholds are set to 2. With the current setup, A could send transaction #2 to the network, while we want to transaction #1 to be submitted only by A, and transaction #2 only by B. Let’s ignore that it does not make economic sense for B to send #1 and for A to send #2.
If we change the definition of transaction #1 to:
and transaction #2 to:
then transaction #1 can only be sent to the network by A and transaction #2 by B. Mission accomplished!
In this post we looked at one of the new features in version 10 of the Stellar Protocol. While the bump sequence operation does not introduce any new feature, it makes it more convenient to build smart contracts with Stellar.