STORE's BlockFinBFT consensus to use the Unspent Transaction Output model (UTXO) popularized by Bitcoin
STORE moving away from Account model to UTXO model to achieve higher performance.
In this document we discuss the UTXO model for transactions in the STORE Chain. Previously, we intended to use the Account model, but during the implementation of BlockfinBFT consensus, we observed the following performance-related issue.
Why?
Because of the leaderness nature of the consensus protocol, we opted for the append-only database model in order to avoid implementing the conflict resolution logic when multiple miners update the same database record. This means, the “account” cannot be modeled as a single record where the account balance is updated based on the transactions from/to it.Instead, the account balance is maintained as a series of records, one each for the block in which transactions from/to this account are finalized. Over time, this scheme results in unnecessary data (although we can argue that this scheme preserves the history of account balances over time). To retrieve the latest account balance, we need to get the latest block in which a transaction from/to this account was finalized. This can be expensive if the account has thousands of transactions. So, in this proposal we are pondering if the UTXO model offers better performance.
UTXO Model
The following diagram illustrates the UTXO model. In this traditional model, popularized by Bitcoin:
- An address has some unspent balance.
- A transaction can be created to transfer some or all the unspent balances from one more unspent addresses to one or more other addresses. In the illustration below, the first transaction transfers amounts 10, 15, and 5 to 3 other addresses. The remaining unspent balance (of 70) is transferred to a new address, unless the sender specifies an address to return the unspent balance to. Note that the original address would have zero balance once this transaction is finalized, unless that address is used to return the unspent balance.
- All addresses that received the amounts are eligible for creating transactions to transfer funds to other addresses. In the following example, transactions 2 and 3 continued to transfer funds to other addresses, leaving a final balance of 40. But notice that after a transaction is finalized, the original addresses have zero balances unless they are used to return unspent balances.
STORE UTXO model
UTXO Transaction Model
UTXO transactions are modeled using the following 2 database tables.
Transaction Output Table (TO_table)
The transaction output table stores addresses and their balances. The following schema defines this table
Field
Data Type
Description
address
String, 32 + 2 bytes
1x, followed by 32 byte address1
balance
BigInt
The Bits this address holds
tx_hash
String, 32 bytes
The hash of the transaction, which produced this output. This is used to verify the legitimacy of this address.
Transaction Output Table Schema
The TO_table is really simple in the sense, it simply captures the funds held in an address and the hash of the transaction that produced that output. Whether this output is “unspent” or not is determined later in the transaction validation phase.
Transaction Table (TXN_table)
Store transactions are modeled as shown below.
Field
Data Type
Description
inputs
Array of [String, 32 + 2bytes]
An array of one or more addresses that can be “spent”. This validation is described below.
input_signatures
Array of [String, 642bytes]
The signatures for each of the inputs
tx_hash
String, 32 bytes
The hash of the transaction, which produced this output. This is used to verify the legitimacy of this address.
Transaction Output Table Schema
1 The exact scheme for addresses is still under discussion. Once the Account vs UTXO decision is made, we can finalize the address format.
2 We will address multisig transactions and signature requirements in a later revision.