Ethercluster: An Open-Source Alternative to Infura
We at the Ethereum Classic Cooperative are happy to unveil Ethercluster, a much-needed project we have been working on for a while.
Ethercluster is an open-sourced Ethereum Virtual Machine (EVM) Remote Procedure Call (RPC) providing Ethereum Classic (ETC) and Kotti endpoints for free. It does so using the latest cutting-edge infra-as-code technologies such as Kubernetes, Terraform and Docker. It also scales easily with increased usage and demand.
The Ethercluster website provides information and the endpoints, while the docs teach how to build it from scratch so you can run your own infrastructure.
Motivations
The main motivations behind building our own RPC endpoint infrastructure is due to not having Infura include Ethereum Classic as an option to connect to. That coupled with wait times to actually integrate with Infura, as well as wanting to provide a reliable, scalable and open-sourced alternative to Infura for not only Ethereum Classic but also any EVM-based network was the main reason we pushed to build this.
Ethercluster serves both as a free endpoint for Kotti and ETC as well as a design specification for building scalable blockchain infrastructure for others. You can use the endpoint provided by us at the ETC Cooperative or check out our docs to building your blockchain infrastructure.
Our documentation will have you learning to build your own node infrastructure in the cloud that can scale easily in no time. That’s right, you’d be able to run an Ethereum-based Ethercluster following our docs if you want. Also, you can modify the manifests and specs in the docs to target your specific needs, even ones not related to EVMs (Hint: You can essentially build your own scalable Proof-of-Stake node infrastructure with ease by building upon Ethercluster).
Cloud Instantiation
Our Ethercluster design specs first target a few things. We build our cloud set up using Terraform, an infra-as-code software to building your cloud setup in a version-controlled way.
The docs go over Terraform and how to get started with it. Essentially, after installing Terraform, you can build your own cloud infrastructure with one command as shown in the following.
You can check out the GitHub for the Terraform files here.
Currently, for this setup, we are using Google Kubernetes Engine on Google Cloud as our sole provider. This design isn’t multi-regional yet and neither is it multi-cloud, which will be the aim for a future design that can be truly highly available no matter if there is a blackout in one datacenter or failure from one of the main Cloud Providers (Azure, AWS, GCloud).
Furthermore, since we are using GKE for our Kubernetes cluster, it makes things a lot easier for managing after when you have a convenient dashboard to check out and help you debug. In the future, the ideal setup would be not to rely on GKE at all but instead customize the cloud instances to have a more robust cloud cluster.
Cluster Design
Our current Ethercluster design relies on being in one region and zone, but that can be easily expanded to multi-zone and multi-regional setting.
For our Kubernetes architecture, we built the node deployments using StatefulSet because we want our Pods to easily pick up where they left off in resyncing the chain and nodes even when we restart them for updating images or adding more custom features.
Using the StatefulSet allows us to preserve the state of our nodes. We also expand it to several replicas, have 4 nodes running as a default per StatefulSet deployment. Currently, the drawback to this design is that all those nodes are being run on the same StorageClass (in this case, Persistent Disk Solid State Drive), so if there’s a failure with the storage, all three nodes are affected.
The solution to that is to create more StatefulSet classes for the same network and distribute them regionally to have a much more failsafe cluster.
Here, we have a handful of Classic and Kotti nodes each load balanced. Since it’s just an HTTP URL, there’s no need to sign up or request an API Key. The hope is that because of this project being open-sourced, it can inspire others to replicate it as well.
The endpoint provides session affinity, so you don’t have to worry about connecting to one node from the load balancer and be reconnected later to a different node. With session affinity, you are guaranteed from the load balancer that you’ll always connect to the same node, provided it is available to connect to.
In the following, we will show how easy it easy to scale from three Parity nodes to 4 with Kubernetes. You’ll see a 4th Parity node being synced eventually.
You can check out the manifest files on Github here.
Containerize Everything
The whole site is mostly run with Docker containers that we manage with Kubernetes. This shows the true power of using containers with Kubernetes. You can easily update Parity or Multi-Geth to the latest image that will be compatible with an upcoming hardfork, or move nodes from dev to prod with ease.
You can plop on top of it a Service so nodes can communicate with each other. In fact, you can also design it in such a way to test different hardfork changes across clients. An example would be by having each container instantiate replicas that are forced to discover one another and communicate with each other to determine if consensus or other aspects work.
By having the power of cutting edge devops and infra-as-code, there’s so much you can do with it.
Here, Ethercluster runs in default with Parity, since Parity has the lowest footprint on any server. A future addition would be adding more clients like Multi-Geth and other clients as well as running more networks such as Astor for SHA3 as well as reviving the Morden testnet.
Default manifest comes packed with the container for Ethereum Node Stats, which can be helpful for monitoring your nodes.
Future Applications
There’s a lot of ways Ethercluster can grow. My main goal is to make the manifest templates into an application that can be run with the command-line, which is a convenient next step.
Integrating IPFS would also be cool for the future. Having more customized infrastructure design that can truly utilize multiple cloud providers and kops to deploy the Kubernetes nodes on top of it would be an amazing future target.
Supporting more networks, making the Kubernetes design more robust on the volume and regional side, adding more customized dashboards for the state of all the nodes, that would be all a great target goal for the project.
For now, though, we focused on the MVP for our community, which was providing reliable endpoints that easily connects their dapps to the ETC network, and we are pleased with the end results.
Please don’t hesitate to DM me if you have more questions about the project or how you can integrate it with your Web3 application. Now, everyone finally has the option of achieving true decentralization by not relying on a centralized endpoint like Infura. Instead, they’ll have the knowledge and code to build their own scalable node infrastructure!
