Buried in Facebook’s Libra White Paper, a Digital Identity Bombshell: “I am over 18” credential … and more

The Takeaway

  • Facebook’s Libra white paper includes a brief but potentially seismic nod to digital identity standards.
  • With 2 billion users worldwide, Facebook may be able to succeed where others have failed in jump-starting a globally accepted digital ID.
  • Some identity experts say this is even more important than the cryptocurrency, but others question how much control Libra would give users and find its approach overbearing.
  • see below: The Libra Technical Whitepaper
  • see below: Libra White Paper Shows How Facebook Borrowed From Bitcoin and Ethereum
  • see below: The Libra Move Programming Language
  • see below: A Deep-Dive into Libra Move

Buried in Facebook’s Libra white paper are two short sentences hinting that the project’s ambitions go even further than bringing billions of people into the global financial system.

More than launching a price-stable cryptocurrency for the masses, Libra could be aiming to change the way people trust each other on the internet.

At the top of page nine, in a section describing the consortium that will govern the Libra coin, the white paper states:

“An additional goal of the association is to develop and promote an open identity standard. We believe that decentralized and portable digital identity is a prerequisite to financial inclusion and competition.”

That’s all the paper has to say on the topic of identity, perhaps explaining why the brief mention of such a foundational issue for 21st-century commerce escaped widespread notice despite all the hype over the document itself.

But to some observers, the line dropped like a bomb.

Dave Birch, director of Consult Hyperion and the author of books on digital identity and bitcoin, flagged these lines as “the most interesting” in the paper.

Smoothing pathways on the internet using identity is a bigger deal to many people than a putative cryptocurrency, Birch argued, adding:

“There are no throwaway remarks in a Facebook white paper that has taken a year to put together. It’s in there for a reason. [Facebook] are actually going to try and fix the identity problem.”

A Facebook spokeswoman said this week that the company had nothing to add about identity beyond what’s in the white paper.

Who are you?

It’s a problem almost as old as the internet itself. As the classic “New Yorker” cartoon put it, “on the internet, nobody knows you’re a dog.”

In such an environment, businesses need to guard against fraud, but the copious amounts of personal data consumers must share to prove they are who they say they are leaves them vulnerable to identity theft and spying.

Fixing this problem means finding a way to have the sort of credentials an individual holds in their physical wallet realized in a verifiable digital version which can be trusted across the internet. And for many technologists who have thought long and hard about identity, the solution must be “self-sovereign,” or controlled by the individual.

Birch, who has long seen the potential of social networks as natural springboards for managing digital identity, described a scenario where a user’s “I am over 18” credential (rather than their exact birthdate) is needed to log into a dating site.

This could be accessed through Libra’s cryptocurrency wallet Calibra via one of its partners, Mastercard, for example, with its two-factor authentication process. Then a cryptographic credential is sent back to Calibra containing no personally identifiable information but stating this person is over 18, which can then be presented to the dating site at log in.

While others have proposed similar arrangements (sometimes involving blockchains), none had the reach of Facebook, with its 2.38 billion users worldwide.

If Libra were “to drift in the direction of self-sovereign solutions, Facebook’s endorsement of that approach might make more of an impact on the market than, say, uPort or Evernym might have done,” Birch said, referring to two such blockchain ID startups.

And despite its reputation as the ultimate Peeping Tom, Facebook has hinted at such aspirations before. In February, while Libra was still under wraps, CEO Mark Zuckerberg said he was investigating blockchain’s potential to allow internet users to log in to various services via one set of credentials without relying on third parties.

Standard setting

Stepping back, technologists have been trying to address the challenge of identity for more than a decade by establishing open standards. In the same way that URLs, for example, open webpages anywhere on the internet, standards are also needed to ensure digital attributes about an individual can be universally issued and verified.

The OAuth standard, for example, is what let you log into websites through a third-party service like Facebook without sharing a password. More recently, such work under the auspices of the World Wide Web Consortium (W3C) has included things like Decentralized Identifiers (DIDs) and the verifiable credentials standard, both meant to enable self-sovereign digital identity.

Some veterans of this field were taken aback by the suggestion that the Libra Association (a group of 30 or so companies, expected to reach 100 or more) would develop an open identity standard.

“That’s very world domination-ish of them,” said Kaliya Young, a co-author of “A Comprehensive Guide to Self Sovereign Identity” and co-founder of the Internet Identity Workshop. “Some of us have been working on that problem for a really long time. You already have a set of open standards for verifiable credentials that are basically done and working.”

Young pointed out that “unilaterally declaring” an open standard belies the process of going through standards development with an open community, adding that all the people working on identity standards are connected to one another in reaching a common goal.

“That work is being led by a community of people deeply committed to there being no one company owning it in the end, because identity is too big to be owned, just like the web is too big to be owned,” she said.

(Indeed, Facebook was previously said to have rebuffed an invitation to participate in the DID project alongside Microsoft.)

Phil Windley, chair at the Sovrin Foundation, which contributed the codebase to the Hyperledger Indy blockchain ID project, acknowledged the risk of parsing two sentences in Libra’s paper too finely. But he made the point that “decentralized” and “portable” (Facebook’s words) are not exactly the same as self-sovereign.

“Decentralized” could simply mean a user’s identity data – their attributes and identifiers – are spread among nodes that are run on the Libra blockchain, said Windley. This doesn’t imply the user necessarily has control of them. Likewise, “portable” just means credentials can be moved from one place to another but doesn’t necessarily mean you get a say in how they are used.

Windley told CoinDesk:

“People often use ‘decentralized’ as an unalloyed gilt and just assume that it means everything is going to be great. That could be what they are doing here – just using ‘decentralized’ as a synonym for ‘awesome.’”

Joining the dots

That said, Windley was respectful about the scale of Libra’s vision, which he suspects is much bigger than dealing with know-your-customer (KYC) checks and the regulation around building a global permissioned currency platform.

He pointed to the paper’s authors which include many firms like Mastercard or Kiva, folks who have thought very hard about digital identity. (Neither company would comment on Libra’s approach to digital identity).

“I suspect given Libra’s goal of financial inclusion, they are probably thinking about it bigger than just authentication and authorization for a few narrow purposes,” said Windley. “I think there is enough there (e.g. the smart contract language) to believe a stablecoin is just one thing that they envisage using Libra for.”

In the absence of any detail on what might comprise a decentralized identity standard from Libra’s perspective, some dots can be joined by examining the recent work of George Danezis and his co-founders at Chainspace, a startup acquired by Facebook in May.

A paper introducing a “selective disclosure credential scheme” called Coconut explains how a system of smart contracts (computer programs that run on top of blockchains) could “issue user credentials depending on the state of the blockchain, or attest some claim about a user operating through the contract – such as their identity, attributes, or even the balance of their wallet.”

The Coconut protocol goes on to describe how credentials can be jointly issued in a decentralized manner by a group of “mutually distrusting authorities.” These credentials cannot be forged by users or a group of corrupt authorities, and are also “re-randomized” prior to being presented for verification to further protect user privacy. Unlike some computationally-hungry proving schemes, this is done in a matter of a few milliseconds making it highly scalable.

Returning to the question of standards, Birch said W3C, DIDs and verified credentials might be the right option for Libra, but whether it’s that or something else, basically whatever they choose would end up being a standard, he said, concluding:

And you could argue, is that necessarily a bad thing? I mean what happens if they come up with a good standard for identity and attributes and so on and then other people can use it, e.g. banks would be one obvious example.”




Libra White Paper Shows How Facebook Borrowed From Bitcoin and Ethereum

With the long-awaited Libra white paper, Facebook is showing off its blockchain smarts, and making a bid for crypto credibility.

Released Tuesday morning, the 29-page paper describes a protocol designed to evolve as it powers a new global currency. More than a year in the making, the document opens by trumpeting the new blockchain’s ambitious goal:

“The Libra Blockchain is a decentralized, programmable database designed to support a low-volatility cryptocurrency that will have the ability to serve as an efficient medium of exchange for billions of people around the world.”

As a first step toward achieving the “decentralized” part, the protocol has been turned over to a new organization, the Libra Association, whose members will hold separate tokens allowing them on-chain voting rights to govern decisions about Libra.

“Over time, it’s designed to transition the node membership from these founding members who have a stake in the creation of the ecosystem to people who hold Libra and have a stake in the ecosystem as a whole,” Ben Maurer, Facebook’s blockchain technical lead, told CoinDesk in an exclusive interview.

In short, Libra is designed to be a high throughput, global blockchain, one that’s built with programmable money in mind but limits how much users can do initially as it evolves from prototype to a robust ecosystem.

Unlike many other blockchains, Libra seems laser-focused on payments and other financial use cases for consumers.

But the white paper itself seems geared to demonstrate both Facebook’s proposed advances to the science of distributed consensus and its appreciation for what has been built so far.

Indeed, over the last several months, many sources told CoinDesk they had visited Facebook to share their perspective on decentralized technology. The company has done a lot of homework.

And now it has created a new language for writing commands on its blockchain, called Move, and opened its software to public inspection.

“To validate the design of the Libra protocol, we have built an open-source prototype implementation — Libra Core — in anticipation of a global collaborative effort to advance this new ecosystem,” the white paper states.

“It’d be sort of presumptuous for us to say we’re creating an open environment and then say, ‘Well, but we’ve set everything in stone,’” Maurer told CoinDesk. “It’s a paper that requests feedback.”

Mix and match

Libra’s designers have picked what they see as the best features of existing blockchains while providing their own updates and refinements.

1. Like bitcoin, there’s no real identity on the blockchain.

From the perspective of the blockchain itself, you don’t exist. Only public-private key pairs exist. The white paper states: “The Libra protocol does not link accounts to a real-world identity. A user is free to create multiple accounts by generating multiple key-pairs. Accounts controlled by the same user have no inherent link to each other.”

2. Like Hyperledger, it’s permissioned (at least to start).

Initially, the consensus structure for Libra will be dozens of organizations that will run nodes on the network, validating transactions. Each time consensus is voted on for a new set of transactions, a leader will be designated at random to count up the votes.

Libra opts to rely on familiarity rather than democracy to choose the right entities to establish consensus in the early days. “Founding Members are organizations with established reputations, making it unlikely that they would act maliciously,” the white paper states. These are entities range from traditional payment networks (Mastercard, Visa) to internet and gig-economy giants (eBay, Lyft) to blockchain natives (Xapo) to VCs (Andreessen Horowitz, Thrive Capital).

3. Like tezos, it comes with on-chain governance.

The only entities that can vote at the outset are Founding Members. These members hold Libra Investment Tokens that give them voting rights on the network, where they can make decisions about managing the reserve and letting new validators join the network.

The governance structure is built into the Move software from the start, and like Tezos it is subject to revision over time. Updates will be essential as it adds members and evolves from what’s more like a delegated proof-of-stake (DPoS) system (such as EOS or steem) to a fully decentralized proof-of-stake ecosystem.

4. Like ethereum, it makes currency programmable.

In a number of ways, the white paper defines interesting ways in which its users can interact with the core software and data structure. For example, anyone can make a non-voting replica of the blockchain or run various read commands associated with objects (such as smart contracts or a set of wallets) defined on Libra. Crucially, Libra’s designers seem to agree with ethereum’s that running code should have a cost, so all operations require payment of Libra as gas in order to run.

Unlike ethereum, Libra makes two important changes in its smart contracts. First, it limits how much users can do on the protocol at first (the full breadth of Move’s features are not yet open). Second, it breaks data out from software, so one smart contract (what Move refers to as a “module”) can be directed at any pool of assets, which Move calls “resources.” So one set of code can be used on any number of wallets or collections of assets.

5. Also like ethereum, it thinks proof-of-stake is the future, but it is also not ready yet.

“Over time, membership eligibility will shift to become completely open and based only on the member’s holdings of Libra,” the white paper promises, describing a path to real permissionless-ness.

Meanwhile, the paper dismisses the approach of the blockchains with the longest track record (namely bitcoin), stating, “We did not consider proof-of-work based protocols due to their poor performance and high energy (and environmental) costs.”

6. Like Binance’s coin, it does a lot of burning.

Blockchains that build in purposeful burning of tokens became very influential last year. Binance, the world’s leading exchange, created the BNB token, with which users could pay trading fees at a discount. Binance led the way to token bonfires, regularly burning a significant portion of its profits paid in BNB.

Libra won’t use burning to enhance the value of its coin. Rather (as with collateralized stablecoins such as tether), tokens will be issued and burned constantly, as the association responds to demand shifts for its reserve, with no supply maximum or minimum supply.

7. Like coda, users don’t need to hold onto the whole transaction history.

A lesser-known protocol, Coda, was one of the first to make its ledger disposable. Users only need to hold a proof of the last block, which they can easily check on a smartphone to be sure they are interacting with a valid ledger.

Similarly, on Libra, “historical data may grow beyond the amount that can be handled by an individual server. Validators are free to discard historical data not needed to process new transactions.”

8. Like EOS, it hasn’t worked everything out yet.

EOS launched without its approach to governance well defined, which yielded complications down the road. Similarly, Libra promises to decentralize, but there’s nothing that inherently forces its members to do so.

Work in progress

Other matters are left undecided as well. For example, the storage of data.

“We anticipate that as the system is used, eventually storage growth associated with accounts may become a problem,” the white paper says. The document anticipates but does not define a system of rent for data storage.

It cites a number of examples of other open questions, such as how best to maintain security as more validators join the network, how often the pool of validators can change and how modules can be updated safely.

As the paper admits:

“This paper is the first step toward building a technical infrastructure to support the Libra ecosystem. We are publishing this early report to seek feedback from the community on the initial design, the plans for evolving the system, and the currently unresolved research challenges discussed in the proposal.”

Dream team

The Libra white paper is signed by 53 people. Though senior Facebook executives such as CEO Mark Zuckerberg and blockchain lead David Marcus are notably absent from the author list, the team that wrote the document looks to be one of the most-heavy hitting in blockchain history.

The signatories hail from nearly every continent and include Ph.D. students from Stanford, computer science professors, and artificial intelligence (AI) developers.

They include:

  • Christian Catalini: The MIT professor was one of the first to study the economics of cryptocurrency alongside crowdfunding and tokenization. Catalini has written extensively for the Harvard Business Review and other publications.
  • Ben Maurer: Facebook’s infrastructure engineer graduated from Carnegie Mellon University with a degree in computer science. He and CMU assistant professor Luis von Ahn built the reCAPTCHA service that Google bought in 2009. He is leading the team that built the Move programming language.
  • George Danezis: A privacy engineer at University College London, Danezis was one of the creators of Chainspace and the Coconut protocol upon which Libra is based. He is currently a researcher at Facebook after the company bought his startup in February 2019.
  • François Garillot: A machine-learning and AI expert who worked at Swisscom and, Garillot focuses on distributed AI.
  • Ramnik Arora: Arora spent time as an analyst at Goldman Sachs Investment Strategy Group as well as at IV Capital as a quant. His background is in finance and he has a master’s in computer science from Stanford and an undergraduate degree in the mathematics of finance.





The Facebook Libra Technical Whitepaper

see also:

Introducing Libra

The world truly needs a reliable digital currency and infrastructure that together can deliver on the promise of “the internet of money.”

Securing your financial assets on your mobile device should be simple and intuitive. Moving money around globally should be as easy and cost-effective as — and even more safe and secure than — sending a text message or sharing a photo, no matter where you live, what you do, or how much you earn. New product innovation and additional entrants to the ecosystem will enable the lowering of barriers to access and cost of capital for everyone and facilitate frictionless payments for more people.

Now is the time to create a new kind of digital currency built on the foundation of blockchain technology. The mission for Libra is a simple global currency and financial infrastructure that empowers billions of people. Libra is made up of three parts that will work together to create a more inclusive financial system:

  1. It is built on a secure, scalable, and reliable blockchain;
  2. It is backed by a reserve of assets designed to give it intrinsic value;
  3. It is governed by the independent Libra Association tasked with evolving the ecosystem.

The Libra currency is built on the “Libra Blockchain.” Because it is intended to address a global audience, the software that implements the Libra Blockchain is open source — designed so that anyone can build on it, and billions of people can depend on it for their financial needs. Imagine an open, interoperable ecosystem of financial services that developers and organizations will build to help people and businesses hold and transfer Libra for everyday use. With the proliferation of smartphones and wireless data, increasingly more people will be online and able to access Libra through these new services. To enable the Libra ecosystem to achieve this vision over time, the blockchain has been built from the ground up to prioritize scalability, security, efficiency in storage and throughput, and future adaptability. Keep reading for an overview of the Libra Blockchain, or read the technical paper.

The unit of currency is called “Libra.” Libra will need to be accepted in many places and easy to access for those who want to use it. In other words, people need to have confidence that they can use Libra and that its value will remain relatively stable over time. Unlike the majority of cryptocurrencies, Libra is fully backed by a reserve of real assets. A basket of bank deposits and short-term government securities will be held in the Libra Reserve for every Libra that is created, building trust in its intrinsic value. The Libra Reserve will be administered with the objective of preserving the value of Libra over time. Keep reading for an overview of Libra and the reserve, or read more here.

The Libra Association is an independent, not-for-profit membership organization headquartered in Geneva, Switzerland. The association’s purpose is to coordinate and provide a framework for governance for the network and reserve and lead social impact grant-making in support of financial inclusion. This white paper is a reflection of its mission, vision, and purview. The association’s membership is formed from the network of validator nodes that operate the Libra Blockchain.

Members of the Libra Association will consist of geographically distributed and diverse businesses, nonprofit and multilateral organizations, and academic institutions. The initial group of organizations that will work together on finalizing the association’s charter and become “Founding Members” upon its completion are, by industry:

  • Payments: Mastercard, Mercado Pago, PayPal, PayU (Naspers’ fintech arm), Stripe, Visa
  • Technology and marketplaces: Booking Holdings, eBay, Facebook/Calibra, Farfetch, Lyft, Spotify AB, Uber Technologies, Inc.
  • Telecommunications: Iliad, Vodafone Group
  • Blockchain: Anchorage, Bison Trails, Coinbase, Inc., Xapo Holdings Limited
  • Venture Capital: Andreessen Horowitz, Breakthrough Initiatives, Ribbit Capital, Thrive Capital, Union Square Ventures
  • Nonprofit and multilateral organizations, and academic institutions: Creative Destruction Lab, Kiva, Mercy Corps, Women’s World Banking

We hope to have approximately 100 members of the Libra Association by the target launch in the first half of 2020.

Facebook teams played a key role in the creation of the Libra Association and the Libra Blockchain, working with the other Founding Members. While final decision-making authority rests with the association, Facebook is expected to maintain a leadership role through 2019. Facebook created Calibra, a regulated subsidiary, to ensure separation between social and financial data and to build and operate services on its behalf on top of the Libra network.

Once the Libra network launches, Facebook, and its affiliates, will have the same commitments, privileges, and financial obligations as any other Founding Member. As one member among many, Facebook’s role in governance of the association will be equal to that of its peers.

Blockchains are described as either permissioned or permissionless in relation to the ability to participate as a validator node. In a “permissioned blockchain,” access is granted to run a validator node. In a “permissionless blockchain,” anyone who meets the technical requirements can run a validator node. In that sense, Libra will start as a permissioned blockchain.

To ensure that Libra is truly open and always operates in the best interest of its users, our ambition is for the Libra network to become permissionless. The challenge is that as of today we do not believe that there is a proven solution that can deliver the scale, stability, and security needed to support billions of people and transactions across the globe through a permissionless network. One of the association’s directives will be to work with the community to research and implement this transition, which will begin within five years of the public launch of the Libra Blockchain and ecosystem.

Essential to the spirit of Libra, in both its permissioned and permissionless state, the Libra Blockchain will be open to everyone: any consumer, developer, or business can use the Libra network, build products on top of it, and add value through their services. Open access ensures low barriers to entry and innovation and encourages healthy competition that benefits consumers. This is foundational to the goal of building more inclusive financial options for the world.



Move, a safe and flexible programming language for the Libra Blockchain

Whitepaper Deep Dive — Move: Facebook Libra Blockchain’s New Programming Language

Key characteristics of Move and How it differentiates with Ethereum from a developer’s perspective

Overview & Motivation

This is a walkthrough of the 26 pages technical whitepaper of Move, Facebook Libra’s new programming language. As an Ethereum developer and a blockchain community enthusiast, I hope to provide a quick overview and highlights of the paper for everyone curious about this new language :)

Hope that you will like it, happy learning!


Move is an executable bytecode language used to implement custom transactions and smart contracts.

There’re two things to take note:

  1. While Move is a bytecode language which can be directly executed in Move’s VM, Solidity (Ethereum’s smart contract language) is a higher level language that needs to be compiled down to bytecode before executing in EVM (Ethereum’s Virtual Machine).
  2. Move can not only be used to implement smart contracts but also custom transactions (explained later in the article), while Solidity is a language for smart contracts on Ethereum only.

The key feature of Move is the ability to define custom resource types with semantics inspired by linear logic: a resource can never be copied or implicitly discarded, only moved between program storage locations.

This is a feature similar to Rust. Values in Rust can only be assigned to one name at a time. Assigning a value to a different name causes it to no longer be accessible under the previous name.

For example, the following code snippet will output the error: Use of moved value ‘x’. This is because Rust has no garbage collection. When variables go out of scope, the memory they refer to is also deallocated. For simplicity, we can understand this as there can only be one “owner” of data at a time. In this example, x is the original owner, and then y becomes the owner.




2.2 Encoding Digital Assets in an Open System

There are two properties of physical assets that are difficult to encode in digital assets:
• Scarcity. The supply of assets in the system should be controlled. Duplicating existing assets should be prohibited, and creating new assets should be a privileged operation.
• Access control. A participant in the system should be able to protect her assets with access control policies.

It points out two major characteristics that digital assets need to achieve, which are considered natural for physical assets. For example, rare metal is naturally scarce, and only you have the access (ownership) of the bill in your hand before spending it.

To illustrate how we came up with the two properties, let’s start with the following proposals:

Proposal#1: Simplest Rule Without Scarcity and Access Control

The simplest state evaluation rule without scarcity and access control.


  • G[K]:=n denotes updating the number stored at key 𝐾 in the global blockchain state with the value 𝑛.
  • transaction ⟨Alice, 100⟩ means set Alice’s account balance to 100.

The above representation has serval serious problems:

  • Alice can have unlimited coins by sending transaction ⟨Alice, 100⟩ herself.
  • The coins that Alice sends to Bob are worthless since Bob could send himself unlimited coins using the same technic as well.

Proposal#2: Taking Scarcity into Account

The second proposal that takes scarcity into account


Now we enforce that the number of coins stored under 𝐾𝑎 is at least 𝑛 before the transfer takes place.

However, though this solves the scarcity issue, there’s no ownership checking on who can send Alice’s coins. (anyone can do so under this evaluation rule)

Proposal#3: Considering both Scarcity and Access Control


The third that considers both scarcity and access control


We address the problem by using digital signature mechanism verify_sig before the scarcity checking, which means Alice uses her private key to sign the transaction and prove that she is the owner of her coin.

2.3. Existing Blockchain Languages

Existing blockchain languages are facing the following problems (all of them have been solved in Move):

1. Indirect representation of assets. An asset is encoded using an integer, but an integer value is not the same thing as an asset. In fact, there is no type or value that represents Bitcoin/Ether/StrawCoin! This makes it awkward and error-prone to write programs that use assets. Patterns such as passing assets into/out of procedures or storing assets in data structures require special language support.

2. Scarcity is not extensible. The language only represents one scarce asset. In addition, the scarcity protections are hardcoded directly in the language semantics. A programmer that wishes to create a custom asset must carefully reimplement scarcity with no support from the language.

These are exactly the problems in Ethereum smart contracts. Custom assets such as ERC-20 tokens use integer to represent its value and its total supply. Whenever new tokens are minted, the smart contract code has to manually check if the scarcity (total supply in this case) has been reached.

Furthermore, serious bugs such as duplication, reuse, or loss of assets, are more likely to be introduced due to the Indirect representation of asset problem.

3. Access control is not flexible. The only access control policy the model enforces is the signature scheme based on the public key. Like the scarcity protections, the access control policy is deeply embedded in the language semantics. It is not obvious how to extend the language to allow programmers to define custom access control policies.

This is also true in Ethereum, where smart contracts do not have native language support for the public-private key cryptography to do access control. Developers have to manually write access control such as using OnlyOwner.

Despite that I’m a big fan of Ethereum, I agree that these asset properties should be natively supported by the language for safety purposes.

In particular, transferring Ether to a smart contract involves dynamic dispatch, which has led to a new class of bugs known as re-entrancy vulnerabilities

Dynamic dispatch here means that the code execution logic will be determined at runtime (dynamic) instead of compile time (static). Thus in Solidity, when contract A calls contract B’s function, contract B can run code that was unanticipated by contract A’s designer, which can lead to re-entrancy vulnerabilities (contract A accidentally executes contract B’s function to withdraw money before actually deducting balances from the account).

3. Move Design Goals

3.1. First-Class Resources

At a high level, the relationship between modules/resources/procedures in Move is similar to the relationship between classes/objects/methods in object-oriented programming.
Move modules are similar to smart contracts in other blockchain languages. A module declares resource types and procedures that encode the rules for creating, destroying, and updating its declared resources.

The modules/resources/procedures are just some jargons in Move. We will have an example to illustrate these later in this article;)

3.2. Flexibility

Move adds flexibility to Libra via transaction scripts. Each Libra transaction includes a transaction script that is effectively the main procedure of the transaction.

The scripts can perform either expressive one-off behaviors (such as paying a specific set of recipients) or reusable behaviors (by invoking a single procedure that encapsulates the reusable logic)

From the above, we can see that Move’s transaction script introduces more flexibility since it is capable of one-off behaviors as well as reusable behaviors, while Ethereum can only perform reusable behaviors (which is invoking a single smart contract method). The reason why it’s named “reusable” is that smart contract functions can be executed multiple times.

3.3. Safety

The executable format of Move is a typed bytecode that is higher-level than assembly yet lower-level than a source language. The bytecode is checked on-chain for resource, type, and memory safety by a bytecode verifier and then executed directly by a bytecode interpreter. This choice allows Move to provide safety guarantees typically associated with a source language, but without adding the source compiler to the trusted computing base or the cost of compilation to the critical path for transaction execution.

This is indeed a very neat design for Move to be a bytecode language. Since it doesn’t need to be compiled from the source to bytecode like Solidity, it doesn’t have to worry about the possible failures or attacks in compilers.

3.4. Verifiability

Our approach is to perform as much lightweight on-chain verification of key safety properties as possible, but design the Move language to support advanced off-chain static verification tools.

From here we can see that Move prefers performing static verification instead of doing on-chain verification work. Nonetheless, as stated at the end of their paper, the verification tool is left for future work.

3. Modularity. Move modules enforce data abstraction and localize critical operations on resources. The encapsulation enabled by a module combined with the protections enforced by the Move type system ensures that the properties established for a module’s types cannot be violated by code outside the module.

This is also a very well thought data abstraction design! which means that the data in a smart contract can only be modified within the contract scope but not other contracts from the outside.



4. Move Overview

The example transaction script demonstrates that a malicious or careless programmer outside the module cannot violate the key safety invariants of the module’s resources.

This section walks you through an example about what modules, resources, and procedures actually is when writing the programming language.

4.1. Peer-to-Peer Payment Transaction Script

The amount of coins will be transferred from the transaction sender to payee


There are several new symbols here (The small red text is my own notes XD):

  • 0x0: the account address where the module is stored
  • Currency: the name of the module
  • Coin: the resource type
  • The value coin returned by the procedure is a resource value whose type is 0x0.Currency.Coin
  • move(): the value can not be used again
  • copy(): the value can be used later

Code breakdown:

In the first step, the sender invokes a procedure named withdraw_from_sender from the module stored at 0x0.Currency.

In the second step, the sender transfers the funds to payee by moving the coin resource value into the 0x0.Currency module’s deposit procedure.

Here are 3 types of code examples that will be rejected:

1. Duplicating currency by changing move(coin) to copy(coin)

Resource values can only be moved. Attempting to duplicate a resource value (e.g., using copy(coin) in the example above) will cause an error at bytecode verification time.

Because coin is a resource value, it can only be moved.

2. Reusing currency by writing move(coin) twice

Adding the line 0x0.Currency.deposit(copy(some_other_payee), move(coin)) to the example above would let the sender “spend” coin twice — the first time with payee and the second with some_other_payee. This undesirable behavior would not be possible with a physical asset. Fortunately, Move will reject this program.

3. Losing currency by neglecting to move(coin)

Failing to move a resource (e.g., by deleting the line that contains move(coin) in the example above) will trigger a bytecode verification error. This protects Move programmers from accidentally — or intentionally — losing track of the resource.

4.2. Currency Module

4.2.1 Primer: Move execution model


Each account can contain zero or more modules (depicted as rectangles) and one or more resource val- ues (depicted as cylinders). For example, the account at address 0x0 contains a module 0x0.Currency and a resource value of type 0x0.Currency.Coin. The account at address 0x1 has two resources and one module; the account at address 0x2 has two modules and a single resource value.

Some highlights:

  • Executing a transaction script is all-or-nothing
  • A module is a long-lived piece of code published in the global state
  • The global state is structured as a map from account addresses to accounts
  • Accounts can contain at most one resource value of a given type and at most one module with a given name (The account at address 0x0 would not be allowed to contain an additional 0x0.Currency.Coin resource or another module named Currency)
  • The address of the declaring module is part of the type (0x0.Currency.Coin and 0x1.Currency.Coin are distinct types that cannot be used interchangeably)
  • Programmers can still hold multiple instances of a given resource type in an account by defining a custom wrapper resource

(resource TwoCoins { c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin })

  • The rule is it is ok as long as you can still reference the resource by its name without having conflicts, for example, you can reference the two resources using TwoCoins.c1 and TwoCoins.c2.

4.2.2 Declaring the Coin Resource

A module named Currency and a resource type named Coin that is managed by the module

Some highlights:

  • A Coin is a struct type with a single field value of type u64 (a 64-bit unsigned integer)
  • Only the procedures of the Currency module can create or destroy values of type Coin
  • Other modules and transaction scripts can only write or reference the value field via the public procedures exposed by the module

4.2.3 Implementing Deposit

This procedure takes a Coin resource as input and combines it with the Coin resource stored in the payee’s account by:
1. Destroying the input Coin and recording its value.
2. Acquiring a reference to the unique Coin resource stored under the payee’s account.
3. Incrementing the value of payee’s Coin by the value of the Coin passed to the procedure.

Some highlights:

  • Unpack, BorrowGlobal are builtin procedures
  • Unpack<T> is the only way to delete a resource of type T. It takes a resource of type T as input, destroys it, and returns the values bound to the fields of the resource
  • BorrowGlobal<T> takes an address as input and returns a reference to the unique instance of T published under that address
  • &mut Coin is a mutable reference to a Coin resource, not Coin

4.2.4 Implementing withdraw_from_sender

This procedure:

1. Acquires a reference to the unique resource of type Coin published under the sender’s account.
2. Decreases the value of the referenced Coin by the input amount.
3. Creates and returns a new Coin with value amount.

Some highlights:

  • Deposit can be called by anyone but withdraw_from_sender has access control to only be callable by the owner of coin
  • GetTxnSenderAddress is similar to Solidity’s msg.sender
  • RejectUnless is similar to Solidity’s require. If this check fails, execution of the current transaction script halts and none of the operations it performed will be applied to the global state
  • Pack<T>, also a builtin procedure, creates a new resource of type T
  • Like Unpack<T>, Pack<T> can only be invoked inside the declaring module of resource T

Wrap up

Now that you have an overview of what is the main characteristics of Move, how it compares to Ethereum, and also familiar with its basic syntax.

Lastly, I highly recommend reading through the original white paper. It includes a lot of details regarding the programming language design principles behind and many great references.

Thank you so much for your time reading. Feel free to share this with someone who might be interested :) Any suggestions are also welcomed!!




*** -OR-