OIP-15: PotterHat - A multi-client Ethereum data service

[unnawut]

Simple Summary

PotterHat is a facade application that attempts to provide a consistent and resilient Ethereum data service by unifying the differences between different Ethereum client implementations and routing requests through the Ethereum client that is running with the most up to date data.

It listens to events and data across Ethereum clients, and returns the data that it thinks is the closest to the truth.

Motivation

Connections to Ethereum can be unreliable. Ethereum integrators therefore need to set up a redundancy mechanism to protect themselves against failures from a single Ethereum node.

However, unlike typical applications where redundancy can be achieved by setting up multiple identical nodes and load-balance over them, hiccups from Ethereum could come from an unstable/faulty client implementation as well. This means that a resilient Ethereum integration not only requires redundancy against a node failure, but also against a failure from the node’s implementation as well.

Specification

Requirements

• Requests & responses, including pub/sub, follow the JSON-RPC defined at https://github.com/ethereum/wiki/wiki/JSON-RPC
• Client selection: always switch to the client with the highest block number
• Alerts:
  • When unable to connect to a client
  • When multiple clients are too far apart in block heights (configurable threshold)

Tasks

• Comparison table of all existing solutions: Is it worth building a new solution instead of reusing an existing?
• 2 Geths PoC: Is there enough value building a multi-instance service?
  • Monitor multiple client instances
  • Collect all discrepancies between the two instances
  • Figure out if those discrepancies could be leveraged for resiliency
• 1 Geth MVP: Consume from a single instance of a specific implementation
  • App architectural design
  • Feature: Fetch Ethereum data from JSON-RPC
  • Feature: Relay pub/sub events
  • Monitoring: Client's health check
  • Monitoring: Client's latest block height & block hash
  • Alert: Client stops responding to requests
  • Alert: Client not returning new blocks after some time (configurable threshold)
  • Alert: Chain reorg
• 2 Geths MVP: Consume from multiple instances of a specific implementation
  • Setup infrastructure for multi-instances
  • Implement client-switching based on health checks
  • Alert: Clients are too far apart in block heights (configurable threshold)
• 1 Geth + 1 Parity MVP: Consume from multiple instances of different implementations
  • Setup infrastructure for multi-implementations
  • Handle the discrepancies between clients
• PaaS: PotterHat as a Service: Supports external API through Phoenix
  • JSON-API
  • Pub/Sub

[Pongch]

Great initiative ! One thing to note is that when we talk about events we mean specifically the emitted smart contract events (listening to individual personal account changes is not possible yet). So I'd add in the requirements maybe something like

• listens to arbitrary smart contract emitted events

[unnawut]

By the way I'm just the notetaker.

[whoisjeremylam]

Does PotterHat need to handle competing chains?
Does this mean selection of the longest chain? Further up, I think it says this is a responsibility of PotterHat to switch to the longest chain.

Would it be useful if PotterHat detected chain re-orgs?

[unnawut]

Does PotterHat need to handle competing chains?
Does this mean selection of the longest chain? Further up, I think it says this is a responsibility of PotterHat to switch to the longest chain.

Would it be useful if PotterHat detected chain re-orgs?

I need to figure out if all clients provide information to detect that. But if that's possible, what do you reckon this service need to do? Just emit a :chain_reorganized event?

[unnawut]

Note to self: chain re-orgs are probably handled pretty well within a client, but since we'll be relying on data from multiple clients we still need to handle when different clients are based on different chains.

[whoisjeremylam]

if that's possible, what do you reckon this service need to do? Just emit a :chain_reorganized event?

Some applications assume a maximum re-org depth and will fail to be secure if that assumption is broken.

It may make sense to have an option that defines a tolerance and emit an event if a re-org occurs with a depth that is equal to or larger than the defined amount.

[unnawut]

TODO: Comparison table with existing solutions

[pdobacz]

Question1: how justified is the thinking that potterhat will be a drop-in replacement for an eth node, in terms of its API/behavior/ways of starting up etc. And if yes - which eth node is it going to mimic "the most"?

Question2: why is Mana not on the client list ? But seriously - would the fact that such (i.e. Elixir/OTP) client exists pivot the design process in any way?

[unnawut]

Question1: how justified is the thinking that potterhat will be a drop-in replacement for an eth node, in terms of its API/behavior/ways of starting up etc. And if yes - which eth node is it going to mimic "the most"?

My initial thought is, probably geth. Though we'll need to do a PoC of this to get comprehensive diffs between different clients. I've added this in the Open Questions section of this OIP.

Question2: why is Mana not on the client list ? But seriously - would the fact that such (i.e. Elixir/OTP) client exists pivot the design process in any way?

Last I heard is that Mana is not ready for use yet. Maybe @InoMurko can give a better informed opinion?

I don't think the design would change since we will still need to depend on non-Elixir/OTP clients and hence reliance on Elixir/OTP should probably be abstracted. But up for discussions on this.

[unnawut]

It may make sense to have an option that defines a tolerance and emit an event if a re-org occurs with a depth that is equal to or larger than the defined amount.

Added to the Requirements -> Alerts section

[unnawut]

Great initiative ! One thing to note is that when we talk about events we mean specifically the emitted smart contract events (listening to individual personal account changes is not possible yet). So I'd add in the requirements maybe something like

• listens to arbitrary smart contract emitted events

@Pongch updated later that listening to ether transactions is possible. Ref: https://ethereum.stackexchange.com/questions/48927/web3-detect-listen-to-events-if-someone-send-ether-to-addresses. So no changes to the OIP for this one.

[InoMurko]

Hi! Mana was not never battle tested and it still needs some work to be a fully functional mainnet clinet :-)

On the other hand (if you remember Shanghai DOS) you really need to run multiple different clients and abstract away any specifics in interface implementation.