HIP-551: Batch transactions

Abstract

This HIP defines a mechanism to execute batch transactions such that a series of transactions(HAPI calls) depending on each other can be rolled into one transaction that passes the ACID test (atomicity, consistency, isolation, and durability)

Motivation

The existing implementation of transactions in the Hedera network does not allow multiple different HAPI transactions to be called in one single network transaction that would have all the ACID properties. This makes it impossible to create more complicated flows without using smart contracts (which do not support all the HAPI transactions at this point) and listening to the mirror node to check the status of the previous transaction. This way we can also achieve an abstraction away from smart contracts.

Rationale

Atomic transactions chain is from the protobuf point of view just a list of SignedTransactions that’s, why we based our new protobuf message on it, we only have to change the bodyBytes field to be repeated, that way we can store there multiple transaction bodies, SignatureMap sigMap can stay unchanged because it’s defined as repeated SignaturePair sigPair.

User stories

1. As a Hedera token service user, I want to be able to unfreeze an account, send an NFT, and freeze it again in one ACID transaction, that way I can achieve an account-bound NFT(nontransferable NFT) collection, without using the hedera smart contract service. We can use nontransferable NFTs e.g. as someone’s achievements, the creation of digital references, etc.

2. As a Hedera token service user, I want to be able to unfreeze an account, send an FT and freeze it again in one ACID transaction, that way I can achieve an account-bound FT(nontransferable FT) collection, without using the hedera smart contract service. We can use nontransferable FT e.g. as game points, reputation points, etc.

3. As a Hedera token service user, I want to be able to wipe a token, mint a token, and transfer a token in one ACID transaction. That way a backend developer could create complicated flows without the need to use smart contracts and the need to handle partially successful flows in the backend, e.g. the wipe transaction was successful but the mint transaction was not.

4. As a Hedera service user, I want to be able to create batch transaction, that use multiple Hedera services e. g. I want to be able to wipe a token, mint a token, transfer a token, and submit a topic message in one ACID transaction. That way a backend developer could create complicated flows without the need to use smart contracts and the need to handle partially successful flows in the backend, e.g. the wipe transaction was successful but the mint transaction was not.

5. As a Hedera token admin, I want to be able to gift Alice some tokens. I want to be able to mint and transfer the tokens in a single transaction.

6. As a Hedera token owner, I want to be able to wipe tokens from an account that I revoked the KYC. I want to be able to grant KYC, wipe tokens and revoke KYC in a single transaction.

Specification

Transaction Integrity

1. Each inner transaction within a batch should be treated as a self-contained transaction, unaware of its batch context.
2. If an inner transaction fails, all preceding inner transactions that succeeded still have to pay, even if their effects are not committed.
3. Inner transactions are individually signed regular transactions indicating that once a person signs an inner transaction, they have agreed to its outcome.

Batch Signatures

Each transaction must be individually signed. Signatures on the batch itself are unique to the batch and don’t represent the inner transactions within. This way:

• It’s impossible for inner transactions to be rearranged post-signature.
• Batch transactions are not designed to solve a problem for retail users but rather for developers and dApps. When someone signs a transaction, they individually agree to the outcome, thus the individual transaction signers within the batch need not sign the batch itself.

Handling Inner Transactions

Inner transactions, by design:

1. Are signed individually.
2. Each pays for itself (node + network + service fees).
3. Have their own payer.
4. Are deduplicated on an individual basis.
5. Are authorized solely by their keys; batch keys are not used.
6. If one of the inner transactions has a child transaction, the parent transaction is in the batch, and the batch isn’t successful, then the child transaction should also be reverted.

The batch:

1. Has its own payer and signatures.
2. Considers inner transactions as part of its signed bytes.
3. Makes the batch payer cover node+network fees for handling the batch, excluding inner transaction fees.
4. Has deduplication based on its unique transaction ID.
5. The submitter does not need to be authorized to carry out all the inner batch transactions. As with every transaction in Hedera, where the submitter can be any account as long as the transaction is properly signed.
6. The standard max transaction size must be respected.

We could create a new protobuf message based on SignedTransaction message:

message BatchTransaction {
    /**
    * TransactionBodies serialized into bytes, which must be signed
    */
    repeated bytes bodyBytes = 1;

    /**
     * The signatures on the body with the new format, to authorize the transactions
     */
    SignatureMap sigMap = 2;
}

Backwards Compatibility

Security Implications

As part of ensuring the integrity of batched transactions, certain security measures are emphasized:

1. Inner transactions within a batch cannot be reordered post-batch-signature.
2. All signatures on the batch pertain solely to the batch and not the inner transactions.

How to Teach This

Reference Implementation

Rejected Ideas

We rejected the idea to add the support of conditional branching to the batch transactions, because we don’t think it’s useful compared to the increase of complications in implementing the HIP.

Open Issues

References

Copyright/license

This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

Citation

Please cite this document as: