EZchain——直面Web3.0的“无限扩展”区块链系统（附github原型系统）

开源地址：GitHub - Re20Cboy/Ezchain-py: via py

& o, _3 M, ^2 N; ~+ q! e& z$ qarXiv：submitted（待更新）
) }' p8 L# ?3 i! R. K# w" L8 i+ o<hr/>EZchain：面向web3.0的新型“无限扩展”区块链账本系统（中文版）
. i+ m! v6 v) p2 T- ]
6 w) S% ?& y/ cEZchain Team
$ H$ t0 [: r# B! O[email protected] & [email protected]
摘要

/ y4 ~) N: B: `3 n( y9 \/ n区块链底层技术的发展大都围绕着这样一个难题：如何在不破坏系统安全性和去中心化的前提下，提升系统的效率、降低节点的各项成本（验证、存储等）。Layer-1的分片、layer-2的链下以及跨链都提供了漂亮的解决方案。但它们还不能被称为“银弹”。为此，本文提出一种面向web3.0的新型去中心化横向扩展账本系统，旨在让区块链技术能够真正意义上支撑大规模完全去中心化网络中的账本类应用场景。
1. 介绍
3 m' g+ n+ A+ Y& P$ E. g8 F
目前，在去中心化，安全性和可扩展性之间取得平衡的同时，最大限度地提高系统效率是一项艰巨的挑战（如图1所示）。这激发了许多出色的工作[3, 8, 4, 15, 16, 6, 2, 5, 12, 14, 18, 17, 11]，它们反映了不同的权衡：将领导者选举与共识分离[3]，这在一定程度上提高了吞吐量，但交易延迟仍然很高；用拜占庭式容错（ByzantineFaultTolerance，BFT）代替Nakamoto共识[8]，尽管它具有良好的交易延迟，但是在大型网络环境中，其性能仍受到BFT的限制。在leader选举中，用可验证的随机函数（VerifiableRandomFunction，VRF）代替PoW可以很好地解决能源问题。但随网络规模同步上升的通信、验证和存储成本依旧没有得到根本的解决。
. [$ A9 Z( [! G. Q


图1 区块链不可能三角

分片，另一个layer-1中值得关注的方向，已成为许多可扩展解决方案的基础[7, 18, 19, 13, 9, 1]。它可以将网络，交易或状态划分为几个子集（或碎片），并且共识算法可以在各种分片中运行，以减少对带宽，存储和计算能力的需求，从而实现高效率和区中心化。但是仍然存在许多挑战：首先，跨分片交易过多会极大地影响系统的效率；其次，在分片中，原始共识方案的安全性假设不再成立，因此大多数协议都需要加强安全性模型（例如，OmniLedger[7]最多只可以容忍n/4个拜占庭错误节点以1–10^6的概率保证分片中的BFT安全性模型）；协议要求对节点进行定期验证（例如，PoW），以防止分片中的Sybil攻击[10]；另外，复杂的网络分片算法也会消耗带宽和计算资源。如何优雅地解决上述这些问题，为layer-1及其上层应用提供一个高效便捷且低成本的底链“基础设施”是一项亟待解决的科学难题。
9 h( P. o6 z( A( {$ z% O
- z& f; K- `( X( b
4 ?$ e) W  o9 X; b' e2 Q6 l+ R: t  X; _
图2 区块链及web3.0应用面临的各项瓶颈指标的“木桶效应”（来自conflux的某次演讲）
2 z" z  X! K7 `* ^. T4 f' ~
为此，我们提出了EZchain，一种面向web3.0的去中心化、开放网络、高性能区块链解决方案。EZchain完全遵从web3.0分布式的设计理念，有别于伪去中心、layer-2、链下、中心化跨链等概念，真正做到在layer-1中进行各项性能瓶颈的突破：1.）在通信复杂度和传输成本方面达到甚至突破分布式网络的物理极限；2.）在系统节点的存储成本方面直接支持消费级存储器参与共识；3.）在验证效率方面保证计算成本不会随系统运行时间的增加而增大。
EZchain摒弃了传统的全网共识设计思路，而采用全新的交互共识算法，其以最小的共识、传输、存储信息量达到与全节点共识相同的效果。其底层原理可以朴素地总结为：区块链共识的“奥卡姆剃刀”。具体而言，当前区块链的共识机制设计着重于整体事务及状态的同步，这是由于先前的设计都默认未来发生的交易需要基于过去的“世界状态”进行验证。但事实上，这个前提过于严格了，例如，在区块链的分片系统中，某个分片内部的事务（未涉及到跨分片事务）完全可以仅仅通过内部的历史和“世界状态”来进行验证判断。EZchain则将这种思想发挥到了极致，即，对于任意一项事务，要验证其合法性最多需要哪些信息量以及如何最大程度地优化这些信息量在传输和存储方面的效率。
7 z' [* r+ G" j1 g& V
# V! M& b) V$ _: f9 O" L0 B
1 H0 l$ e2 \, U' Z! D# a( j
图3 分片内部事务验证案例
4 D1 s* K. w) O% Z% W
在实验测试方面，我们实现了EZchain的原型系统（代码开源于github：https://github.com/Re20Cboy/Ezchain-py），结果显示EZchain确实能满足web3.0环境下的“无限扩展”的性能。
' p+ t' t$ [2 f8 v6 g' a2. EZchain设计

2.1 EZchain核心设计思路
$ L/ Y3 u! I. i" ~
本章将直觉地非形式化地介绍EZchain设计的朴素思路以帮助读者更好地理解整体系统和算法设计。
6 H  V" {5 p% s" m


! k8 t& M- a% K: ~0 Y) Z; q图4 web2.0和web3.0在各项成本上的差异与区别
) K* r. }2 _* C
目前包括区块链在内的web3.0系统设计中，牵扯到全网共识和去中心化验证的情况，则需要至少O(n^2)级别的全网通讯和存储复杂度（BFT类算法在有些情况下甚至需要O(n^3)的通信复杂度），这是各项瓶颈和约束（见图2中的介绍）形成的本质原因。以分布式账本为例，要验证一笔事务是否合法，是否被“双花”，则需要溯源整个区块链的历史信息来确认[1]；提交一笔事务，需要广播至所有共识节点，并通过它们的验证，即使此事务可能和一些节点毫无关系；在存储方面，每个共识节点本质上都相当于充当了原本的中心化服务节点，冗余存储着世界状态和事务历史的备份。针对这些问题，目前涌现出的多种解决方案：分片、链下、跨链等大都考虑以牺牲一定的安全性和去中心化为前提来尽可能地提升系统的效率。EZchain则深入探索此问题是否存在更优雅的解法。我们认为，事实上，目前的区块链系统在验证、存储和传输的设计思路上存在冗余和优化空间。从信息论的角度来说：即使在去中心化的存在恶意节点的网络中，验证某一笔事务的合法性，也并不需要传输和存储整个世界历史的信息量。更幸运的是，我们发现，足够小的（传输与存储的）信息量就可以在去中心化、无信任的场景中支撑一笔事务的全部合法性验证[2]。
接下来，我们结合一个简单的案例来解释EZchain的核心思想。如下图所示，蓝色虚框内的某个值（图中表示为蓝色货箱）在不同的事务间不断传递（Txn #4~6），那么当账户l收到此值时，l对Txn#6的合法性验证可以等价为对此值的合法性验证，即，验证：此值在Txn#6之前经历的所有事务均是合法的且Txn#6也是合法的。并且直观地，这些验证均和Txn#1~3是毫无关联的，因此，Txn#1~3这部分的信息量既不需要在Txn#6被验证时传输也不需要l对其进行存储。以上便是EZchain的朴素核心思想，也即，区块链共识的“奥卡姆剃刀”，尽可能剔除删减与共识和验证无关的信息量，达到最优化的传输、存储和验证。

& I8 m/ F* _7 a

! v$ X* |% u! N9 Q. B# I8 M3 P图5 事务验证和各个事务之间的逻辑关系
0 ]! i+ e. N& k+ C% f
9 d! y" s" C# p+ u2.2 EZchain系统概述

5 I" p! w5 M9 `. R4 z. L# c3 N6 B总体研究思路和设计框架如图6所示。首先，EZchain的共识算法支持大部分的开放性拜占庭容错共识机制（例如，PoW、PoS、DPoS等），在共识的信息和数据结构上，EZchain并未采用Account模式或UTXO模式，而是创新地采取了“Value-based”模式，此模式主要以值的转移的视角去观测记录和验证整个账本记录。EZchain的链上采取了极致“轻量化”的数据结构，每个区块仅约1+Mb，但其理论上可以容纳无限多的交易，实现区块存储信息层面上的“无限扩容”。并且链上信息的验证操作也十分便捷，仅需必要的签名验证及哈希验证，而无需回溯和验证事务历史和逻辑，这一点同样解决了“新节点”加入系统时的初始信任难题。关于事务的验证则推迟到账户节点的“p2p交互验证部分”，这相当于让事务的涉及方对自己的事务合法性负责（这也是正向激励的），也分散了共识节点的验证压力。

7 y6 G" W  w) U, D
2 m' ~, C$ l0 A4 }8 ^7 ~
# m* b# M! f$ a4 Z7 {7 z图6 EZchain系统概览图
0 k) t! X/ z8 q3 E& @4 }; s, Z0 Q

算法1 - EZchain主算法（PoW版）

Miner：   1.     Miner从交易池中收集打包交易集合TxnPool={AccTxn_1, AccTxn_2, ) h2 z$ t1 J$ ]/ e  …}，其中AccTxn_i=(Sender_i, HASH(Txns_i), SigInfo_i)，其中HASH()为哈希散列函数，Txns_i是由账户节点Sender_i发起的交易的集合, SigInfo_i则是Sender_i对HASH(Txns_i),的数字签名。   2.      Miner创建新的Block=(Mtree   Root, Bloom Filter, Pre Hash, Time, Miner SigInfo, Nonce, Index)，其中Mtree Root是根据交易池TxnPool中的所有HASH(Txns_i)项形成的默克尔树的树根信息，Bloom Filter则添加了所有在TxnPool中的Sender的地址信息，Pre Hash、Time、Miner ! c3 g) \! Q9 u& A  SigInfo、Nonce、Index则分别是前块哈希、时间戳、矿工签名、随机数、块编号。   3.      若Miner在“挖矿竞赛”中胜出，则广播Msg_1=Block及Msg_2=SigInfos，其中SigInfos={ SigInfo_i | ∀ SigInfo_i in TxnPool}，Miner应当优先广播Msg_1再广播Msg_2。 " [! o7 v4 m* h6 D& K  4.    5 }' \, G+ y  L$ q& W% Y5 w5 ~1 q  其他Miner则对接收到的Msg_1和Msg_2的信息进行验证：1.）各项数字签名的正确性；2.）Bloom   Filter和SigInfos是否匹配；3.）SigInfos是否能重构Mtree Root；4.）SigInfos中是否存在重复签名（即，一个Sender在一个SigInfos中签名了两个SigInfo）5.）其他信息的验证（Pre Hash、Time、Miner   SigInfo、Nonce、Index等）。 4 `$ b. E- I" o% E, @3 m  Account：   1.      本账户(account i)向其他账户(account j)进行交易时，i先从自己持有的值[3]中选择适合本次交易的值组合。并形成交易Txn=(Sender, Recipient, Values, Time, SigInfo)，其中Sender、Recipient分别是发送者和接收者的地址，Values是Sender选取的用于支付此次交易的值的集合，Time和SigInfo分别是交易时间戳和Sender的签名信息。 " U. y2 C0 B6 z3 a5 Z  2.    6 G( z' p- F+ u3 Y1 i8 A0 Y  账户i将一段时期内的所有交易Txn收集打包为Txns_i，并形成AccTxn_i=(Sender_i, HASH(Txns_i),   SigInfo_i)提交至交易池，等待相关信息被Miner打包进区块Block。 ) F6 N) N$ b: d. ?4 l) A" m' l  3.      若Block成功上链，则i向Miner索要Mtree Proof={MTree Node| 证明HASH(Txns_i)在此Mtree中的树节点列表}。 5 i# l; T+ T8 x  4.      账户i向j提供Txn中Values所包含的所有值及其对应的VPB pair， j将结合主链信息和i给出的所有VPB 2 \& A* X( g2 y5 f7 e8 p! j8 E  pair进行交互验证。 * [% q" c+ T9 g5 `$ ^  5.      若通过交互验证，则j接收i转移给自己的值集合Values，并将相关证明存储在本地，以便在未来使用该值Values时出示。

EZchain的共识机制大体设计逻辑如算法1所示，可以看出，EZchain不依赖于底层的leader选举和出块逻辑的设计，因此可以适配现有的多种共识算法，例如，PoW、PoS、DPoS、BFT类等。事实上我们较为推荐Algorand中的共识机制——VRF+BFT[x]，因其（几乎）不会产生多余的分叉，能较好地适配EZchain的极速出块性能[4]。EZchain主算法中涉及到的数据结构并未给出详细解释，具体内容推迟到“数据结构”小节。
% ]8 M, @+ k3 z' u& [. \2.3 EZchain相关数据结构
+ [/ Z6 o& y9 H: i! E% t" x
; S) |' O6 g( c5 e; L5 q与传统的区块链相比，EZchain在区块、验证、证明等方面的数据结构进行了详细的重新设计，具体解释如下：
; p: w9 L9 x# }# T. j8 q& i

  D' n1 A* C; J
2 d! c% @8 }- P图7 EZchain中的value数据结构

' L3 ?# Y6 \/ d1. 前文中提到的value（值），并非和经典区块链中的token相同，其数据结构为value=(Begin index, End index)，即，由开始值和结束值构成，其有以下特性：1.）value本质上是一个整数集合{x, x \in [Begin index, End index]}；2.)不同的两个value无交集；3.）value可以分裂为更小的集合，分裂后集合的并集仍等于原集合；4.）值的数目可由Begin index和End index计算得出。



图8 EZchain区块数据结构中的默克尔树与布隆过滤器
6 n4 c# K) A/ R, C
* J# {6 C7 o- E6 c' X/ @- l+ c2. 在区块主体方面，EZchain的区块主体仅包含以下信息：Block=(Mtree Root, Bloom Filter, Pre Hash, Time, Miner SigInfo, Nonce, Index)，分别表示默克尔树的树根哈希值、布隆过滤器、前块哈希值、时间戳、矿工签名、随机数、区块序号。这里详细解释两个较为特殊的数据结构Mtree Root和Bloom Filter：1.）Mtree Root，Miner收集到的交易池中的所有HASH(Txn_i)的集合，并以此集合内元素作为叶子节点构建一颗默克尔树（如上图所示），此数的树根节点便是区块中的Mtree Root；2.）Bloom Filter，此布隆过滤器则是添加了AccTxn集合中所有Sender的地址信息。其他区块内数据结构和一般区块链系统相同。

$ Y+ P, k1 F. ~( C5 r

图9 EZchain账户节点提交至交易池的数据结构

3 g& M1 T. a% b! E$ R9 R# Z3. 在Accout提交到交易池的数据方面，AccTxn_i=(Sender_i, HASH(Txn_i), SigInfo_i)。如上图所示，账户a将自己发起的且目前未提交的交易打包为Txn_a并计算其摘要HASH(Txn_a)，然后a对HASH(Txn_a)进行签名得到SigInfo_a，最后结合a的地址信息Sender_a组成AccTxn_a=(Sender_a, HASH(Txn_a), SigInfo_a)提交至交易池中。
# M; M3 Z4 H$ T% Q

! f0 m* \, V# ^
图10 Miner广播信息的数据结构示意图

( c7 d2 o3 n4 m2 W4. 在Miner广播的信息方面，Msg_1=Block、Msg_2=SigInfos，其中Block如1中所述，SigInfos={SigInfo_i | ∀ SigInfo_i in TxnPool}，TxnPool ={AccTxn_1, AccTxn_2, …}。上图直观地展示了Miner广播的两个消息的数据结构及其内容。

6 E0 L& p' u* b5 i: m
8 M3 d3 f+ q5 w
( n( }4 o: a9 G' |图11 EZchain中的VPB pair数据结构示意图。
$ F! [: U* |0 y! b$ Y
5. Account_i在交易时出示的证明方面，EZchain采用“VPB pair（Value-Proof-Block_Index pair）”数据结构，其中，Value是账户i用于支付事务所选取的值；Proof包含：1.）Mtree Proof={MTree Node| 证明HASH(Txn_i)在此Mtree中的树节点列表}，2.）Bloom Proof={构建Bloom Filter_k的所有账户地址信息|Bloom Filter_k为所有“错误包含”了账户i的Bloom Filter[5]}；Block_Index则为Proof对应的区块索引号。上图直观地展示了VPB pair的数据结构的逻辑关系。
: ^! a1 t; K* r) U8 J5 b6 I* H2.4 EZchain具体事务案例分析

6 i/ K6 T% }8 C5 `- H本节将以一个具体事务为案例详细分析EZchain各个节点在一个事务的开始、提交、共识、确认等环节中如何参与，以及EZchain系统是如何运作的。
以图x中的案例为例。假设value在创世块（区块高度为0）中被分配给了账户a，随后账户a想在某个区块（区块高度为α）提交交易Txn_α=(a, b, value, Time, SigInfo)，即，a将value转移给账户b。那么a需要：1.）将Txn_α添加进待提交的交易集合Txns_a中，然后向交易池中提交AccTxn_a=(Sender_a, HASH(Txns_a), SigInfo_a)；2.）等待Miner广播区块α，并将AccTxn_a对应的MTree Proof发送给账户a；3.）账户a将value对应的VPB pair传输给b；4.）b对a发送来的VPB pair进行验证，若验证通过则确认Txn_α。上述案例中value对应的VPB pair，其中Proof应为：账户a在高度0~α的区块内所有的Txns_a的信息及其对应的MTree Proof，这被称之为Proof Unit=(Txns_a, MTree Proof)，多个Proof Unit组合为a提交给b的Proof^a_b，注意Proof^a_b中最后一个Proof Unit的Txn_a应当包含Txn_α。VPB pair中的Block index则为Proof^a_b中所有Proof Unit对应的区块索引编号。
在验证环节，这里我们给出一个非形式化但直观的账户b对a给出的VPB pair的验证思路。账户b首先需要验证Block index的正确性，这可以通过EZchain主链上的Bloom Filter来判断，因为EZchain主链是通过全网共识的，其中的布隆过滤器也在节点中保持一致性和正确性。除去一些少见的特殊情况（见附录A），b可以根据Bloom Filter来判断a在哪些块提交过交易，然后根据Block index对用的Proof来查看a在高度0~α的区块内提交所有的交易中有没有使用value的，若有，则说明此value在Txn_α提交前已被转移，因此Txn_α是非法事务，b应当拒绝，反之，则可以确认此交易。上述的验证过程需要b结合EZchain主链的信息和a提供的证据共同验证交易的合法性，EZchain的链上信息可以保证a无法提供虚假的信息，无法篡改“真实的历史”，因此a只能向b提供真实的完整的可验证的证据。
8 X$ X4 [. v! U若b确认了Txn_α，则成为了value的新owner，在后续b想要将value在高度为β的块转移给账户c时，则和先前a向b提供VPB pair的操作相同，只是这里的Proof和Block index需要涵盖a和b的所有历史信息（a在高度0~α的区块内提交所有的交易及b在高度α~β的区块内提交所有的交易）。当然，EZchain完全允许一笔事务中包含多个value，只需对每个涉及到的value进行上述操作即可。
2.5 EZchain相关优化设计

, n# o2 o1 S9 Y' F# }4 l3 z9 K2.5.1 交易时value选择机制

交易时，假设账户a想要支付一笔目标金额x给账户b，那么a则需要在自己持有的values集合中凑足此目标金额。最朴素的做法就是从头开始遍历，直到找到金额满足x的values即可（如下图所示）。
$ F, g9 b) _4 h# d/ q0 Y) A
, {. e# @% C* y  ?. |3 q4 E
  z+ a# V2 w' C# i& i9 ?
图12 未经优化的交易value集合选择方案示例图
. u4 t% `& Q1 `; Y: @3 h
1 g: F/ K* k* @. T 但账户节点完全可以根据具体情况进行分析然后择优选择最适合本次交易的值集合，例如，可以选择所需证明最小的值集合，或者选择不需要分割（找零）的值集合等（如下图所示），进行综合考虑，每个账户都可以根据自身情况进行定制符合自身的优化选择策略。
( K3 C1 k7 W+ g0 g0 e


" F: U5 `3 M% c8 y! u9 ~图13 优化后的交易value集合选择方案示例图
/ Q4 N  T, m) B& {  `
2.5.2 Check point机制

7 d; N: U! P0 B( h& a3 Q2 e# N, X考虑一个常见的应用场景：账户a和b有多次历史事务往来记录，那么在下一次a和b进行交易时，是否有合理的优化方案来减少值的证明量？答案是肯定的，这里举一个简单直观的例子来进行说明：a在高度为α的区块转移了某个value（值数为100）给b，在随后的某个区块高度β（β>α），b想要转移值数为100的值给a，那么b完全可以选择先前a转移给自己的value，并告诉a，此值在区块高度α前都无需验证，因为a自己已经本地验证过了，即，a只需验证value在区块高度从α+1到β内的合法性即可。这便是check point机制的朴素设计理念。并且随着事务的推移，节点可以不断地跟新持有值的check point，以节省存储、通信和验证成本。



- q5 Q' q% |, ]图14 EZchain check point机制图示
2 e6 J4 N8 K, O  G; h' v! {! ~; m
3. EZchain性能分析

总体而言，EZchain在先前提到的各项性能瓶颈的指标上均有明显的突破（如下图所示）。

; f" K. u* k8 k- E+ @
5 }  i. V" _/ T2 v7 F* l
# p7 ?/ K  F) a& r1 A! V图15 EZchain在共识、网络、验证及存储方面的性能突破
! b) f5 A0 g" ~
/ y- q2 W" p5 F) q在共识和通信效率方面，当前大多数layer-1层的共识算法的效率和去中心化上仍无法取得理想的实用效果（例如，比特币及以太坊的事务处理拥塞、算力富集导致中心化程度严重）。Layer-2层协议、许可链及私有链虽然可以解决以上痛点，但前者的安全性几乎与主链脱钩，后者的系统准入门槛过高不利于去中心化。而EZchain能够在仅共识事务默克尔树根哈希和相关布隆过滤器信息的情况下保证事务的原子性和合法性，这使得事务的共识和验证能够并行处理，如图3所示，EZchain方案大大提升带宽利用率（趋近100%），进而提升吞吐量。

; b4 N" {9 V* \: [- p+ P, Z. w

) ]8 P# {7 J) k0 T7 L- v& K! u图16 EZchain与传统区块链的带宽利用率（传输成本）对比示意图

, a" N3 _7 f1 V, O在存储成本方面，由于EZchain的特殊设计，共识节点共识的区块信息仅包含默克尔树树根、布隆过滤器、随机数Nonce、时间戳、Miner签名、Miner地址及区块编号。且每个EZchain的区块大小几乎恒定不变（大约在1Mb左右），不随系统吞吐量和网络节点规模的增大而改变，另外，共识节点还需要存储近期的区块所对应的完整默克尔树信息（以便应对其他节点发起的“挑战”），以上设计大大缩减了共识节点的存储成本。对于账户节点而言，其仅需存储自身持有值的相关信息（value、VPB pairs、check point）即可，并且在后续的仿真实验中可以得知，这些存储成本随系统运行时间的增长是极其缓慢的（并不会明显高于正常中心化交易系统的账户节点存储成本）。
; P- u' k* i% K. q4 F
3 q* m* ?* b" @- W) r( l- G

# \4 ^2 i5 `: j0 }图17 EZchain各节点的存储及验证成本示意图

在验证成本方面，共识节点的验证成本也变为几乎常数级别，不随系统吞吐量和网络规模的正大而增加。账户节点的验证成本由于有check point机制的存在也几乎是常数级别。以上两点在随后的仿真实验中均可以被很好地验证。
5 d  S  J  c3 m! |) ^/ @4. EZchain的仿真实验及结果
0 B% k/ @8 H4 l0 o: n
& z8 k+ l3 j6 \0 e) [+ y. w# P在本节中，我们通过实现一个EZchain的仿真原型（包含网络传输层）来评估其性能，主要关注以下几个方面：1.）EZchain系统的平均吞吐量；2.）EZchain共识节点的存储消耗和验证时长；3.）EZchain账户节点的存储消耗和交易的确认时长。
1 G, \9 }. z% \: c6 n/ ~4 N% e; R4.1 EZchain实验设置
! w  L# J0 y# J/ k
4.1.1 实验设备
9 L8 f4 E# a* Y  A5 u, C1 O
处理器：11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz 2.80GHz（八核）
内存：16.0 GB
系统：Windows 10 专业版
4.1.2 仿真系统设置
  r( U2 ~; `$ A$ M% K$ U
  N6 F0 k. b' C* |0 {5 v共识节点数、账户节点数均可自由设置，由于设备内存条件限制，本实验的设定一般在3~150节点范围内。带宽速率一般设置为1~5Mbits/s。共识节点之间的通信延迟（这里指排队等待的延迟，不包含信息传输的耗时，后同）在1s内，为随机数，共识节点和账户节点的通信延迟为1.5s，账户节点和账户节点间的通信延迟为1.5s。
  ?) A* U5 i5 C3 x# N4.2 EZchain系统吞吐量测试
7 |' A3 O# W. r4 e8 S
由于设备条件限制，且为了尽可能测试EZchain的吞吐量上限，我们减少执行轮次，增加扩展节点和事务规模。且由于账户节点数量和每轮投入交易池中交易数量也存在平方限制关系[6]，综上，我们设置共识节点数量为100个，账户节点数量为160个，并执行三轮EZchain模拟（三次出块），系统的吞吐量测试结果如下图所示，其中红色虚线表示三轮测试结果的平均值。由图可知，EZchain可以满足过万的TPS吞吐量，每个区块中可以轻松包含近15000笔交易。
2 K: n# R5 ?4 q3 |1 B3 }! E
* X% L( w2 V+ N: j1 D: m0 u4 K7 x

% w- _2 K$ h% D* ?- J图18 左图为EZchain的吞吐量仿真实验结果图，右图为每个区块中提交的交易数量及包含的值的总数量。
9 l; T% H, m7 H1 t1 w
8 ?9 ]7 m& G$ |+ \9 ^" X 在超10000TPS的吞吐量情况下，我们继续观测EZchain的共识节点和账户节点的其他性能指标，包括存储消耗和验证消耗等，如下图所示。共识节点三轮的存储消耗甚至没有超过1MB，这甚至低于Bitcoin的区块大小，但提供了超Bitcoin千倍的吞吐量。账户节点的存储成本在此处由于轮次较少，无法展示明显的规律，更多信息将推迟到后续的实验小节。在验证时长方面，EZchain共识节点的区块验证基本在<1毫秒的量级，账户节点的事务确认时长也几乎在10s以内。
% ]% ^8 F  a8 Q+ U" X( z; q
5 c7 w( w' A8 u# e' r3 c

图19 左图为账户节点的每轮存储消耗，右图为共识节点每轮的存储消耗。


3 N9 w9 t: F- N! ^+ L! L
; d$ J6 q& r( w9 {1 }4 ~7 o图20 左图为账户节点的事务确认时长，右图为共识节点的（单个）区块验证时长。

! r& B( c9 K' Y/ I; s2 c. M" x4.3 EZchain共识节点的存储消耗和验证成本
" X- w6 G- n2 s0 k5 s$ K. N
由于设备条件限制，且为了尽可能测试共识节点的存储和验证成本，我们需要尽可能增加实验轮次（即，系统运行时间）来观测长期情况下的各项成本。因此，本此实验设置3个共识节点和3个账户节点，运行1500轮次（区块）来观测EZchain共识节点在存储和验证上的消耗趋.3 势。实验结果如下图所示，对于共识节点而言，1500个区块的存储成本大约在175MB左右，且保持线性增加的趋势；验证方面，单个区块的验证时长完全与系统吞吐量、提交的事务数量、系统运行时长等无关，基本维持在1毫秒以下。
' v' f" m) Z+ X+ i+ Y4 s* |
( g, C; c6 q! m0 E" \* r
# F; E; {1 \1 a. O* v* |
图21 左图为共识节点的（单个）区块验证时长，右图为共识节点的存储消耗。
+ ^, p7 U9 |! u8 u9 S/ D
4.4 EZchain账户节点的存储消耗和验证成本
4 o' H5 y4 i- Y- ~0 @7 O7 ~1 B  n
# P' e" M" n% H( ?由于设备条件限制，且为了尽可能测试账户节点的存储和验证成本，我们需要尽可能增加实验轮次（即，系统运行时间）来观测长期情况下的各项成本。因此，本此实验设置3个共识节点和3个账户节点，运行1500轮次（区块）来观测EZchain账户节点在存储和验证上的消耗趋势。实验结果如下图所示，观察平均值可知（左图的绿线、右图的黑线），账户节点的存储消耗随系统轮次运行的增加是非常不明显的，几乎维持在一个区间内上下波动，且在1500轮内观测到的增长速率也是极其缓慢的。在事务确认时长方面，实验结果如下图所示，账户节点的事务确认时长几乎都在40s以内。
9 [- v2 R/ o0 N; R( v4 R
! l2 D( H& k+ f; F$ W9 C  v

图22 左图为账户节点的存储消耗随系统运行轮次（区块数）的变化图，右图为账户节点每轮接收的VPB pairs的容量大小变化图。

" W2 B5 D& \# j7 [, W

图23 账户节点的事务确认时长实验结果图
5 m$ H# }' d" p. i+ J
7 ~* Y0 I2 c; B% s9 u总结
4 g7 S! Q/ m; F) V, P
2 `% @  B$ F$ n5 y: t面向真正的web3.0应用场景，我们提出了EZchain，一种可以达到“scale-out（横向扩展）”性能的消费级去中心化分布式账本区块链系统。并实现了原型仿真系统（开源于：https://github.com/Re20Cboy/Ezchain-py）。未来我们将聚焦于两个方向：1.）如何继续优化和压缩EZchain的存储、传输成本，提出更多优化算法插件；2.）将EZchain的设计体系应用于图灵完备性的区块链系统中。
7 l3 P2 P+ k3 K% M1 V: l# |引用文献
$ j2 p/ u6 U3 @( [
[1] Mustafa Al-Bassam, Alberto Sonnino, Shehar Bano, Dave Hrycyszyn, and George Danezis. Chainspace: A sharded smart contracts platform. In 25th Annual Network and Distributed System Security Symposium, NDSS 2018, San Diego, California, USA, February 18-21, 2018, 2018.
4 l% u/ {% H$ x  p5 a[2] Iddo Bentov, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. IACR Cryptology ePrint Archive, 2016:919, 2016.
[3] Ittay Eyal, Adem Efe Gencer, and Robbert Van Renesse. Bitcoin-ng: a scalable blockchain protocol. In Usenix Conference on Networked Systems Design and Implementation, 2016.
  ^( W. Q4 H& q7 \9 I+ e* o7 {- b[4] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, Shanghai, China, October 28-31, 2017, pages 51–68, 2017.
[5] Timo Hanke, Mahnush Movahedi, and Dominic Williams. DFINITY technology overview series, consensus system. CoRR, abs/1805.04548, 2018.
2 [; `& _8 @/ l/ h" K# Y[6] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Advances in Cryptology - CRYPTO 2017 - 37th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 20-24, 2017, Proceedings, Part I, pages 357–388, 2017.
[7] Eleftherios Kokoris-Kogias, Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ewa Syta, and Bryan Ford. Omniledger: A secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy, SP 2018, Proceedings, 21-23 May 2018, San Francisco, California, USA, pages 583–598, 2018.
[8] Eleftherios Kokoriskogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. Enhancing bitcoin security and performance with strong consistency via collective signing. Applied Mathematical Modelling, 37(8):5723–5742, 2016.
  p. _( `7 L6 t. n/ k; G  v[9] Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena. A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, Vienna, Austria, October 24-28, 2016, pages 17–30, 2016.
, }* x* a+ g+ A/ K[10] Andrew Miller, Iddo Bentov, Surya Bakshi, Ranjit Kumaresan, and Patrick McCorry. Sprites and state channels: Payment networks that go faster than lightning. In Financial Cryptography, volume 11598 of Lecture Notes in Computer Science, pages 508–526. Springer, 2019.
[11] Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable off-chain instant payments. https: //lightning.network/lightning-network-paper.pdf. January 14, 2016.
& r9 r3 P( c6 J  U[12] Serguei Popov, Olivia Saa, and Paulo Finardi. Equilibria in the tangle. CoRR, abs/1712.05385, 2017.
[13] Zhijie Ren and Zekeriya Erkin. VAPOR: a value-centric blockchain that is scale-out, decentralized, and flexible by design. CoRR, abs/1810.12596, 2018.
[14] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In Financial Cryptography and Data Security - 19th International Conference, FC 2015, San Juan, Puerto Rico, January 26-30, 2015, Revised Selected Papers, pages 507–527, 2015.
0 F8 g" S. X. Z  K1 R, s[15] Yonatan Sompolinsky and Aviv Zohar. PHANTOM: A scalable blockdag protocol. IACR Cryptology ePrint Archive, 2018:104, 2018.
[16] Shuai Xiao, Xu An Wang, and Han Wang. Large-scale electronic voting based on conflux consensus mechanism. In Innovative Mobile and Internet Services in Ubiquitous Computing - Proceedings of the 13th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS-2019), Sydney, NSW, Australia, 3-5 July 2019., pages 291–299, 2019.
[17] Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan-Gueta, and Ittai Abraham. Hotstuff: BFT consensus with linearity and responsiveness. In Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing, PODC 2019, Toronto, ON, Canada, July 29 - August 2, 2019., pages 347–356, 2019.
[18] Haifeng Yu, Ivica Nikolic, Ruomu Hou, and Prateek Saxena. OHIE: blockchain scaling made simple. CoRR, abs/1811.12628, 2018.
: j' |  j8 I8 h6 x[19] Mahdi Zamani, Mahnush Movahedi, and Mariana Raykova. Rapidchain: Scaling blockchain via full sharding. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS 2018, Toronto, ON, Canada, October 15-19, 2018, pages 931–948, 2018.
附录

* P7 [3 ^' Y2 }5 VA. 共识节点是否可以将诚实账户节点的交易重复添加进MTree中，以达到“污蔑”诚实节点的效果？因为每个区块的布隆过滤器是公开且被共识的，因此，诚实节点很容易发现哪些区块，自己明明没有参与（提交交易），但布隆过滤器却包含了自己，那么此诚实节点则可以向发布此块的共识节点发出“挑战”，要求此共识节点把相关证明（为何包含此诚实账户节点）传输给自己。共识节点提供的证明若是合法的，那么要么说明是布隆过滤器的“误伤”，要么是共识节点的重复提交。固可以证明诚实账户节点的“清白”。
B. 创世块规定了所有value的初始化owner，但若若干节点需要自行创建一个内部的循环交易事务，那么只要这些节点认可，完全可以委派一个节点制作一些新的values（不与已存在的创世块中的values有冲突即可）在某个新块中分发给这些节点，即，创建一个新的创世块，这些value和原本的value也是完全可以流通交易的。
C. 利用默克尔树压缩EZchain主链的存储空间消耗。

. E- f+ `8 _+ H" S- |( s( M
<hr/>[1] 又或者节点可以采用“世界状态”进行验证，但这仍然依赖自身或其他节点对于“世界状态”合法性的验证。若基于去中心化的原则，那么对于“世界状态”的验证也同样需要溯源整个区块链的历史信息。

[2] 当然，我们也相信，目前EZchain的设计远非最小的必要信息量。

[3] 此处的值在某些情景下可以理解为token，类似于UTXO交易中选择哪些“前置交易”来进行支付。

[4] 注意这里EZchain主算法并未采用Algorand的共识机制进行解释是由于Algorand共识机制较PoW更为复杂，考虑可读性，我们主要以PoW版的EZchain进行展示解释。

3 x0 F7 }' w  e8 _" I$ {2 c0 g [5] 因为布隆过滤器存在一定的“误判”率，即，将不属于目标集合中的元素（账户地址）包含进来，因此，当某账户被“错误包含”在某个布隆过滤器中时，其需要提供能完全重构此布隆过滤器的信息（即，目标集合的所有元素）来佐证。
9 d) |% o0 \# q, q
[6] 这里我们假定每轮（每个块中）交易的提交中，两个账户之间单向最多只能产生一笔事务，因此对于n个账户节点，每轮最多只能产生n^2笔事务。

牛🐮，[赞同]

related works几乎没写，现在大火的DAG也没咋提，求轻喷

很有意思的概念，期待arxiv的完整版

必须安排[赞同]

“提交一笔事务，需要广播至所有共识节点，并通过它们的验证，即使此事务可能和一些节点毫无关系；在存储方面，每个共识节点本质上都相当于充当了原本的中心化服务节点，冗余存储着世界状态和事务历史的备份。”想邀请作者一起探讨以上观点:个人认为，在去中心化的分布式账本里边，不存在一笔事务与某个共识节点无关，事实上，所有交易都与每个共识节点相关，理由如下，张三给李四进行转账，看似与王五无关，但如果张三和李四是同一个人，他凭空捏造财产给自己，那就相当于稀释了整个系统的财产，让所有其他人的财产贬值，这是一个比较直观的例子，本质应该是传统的中心化背书变成了全网的共同见证，因此传统中心化系统中你的一亩三分不再是你自己的一亩三分地，而是关系到所有人的利益，这也是区块链的基础。存储方面，区块链带来的难以篡改，灾难备份，去中心化最本质的原因就是全网冗余存储，这一点是带有很强的目的性的设计。

弱鸡求问，不知道我有没有理解对：作者这个idea应该是说基于value的唯一性，可以在交易的过程中，只需要交易的双方来验证 ，而不是所有共识节点都进行验证。从而降低验证的开销。
: B; k- `1 }/ k% G3 I3 Z5 K6 {但是这和UTXO模式有什么本质上的区别呢？UTXO中的每一个交易应该也是唯一的。所以我的疑惑跟yousleepfirst那个老哥一样，比特币采用全网冗余的验证和存储，还是为了去避免包括双重支付等问题。
! X; E3 I" K/ Q, {那作者提到的这个基于value的模式，和UTXO到底有什么本质的区别？又或者说，是怎么样在降低了验证成本的同时，还能保证安全性呢？

我也暂时还没有理解跟utxo的区别，不过我的观点是在去中心化的货币系统中，你的一亩三分不再是你的一亩三分地，两个人的交易不再是我们俩认定就可以，共识节点承载的不仅是自己的交易得到验证，还有义务保证全网数据的一致性

接上面，如果只存储自己相关的数据，那么所有节点都存在单点失效，数据丢失的问题，但是去中心化的最大特点就是为了防止单点失效，如果丢了这一点，用区块链到底是在用什么，我们现在面临的难题是不是不用区块链能解决得更好。以上内容可能与作者工作细节不太相关了，单纯想邀请作者一起探讨。[大笑]