EOSDR.io has a combined expertise of over 50 years designing, building and supporting very complex network environments in highly demanding industries such as retail, hospitality, eCommerce, web applications, healthcare, online casinos and banking.
Having worked on all these verticals, our team also possesses an expert understanding of security and regulatory compliance best practices. We have brought all this knowledge to bare in the design of our EOS Technical Proposal for both testnet and mainnet.
As custodians of such an important platform, EOS Block Producers (BP’s) need to ensure that the network and computer systems managing the hundreds of thousands of transactions per second, estimated at this time for processing in serial or parallel methods, occur with the highest degree of security, low latency and as resistant to failure as possible.
At this time, only some information is known about the requirements for the EOS network and performance requirements. Thus, our solution is easily scalable to accommodate to any unsuspected changes. We have drafted our technical proposal with cloud service providers in mind (AWS, Google Cloud), for the sake of agility.
However, depending on the needs of the users and appropriate business case, future phases might include EOSDR.io owned equipment. This equipment would be co-located in the NAP of the Americas datacenter, located in Miami, FL.
It is important for everyone to keep in mind that it is the job of the Block Producers to ensure optimum performance with very little to no risk, in the most cost-effective way. This will ultimately translate into a more efficient distributions of BP rewards going back to the EOS community. We will leverage our experience, know-how, transparency and integrity to make this happen as Block Producers for the EOS platform.
In addition to a powerful and resilient infrastructure (defined below), EOSDR.io is prepared to offer a set of services to the EOS Community of voters, dAPP Developers, other users and fellow Block Producers.
As part of the core set of services, our servers’ operations and health will be monitored constantly. Both technically and functionally, our Incident Management and Infrastructure Engineering teams will handle any issue and act when needed. Whether it is a request for arbitration (or account freeze) or anything related to system stability, we aim to exceed expectations and accurately report on our performance. We hope to collaborate with other BPs to produce adequate tools to achieve this level of efficiency and transparency. Our voters are entitled to know everything, always.
Team members of EOSDR.io are intimately familiar with regulatory compliance frameworks and best practices. We believe that, although there is no requirement at this time for any Block Producers in this regard, we should operate in a manner consistent with such compliance expectations outlined by COSO (as an example). We will collaborate with the EOS Community to draft an applicable subset of this framework, so the community can hold BP’s accountable, maintain proper homogeneous controls and mitigate risks on the EOS platform. Perhaps in the future independent bodies can audit BP’s.
OPERATIONS: The system will be maintained and monitored using a combination of several open source tools to keep both time series graphs as well as service availability charts. There will be several individuals in our NOC and on-call, aware of the condition of the environment. The team will provide either an on-demand report or access into the real time health and dashboard. Note: We may not be able to provide completely public dashboards and may have to provide invitational dashboards based on adversarial attack patterns. Our goal is to aid the community by correlating real-time system health and metrics with the performance of the network in order to improve performance or provide better statistics and calculations of required infrastructure.
SCALABILITY: The most fundamental characteristic for Block Producers’ network infrastructure is to have the elasticity to adequately expand very quickly, without any downtime. We may initially start in one cloud provider with several availability zones, but the intention is to leverage multiple cloud providers. The elasticity of the environment will be performed via several operational best practices. One of them will be to keep all infrastructure services referenced in code and use CI/CD-like tooling to keep servers running. Another objective in this area is to provide services and nodes to areas in Latin America and other regions which may not be getting the appropriate support from the network.
FAULT TOLERANCE: Every computer device will fail at some point. We will be leverage tooling like Chaos Monkey to randomly shutdown and restart services in order to prove continuous redundancy in the system. This will allow for ease of maintenance and expectation of service. This will also ensure we have included redundancy at every level. There should be no single points of failure as every component of the production environment has a secondary High-Availability counterpart. We eventually will include multiple cloud service providers, with Google Cloud being the first. We will need to understand the dynamics of the EOS Ecosystem’s requirements before attempting to scale out to a larger environment.
LOW LATENCY and COMPUTATIONAL PERFORMANCE: The following machines will be part of the first phase, based on their roles (see diagram below). Again, every component is upgradeable and horizontally scalable, so we can respond to the EOS network demand for both sequential or parallel (when it’s available) processing method. We hope to share our performance and throughput tools with the rest of the BP's and community, so everyone can gauge our performance. In the future, we see the need to develop Predictive Business Intelligence tools to help us manage network loads more efficiently. We will participate in the development of such tools if necessary.
Our initial infrastructure will be as follows:
The computer nodes will be initially sized as n1-highmem-32 – Memory Optimized Compute Nodes
o 32 vCPU’s
o 208GB vMEM
o 3x375GB SSD Drives
Each of the Availability Zones will have initially 2 Compute Nodes:
o EOS Node
o Public Block Producer
We will also have at some point storage pools that will be able to scale out as needed.
INFRASTRUCTURE SECURITY: The architects of the system will be following several security paradigms to try and keep the system free of breaches. Those paradigms will follow frameworks such as the NIST CSF and CIS Top 20 standards.
Overall the system security will be dictated in several ways:
Most of the security of the system will NOT be described here and will be obscured from public view as we would like to keep an element of surprise to any adversaries.
DEVELOPER SANDBOX/TESTNET: EOSDR.io currently provides a sandbox as part of the PUBLIC TESTNET to any dAPP project that needs specific services.
The TESTNET computer nodes will be initially sized as M5.2xlarge – General Purpose Compute Nodes
o 8 vCPU’s
o 32GB vMEM
o Unlimited Elastic Storage
VALIDATION BY ANOTHER BLOCK PRODUCER: we are very confident of our ability to deliver the services and trustworthiness expected by the EOS Community. To prove it, we are open to the possibility of having another randomly selected BP validate our infrastructure. We do this because we believe very deeply in the collaborative spirit and to ensure all voters we are who we say we are, we do what we say we do. We encourage others to do the same!
