Portal Network: State Network Functionality

[kdeme]

Portal Network: State Network Client Functionality

Issue to better track the implemented State network related features in the Fluffy Portal client, in order to know what to work in still and to have a better view on the state of the client.

Specific items to do still can have their own issue to track in more detail

Edit: Anything wire protocol / network overlay related items have been moved to #898. This issue is purely about State network only functionality and is currently probably pretty incomplete.

• A - Content Management

  • A.1 - Proof handling
    • A.1.a - Proof Transmission
      • A.1.a.1 - Proof Encoding and Serialization
        The ability to take a merkle proof against the hexary patricia trie and serialize it to a stream of bytes suitable for transmission.
      • A.1.a.2 - Proof Decoding and Deserialization
        The ability to take a stream of bytes representing a merkle proof against the hexary patricia trie and deserialize it into a native representation.
    • A.2.b - Proof validation
      The ability to validate that a given merkle proof is well formed against a known state root.
    • A.2.c - Proof storage
      For each proof, the client should be able to store the proof for later retrieval.
      Efficient storage will require the ability to merge multiple proofs into a single proof, and then to extract a minimal sub-proof from the merged proofs.
      A simple model for storage would be simply to store the serialized versions which will result in larger storage overhead, but side-steps the need for merging proofs.

• B - JSON-RPC
  Endpoints that require state access

  • B.1 - eth_balance: TODO
  • B.2 - eth_getTransactionCount: TODO
  • B.3 - eth_getCode: TODO
  • B.4 - eth_getStorage: TODO
  • B.5 - eth_call: TODO
  • B.6 - eth_estimateGas: TODO

[kdeme]

Closing this in favour of #1923