2 Challenges of existing PoS-based blockchains
2.1 Challenge 1: Existing BFT protocols are not sufficient to guarantee blockchain security in open networks
2.2 Challenge 2: achieving unpredictability of next-block-proposer identity
3 Sperax’s Innovative layer-1 design
3.1 Sperax blockchain
3.2 Sperax random beacon protocol
3.3 Reliable broadcast and BFT protocols
3.4 Mathematically Provable Secure BFT Consensus Protocol: SperaxBFT
3.5 Sperax blockchain header
3.6 Security Analysis
3.6.1 Methodology
3.6.2 Calculation on the Worst Case
3.6.3 Analysis
3.7 Democratic and Decentralized
3.8 Virtual Machine and Various Applications
4 Sperax Tech Roadmap
4.1 Phase 1: Prototype
4.2 Phase 2: Full version
A Sperax Enabling Technology
A.1 Privacy Protection Technology
A.2 Smart Contract
Sperax Team
August 3, 2020
S^{0} = { (P_{1}, a_{1}), · · ·, (P_{j}, a_{j}) }
where P_{1}, P_{2}, · · · , P_{j} are a list of initial users and a_{1}, · · · , a_{j} are their respective initial amounts of money units. We assume that each user P_{i} is identified by its public key pk_{i} . That is, for the users P_{1} , P_{1} , · · · , P_{j} , their corresponding public keys are pk_{1} , · · · , pk_{j} . In practical implementations, a user P_{i} may be identified by the hash of her public key. That is, we may use P_{i} = H(pk_{i}) in implementations. A valid transaction from a user P_{i} to a user P_{i′} is in the format ofSIG_{pki} (P_{i}, P_{i′} , a^{′})
where the user P_{i} currently has a ≥ a′ money units, P_{i′} is an existing or a newly created user, and pk_{i} is the public key of user P_{i}. The impact of this transaction is that the amount of money units for user P_{i} is decreased by a′ and the ′ amount of money units for user P_{i′} is increased by a^{'} .L = TX^{0},TX^{1},TX^{2},· · ·,
S^{r} = { (P_{1},a^{(r)}1),(P_{2},a^{(r)}2),(P_{3},a^{(r)}3) }
TX^{r}: S^{r} -> S^{r+1}.
B^{r} = { r,t_{r},TX^{r},H(B^{r-1}),P^{r},CERT^{r} }
SIG_{pki}(P_{i},P_{∞},m_{i},γ_{i}r+κ′,r+κ′)
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_{1} can send a message m_{1} to participant P_{2} and send a different message m_{2} to participant P_{3} though, in a broadcast channel, the malicious participant P_{1} has to send the same message m to multiple partici- pants including P_{2} and P_{3}. If a malicious P_{1} 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].
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_{0} = H(0x03243F6A8885A308D313198A2E037073),
2. W_{j} = H(P^{j−1},W_{j−1}) for 0 < j ≤ r, where P^{0} = ∅ and P^{j} is the participant who generated the block B^{j−1},
for all potential leaders P_{i}.
Remark: It should be noted that if a user stakes 10000a_{i} SPA tokens and uses (1) to calculate the probability for him to serve as the block B^{r} proposer, he may has small disadvantages since he only has one chance to use the equation (2). If this is a concern, for a user who staked 10000a_{i} SPA tokens, he may be considered as a_{i} virtual users for the calculation of the probability in the equation (1).
At the start of stage s of round r, each potential leader P_{i} of this stage collects the maximal transaction set T X_{i}^{r} of round r that have been propagated to her. Then she computes the candidate block B_{i}^{r} without the certificate CERT^{r}
The user P_{i} then propagates to the entire network the message m_{i}^{r,2s} = (B_{i}^{r} , μ_{i}^{r} ) together with the Merkle hash tree r path corresponding the value μ_{i}^{r} .
Since there could be several potential leaders during round r, each user could receive several candidate block messages m_{j}^{r,2s }from the preceding paragraph. Thus we need to select a verifier committee to determine the actual leader P_{lr} and finalize B^{r} as the corresponding block B_{lr}^{r} proposed by this leader. The verifier committee is selected as follows. A user P_{i} belongs to the verifier committee V ^{r} for τ_{i} > 0 times (that is, P_{i}’s signature will be counted as τ_{i} signatures) where
whereγ_{i} ^{r′} is the committed string by userP _{i} in Section3.2,W_{r} is recursively defined in the same way as in the leader selection process, and p^{′} is a pre-determined probability. For example, one may choose p^{′} = 60/T_{r} where T_{r} is the total number of unit users who paid staking deposit for the round r (that is, T_{r} = Ω_{r}/10000). It should be noted that in the formula(3),the value (^{ai}_{j}) (p^{'}>)^{j} (1-p^{'}>)^{wi-j} is the probability that the user P_{i} is selected for exact j-times if each individual sub-user (P_{i}, j^{′}) is selected with the probability p′/Ω_{r} (this approach is similar to the approach used in Giladet al [19].
Each verifier P_{i} in V^{r} determines that the user P_{l} is the round leader if the conditions in both the formula (1) and the formula (2) are satisfied for all potential leader P_{j} contained in the messages m_{j}^{r,2s} that she has received. After verifying the validity of the message m_{j}^{r,2s} = (B_{l}^{r},μ_{l}^{r}), the verifier P_{i} authenticates and propagates her candidate lll block B_{l}^{r} to the entire network using the signature SIG_{pki} (τ_{i} , H (B_{l}^{r} )) where τ_{i} is the number of time that the user P_{i} should serve in the verifier committee. Together with the message, the user P_{i} should also propagates the proof that she is the qualified committee member. This can be done by including his committed value μ_{i}^{r} together with the Merkle hash tree path corresponding the value μ_{i}^{r} .
Next each user P_{i} checks whether she has received more than 2v_{r}/3 signatures for some candidate block B^{r} where v_{r} is the total number of committee members of V^{r} (note that a committee member may be counted multiple times). If there exist more than 2v_{r}/3 signatures for a proposed block B^{r}, then P_{i} marks B^{r} as the final round r block. If no more than 2v_{r}/3 signatures for a proposed block is received, then P_{i} marks the block Br as an empty block. It is straightforward to see that if the majority moneys are honest, then all the honest nodes will reach an agreement on the block B^{r} at the end of round r.
Generally a more involved Byzantine Agreement protocol could be used to offer rewards for those verifier com- mittee members who have served. However, it may not be worthwhile to add this extra layer of operations to motivate verifier committee members. One may assume these committee members would like to work voluntarily to keep the system in function.
Figure 2: Sperax Blockchain Header
Factors. In a nutshell, the probability for malicious nodes to successfully make the first block when attempting to make a fork, P robr , is determined by six factors:
1. Ω_{r}, the total amount of money at round r (including both active and offline money)
2. α_{r}, the ratio of the amount of money controlled by malicious nodes to the total amount of money at round r (in short, bad money over total money)
3. ρ_{r}, the ratio of the amount of money controlled by active nodes to the total amount of money at round r (ρ_{r} is also called the participation rate at round r. In short, it is active money over total money)
4. N_{r}, the numerator in the expression of p (e.g. 20 in p = 20 / T_{r} in section 3)
5. N′_{r} , the numerator in the expression of p′ (e.g. 1000 in p′ = 1000 / T_{r} in section 3)
6. V_{min}, the absolute minimum amount of votes a block needs in order to be valid which is not the minimum 2/3 requirement
Formula. To calculate Prob_{r}, we must first understand the two essential steps in which malicious nodes have to succeed if they ever want to successfully make their first block. The first step is to have at least one malicious node elected as a potential leader so that there is one node that can propose a candidate block for later verification. We 1 denote the probability for malicious nodes to succeed in this step as P_{ro}b_{r}^{1} . The second step in which malicious nodes have to succeed is to gather at least V_{min} votes among themselves during the verifiers election process so that they can have enough votes required to validify the candidate block proposed by one of them. We denote the probability for them to succeed in this step as P_{ro}b_{r}^{2} . Since these two steps are probabilistically independent, the ultimate probability for malicious nodes to successfully make the first block in forming a fork, P_{ro}b_{r}, is simply the multiplication of the two. That is,
P_{ro}b_{r} = P_{ro}b^{1}_{r} ∗ P_{ro}b^{2}_{r}
Now, in the following, we explain how Pr1 and Pr2 are calculated respectively. We calculate P rob1r by the formula below:
P_{ro}b^{1}_{r} = 1 − (1 − p_{r})^{M}
where M is the amount of money controlled by all malicious nodes at round r (which is obtained by multiplying α_{r} to Ω_{r} and then rounding to an integer); p_{r} is the Sperax network-chosen probability parameter as discussed in section 3 (pr = N_{r}/ T_{r} where T_{r} is obtained by multiplying ρ_{r} to Ω_{r} and rounding to an integer). Since (1 − p_{r} )M is the probability T_{r} of no malicious node elected as a potential leader, 1 − (1 − p_{r})^{M} means the probability of they having at least one potential leader at round r.
We calculate P_{ro}b^{2}_{r} by the formula below:
We recall that Probr is essentially determined by six factors: (1). Ω_{r} (2). α_{r} (3). ρ_{r} (4). N_{r} (5). N_{r}^{'} (6). V_{min}. Firstly, among these six factors, Ω_{r} can be reasonably assumed to be a constant because Ω_{r} is a very large number and will not vary from rounds to rounds dramatically. Specifically, according to Sperax’s economic whitepaper, we assume Ω_{r} to be 200, 000, 000. Secondly, since it is possible that the worst senario might happen, we should make our adversary as powerful as possible when investigating the safety of our network. Thus, we assume α_{r} to be 0.33. This is because when more than 1/3 of the money in the network are controlled by malicious nodes we simply consider our network no longer safe according to our assumptions. Thirdly, N_{r} , N_{r}^{′} , and V_{min} are Sperax network-controlled parameters. In orther words, the Sperax network pre-determines some appropriate values for each of them and can adjust them at any time in order for the whole network to remain well-functioning. Specifically, as we have discussed in section 3 above, under usual circumstances, N_{r} is 20, N_{r}^{′} is 100, and V_{min} is 67.
Therefore, since all the six factors except ρ_{r} are either constants or as completely controllable variables, the only source of uncertainty is ρ_{r} , i.e. the participation rate. Plus, given a specific set of Ω_{r}, α_{r}, N_{r}, N′_{r}, and V_{min}, if we know what P_{ro}b_{r} will be like under every possible ρ_{r} , we will exhaust all the possible P_{ro}b_{r} ’s in that specific setting including the worst. Since we are investigating the safety of our blockchain, the setting we are most interested in is the worst case under usual circumstance. Thus, we set Ω_{r} = 200,000,000, α_{r} = 0.33, N_{r} = 20, N′_{r} = 100, and V_{min} = 67 and draw a P_{ro}b_{r} vs ρ_{r} graph as follows.
According to our assumptions, active, honest nodes control at least 51% of the total money at round r. Hence, the participation rate, ρ_{r} , is at least 84% (since α_{r} = 0.33). As a result, in the graph above, we only need to care about the portion where ρ_{r} is larger than or equal to 84%. According to the graph, clearly, when ρ_{r} increases, P_{ro}b_{r} goes down and our blockchain becomes safer. Hence, the largest P_{ro}b_{r}, i.e. the most unsafe, is at ρ_{r} = 84%. In this worst case, P_{ro}b_{r} has its order of magnitude of at most -5; that is, the largest possible P_{ro}b_{r} is less than 2^{−13} when appropriate N_{r}, N′_{r}, V_{min} are given by the Sperax network (It is in fact less than 2^{−14} as our previous calculation on the worst case has shown). This number is practically low enough considering the safety of any blockchain. Therefore, based on the analysis provided above, we conclude that our blockchain is safe against "network-partitioning attacks" when Sperax network-controlled parameters are appropriately chosen.
Figure 3: Democratic community
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;
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.
[1] David Ahmad. Two years of broken crypto: debian’s dress rehearsal for a global pki compromise. Security & Privacy, IEEE, 6(5):70–73, 2008.
[2] ThomasBall,ByronCook,Vladimir Levin,and Sriram K Rajamani.SLAM and static driver verifier:Technology transfer of formal methods inside microsoft. In International Conference on Integrated Formal Methods, pages 1–20. Springer, 2004.
[3] M. Ben-Or. Another advantage of free choice: Completely asynchronous agreement protocols (extended ab- stract). In Proc. 2nd ACM PODC, pages 27–30, 1983.
[4] K.P. Birman and T.A. Joseph. Reliable communication in the presence of failures. ACM Transactions on Com- puter Systems (TOCS), 5(1):47–76, 1987.
[5] G.Bracha.Anasynchronous[(n−1)/3]-resilientconsensusprotocol.InProc.3rdACMPODC,pages154–162. ACM, 1984.
[6] E. Buchman, J. Kwon, and Z. Milosevic. The latest gossip on BFT consensus. Preprint arXiv:1807.04938, 2018.
[7] M.Castro and B.Liskov.Practical byzantine fault tolerance and proactive recovery.ACM TOCS,20(4):398–461, 2002.
[8] T. D. Chandra and S. Toueg. Unreliable failure detectors for reliable distributed systems. JACM, 43(2):225–267, 1996.
[9] D. Chaum. Blind signatures for untraceable payments. In Proc. CRYPTO, pages 199–203. Springer, 1983.
[10] D.Chaum,A.Fiat,andM.Naor.Untraceableelectroniccash.InProc.CRYPTO,pages319–327.Springer-Verlag New York, Inc., 1990.
[11] Cosmos. Cosmos Network: Internet of Blockchains https://cosmos.network.
[12] Debian.Debian security advisory dsa-1571-1.available at http://www.debian.org/security/2008/ dsa-1571., 2008.
[13] Yvo Desmedt, Yongge Wang, and Mike Burmester. A complete characterization of tolerable adversary struc- tures for secure point-to-point transmissions without feedback. In International Symposium on Algorithms and Computation, pages 277–287. Springer, 2005.
[14] D. Dolev and H.R. Strong. Polynomial algorithms for multiple processor agreement. In Proc. 14th ACM STOC, pages 401–407. ACM, 1982.
[15] C. Dwork, N. Lynch, and L. Stockmeyer. Consensus in the presence of partial synchrony. JACM, 35(2):288–323, 1988.
[16] Ethereum. Randao: A DAO working as RNG of ethereum, 2017. https://github.com/randao/randao and https://www.randao.org/whitepaper/Randao_v0.85_en.pdf
[17] M.J. Fischer, N. A Lynch, and M.S. Paterson. Impossibility of distributed consensus with one faulty process. JACM, 32(2):374–382, 1985.
[18] J. Garay, A. Kiayias, and N. Leonardos. The bitcoin backbone protocol: Analysis and applications. In EURO- CRYPT, pages 281–310. Springer, 2015.
[19] Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proc. the 26th Symposium on Operating Systems Principles, pages 51–68. ACM, 2017.
[20] Osman Gazi Gucluturk. The dao hack explained: Unfortunate take- off of smart contracts. https://medium.com/@ogucluturk/the-dao-hack-explained-unfortunate-take-off-of-smart-contracts-2bd8c8db3562.
[21] Benjamin Jun and Paul Kocher. The intel random number generator. Cryptography Research Inc. white paper, 1999.
[22] I. Kanter, Y. Aviad, I. Reidler, E. Cohen, and M. Rosenbluh. An optical ultrafast random bit generator. Nature Photonics, 4(1):58–61, 2010.
[23] J. Katz and C.-Y. Koo. On expected constant-round protocols for byzantine agreement. Journal of Computer and System Sciences, 75(2):91–112, 2009.
[24] J. Kwon. Tendermint powers 40%+ of all proof-of-stake blockchains. invest:asia, available at https:// realsatoshi.net/12886/, Sept. 12, 2019.
[25] L. Lamport, R. Shostak, and M. Pease. The Byzantine generals problem. ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982.
[26] Pu Li, Xiaogang Yi, Xianglian Liu, Yuncai Wang, and Yongge Wang. Brownian motion properties of optoelec- tronic random bit generators based on laser chaos. Optics express, 24(14):15822–15833, 2016.
[27] S.J. Mullender. Distributed systems. Addison-Wesley, 1993.
[28] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
[29] M. Pease, R. Shostak, and L. Lamport. Reaching agreement in the presence of faults. JACM, 27(2):228–234, 1980.
[31] TK Srikanth and S. Toueg. Simulating authenticated broadcasts to derive simple fault-tolerant algorithms. Dis- tributed Computing, 2(2):80–94, 1987.
[32] The LibraBFT Team. State machine replication in the Libra Blockchain. available at https://developers.libra.org/docs/assets/papers/libra-consensus-state-machine-replication-in-the-libra-blockchain/2019-11-08.pdf, November 28, 2019.
[33] John Walker. Hotbits: Genuine random numbers, generated by radioactive decay. Online: http://www. fourmilab.ch/hotbits, 2001.
[34] Y. Wang and Y. Desmedt. Secure communication in multicast channels: the answer to Franklin and Wright’s question. Journal of Cryptology, 14(2):121–135, 2001.
[35] Y. Wang and Y. Desmedt. Perfectly secure message transmission revisited. Information Theory, IEEE Tran., 54(6):2582–2595, 2008.
[36] Y. Wang and T. Nicol. Statistical properties of pseudo random sequences and experiments with PHP and Debian OpenSSL. In Proc. ESORICS, LNCS 8712, pages 454–471, 2014.
[37] Yongge Wang. Byzantine fault tolerance in partially connected asynchronous networks. http://eprint.iacr.org/2019/1460, 2019.
[38] M.Yin,D.Malkhi,M.K.Reiter,G.G.Gueta,andI.Abraham.HotStuff:BFT consensus in the lens of blockchain. arXiv preprint arXiv:1803.05069, 2018.
Figure 4: SperaxDAP example
Contract code storage: The hash value of the smart contract is recorded on the chain, and the complete contract code is stored off chain with a hash value index. When the contract is executed, the code is loaded from the outside of chain. Since the hash value of the contract is already recorded in the chain, even if the code is loaded from the outside of chain, there is no need to worry about the contents of the contract being tampered with. This allows the node to save more space for storage and can also protect the content of smart contracts to a certain degree of privacy at the same time.
Contract code execution: The Sperax virtual machine adopts a memory-safe and platform-independent instruction set standard based on WebAssembly that can be mapped to all types of CPU architectures perfectly and efficiently. The contract’s instruction set runs in a virtual container which imposes strict restrictions on computing resources and program steps to ensure secure execution of the contract.