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:


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.



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.