Zhuang's Diary

go-ethereum 在 2019 年 7 月推出了 v1.9.x 版本。

Geth v1.9.0为轻型客户端提供了一种新模式，称为超轻型客户端 ultra light client。

此模式旨在将自己定位在受信任服务器和轻型服务器之间的安全范围中，用来自大多数受信任服务器的数字签名代替PoW验证。借助来自独立实体的足够签名，可以为非关键DApp实现远远超过足够的安全性。就是说，超轻量客户端模式并不是真正针对您的普通节点，而是希望将Geth嵌入到自己的流程中的项目。

轻客户端不下载和验证任何块头，而是使用硬编码检查点（hard coded checkpoint）作为起点。这个检查点包含了全部的必要的信息，从而验证之前的区块的正确性。所以从安全角度而言，没有任何的损失。

但是硬编码检查点（hard coded checkpoint）也有缺点：

• 由于检查点被硬编码到发行版二进制文件中，因此较旧的发行版将始终从较旧的块开始同步。几个月就可以了，但是最终变得很烦人。当然，您可以更新Geth来获取一个新的检查点，也可以获取所有的变更，但是很少有人希望这样做。
• 由于这些检查点已嵌入到代码中，因此如果您想在自己的专用网络中支持它们，那将很不幸，需要修改Geth，或通过配置文件配置检查点，并在每次更新检查点时分发一个新文件。可行，但长期而言并不可行。

Geth v1.9.x 附带了对链上检查点oracle的支持。超轻型客户端 ultra light client 可以不依赖于硬编码的检查点，而可以联系远程轻服务器，并要求它们返回存储在链上智能合约中的更新的检查点。最好的部分是，超轻型客户端 ultra light client 可以通过密码证明返回的数据已由所需数量的批准验证者签名！

等等，超轻型客户端 ultra light client 如何知道谁被授权签署链上检查站？对于开箱即用的受支持网络，Geth附带硬编码的检查点oracle地址和授权签署者的列表；对于专用网络，可以通过配置文件指定oracle详细信息。

尽管新旧检查点机制看起来很相似（两者都需要Geth或配置文件中的硬编码数据），但新检查点oracle只需要配置一次，然后可以任意长时间使用以发布新的检查点。

checkpoint-admin —Geth v1.9.x 附带的针对 checkpoint oracle contract 的管理工具。

checkpoint-admin 可用于查询已部署合同的状态。--rpc 需要指向一个light node，或者一个开启 --lightserv 特性的 full node。

1
2
3
4
5
6
7
8
9

$ checkpoint-admin --rpc ~/.ethereum/rinkeby/geth.ipc status
Oracle => 0xebe8eFA441B9302A0d7eaECc277c09d20D684540

Admin 1 => 0xD9C9Cd5f6779558b6e0eD4e6Acf6b1947E7fA1F3
Admin 2 => 0x78d1aD571A1A09D60D9BBf25894b44e4C8859595
Admin 3 => 0x286834935f4A8Cfb4FF4C77D5770C2775aE2b0E7
Admin 4 => 0xb86e2B0Ab5A4B1373e40c51A7C712c70Ba2f9f8E

Checkpoint (published at #4638418) 140 => 0x488c2eba92d31baeccfb6968fad5c21a3df93181b43b4cf253b4d572b64172ef

该命令也可以用户部署一个oracle，用以更新checkpoint，并publish该checkpoint到区块链网络中。

将来，checkpoint-admin 也可以离线工作，并有 clef 钱包签名。

参考文档==> Geth v1.9.0 Six months distilled

go-ethereum 在 2019 年 7 月推出了 v1.9.x 版本。1.9.x 在数据方面做了重新整理，大概有以下两个非兼容的改动：

1. 历史的区块链数据(header，body， receipts等)被挪到一个flaten file存储中，因为这部分数据已经是不会更改的了

2. 更改了部分数据结构的scheme，例如receipt。原先很多字段不需要存到db，是可以在read之后重新计算出来的。这部分会占据大量的存储空间，在1.9把这些字段删去了。

geth 有一个 inspect 命令，统计数据库详细信息。help中的内容是 inspect，Inspect the storage size for each type of data in the database。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

+-----------------+--------------------+------------+
|    DATABASE     |      CATEGORY      |    SIZE    |
+-----------------+--------------------+------------+
| Key-Value store | Headers            | 211.40 KiB |
| Key-Value store | Bodies             | 44.00 B    |
| Key-Value store | Receipts           | 42.00 B    |
| Key-Value store | Difficulties       | 19.07 KiB  |
| Key-Value store | Block number->hash | 17.24 KiB  |
| Key-Value store | Block hash->number | 845.67 KiB |
| Key-Value store | Transaction index  | 0.00 B     |
| Key-Value store | Bloombit index     | 0.00 B     |
| Key-Value store | Trie nodes         | 4.79 MiB   |
| Key-Value store | Trie preimages     | 547.13 KiB |
| Key-Value store | Clique snapshots   | 0.00 B     |
| Key-Value store | Singleton metadata | 149.00 B   |
| Ancient store   | Headers            | 5.97 MiB   |
| Ancient store   | Bodies             | 851.64 KiB |
| Ancient store   | Receipts           | 182.32 KiB |
| Ancient store   | Difficulties       | 279.10 KiB |
| Ancient store   | Block number->hash | 769.77 KiB |
| Light client    | CHT trie nodes     | 0.00 B     |
| Light client    | Bloom trie nodes   | 0.00 B     |
+-----------------+--------------------+------------+
|                         TOTAL        | 14.40 MIB  |
+-----------------+--------------------+------------+

这里的flaten file 存储，其实是把历史数据挪到了 ancient 文件夹（在前文亦有size说明），不在用 LeveldDB 存储，而用普通的二进制格式储存数据。

当从更加老的版本升级到 v1.9.x （或者Geth1.9.x重新启动）时，Geth将自动地升级Blocks和Receipts，从 LevelDB 转移到 ancient 文件夹。也可以通过手动设定 ancient 文件夹位置 --datadir.ancient 。

chaindata 存放了账本数据（cold data），默认的话，ancient 在 chaindata 里面。state 存放了业务数据（hotdata）。

• 如果 chaindata 账本数据被删除（或者指定到了错误的位置），节点将变得不可用。这种操作是命令禁止的。
• 如果 state 业务数据被删除，Geth将在 chaindata 账本数据的基础上重建其索引，并在顶部快速同步到丢失的状态数据。

参考文档==> Geth v1.9.0 Six months distilled

2019-12-20，版本1.0.4，块高89万+（约59万笔交易）

==========================================================

run 25G

|

consus.log 526M

logs 4.6G

odys.log 16M

data 19G

|

config 32K

data 2.7G — blockstore.db 1.4G / cs.wal 1G / state.db 21M / tx.index 308M

odyssey 17G

|

chaindata 17G — 平均每个文件2.1M，共计97224个文件，其中 ancient 472M

==========================================================

某项目中，2019年11月29日上线起始，截至2020年6月19日为止。用户量逐渐增大，目前的日活用户数量为10000~60000。区块高度为6,000,000以上，单个节点的磁盘用量为300G，日新增存储量为1.5G。

==========================================================

BTW：在ethereum1.9.9的版本中，geth 增加了 inspect 命令，“Inspect the storage size for each type of data in the database” ，详细情况将在下一篇文章中介绍。

refer link==> http://www.jryj.org.cn/CN/abstract/abstract535.shtml (中国人民银行研究局/金融研究所)

（：：姚前先生的文章常读常有心得）

共识（consensus）和去信任（trustless）是区块链两个非常重要的基础概念。这两个概念脱胎于计算机领域，很难再经济学上予以严格定义，却很容易被误解。比如，将共识等同于消除了信息不对称或实现了共同信念，将去信任等同于没有信用风险。

1.共识的界定

目前对区块链共识的讨论，涉及三种不同语境下的共识概念—机器共识、治理共识和市场共识，其中治理共识和市场共识可以成为“人的共识”。很多误解就源于混淆了这三类共识，或者泛化了共识的范围和性质。

第一，机器共识。机器共识属于分布式计算领域的问题，目标是在存在各种差错、恶意攻击以及可能不同步的对等式网络中（peer-to-peer network），并且在没有中央协调的情况下，确保分布式账本在不同网络节点上的备份文本是一致的（不是语义一致）。

对等式网络的节点（特别是负责生成和验证区块的节点）有诚实节点和恶意节点之分。诚实节点遵守预先定义的算法规则（主要是共识算法），能完美地发送和接收消息，但其行为完全是机械性的。恶意用户可以任意偏离算法规则。在一定限制条件下（比如比特币要求50%以上算力由诚实节点掌握），算法规则保证了机器共识的可行性、稳定性和安全性。机器共识的范围限于区块链内与Token的状态和交易等有关的信息。

第二，治理共识。指在群体治理中，群体成员发展并同意某一个对群体最有利的决策。比如，比特币社区关于“扩容”和分叉的讨论可以在治理共识框架下理解。治理共识的要素包括：1.不同的利益群体；2.一定治理结构和议事规则；3.相互冲突的利益或意见之间的调和折衷；4.对成员有普遍约束的群体决策。袁勇等（2018）指出，治理共识涉及人的主观价值判断，处理的是主观的多值共识，治理共识的参与者通过群体间协调和协作过程收敛到唯一意见，而此过程如果不收敛，就意味着治理共识的失败。

第三，市场共识。Token参与交易时（不管是不同Token之间交易，还是Token与区块链外资产或权利交易），就涉及市场共识。市场共识体现在市场交易形成的均衡价格中。

三类共识之间存在紧密而复杂的关系。机器共识是对等式网络的节点运行算法规则的产物，治理共识反映由人（包括网络节点的拥有者或控制着）来制定或修改算法规则的过程。市场共识受机器共识和治理共识的影响。比如，如果分布式账本的安全性没有保障（即机器共识失效），比特币的市场价格将受到毁灭性冲击。再比如，2017年比特币社区对“SegWit2x”的讨论（即引入隔离见证并将单个区块的大小从1M提升到2M），对当时比特币价格走势有明显的影响，就体现了治理共识对算法共识的影响。下文如无特别说明，讨论的均是机器共识。

2.去信任含义的辨析

去信任源于Token被交易时，Token的状态变更和交易确认同步发生这一安排。设想Alice以比特币向Bob买入某一货物。Alice向Bob支付比特币这一过程无需两人之间有任何了解，也无需受信任的第三方机构，就可以在区块链内有保障地进行。这是去信任的真正含义。但在交易的另一端，Alice如何确保Bob会按时向她交付合格的货物？只要做不到一手交比特币、一手交货，就存在不容忽视的交易对手信用风险。只有准确识别、评估信用风险并引入风险防范措施，很多交易才能进行。比如，在暗网交易中，交易平台通常设立第三方托管账户（escrow account）。买方先将比特币打入第三方托管账户，等收到商品并确认后，才通知交易平台将比特币转给卖方。如果没有第三方托管账目这个增信手段，比特币忠实拥趸之间的交易也会大幅减少。

因此，区块链内的去信任环境，不能简单外推到区块链外。一旦脱离Token交易等原生场景，区块链要解决现实中的信任问题，往往需要引入区块链外的可信中心机制予以辅助。

refer link==> https://ethereum.stackexchange.com/questions/143/what-are-the-ethereum-disk-space-needs

Update on Dec 9th, 2018 / Block ~ 6_850_000

Geth (Go)

Last Update: May 14th, 2018 / Block ~ 5_600_000

1
2
3
4
5
6

Client / Mode         | Block Number   | Disk Space
======================|================|===========
geth light            | 5_600_000      | 363M
geth fast full        | 5_600_000      | 142G
geth full full        | 4_980_000 [1]  | 239G + [1]
geth full archive     | 4_980_000 [2]  | 671G

• Geth 1.8.3
• Ubuntu 16.4 LTS, VPS instance with SSD backed storage

Parity (Rust)

Last Update: May 14th, 2018 / Block ~ 5_600_000

1
2
3
4
5
6

Client / Mode         | Block Number   | Disk Space
======================|================|===========
parity light          | 5_600_000      |  89M
parity warp fast      | 5_600_000      |  82G
parity full fast      | 5_600_000      |  78G
parity full archive   | 5_600_000      | 1.1T

• Parity 1.10.0
• Ubuntu 16.4 LTS, VPS instance with SSD backed storage