Comparing Ethereum and the Libra blockchain

One is the second-biggest currently operating blockchain (since 2015). The second was unveiled just a few days ago, which wouldn’t attract as much attention, if the company behind it wasn’t Facebook.

Both allow transacting a cryptocurrency — ETH and the Libra coin — respectively, as well as running user-defined smart contracts: custom scripts, which can read and manipulate the blockchain state.

Do the similarities end here? How much is Libra influenced by Ethereum — what does it improve on, change? Basing on what’s available in the whitepaper, let’s find out!

Who‘s in power

The first major difference between Libra and Ethereum (as well as Bitcoin), is that Libra is a permissioned blockchain, unlike Ethereum, which is permissionless. What does it mean?

In Ethereum, everybody is more or less equal. Nothing stops you from buying a powerful machine and joining the network as a miner, potentially earning mining fees and participating in the execution of the smart contracts. There are no parties which are more privileged than others; there’s no permission system, which dictates who can confirm new transactions and deploy new smart contracts.

Libra, at least initially, will be quite different. There will be a selected group of about 100 founding members (validators). These members will have to be trusted, and only they will be allowed to confirm new transactions. In essence, the founding members will be running the blockchain. Only they will have the permissions required to govern the blockchain.

This is similar to private blockchains, such as Hyperledger, which can be used to build a shared ledger among parties, so that no single node has to be fully trusted.

You may wonder, is this any better than a “traditional”, fully centralised system, where the transactions are operated by a central bank, or a financial institution? Yes, it could be better — as in this scheme, we get partial decentralisation. This is far from the full decentralisation of Ethereum, but the control over the network is now spread among a hundred organisations, not a single one. You only have to trust the majority of them to rest assured that your funds are safe, not a single entity or single state.

The Libra Association plans to transition to a permissionless system. This, however, depends on a number of technical and organisational issues, which still need to be resolved. When, and if they get resolved, is an open question.

Is this really a blockchain?

Now on a more technical note. In Ethereum, the concept of blocks is central to the system. Each miner takes a number of transactions, forms a block, and tries to append the block to the blockchain by guessing a number, so that a certain mathematical equation is true (this guessing takes a lot of computing power, and is known as Proof of Work). Each block references the previous one, and hence an authenticated chain is formed.

The security of this system relies on the fact that it would take a lot (really, a lot!) of computing power to create blocks with e.g. double-spend transactions. We get security, but at a cost of high energy consumption. Ethereum plans to transition to another system, called Proof of Stake, which doesn’t have this problem, but this is still under active research.

In Libra, the core data structure doesn’t contain blocks. Hence, we might say that it’s not really a blockchain. That’s probably also why the system is described as a decentralized, programmable database. What’s in Libra’s core data structures, then? Transactions. They still form a sequence (numbered with ever-increasing integers), and are incrementally stored in Merkle trees.

The root of this tree contains an authenticator value, which is similar to a block or transaction hash known from Ethereum. The authenticator for transaction i+1 depends on the authenticator of transaction i. We might then say that Libra is a blockchain after all, however with very small blocks, of size 1.

Even though blocks are not present in the way data is stored in the system, they are used by the validators when confirming transactions. As an optimisation, to reduce network traffic and improve performance, the validator nodes propose and commit transactions in blocks.

The security of Libra’s blockchain depends on the fact that the majority of founding members can be trusted (at least 2/3, to be precise; this is also known as Proof of Authority), and hence is much more energy-efficient. There are also plans to transition to Proof of Stake, but this depends on the same open research problems, as in Ethereum.

What’s in the blockchain

Libra follows Ethereum by using an account-based model. That is, the blockchain stores a database, which contains a mapping from account addresses to account values. Each account corresponds to a private/public key pair (private keys can be rotated, it’s not a 1–1 correspondence).

The values stored for an account can contain Libra coins (ETH balance), or deployed smart contracts.

This is unlike e.g. Bitcoin, which uses the UTXO model.

Fees

When considering a financial system, one of the main questions is — how much does it cost to make a transfer? Are there any transfer fees?

For both systems the answer is yes, and both have a very similar way of handling fees. They are even called the same! Each transfer, and more generally each invocation of a smart contract (a script manipulating the data in the blockchain) costs gas. How much gas, depends on how many operations the script performs. The more complex the script, the more costly it is to execute. That way, you pay for the computational power lended to you by the validators.

The amount of gas used is then translated to the native cryptocurrency — either ETH or the Libra coin — basing on the gas price. That price may fluctuate, depending on existing demand.

An important difference might be that currently, making a transaction on Ethereum is quite expensive. For a simple transfer, it’s about $0.02 (see ethgasstation.info), but can get much more expensive when running larger contracts.

Libra promises “low fees”, which is of course quite vague. However, given the ambition to become a global currency, we might expect these indeed to be low.

Transaction

The structure of the transaction is roughly the same in both systems. It consists of:

• a sender address, the account which invokes the transaction, and which will pay for the transaction
• the amount of ETH/Libra coin that the sender can pay for a single gas unit used by the invocation
• the maximum amount of gas that the invocation can use
• a per-account sequence number, protecting against replay attacks
• the code to invoke, along with arguments (if any)
• a signature, created using the sender’s private key

Performance

Existing blockchain technologies aren’t fast. You could even say, they are slow. Bitcoin can process 3–7 transactions per second, while Ethereum 15 tx/s. Libra promises 1000 tx/s — how is that possible?

The answer lies in the limited set of validators, which allows nodes to reach consensus faster.

Consensus is a central component of each blockchain. It’s the process during which miners or validators agree on which transactions to include in the database. This isn’t an easy task — it involves a lot of network communication between the nodes. Things get even more complicated, as some nodes might be rogue (Byzantine).

Ethereum is fully open, everybody can join, and everybody can become a miner (which corresponds to a validator in Libra). The network is much larger than the original 100 validator nodes of Libra: at the time of writing, there were about 8000 operating nodes. But that comes at a performance cost, which causes the network to have limited throughput.

Libra doesn’t have this problem, and caps the number of validator nodes. There are also minimum hardware requirements for a validator node. This means less network traffic, with more predictable latencies.

Programming the blockchain

Both Ethereum and Libra define their own programming languages to create smart contracts for their networks. Both of them have a high-level, human-readable component — Solidity in case of Ethereum, and Move in case of Libra — and both compile down to bytecode, which is then interpreted by a virtual machine.

However, the similarities end here. Although the Libra whitepaper draws parallels between Move and object-oriented languages, it’s really a different kind of language.

Move follows the model of functional languages, such as Haskell and OCaml, which strictly separate code and data.

On the other hand, Ethereum follows object-oriented languages, such as Java or C#. Here, the data is stored together with the code.

As an example, let’s see how we would implement a token, maybe for an ICO, on both platforms. On Ethereum, to create a token you need to deploy a smart contract, which contains:

1. a mapping between user addresses and the amount of tokens they own
2. code to transfer and manage tokens

To transfer a token to another user, we need to invoke the given smart contract. The code in the contract then updates its internal state (the mapping). If a token is popular, this internal state can grow very large — as all the data is contained inside the contract.

In Move, we would both deploy a new resource type (new data type) — corresponding to our token — and code, which would allow operating on the token. These two concepts are separate. To transfer a token, we would again invoke the smart contract. However, it would not update its internal state — as a contract does not have any state associated with it — but rather, move the resource from one account to another. The data belongs to the user’s account, not to the contract.

The Move virtual machine contains safety mechanisms, which prevents code from copying or modifying existing resources (that might be where the name comes from!). This guarantees that the coin — which is represented as a resource — cannot be manipulated at will, only as defined by the governing code.

Native currencies

The native currency of Ethereum is ETH, and the native currency of Libra is the Libra coin. This might sound as an implementation detail, but how integrated is the native currency into both systems?

In case of Ethereum, the concept of ETH is built right into the blockchain software itself. It’s a first-class concept, intrinsically bound to the system. The Ethereum virtual machine has special instructions, dealing with transfer of ETH.

In Libra, the case is quite different. The Libra coin is implemented as a smart contract — it’s not directly embedded in the blockchain software. There’s a special genesis transaction, which creates the “system” smart contracts. This makes the design much more general — and also opens possibilities to create other coins, which would operate very similarly to Libra.

There is in fact another coin in the system already — the Libra Investment Token. This coin is used to represent the validator’s stake in the association.

The Libra coin has however special status in one aspect — it is used to pay for transaction fees. That’s the same as in Ethereum. In both cases, the amount of gas you use to invoke a smart contract is deducted from your account in the native currency of the blockchain.

Libra tries to transfer as much logic as possible to the smart contract platform, and that doesn’t stop with the native coin implementation. The process of choosing the current validator set is also defined as a smart contract — and depends on votes granted basing on the already mentioned Libra Investment Tokens.

The value of the Libra coin

An important difference is that the Libra coin is designed to be a stable coin. It will be backed by a reserve in fiat money (definitely a lot of USD, other currencies probably as well). This means its value won’t fluctuate as much, but on the other hand, it won’t be an open and independent currency.

New Libra coins will be minted, and excess will be burnt, depending on the amount of money the members of the Libra Associated store in the reserve. This also means that the value of the coin will be tightly bound to the condition of the global economy. However, if the founding members are diverse enough, it might be independent from the state of the economy of a single country or a single fiat currency.

ETH, on the other hand, is fully open and independent. It’s not tied to any traditional currency, and doesn’t have any intrinsic “real-world” value (assuming that fiat currencies are in some aspect “real”). Which is definitely appealing, but also leads to speculation.

Managing funds

The blockchain is one thing, but how to manage funds? How to obtain the cryptocurrency?

Along with the Libra announcement, another one has been made as well — that Facebook will create the Calibra wallet, which will be operated by a company with the same name, owned by Facebook itself. Calibra will be a custodial wallet — which means that you won’t have to (or be able to?) manage the cryptographic keys yourself, and that you will have the option to recover lost passwords and hence regain lost funds.

Most expect that Calibra will be the main way through which the general public will interact with the blockchain.

Calibra will also be a way to obtain Libra coins. It will require providing the company with a government-issued ID, hence implementing the KYC (Know Your Client) and AML (Anti-Money Laundering) procedures.

This means that while the data on the Libra blockchain itself will be pseudonymous, there will be quite an easy way to bind your identity to the keys you use — through the Calibra wallet.

In Ethereum, there’s a wide range of wallets and exchanges, on which you can obtain the coins; the exchanges usually require a government-issued ID as well. The ETH cryptocurrency can however also be obtained by becoming a miner — and hence fully anonymously.

Authenticated reads

One of the areas in which Libra improves on the current state of the blockchain technology is verifying reads and proving that a certain transaction is indeed part of the blockchain.

In Ethereum, to get a guarantee that a certain transaction happened on the blockchain, it’s necessary to replay the whole history, starting from a trusted block, all the way until the given transaction.

Libra contains a mechanism of authenticated reads, using which it’s possible to obtain relatively short proofs (also based on Merkle trees), that a certain transaction has indeed been committed to the blockchain’s database.

Summary

Libra certainly draws a lot of inspiration from Ethereum and other blockchains, however it also adds a number of unique features and choices.

It has a permissioned, closed model, which on one hand doesn’t give the full decentralisation and openness of Ethereum, but on the other gives higher transaction throughput and lower fees.

It has an interesting data and smart contract programming model, inspired by functional programming. The fact that the Libra coin and the management of the validator set are not baked into the blockchain, but defined as smart contracts is very elegant.

Finally, Libra is at its early stages. There’s a testnet available, however many of the implementation details are yet to be fleshed out, including the high-level Move language representation. Moreover, initially developers won’t be able to publish their own smart contracts — only a pre-defined set will be allowed, governed by the Libra Association.

Libra is an interesting compromise between a fully decentralised blockchain network, and a centralised banking system. A lot of technical challenges are deferred for a later time, and there are even more challenges when it comes to regulatory compliance, setting up the reserve and governing the organisation.

But given the commercial backing, and the interesting technical design, it’s definitely worth paying close attention to Libra’s development!