A: Transaction Gossip

The portal network design for transaction gossip requires that:

• nodes can limit how much of the mempool they are expected to process
• nodes that want to view the full mempool can do so

The current designs for this involve actually shaping the network topology around these two needs. It isn't obvious to me how this can be accomplished using the functionality provided by libp2p

B: O(1) access to the state

We need these things:

• queries can be made under a specific state root
• we query by key which is the full path into the trie where the leaf should live
• the response is contains both the leaf and a proof that anchors the returned data to the state root it should be under.

First I'll start with a completely naive solution that does seem to map fine to the new architecture.

We will store things roughly as (key, state_root) => (leaf, proof), which means that we will key off of both the state root, and the key in the trie, and we will store both the leaf value and the proof. For this to work without anything extra fancy we must push a full new copy of the state into the network at every single block, anchoring each leaf to the state root (regardless of whether the value has changed since the previous block).

In the DHT-portal network, we get around this by having nodes store a proof that they are continually updating as new data shows up in new blocks. This gives us both efficiency of storage since we don't have to store duplicate values that haven't changed, as well as efficient data ingress since we only have to pipe in the new/updated state data.

It isn't clear to me how we can accomplish similar things using IPLD/bitswap.

We need to figure out which of the Ethereum JSON RPC routes the portal network can support. There's currently a list of all routes in docs/json-rpc.md.