Full disclosure: Let's publish validator operations & infrastructure info 📖

Full disclosure on Figment Networks’ Cosmos validator infrastructure and operations: https://twitter.com/FigmentNetworks/status/1136000871463104512

Let’s get about how to make staking on Cosmos as secure as possible, and let’s be open for delegators to make informed decisions.

Spread the word: more transparency and a stronger, more secure Cosmos network

Medium article here

Thanks Gavin, we will be publishing something soon for Neptune Stake and I think this is a great initiative.

Something I would also like to see added to the block explorers, is some way to indicate which validators are using an HSM versus software keys, as I think its an important consideration for delegators.

Im not aware of any way to do this automatically, but even a community verification for HSM and correctly setup infrastructure would be very beneficial for the community.

This would both inform delegators which validators have properly setup infrastucture, and also encourage validators that dont to improve their setup.

Thanks Guy, it would be nice to have a badge or something to indicate HSM-based validators. But verifying that would open a whole can of worms that we’re not prepared to handle at the moment. We’d be open to chatting with anyone else who is interested in implementing this sort of thing

HSM based validation is not the only secure solution. We use a custom remote signing sever, which is similarly secure. If you want to prove that your setup is really secure, get audited from a 3rd party and publish the results. Feel free to get in touch with us https://www.ethermat.com

If you want to go a step further get certified… ISO27001 etc.

We strongly believe that the ecosystem might profit from non-HSM validators. If all deployments were the same, potential attacks would have a critical impact. Mixed validators with different deployment styles and (custom) software strongly add value to the ecosystem.

Here’s Chainflow’s -

Chainflow Cosmos Validator Network Architecture

This architecture draws on my 20+ years of experience designing large, global and mission critical network and data center architectures.

In describing the architecture, I again am trying to strike a beneficial balance. This balance is between providing transparency, while not compromising operational security.

we did publish some along the way

On Validator Setup » How to Choose the Best Validator? | 01NODE

How to choose the best validator? Or a particular one for that matter. Most of the time we let the metrics tell the stories, and we are more about the facts and action than words, although good stories do sell! But this time we decided to give a...

on validator setup — part2

i think it s time to publish an update regarding our validator setup.

Reading time: 2 min read

We will be disclosing ours soon in a medium post and also our learnings along the way. Will update here!

Great idea!

We’re already providing documentation about our infrastructure through our website: https://validator.network.

Datacenter:

• Using YubiHSM inside redundant isolated hosts
• Redundant validators hosts

Redundant, dedicated bandwidth to AWS Frankfurt where we operate multiple public sentry nodes in different availability zones.

We’re doing 24x7 monitoring via Pagerduty on logs and Prometheus data and have developed in-house tooling for improving observability.

20+ years of experience operating secure and highly available IT infrastructure.

You can find a description of our validator architecture and some operations info here: the iqlusion blog on Svbtle A look inside iqlusion's Cosmos Hub Validator architecture • the iqlusion blog By Tony Arcieri and Shella Stephens Here at iqlusion, we have taken our past professional experiences from infrastructure and security teams at notable Silicon Valley companies and applied them in building what we believe is one of the most... | the... We also tweet when we’re performing maintenance, noting if there was downtime/missed blocks, and also have published a postmortem for our first outage: the iqlusion blog on Svbtle Postmortem: 2019-03-29 DNS-related Cosmos Hub Validator Incident • the... It began with a series of PagerDuty alerts on our phones. We occasionally have false positives, but this was different: several alarms in a row. We looked up at the display in our NOC (above photo, although from a different day) to see that this... |... Gavin: Thanks Guy, it would be nice to have a badge or something to indicate HSM-based validators. This would be interesting, especially if…

Excerpt (1196 of 1605 characters). Read the whole post on the forum ↗

We have just published our setup and some learnings here: http://bit.ly/SetupAndLearnings

We will continue to publish articles on some tools we use and more learnings along the way. Happy to discuss infrastructure related issues!

We just published our infrastructure to our website: https://freshatoms.com/

We do not have automatic failover yet, for fear of slashing, but we can get the spare node and signer running nearly seamlessly in case of maintenance (missing 0 to 3 blocks max), or on alert (in case of failure) within minutes of receiving the alert (which is monitored 24/7).

KIRA Staking, architecture overview and disclosure -> https://medium.com/kira-core/kira-cosmos-hub-validator-db1828264506

Question(s):

Does the broader Cosmos Hub community have the right to explicitly know, and distinguish, whether or not certain Validators are the same entity, direct partners, etc?

(Instead of opening a new conversation, saw this thread captured the general sentiment of the question above)

How is a user to know if certain COI’s exist within the Validator set when choosing to delegate?

At this point, who is to say if Validator X is, or is not, Validator Y, or Validator Z? In the spirit of securing true decentralization, is publishing validator operations & infrastructure info “enough?”

Curious to hear others thoughts.

Fascinating to see validators blatantly ignore these questions, which would serve as a net benefit for all small/new validators, delegators, and users, to be made fully aware.