Understanding Leaf Structures: How Merkle Trees Maintain Privacy in Liabilities

:::info Authors:

(1) Hamid Bateni, Nobitex Labs ([email protected]);

(2) Keyvan Kambakhsh, Nobitex Labs ([email protected]).

:::

Abstract and 1 Introduction

2 Proof of Liability and 2.1 Commitment

2.2 Merkle Tree

2.3 Leaves Structure

2.4 Proof Statement

3 Proof of Reserve

3.1 Ethereum

3.2 Bitcoin

4 Proof of Solvency

5 Future Works and References

Until now, we have discussed how we can commit to a list of data by using a hash tree, specifically, a Merkle tree. Now let’s delve into the structure of the data we are committing to.

\ In our commitment to data via a Merkle tree, each leaf (except the last right leaf) contains key-value pairs of data:

\

\ The ’User Identifier’ is a unique identifier for each user. The ’Asset Identifier’ refers to the identifier for each asset. For example, in the Ethereum network, we consider the zero address as the identifier for ETH, and for each token, we consider their token address as the identifier. The ’amount’ is the balance the user holds of that specific asset according to the business database that wants to prove their liabilities amount.

\ This approach to committing to our liabilities is similar to other proof of solvency approaches. However, traditionally, committing to our liabilities in this way would require us to make our total liabilities public. To prove the correctness of the sum, we would need to enlist the help of an auditor firm or use Zero-Knowledge Proofs (ZKP). But in doing so, we would have to reveal our total liabilities.

\ The approach we’re introducing allows the total liabilities to remain private. Let’s explain how this is achieved by discussing the last right leaf of our Merkle tree:

\

\ The Total Balance is the sum of the balances of all users for a specific asset (Asset1: user1 balance + user2 balance + …).

\ We then use a ZKP protocol to create a circuit and leverage the characteristic of verifiable computation to prove that the total sum in the last right leaf is calculated correctly by adding previous leaves related attributes and that there is no negative balance in any leaf.

\ So now, we commit to a liabilities tree that includes all of our user liabilities. We also hold the total amount we commit to and have a proof for the correctness of the entire tree and calculation, without revealing the total amount of our liabilities. This allows us to maintain privacy while still proving our solvency.

\

:::info This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license.

:::

\