Share and get +16 +16

Libra Cryptocurrency: The Libra Consensus Algorithm

In part 1 of this guide, we gave you an introduction to Libra cryptocurrency and talked about its blockchain. We also told you about the unique opportunity that Facebook has to leverage its user base to gain traction for its coin. In this guide, we are going to discuss the LibraBFT consensus algorithm, the Move programming language, and the Libra Association.

LibraBFT is the Libra Consensus Algorithm. “Consensus” is a dynamic way of reaching an agreement in a group. While voting settles for a majority rule without any thought for the feelings and well-being of the minority, a consensus, on the other hand, makes sure that an agreement is reached which could benefit the entire group as a whole.

From a more idealistic point-of-view, Consensus can be used by a group of people scattered around the world to create a more equal and fair society. The method by which consensus decision-making is achieved is called “consensus mechanism.”

Consensus mechanisms can be categorized into the following:

Nakamoto Consensus.

Classical Consensus.

Nakamoto Consensus

The next stage of consensus-evolution is Nakamoto consensus. Named after the pseudonym of the anonymous Bitcoin creator Satoshi Nakamoto, these kinds of consensus mechanisms are widely used in modern decentralized ecosystems. So, what are the main requirement of a Nakamoto consensus?

It should be able to deal with a wide area network.

The consensus mechanism should provide proper validation of transactions by at least 2/3rd of the network.

Should protect against double-spending.

So, what sets Nakamoto consensus systems apart from classical consensus? Nakamoto consensus introduces a particular element called “difficulty” into the network. The difficulty could be some sort of work, resource, asset, etc., which the member of the network must invest to create a new block. The “difficulty” helps in the following:

Block verification.

Controlling the number of coins/tokens floating around in the ecosystem.

Bringing security into the system.

Proof-of-work is an example of a Nakamoto consensus.

Classical Consensus

In this class of algorithms, the participating processes reach consensus using multiple rounds of message exchanges, carrying votes, and safety-proofs. For this system to work, a good majority of the processes need to agree on the votes and safety-proofs. Classical consensus algorithms must satisfy the following properties:

Validity : If a correct process broadcasts a message, then it is assumed that the process will eventually deliver that message.

Agreement : If a message is delivered by some correct process then it will eventually be delivered by that process.

Integrity : If the correct process delivers a message, then the process before that which delivered that same message must be correct. No correct process will deliver the same message more than once.

Total order: If two messages m and n have been sent by two correct processes. Then if one process sent m before n, then we can automatically assume that the other process also sent m before n.

Byzantine Tolerance

A system is called Byzantine tolerant if it can solve the Byzantine general’s problem.

Imagine this scenario.

We have a bunch of generals surrounding the enemy castle with their armies. The castle is extremely strong, so it needs to be attacked by a supermajority (2/3rd) of all the generals at the same time. There is no central authority that commands all these generals because they are scattered around. The only way they can somewhat coordinate the attack is by sending a messenger to each of the generals, carrying a particular message.

However, this is where we hit an obstacle.

You see, not all of our generals are honest. Some of our generals are plotting against us. Their strategy is to pull out from the attack in the last second and leave our army stranded. This right here is the Byzantine Generals Problem.

In simple terms, how do you make a decentralized system work even if some of the participants are corrupt? A consensus algorithm should be able to do just that.

Way back in the 1980-90s, researchers came up with a method to answer the Byzantine general problem by creating a Byzantine Fault Tolerance (BFT) system. The way BFT works is straightforward. A distributed system should be able to achieve consensus even if some of the nodes in the network become malicious. The end goal of this mechanism is to protect against catastrophic system failures, reducing the impact that these malicious nodes have on the proper functioning of the network.

In the 1980s, several system architectures were developed in which BFT was implemented. These include Draper’s FTMP, Honeywell’s MMFCS and SRI’s SIFT. One of the most prominent examples of classical consensus is Practical Byzantine Fault Tolerance or pBFT.

LibraBFT belongs to the class of classical BFT consensus algorithms. It is based on another consensus algorithm called HotStuff, which in turn borrows some of its consensus logic from pBFT.

Practical Byzantine Fault Tolerance or pBFT.

Practical Byzantine Fault Tolerance is a practically improved form of BFT. Its working principle is based on the following assumptions:

The nodes in the network will be embroiled in constant communication.

At any time, the total number of malicious nodes simple cannot exceed one-third of the total population.

pBFT makes the consensus process extremely efficient. The moment 2/3rd of the network agrees on a particular decision, it gets executed. This particular assumption has been utilized in future consensus mechanisms as well. The constant communication between the nodes reduces network latency. pBFT uses an asynchronous distributed system where processes are connected by a network. The network may fail to deliver messages, delay them, duplicate them, or deliver them out of order.

If N is the total number of processes and f is the total number of Byzantine processes, then his condition should be maintained: N ≥ 3f + 1 to maintain a pBFT system.

The HotStuff consensus protocol improves upon pBFT by making it a lot less complex. The Libra developers took inspiration for HotStuff and improved upon it to create LibraBFT.

Libra Cryptocurrency: The LibraBFT protocol

In LibraBFT, the nodes in charge of block production are called “Validators,” who make progress in rounds. Each round has its own designated validator called a leader who is responsible for proposing new blocks and obtaining majority votes from the rest of the validators to get the block approved. Let’s take a look at how the protocol works (thanks to Block Crypto for the content):

The round begins. A round is a communication phase initiated by a randomly selected leader. The proposals made by the leader is organized into a chain using cryptographic hashes

The leader proposes a block.

If the block is valid, the validators sign off on it and send their votes to the leader.

When the leader has received enough votes to reach a quorum, they aggregate these votes into a Quorum Certificate (QC)

The QC is broadcast to every node.

If the leader fails to assemble the QC then the other validators will issue a timeout and move on to the next round. So the current leader will be replaced.

Eventually, enough blocks and QCs will extend the chain in a timely manner, and a block will match the commit rule of the protocol.

As soon as the block matches the commit rule, the chain of uncommitted blocks up to the matching block becomes committed.

Libra Cryptocurrency: Libra Association

The Libra Association is the governing entity of the Libra blockchain. It is an independent, not-for-profit membership organization, headquartered in Geneva, Switzerland. According to the whitepaper, “The association is designed to facilitate the operation of the Libra Blockchain; to coordinate the agreement among its stakeholders — the network’s validator nodes — in their pursuit to promote, develop, and expand the network, and to manage the reserve.”

The association is governed by the Libra Association Council, which is comprised of one representative per validator node. The Council must approve all decisions regarding the network via a 2/3rd majority vote. Council will initially consist of the Founding Members.

Along with the decision making, the Libra Association will also be in charge of two more important roles:

Managing the Libra Reserve.

Increase decentralization over time.

Libra Cryptocurrency: Managing the Libra Reserve

Managing the Libra Reserve is vital for the stability and growth of the Libra economy. Only the association can mint and burn Libra cryptocurrency.

Tokens can only be minted when authorized resellers have purchased those coins from the association with fiat assets to back the new coins fully.

Tokens can only be burned when the authorized resellers sell Libra coin to the association in exchange for the underlying assets.

Increase decentralization over time

A vital objective of the Libra Association is to move towards decentralization over time. They will be starting the transition within five years since launch. During the transition, the network’s reliance on the Founding Members will decrease.

Here’s the full list of founding members and partners:

Andreessen Horowitz

Anchorage

Bison Trails

Booking Holdings Inc.

Breakthrough Initiatives

Facebook’s Calibra

Coinbase Inc.

EBay Inc.

Farfetch Ltd.

Iliad SA’s Free

Lyft Inc.

Mastercard

MercadoLibre Inc.’s Mercado Pago

PayPal

Naspers Ltd.’s PayU

Ribbit Capital

Spotify Technology SA

Stripe Inc.

Thrive Capital

Union Square Ventures

Uber

Visa

Vodafone Group

Xapo

Creative Destruction Lab

Kiva

Mercy Corps

Women’s World Banking

Reports suggest Facebook charged around $10 million from each of these backers to manage a node in the Libra ecosystem.

Libra Cryptocurrency: Move – Libra’s programing language

“Move” is a new programming language for implementing custom transaction logic and “smart contracts” on the Libra Blockchain. Move’s main priority is to provide smart contracts with a high degree of security. To do that, Move has taken the approach of functional programming languages.

So, how does functional programming work?

Suppose there is a function f(x) that we want to use to calculate a function g(x) and then we want to use that to work with a function h(x). Instead of solving all of those in a sequence, we can simply club all of them together in a single function like this:

h(g(f(x)))

This makes the functional approach easier to reason mathematically. This is why functional programs are supposed to be a more secure approach to smart contract creation. This also aids in simpler Formal Verification which pretty much means that it is easier to mathematically prove what a program does and how it acts out. This gives Cardano its “High Assurance Code” property.

Let’s take a real-life example of this and see why it can become extremely critical and even life-saving in certain conditions.

Suppose, we are coding a program that controls air-traffic.

As you can imagine, coding such a system requires a high degree of precision and accuracy. We can’t just blindly code something and hope for the best when people’s lives are at risk. In situations like these, we need a code that can be proven to work to a high degree of mathematical certainty.

This is precisely why the functional approach is so desirable.

And that is exactly what Cardano is using Haskell to code their ecosystem and Plutus for their smart contracts. Both Haskell and Plutus are functional languages.

So, let’s look at the advantages of the functional approach:

It helps with creating high assurance code because it is easier to prove how the code is going to behave mathematically.

It increases the readability and maintainability because each function is designed to accomplish a specific task. The functions are also state-independent.

The code is easier to refractor and any changes in the code are simpler to implement. This makes reiterative development easier.

The individual functions can be easily isolated which makes them easier to test out and debug.

The three main applications of Move are:



Issuing cryptocurrencies, tokens, and digital assets.

Handling blockchain transactions.

Managing validators.

Let’s go through some of the features of Move.

Feature #1: Bottom-up Static Typing

The static typing of Move is much stricter than solidity. This makes sure that many simple bugs will be detected during compilation instead of execution. The logic behind this is that well-typed programs will never get stuck. Since smart contracts usually deal with millions of dollars, it’s much preferable if the code behind it has been refined to its fullest.

Move is not 100% statically typed, due to practicability requirements. It tries to perform type checking during compilation rather than deployment. Interestingly, Move’s virtual machine is statically typed as well.

Feature #2: Resource Types

Traditional programming languages, including solidity, record digital assets in values which might be incorrect numbers. The problem with “value” is that when it comes to programming it is something that people read and copy. “Resource,” on the other hand, is something that you consume and can’t copy.

This is why digital assets in a Move contract is of the “resource type” where:

Digital assets could not be copied.

Digital assets could not vanish.

As the whitepaper stated, “First-class resources are a very general concept that programmers can use not only to implement safe digital assets but also to write correct business logic for wrapping assets and enforcing access control policies.”

The main idea of First-class Resources is that digital assets are first-class citizens. This infers that ‘Move’ is the smart contract language designed exactly for managing digital assets. Technically, digital assets could be variables in contracts to be stored, assigned, and become parameters/return values of functions & processes. The static typing of ‘Move’ enables the compiler to examine most errors of resources during compilation and before deployment, enhancing smart contracts’ security.

Feature #3: Contract Security Design

Let’s understand the differences between dynamic and static dispatches. Dynamic dispatch is a flexible language mechanism that allows you to write multiple functions, processes, or subprograms in the code which will allow the program to call an external unknown program/function to perform various functions.

Static dispatch, on the other hand, allows programs to only call functions whose behavior is already known.

On paper, dynamic dispatch sounds better, right? However, allowing so much flexibility opens up the program to bugs and various vulnerabilities. This is why Move contracts don’t support dynamic dispatch.

Move’s modular system doesn’t support cyclic recursion dependency so there could be no re-entrancy bug. This was the bug that caused the infamous DAO hack, which led to Ethereum getting split up into Ethereum and Ethereum classic.

Speaking of Module Systems.

Feature #4: Advanced Module System

The whitepaper states:

“Move modules are similar to smart contracts in other blockchain languages. …, However, modules enforce strong data abstraction — a type is transparent inside its declaring module and opaque outside of it.”

Move’s module system has been optimized to enable efficient formal verification. Formal verification is a process that mathematically shows what a program does and how it acts out. For mission-critical programs like smart contracts, formal verification is an absolute necessity.

Firstly, Move’s module system will offer a solid base for formal verification by allowing you to define invariants inside the module. The invariant is a strict restraint of digital asset state providing valuable information for formal verification automation.

Secondly, the module system will enable formal verification to be modularized. So instead of verifying the entire contract, it would be possible to formally verify certain parts of the contract, which will reduce costs dramatically.

Conclusion: Is Facebook’s Libra Cryptocurrency good or bad for crypto?

So, now that we have reached the end, do you think that Facebook Libra is good or bad for crypto in general? The community seems to be split. Let’s look at some of the reactions.

Positive Reactions

Brad Garlinghouse CEO of Ripple said that Libra has hastened catalyzed contract activity on Ripple. He added, “I will send a case of champagne to David Marcus the guy who runs Libra.” Morgan Creek CEO Anthony Pompliano, “The most important part of the Facebook announcement is that every user of a Facebook property will get a digital wallet eventually. Almost 1/3 of the world will be onboarded to cryptocurrencies. This is incredibly bullish for Bitcoin.” Bank of England (BOE) Governor Mark Carney: “The Bank of England approaches Libra with an open mind but not an open door. Unlike social media … the terms of engagement for innovations such as Libra must be adopted in advance of any launch. To remain a dominant player we in the U.K. must do what London’s markets have always done: evolve.”

Negative Reactions

Nouriel Roubini, “It has nothing to do with blockchain. Fully private, controlled, centralized, verified and authorized by a small number of permissioned nodes. So what is crypto or blockchain about it? None.” Sarah Jamie Lewis, “Can’t wait for a cryptocurrency with the ethics of Uber, the censorship resistance of Paypal, and the centralization of Visa, all tied together under the proven privacy of Facebook.” France’s finance minister Bruno Le Maire, “[Libra] can’t and…must not happen..it is out of question [for Libra to] become a sovereign currency.” Representative Sherrod Brown, the leading Democrat on the Senate Banking Committee, said, “Facebook is already too big and too powerful, and it has used that power to exploit users’ data without protecting their privacy. We cannot allow Facebook to run a risky new cryptocurrency out of a Swiss bank account without oversight.”

The regulators are working overtime to figure out Libra and strategizing how they can control its use. We guess only time will tell if Libra can indeed be the “global coin” it aims to be.