没有合适的资源?快使用搜索试试~ 我知道了~
首页Facebook加密货币项目Libra技术白皮书(英文版).pdf
The Libra Blockchain is a decentralized, programmable database designed to support a low-volatility cryptocurrency that will have the ability to serve as an efcient medium of exchange for billions of people around the world. We present a proposal for the Libra protocol, which implements the Libra Blockchain and aims to create a financial infrastructure that can foster innovation, lower barriers to entry, and improve access to financial services. 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 Libra Blockchain
Zachary Amsden, Ramnik Arora, Shehar Bano, Mathieu Baudet, Sam Blackshear, Abhay Bothra, George Cabrera,
Christian Catalini, Konstantinos Chalkias, Evan Cheng, Avery Ching, Andrey Chursin, George Danezis,
Gerardo Di Giacomo, David L. Dill, Hui Ding, Nick Doudchenko, Victor Gao, Zhenhuan Gao, François Garillot,
Michael Gorven, Philip Hayes, J. Mark Hou, Yuxuan Hu, Kevin Hurley, Kevin Lewi, Chunqi Li, Zekun Li, Dahlia Malkhi,
Sonia Margulis, Ben Maurer, Payman Mohassel, Ladi de Naurois, Valeria Nikolaenko, Todd Nowacki, Oleksandr Orlov,
Dmitri Perelman, Alistair Pott, Brett Proctor, Shaz Qadeer, Rain, Dario Russi, Bryan Schwab, Stephane Sezer,
Alberto Sonnino, Herman Venter, Lei Wei, Nils Wernerfelt, Brandon Williams, Qinfan Wu, Xifan Yan, Tim Zakian,
Runtian Zhou
*
Abstract. The Libra Blockchain is a decentralized, programmable database designed to support a
low-volatility cryptocurrency that will have the ability to serve as an ecient medium of exchange for
billions of people around the world. We present a proposal for the Libra protocol, which implements
the Libra Blockchain and aims to create a nancial infrastructure that can foster innovation, lower
barriers to entry, and improve access to nancial services. To validate the design of the Libra protocol,
we have built an open-source prototype implementation — Libra Core — in anticipation of a global
collaborative eort to advance this new ecosystem.
The Libra protocol allows a set of replicas — referred to as validators — from dierent authorities
to jointly maintain a database of programmable resources. These resources are owned by dierent
user accounts authenticated by public key cryptography and adhere to custom rules specied by the
developers of these resources. Validators process transactions and interact with each other to reach
consensus on the state of the database. Transactions are based on predened and, in future versions,
user-dened smart contracts in a new programming language called Move.
We use Move to dene the core mechanisms of the blockchain, such as the currency and validator
membership. These core mechanisms enable the creation of a unique governance mechanism that
builds on the stability and reputation of existing institutions in the early days but transitions to a
fully open system over time.
1 Introduction
The spread of the internet and resulting digitization of products and services have increased eciency,
lowered barriers to entry, and reduced costs across most industries. This connectivity has driven
economic empowerment by enabling more people to access the nancial ecosystem. Despite this
progress, access to nancial services is still limited for those who need it most — impacted by cost,
reliability, and the ability to seamlessly send money.
This paper presents a proposal for the Libra protocol, which supports the newly formed Libra ecosys-
tem that seeks to address these challenges, expand access to capital, and serve as a platform for
innovative nancial services. This ecosystem will oer a new global currency — the Libra coin —
which will be fully backed with a basket of bank deposits and treasuries from high-quality central
∗
The authors work at Calibra, a subsidiary of Facebook, Inc., and contribute this paper to the Libra Association under
a Creative Commons Attribution 4.0 International License. For more information on the Libra ecosystem, please refer
to the Libra white paper [1].
1
banks. All of these currencies experience relatively low ination, and thus the coin mechanically
inherits this property as well as the advantages of a geographically diversied portfolio of assets. The
Libra protocol must scale to support the transaction volume necessary for this currency to grow into a
global nancial infrastructure and provide the exibility to implement the economic and governance
policies that support its operations. The Libra protocol is designed from the ground up to holisti-
cally address these requirements and build on the learnings from existing projects and research — a
combination of novel approaches and well-understood techniques.
A key prerequisite for healthy competition and innovation in nancial services is the ability to rely
on common infrastructure for processing transactions, maintaining accounts, and ensuring interoper-
ability across services and organizations. By lowering barriers to entry and switching costs, the Libra
protocol will enable startups and incumbents to compete on a level playing eld, and experiment
with new types of business models and nancial applications. Blockchain technology lends itself well
to address these issues because it can be used to ensure that no single entity has control over the
ecosystem or can unilaterally shape its evolution to its advantage [2].
The Libra Blockchain will be decentralized, consisting of a collection of validators that work together
to process transactions and maintain the state of the blockchain. These validators also form the
membership of the Libra Association, which will provide a framework for the governance of the
network and the reserve that backs the coin. Initially, the association (and validators) will consist of
a geographically distributed and diverse set of Founding Members. These members are organizations
chosen according to objective participation criteria, including that they have a stake in bootstrapping
the Libra ecosystem and investing resources toward its success. Over time, membership eligibility will
shift to become completely open and based only on the member’s holdings of Libra. The association
has published reports outlining its vision [1], its proposed structure [3], the coin’s economics [4], and
the roadmap for the shift toward a permissionless system [5].
This paper is the rst 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. Thus, the association has established an open-source community [6] for the discussion and
development of the project.
The Libra protocol. The Libra Blockchain is a cryptographically authenticated database [7, 8, 9]
maintained using the Libra protocol. The database stores a ledger of programmable resources, such
as Libra coins. A resource adheres to custom rules specied by its declaring module, which is also
stored in the database. A resource is owned by an account that is authenticated using public key
cryptography. An account could represent direct end users of the system as well as entities, such as
custodial wallets, that act on behalf of their users. An account’s owner can sign transactions that
operate on the resources held within the account.
Figure 1 shows the two types of entities that interact using the Libra protocol: (1) validators, which
maintain the database and (2) clients, which perform queries on the database and submit transactions
to modify it.
1
validators
client
other validators
2
45
leader
execution
3
execution
3
Figure 1: Overview of the Libra protocol.
2
Validators maintain the database and process transactions submitted by clients for inclusion in the
database (
1
). The validators use a distributed consensus protocol to agree on an ever-growing list
of transactions that have been committed to the database as well as the results of executing those
transactions. This consensus protocol must be reliable even in the presence of malicious or erroneous
behavior by a minority of validators. Validators take turns driving the process of accepting transac-
tions. When a validator acts as a leader, it proposes transactions, both those directly submitted to it
by clients and those indirectly submitted through other validators, to the other validators (
2
). All
validators execute the transactions ( 3 ) and form an authenticated data structure that contains the
new ledger history. The validators vote on the authenticator for this data structure as part of the
consensus protocol ( 4 ). As part of committing a transaction T
i
at version i, the consensus protocol
outputs a signature on the full state of the database at version i — including its entire history — to
authenticate responses to queries from clients (
5
).
Clients can issue queries to a validator to read data from the database. Since the database is authen-
ticated, clients can be assured of the accuracy of the response to their query. As part of the response
to a read query, a validator returns a signed authenticator for the latest version i of the database
known to the validator.
In addition, a client can optionally create a replica of the entire database by synchronizing the
transaction history from the validators. While creating a replica, a client can verify that validators
executed transactions correctly, which increases accountability and transparency in the system. Other
clients can read from a client that holds a replica in the same way they would read from a validator
to verify the authenticity of the response. For the sake of simplicity, the rest of this paper assumes
that clients query a validator directly rather than a replica.
Organization. This paper discusses the components of the Libra protocol:
• Logical Data Model (Section 2) describes the logical data model that organizes the decen-
tralized database visible to validators and clients.
• Executing Transactions (Section 3) describes the use of Move [10], a new programming
language that is used to dene and execute database transactions.
• Authenticated Data Structures and Storage (Section 4) describes the mapping of the
logical model into authenticated data structures based on Merkle trees [11].
• Byzantine Fault Tolerant Consensus (Section 5) describes the LibraBFT [12] variant of the
HotStu protocol [13], which allows a network with potentially malicious validators to maintain
a single, consistent database by executing transactions with Move and coming to agreement on
their execution using the authenticated data structures.
• Networking (Section 6) describes the protocol that enables validators to communicate with
each other securely, as required for consensus.
Subsequently, we present the open-source Libra Core prototype [6]. Section 7 discusses how Libra
Core combines the components of the Libra protocol to process a transaction. Section 8 discusses
performance considerations.
Finally, we explain how the protocol is being used to support the economic stability and governance
policies of the Libra ecosystem. Section 9 shows how we use the Move language to implement the low-
volatility, reserve-backed Libra coin and a validator management system that mirrors the governance
of the Libra Association.
Section 10 concludes the paper with a discussion of future plans and ongoing challenges for the Libra
ecosystem.
3
2 Logical Data Model
All data in the Libra Blockchain is stored in a single versioned database [14, 15]. A version number is
an unsigned 64-bit integer that corresponds to the number of transactions the system has executed. At
each version i, the database contains a tuple (T
i
, O
i
, S
i
) representing the transaction (T
i
), transaction
output (O
i
), and ledger state (S
i
). Given a deterministic execution function Apply, the meaning of
the tuple is: executing transaction T
i
against ledger state S
i−1
produces output O
i
and a new ledger
state S
i
; that is, Apply(S
i−1
, T
i
) → ⟨O
i
, S
i
⟩.
The Libra protocol uses the Move language to implement the deterministic execution function (see
Section 3). In this section, we focus on the versioned database, which allows validators to:
1. Execute a transaction against the ledger state at the latest version.
2. Respond to client queries about the ledger history at both current and previous versions.
We rst explain the structure of the ledger state stored in a single version and then discuss the
purpose of the versioned ledger history view.
2.1 Ledger State
The ledger state represents the ground truth about the Libra ecosystem, including the quantity of
Libra held by each user at a given version. Each validator must know the ledger state at the latest
version in order to execute new transactions.
The Libra protocol uses an account-based data model [16] to encode the ledger state. The state is
structured as a key-value store, which maps account address keys to account values. An account value
in the ledger state is a collection of published Move resources and modules. The Move resources store
data values and modules store code. The initial set of accounts and their state are specied in the
genesis ledger state (see Section 3.1).
Account addresses. An account address is a 256-bit value. To create a new account, a user
rst generates a fresh verication/signature key-pair (vk, sk ) for a signature scheme and uses the
cryptographic hash of the public verication key vk as an account address a = H(vk).
1
The new
account is created in the ledger state when a transaction sent from an existing account invokes the
create_account(a) Move instruction. This typically happens when a transaction attempts to send
Libra to an account at address a that has not yet been created.
Once the new account is created at a, the user can sign transactions to be sent from that account
using the private signing key sk . The user can also rotate the key used to sign transactions from the
account without changing its address, e.g., to proactively change the key or to respond to a possible
compromise of the key.
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. This scheme follows the example of Bitcoin and Ethereum in that it provides
pseudonymity [19] for users.
Resource values. A resource value, or resource, is a record that binds named elds to simple values
— such as integers — or complex values — such as other resources embedded inside this resource.
1
Concretely we instantiate hash functions with SHA3-256 [17] and digital signatures with EdDSA using the ed-
wards25519 curve [18].
4
Currency.T
Currency.T
StateChannel.T
Currency.TCurrency
StateChannel
Account ContentAddress
0x12…
0x34…
0x56…
0x78…
Figure 2: An example ledger state with four accounts. In this diagram, ovals represent resources and rectangles
represent modules. A directed edge from a resource to a module means that the type of the resource
was declared by that module. The account at address 0x12 contains a Currency.T resource declared
by the Currency module. The code for the Currency module is stored at address 0x56. The account
at address 0x34 contains both a Currency.T resource and a StateChannel.T resource, which is
declared by the module stored at address 0x78.
Every resource has a type declared by a module. Resource types are nominal types [20] that consist
of the name of the type and the name and address of the resource’s declaring module. For example,
the type of the Currency.T resource in Figure 2 is 0x56.Currency.T. Here, 0x56 is the address where
the Currency module is stored, Currency is the name of the module, and Currency.T is the name
of the resource.
To retrieve the resource 0x56.Currency.T under account address 0x12, a client would request
0x12/resources/0x56.Currency.T. The purpose of this design is to let modules dene a predictable
schema for top-level account values — that is, every account stores its 0x56.Currency.T resource un-
der the same path. As such, each account can store at most one resource of a given type. However, this
limitation is not restrictive, since programmers can dene wrapper resources that organize resources
in a custom way (e.g., resource TwoCoin { c1: 0x56.Currency.T, c2: 0x56.Currency.T }).
The rules for mutating, deleting, and publishing a resource are encoded in the module that created
the resource and declared its type. Move’s safety and verication rules prevent other code from
making modications to the resource.
Module values. A module value, or module, contains Move bytecode that declares resource types
and procedures (see Section 3.4 for more details). Like a resource type, a module is identied by the
address of the account where the module is declared. For example, the identier for the Currency
module in Figure 2 is 0x56.Currency.
A module must be uniquely named within an account — each account can declare at most one
module with a given name. For example, the account at address 0x56 in Figure 2 could not declare
another module named Currency. On the other hand, the account at address 0x34 could declare
a module named Currency. The identier of this module would be 0x34.Currency. Note that
0x56.Currency.T and 0x34.Currency.T are distinct types and cannot be used interchangeably.
5
剩余28页未读,继续阅读
jamin_liu_91
- 粉丝: 43
- 资源: 44
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- ExcelVBA中的Range和Cells用法说明.pdf
- 基于单片机的电梯控制模型设计.doc
- 主成分分析和因子分析.pptx
- 共享笔记服务系统论文.doc
- 基于数据治理体系的数据中台实践分享.pptx
- 变压器的铭牌和额定值.pptx
- 计算机网络课程设计报告--用winsock设计Ping应用程序.doc
- 高电压技术课件:第03章 液体和固体介质的电气特性.pdf
- Oracle商务智能精华介绍.pptx
- 基于单片机的输液滴速控制系统设计文档.doc
- dw考试题 5套.pdf
- 学生档案管理系统详细设计说明书.doc
- 操作系统PPT课件.pptx
- 智慧路边停车管理系统方案.pptx
- 【企业内控系列】企业内部控制之人力资源管理控制(17页).doc
- 温度传感器分类与特点.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0