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.4 Proof Statement In this section, we will discuss the entire proof statement of our proof of liabilities process. In simple terms, we’ve developed a commitment tree with a specific leaf structure that allows us to make the following proof statement: ”I know a Merkle tree with a public root and nodes, the leaves of which contain data about my user balances. The last right leaf in this tree contains data about the total sum of my liabilities per asset.” There are two important aspects of this proof statement: • I have a Zero-Knowledge Proof (ZKP) for this tree that demonstrates that the data in the last leaf is calculated correctly and that there is no negative balance in any leaf. This ZKP proof allows me to verify the integrity and correctness of the total liabilities without having to reveal the actual amounts.[6] • My users can download the snapshot related to their balances from the website and also get the path to verify that their balances are included in the total liabilities. This allows users to independently confirm that their balances have been taken into account in the proof of liabilities. Based on this approach, as a business, I only need to publish the Merkle root and nodes, not the leaf data. With the ZKP, I prove that my total obligations are included in the last right leaf without having to make this data public. This maintains the privacy of the total liabilities while still allowing users and auditors to verify the correctness of the proof of liabilities. In the Proof of Solvency section, we will revisit the last right leaf and discuss how it aids us in maintaining the privacy of the total liabilities while enabling efficient and correct verification. Note: In implementation, it is advisable to use a Merkle Sparse Tree. This reduces some complexity and makes the circuit process more efficient. 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.4 Proof Statement In this section, we will discuss the entire proof statement of our proof of liabilities process. In simple terms, we’ve developed a commitment tree with a specific leaf structure that allows us to make the following proof statement: ”I know a Merkle tree with a public root and nodes, the leaves of which contain data about my user balances. The last right leaf in this tree contains data about the total sum of my liabilities per asset.” There are two important aspects of this proof statement: • I have a Zero-Knowledge Proof (ZKP) for this tree that demonstrates that the data in the last leaf is calculated correctly and that there is no negative balance in any leaf. This ZKP proof allows me to verify the integrity and correctness of the total liabilities without having to reveal the actual amounts.[6] • My users can download the snapshot related to their balances from the website and also get the path to verify that their balances are included in the total liabilities. This allows users to independently confirm that their balances have been taken into account in the proof of liabilities. Based on this approach, as a business, I only need to publish the Merkle root and nodes, not the leaf data. With the ZKP, I prove that my total obligations are included in the last right leaf without having to make this data public. This maintains the privacy of the total liabilities while still allowing users and auditors to verify the correctness of the proof of liabilities. In the Proof of Solvency section, we will revisit the last right leaf and discuss how it aids us in maintaining the privacy of the total liabilities while enabling efficient and correct verification. Note: In implementation, it is advisable to use a Merkle Sparse Tree. This reduces some complexity and makes the circuit process more efficient. 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.

Too Long; Didn't Read

Make resilience your competitive advantage

Private Proof of Solvency: Proof Statement

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How Merkle Trees Enhance Data Integrity in Crypto Custody

Ceffu Joins Forces With EOS To Deliver Advanced Custody And CeDeFi Opportunities

Future Directions for Proof of Solvency in Digital Assets

Ever Wonder How Crypto Platforms Show They're Solvent?

How UTXOs Keep Your Coins Safe and Sound

How Merkle Trees Enhance Data Integrity in Crypto Custody

Ceffu Joins Forces With EOS To Deliver Advanced Custody And CeDeFi Opportunities

Future Directions for Proof of Solvency in Digital Assets

Ever Wonder How Crypto Platforms Show They're Solvent?

How UTXOs Keep Your Coins Safe and Sound

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps