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.”

from: https://www.coindesk.com/buried-in-facebooks-cryptocurrency-white-paper-a-digital-identity-bombshell

***

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 Skymind.ai, 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.

from: https://www.coindesk.com/libra-white-paper-shows-how-facebook-borrowed-from-bitcoin-and-ethereum

***

The Facebook Libra Technical Whitepaper

see also: https://developers.libra.org/docs/the-libra-blockchain-paper
https://developers.libra.org/docs/assets/papers/the-libra-blockchain.pdf

Introducing Libra

from: https://libra.org/en-US/white-paper/#introducing-libra

***

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!

Abstract

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

• 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

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

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

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

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!!

from: https://medium.com/coinmonks/whitepaper-deep-dive-move-facebook-libra-blockchains-new-programming-language-7dbd5b242c2b

***