Authors:
(1) Hamid Bateni, Nobitex Labs (hamid@europe.com);
(2) Keyvan Kambakhsh, Nobitex Labs (keyvankambakhsh@gmail.com). Table of Links 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 2.3 Leaves Structure 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. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Hamid Bateni, Nobitex Labs (hamid@europe.com); (2) Keyvan Kambakhsh, Nobitex Labs (keyvankambakhsh@gmail.com). Authors: Authors: (1) Hamid Bateni, Nobitex Labs (hamid@europe.com); (2) Keyvan Kambakhsh, Nobitex Labs (keyvankambakhsh@gmail.com). Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Proof of Liability and 2.1 Commitment 2 Proof of Liability and 2.1 Commitment 2.2 Merkle Tree 2.2 Merkle Tree 2.3 Leaves Structure 2.3 Leaves Structure 2.4 Proof Statement 2.4 Proof Statement 3 Proof of Reserve 3 Proof of Reserve 3.1 Ethereum 3.1 Ethereum 3.2 Bitcoin 3.2 Bitcoin 4 Proof of Solvency 4 Proof of Solvency 5 Future Works and References 5 Future Works and References 2.3 Leaves Structure 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. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Understanding Leaf Structures: How Merkle Trees Maintain Privacy in Liabilities

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Assessing VASP Solvency For Cryptoassets: A Closer Examination

Blockchain’s Impact on the Global Economy and the Role of Custody

Introducing Private Proof of Solvency

The Role of Commitment in Proof of Solvency

How Merkle Trees Enhance Data Integrity in Crypto Custody

Private Proof of Solvency: Proof Statement

Assessing VASP Solvency For Cryptoassets: A Closer Examination

Blockchain’s Impact on the Global Economy and the Role of Custody

Introducing Private Proof of Solvency

The Role of Commitment in Proof of Solvency

How Merkle Trees Enhance Data Integrity in Crypto Custody

Private Proof of Solvency: Proof Statement

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps