3

According to the SCP document (draft-mazieres-dinrg-scp-04, https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/), the following paragraph describes how a node get its higher-layer software's input:

Nodes must not send an "SCPNominate" message until at least one of the "voted" or "accepted" fields is non-empty. When these fields are both empty, a node that has the highest priority among its neighbors in the current round (and hence should be echoing its own votes) adds the higher-layer software’s input value to its "voted" field. Nodes that do not have the highest priority wait to hear "SCPNominate" messages from the nodes whose nominations they are echoing.

However, I think it can be the case that the higher-layer software's input is empty for a node. This leads a questionable case: when the highest priority node has no higher-layer software's input while another node whose priority is not the highest has higher-layer software's input, should this node wait for the highest priority node even though it has its own higher-layer software's input?

Of course, it is not a big problem because the priority of the nodes changes as the round increases, but it seems to hinder the quick agreement.

0

The solution is actually quite simple : a different set of priorities will be picked after a timeout (lookup the "n" parameter) which allows the protocol to proceed in the event of dead nodes for example.

0

The protocol requires all nodes to be able to produce a value. That value could be empty--for instance, in the case of Stellar, it might contain no new transactions. But it would still contain a time stamp, a previous ledger hash, and a bucket list hash that must potentially be reorganized according to the bucked list structure.

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.