User Tools

Site Tools


dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1186

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1186 [2019/05/27 01:43]
nick created
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_1186 [2021/08/09 12:00] (current)
murphy
Line 1: Line 1:
-======== EIP 1186: RPC-Method to get Merkle Proofs - eth_getProof ​  ========= +==== EIP 1186: RPC-Method to get Merkle Proofs - eth_getProof ​(DRAFT)  ​==== 
-[[dido:​public:​stds:​defact:​ethereum | Return to Ethereum ERCs ]]+[[dido:​public:​ra:​xapend:​xapend.b_stds:​defact:​ethereum:eip| Return to Ethereum ERCs ]]
  
-: **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a connivence ​and is not authoritative. Refer to the original document as the authoritative reference.+  ​: **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a convenience ​and is not authoritative. Refer to the original document as the authoritative reference.
  
 <​table>​ <​table>​
Line 15: Line 15:
 </​table>​ </​table>​
  
 +=== 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 [[dido:​public:​ra:​xapend:​xapend.a_glossary:​c:​client|client]],​ we need an additional function delivering us the required proof. These proofs are important to secure Layer2-Technologies.//​
  
-====== ​Simple Summary ======+=== Abstract ​===  
 +  : //Ethereum uses a [[ https://​github.com/​ethereum/​wiki/​wiki/​Patricia-Tree |Merkle 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.//
  
-  : //One of the great features ​of Ethereum is the fact, that you can verify all data of the stateBut 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.//+  ://Combined with a stateRoot (from the blockheader) it enables offline verification ​of any account or storage-valueThis allows especially [[dido:​public:​ra:​xapend:​xapend.a_glossary:​i:​iot|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.//
  
-====== ​Abstract ======+=== Motivation ​===  
 +  ://In order to create a MerkleProof access to the full state db is required. The current RPC-Methods allow an [[dido:​public:​ra:​xapend:​xapend.a_glossary:​a:​application|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)//​
  
-  ​: //Ethereum uses a [[ https://​github.com/​ethereum/​wiki/​wiki/​Patricia-Tree | Merkle 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.// +  : //Today MerkleProofs are already used internally. For example, the [[https://​github.com/​ethereum/​devp2p/​blob/​master/​caps/​les.md |Light Client Protocol]] supports a function creating MerkleProof,​ which is used in order to verify the requested account or storage-data.//​
- +
-  ://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 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 [[https://​github.com/​ethereum/​devp2p/​blob/​master/​caps/​les.md | 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. This could be used to verify data in mobile applications or IOT-devices,​ which are currently only using a remote client.//   : //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.//
- 
- 
- 
dido/public/ra/xapend/xapend.b_stds/defact/ethereum/eip/erc_1186.1558935832.txt.gz · Last modified: 2019/05/27 01:43 by nick