We will use multisignature schemes for all the BP operations involving holding of actual coins (e.g. in the form of BP rewards). The signing schedule will rotate every day, there will be a delay of 12 hours for every approved claim reward operation, while the treasury function will be segregated from the claim reward function. The out-of-band signing functionality will be employed to reduce the risks associated with exposing BP’s active key. The owner key will at all times be cold-stored and will only be used in force majeure situations.
A private VPN backup network will be deployed to ensure resilience of the BP infrastructure to large DDOS attacks. To ensure that DDoS attacks have minimal, if any, effect on the stability of BP performance, AWS Shield is utilized, which does not limit network access of affected servers leading to a much quicker service recovery. View structure
Following the industry security standards and recommendations, Host security is ensured employing, among others, the following methods:
There actual architecture of servers that we run is designed to ensure: (a) resilience and (b) scalability.
The servers are located in EU. The SEED, the API (combined referred to as EOS API) and the BP (EOS BP) are the three instances of the first node. The BP listens to the network via the EOS API. On the second node the EOS API instances are deployed on a single machine while the BP is likewise separate and has no direct exposure to the broader net. View structure
Both EOS APIs are protected by a firewall and are deployed using different ISPs (Internet Service Providers). Most of our processes and procedures are designed to avoid the concentration of any form of technological risk: physically, the actual servers are deployed in different data centers. View structure
AWS Route 53 Service Discovery (SD) module is set up to provide high frequency feeds of the current status of node instances directly to the Load Balancer (LB). If an instance fails, the consistent performance of the BP entity will continue, as the switchover to the reserve machine is ensured to be instantaneous by employing Amazon automated DNS record management. View structure
CPU: Xeon E3-1240 V6 / 1 CPU @ 3.7 GHz with 8MB cache Level 3
Storage: Two 500GB SSD
RAM: 64GB DDR4 ecc
The aforementioned hardware is “hot swap”- deployed on the two machines to ensure the consistent performance of the BP. View structure
A cluster of inactive full nodes is set up to ensure high availability and quick access to the EOS blockchain.
An IPFS-node infrastructure will be developed in order to accommodate the forward looking, in terms of scalability, EOS Storage plan.
Regardless of the block production rewards a fixed amount of funds will be dedicated to hard drive and RAM expansions during the first year of operations.
Finally, as it is company policy, we will search for novel ways to improve, develop, and deploy solutions that are aimed to further our overall initiative of constant scalability.