Diem(原Libra)学习笔记

一、介绍

1. diem目标:

• 实现一个能够承载数十亿的账户的区块链系统，这个系统需要由 高吞吐量，低延迟 的交易能力以及一个高效的大容量存储系统；
• 极高的 安全性 ，足以保障资金和金融数据的安全；
• 足够的 灵活性 以便支撑 Libra 生态的管理和金融创新。

2. 重要技术方向：

• 设计了一套新的智能合约 编程语言 Move；
• 选择 Byzantine Fault Tolerant 作为 共识算法 ；
• 遵循已有的区块链 数据存储模型 。

3. 发币机制

发币机制	特点
普通区块链发币机制	数字货币凭空出现，发币史“体内循环”的激励机制
Libra Reserve的发币机制	Diem数字货币与法币挂钩，通过使用储蓄法币投资获得的利润维护系统

二、JSON-RPC SPEC

1. JSON-RPC协议：

diem客户端API基于JSON-RPC协议，该协议定义了客户端端点和类型。
JSON-RPC协议是一个无状态，轻量级远程调用协议。

2. 节点活跃度（个人理解就是时效性）检验：JSON-RPC响应对象的三个变量（id,version,timestampusec），如下：

Field	Type	Meaning
diem_chain_id	unsigned int8	network chain id, e.g. testnet chain id is 2
diem_ledger_version	unsigned int64	server-side latest ledger version number
diem_ledger_timestampusec	unsigned int64	server-side latest ledger timestamp microseconds

3. HTTP响应头扩展（注意与上面表格中的变量含义相同，但区别除了名称，主要是类型）

Field	Type	Meaning
X-Diem-Chain-Id	String	network chain id, e.g. testnet chain id is 2
X-Diem-Ledger-Version	String	server-side latest ledger version number
X-Diem-Ledger-TimestampUsec	String	server-side latest ledger timestamp microseconds

4. 批量请求处理：JSON-RPC默认每次最多批处理20个请求（相同批次的请求会共用一个request context）。
5. 错误返回码：

Code	Meaning
-32600	standard invalid request error
-32601	method not found or not specified
-32602	invalid params
-32604	invalid format

6. CORS：CORS（跨源cross origin）已经嵌入JSON-RPC。规范如下：

Origin: 			any
Request-Method: 	POST
Request-Headers: 	content-type

7. 协议中包含的主要方法

submit(data: string) -> void
get_transactions(start_version: unsigned_int64, limit: unsigned_int64, include_events: boolean) -> List<Transaction>
get_account(account: string) -> Account
get_account_transaction(account: string, sequence_number: unsigned_int64, include_events: boolean) -> List<Transaction>
get_account_transactions(account: string, start: unsigned_int64, limit: unsigned_int64, include_events: boolean) -> Transaction
get_metadata(version: unsigned_int64) -> Metadata
get_events(key: string, start: unsigned_int64, limit: unsigned_int64) -> List<Event>
get_currencies() -> List<CurrencyInfo>

三、Diem总体结构设计

1. Diem网络结构上有两类节点：用户节点（Client）和 验证节点（Validator）。

client 可以提交或查询交易，Validator 则负责根据 Libra 协议去处理这些交易并维护账本的更新。

2. Transactions and States（交易与状态）

Libra 网络还维护了一个 Ledger State，这里面存储了账户地址和账户数据之间的映射。

3. Transaction 模型

区别传统区块链，diem独特部分：Program 和 Sequence numb

1. Sender Address：交易发起者的地址（不是物理意义的地址，可以理解成发起者的“银行账号”）；
2. Sender’s publick key，交易发起者的公钥；
3. Program：交易指令，包含：

	a. Move 语言字节码组成的交易脚本
	b. （可选项）交易脚本的输入内容，在转账交易中，脚本的输入是转账的金额和接收方地址。
	c. （可选项）Move 语言字节码模块，可以理解成一个智能合约的合约内容。

4. Gas Price：Gas 价格。Gas 是衡量计算量一个度量，每执行一定的交易代码就会产生一定 Gas，客户要为这些 Gas 买单；
5. Maximum gas amount：客户愿意支付的 Gas 上限；
6. Sequence number：序列号。

	注：每个账户的交易序列号从 0 开始，每完成一笔交易则序列号自增 1。

7. Expiration time：失效时间（如果一个交易在失效时间内没有被执行，则交易作废）；
8. Signature，数字签名。

4. Account 模型

1. 类似以太坊，从逻辑上看，账户是一个拥有两类资源的一个集合：Move Mouldes（程序代码）和 Move Resources（数据）。
2. Mouldes 存储的是 Move 语言字节码，即智能合约的代码，这些代码可以去访问或更新 Resouces 中的数据。
3. Resouces 存储是是数据部分，账户拥有的 Libra Coin 也是存储在 Resource 中。
4. Libra 网络通过一个 k-v map 的形式在 Ledger State 中维护了 Address 到 Account（Mouldes 和 Resoucrces）的映射。
5. 要创建一个 Libra 账户，首先要构造一对公私钥(vk, sk)，该账户的地址等于公钥vk的hash值，address=hash(vk)。
6. 只有当一个已经存在的账户向该地址发起一笔交易的时候，Libra 网络才会在 Ledger State 中创建新建账户的映射结构。
7. 一个用户可以有无数个账户，一个账户下面可以有无数的 Mouldes 和 Resource。

5. Versioned Database

1. Libra 并没有引入区块的链式（Block chain）结构，仅在共识协议的实现上引入了“区块”的概念作为共识算法的“优化”手段。
2. Libra 这个数据库在逻辑上是一个线性的结构，交易记录在数据库中只能单向增长。
3. Libra 定义了一个基于 version 的三元组存储在这个数据库中：对于每一个 Version i，数据库中存储了这样的一个三元组<Ti, Oi, Si>，分别指交易Ti，交易Ti执行时产生的输出Oi，交易Ti执行之后的账本状态Si（交易Ti是在状态S_(i-1)的基础上执行的）。

三、validator结构 (简单介绍在这里 ，详细介绍在这里 )

1. Admission control （AC）
2. Virtual Machine （VM）
3. Mempool
4. Consensus
5. Execution
6. Storage

四、validator工作机制

1. 接受交易

1. Validator 通过 AC 获取交易。
2. AC 通过 VM 执行交易检查，包括：使用交易中的公钥（地址）验证交易签名（基于密码学的数字签名原理：有且只有通过 Alice 的公钥解开 Alice 的签名可以获得和原文内容一致的文本；由此可以确认交易的发起者一定是 Alice 本人，且交易的内容真实可信），检查 Alice 余额是否足够，交易序列号是否正常等。
3. 当交易通过检查，AC 会把这个交易放到 Mempool 中。

2. 在 Validator 之间共享交易信息

4. Mempool 中可能已经有很多笔交易了。
5. Mempool 会通过 shared-mempool 协议和其他 Validator 节点共享各自所有的已接受的交易信息。

3. 打包提议

6. 假设当前 Validator 是共识过程中的 proposer/leader（不在此详细讨论 Libra 共识算法的具体过程），该节点会从 Mempool 中拿出一部分交易，打成一个区块（Block）。Consensus 模块负责同步这个块到其他 Validator 节点上。
7. Consensus 模块接下来负责协调各个 Validator 对该区块内当交易内容达成共识，包括交易记录的顺序。

4. 执行区块中的交易

8. 当 Validator 们达成共识之后，这个区块（一个排序好的交易集合）会被送到 Execution 模块。
9. Execution 模块通过 VM 去按序执行区块中的交易。对于 Alice 的交易来说，执行过程在逻辑上需要把 Alice 的账户余额减少，把 Bob 的账户余额增加；物理上需要对 Resource 部分的数据进行修改。
10. 执行完成后，Execution 会把这些交易按序添加到一个临时的 Merkel 树结构中。
11. Leader 节点的共识模块再次协调所有 Validator 节点对执行结果进行确认并达成共识。

5. Commit 区块

12. 当一个区块当执行结果被绝大多数当 Validator 认可之后，Execution 模块就会从刚刚的 cache 中读取之前的执行结果，然后把所有当交易提交到存储模块做持久化保存。
13. 至此，Alice 的转账交易完成，Alice 的账户余额减少了(10 + gas) Libra，Bob 的账户增加10，Alice 的sequence number从5变成6。

四、JSON-RPC协议函数（编写资料）

1. submit(data: string) -> void
2. get_transactions(start_version: unsigned_int64, limit: unsigned_int64, include_events: boolean) -> List
3. get_account(account: string) -> Account
4. get_account_transaction(account: string, sequence_number: unsigned_int64, include_events: boolean) -> List
5. get_account_transactions(account: string, start: unsigned_int64, limit: unsigned_int64, include_events: boolean) -> Transaction
6. get_metadata(version: unsigned_int64) -> Metadata
7. get_events(key: string, start: unsigned_int64, limit: unsigned_int64) -> List
8. get_currencies() -> List