Create State specific JSON api-s

[morph-dev]

Add state specific JSON api-s:

• portal_stateRecursiveFindAccountState
  • for a given state root and address, returns account state and proof
• portal_stateRecursiveFindContractStorageAt
  • for a given address, contract storage root and storage slot, returns value from the storage trie and proof
• portal_stateRecursiveFindContractBytecode
  • for a given address and codehash, returns contract's bytecode

This PR also defines few api-s that already exist (at least in trin):

• portal_historyRadius
• portal_stateTraceRecursiveFindContent
• portal_stateRadius

[ogenev]

LGTM 👍

[kdeme]

Do I understand correctly that these calls walk down the state to get to a specific account / storage data?
So basically a bunch of different recursiveFindContent calls?

[morph-dev]

Yes, that's the idea. It is a mid point between recursiveFindContent and eth_ state methods (eth_getBalance, eth_getStorageAt, eth_getTransactionCount, eth_getCode).

[kdeme]

Right. I'm not a big fan of mixing these type of methods in the core Portal json-rpc API. Unless their logic is also required in the core protocol.

It seems they are not so different from the Execution layer JSON-RPC API counterparts, aside from directly requiring the state root versus the block root?

But if that is enough reason to still have them, then I'd say they perhaps should have a separate, more application focused, Portal json-rpc "namespace"? Or for now, atleast they could be made optional in the current Portal JSON-RPC specification (and moved when/if there are more?).

[morph-dev]

I would say that benefits are slightly better:

• the Execution api-s actually don't allow block hash. They explicitly support block number or string ("latest", "earliest" or "pending"), and I don't think we support either (I assume we plan to in the long run, so this might not be so big issue)
• official api for the eth_getStorageAt would have to always iterate over state trie (to find account state) and contract storage trie. The api that I propose splits those tree traversals into separate calls (meaning, if you want to get multiple values from the same contract, you will iterate state trie only once).

I'm fine with creating different namespace and / or making them optional. Maybe we can discuss this on the next team meeting.

[kdeme]

Further thinking about it, having a different namespace is not just useful for us in keeping some logic separate, but even more interesting for end users.

Providing just one API which contains also all these lower level calls that are only useful for testing the actual protocol will be overwhelming and not great UX. Separate user focused API does sound better for that.