Stewards as VM on major cloud providers

It appears from various documents related to Stewards, that running a Steward as a VM on AWS is perfectly acceptable. But if all Stewards run as VMs on AWS, can one really talk about a decentralised network? What’s the percentage of Stewards, today, running as VM on AWS or no Azure? I have not seen (or maybe I missed it) this point addressed in the Trust Framework. Could someone comment of point me to the relevant discussion please?

Fabien: This is a much-discussed issue with Sovrin’s Technical Governance Board. There is an official Node Selection Algorithm that helps choose which nodes should be participating in consensus. It takes into account a number of dimensions of diversity, including diversity of hosting environment. You can read more about it here:

1 Like

Fabian, to add to Daniel’s point, this has actually been one of the most-discussed aspects of Sovrin infrastructure—so much so that it is addressed by several of the Core Principles of the Sovrin Governance Framework V2.

In the SGF Master Document, see in particular sections 2.8 (Decentralization by Design), especially 2.8.2 (Diffuse Trust):

Sovrin Infrastructure shall not concentrate power in any single Individual, Organization, Jurisdiction, Industry Sector, or other special interest to the detriment of the Network as a whole. Diffuse Trust shall take into account all forms of diversity among Identity Owners.

And section 2.8.6 (No Single Point of Failure):

Sovrin Infrastructure shall be designed and implemented to not have any single point of failure.

Also, Security by Design principle 2.11.1 (System Diversity):

The process and policies for selecting Stewards shall optimize availability and security by maximizing diversity of hosting locations, environments, networks, and systems.

The specific policy Daniel is referring to is section 5 of Sovrin Steward Technical Policies:

5. ​Node Selection Algorithm

  1. The selection of active Validator Nodes at any point in time MUST be governed by the Node Selection Algorithm as specified by the Sovrin Technical Governance Board (TGB).

  2. Non-technical inputs or policy decisions implemented by the Node Selection Algorithm MUST be approved by the Sovrin Board of Trustees.

  3. At any point in time, the Node Selection Algorithm MUST represent the TGB’s best efforts at designing an algorithm that applies the Core Principles of the Sovrin Governance Framework. Recognizing the inherent tension and tradeoffs between some of the Core Principles, the design of this algorithm should give priority to balancing: (a) the Decentralization by Design principles, in particular the principles of Diffuse Trust and High Availability; (b) the Security by Design principles, in particular the principles of System Diversity and Secure Failure.

  4. A human-readable, understandable, and explainable description of the current design of the algorithm as approved by the TGB MUST be published by the TGB in the official Sovrin Code Repository and made publicly visible via a web page on the Sovrin Foundation website.

I hope this helps—as you can see, the Sovrin Community takes Decentralization by Design very seriously.

1 Like


Unfortunately, I feel Drummond’s + Daniel’s replies give a very one-sided view of this topic, so here’s an additional perspective.

To answer your question: Out of the 25 nodes currently in the Sovrin ledger, 7 run on AWS, and another 4 run on other major cloud providers, i.e. in total 44%. Also, 15 nodes, i.e. 60%, either have U.S. Steward organizations or use U.S. based hosting.

So although the Governance Framework and Node Selection Algorithm are in theory great tools for governing a permissioned network like Sovrin, in practice they currently fail to achieve a good level of decentralization/diversity of the network.

My own experiments with the Node Selection Algorithm seemed to show that it is good at minimizing the impact of individual incidents such as earthquakes or operating system bugs, but it is not designed to optimize for political or other kinds of diversity of the network as a whole.

Another much discussed topic, which for transparency reasons should also be mentioned here, is that the Sovrin governance mechanisms described above have failed to prevent a “Steward-as-a-Service” offering by IBM, which in the eyes of some is an almost absurd contradiction to the basic premise of the “distributed ledger” concept itself.


Thanks Daniel, Drummond and Markus for helpful responses.


what I’d like to see

  1. Specific and finely grained guidelines for percentage of “as a service” stewards compared to the total figure.

  2. There should be decentralization in cloud providers, and applicants for the steward role should be strongly encouraged to run their own node, and guided towards firms other than IBM, but more specifically, any available cloud provider should be recommended other than the one already running the most nodes.

  3. There should be incentive systems designed to reward self-hosting.

Self-Hosting Stewards should get prominent positions on the website, and thanked for personally running a node.

not to say that stewards who’s node is run by a cloud provider should be penalized, but those w their own nodes should be clearly rewarded in some fashion that cloud provided stewards are not…

  1. There are really a whole host of related issues that should be addressed and well documented how they are treated. As this is a sore subject that many people will object to.

All of this is really concerning to me.

The fact of running a permissioned network is already 1 blow to the legitimacy of this project in the eyes of many in the blockchain community. I myself am still in the air on that topic.

When you add to that uncertainty about how cloud providers could quietly gather power in the network…and exactly what proportions are safe? (both between competing providers and vs the total number of stewards)

We need a threat model

I feel like the risks, where this system could potentially break down, are not well understood.

What are the potential scenarios where a government or some other powerful agent might want to influence or change a record? or perhaps deny service?

Although I’m sure many have wondered this same thing… (to begin with few are educated about public key cryptography, and the potential risks…) could we start by assuming that some powerful agents could control this system in a way it is designed to protect against? and work our way from there… what safeguards are in place to the inevitable attacks on decentralization.

The whitepapers I recall most fondly include a thick section on potential threats to the network, and how they are mitigated. this is a whole new kind of ledger, about public keys and associated documents… we understand the threats against a cryptocurrency fairly well, comparatively.

The question of threat models is directly related to what proportion of cloud providers running nodes I would feel comfortable with.

It should be done in house, first… because if there will be a token on this network, that will bring a lot of criticism… better to have the strongest criticism come within before all the coiners have their say.

I will have reservations about promoting the Sovrin network, until I can see there is some progress made on this subject (otherwise I would wonder if they already wield a disproportionate amount of power, even if that is simply relying too heavily on the cloud services to easily on-board member organizations and grow the network faster)

Why not lets have all the particulars around cloud providers much more well defined in the governance framework. There must be a detailed and specific system in place to guard against unbalance and over-concentration of power re: cloud providers.

and hopefully well documented so others who wonder can go and clearly see how the subject is handled.

for example… what about the keys… how much control do they have over the nodes they host?

do the stewards have full permissions? can IBM affect the operation of the node other than on\off?

1 Like