Self-Contained Proofs 📦

[rmnblm]

Dear valued Bazonians 👋

In this pull request, I present self-contained proofs (SCPs) -- a new paradigm that is designed to improve scalability of blockchain protocols, while preserving security and decentralization. Instead of all nodes having a local copy of the whole blockchain to verify a transaction, nodes can derive the validity of a transaction by only using block headers of the chain.

The utilization of self-contained proofs simplifies the recognized issues in scaling, especially in a sharded environment, see my previous paper showcasing a sharding concept for the Bazo blockchain.

Example

Consider a blockchain as shown below. Assume that a user was the receiver of 100 coins in transaction F3 and sender of 50 coins in transaction F6. The user wants to spend the remaining 50 coins, disregarding previous transaction fees. A self-contained proof must contain two Merkle proofs, one for each transaction F3 and F6, i.e., SCP = {Proof_1, Proof_2}, where Proof_1 = {F5, F6, B2} represent the proof where the user was sender of coins and Proof_2 = {F3, F4, A1} represents the proof where the user was the receiver of coins.

Prerequisites

Before presenting the design of self-contained proofs, let's revisit two crucial concepts of the Bazo blockchain.

Merkle proofs

Every block header contains a Merkle root obtained from a Merkle tree. A Merkle tree creates a single value (the Merkle root) that proves the integrity of all transactions by hashing correspondent nodes together and climbing up the tree until the root hash is obtained. As long as the root hash is publicly known and trusted, it is possible for anyone to use a Merkle proof to verify the position and integrity of a transaction within a block, since it is computationally infeasible to guess a transaction hash that results in a particular root.

Bloom filters

Every block (header) in the Bazo blockchain contains a Bloom filter. A Bloom filter is a space-efficient data structure that provides a fast way to check the existence of an element in a set and returns true or false as a result, defined by the false-positive probability of a Bloom filter.

Types of Proof

Since Bloom filters are probabilistic data structures, we must distinguish between true-positive and false-positive proofs.

• True-Positive Proof (TPP) A true-positive proof is a type of Merkle proof that proves the existence of a transaction in a block, i.e., the Bloom filter of a block returns true if one (or more transactions) for a specific address are part of the block.

• False-Positive Proof (FPP) A false-positive proof is a type of Merkle proof that proves the non-existence of a transaction in a block, i.e., the Bloom filter of a block returns true even if no transaction for a specific address is part of the block. A false-positive proof consists of two Merkle proofs.

Transaction Buckets

I introduce the new transaction bucket data structure, short TxBucket, which consists of the properties

• Address: The address of a unique sender or receiver within a block.
• RelativeBalance: The sum of all transaction amounts by this address in a single block.

This data structure is required to support multiple transactions per address per block and to mitigate fraudulent proofs.

Let's take a look at an example. Consider the following scenario with accounts 0x01, 0x02 and 0x03. Further assume the following transactions, all included in a single block:

• From: 0x02, To: 0x01, Amount: 50
• From: 0x03, To: 0x01, Amount: 50
• From: 0x01, To: 0x02, Amount: 75
• From: 0x01, To: 0x03, Amount: 10

This scenario would lead to three transaction buckets in a single block with the following property values:

• Address: 0x01, RelativeBalance: +15 (received 100, spent 85)
• Address: 0x02, RelativeBalance: +25 (received 75, spent 50)
• Address: 0x03, RelativeBalance: -40 (received 10, spent 50)

As mentioned before, a block contains a Merkle root which previously was constructed from all transaction hashes, i.e., ConfigTx, StakeTx, ContractTx, and FundsTx. With the introduction of TxBuckets, the Merkle root of a block is now constructed from the hashes of ConfigTx, StakeTx, ContractTx and TxBucket.

Structure

A self-contained proof is an array of Merkle proofs attached to a FundsTx. For this purpose, I introduced the MerkleProof data structure, i.e.,

type MerkleProof struct {
	Height uint32
	MerkleHashes [][33]byte
	BucketAddress AddressType
	BucketRelativeBalance int64
	BucketMerkleRoot HashType
}

containing the properties

• Height: The height of the block this Merkle proof was created for.
• MerkleHashes: These are the intermediate hashes to obtain the Merkle root. Note that it is an array of 33-byte-long values, where the first byte determines whether it was a left or right node in the Merkle tree, and the rest (32 bytes) is the actual hash. Creating the array in code here, verifying the array in code here.
• BucketAddress, BucketRelativeBalance and BucketMerkleRoot: These properties are the properties of a TxBucket we want to proof at a specific Height. Hashing these three properties together results in the same hash as calling the Hash() function of a transaction bucket.

Proof Calculation

Proofs are created by the bazo-client, which are explained here.

Proof Verification

A self-contained proof is used to determine a verified balance that goes from the current block until the genesis block. By comparing the verified balance with the amount a user want to spend in a funds transaction, we can determine whether the transaction is valid or not and with the introduction of TxBuckets, a user can include multiple transactions in a single block. However, a user only has to provide one self-contained proof for all transactions in a single block, because the derived verified balance should be equal for all proofs. Thus, a miner verifies the first self-contained proof in a bucket and derives the verified balance. Using this verified balance, the miner can conclude if the sum of the verified balance and the relative balance of the bucket is greater or equal to 0, you can check this process in code here.

Limitations

• False-Positive Proofs are not implemented yet, placeholders are in code. This is future work, e.g., by using a false-positive-free Bloom filter.
• Self-contained proofs are only implemented for testing purposes, failing SCPs do not invalidate a block, it only spits out an error message in the console.

Future Work

• Security Considerations The concept of self-contained proofs has been implemented as a proof-of-concept in Bazo. However, a rigorous security analysis to identify potential threats is crucial before using SCPs in production. We leave this analysis to future work.

• Proof Size The size of a self-contained proof in a transaction could potentially become very large when a user has to provide many small transactions in order to spend a large amount of coins in a single transaction. One way to solve this problem is to introduce checkpoints to the blockchain. Another way is to let SCPs refer to previous SCPs instead of the whole history of past transactions. We leave to future work the exploration and implementation of alternative ways to reduce the proof size.

• Sharding We are currently exploring ways to implement self-contained proofs into a sharded blockchain environment. We may consider Merkle Patricia trees when smart contracts and other additional state comes into play.

Final Words

This project was submitted in fulfillment of the requirements for the degree of Master of Science in Engineering. A paper with formal definitions will be uploaded shortly and mentioned here.

Happy Holidays 🎄
Roman