Telos Block Producer Infrastructure Requirements

By Azad Halim and the Telos GRC & Security Working Groups

This document defines the infrastructure standards that block producers must meet in order to be compliant with the technological components of the Telos Block Producer Minimum Requirements.

  1. Introduction

Block producer (BP) participation is first and foremost subject to the Telos Network Operating Agreement and signing the Regproducer Contract.

BP infrastructure requirements presented here exclude the impact of Random Access Memory (RAM) market price variations and may be revised if necessary prior to, or post, Telos MainNet launch.

Considerations were made for the inclusion of BPs that may not have the capability to provide a full service coverage of all the Telos components, aka plug-ins, at the time of MainNet launch but are able to meet the absolute minimum infrastructure requirements to participate as Telos members subject to an action plan put in place to incorporate the additional components in stages as defined by the Telos Launch Group (TLG).

This document uses the traditional risk management model to map EOSIO components to technology controls to provide Confidentiality, Integrity and Availability (CIA) of data that is either owned by Telos members or is processed on their behalf by 3rd party participants and/or distributed applications.

2. Details

The Telos platform comprises of three distinct networks:

  • MainNet is the production network where all official Telos value and transactions are recorded.
  • Staging is used to receive all new code updates for at least 24 hours prior to incorporating them into the MainNet. DApp developers who wish to remain extremely current on each new version may also utilise it.
  • TestNet is a network for developers and others to have a full but valueless version of the network for testing.

Candidate BPs may join the Telos network at a level of their choosing as listed below:

  1. Establish a TestNet node comprising of all the Telos components (plug-ins) and perform a prescribed number of tests.
  2. Build Staging Producer, Chain & Full Nodes or upgrade the TestNet node to meet the minimum requirements of the MainNet nodes with which the BP is planning to join.
  3. Establish MainNet presence in addition to Staging and similar in specification.
  4. Add a MainNet Seeding-Node.
  5. Add a load-balanced Full-Node and a backup file-system for fast blockchain playback.
  6. Add DDoS protection, security event monitoring, alerting, command and control capabilities.

Figure 1 below provides an outline of the EOSIO components distributed across a typical network architecture referenced in this document to explain the basic principles of security controls that could be applied by BPs.

Figure 1. Example EOSIO Implementation
Table 1. Block Producer Risk Reduction Participation

Unless a mechanism is put in place to reward BPs based on their level of contribution, as shown in Table 1 above, all BPs will be rewarded in equal measure based on token holder perception of their contribution, hence their ranking will be based on the number of votes garnered, not the actual or underlying cost of hosting and operating their infrastructure.

3. Recommendation

Token holders, as stakeholders and/or enthusiasts, should be aware of the costs & benefits of applying additional layers of security controls to protect their stake or interest in Telos as it is ultimately up to them to make Telos a success.

Figure 2 below presents these controls in the form of security layers that BPs should consider while building their infrastructures to protect the core which most token holders will view as Telos’ block production capability but ultimately they will be staking on its availability, the integrity of their transactions, confidentiality of the data and accessibility to the platform as a whole.

Figure 2. Telos Technology Controls

At MainNet launch, BPs will be able to join at Level 3 and may choose to run a subset of the EOSIO components (plug-ins), negatively impacting end-user experience whereby, for example, a limited number of API nodes may not be geographically diverse, as was the case with BitShares, resulting into poor connectivity, user dissatisfaction and loss of interest from token holders.

Table 2. Requirements for Level 3 BP participation.

At the time of writing this document, EOS MainNet was reported to have only two operational Seed nodes. For the casual observer this may seem to be sufficient, but in reality the lack of participation by capable BPs demonstrates lack of commitment, elevates the risk of network failure, the integrity and availability of historic data. A targeted attack on a limited number of Seed nodes may render the whole network useless.

One might ask, would an attacker be able to present a revised history of the blockchain? If this is a probable threat scenario, majority of BPs must operate at level 4 or higher with the minimum requirements shown in Table 3 below.

At level 4, BPs must run the following EOSIO software components:

  1. chain_plugin
  2. chain_api_plugin
  3. history_plugin
  4. history_api_plugin
  5. http_plugin
Table 3. Requirements for Level 4 BP participation.

Prior to launch, BPs that are active on TestNet may choose to establish milestone dates for lifting the infrastructure to collectively operate at the higher 5 and 6 levels , subject to the standard ⅔ + 1 vote in favour of doing so.

Table 4. Requirements for Level 5 BP participation.

Finally, if Telos is to attract customers/users from major industry sectors, the expectation will be that all BPs will be operating at Level 6, or higher, to meet the most common cybersecurity standards and regulatory compliance requirements that are applicable to them.¹