Resource: White Paper

3.1 Sperax blockchain

S⁰ = { (P₁, a₁), · · ·, (P_j, a_j) }

SIG_pki (P_i, P_i′ , a^′)

TX^r: S^r -> S^r+1.

B^r = { r,t_r,TX^r,H(B^r-1),P^r,CERT^r }

3.2 Sperax random beacon protocol

3.3 Reliable broadcast and BFT protocols

• 
  Type I asynchronous network: ∆ < ∞ is unknown. That is, there exists a ∆ but the participants do not know the exact value of ∆.
• 
  Type II asynchronous network: ∆ < ∞ holds eventually. That is, the participant knows the value of ∆. But this ∆ only holds after an unknown time slot T = T_i. Such a time T is called the Global Stabilization Time (GST).

For Type I asynchronous networks, the protocol designer supplies the consensus protocol first, then the adversary chooses her ∆. For Type II asynchronous networks, the adversary picks the ∆ and the protocol designer (knowing ∆) supplies the consensus protocol, then the adversary chooses the GST. The definition of partial synchronous networks in [7, 38, 32] is the second type of partial synchronous networks. That is, the value of ∆ is known but the value of GST is unknown. In such kind of networks, the adversary can selectively delay, drop, or re-order any messages sent by honest participants before an unknown time GST. But the network will become synchronous after GST.

For the Type I network model, Denial of Service (DoS) attack is not allowed since message could be lost with DoS attacks. We think that it is more natural to use Type II asynchronous networks for distributed BFT protocol design and analysis. Sperax adopts the Type II network model unless specified otherwise.

The difference between point-to-point communication channels and broadcast communication channels has been extensively studied in the literature. A reliable broadcast channel requires that the following two properties be satisfied.

1. Correctness: If an honest participant broadcasts a message m, then every honest participant accepts m.

2. Unforgeability: If an honest participant does not broadcast a message m, then no honest participant accepts m.

Other broadcast primitives have also been proposed in the literature (see, e.g., Mullender [27]):

1. FIFO broadcast: a reliable broadcast guaranteeing that messages broadcast by the same honest sender are deliv- ered in the order they were broadcast.

2. Causal broadcast: a reliable broadcast guaranteeing that messages are delivered according to the causal prece- dence relationship. That is, if a message m depends on m′ then m′ is delivered before m.

3. Atomic broadcast: a reliable broadcast guaranteeing a total ordering of all messages. Unlike causal broad- casts, atomic broadcast requires all participants to receive all messages in the same order. However, the atomic broadcast does not enforce a causal order.

4. FIFO atomic broadcast: FIFO broadcast a total ordering of all messages.

5. Causal atomic broadcast: casual broadcast a total ordering of all messages.

It has been shown in Chandra and Toueg [8] that atomic broadcast is equivalent to Byzantine consensus. Other related group broadcast primitives for communication for supporting distributed computation in the presence of non-Byzantine crash failures may be found in Birman and Joseph [4] and other literatures.

For complete networks, reliable broadcast protocols have been proposed in Bracha [5]. For a given integer k, a network is called k-connected if there exist k-node disjoint paths between any two nodes within the network. In non-complete networks, it is well known that (2t + 1)-connectivity is necessary for reliable communication against t Byzantine faults (see, e.g., Wang and Desmedt [35] and Desmedt-Wang-Burmester [13]). On the other hand, for broadcast communication channels, Wang and Desmedt [34] showed that there exists an efficient protocol to achieve probabilistically reliable and perfectly private communication against t Byzantine faults when the underlying commu- nication network is (t + 1)-connected. The crucial point to achieve these results is that: in a point-to-point channel, a malicious participant P₁ can send a message m₁ to participant P₂ and send a different message m₂ to participant P₃ though, in a broadcast channel, the malicious participant P₁ has to send the same message m to multiple partici- pants including P₂ and P₃. If a malicious P₁ sends different messages to different participants in a reliable broadcast channel, it will be observed by all receivers.

Though broadcast channels at physical layers are commonly used in local area networks, it is not trivial to design reliable broadcast channels over the Internet infrastructure since the Internet connectivity is not a complete graph and some direct communication paths between participants are missing (see, e.g., [25, 35]). Quite a few broadcast primitives have been proposed in the literature using message relays (see, e.g., Srikanth and Toueg [31], Bracha [5], Dwork, Lynch, and Stockmeyer [15], and LibraBFT [32]). In the message relay based broadcast protocol, if an honest participant accepts a message signed by another participant, it relays the signed message to other participants. However, in order for these message relay based broadcast protocol to be reliable, it requires that the network graph is complete which is not true for the Internet environments.

A broadcast channel is unreliable if a malicious participant could broadcast a message m1 to a proper subset of the participants but not to other participants. That is, some participants will receive the message m1 while other participants will receive a different message m2 or receive nothing at all. In next sections, we show that several BFT protocols are insecure due to the lack of reliable broadcast channels before GST (messages before GST could get lost or re-ordered by the definition). Thus it is important to design BFT protocols that could tolerate unreliable broadcast channels before GST.

Sperax BFT protocol. Sperax adopts a Type II partial synchronous network model and adopts the BDLS BFT protocol discussed and analyzed in Wang [37] as the finality gadget for the Sperax block chain. For details of the BDLS BFT protocol and analysis, it is referred to [37].

3.4 Mathematically Provable Secure BFT Consensus Protocol: SperaxBFT

As we have mentioned in Section 3.2, if a user P_i wants to participant in the leader and verifier committee selection process for the block B^r generation, then P_i needs to deposit 10000_ai SPA tokens in round r − κ^' . Note that a user may create several virtual participants for the governance process of Sperax blockchain and each virtual participant deposits 10000 SPA tokens. Alternatively, a user may commit 10000_ai SPA tokens in one package to improve the performance. Let Ω_r be the total amount of SPA tokens deposited for the round r. For each round r, the protocol proceeds from the stage s = 0 until a block B_r is finalized. If stage s fails to finalizes the block Br, it moves to stage s+1.

where γ^r_i is the random string that user P_i has committed with staking (see Section 3.2), and Wr is defined as follows:

1. W₀ = H(0x03243F6A8885A308D313198A2E037073),

2. W_j = H(P^j−1,W_j−1) for 0 < j ≤ r, where P⁰ = ∅ and P^j is the participant who generated the block B^j−1,

4 Sperax Tech Roadmap

4.1 Phase 1: Prototype

Feasibility Research

1. Focus on SperaxBFT consensus mechanism and prove its validity;

2. Sperax Basic Model Prepare;

3. Privacy transaction technique research;

4. Put up with privacy transaction Proposal/Design in Sperax.

Software design

1. Complete detailed design of software;

2. Focus on the designing of function, performance, input and output, algorithms, logic, interface, storage distribution.

Software Development & Test

1. SperaxBFT consensus algorithm verified in software environment and prompted;

2. Privacy transaction performance tested in software environment and optimization;

3. Sperax blockchain runs in complete software environment and achieves all functions which are mentioned in White Paper;

4. Provide Sperax blockchain traceability;

4.2 Phase 2: Full version

Production & Test

1. Sperax testnet Wallet release;

2. Sperax testnet online.

Release

1. Release Sperax (Alpha) ;

2. Release SperaxScan (SperaxScan support entire Sperax blockchain block include basic transaction and smart contract transaction);

3. Release Sperax (Belta) ;

4. Sperax MainNet Wallet release;

5. Sperax main-net online (v1.0).

Future plan

1. Improve SperaxVM to achieve higher performance and security.