We have been hard at work creating the global infrastructure to support Cardano Shelley Mainnet while we wait for Stake Pool Operator (SPO) support in hardware wallets. While we wait it’s time to give you a breakdown of our infrastructure, the decentralization we bring to Cardano as a Stake Pool Operator and how we setup everything for SPO peering arrangements.
This first part in the two part series will cover infrastructure, decentralization and SPO peering. and part two of this series will discuss security.
We decided early on that for supporting Cardano a decentralized infrastructure is crucial (see I did it again!). We see this as a balancing act, especially as we move into the 4th Industrial Revolution. It’s hard to be anywhere in the cloud and not rely on one of the “big 5” providers, however we can spread out or agreements so we contribute as little to each providers centralization of data and power. If your not familiar with what we are talking about I invite you to click the above link or you can look for the book by Klaus Schwab of the same name.
One way we help decentralization data and power in addition to the blockchain is having our own datacenter colocation and bare-metal servers in Northern California. This will be the core infrastructure with a node to produce blocks for the stake pool as well as a low latency relay node. We have a standby block producing node that we can activate in case of any hardware, peering transport or other failure. As long as Charles and team provide a replacement for the high availability of block producing nodes phase 2 expansion will include a review of architecture and place 1 redundant block producing node in the colocation and another 1 outside of the datacenter.
The datacenter infrastructure is connected to utility power with a diesel backup generator with indefinite refueling contract. The network is build for no single point of failure with multiple dual-entrance SONET OC-12 fiber rings, and gigabit fiber. Using FM-200 waterless fire suppression systems and cooling management that allows a 3 dimensional view and control of temperature distribution within each cabinet.
Having a single point of presence doesn’t provide the best support of the Cardano mainnet and testnets. This is why we also use cloud providers, but we spread it among multiple cloud providers which diminishes the impact of a failure at any one provider.
We have multiple relays in the US. With west coast and east coast relays using two different cloud providers, as well as residential ISP’s. So each coast is protected from a single cloud provider failure. Each coast also has its own RR DNS entries to aid in peering configuration with other stake pools.
In addition to our US relays in the cloud and 1 in the colocation (awaiting a new IP Block assignment) we have a number of residential relays. Team members and their extended family are participating and along the west coast we have 1 residential relay up today another two coming up this week, and four more within a month. This will put us at 7 residential relays to combine with our multiple cloud and colocated relays. More residential relays will potentially be deployed during road map phases 2 and 3 as well if the team expands.
South America / Europe / Asia
Additional relays in South America and Europe are planned as part of our Phase 2 & Phase 3 expansions.
Currently we have no relays in Africa as we are relying on our European relay at this time. We are hoping that SPO’s in Africa are looking to peer and we will be actively seeking stake pools in the region to peer with our relays. Our first regional relay is either in phase 2 or phase 3 of the roadmap. Once we have delegators in the pool we will investigate and determine which phase will include a relay in this region.
The FQDN for all relays is relays.cardano-mainnet.chaincrucial.io, but each region has it’s own regional FQDN as well. This is to aid with SPO peering. If an SPO wants to peer in specific regions they can use the Regional FQDN and as regions are expanded new relays will be added to the FQDN. SPO’s can simply increment, or decrement, the valency for the specific region to make changes.
Below is a table of all current relays by region, the colocation low latency relay should be up once we have a new IP block assigned to the colocation.
|US West – N. California||Colocation||TBD / From New IP Block|
|US West – S. California||Cloud||22.214.171.124|
|US West – N. California||Cloud||126.96.36.199|
|US East – S. Carolina||Cloud||188.8.131.52|
|US East – Ohio||Cloud||184.108.40.206|
|ASIA – Hong Kong||Cloud||220.127.116.11|
For SPO’s who want to peer regionally, below is the list of addresses that can be used to simplify the setup.
|Region||Fully Qualified Domain Name|
All phase 2 and phase 3 relay expansion locations will be determined by delegators. That’s right, delegators will be voting on the locations and timelines for relays within all regions. We think were off to a great start at creating an efficient and decentralized relay network, however we want our delegators to be able to choose the next locations of our relays their maintenance fee’s will pay for. Whether you’re choosing your first stake pool or re-delegating from one of the many over saturated pools if you would like a voice in where your SPO has relays, then consider staking with ChainCrucial.
If your happy with your current SPO then maybe when wallet one to many delegation and staking profiles comes out consider supporting ChainCrucial by delegating us a part of your stake.
Please join us for Part 2 of this series, when we discuss our security posture and policies. We’ve have decades of experience in datacenters and large enterprises including the financial industry including heavy compliance. We weren’t joking when we said we cared about security, and Part 2 is when we put our money where our mouth is and break it down.
Comments are closed