Self-Contained Proofs 📦

[rmnblm]

Hey there Bazo community 👋

This is the complementary PR for the implementation of self-contained proofs in the bazo-miner.

Proof Calculation

The client of the Bazo blockchain plays an important role for self-contained proofs. A user is only able to create a self-contained proof if it can provide one Merkle proof for each transaction it was involved in. In other words, a user needs to keep track of all transactions where the sender or the receiver of the transaction equals to the user's address. The client software of the blockchain must be adapted to these requirements. We distinguish between always-on and just-in-time client software which we discuss below.

• Always-On: maintains a constant connection to the network and receives all blocks sent through the network. This type of software is recommended for users which extensively interact with the network, i.e., users commonly sending or receiving transactions to or from the network respectively. This way, the list of Merkle proofs is always up-to-date and transactions can be sent very quickly, with the downside of having to run the software without interruption.
• Just-In-Time: downloads block headers and processes Merkle proofs just before a new transaction is sent to the network. The client software does not have to run constantly, however, it results in a delay if for example a user casually sends transactions and is far behind the current state of the blockchain. The process of saving a Merkle proof to local storage is identical as in always-on client software.

I decided to implement a just-in-time mechanism. When the command line is executed to send a FundsTx to the network, the client first syncs with the blockchain (in code here and here)

Upon receiving a block, the algorithm processes as follows:

• Check if the block has already been processed. If yes, stop the algorithm, otherwise continue.
• Query the Bloom filter by the user's address. If it returns false, the block contains no transactions where the user is involved in, i.e., the user is neither sender or receiver of a transaction. If it returns true, continue.
• Download all funds transaction from a miner, find the transactions where the user was either sender or receiver, add these transactions to a TxBucket and calculate the hash of the bucket. Using this hash, the client can then request all intermediate hashes of the block's Merkle tree and to finally derive the Merkle proof that can be stored in the local database.

Proof Verification

Proofs are verified by the bazo-miner, which are explained here.

Limitations

• False-Positive Proofs are not implemented yet, placeholders are in code.
• The client still relies on a miner to create a Merkle proof: If a Bloom filter returns true, the client has to download funds transactions in order to locally create a TxBucket, derive the hash of it and further download the intermediate hashes of the miner. These are all necessary steps to create a single Merkle proof.

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