To start a blockchain project, one of the first things that needs to be defined and implemented in any development project is the working and production environments where the product will be developed, tested, and deployed.
Identifying & defining the testing and production environments that will provide access to a blockchain distributed ledger, and smart contracts have several considerations, such as permissioned or permissionless blockchain, reliability, and elasticity.
Over the course of two articles, we will explore the journey and considerations that Encora made for choosing the right environment setup for a project under Ethereum Mainnet; also, a guide and tips on how the final implementation was done.
These articles don’t intend to imply that one environment option is better than another, but instead intends to demonstrate how Encora can help choose and implement the best option for each use case.
Ethereum QA and Production environments
It is essential to clarify that for the project, the idea was to use and connect to Ethereum Mainnet and Testnets; we are not talking about a permission for implementation or any other compatible EVM environment here.
At a basic level, we needed to connect with Ethereum Mainnet and Testnets. Therefore, we needed a client node that accomplished this. When we talk about a client node, we are talking about any VM, container, machine, or cloud infrastructure with the client software that allows it to connect with the blockchain.
For a smart contract development environment, VMs and Testnets integrations that bring IDEs like Remix were enough to test and deploy single, smart contracts functions. But this wasn't optimal for developers and QAs when they needed a more thorough review and integrated testing (with Dapps and other actors).
So, we had to define a QA environment over which we could test end to end project functionality and as well define the best production environment.
The first point of consideration is to identify the Ethereum client to be used. This is a point that many people overlook, but as Ethereum blockchain popularity and use advances, more clients are created, adding new capacities and improvements.
Currently, more popular clients are:
- Geth: Golang implementation and most popular. Allows creating full, light, and archive nodes.
- Erigon: Geth fork with improvements on speed and disk space optimization.
- Hyperledger Besu: Java implementation, good integration with web3.js.
- Nethermind: .NET implementation runs on all platforms, including ARM, with an optimized EVM.
For this project, we decided to look for implementation options with Geth client, mainly because it is still the most used and proven client, provides access to testnets, and has the implementation for full, light, and fast nodes.
Once the client was decided, we needed to consider where the client will be deployed. Here we had two options:
- Use a third-party service node provider: these are providers like Infura, Alchemy.
- Running our own network: this option has two sub-options
- On-Premises / Cloud implementation.
- A Cloud Managed Service implementation.
Node Providers
Node Providers offer the full infrastructure for accessing, monitoring, and developing on blockchain. They cover Ethereum Mainnet and Testnets and other networks like L2 Polygon and Arbitrum.
With these services, you don't have to worry about infrastructure implementation details, or any point related to reliability, elasticity, backups, and connectivity since you delegate and trust what the provider is offering.
The most popular services are Infura and Alchemy. Infura has some clients like Metamask (the most popular wallet) and Uniswap. On the other hand, Alchemy offers its services to clients like Meta, Shopify, and OpenSea.
This type of service takes advantage of economies of scale, and its reputation depends on the SLA offered, security, and clients' trust in them.
Usually, this kind of service offers some advantages like ease to use, technical support from a specialized team and transitioning effort of setting up and keeping up the infrastructure to a third party. But that also means some other points to consider, like the reliance on a third-party provider (dependency on one actor when looking for a decentralized approach could sound a little ironic), privacy, and costs.
Regarding costs, Infura offers up to 100,000 requests per day on a free tier, and Alchemy offers up to 300 million requests monthly at no cost. Obviously, these basic tiers include primary nodes and functionality. Additional costs depend on the needs of the specific use case.
Running your own network
Running your own network option is worthy when you look for privacy/security, sovereignty, and control over your blockchain infrastructure and decisions. Nevertheless, it usually comes with the challenges of building something that allows reliability, elasticity, and all the details related to a robust setup that accomplishes all those goals.
One can think of having a single node client and, from there, provide access to the blockchain, but is it enough for a real-life project? What about redundancy, concurrency, and load? What about security?
Besides, client nodes suffer from “regular” issues like peering problems, corrupted local layer, broadcasting errors, CPU, and memory spikes.
To plan and deploy a node infrastructure that complies with all previous needs stated, require high maintenance, are time-consuming, and therefore, typically is expensive. The final price includes machines or cloud services, a support team, backups, and monitoring, among others.
Evaluating an on-premises setup will require assessing the reliability of the current on-premises environment, how to manage access, stability, what machines and CPU, I/O access, memory, connection with the network, and multilocation.
Another option is to create nodes on a cloud, using VM or containers with major public cloud providers such as AWS, Azure, or Google
Another option is managed services like the one from AWS. AWS Blockchain Managed services eliminate the overhead of self-provisioning, reliability, elasticity, backups, and maintenance and delegate that to service. However, unlike node providers, you are still managing the infrastructure.
Azure used to have a similar service; however, they have deprecated it, and third parties also offer managed service. QB (Quorum Blockchain services by Consensys) and Kaleido.io are well known providers. However, those solutions are currently optimized for permissioned implementations, but it could be good to keep an eye on how they evolve and start, including permissionless deployments.
Final chosen implementation
The final QA and production environment chosen for Ethereum Mainnet and Testnets connection was using AWS Blockchain Managed services. The main reason was that, for the use case in question, the project needed to be on a “managed” infrastructure, even if that meant an overhead on provisioning and maintenance. We understand that a multi-cloud or hybrid approach would probably be a better option for reliability and stability. Still, we were good with just having it on one cloud provider for that met the use case requirements.
As summary:
- Always evaluate each company/project's need, policy, functional and non-functional requirements, and budget for choosing the implementation strategy that fits better.
- Constantly evaluate new players and offers in the market. Blockchain is evolving fast, and new options will be available and maturing in the short and mid-term.
- Look for options that cover the needs for connecting effectively with Ethereum and what is needed for the Dapps or client apps to provide the best experience to end users.
In the following article, we will review the Ethereum nodes' implementation process over AWS Blockchain Managed services.
About Encora
Fast-growing tech companies partner with Encora to outsource product development and drive growth. Contact us to learn more about our software engineering capabilities.
