Subject: Re: [Din] New SCP draft

From: Piers Powlesland <[email-masked]>
Date: Tue, 7 Aug 2018 17:03:50 +0100

Hi David,

Thank you for the clarification.

Piers
On Tue, Jun 19, 2018 at 6:33 PM David Mazieres expires 2018-09-17 PDT
<[email-masked]>
wrote:
>
> Piers Powlesland <[email-masked]> writes:
>
> > Ahh, I think I was misunderstanding the definition for quorum threshold.
> >
> > Please could you clarify if my current understanding is correct?
> >
> >> 1.  "v" itself has issued (digitally signed) the message,
> >
> > This part is self evident.
> >
> >> 2.  The number of nodes in "validators" who have signed "m" plus the
> >>     number "innerSets" that (recursively) meet this condition is at
> >>     least "k", and
> >
> > Here I am interpreting "(recursively)" to be applying to the innerSets, so for
> > each innerSet the number of validators plus innerSets that have signed "m"
> > must be at least this innerSet's threshold, and so on for this innerSet's
> > innerSets recursively.
>
> Correct.
>
> >> 3.  These three conditions apply (recursively) at some combination of
> >>    nodes sufficient for condition #2.
> >
> > Here I am interpreting "(recursively)" as applying to nodes. Meaning
> > that these 3 conditions apply at some set of nodes that are sufficient
> > for condition 2 to hold for this node, but also they apply at all the
> > nodes from this nodes validators and inner sets that have signed
> > message "m" and are contributing to this node meeting its threshold
> > and so on recursively.
>
> Correct.
>
> > If the above is correct, I am wondering what is the mechanism for a
> > node to learn about the messages signed by nodes outside of its slices
> > but inside it's quorum? Or put another way, how is a node able to
> > acquire all of the information needed for it to determine if it has
> > reached quorum threshold?
>
> In Stellar, the messages are broadcast through an overlay network.
> However, this is really out of scope of the consensus document, because
> end system multicast is an independent problem.  A dumb thing you can do
> is just have each node configure a number of peers and flood each
> message to every peer that has not yet received it.  That will cause
> redundant traffic, but at least get the job done.
>
> David