We announced PCHAIN will adopt our cross chain tech to support Facebook Libra yesterday. We are proud of being the 1st public blockchain to support Libra via our patented cross chain tech. Many people is curious why PCHAIN will cross chain to Libra？In fact, this is an important decision for PCHAIN from both tech aspect and ecosystem aspect.
From ecosystem aspect, it’s quite simple. Obviously, Libra introduced global attention. More and more cooperation is considering how to collaborate with Libra both in super node way and business way. Of course, beside to support cross chain, PCHAIN also come with several partner to apply for Libra super node. But more importantly, Facebook itself is an ecosystem which includes 2 billion face users. And Libra obviously will facilitate their financial inclusion and break the limitation of country board.
From tech aspect, it’s also natural. After studying the whitepaper of Libra, we found it’s mainly based on Libra BFT algorithm. It can be easily interact with PCHAIN PDBFT algorithm, as both of them is BFT class consensus. And BFT consensus can get instance finality within 1 block. While our PDBFT can be much faster as PCHAIN can generate new block within 1–2 seconds with 78 nodes globally. We even would help Libra to achieve better performance by adopting part of PDBFT algorithm to improve their current 10 second block generation time to 2 seconds or even 1 second.
let’s revisit our PDBFT algorithm. How it can achieve these 1–2 second instance finality.
PDBFT2.0 is based on the classic PBFT protocol, with 3 major improvements: (1) PDBFT2.0 achieves linear worst-case communication volume, in contract to PBFT’s O(n4); (2) the leader of each round in PDBFT2.0 is selected by a verifiable random function (VRF), which avoids that the leader is attacked by DDos; (3) in the ordinary case, PDBFT2.0 involves only a single round of voting instead of two in PBFT, which reduces both communication overhead and confirmation time.
It is well known that PBFT is a protocol with three phases: pre-prepare, prepare and commit. In phase prepare and commit, each validator has to broadcast its vote for the proposed block. Upon receiving 2f+1 commit-vote, each validator finalizes the block. Due to the broadcasting of vote, the complexity of communication is O(n²). Instead, there is a collector for collecting votes from all validators in PDBFT2.0. In addition, PDBFT2.0 adopts threshold signature to achieve linear communication. An (n,t)-threshold signature on a mes- sage m is a single, constant-sized aggregate signature that passes verification if and only if at least t out of the n participants sign m. Note that the verifier does not need to know the identities of the t signers.
Each collector derives an (n,2f+1)-threshold signature after collecting 2f+1 votes. Threshold signature can be seen as a single signature with constant size. After that, collector broadcasts the threshold signature and each validator can confirm that more than 2f+1 validators have voted for proposed block via verify threshold signature.
In classic PBFT, two rounds of voting are deployed to guarantee safety and liveness of protocol. However, in PDBFT2.0, single round of voting is enough without losing safety or liveness. It notes that the blocks are chained by a hash value in blockchain. Therefore, the vote for current block is the confirmation for previous block as well. Hence, one vote can be seen as two different votes. In PDBFT2.0, each validator just sends one vote for the proposed block. If more 2f+1 votes for current block is collected by validator, previous block is finalized at once. We see that the vote for current block is the prepare-vote and commit-vote for current block and previous block at the same time. Therefore, each block is finalized after two round of voting which promises the safety. Besides, each block just consumes single round of voting in average.
Similar to PBFT, the view change subprotocol of PDBFT2.0 is triggered when the validators cannot reach consensus in a single round. This can be due to an asynchronous network (e.g., when more than 1/3n nodes are offline), or the presence of malicious collectors/leaders. PDBFT2.0 handles a view change with the Linear View Change (LVC) algorithm. The essence of LVC is that the leader of the next round sends its highest commit certificate instead of all commit certificates, which reduces transmission volume during a view change by a factor of O(n). In PBFT or tendermint, each leader is decided in a round-robin scheduling which can be predicted by the adversary. PDBFT2.0 avoids this situation by selecting collectors (leaders) randomly, using a VRF. A VRF is a pseudo-random generator whose output is verifiable (i.e., on whether a given number is indeed the output of the VRF), random, uniformly distributed, and unpredictable beforehand. With random leaders, the leader of next round is unpredictable and the adversary can not attack the leader in advance.
Everyone who is familiar with our project should notice Fig.1 “The overall structure of PCHAIN” defined in our position paper in Mar. 2018. The PCHAIN Network can access a variety of external public blockchain and consortium blockchains.
Now, we are glad to include the Libra as the new external public chain!
**Click here to review the previous news that PCHAIN crosschain technology will support Binance chain.
