From the outset, one of the big challenges OpenRelay has faced has been the management of Ethereum clients. In general, the challenges are:

• Syncing the blockchain takes hours at best, and often days.
• Losing peers can put you out-of-sync
• Processing transactions requires a lot of CPU, RAM, and disk IO *If your application needs to make more RPC requests than a single node can handle, all of the above must be replicated to expand capacity.

In the world of databases, these problems are solved through streaming replications. Rather than running a single database server, database administrators run a master and replicas. Read requests can be routed to the replicas to provide additional capacity, while write operations go to the master and get replicated out. Replicas generally avoid a lot of the complex operations the master has to perform, and just writes to disk based on the master’s instruction. If a master ever fails, a replica can be promoted to master with minimal disruption.

The Ether Cattle Initiative brings streaming replication to Ethereum clients. In a nutshell:

• Systems administrators run a master server, a Kafka cluster to capture write operations, and as many replicas as necessary to meet capacity requirements.
• The master maintains peer-to-peer connections and validates incoming blocks & transactions.
• As the master writes to disk, it logs its write operations to a Kafka topic.
• The replica servers subscribe to the Kafka topic and write operations get stored on the replica.
• The replica server then serves RPC requests.
• Any transactions sent to the replica are routed back to the master though a separate Kafka topic to be broadcast to the network.

This design is documented in more detail in our Architecture Document, we also put out a YouTube video on the subject.

How You Can Help

If you have a dApp you’d be open to testing against Ether Cattle replicas, we have a couple of options.

First, we are hosting a public Goerli RPC server at https://goerli-rpc.openrelay.xyz/ — If your dApp runs on Goerli, we’d encourage you to point at our RPC server and check that everything works as expected. Also, if you run your dApp on Goerli, we’re trying to build a list of dApps that support Goerli, and would appreciate a pull request at github.com/openrelayxyz/goerli-dapp-list

To get Goerli working with Metamask, use these instructions, with https://goerli-rpc.openrelay.xyz as the network RPC URL.

If your dApp doesn’t run on Goerli, we also have a mainnet endpoint available, but we are not publishing it just yet. If you are open to helping test your dApp against our mainnet endpoint, reach out to me directly at austin.roberts[at]openrelay.xyz and I’ll get you the endpoint URL.

We plan to leave these endpoints up through the end of April, 2019.

Reporting Bugs

If you run into issues with Ether Cattle Replicas, please report them to our Github Repository. Note that at this time we are running minimal infrastructure for the purposes of testing the behavior of our RPC servers; we do not have these endpoints deployed in a highly available configuration. We are monitoring for gateway errors, but don’t need bug reports when the endpoints go down.

If you have questions that you don’t think necessarily warrant a bug report, you can also reach out to us on gitter.

Acknowledgements

The work OpenRelay has done on the Ether Cattle Initiative has been possible (in part) thanks to a 0x Ecosystem Development Grant. The work on Ether Cattle will always be open source, and we hope to contribute it back to the Go Ethereum project once it’s stable.