This website is no longer actively supported. Please see the Ripple Developer Center for up-to-date documentation and other resources.

Unique Node List

From Ripple Wiki
Jump to: navigation, search

The Unique Node List is a list maintained by each server operator of active nodes they believe are unique.

Ledger consistency

Each Node has their own Unique Node List (UNL). Unique here means nodes not run by the same group or individual. A node chooses to accept a particular Ledger based on how many of the unique nodes on its list have validated that ledger. A node validates a ledger simply by signing it with its private key. There is a method for adding nodes to your UNL in the client. The UNL is NOT just random nodes from the network. It is very easy to start millions of nodes so you can’t trust that two random nodes won’t be controlled by the same attacker. There must be some other method of building your UNL.

We imagine UNL's should have 100+ nodes on them.

This means that a node doesn't have to trust any node. In fact you can know that the nodes on your list are all liars and cheats. A node just has to trust that > 50% of the nodes on its list won’t collude.

You aren't required to maintain a connection to the nodes on your UNL. You don’t even need to know their IP or how to contact them. All you need to know is the public key for these nodes (which you can obtain from the domain). When you see validations for a ledger or proposed transaction sets, you just collect the ones that match entries on your UNL and ignore the others.

The UNL Database

The UNL database is hash of:

  • Key:
    • public key
  • Value:
    • last validation time
    • identity string (optional)
      • This specifies the domain that served this public key.

Declaring your node

Strategies for building a UNL

The ripple.com site provides a starter UNL. This starter UNL might be built as follows:

  1. Periodically, a list of top Internet sites is obtained.
  2. Once per month, sites are polled for node declarations.

Nodes from this list plus nodes selected by developers form the starter UNL. The starter UNL is published at: http://ripple.com/ripple.txt

A user might install a browser addon to look for node declarations by sites visited.

Trusted Core

UNL entries may have a trust score:

  • 10: source: came with the client
  • 5: source: by trusted referral
  • 2: source: random web browsing

We periodically poll our sources. If they mention a new node with a score over an amount, we add the node to our trusted core set.

Nodes Selection

Nodes participate in the Ripple network. Nodes can participate as validation nodes or monitoring nodes. A validation node participates in generating ledger consensus by declaring their view of the ledger during ledger reconciliation. Monitoring nodes typically serve back end application or client software.

Nodes should select a diverse list of nodes based on their legal jurisdiction (e.g. US, China), political regime (i.e. democratic, communist), political affiliation (party), business category (e.g. manufacturer, retail, finance, church, government). Choices should be made to reduce the probability of collusion. If everyone had 20% of the nodes on their list collude, forward progress of the network could stop.

Functionally complete software should allow their users to directly select the nodes to utilize for determining valid ledgers. In practice, this is likely too cumbersome. Initially selecting and maintaining a list is likely too bothersome for most people. To allow for Ripple network software to be secure by default, the following system is being developed.

  1. Validators will publish information about their organization which is cryptographically signed by their Ripple account.
    • Public signing key
    • Contact information
    • Region
    • Affiliations
    • Website URL
    • Uptime commitment
  2. Organizations (e.g. International Ripple Business Association, Ripple Federation, and Coinist.co) will:
    • Cryptographically attest if the validator meets their verification criteria.
    • Publish their attestations.
  3. Nodes will:
    • Subscribe to the attesting organizations to receive the latest attestations
    • Choose a subset of validators for their UNL based on the information about the validator.
    • Publish their UNL list of analysis.
  4. To prevent theoretically degenerate UNL lists creating a weak topology which could be easily attacked, auditing software will analysis the networks UNL and report on potential degenerate lists so that they can be corrected and theoretical weaknesses can empirically be shown to be impossible.

See also:

Code Specification

UniqueNodeList