The Stellar Core network depends on validators to ensure liveness and reliability. Operating on the Stellar Core network means putting trust in a set of validators, also known as a quorum set. Any organization or individual can run a validator, thus leveraging their reputation and computing resources to reinforce the network.
As the operator of a validator, as the operator of an interface to the Stellar Core network (such as Horizon) or simply as an entity doing business on Stellar it is important to be aware of which validators are trusted with ensuring the health of the network.
As an introduction to organizations on the Stellar Core network, below is a list and chart of the most trusted organizations on the network. Select one to get more information about that organization.
This section should enable the visitor to pick a good set of validators.
It should also help the visitor with selecting some preferred peers to strengthen its chances of having a good network.
This should answer a set of general questions:
This should answer some questions about a specific entity.
Quorum Explorer currently employs a crude estimate of the amount of trust the network in general puts into a specific validator or organization. This "trust index" number is just the amount of nodes that have this particular validator in their quorumset, divided by the total amount of validators in quorumsets. This number is not reliable for any decision, as it can easily be gamed, it's just used to roughly order nodes.
You want a quorum set that consists of as many validators that you trust as possible, and also as diverse as possible, with a treshold so that a conspiracy would have to span as much validators as possible, while still allowing for a maximum number of unreachable/unresponsive validators.
This actually means that you want your quorumset to be the minimum amount of validators that you would still trust to not have a conspiracy greater than the treshold.
The next question is which peers do we prefer. We want a group of peers that are reliably available, and also that broadcast quorums that contain the validators we are interested in.
We receive externalize messages from our peers whenever they advance their ledgers. Associated with the externalize messages are quorumset hashes. We use this quorumset hash to ask a peer which members that quorumset has, and who the owner is of that quorumset.
If we receive a statement from a peer saying that it externalizes a message by virtue a certain quorumset, how do we know it is correct? Is this pledges? are they signed? The quorumset is signed by the message sender. This means we know that whoever sent the quorumset believes that particular quorumslice voted for the value it accepted.
The API can be found at https://api.quorumexplorer.com/v1.
The endpoints in this API simply return JSON documents that are continuously refreshed by runs of a crawler.
This endpoint returns an object with basic information on all nodes that are part of the Stellar Core network. For convenience there is also a list of organizations, a total_trust amount which is used to relativize trust amounts and a last_crawl_time which is the time the crawler generated this data.
The root object is structured as follows:
{
organizations: { id -> basic_organization },
nodes: { id -> basic_node },
total_trust: float,
last_crawl_time: integer
}
View an example of the response to this endpoint here.
This field is a map of node id to node. Node id is also known as the node public key and can be used to uniquely identify a node. basic_info is a map of node properties that leaves out some more data intensive fields.
{
ledger_version: integer,
network_id: string,
overlay_min_version: integer,
overlay_version: integer,
peer_id: string,
version_string: string,
accepts_connections: boolean,
error: string | null,
address string,
known_info: known_info,
quorum: quorum,
account_info: account_info | null,
organization_name: string,
trust_table: trust_table,
trusting_nodes: [string],
trust_value: float,
organization_id: string,
last_seen: integer,
id: string,
quorum_history: [quorum]
accepts_connections_history: basic_accepts_connections_history,
seen_history: basic_seen_history
}
This field is a map of organization id to node. Organization id's are a hash of the organization name, in the same way as node id's are calculated by Stellar. basic_organization is a map that leaves out some data intensive fields.
{
id: string,
name: string,
validators: [string],
last_seen: integer
}