link table
Summary and 1 Introduction
2 Proof of Responsibility and 2.1 Commitment
2.2 Merkle Tree
2.3 Leaf structure
2.4 Attestation Statement
3 Proof of reserve
3.1 Ethereum
3.2 Bitcoin
4 Proof of ability to pay
5 Future research and references
3.1 Ethereum
Ethereum is a public blockchain protocol that uses an account-based model for its accounting system. This model is a key aspect of Ethereum’s architecture and enables a wide range of financial transactions and applications.
The protocol distinguishes between two types of accounts: Externally Owned Accounts (EOA) and Contracted Accounts. EOA is controlled by a private key and is used for simple transactions. Contract accounts, on the other hand, are managed by internal code and are used to create smart contracts.
Ethereum also introduced the concept of a virtual machine (VM), specifically the Ethereum Virtual Machine (EVM). EVM is a runtime environment that executes smart contracts on the Ethereum network. These smart contracts are self-executing contracts with terms and conditions written directly into the lines of code.
These features make Ethereum an extremely powerful platform for a wide range of decentralized applications, including but not limited to financial applications.
In addition to the account-based model and the Ethereum Virtual Machine (EVM), Ethereum employs a data structure called the Merkle Patricia Tree (MPT) to manage the state of the entire blockchain network. A key component of Ethereum’s architecture, the world state is represented by MPT and allows efficient storage and retrieval of account information, balances, and smart contract data. MPT is a critical data structure that strengthens the integrity and security of the Ethereum blockchain by providing a tamper-proof method of organizing and updating network state, allowing for rapid verification and validation of transactions and contracts. . This combination of MPT and EVM forms the backbone of Ethereum’s decentralized ecosystem, making it easy to create and run complex, secure, and transparent applications. (8)
3.1.1 World State and MPT
The Ethereum world state is the global state of the Ethereum system and is made up of many small objects known as accounts. Each account is a data structure containing four fields: nonce, balance, storageRoot, and codeHash. nonce is a scalar value equal to the number of transactions sent from this address, balance is a scalar value equal to the number of Weis owned by this address, and storageRoot is a 256-bit hash of Merkle Patricia’s root node. codeHash is a hash of the EVM code for this account.
Merkle Patricia Trie (MPT) is a cryptographic data structure that maps keys to values. In the Ethereum context, MPT is used to map addresses to account states. It is a modified version of the Patricia Try and Merkle tree, hence the name. There are three types of nodes in MPT: leaf nodes, extension nodes, and branch nodes.
Leaf nodes and extension nodes are similar in that they both contain a path and a value. The difference lies in what the values represent. On leaf nodes, the value is the state of the account, while on extension nodes, the value is a hash of the next node. The branch node contains 17 items. The first 16 items point to other nodes in the try, and the 17th item contains the value of the account state if the key ends at this node. The root hash of an MPT is a cryptographic hash of all the data in the trie and is stored in the header of each block. This allows data to be verified quickly and efficiently.
By using MPT, Ethereum can efficiently store the state of the entire system and quickly retrieve, update, and verify parts of it. This is critical to maintaining the integrity and performance of the Ethereum network.
3.1.2 GetProof method
The Ethereum JSON-RPC API provides the eth getProof method, a function used by Ethereum execution nodes. This method requires an address, an array of storage keys, and a block identifier as arguments, and then returns an object containing information about the account and its storage.
The data returned includes the account balance, nonce, storage hash, and code hash, supplemented by a list of nodes (in Recursive Length Prefix (RLP) format) that form proof of the specified account and its storage. will be done. (4)
This proof essentially consists of a subset of the Merkle Patricia Tries (MPT) required to verify the data in your account. This includes the MPT nodes along the path from the root to the account node and, if a storage key is specified, to the storage node. This proof allows you to independently verify the accuracy of data in your account and that it is included in the state of a given block.
The path within the MPT is determined by the address of the account used as the key for the try. The path to the key is a series of nibbles (half-bytes) derived from the key.
Verifying the proof involves starting at the root node of the MPT and following the path specified by the key. Each step involves comparing the hash of the node to the hash expected in the proof. If all hashes match and the path leads to the expected account data, the proof is verified.
This mechanism allows the state of an account to be verified in a specific block without accessing the entire Ethereum state, a feature that greatly increases the scalability and efficiency of the Ethereum network.
3.1.3 Eth balance proof
Based on the information in the previous section, we can see that Ethereum addresses are mapped to specific data within the Ethereum World State via Merkle Patricia Tries (MPT). Account balances are one such data point that is mapped.
To prove that a certain address holds at least a minimum amount of Ether, you can design a zero-knowledge proof (ZKP) circuit in the following way.
Our circuit has two public inputs.
• Minimum amount
• Block root
And some private input:
• MPT certification path
• Account data
• Block header data
The circuit to prove the minimum balance of eth should follow the following flow:
1- Hash account data
2- Insert hash into MPT path
3- Check MPT path
4- Insert the calculated route as a state route along with other block header data.
5- Calculate block hash based on block header data
6- Compare the calculated block hash with the public block root. If they match, it means that the data of the account in a particular block was correctly proven
7- The final step is to check if the balance in your account data is greater than or equal to the published minimum amount.
After following all the steps of the ZKP circuit, you can prove that a given address holds at least the minimum Ether balance without exposing the address itself to others.
To implement the described flow in a ZKP circuit, certain functionality must be implemented in the zkp circuit. These include the Kecck hash function, Recursive Length Prefix (RLP) encoding, and MPT validation.
The Keccak hash function is a cryptographic hash function used in Ethereum for various purposes, including calculating block hashes and hashes of account data and MPT nodes. Implementing this function in your circuit is important for validating MPT paths and block hashes.
Recursive Length Prefix (RLP) encoding is a space-efficient object serialization scheme used by Ethereum. Used to encode block header data and account data. Implementing RLP encoding in your circuit allows you to properly handle these data structures.
Finally, MPT validation is required to check the validity of the MPT certification path. This involves following the path specified by the account’s address and matching each node’s hash with the expected hash in the proof.
3.1.4 ERC20 Balance Proof
While Ether balance proofing involves validating the state MPT of the specific address you want to prove, ERC20 balance proofing involves the additional step of validating the contract storage of keys associated with the address.
ERC20 tokens are implemented as smart contracts on the Ethereum platform. The balance of ERC20 tokens for each address is stored in the storage of the contract, not in the account state as in the case of Ether. Therefore, to prove your ERC20 balance, you need to access and verify your contract storage.
Storage of contracts is a separate MPT, where each key-value pair is a mapping of addresses to balances. To prove a specific ERC20 token balance, you must first generate proof of contract storage. This can be done using the eth getProof method by providing the key associated with the specific address you want to prove. This will return proof that you can commit the value of the token balance for that address.
Once you have this proof of contract storage, verify the state MPT of the contract address, not the address you want to certify. This includes hashing the contract account data, inserting the hash into the MPT path, validating the MPT pass, and checking whether the calculated balance in the contract storage proof matches the published minimum amount.
To summarize, the main differences in ERC20 proof of balance are the added ability to validate contract storage via its own MPT and the ability to use contract addresses to validate state MPTs. This allows you to prove that a particular address holds at least a minimum ERC20 token balance without revealing the address itself, providing evidence of ERC20 token privacy protection.
