Support eth_getProof JSON RPC method #251

fedejinich · 2021-06-30T15:09:06Z

Introducing a new JSON RPC method to retrieve merkle proofs from the JSON RPC layer. Useful for state verifications

fedejinich · 2021-06-30T15:13:48Z

@SergioDemianLerner It'd be interesting to know your thoughts about this RSKIP, specially the verifications for non existing accounts (or storage keys). To me it seems more clear to return empty lists for any of those scenarios

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.

fedejinich · 2021-06-30T15:14:10Z

also I still need to add some tests cases and code to the spec

smishraIOV · 2021-07-16T22:08:33Z

IPs/RSKIP251.md

+
+RSK implements a Unitrie data structure to store all the relevant blockchain data, such as account states and storage values, this particular data structure enables an easy verification of each stored value, just by getting a merkle proof. Currently these proofs are only useful for blockchain nodes, but in order to allow verification of accounts outside the client, we need an additional function delivering us the required proof. 
+
+Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value. 


This sentence should be part of the above paragraph.. the "it" in "it enables" refers to the function mentioned above

... enables "offline verification" .. what does "offline" mean?

Even though it is mentioned in title (and motivation), it is good to explicitly say this is a RPC method in the abstract

smishraIOV · 2021-07-16T22:08:35Z

IPs/RSKIP251.md

+
+## Motivation
+
+Offering these function through the RPC-Interface would enable applications to store and send proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. This could be used for mobile applications, which are currently only using a remote client.


typo these function -> this function
.. there are some other minor typos, we can clean them up later :)

smishraIOV · 2021-07-16T22:08:37Z

IPs/RSKIP251.md

+
+Offering these function through the RPC-Interface would enable applications to store and send proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. This could be used for mobile applications, which are currently only using a remote client.
+
+Also it might be useful for L2 solutions.


move to above paragraph

smishraIOV · 2021-07-16T22:08:41Z

IPs/RSKIP251.md

+- balance (QUANTITY)
+- codeHash (UNFORMATTED): SHA3 of the code associated to the specifica account (for EOA just retrieve SHA3(EMPTY_BYTE_ARRAY)) 
+- nonce (QUANTITY)
+- storageHash (UNFORMATTED): hash of the code of the account. For a EOA it will return "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470" == SHA3(EMPTY_BYTE_ARRAY)


hash of "code" -> hash of "value" in storage node/ cell (for the given the storage key)

smishraIOV · 2021-07-16T22:08:44Z

IPs/RSKIP251.md

+- codeHash (UNFORMATTED): SHA3 of the code associated to the specifica account (for EOA just retrieve SHA3(EMPTY_BYTE_ARRAY)) 
+- nonce (QUANTITY)
+- storageHash (UNFORMATTED): hash of the code of the account. For a EOA it will return "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470" == SHA3(EMPTY_BYTE_ARRAY)
+- accountProof (UNFORMATED[]): Array of rlp-serialized MerkleTree-Nodes, starting with the stateRoot-Node, following the path of the SHA3(address) as key.


minor typo unformated -> unformatted

smishraIOV · 2021-07-16T22:08:46Z

IPs/RSKIP251.md

+    - Storage-entry:
+        - Key (UNFORMATTED): Requested storage key 
+        - Value (QUANTITY): Value contained for that key
+        - Proof (UNFORMATED[]): Array of rlp-serialized MerkleTree-Nodes, starting with the storageHash-Node, following the path of the SHA3(key) as path.


minor typo unformated -> unformatted

smishraIOV · 2021-07-16T22:08:49Z

IPs/RSKIP251.md

+        - Value (QUANTITY): Value contained for that key
+        - Proof (UNFORMATED[]): Array of rlp-serialized MerkleTree-Nodes, starting with the storageHash-Node, following the path of the SHA3(key) as path.
+
+Each unitrie node should be serialized as described in the [RSKIP107](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP107.md)


how/why is the serialization relevant for the RPC method?

smishraIOV · 2021-07-16T22:08:53Z

IPs/RSKIP251.md

+
+Each unitrie node should be serialized as described in the [RSKIP107](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP107.md)
+
+### Address or storage non existent values


please change the order, start with Non existent .. e.g. Non existent addresses or storage values

smishraIOV · 2021-07-16T22:08:56Z

IPs/RSKIP251.md

+
+### Address or storage non existent values
+
+If a non-existent address or key from storage is requested, we’ll need to provide enough information to verify that ausence from the outside world. For example, a non existing key will lead to a different node.


ausence -> absence?

a non existent key will lead to different node .. I don't follow what different trie node means

unclear meaning of this paragraph.

Do you want to receive a proof of non-membership ?

smishraIOV · 2021-07-16T22:09:00Z

IPs/RSKIP251.md

+
+Note that this is not the same as requesting with wrong parameters, if those params are invalid, we just need to respond as a failed request. 
+
+## References


These references numbers should be marked in the text where they are cited. For example, it would be nice to cite [1] in the abstract when talking about Merkle proofs for state data

smishraIOV · 2021-07-16T22:15:50Z

Hey Fede, we can approve the PR, but we will merge it only after Sergio has some time to review it, since you marked him specifically :)

SergioDemianLerner · 2021-08-31T18:14:13Z

IPs/RSKIP251.md

+The method eth_getProof() is added to the RPC interface. The method returns the account and storage-values of the specified account including the Merkle-proof.
+
+Params
+- address (UNFORMATTED)


which is the name of the field?

SergioDemianLerner · 2021-08-31T18:14:33Z

IPs/RSKIP251.md

+
+Params
+- address (UNFORMATTED)
+- storage keys that we want to prove (if needed)  (UNFORMATTED[])


same here. This field should have a name, right ?

What is address specified but starageKeys is omitted ? Are both optional ?

SergioDemianLerner · 2021-08-31T18:17:24Z

IPs/RSKIP251.md

+- nonce (QUANTITY)
+- storageHash (UNFORMATTED): hash of the code of the account. For a EOA it will return "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470" == SHA3(EMPTY_BYTE_ARRAY)
+- accountProof (UNFORMATED[]): Array of rlp-serialized MerkleTree-Nodes, starting with the stateRoot-Node, following the path of the SHA3(address) as key.
+- storageProof: Array of storage-entries as requested.


Is this proof given for the account or for the storage keys given as arguments? It's unclear

SergioDemianLerner · 2021-08-31T18:18:11Z

IPs/RSKIP251.md

+
+### Address or storage non existent values
+
+If a non-existent address or key from storage is requested, we’ll need to provide enough information to verify that ausence from the outside world. For example, a non existing key will lead to a different node.


unclear meaning of this paragraph.

Do you want to receive a proof of non-membership ?

smishraIOV · 2021-12-21T22:34:03Z

@fedejinich this PR has stagnated for a long time. When you get the chance, please update it to address some of the major comments, so we can merge the PR. Further discussions can then happen on the RSK research forum.

eth_getProof first aproach

d653b57

fedejinich requested a review from SergioDemianLerner June 30, 2021 15:09

fedejinich mentioned this pull request Jun 30, 2021

Support eth_getProof JSON RPC method rsksmart/rskj#1519

Open

8 tasks

smishraIOV reviewed Jul 16, 2021

View reviewed changes

Some grammar corrections to clarify

1c2c5cb

SergioDemianLerner requested changes Aug 31, 2021

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support eth_getProof JSON RPC method #251

Support eth_getProof JSON RPC method #251

fedejinich commented Jun 30, 2021 •

edited

Loading

fedejinich commented Jun 30, 2021 •

edited

Loading

fedejinich commented Jun 30, 2021 •

edited

Loading

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

smishraIOV Jul 16, 2021

SergioDemianLerner Aug 31, 2021

smishraIOV Jul 16, 2021

smishraIOV commented Jul 16, 2021

SergioDemianLerner Aug 31, 2021

SergioDemianLerner Aug 31, 2021

SergioDemianLerner Aug 31, 2021

SergioDemianLerner Aug 31, 2021

SergioDemianLerner Aug 31, 2021

smishraIOV commented Dec 21, 2021


		RSK implements a Unitrie data structure to store all the relevant blockchain data, such as account states and storage values, this particular data structure enables an easy verification of each stored value, just by getting a merkle proof. Currently these proofs are only useful for blockchain nodes, but in order to allow verification of accounts outside the client, we need an additional function delivering us the required proof.

		Combined with a stateRoot (from the blockheader) it enables offline verification of any account or storage-value.


		## Motivation

		Offering these function through the RPC-Interface would enable applications to store and send proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. This could be used for mobile applications, which are currently only using a remote client.


		Offering these function through the RPC-Interface would enable applications to store and send proofs to devices which are not directly connected to the p2p-network and still are able to verify the data. This could be used for mobile applications, which are currently only using a remote client.

		Also it might be useful for L2 solutions.


		Each unitrie node should be serialized as described in the [RSKIP107](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP107.md)

		### Address or storage non existent values


		### Address or storage non existent values

		If a non-existent address or key from storage is requested, we’ll need to provide enough information to verify that ausence from the outside world. For example, a non existing key will lead to a different node.


		Note that this is not the same as requesting with wrong parameters, if those params are invalid, we just need to respond as a failed request.

		## References

Support eth_getProof JSON RPC method #251

Are you sure you want to change the base?

Support eth_getProof JSON RPC method #251

Conversation

fedejinich commented Jun 30, 2021 • edited Loading

fedejinich commented Jun 30, 2021 • edited Loading

fedejinich commented Jun 30, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smishraIOV commented Jul 16, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smishraIOV commented Dec 21, 2021

fedejinich commented Jun 30, 2021 •

edited

Loading

fedejinich commented Jun 30, 2021 •

edited

Loading

fedejinich commented Jun 30, 2021 •

edited

Loading