To get a more intuitive understanding of the SCP I'm trying to implement a generic version of it. For the implementation I'm using 3 references:

I'm now seeing some differences for the SHA-256 calculations in the nomination protocol. Stellar's source code and the paper define the hash function as Gi(m) = SHA-256(i || x_(i-1) || m) where x_(i-1) is the value of the previous slot. But the internet draft doesn't use the previous value Gi(m) = SHA-256(i || m).

I would like to stick to the internet draft, as it's the latest updated specification, but now I'm running into the problem that I would not be able to use this implementation for running a Stellar node. My priority calculations would differ from other nodes and this looks like trouble to me.

Will stellar-core's implementation change in the future to be again closer to the specification?

  • 3
    That's an awesome endeavor! Independent SCP implementation is a huge step towards better protocol security as it may help to uncover potential vulnerabilities of SDF implementation. Would be great to see a series of post containing your thoughts and implementation notes. – Orbit Lens Feb 28 '19 at 12:03

At this point, there are a bunch of small ways in which the internet draft is not wire compatible with stellar-core. The most important is that while multiple people have implemented SCP, there is only one implementation of the underlying overlay protocol, which has not been specified outside of the stellar-core implementation, and probably won't be, so that pretty much guarantees wire incompatibility. Given that, and because things may change in the RFC process anyway, the authors made the decision to make the internet draft as simple and ince as possible, where stellar-core and the draft can be reconciled down the line. A good example of this is the fact that the internet draft pulls the quorumSetHash out of the statement union, rather than having it in each separate structure.

In terms of your specific question, the whitepaper is written in a very generic way in which consensus is reached on abstract slots which are partially and not totally ordered, so the previous value was there just to ensure there is no possible ambiguity about the slot identity. By contrast, the internet draft just numbers slots with a uint64, which can never repeat, so the previous value isn't needed. Once you don't need the previous value, it's better not to include it, because including it gives any bad node that wins nomination potential control over who wins the next nomination.

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.