As cryptoassets have become more mainstream the average technical ability has dropped considerably. Many barely grasp the underlying principles of blockchain, let alone the technical differences between competing projects.
Accordingly, marketing and hype has overtaken substance as the predominant driver for valuations. Ludicrous claims of scalability and security are thrown out without a semblance of proof, all willingly lapped up by either paid for actors or shill armies more resembling the tribalistic nature of football fans than emotionally detached investors.
These conditions only increase the intrigue when a normally reserved team, Maidsafe, announce their new development, the Protocol for Asynchronous, Reliable, Secure and Efficient Consensus (PARSEC), in unusually hyperbolic fashion:
“We’ve created the world’s first (as far as we’re aware!) completely decentralised, open source, highly asynchronous, Byzantine Fault Tolerant consensus mechanism.”
Awesome! But what does that actually mean? And why should people care?
To explain, I will break down (warning: the following will be very long) the PARSEC whitepaper written by Pierre Chevalier (I also draw upon Chevalier’s supplementary presentation at certain points), Bartlomiej Kami´nski, Fraser Hutchison, Qi Ma and Spandan Sharma. Hopefully I will even manage to avoid butchering their work. I will explain some of the key concepts taken for granted as presumed knowledge in the whitepaper as well as run through the underpinning aspects of PARSEC. I will not go through every single piece of how PARSEC works at a granular level — the whitepaper is there to serve that purpose.
I am also going to avoid validating — or refuting — Maidsafe’s claims as there are others better placed to do so. Finally, I am not going to delve into every little thing but rather will focus on explaining the broad topics needed to understand PARSEC. As such some of the intricacies, exceptions and smaller aspects that take many words to explain but have a minimal impact will be omitted. With that out of the way…
What is PARSEC attempting to achieve?
“In this paper we present an algorithm for reaching consensus in the presence of Byzantine faults in a randomly synchronous network. We prove the algorithm’s correctness provided that less than a third of participating nodes are faulty.”
It’s easy to read a sentence and think you understand it but, when called upon to fully explain, struggle to do so. Let’s provide some definitions of what this means. The three key points in these sentences are:
Consensus algorithm: You can find an introduction to consensus algorithms (CA) here, but essentially CA’s are what allow Distributed Ledger Technology (DLT) to function. They are used to verify which data submitted to a shared ledger should be retained as correct, which should be ignored and what order it should go in. An example of a CA is Proof of Work, used by likes of Bitcoin, which enables all users on the Bitcoin network to agree upon and subsequently see the same information on the blockchain.
Byzantine faults: A Byzantine fault is a fault presenting different symptoms to different observers. A network is Byzantine Fault Tolerant (BFT) when it can provide service and reach a consensus in spite of system faults or failures. Consensus algorithms are what makes it possible for distributed networks to solve the Byzantine Generals Problem, even when there are unreliable or malicious actors operating.
Randomly synchronous: The whitepaper defines this as “messages are delivered with random delays, such that the average delay is finite”. Essentially, you may have to wait a while, but the message will eventually be delivered. Imagine you are at home and staring out of the window waiting for an important parcel to be delivered. The delivery company has promised it will be delivered today. But it’s now 20:30 and there is no driver in site. Has the company lost it? Did they never manage to send it? Or is it just delayed?
Essentially, the abstract is setting out a claim that Maidsafe have managed to create a protocol in which:
- All users can reach an agreement on what has happened;
- This consensus occurs despite the possibility of system failures or faults (e.g. nodes going offline) and even if we assume up to 1/3 of all actors (which is the best possible solution a network can reach under any circumstances) operating on the network are malicious or faulty;
- There is no guarantee for nodes on the timing that they should be receiving messages
The last point is important. There are three broad types of synchrony used by DLTs:
Synchronous: This means that there is a known timing for nodes to wait and receive information. Ethereum and Bitcoin are both examples of this; Bitcoin blocks are 10 minutes apart, Ethereum c. 15 seconds. Essentially, if a node has not received an input within these boundaries they know that there is a problem.
Partially Synchronous: A partially synchronous network retains some form of timing assumption but it can continue to operate without knowing said assumption of how fast nodes can exchange messages over the network. Rather than pushing out a block every X seconds, a partially synchronous blockchain would know there was some limit but not know exactly what it was, with messages always being sent and received within the unknown deadline. DLTs that are not synchronous tend to be partially synchronous (such as Cosmos and others).
The problem with both synchronous and partially synchronous implementations is summed up well in the whitepaper The Honey Badger of BFT Protocols (a text the PARSEC paper also leans on) which argues that “protocols based on timing assumptions are unsuitable for decentralized, cryptocurrency settings, where network links can be unreliable, network speeds change rapidly, and network delays may even be adversarially induced”.
Essentially, basing a protocol on timing opens the network up to attack vectors such as Denial of Service attacks. If a DoS slows down the network sufficiently then a synchronous protocol becomes unsafe. While a partially synchronous protocol would be safe, both protocols would be unable to operate, as the messages would be interfered with (and both Ethereum and Bitcoin have been subjected to DDoS attacks).
Asynchronous: An asynchronous network makes no timing assumption and allows for the potential that the sending and receiving of messages is delayed for an arbitrarily long time (which could include infinity). The speed is driven by the speed that the network can communicate. Rather than a fixed limit of X seconds (be it known or not), it just happens as and when consensus is reached.
An asynchronous protocol would be able to operate under a DoS attack but creates a new problem which is that it is hard to reach a consensus when it is impossible to know if the network is under attack (e.g. DDoS) or if a particular message is just being delayed by the protocol itself. Synchronous protocols come to a consensus every X seconds. Partially synchronous protocols come to a consensus every unknown amount of seconds. An asynchronous protocol instead needs a different means to decide when all nodes are able to come to a consensus.
This problem is essentially what PARSEC solves. It makes it possible to reach 100% certainty consensus with no reliance on timing, with up to 1/3 of the network being dishonest even if the network is attacked (up to 1/3 is the most any network can endure).
Not a blockchain
One final point before I actually start going through the whitepaper (I am painfully aware I have just taken 1,210 words to explain a two sentence abstract); Maidsafe is not a blockchain and the company is one of the few in the space to predate Bitcoin, in operation since 2006. A Medium post that accompanied the launch of PARSEC details the limitations of blockchain, reasons that will be familiar to anyone who reads this site.
I fully agree with their assessment that despite the achievements of blockchain it “comes with limitations of transactions-per-second” which renders it unsuitable for true adoption. There are obviously initiatives in progress and promises that blockchain will see 1m+ tps — I accept the ambition but will remain sceptical until it is achieved with no sacrifice to security or decentralisation.
I’m not going to go through the whitepaper line by line but some key points in the introduction not already covered:
“It has no leaders, no round robin, no proof-of-work and reaches eventual consensus with probability one”
Fairly self-explanatory, it avoids the DPoS style need for a trusted set of leaders and similarly does not have round robin (which is where a permissioned set of miners sign each block).
“It is also fully open”
Unlike the likes of Hashgraph which are patented and closed sourced, PARSEC is open source software
“The general problem of reaching Byzantine agreement on any value is reduced to the simpler problem of reaching binary Byzantine agreement on the nodes participating in each decision. This allows us to reuse the elegant binary Byzantine agreement protocol (Signature-Free Asynchronous Byzantine Consensus) after adapting it to the gossip protocol”
I will come onto this later, but essentially the principle behind Mostefaoui, Hamouna and Raynal’s paper cited in the link above relies on a concept called the Common Coin, as defined by Michael Rabin back in 1983. The Common Coin was a means to allow a CA to make a random choice and in so doing achieve consensus in a distributed network. I will also cover the gossip protocol in the next section.
“The need for a trusted leader or a trusted setup phase implied in is removed by porting the key ideas from  to an asynchronous setting.”
- The protocol allows for consensus agreement without a central party
- The key ideas referred to here from Silvio Micali’s paper is the Concrete Coin, which is used instead of the Common Coin
Part 1 has outlined the objectives of PARSEC and we have defined some key terms necessary to understand the paper. Part 2 will now begin to look at how the PARSEC protocol works.
Disclaimer: I do not hold MAID and have no plans to buy. If you enjoyed this article then please follow me @FlatOutCrypto