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
S0 = { (P1, a1), · · ·, (Pj, aj) }
where P1, P2, · · · , Pj are a list of initial users and a1, · · · , aj are their respective initial amounts of money units. We assume that each user Pi is identified by its public key pki . That is, for the users P1 , P1 , · · · , Pj , their corresponding public keys are pk1 , · · · , pkj . In practical implementations, a user Pi may be identified by the hash of her public key. That is, we may use Pi = H(pki) in implementations. A valid transaction from a user Pi to a user Pi′ is in the format ofSIGpki (Pi, Pi′ , a′)
where the user Pi currently has a ≥ a′ money units, Pi′ is an existing or a newly created user, and pki is the public key of user Pi. The impact of this transaction is that the amount of money units for user Pi is decreased by a′ and the ′ amount of money units for user Pi′ is increased by a' .L = TX0,TX1,TX2,· · ·,
Sr = { (P1,a(r)1),(P2,a(r)2),(P3,a(r)3) }
TXr: Sr -> Sr+1.
Br = { r,tr,TXr,H(Br-1),Pr,CERTr }
SIGpki(Pi,P∞,mi,γir+κ′,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 P1 can send a message m1 to participant P2 and send a different message m2 to participant P3 though, in a broadcast channel, the malicious participant P1 has to send the same message m to multiple partici- pants including P2 and P3. If a malicious P1 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 Pi wants to participant in the leader and verifier committee selection process for the block Br generation, then Pi needs to deposit 10000ai 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 10000ai 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 Br is finalized. If stage s fails to finalizes the block Br, it moves to stage s+1.
where γri is the random string that user Pi has committed with staking (see Section 3.2), and Wr is defined as follows:
1. W0 = H(0x03243F6A8885A308D313198A2E037073),
2. Wj = H(Pj−1,Wj−1) for 0 < j ≤ r, where P0 = ∅ and Pj is the participant who generated the block Bj−1,
Remark: It should be noted that if a user stakes 10000ai SPA tokens and uses (1) to calculate the probability for him to serve as the block Br 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 10000ai SPA tokens, he may be considered as ai virtual users for the calculation of the probability in the equation (1).
At the start of stage s of round r, each potential leader Pi of this stage collects the maximal transaction set T Xir of round r that have been propagated to her. Then she computes the candidate block Bir without the certificate CERTr
The user Pi then propagates to the entire network the message mir,2s = (Bir , μir ) together with the Merkle hash tree r path corresponding the value μir .
Since there could be several potential leaders during round r, each user could receive several candidate block messages mjr,2s from the preceding paragraph. Thus we need to select a verifier committee to determine the actual leader Plr and finalize Br as the corresponding block Blrr proposed by this leader. The verifier committee is selected as follows. A user Pi belongs to the verifier committee V r for τi > 0 times (that is, Pi’s signature will be counted as τi signatures) where
whereγi r′ is the committed string by userP i in Section3.2,Wr 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/Tr where Tr is the total number of unit users who paid staking deposit for the round r (that is, Tr = Ωr/10000). It should be noted that in the formula(3),the value (aij) (p'>)j (1-p'>)wi-j is the probability that the user Pi is selected for exact j-times if each individual sub-user (Pi, j′) is selected with the probability p′/Ωr (this approach is similar to the approach used in Giladet al [19].
Each verifier Pi in Vr determines that the user Pl is the round leader if the conditions in both the formula (1) and the formula (2) are satisfied for all potential leader Pj contained in the messages mjr,2s that she has received. After verifying the validity of the message mjr,2s = (Blr,μlr), the verifier Pi authenticates and propagates her candidate lll block Blr to the entire network using the signature SIGpki (τi , H (Blr )) where τi is the number of time that the user Pi should serve in the verifier committee. Together with the message, the user Pi should also propagates the proof that she is the qualified committee member. This can be done by including his committed value μir together with the Merkle hash tree path corresponding the value μir .
Next each user Pi checks whether she has received more than 2vr/3 signatures for some candidate block Br where vr is the total number of committee members of Vr (note that a committee member may be counted multiple times). If there exist more than 2vr/3 signatures for a proposed block Br, then Pi marks Br as the final round r block. If no more than 2vr/3 signatures for a proposed block is received, then Pi 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 Br 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. Nr, the numerator in the expression of p (e.g. 20 in p = 20 / Tr in section 3)
5. N′r , the numerator in the expression of p′ (e.g. 1000 in p′ = 1000 / Tr in section 3)
6. Vmin, 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 Probr, 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 Probr1 . The second step in which malicious nodes have to succeed is to gather at least Vmin 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 Probr2 . Since these two steps are probabilistically independent, the ultimate probability for malicious nodes to successfully make the first block in forming a fork, Probr, is simply the multiplication of the two. That is,
Probr = Prob1r ∗ Prob2r
Now, in the following, we explain how Pr1 and Pr2 are calculated respectively. We calculate P rob1r by the formula below:
Prob1r = 1 − (1 − pr)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); pr is the Sperax network-chosen probability parameter as discussed in section 3 (pr = Nr/ Tr where Tr is obtained by multiplying ρr to Ωr and rounding to an integer). Since (1 − pr )M is the probability Tr of no malicious node elected as a potential leader, 1 − (1 − pr)M means the probability of they having at least one potential leader at round r.
We calculate Prob2r by the formula below:
We recall that Probr is essentially determined by six factors: (1). Ωr (2). αr (3). ρr (4). Nr (5). Nr' (6). Vmin. 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, Nr , Nr′ , and Vmin 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, Nr is 20, Nr′ is 100, and Vmin 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, Nr, N′r, and Vmin, if we know what Probr will be like under every possible ρr , we will exhaust all the possible Probr ’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, Nr = 20, N′r = 100, and Vmin = 67 and draw a Probr 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, Probr goes down and our blockchain becomes safer. Hence, the largest Probr, i.e. the most unsafe, is at ρr = 84%. In this worst case, Probr has its order of magnitude of at most -5; that is, the largest possible Probr is less than 2−13 when appropriate Nr, N′r, Vmin 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.