ZooBC wiki
Transactions

One transaction per account per block, and batches

From version 0.5.8 a simple validity rule applies to every block: it may carry at most one transaction from each account. To do many things at once, an account uses a batch, one transaction that carries several actions of one kind. Together the two rules keep the checks that nodes make before a block exact, while still letting a busy account pay many people inside a single block.

The rule

The account here is the signing address. A block that carries two transactions from the same address is invalid on every node, so an honest producer never builds one. Producers take each account's oldest eligible transaction first and leave the next one for a later block, 15 seconds on.

A queue of transactions from sender A entering blocks N, N+1 and N+2 one per block, oldest first, while transactions from senders B and C fill the same blocks
A queue of transactions from sender A entering blocks N, N+1 and N+2 one per block, oldest first, while transactions from senders B and C fill the same blocks

An account can still submit several transactions in a row. A node's pool holds up to 50 pending transactions per sender (a local policy of each node), and producers include them one per block, oldest first.

Two details follow from the definition:

  • each member of an account group has its own slot, because each member signs with its own address, even though the members share one balance;
  • when a multisignature account's inner transaction runs, it counts for the multisignature account.

Why it helps

A node checks a transaction against the confirmed state twice: when it admits it into its pool, and when it assembles a block. With one transaction per account, no other transaction from the same account can change that state inside the block. The check therefore stays exact for everything that only the sender controls, such as its own balance and its own objects.

Between different accounts, the first transaction applied wins. If two accounts try to take the same swap offer, the first one gets it, and the second has become pointless: it is a paid no-op that pays its fee and does nothing else (see transactions). Honest producers leave such transactions out. There is no separate rule per object.

Batches

A batch is one transaction that carries several actions of one kind. Three kinds exist:

  • ZBC payments, up to 25 in one batch;
  • token transfers, up to 32, of any tokens, with the fee paid in ZBC;
  • storage proofs, up to 1,000, one batch per node per storage epoch (see decentralised storage pool).

A batch is all or nothing. Every action is checked up front, so either every payment in it happens or none does, and the whole batch is signed once.

What a batch costs

Several actions pay as several transactions. A batch's minimum fee is the sum of the minimum fees its actions would pay as separate transactions: a base fee for each action plus each action's byte charge (see fees), with the batch's message charged only once. Three payments without a message cost the same in one batch as in three single transactions. A batch of storage proofs pays nothing: each storage proof is a fee-free duty, so the sum is zero.

Three separate payments, each with its fee, equal one batch of three payments carrying the same three fees, marked all or nothing and signed once
Three separate payments, each with its fee, equal one batch of three payments carrying the same three fees, marked all or nothing and signed once

What a batch saves is mostly work for the network, not fees: one signature to verify and one slot in the block instead of three. And it is the way for one account to pay many recipients in the same block.

See also