Skip to content

Latest commit

 

History

History
143 lines (106 loc) · 4.89 KB

sep-0020.md

File metadata and controls

143 lines (106 loc) · 4.89 KB
Raw
SEP: 0020
Title: Self-verification of validator nodes
Author: Johan Stén <[email protected]>
Track: Standard
Status: Active
Created: 2018-05-06
Discussion: https://github.com/stellar/stellar-protocol/issues/111

Simple Summary

Using Stellar accounts to link validator nodes to the entities operating them.

Abstract

SCP depends on knowing the identies of the nodes you add in your quorum slice and thus choose to listen to. When discovering or verifying validators in the Stellar network it is useful to have a clear link between the nodes and their identity in the wider internet.

So who do you listen to? 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 a baseline level of verification of validator nodes.

Motivation

There is currently no standard way for publishing node metadata. We need better scalability, better discoverability, more decentralization, better information quality.

Specification

Linking

  • Create 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 stellar.toml file

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

Stellar.toml metadata

SEP-0001 specificies how to add validator information to your stellar.toml. The basic idea: for each validator you run, add a [[VALIDATORS]] table, and provide information about that validator in the table.

At a minimum, you need to complete the PUBLIC_KEY field, though completing all fields improves discoverability. If your node publishes an archive, add its location in the HISTORY field so that other validators know where to find it.

Example code for linking

const userKeys = StellarSdk.Keypair.fromSecret(...);

// validator node NODE_SEED
const nodeKeys = StellarSdk.Keypair.fromSecret(...);
const nodeId = nodeKeys.publicKey();

// the
const homeDomain = '...';

const account = await server.loadAccount(userKeys.publicKey());
const tx = new StellarSdk.TransactionBuilder(account,  {fee: 100})
    .addOperation(StellarSdk.Operation.createAccount({
        destination: nodeId,
        startingBalance: '1'
    }))
    .addOperation(StellarSdk.Operation.setOptions({
        source: nodeId,
        homeDomain: homeDomain
    }))
    .setTimeout(0)
    .build();

tx.sign(userKeys);
tx.sign(nodeKeys);

const result = await server.submitTransaction(tx);

Example look-up

MacBook-Pro:~ Johan$ curl https://horizon.stellar.org/accounts/GCGB2S2KGYARPVIA37HYZXVRM2YZUEXA6S33ZU5BUDC6THSB62LZSTYH
{
  ...
  "id": "GCGB2S2KGYARPVIA37HYZXVRM2YZUEXA6S33ZU5BUDC6THSB62LZSTYH",
  ...
  "home_domain": "www.stellar.org",
  ...
}

MacBook-Pro:~ Johan$ curl https://www.stellar.org/.well-known/stellar.toml
...
[[VALIDATORS]]
ALIAS="sdf1"
DISPLAY_NAME="SDF 1"
HOST="core-live-a.stellar.org:11625"
PUBLIC_KEY="GCGB2S2KGYARPVIA37HYZXVRM2YZUEXA6S33ZU5BUDC6THSB62LZSTYH"
HISTORY="http://history.stellar.org/prd/core-live/core_live_001/"

[[VALIDATORS]]
ALIAS="sdf2"
DISPLAY_NAME="SDF 2"
HOST="core-live-b.stellar.org:11625"
PUBLIC_KEY="GCM6QMP3DLRPTAZW2UZPCPX2LF3SXWXKPMP3GKFZBDSF3QZGV2G5QSTK"
HISTORY="http://history.stellar.org/prd/core-live/core_live_002/"

[[VALIDATORS]]
ALIAS="sdf3"
DISPLAY_NAME="SDF 3"
HOST="core-live-c.stellar.org:11625"
PUBLIC_KEY="GABMKJM6I25XI4K7U6XWMULOUQIQ27BCTMLS6BYYSOWKTBUXVRJSXHYQ"
HISTORY="http://history.stellar.org/prd/core-live/core_live_003/"
...

Design Rationale

Federation is well-established as a building block for protocols built on Stellar.

Validator nodes have keypairs and are already using public keys as their identity, so it's not much of a stretch to add accounts into the mix, in order to start using reverse federation as a means of looking up metadata associated with a specific validator node.

Security Concerns

With a validator node account linked to a homedomain stellar.toml file like suggested, we're really relying on the integrity of the stellar.toml file and the server it resides on, making sure it only has write access by authorized users.

Additional security measures that could be taken include signing the stellar.toml file with the validator key(s), and serving in a file next to the stellar.toml file.

Another thing might be to add DKIF2-style protection, and sign the stellar.toml file with a private key unrelated to the validator node(s), and publish the public key in the DNS response.

These are most likely the topic of a SEP by themselves.

Links

1) https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md
2) stellar#80