From 70d44cb96b7f206a86e86bb850f85defb7f56098 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 11:15:50 +0200 Subject: [PATCH 01/19] Create eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 54 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 EIPS/eip-eth_getProof.md diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md new file mode 100644 index 00000000000000..1b602fe4fd36b0 --- /dev/null +++ b/EIPS/eip-eth_getProof.md @@ -0,0 +1,54 @@ +--- +eip: +title: +author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> +discussions-to: +status: Draft +type: +category (*only required for Standard Track): +created: +requires (*optional): +replaces (*optional): +--- + + +This is the suggested template for new EIPs. + +Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. + +The title should be 44 characters or less. + +## Simple Summary + +If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP. + +## Abstract + +A short (~200 word) description of the technical issue being addressed. + +## Motivation + +The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright. + +## Specification + +The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). + +## Rationale + +The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> + +## Backwards Compatibility + +All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +## Test Cases + +Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. + +## Implementation + +The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From d5208ce9894796982508d23dbcbd926e6ea49650 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 11:53:00 +0200 Subject: [PATCH 02/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 1b602fe4fd36b0..c21f5922b87004 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -1,37 +1,42 @@ --- eip: -title: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> -discussions-to: +title: eth_getProof +author: Simon Jentzsch , Christoph Jentzsch +discussions-to: simon.jentzsch@slock.it status: Draft -type: -category (*only required for Standard Track): -created: -requires (*optional): -replaces (*optional): +type: Standards Track (Core, Networking, Interface, ERC) +category : Interface +created: 2018-06-24 --- -This is the suggested template for new EIPs. - -Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. - -The title should be 44 characters or less. ## Simple Summary -If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP. + +One of the great feature of Ethereum is the fact, that you can verify all data of the state. But in order to allow verification of accounts outside the client, we need a additional function delivering us the required proof. These proofs are important to secure Layer2-Technologies. + ## Abstract -A short (~200 word) description of the technical issue being addressed. + +Ethereum uses MerkleTrees to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently the eth-Module does not give you access to these proofs. This EIP suggests a additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. + +Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. This allows especially IOT-Devices or even mobile apps which are not able to run a light client to verify responses from a untrusted source. ## Motivation -The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright. + +In order to create a MerkleProof access to the full state is required. The current RPC-Methods allow a application to access single values (`eth_getBalance`,`eth_getTransactionCount`,`eth_getStorageAt`,`eth_getCode`), but it is impossible to read Information about the MerkleTree storing these values through the standard RPC-Interface. + +Today MerkleProofs are already used internally. For example the [Light Client Protocol](https://github.com/ethereum/wiki/wiki/Light-client-protocol) supports a function creating MerkleProof, which is used in order to verify the requested account or storage-data. +Offering these already existing function through the RPC-Interface as well would enable Applications to store and send these proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. + + ## Specification + The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). ## Rationale From 4c01600b57e5cad50fd6760f401ed2eae120cf15 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 13:09:44 +0200 Subject: [PATCH 03/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 80 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 77 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index c21f5922b87004..cef808b5886698 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -29,15 +29,89 @@ Combined with a stateRoot (from the blockheader) it enables offline verification In order to create a MerkleProof access to the full state is required. The current RPC-Methods allow a application to access single values (`eth_getBalance`,`eth_getTransactionCount`,`eth_getStorageAt`,`eth_getCode`), but it is impossible to read Information about the MerkleTree storing these values through the standard RPC-Interface. -Today MerkleProofs are already used internally. For example the [Light Client Protocol](https://github.com/ethereum/wiki/wiki/Light-client-protocol) supports a function creating MerkleProof, which is used in order to verify the requested account or storage-data. +Today MerkleProofs are already used internally. For example the [Light Client Protocol](https://github.com/zsfelfoldi/go-ethereum/wiki/Light-Ethereum-Subprotocol-%28LES%29#on-demand-data-retrieval) supports a function creating MerkleProof, which is used in order to verify the requested account or storage-data. Offering these already existing function through the RPC-Interface as well would enable Applications to store and send these proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. - ## Specification -The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). +As Part of the eth-Module, a additional Method called `eth_getProof` should be defined as following: + +#### eth_getProof + +Returns the account- and storage-values of the specified account including the merkle-proof. + +##### Parameters + +1. `DATA`, 20 Bytes - address of the storage. +2. `ARRAY`, 32 Bytes - array of storage-keys which should be proofed and included. See [`eth_getStorageAt`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getstorageat) +3. `QUANTITY|TAG` - integer block number, or the string `"latest"`, `"earliest"` or `"pending"`, see the [default block parameter](https://github.com/ethereum/wiki/wiki/JSON-RPC#the-default-block-parameter) + +##### Returns + +`Object` - A account object: + + - `balance`: `QUANTITY` - the balance of the account. See [`eth_getBalance`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getbalance) + - `codeHash`: `DATA`, 32 Bytes - hash of the code of the account. For a simple Account without code it will return `"0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"` + - `nonce`: `QUANTITY`, - nonce of the account. See [`eth_getTransactionCount`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransactioncount) + - `storageHash`: `DATA`, 32 Bytes - SHA3 of the StorageRoot. All storage will deliver a MerkleProof starting with this rootHash. + - `accountProof`: `ARRAY` - Array of rlp-serialized MerkleTree-Nodes, starting with the stateRoot-Node, following the path of the SHA3 (address) as key. + - `storageProof`: `ARRAY` - Array of storage-entries as requested. Each entry is a object with these properties: + + - `key`: `QUANTITY` - the requested storage key + - `value`: `QUANTITY` - the storage value + - `proof`: `ARRAY` - Array of rlp-serialized MerkleTree-Nodes, starting with the storageHash-Node, following the path of the SHA3 (key) as path. + + +##### Example + + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "method": "eth_getProof", + "params": [ + "0x7F0d15C7FAae65896648C8273B6d7E43f58Fa842", + [ "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421" ], + "latest" + ] +} +``` + +The result will look like this: + +```json +{ + "jsonrpc": "2.0", + "result": { + "accountProof": [ + "0xf90211a...0701bc80", + "0xf90211a...0d832380", + "0xf90211a...5fb20c80", + "0xf90211a...0675b80", + "0xf90151a0...ca08080" + ], + "address": "0x7f0d15c7faae65896648c8273b6d7e43f58fa842", + "balance": "0x0", + "codeHash": "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470", + "nonce": "0x0", + "storageHash": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", + "storageProof": [ + { + "key": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", + "proof": [ + "0xf90211a...0701bc80", + "0xf90211a...0d832380" + ], + "value": "0x1" + } + ] + }, + "id": 1 +} +``` ## Rationale From 2060fc3277df420ef9663174bf7410be32aabe65 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 13:32:09 +0200 Subject: [PATCH 04/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 38 +++++++++++++++++++++++++++++--------- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index cef808b5886698..53391124ffc6f1 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -46,7 +46,7 @@ Returns the account- and storage-values of the specified account including the m 1. `DATA`, 20 Bytes - address of the storage. 2. `ARRAY`, 32 Bytes - array of storage-keys which should be proofed and included. See [`eth_getStorageAt`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getstorageat) -3. `QUANTITY|TAG` - integer block number, or the string `"latest"`, `"earliest"` or `"pending"`, see the [default block parameter](https://github.com/ethereum/wiki/wiki/JSON-RPC#the-default-block-parameter) +3. `QUANTITY|TAG` - integer block number, or the string `"latest"` or `"earliest"`, see the [default block parameter](https://github.com/ethereum/wiki/wiki/JSON-RPC#the-default-block-parameter) ##### Returns @@ -69,8 +69,8 @@ Returns the account- and storage-values of the specified account including the m ```json { - "jsonrpc": "2.0", "id": 1, + "jsonrpc": "2.0", "method": "eth_getProof", "params": [ "0x7F0d15C7FAae65896648C8273B6d7E43f58Fa842", @@ -84,6 +84,7 @@ The result will look like this: ```json { + "id": 1 "jsonrpc": "2.0", "result": { "accountProof": [ @@ -93,7 +94,6 @@ The result will look like this: "0xf90211a...0675b80", "0xf90151a0...ca08080" ], - "address": "0x7f0d15c7faae65896648c8273b6d7e43f58fa842", "balance": "0x0", "codeHash": "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470", "nonce": "0x0", @@ -108,26 +108,46 @@ The result will look like this: "value": "0x1" } ] - }, - "id": 1 + } } ``` ## Rationale -The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> + +This one Method actually returns 3 different important data: + +1. The 4 fields of an account-object as specified in the yellow paper `[nonce, balance, storageHash, codeHash ]`, which allows to store a hash of the account-object in order to keep track of changes. +2. The MerkleProof for the account starting with a stateRoot from the specified block. +3. The MerkleProof for each requested storage entry starting with a storageHash from the account. + +Combining these in one Method allows the client to work very efficient, since the required data are already fetched from the db. + +### possible Changes to be discussed: + +- instead of providing the blocknumber maybe the blockhash would be better, since it would allow proofs of uncles-states. +- in order to reduce data, the account-object may only provide the `accountProof` and `storageProof`. The Fields `balance`, `nonce`, `storageHash` and `codeHash` could be taken from the last Node in the proof by deserializing it. ## Backwards Compatibility -All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +Since this only adds a new Method there is no issues with Backwards Compatibility. ## Test Cases -Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. + +These Tests cover the verification based on the result of the `eth_getProof` +https://github.com/slockit/in3-server/blob/master/test/eth/eth_abi.ts#L277 + + Further test inside the client may be required. ## Implementation -The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. + +We implemented this function for: + +- [x] [parity](https://github.com/paritytech/parity/pull/9001) (Status: pending pull request) +- [ ] geth (Status: planned) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From b2337411048dad3bfd76344bc59777f1febc1c67 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 13:37:39 +0200 Subject: [PATCH 05/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 53391124ffc6f1..81dd9dcf78fca4 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -123,6 +123,10 @@ This one Method actually returns 3 different important data: Combining these in one Method allows the client to work very efficient, since the required data are already fetched from the db. +### Proofs for non existant values + +In case a address or storage-value does not exist, the proof needs to provide enough data to verify this fact. This means, the client needs to follow the path from the root node and deliver until the last matching node. If the last matching node is a branch, the proof value in the node must be empty one. In case of leaf-type it must be pointing to a different relative-path in order to proof that the requested path does not exists. + ### possible Changes to be discussed: - instead of providing the blocknumber maybe the blockhash would be better, since it would allow proofs of uncles-states. From 2fc3d6395cb45412a402fe5d2d715bc132762143 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 13:41:55 +0200 Subject: [PATCH 06/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 81dd9dcf78fca4..4c88225857184a 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -14,13 +14,13 @@ created: 2018-06-24 ## Simple Summary -One of the great feature of Ethereum is the fact, that you can verify all data of the state. But in order to allow verification of accounts outside the client, we need a additional function delivering us the required proof. These proofs are important to secure Layer2-Technologies. +One of the great features of Ethereum is the fact, that you can verify all data of the state. But in order to allow verification of accounts outside the client, we need a additional function delivering us the required proof. These proofs are important to secure Layer2-Technologies. ## Abstract -Ethereum uses MerkleTrees to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently the eth-Module does not give you access to these proofs. This EIP suggests a additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. +Ethereum uses MerkleTrees to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently the eth-Module in the RPC-Interface does not give you access to these proofs. This EIP suggests a additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. This allows especially IOT-Devices or even mobile apps which are not able to run a light client to verify responses from a untrusted source. From e38608d7c646d7fae2f1d715f3850fc6f1eeed86 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 13:48:54 +0200 Subject: [PATCH 07/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 4c88225857184a..15089d192e58b4 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -27,10 +27,11 @@ Combined with a stateRoot (from the blockheader) it enables offline verification ## Motivation -In order to create a MerkleProof access to the full state is required. The current RPC-Methods allow a application to access single values (`eth_getBalance`,`eth_getTransactionCount`,`eth_getStorageAt`,`eth_getCode`), but it is impossible to read Information about the MerkleTree storing these values through the standard RPC-Interface. +In order to create a MerkleProof access to the full state db is required. The current RPC-Methods allow a application to access single values (`eth_getBalance`,`eth_getTransactionCount`,`eth_getStorageAt`,`eth_getCode`), but it is impossible to read the data needed for a MerkleProof through the standard RPC-Interface. (There are implementaion using leveldb and accessing the data via filesystems, but this can not be used for productive systems, since it requires the client to be stopped first - See https://github.com/zmitton/eth-proof) Today MerkleProofs are already used internally. For example the [Light Client Protocol](https://github.com/zsfelfoldi/go-ethereum/wiki/Light-Ethereum-Subprotocol-%28LES%29#on-demand-data-retrieval) supports a function creating MerkleProof, which is used in order to verify the requested account or storage-data. -Offering these already existing function through the RPC-Interface as well would enable Applications to store and send these proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. + +Offering these already existing function through the RPC-Interface as well would enable Applications to store and send these proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. This could be used to verify data in mobile applications or IOT-devices, which are currently only using a remote client. ## Specification From 814845b10c5871ca4c3b6ca1ec9eb0973c71eaaf Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Thu, 28 Jun 2018 13:50:02 +0200 Subject: [PATCH 08/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 15089d192e58b4..0a9b8b20a83bb4 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -85,7 +85,7 @@ The result will look like this: ```json { - "id": 1 + "id": 1, "jsonrpc": "2.0", "result": { "accountProof": [ From 771ff01315a5aa7663caf953adbc6f54ec8205ba Mon Sep 17 00:00:00 2001 From: Christoph Jentzsch Date: Thu, 28 Jun 2018 14:30:19 +0200 Subject: [PATCH 09/19] Update eip-eth_getProof.md Minor changes and grammar check --- EIPS/eip-eth_getProof.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 0a9b8b20a83bb4..2d982a18cd5f49 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -14,22 +14,22 @@ created: 2018-06-24 ## Simple Summary -One of the great features of Ethereum is the fact, that you can verify all data of the state. But in order to allow verification of accounts outside the client, we need a additional function delivering us the required proof. These proofs are important to secure Layer2-Technologies. +One of the great features of Ethereum is the fact, that you can verify all data of the state. But in order to allow verification of accounts outside the client, we need an additional function delivering us the required proof. These proofs are important to secure Layer2-Technologies. ## Abstract -Ethereum uses MerkleTrees to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently the eth-Module in the RPC-Interface does not give you access to these proofs. This EIP suggests a additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. +Ethereum uses MerkleTrees to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently, the eth-Module in the RPC-Interface does not give you access to these proofs. This EIP suggests an additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. -Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. This allows especially IOT-Devices or even mobile apps which are not able to run a light client to verify responses from a untrusted source. +Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. This allows especially IOT-Devices or even mobile apps which are not able to run a light client to verify responses from an untrusted source only given a trusted blockhash. ## Motivation -In order to create a MerkleProof access to the full state db is required. The current RPC-Methods allow a application to access single values (`eth_getBalance`,`eth_getTransactionCount`,`eth_getStorageAt`,`eth_getCode`), but it is impossible to read the data needed for a MerkleProof through the standard RPC-Interface. (There are implementaion using leveldb and accessing the data via filesystems, but this can not be used for productive systems, since it requires the client to be stopped first - See https://github.com/zmitton/eth-proof) +In order to create a MerkleProof access to the full state db is required. The current RPC-Methods allow an application to access single values (`eth_getBalance`,`eth_getTransactionCount`,`eth_getStorageAt`,`eth_getCode`), but it is impossible to read the data needed for a MerkleProof through the standard RPC-Interface. (There are implementations using leveldb and accessing the data via filesystems, but this can not be used for production systems since it requires the client to be stopped first - See https://github.com/zmitton/eth-proof) -Today MerkleProofs are already used internally. For example the [Light Client Protocol](https://github.com/zsfelfoldi/go-ethereum/wiki/Light-Ethereum-Subprotocol-%28LES%29#on-demand-data-retrieval) supports a function creating MerkleProof, which is used in order to verify the requested account or storage-data. +Today MerkleProofs are already used internally. For example, the [Light Client Protocol](https://github.com/zsfelfoldi/go-ethereum/wiki/Light-Ethereum-Subprotocol-%28LES%29#on-demand-data-retrieval) supports a function creating MerkleProof, which is used in order to verify the requested account or storage-data. Offering these already existing function through the RPC-Interface as well would enable Applications to store and send these proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. This could be used to verify data in mobile applications or IOT-devices, which are currently only using a remote client. @@ -37,15 +37,15 @@ Offering these already existing function through the RPC-Interface as well would ## Specification -As Part of the eth-Module, a additional Method called `eth_getProof` should be defined as following: +As Part of the eth-Module, an additional Method called `eth_getProof` should be defined as follows: #### eth_getProof -Returns the account- and storage-values of the specified account including the merkle-proof. +Returns the account- and storage-values of the specified account including the Merkle-proof. ##### Parameters -1. `DATA`, 20 Bytes - address of the storage. +1. `DATA`, 20 Bytes - address of the account. 2. `ARRAY`, 32 Bytes - array of storage-keys which should be proofed and included. See [`eth_getStorageAt`](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getstorageat) 3. `QUANTITY|TAG` - integer block number, or the string `"latest"` or `"earliest"`, see the [default block parameter](https://github.com/ethereum/wiki/wiki/JSON-RPC#the-default-block-parameter) @@ -116,27 +116,27 @@ The result will look like this: ## Rationale -This one Method actually returns 3 different important data: +This one Method actually returns 3 different important data points: -1. The 4 fields of an account-object as specified in the yellow paper `[nonce, balance, storageHash, codeHash ]`, which allows to store a hash of the account-object in order to keep track of changes. +1. The 4 fields of an account-object as specified in the yellow paper `[nonce, balance, storageHash, codeHash ]`, which allows storing a hash of the account-object in order to keep track of changes. 2. The MerkleProof for the account starting with a stateRoot from the specified block. 3. The MerkleProof for each requested storage entry starting with a storageHash from the account. -Combining these in one Method allows the client to work very efficient, since the required data are already fetched from the db. +Combining these in one Method allows the client to work very efficient since the required data are already fetched from the db. ### Proofs for non existant values -In case a address or storage-value does not exist, the proof needs to provide enough data to verify this fact. This means, the client needs to follow the path from the root node and deliver until the last matching node. If the last matching node is a branch, the proof value in the node must be empty one. In case of leaf-type it must be pointing to a different relative-path in order to proof that the requested path does not exists. +In case an address or storage-value does not exist, the proof needs to provide enough data to verify this fact. This means the client needs to follow the path from the root node and deliver until the last matching node. If the last matching node is a branch, the proof value in the node must be an empty one. In case of leaf-type, it must be pointing to a different relative-path in order to proof that the requested path does not exist. ### possible Changes to be discussed: -- instead of providing the blocknumber maybe the blockhash would be better, since it would allow proofs of uncles-states. +- instead of providing the blocknumber maybe the blockhash would be better since it would allow proofs of uncles-states. - in order to reduce data, the account-object may only provide the `accountProof` and `storageProof`. The Fields `balance`, `nonce`, `storageHash` and `codeHash` could be taken from the last Node in the proof by deserializing it. ## Backwards Compatibility -Since this only adds a new Method there is no issues with Backwards Compatibility. +Since this only adds a new Method there are no issues with Backwards Compatibility. ## Test Cases From 9f7cd375bd0de94c463b046b2610b7bf5c3cbb8f Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Fri, 21 Sep 2018 09:08:56 +0200 Subject: [PATCH 10/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 2d982a18cd5f49..504e59f7b2b152 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -1,5 +1,5 @@ --- -eip: +eip: 1186 title: eth_getProof author: Simon Jentzsch , Christoph Jentzsch discussions-to: simon.jentzsch@slock.it @@ -141,10 +141,7 @@ Since this only adds a new Method there are no issues with Backwards Compatibili ## Test Cases -These Tests cover the verification based on the result of the `eth_getProof` -https://github.com/slockit/in3-server/blob/master/test/eth/eth_abi.ts#L277 - - Further test inside the client may be required. +Tests still need to be implemented, but the core function creating the proof already exists inside the clients and are well tested. ## Implementation From a2c9e34bc4501c98dddc53007faea023195efc80 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Fri, 21 Sep 2018 09:29:23 +0200 Subject: [PATCH 11/19] Update eip-eth_getProof.md --- EIPS/eip-eth_getProof.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-eth_getProof.md index 504e59f7b2b152..745677e6ac9bcd 100644 --- a/EIPS/eip-eth_getProof.md +++ b/EIPS/eip-eth_getProof.md @@ -148,7 +148,7 @@ Since this only adds a new Method there are no issues with Backwards Compatibili We implemented this function for: -- [x] [parity](https://github.com/paritytech/parity/pull/9001) (Status: pending pull request) +- [x] [parity](https://github.com/paritytech/parity/pull/9001) (Status: pending pull request) - [Docker](https://hub.docker.com/r/slockit/parity-in3/tags/) - [ ] geth (Status: planned) ## Copyright From 651def7acae5c37f8bc600a54a7fee2620383fd5 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Fri, 21 Sep 2018 09:31:07 +0200 Subject: [PATCH 12/19] renamed --- EIPS/{eip-eth_getProof.md => eip-1186.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-eth_getProof.md => eip-1186.md} (100%) diff --git a/EIPS/eip-eth_getProof.md b/EIPS/eip-1186.md similarity index 100% rename from EIPS/eip-eth_getProof.md rename to EIPS/eip-1186.md From 0beecf1c6dd191b887d4d88e36301ab36811a619 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Fri, 21 Sep 2018 10:08:33 +0200 Subject: [PATCH 13/19] Update eip-1186.md --- EIPS/eip-1186.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 745677e6ac9bcd..6f1c0a68bcb831 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -2,7 +2,7 @@ eip: 1186 title: eth_getProof author: Simon Jentzsch , Christoph Jentzsch -discussions-to: simon.jentzsch@slock.it +discussions-to: https://github.com/ethereum/EIPs/issues/1186 status: Draft type: Standards Track (Core, Networking, Interface, ERC) category : Interface From df9691f8a70aed59aac9f6fc419bb18422e4b748 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Fri, 21 Sep 2018 10:31:23 +0200 Subject: [PATCH 14/19] fixed type --- EIPS/eip-1186.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 6f1c0a68bcb831..d80d348b27db0d 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -4,7 +4,7 @@ title: eth_getProof author: Simon Jentzsch , Christoph Jentzsch discussions-to: https://github.com/ethereum/EIPs/issues/1186 status: Draft -type: Standards Track (Core, Networking, Interface, ERC) +type: Standards Track category : Interface created: 2018-06-24 --- From 34e17daeea619ff111766ca22feeb30fcc52f858 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Sat, 22 Sep 2018 08:35:43 +0200 Subject: [PATCH 15/19] Update eip-1186.md --- EIPS/eip-1186.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index d80d348b27db0d..c6374b9f7acfa7 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -149,7 +149,7 @@ Since this only adds a new Method there are no issues with Backwards Compatibili We implemented this function for: - [x] [parity](https://github.com/paritytech/parity/pull/9001) (Status: pending pull request) - [Docker](https://hub.docker.com/r/slockit/parity-in3/tags/) -- [ ] geth (Status: planned) +- [x] [geth](https://github.com/ethereum/go-ethereum/pull/17737) (Status: pending pull request) - [Docker] (https://hub.docker.com/r/slockit/geth-in3/tags/) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From d17b7f4a2c1703c8aee764d3a653e29b75ba9c28 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Sat, 22 Sep 2018 08:41:56 +0200 Subject: [PATCH 16/19] fixed links to geth --- EIPS/eip-1186.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index c6374b9f7acfa7..7597184248a11b 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -149,7 +149,7 @@ Since this only adds a new Method there are no issues with Backwards Compatibili We implemented this function for: - [x] [parity](https://github.com/paritytech/parity/pull/9001) (Status: pending pull request) - [Docker](https://hub.docker.com/r/slockit/parity-in3/tags/) -- [x] [geth](https://github.com/ethereum/go-ethereum/pull/17737) (Status: pending pull request) - [Docker] (https://hub.docker.com/r/slockit/geth-in3/tags/) +- [x] [geth](https://github.com/ethereum/go-ethereum/pull/17737) (Status: pending pull request) - [Docker](https://hub.docker.com/r/slockit/geth-in3/tags/) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 92052ce37f345b8f4c8667a461d508971fc3b568 Mon Sep 17 00:00:00 2001 From: Nick Johnson Date: Mon, 15 Oct 2018 12:24:48 +0100 Subject: [PATCH 17/19] Update eip-1186.md --- EIPS/eip-1186.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 7597184248a11b..06e5e69fc7026e 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -5,7 +5,7 @@ author: Simon Jentzsch , Christoph Jentzsch Date: Mon, 15 Oct 2018 15:40:21 +0200 Subject: [PATCH 18/19] - better title --- EIPS/eip-1186.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 06e5e69fc7026e..37bedd458e90f4 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -1,6 +1,6 @@ --- eip: 1186 -title: eth_getProof +title: RPC-Method to get MerkleProofs - eth_getProof author: Simon Jentzsch , Christoph Jentzsch discussions-to: https://github.com/ethereum/EIPs/issues/1186 status: Draft @@ -20,7 +20,7 @@ One of the great features of Ethereum is the fact, that you can verify all data ## Abstract -Ethereum uses MerkleTrees to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently, the eth-Module in the RPC-Interface does not give you access to these proofs. This EIP suggests an additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. +Ethereum uses a [Patricia-MerkleTree](https://github.com/ethereum/wiki/wiki/Patricia-Tree) to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently, the standard RPC-Interface does not give you access to these proofs. This EIP suggests an additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. This allows especially IOT-Devices or even mobile apps which are not able to run a light client to verify responses from an untrusted source only given a trusted blockhash. From 021ffcbc2a4b2efa2c29ffc3979364d34d879dc8 Mon Sep 17 00:00:00 2001 From: Simon Jentzsch Date: Mon, 15 Oct 2018 15:44:29 +0200 Subject: [PATCH 19/19] - better title - better typography --- EIPS/eip-1186.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 37bedd458e90f4..3398e5b5819bf2 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -1,6 +1,6 @@ --- eip: 1186 -title: RPC-Method to get MerkleProofs - eth_getProof +title: RPC-Method to get Merkle Proofs - eth_getProof author: Simon Jentzsch , Christoph Jentzsch discussions-to: https://github.com/ethereum/EIPs/issues/1186 status: Draft @@ -20,7 +20,7 @@ One of the great features of Ethereum is the fact, that you can verify all data ## Abstract -Ethereum uses a [Patricia-MerkleTree](https://github.com/ethereum/wiki/wiki/Patricia-Tree) to store the state of accounts and their storage. This allows verification of each value by simply creating a MerkleProof. But currently, the standard RPC-Interface does not give you access to these proofs. This EIP suggests an additional RPC-Method, which creates MerkleProofs for Accounts and Storage-Values. +Ethereum uses a [Merkle Tree](https://github.com/ethereum/wiki/wiki/Patricia-Tree) to store the state of accounts and their storage. This allows verification of each value by simply creating a Merkle Proof. But currently, the standard RPC-Interface does not give you access to these proofs. This EIP suggests an additional RPC-Method, which creates Merkle Proofs for Accounts and Storage Values. Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. This allows especially IOT-Devices or even mobile apps which are not able to run a light client to verify responses from an untrusted source only given a trusted blockhash.