3

After checking that my stellar-core node was hanging with status Joining SCP, and seeing in the debug messages that the SCP was receiving all the envelopes normally, I realized that the problem was the quorum:

"16341117" : {
    "agree" : 3,
    "disagree" : null,
    "fail_at" : 0,
    "fail_with" : null,
    "hash" : "cb9b4d",
    "missing" : [ "ibm_brazil", "ibm_us", "fairx_us" ],
    "phase" : "CONFIRM",
    "value" : {
       "t" : 5,
       "v" : [
          "sdf_watcher1",
          "sdf_watcher2",
          "sdf_watcher3",
          "ibm_brazil",
          "ibm_us",
          "fairx_us"
       ]
    }
 }

These nodes (ibm_brazil, ibm_us, and fairx_us) were online on the dashboard, my node was connected to them and a few days ago they were working normally.

After changing the quorum set to only the 3 SDF nodes, it worked. But what is the proper way to configure the quorum sets so that something like this doesn't happen? Is there a way to test if a specific node is validating?

2

What you probably saw is the result of DDoS countermeasures in the Stellar network (we’re working to make this less aggressive while preserving safety): the way to test that a validator is working (or simply to use it) is done by adding that validator’s ip & port to your “preferred peers” setting (or at a minimum to a validator that you know is connected to your target validator).

In your example: the IBM validators are validating but you didn’t have at the time a good path to them, all you’d need to add all IBM validator keys is to be connected to any one of them (as they are likely connected to each other).

0

I would recommend taking FairX and IBM off your validator list as they don't have live users on the public network and they don't run operational businesses from these validators yet. Because of this, they could be down and they don't realize it.

I'd recommend the Stronghold and Stellarport validator list as they are live and can catch validator issues more quickly as they have the user base to detect if a transaction is slow.

https://github.com/stellar/docs/blob/master/validators.md

  • Thanks for the response and the link. Did not know about this document. – matheusb.comp Feb 20 '18 at 16:50
  • This is factually inaccurate, on a number of fronts. 1: The IBM nodes are in fact running production load. And, they were confirmed as in-sync and NOT down this weekend thankyouverymuch. 2: The FairX nodes are used actively, but the functionality exposed by FairX is not available to the public yet. – Michael Dowling Feb 20 '18 at 23:03
  • Yeah I agree this answer is misleading: it doesn’t answer the original question and removing validators doesn’t really help (we need more decentralization not less). Validation speed by the network is not coupled to validators like that (Tammy: you confused Horizon being slow because of ingestion and IBM/fairX are not running one afaik) – MonsieurNicolas Feb 21 '18 at 2:43
  • @MonsieurNicolas correct, we're not running a public horizon server at IBM. – Michael Dowling Feb 23 '18 at 4:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.