Proposal: Self-verification of validator nodes

[johansten]

SEP: 000x
Title: Self-verification of validator nodes
Author: Johan Stén johan@futuretense.io
Status: Draft
Created: 2018-05-06

Simple Summary

Use Stellar accounts to link validator nodes to the entities that operate them.

Abstract

Contrary to Bitcoin, which was designed to remove the need to trust third parties, trust is fundamental to FBA/SCP -- node operators explicitly have to select sets of nodes which they trust.

So who do you trust? And how do you know what nodes belong to them?

Just as Stellar uses federation for anchors, and federated address lookups, we suggest using the same mechanics for baseline verification of validator nodes.

Motivation

The current protocol for publishing node metadata is highly centralized, relying on SDF as a central gatekeeper as the maintainers of the https://github.com/stellar/docs/blob/master/validators.md file.

We need better scalability, better discoverability, more decentralization, better information (e.g., my node is marked as offline(?) in that file)

There's also the matter of preferential treatment. https://dashboard.stellar.org currently lists 28 validator nodes. Previously, these were marked "verified", attaching status to them.

Specification

• register an account for the validator node you operate
• set the account homedomain to your website
• create a stellar.toml file in /.well-known on the website server
• add your validator node to the file

This creates a two-way link between the node and the website of the operating entity, uniquely identifying it.

Test case

MacBook-Pro:~ Johan$ curl -X GET https://horizon.stellar.org/accounts/GBFZFQRGOPQC5OEAWO76NOY6LBRLUNH4I5QYPUYAK53QSQWVTQ2D4FT5
{
  ...
  "id": "GBFZFQRGOPQC5OEAWO76NOY6LBRLUNH4I5QYPUYAK53QSQWVTQ2D4FT5",
  ...
  "home_domain": "futuretense.io",
  ...
}

MacBook-Pro:~ Johan$ curl -X GET https://futuretense.io/.well-known/stellar.toml
OUR_VALIDATORS=[
    "GBFZFQRGOPQC5OEAWO76NOY6LBRLUNH4I5QYPUYAK53QSQWVTQ2D4FT5"
]

[bartekn]

Isn't it already a part of SEP-0001:

OUR_VALIDATORS | list of G...strings | A list of validator public keys that are declared to be used by this domain for validating ledgers. They are authorized signers for the domain. Names defined in NODE_NAMES can be used as well, prefixed with $.

[johansten]

Yes, OUR_VALIDATORS is a part of SEP-0001 already.

The idea was to link together existing elements, to give reverse lookups, just like with federated addresses. Accounts + stellar.toml's

If you take a look at what e.g. https://stellarbeat.io/nodes creates by crawling nodes, the mapping is done from entity to node ID, and not the other way around, and most nodes don't have any name because they're never listed in validators.md.

Instead of having a centralized repository, we can use the ledger.

[jedmccaleb]

yes this is a good idea

[MonsieurNicolas]

Forgot to comment on this. I like this idea.

Only a couple of things to consider to keep the conversation going:

• I don't know if we want to require federation for nodes
• do we want to take this further and add "peer" and "archive" information as data fields (basically have all core related data stored in the ledger)?

It seems to me that relying on domain is much better as it links back validators to the "real world" - but it may be too strong of a requirement for basic validators.

[chriserice]

I like the idea of discoverability especially in my peer list- I often wonder who is behind the IP address or node ID. At the very least, I ensure that my IP addresses have PTR records so that someone can discover the hostname behind the IP address.

I think requiring federation adds complexity and additional cost to individual validators who just want to contribute compute time for validation (and maybe learn a thing or two on the inner working of SCP). At the very least, I think everyone should have a PTR record--for those that want to be discovered. It's a free service on Google Cloud and Digital Ocean (couldn't it figure out on AWS). I support a domain/dns-txt and/or hybrid approach. ☺️

[JeremyRubin]

I'm not sure I'm fond of serving the data dynamically -- I'd much rather have our spec for this require a commitment in the memo field of the account which is a hash commitment to stellar.toml or something.

I can't think of a case where we'd want a site to serve two different clients two different validators.

I'd also potentially like to specify that stellar.toml should be self-signed with the set of all validators claimed under OUR_VALIDATORS.

[johansten]

@JeremyRubin

How about using TXT records for the stellar.toml signatures? A memo is attached to a specific transaction, and there are no guarantees that a horizon node you're connected to has it in its history.

Private key, website access, DNS access. That should take some work to interfere with.

[JeremyRubin]

By memo I mean Data entry

[tinco]

Do you mean that a TXT record has a signature for the contents of the stellar.toml? If so I think putting it in the stellar.toml is a better idea, since we don't mix technologies then. In any case, the OUR_VALIDATORS field is already in the specs, so to enhance its integrity would be a separate proposal right?

@MonsieurNicolas raises a valid concern in his first point. If we make this a validator requirement, that would imply it's a part of SCP, and that would imply this is all very critical and that it should enforced as well. But that's a bootstrap problem, because we get the account information from the ledger, and we get the ledger from the validators.

We can't require this of validators, we just want to encourage validators to do this, so their clients can make better informed decisions. And since it's just an optional layer on top, it makes sense to use federation for this.

If it's less of a modification to the protocol and more of a good practice, should this be a SEP? How do we establish the good practice, do we just start adding the steps to all the guides so people start doing it?

[johansten]

@tinco

Definitely an enhancement layer, nothing we can or should require.
The goal is a decentralized discovery mechanism, to get away from
https://github.com/stellar/docs/blob/master/validators.md as a central repository.

Additional fields could be added to the stellar.toml file, just as in SEP-0001, so we have more information about the organization behind a node (name/contact person/etc).

[JeremyRubin]

Let's spec a new file, stellar.toml.sig which contains signatures for high, medium, or low threshold keys (keys, not preauth or whatever else) on the account.

There is a benefit to putting it in the memo field though -- it's difficult to serve multiple versions to different clients.

Signature bearing fields cannot be added to the toml easily, for the obvious reasons.

[jedmccaleb]

@johansten Can you make a PR for this SEP?

[smdwireless]

What happens when you have more than one node? Which one should you attach to your toml?
Our authorized key as listed in the toml is different from the keys used for any of our validators and the validator keypairs are kept inactive as far as transactions are concerned... it's just less complicated to manage fewer accounts.

I like the idea but the implementation could be as simple having the path to the toml as the memo txt in a specific transaction sent to the validator's address from the authorizing node and with the toml file already listing OUR_VALIDATORS=[ ], it's easy confirmation.

So I'm in agreement with the idea @johansten and with your suggestion @JeremyRubin just if possible let's try to use the existing config files first rather than introducing new ones to the ecosystem

[tinco]

I thought with multiple nodes, you'd have multiple accounts, all pointing to the same toml file, right?

[smdwireless]

@tinco Yes, this is what I'm referring to. So all nodes would have account keypairs which would be listed in the single toml file under OUR_VALIDATORS and all that would be needed is for those accounts to each carry a single transaction from the authorizing account keypair (shown in the toml) which carries the memo txt with the toml's path.

It's just an idea that would solve the problem without the need to introduce more files or additional complexity. The only problem with this method is that it would require that every node operator who wants to be validated also uses the federation protocol and so has a toml in the first place.

So with this you could do the equivalent of a reverse DNS lookup from the node by simply looking for that transaction in its account history and from the toml file you can see all nodes that are related.

It also means you would have a direct link between a registered domain name and the validating nodes, adding more useful identity data to the id graph of that organization.

[MonsieurNicolas]

Cool.

As we're only using the same distribution mechanism than federation (stellar.toml file under /.well-known), I think that what we should make sure as part of this SEP is to specify:

• which properties are required to verify validators
• which properties are optional in the context of validator verification (name?)
• how clients can trust those properties (signed, with which key? or is there a hash of the content in the ledger?)
• a stellar.toml file that only contains those fields is well formed

We should make sure that the format is extensible so that in the future it's easy to add new properties for validators.

For example it should be easy for people to add "archive" information for full validators (whatever needs to be put in people's configurations if they want to download from that archive).

[theaeolianmachine]

Hey @johansten — given mostly positive sentiment, I'd like to get this moving forward. Could you take a look at the readme in the ecosystem folder, and submit a draft PR? Let me know if you have any questions. Apologies for the lack of movement on our side.

[johansten]

@theaeolianmachine I lost momentum too when the discussion here, and other SEPs, got into how we sign for things. I'll make a draft.

[theaeolianmachine]

@johansten I merged in #289 as SEP-0020; thanks so much for getting to this. I'll keep this thread open if you want to get any more discussion here, and will plan to close it when it moves to a more final post-draft state.

[johansten]

@theaeolianmachine Np!

One of the things I thought about, but think needs to go into SEP-0001, is an array of display names of nodes. OUR_VALIDATORS is a list of node IDs, NODE_NAMES is a list of "short names" for use in a stellar-core.cfg, but there's really nothing where you can get a full, "pretty" name suitable for display.

[MonsieurNicolas]

Very good suggestion on names @johansten : this might be the occasion to move to something a little more extensible going forward on the validator front and stop the proliferation of arrays.

Right now we have NODE_NAMES, OUR_VALIDATORS, ASSET_VALIDATOR, KNOWN_PEERS, HISTORY that are expressed independently.

This is broken, it should be the other way around: for each validator, have properties attached to it.

As toml doesn't support (arrays of) complex types, I think we need to do something similar to how we configure archives in the core configuration:

# validator1 is the "shortname"
[validator.validator1]
NODE_NAME="Validator 1"
NODE_PUBLIC_KEY="GSDSDS..."
PEER="v1.mydomain:11625"
HISTORY="http://www.mydomain/node1/"
VALIDATED_ASSETS=true

[validator.validator2]
NODE_NAME="Validator 2"
NODE_PUBLIC_KEY="GADSDS..."
PEER="v2.mydomain:11625"
HISTORY="http://www.mydomain/node2/"
VALIDATED_ASSETS=true

With this in place it becomes trivial to add new properties to validators (if we want to), and makes it easier to write tools (like automated configuration generation).

Not sure what to do with the VALIDATORS field (quorum set configuration), probably remove it as it's non authoritative and the domain validators are likely to not have the same configuration. Horizon should expose that information retrieved from the network.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed, or a comment is posted.