The Dusk Network And Blockchain Architecture
WEB3 Symposium, April 2018, Amsterdam, The Netherlands
The probability for obtaining k selections out of n extractions nk n−k
• bc is the tuple of the pre-block candidate hash H(block) and the transaction list txblock
• bdefault isthedefaultpre-blockpropagatedbytheappro- priate Provisioner’s committee
Algorithm 4 Verify and propagate pre-blocks
followsthebinomialdistributionPr(k;n,p)= k p (1−p)
where the sum of all probabilities Ínk=0 Pr(k;n,p) is naturally 1.
The set representing all possible probability values [0, 1) gets split
into adjacent intervals Ij = [Íj Pr(k;n,p),Íj+1 Pr(k;n,p)) for k=0 k=0
j ∈ 0,1,...,n. If hash/2len(hash) falls in the intervals Ij, then j is the priority of the node’s sortition and it is verifiable by knowing the VRF’s output hash (proven by π ) and the amount n. While in BA⋆ n is the information about a node’s entire balance, in SBA⋆ this amount is instead encrypted by the node and shared among the Verifiers using the NIVSS algorithm and kept verifiable solely by a threshold t of the n members of the Verifier Committee.
Differently from BA⋆, in SBA⋆ the probability of obtaining a total amount of Θ positive extractions is 1 only if all nodes partici- pate to the sortition with their whole balance. This is seldom the case and therefore the probability that no candidate gets selected to propose a block is greater than zero. To obviate to this eventual- ity and still produce a block in case a dishonest Block Generator gets caught, Provisioners run their own parallel Block Generator sortition as a fallback scenario for those cases. Also, to mitigate the potentially reduced probability to generate a successful sortition with multiple candidates, Θ is chosen to be substantially higher than the τ parameter of BA⋆.
3.6 Verification — Pre-Block Propagation
During the gossip procedure, each node relays solely the pre-block with the claimed highest priority (Provisioners will also gossip the default pre-block to the other Provisioners), while dropping all other pre-block proposals. In SBA⋆, protection from Sybil attacks is granted by the time-locked payment made by the Block Generator candidate which is not in clear. Therefore nodes and Provisioners other than Verifiers could only perform validation on the VRF result hash and the proposed pre-block. They do not engage in priority validation, which is entirely demanded to the Verifiers. This has the positive side-effect to perceivably decrease network latency during gossip operations.
Verifiers run the VerifyBlockProposerSortition in order to recon- struct the view-key and the time-locked transaction propagated by the Block Generator candidate and be able to validate the claimed priority. Depending on the outcome, they either sign and propagate the candidate’s pre-block or the default pre-block. This does not really require consensus since the propagated pre-block is a mere result of the validation operation, which gets further audited by the different Voter Committees. As such the probability for propagating mismatching pre-blocks is negligible. In the future we will explore the possibility to use Probabilistic Checkable Non-Interactive Zero Knowledge Proofs to propagate a very efficient proof of validation without revealing the candidate’s view-key any further than the Verifiers.
