The team at Block Matrix are excited to officially announce our candidacy to be elected as a Block Producer (BP) for the EOS network. We are an experienced team, with a proven record of designing, developing and launching large scale commercial infrastructures. It is our belief that the EOS project will lead the industry into the next phase of innovation, commercial adoption and pioneer the next wave of decentralised, self-governing ecosystems. We are proud to be part of it!

1: Public Presence

• https://blockmatrix.network
• https://t.me/blockmatrixnetwork
• https://github.com/BlockMatrixNetwork
• https://steemit.com/@blockmatrix

2: ID Information

Official block producer candidate name

Block Matrix

Location of company headquarters

We are a fully registered UK limited company based in Newcastle, England.

Expected location of servers

For the June launch, we will have servers deployed in Ireland and N. Virginia in the US.

Type of servers

Our team have extensive experience in deploying enterprise grade cloud based infrastructure, so for the launch we are focusing on a cloud architecture within Amazon AWS. We are taking great care to future proof our design by ensuring that our cloud infrastructure and configuration isn't tightly coupled to AWS.

Current employee list and background qualifications

Pete Cheyne, Co-Founder

Pete has 18 years commercial experience building enterprise grade technology platforms with global scale that have been responsible for processing billions of dollars in transaction volume. He was part of the founding team at performancehorizon.com and has been involved with blockchain technologies since 2011.

Chris Tuohy, Co-Founder

Chris is a serial entrepreneur with a background in engineering and commodities trading. He has been active within the crypto space for several years and believes that blockchain technology will revolutionise almost every industry we know.

Alan Howard, Co-Founder

Alan is an industry veteran within the financial sector. He has served on the New York Federal Reserve's investor advisory committee on financial markets and is the co-founder of Brevan Howard Asset Management LLP.

Joshua Edwards

Josh is an experienced cloud architect, designing and deploying large scale infrastructure for corporations such as Accenture and Capgemini. With a deep understanding of cloud architecture and security, Josh is ensuring we have a scalable and secure platform in place from launch.

Stepan Lustov

Stepan is a devops specialist, combining 10 years of commercial experience designing and supporting highly available infrastructures and high volume applications. Stepan will be automating the deployment of our entire stack through configuration management and will be focused on monitoring, capacity management and performance tuning.

3: Tech Specs

We have put a lot of thought into the architecture to ensure it has the right balance of availability, redundancy and security so that it can easily scale out once the mainnet is launched and we have a better understanding of the demands of the network.

Throughout the architecture, there is no single point of failure as all services and server roles are distributed and at least N+1 redundant. We are protecting the producer node and its standbys from direct external access and at launch we will have 2 regional clusters with geographic separation.

Network Architecture

Load Balancers

We will have two distinct load balancer (LB) roles. The first is an external facing LB which will accept all network requests and filter these requests through to the non producing nodes.

The second LB role is internal, it will facilitate requests to the currently active producing node, from both the non producing nodes and the trusted peer group of external BPs.

Combined with upstream DDoS mitigation, this setup will provide sufficient protection to all nodes, ensure we maintain consistent access routes to all services, and failover can be actioned without the need for any other node in the network to update its configuration details.

Non Producing Nodes

The non producing nodes will be publically accessible, acting as a resource for blockchain users and dApps. They will also shield the producing node from any direct query requests from the external network. All non producing nodes will be considered active and the LB will distribute valid requests to all nodes.

Launch Specification

• OS: Ubuntu
• Instance type: X1e
• vCPU: 8
• Memory: 244 GiB
• Storage: 240 GB SSD
• Network: 1 GB/s

Producer Nodes

The producer nodes will be located within a private subnet to shield them from all external requests. The nodes have a dedicated LB that is aware of the currently active producing node. With a combination of the LB and custom scripts baked into keepalived, we have designed an automated failover solution so that in an event of failure, the promotion of a backup node (config update, key exchange, etc) happens as quickly as possible.

Launch Specification

• OS: Ubuntu
• Instance type: X1e
• vCPU: 8
• Memory: 244 GiB
• Storage: 240 GB SSD
• Network: 1 GB/s

Security

Security considerations for the producing nodes is of paramount importance. We are working with the BP community to ascertain the best possible methodology for connecting our active producing node to the other external BP nodes. Currently we have a Wireguard VPN solution in place, combined with an elastic IP which allows us to failover to a backup node without affecting configuration requirements for the rest of the network.

Storage

In preparation for the IPFS integration, we are building out a redundant network storage cluster.

Launch Specification

• OS: Ubuntu
• Instance type: d2.xlarge
• vCPU: 4
• Memory: 30.5 GiB
• Storage: 3 x 2TB HDD
• Network: 1 GB/s

Location

We will be using 2 regions within the Amazon ecosystem, post launch we plan on scaling this out to meet the demands of the network and to keep latency as low as possible.

• Cluster A: eu-west-1, EU (Ireland)
• Cluster B: us-east-1, US East (N. Virginia)

Both clusters will have the same infrastructure to ensure they are equally capable of being considered the active primary.

Security and Monitoring

Our team are leveraging both good security design principles and best practice processes such as end-to-end encryption (in transit and at rest) with auto-rotation of keys and locked down protected private subnets for producing nodes with filtered outbound internet access.

We will implement monitoring, auditing and alerting tools such as Grafana, GuardDuty, CloudTrail, CloudWatch, and Pager Duty. All of our environments will be designed using the latest DevOps architectures to create a fully immutable environment that can be re-created in minutes. This will ensure that we have the highest level of security, consistency, reliability and protection within our network.

Our goal is to adhere to the AWS UK government official level security architecture, you can read more about this here: https://d1.awsstatic.com/whitepapers/compliance/AWS_CESG_UK_Cloud_Security_Principles.pdf

We are going to engage an external security consulting firm to take periodic audits on our infrastructure to identify any areas for improvement and learnings from this will be taken to the community so that fellow BPs can benefit from the findings.

Costs

Production

For our production system, which will be fully in place by mid-May, we estimate the initial monthly infrastructure cost to be around $12,000. It's not possible to give a more accurate figure at this time due to variable bandwidth costs and not fully understanding production usage patterns of standby nodes, etc.

Another point of consideration is DDoS protection. This could add up to $5,000/month to the outgoings based on the chosen provider. We are still investigating the best solution for this with the BP community.

Future

The cost for the current architecture does not include personnel costs, selling, general and administrative expenses. If our proposal to become a BP is successful, we are committed to absolute transparency around all costs of running our business and will make a full breakdown of costs available to the community.

GDPR

GDPR is an important topic, with a lot of uncertainty around how this will be policed within the blockchain industry. As our founding team are based in the UK, we have been exposed to this impending legislation for over a year and have personally met with various consultants and authorities over the last 12 months to ensure that our previous business interests were prepared for GDPR compliance.

How this will apply to BPs is not known, it is possible that we could be held accountable as data processors. It is the general consensus that it's the dApp developer's responsibility to be mindful of GDPR, but due to the immutable nature of the blockchain it is more than plausible that PII data can and will be exposed.

At this stage, we are planning to keep up to date with our contacts who advise on GDPR legislation and will inform the community of any developments in this area.

4: Scaling Plan

We have taken great care to ensure that the instance class chosen for our servers provides substantial capacity to scale up. Whilst battle testing our architecture pre-launch is great for understanding artificial limits, it is impossible to accurately predict the demands of the mainnet once launched and how quickly that demand will grow.

Auto scaling our environment is a key part of our design process, and it is one of the top benefits of being in the cloud. As all server roles will be covered in our configuration management tooling (Ansible), we will be able to launch new machines of any server type within minutes.

For the producing and non producing nodes, we are using the X1e instances from Amazon. They are powered by four Intel Xeon E7 8880 v3 processors that feature high memory bandwidth and larger L3 caches to boost the performance of in-memory applications. This instance type allows us to scale up all major components:

• vCPU: Up to 128
• Memory: Up to 3,904 GiB
• SSD: Up to 2 x 1,920 GB
• Bandwidth: Up to 14 GB/s

We are committed to being cloud provider agnostic, over time we will look to integrate other cloud providers and will continue to add additional regional clusters to ensure the best global coverage based on the network demands.

Once we understand more about the IPFS implementation, we can scale out this service and will ensure it is available multi-region so that we can keep request latency to a minimum.

Within our monitoring framework, we will have specific charts for capacity management as well as auto scaling triggers based on actual usage. We understand that scaling is never on a perfect linear trajectory, so it's important to be able to fluctuations and sudden surges in demand.

5: Community Benefit

As a Block Producer, we understand the importance of the role we will play in the network. Therefore we want to lead by example by being a committed and positive member of the community. We believe that we have a great deal to offer based on our past experience, the majority of our community efforts will be centred around:

• Community articles based on technical aspects of the EOS project, tutorials for creating or interacting with the network, how to kickstart a dApp project on the network, etc. Here is an example of a node creation tutorial: https://steemit.com/eos/@blockmatrix/setup-an-eos-test-node-block-producer-with-ssl-testnet

• We are strong believers in open source. We will make all tooling that we build to support our BP network available through our Github. Rather than protect our competitive advantage, we see that sharing knowledge and tools to other BPs is a net positive for the community. For example, to get prospective BPs up and running as quickly as possible, we released an ansible playbook which will automatically create a producing node and hook it into a testnet: https://github.com/BlockMatrixNetwork/eos-testnet

• We have proven track record of building and running successful start ups. We are excited to help foster a start up culture around the EOS project, it's a perfect opportunity for a new wave of businesses to build products and services on top of the protocol. There is a thriving local start up scene in the UK, and we propose to leverage our personal relationships with local incubators and universities to cultivate a new EOS community in the area. Long term, we would like to open this up to a wider audience once the local community is established.

6: Telegram and Testnet

Telegram

If you would like to chat, we have a public company Telegram: https://t.me/blockmatrixnetwork

Pete is active in various EOS telegram groups: https://t.me/blockmatrixpete

Test Networks

We have been active in various testnets, the community vibe in each has been great - we are all learning together!

• Network: http://jungle.cryptolions.io:9898/monitor/

• Nodes: Baboon, Spidermonkey

• Network: https://t.me/BPInfrastructure

• Nodes: Block Matrix

We have also built out our own testnet rig within the cloud which we are using for load testing, simulating failover scenarios and implementing alternative configurations.

7: Block Producer Candidate Roadmap

We are an independent, self-funded company with complete control over the direction of our business. We are not subject to any outside influences that could attempt to alter our focus, and we are in the fortunate position that we will not have to raise external capital to support further scaling of the technology or the business.

We are committed to being completely transparent with the community around our finances in respect to earnings gained as a Block Producer and how those earnings are distributed. Our team is experienced enough within this industry to fully understand its unique market dynamics. The token value volatility is something that is difficult to predict and we want to ensure that our business is run in a sustainable way that can absorb large moves in the market.

As well as our technical obligations as a Block Producer, we understand the importance of our duties around governance and upholding the constitution. We believe that the EOS project has the potential to create a truly unique social, economic and technical ecosystem and we are committed to ensure its core values are always adhered to.

We have put together a high level plan for the next 12 months which has a blend of regular themes with growth and community objectives.

8: Position on Dividends

We want to earn your votes through our ability to serve the EOS community and its network, not through solicitation or incentivised offers. It is clear to us that if we are to truly create a self-governing ecosystem, then those in a position of authority must act in a manner with which others can respect.

We will never offer payment to EOS token holders or collude with other BPs in return for votes.