1. 综述

随着Defi应用的爆炸式发展,以太坊上已经部署了大量的去中心化应用。不幸的是,以太坊作为最广泛使用的智能合约平台却受限于可扩展性无法满足终端用户的海量需求。不仅如此,以太坊Dapp用户体验较差,不益于普通用户使用。已经有很多这样的例子,即以太坊上一个应用短时间内具备极高热度、参与用户剧增,直接导致整个以太坊网络瘫痪。具体而言,以太坊目前存在以下问题:


a. 较低的交易吞吐量

为保证有充足的时间使得区块能够在网络中广播,以太坊在相邻两个块之间维持了一定的延迟时间。不仅如此,区块也需要足够的“小”去保证在网络中快速同步,使得以太坊单一区块中所包含交易数量受到严重限制。两点设计共同导致以太坊网络的交易吞吐量较低。

b. 高昂的交易费用

随着区块链生态系统的迅速增长,加密资产被创建、转移和买卖的频率越来越高。同时,大多数的去中心化应用也有自己本身的通证和经济体系。在区块链系统中为服务付费或者完成任何事件都需要在链上发送交易。以太坊对链上所有交易都收取一定的Gas费,而这笔费用目前已经足够高昂去限制链上Defi应用的操作。


c. 较差的用户体验

由于较低的交易吞吐量以及高额的交易费用,以太坊上DApp应用的交互成本较高且存在相当程度的延迟。因此用户在使用Defi产品时体验较差。


X-Rollups是一个全新的以太坊二层解决方案,旨在解决以太坊目前存在的可扩展性和可用性问题,同时仍保持完全去中心化以及与现有开发者社区和生态的完全兼容。与已有的二层扩容方案相比,X-Rollups在安全性、兼容性、可扩展性和延迟性上均具备优势。


2. X-Rollups技术细节

2.1 系统架构

X-Rollups的整体系统架构见图1。Layer1是以太坊,存在有限交易吞吐量和高额交易费的缺陷;Layer2是万维链,具备高交易吞吐量和低交易费用的优势。任意开发者可以将其DApps从Layer1迁移至Layer2,同时用户也可以将自己的资产从Layer1迁移至Layer2以获取更好的用户体验。不仅如此,用户还可以随时将其资产从Layer2提取回Layer1,提取过程基本不存在延迟。整个X-Rollups协议的安全性和鲁棒性是由Layer Connector所保证,它在Layer1和Layer2之间建立一个通道去完成资产的转移和信息的验证。


图 1. X-Rollups的系统架构

2.2 角色

Layer Connector是由两类角色所运行,即Storeman和Voucher。二者所承担的工作内容和职责描述如下。


Storeman

Storeman负责在Layer1和Layer2之间完成资产的转移。具体而言,Storeman组对Layer1上智能合约L1-Asset Management Contract和Layer2上智能合约L2-Asset Management Contract发生的事件进行全天候监听。当用户在Layer1向L1-Asset Management Contract存入资产后,Storeman组将其进行锁定,同时在L2-Asset Management Contract为用户铸造等量资产,完成资产从Layer1向Layer2的转移。同样地,当用户将资产转入L2-Asset Management Contract烧掉后,Storeman组将向L1-Asset Management Contract发送一笔提款交易将资金转回用户账户,完成资产从Layer2向Layer1的转移。


Voucher

Voucher负责将Layer2的区块信息注入Layer1,保证Layer1能够对Layer2的任意交易进行合法性验证。具体而言,Voucher组运行Layer2全节点,本地维护Layer2的最新区块数据,并且定期将Layer2的区块头压缩打包注入Layer1。通过这些注入的信息,Layer2自动地与Layer1达成锚定。


需要强调的是,Storeman组和Voucher组的成员是从社区随机选择,每个成员要求在Collateral Management Contract存入一定量的抵押金。如果节点在工作过程中出现恶意行为(如发送虚假提款交易或注入错误区块头数据),那么其抵押金将会被没收以补偿用户可能的损失。


2.3 智能合约

在X-Rollups中,供需部署五个智能合约,其中两个个需要部署在Layer1,三个需要部署在Layer2。


L1-Asset Management Contract (L1-AMC)

L1-AMC是部署在Layer1的智能合约,用于管理用户的原始资产。它有两个基本的函数,即存款函数和提款函数。任何用户可以通过向L1-AMC发送存款交易来调用存款函数,将资产锁定在智能合约。提款函数则只能被Storeman组通过发送提款交易来调用,完成2Stage-Proof验证,将锁定原始资产提取到用户账户。


State Management Contract (SMC)

SMC是部署在Layer1的智能合约,用于存储注入的Layer2被压缩区块头数据,只能被Voucher组调用。每次Voucher组注入新的区块头数据,SMC中存储的区块头数据Merkel根都会更新(图2)。


图2. SMC合约中Merkel根更新过程


需要强调的是,SMC中存储的Merkel根数据是必要的,将Layer2和Layer1进行锚定,能够用于验证Layer2上任意交易。这个设计使得X-Rollups与已有方案相比实现了更高的压缩效率,极大的降低了SMC存储空间的占用。


L2-Asset Management Contract (L2-AMC)

L2-AMC是部署在Layer2的智能合约,用于管理用户的映射资产。它有两个基本的函数,即铸币函数和烧毁函数。铸币函数只能由Storeman组通过向L2-AMC发送铸币交易来调用,为用户在Layer2产生映射资产。烧毁函数能够被任意用户通过发送烧毁交易而调用,完成映射资产在Layer2的烧毁。


Twin Contract (TC)

TC是部署在Layer2的智能合约,是Layer1中智能合约在Layer2上的孪生,二者具有完全一致的运行逻辑和使用方式。相同的交易会在TC和原始智能合约中产生相同的输出。因此用户自由地在Layer2中与TC交互,然后再将运行结果返回Layer1。


Collateral Management Contract (CMC)

CMC是部署在Layer2的智能合约,用于管理Storeman和Voucher的抵押金。它通过完整的经济激励机制(奖励/惩罚)去保障各节点能够诚实运行协议。具体而言,输入节点的工作记录后,CMC会自动分析其行为。诚实行为将会被奖励,而恶意行为将会导致其抵押金被没收。整个过程是公平且完全去中心化的。


2.4 核心算法

a. 基于门限签名的共识算法

基于门限签名的共识算法(TSS-based Consensus ,简称TBC)用于在Storeman组和Voucher组成员内部对Layer1和Layer2上的数据达成共识。门限签名算法是区块链系统设计中常见的密码学组件,被广泛应用于跨链方案和数字钱包中。简而言之,一个(n,t)门限签名算法将签名的权力分配给个n节点,不少于t个节点可以合作产生合法签名。签名过程与共识过程非常类似,一旦签名生成,那么必然代表其中至少t个节点认同签名的内容,这是TBC的根本逻辑所在。与拜占庭共识算法相比,TBC具备更高的灵活性,而且共识过程中计算复杂度和空间占用均更低。


TBC的执行流程如下(图3):


  1. DKG阶段:在这一阶段,所有节点共同执行联合Feldman秘密分享,输出一个共同的签名公钥,同时每个节点掌握对应私钥的一个私钥碎片。需要强调的是,这一过程只在TBC共识建立时执行一次。


  1. 共识阶段:在这一阶段,所有节点尝试某一数据达成共识。一个节点如果认为数据合法,则在本地用自己的私钥碎片对数据进行签名,并将产生的签名碎片广播给其他节点。同时每个节点也在不断收集网络中的签名碎片,只要收集到t个签名碎片即可通过拉格朗日插值共识计算得到完成签名。最后将完成签名与DKG阶段产生的公钥进行验证,如果验证通过,则节点对数据达成共识。


图 3. TBC工作流程

b. 增强压缩算法

数据压缩一致是决定Rollups方案可扩展性的关键因素。增强压缩算法(Enhanced Compression Algorithm,简称ECA)用于完成对注入Layer1数据的压缩。ECA将Layer2完成区块链数据压缩为一个32字节长度的值,用于验证Layer2上任意交易的合法性。与已有的Rollups方案压缩算法相比,ECA将压缩的对象由交易改进为区块头,然后再将压缩后的区块头构造成一个Merkel树,实现了更高的数据压缩效率。ECA的执行过程如下:


Step 1:对区块头中数据进行缩减

Layer2的区块头共包含有16个参数,其中大多数与数据的验证并无关系。因此在ECA中,要将这些无用的参数进行缩减,仅保留三个核心参数,即ParentHash、Root和TxHash。ParentHash可用于验证区块高度,Root可用于验证账户状态,TxHash可用于验证交易的合法性。通过这一步骤,Layer2区块头由超过516字节降低至96字节。细节见表1。

表 1. ECA区块头数据结构

Parameter

Layer2 Block Header

ECA Block Header

ParentHash

32 Bytes

32 Bytes

UncleHash

32 Bytes

——

Coinbase

20 Bytes

——

Root

32 Bytes

32 Bytes

TxHash

32 Bytes

32 Bytes

ReceiptHash

32 Bytes

——

Bloom

256 Bytes

——

Difficulty

8 Bytes

——

Number

8 Bytes

——

GasLimit

8 Bytes

——

GasUsed

8 Bytes

——

Time

8 Bytes

——

Extra

Not Fixed

——

Extra2

Not Fixed

——

MixDigest

32 Bytes

——

Nonce

8 Bytes

——


Step 2: 通过哈希计算将ECA区块头压缩为32字节

最终的区块头数据是ParentHash、Root和TxHash的哈希值:

BH=SHA256(ParentHash,Root,TxHash)


这一操作能够进一步减少63字节的存储空间。虽然在后续交易的验证过程中会引发额外的计算量,但是在存储受限的应用场景中仍然是必须的,是时空折衷的结果。


Step 3: 将ECA区块头构建为Merkel树

通过Step1和Step2,Layer2的区块头数据已经由超过516字节降低至32字节。但是将Layer2所有区块头数据都注入Layer1仍然是不现实的,因为占用的空间随区块头的数量线性增长。为解决这一问题,我们构造了ECA区块头数据的Merkel树,只有Merkel树的树根是存储在Layer1的。每次Voucher组提交新的区块头数据时,Merkel根都会进行更新。


通过以上三个步骤,Layer2的整个区块链数据就被压缩为一个32字节长的值,也就是Merkel根。


c. 2-Stage Proof

2-Stage Proof用于通过存储在Layer1的Merkel根去验证Layer2上任意交易的合法性。一个2-Stage Proof由两个部分构成,即一阶证明(First Stage Proof,简称FSP)和二阶证明(Second Stage Proof,SSP)。FSP用于证明“存在一个交易tx在Layer2的区块头为bh的区块中”;SSP用于证明“bh是Layer2某个合法区块的区块头”。结合FSP和SSP,即可证明tx是Layer2上合法交易。我们通过图4来展示这一过程。


图 4. 2-Stage Proof验证路径


为证明交易Tx1的合法性,构造2-Stage Proof如下:


  1. 构造FSP:

ECA_BH3=(ParentHash,Root,TxHash)

FSP={Tx1,Tx2,Tx34,ECA_BH3}


  1. 构造SSP:

BH3=SHA256(ECA_BH3)

SSP={BH3,BH4,BH12}


  1. 将两个证明进行组合:

2StageProof={FSP,SSP}


2-Stage Proof是合法的当且仅当以下等式成立:

TxHash=SHA256(SHA256(Tx1,Tx2),Tx34)

BH3=SHA256(ECA_BH3)

BHRoot=SHA256(BH12,SHA256(BH3,BH4))


2.5 X-Rollups工作流程


在以上概念和算法的基础上,我们现在介绍X-Rollups的工作流程:


准备阶段(Preparation Stage)

  1. 在Layer1上部署智能合约L1-Asset Management Contract和State Management Contract;
  2. 在Layer2上部署智能合约L2-Asset Management Contract、Twin Contract和Collateral Management Contract;
  1. 完成Storeman组和Voucher组的选举;
  2. Storeman组和Voucher组执行TBC的DKG过程,生成签名公钥和各节点的私钥碎片。


工作阶段(Working Stage)

  1. 用户从其原始账户(即图1中L1-Address)向L1-Asset Management Contract发送存款交易,存入ETH或者其他ERC-20通证;
  2. Storeman组发现用户存款交易后,对存款信息(如存款人地址、资产类型、资产数额等)通过TBC进行共识;
  1. 基于达成共识的内容,Storeman组构造一笔铸造交易,发送到L2-Asset Management Contract为用户在Layer2的地址L2-Address铸造相等数量的映射资产。需要注意的是,L2-Address与用户Layer1的地址L1-Address共享同一私钥;
  2. 用户利用私钥控制L2-Address中的映射资产,发送交易到Twin Contract以极低成本参与Layer2的Defi应用。


提款阶段(Withdraw Stage)

  1. 用户从L2-Address发送一笔烧毁交易到L2-Asset Management Contract将其在Layer2的映射资产烧毁;
  2. Storeman组发现烧毁交易后,对烧毁信息(如用户地址、资产类型、资产数额等)通过TBC进行共识;
  1. 基于达成共识的内容,Storeman组构造一笔提款交易发送到L1-Asset Management Contract;
  2. L1-Asset Management Contract从State Management Contract中获取到区块头的Merkel根,然后对提款交易中的2-Stage Proof进行合法性验证,如果验证通过,则将资产提取到用户L1-Address。


需要强调的是,Voucher组提交Layer2压缩区块头的频率可以根据实际应用场景灵活确定,可以从准备阶段结束后就定时将区块头数据注入Layer1,也可以在发现链上用户提款交易后再注入相应的区块头数据。


3. 安全性分析

X-Rollups的安全模型基于以下两个假设

  1. SHA256是碰撞免疫的;
  2. Storeman/Voucher组诚实大多数


SHA256是碰撞免疫的SHA256

X-Rollups使用SHA256用于数据压缩,而密码学界的普遍共识是SHA256是碰撞免疫的。我们有以下定理:

定理:


如果SMC中存储的区块头Merkel根是合法的,那么任何一个PPT攻击者都无法为Layer2的非法交易伪造2-Stage Proof。


证明:我们证明如果存在一个攻击者A能够为Layer2的非法交易构造2-Stage Proof,那它也一定能够破坏SHA256碰撞免疫的性质。如图5所示,A成功构造出非法交易的2-Stage Proof如下:

FSP'={Tx'3,Tx'4,Tx'12,ECA_BH4}

SSP'={BH'3,BH'4,BH'12}

2StageProof'={FSP',SSP'}


根据2-Stage Proof的定义,我们有以下等式:

BHRoot=SHA256(BH'12,SHA256(BH'3,BH'4))


Tx1是Layer2的一个合法交易,因此对应于一个2-Stage Proof:

BHRoot=SHA256(BH12,SHA256(BH3,BH4))


将以上两公式合并,我们有:

SHA256(BH^'12,SHA256(BH^'3,BH^'4))=SHA256(BH12,SHA256(BH3,BH4))


x1=(BH^'12,SHA256(BH^'3,BH^'4))x2=(BH12,SHA256(BH3,BH4)),那么有

x1≠x2

SHA256(x1)=SHA256(x2)


因此构造出SHA256的一个碰撞实例,打破了其碰撞免疫的性质。而根据假设,SH256是碰撞免疫的,因此A无法为Layer2上非法交易生成2-Stage Proof。证明完毕。


图 5. 为非法交易构造2-Stage Proof


Storeman/Voucher组诚实大多数

X-Rollups在TBC共识算法中使用(t,n)门限签名,满足t≥n/2+1。因此在诚实大多数假设下,我们有以下事实:

  1. 所有铸币交易、提款交易都至少由一个诚实的Storeman签名;
  2. 所有注入的区块头数据至少被一个诚实的Voucher签名。


事实1保证了用户资产的安全性,而事实2保证了存储在Layer1的Merkel根的合法性。


虽然诚实大多数是区块链领域中一个常见安全假设,但是很多区块链协议都面临参与者合谋攻击的风险。为解决这一问题,我们提出以下两个方案:


方案1:匿名参与

如图6所示,Storeman/Voucher节点的选举分为两个阶段。在第一阶段,从社区中随机选取一定数量的节点;在第二阶段,每个节点被分配Storeman或Vouvher角色,而分配的过程是基于环签名和隐蔽地址技术实现,保证角色的匿名性。因此在X-Rollups中,各节点不知道其他节点的现实真实身份,也不知道其他节点的角色。这一匿名性极大的提升了合谋攻击的难度。

图 6. Election of Storeman/Voucher组成员选取过程


方案2:子组

在这一方案中,Storeman/Voucher组被进一步分为多个子组(Subgroup)。每个子组中节点独立执行DKG过程,使得合谋攻击的难度提升。不妨设Storeman组由10个节点构成,如果其中6个人合谋,就一定能够控制整个组,完成合谋攻击。但是如果将10个节点进一步分为两个子组,每个子组由5个节点组成。这样的话,只有分别控制每个子组中的3个节点才能够完成合谋攻击。显然,子组的建立使得合谋难度提升。事实上,合谋难度的随子组数量的增加指数上升。理论上,通过这种方式可以彻底抵御合谋攻击。


4. 同类方案比较

在本部分,我们将X-Rollups与Optimistic Rollups和ZK Rollups进行比较,比较的内容为数据可用性、交易合法性、兼容性、可扩展性和延迟性。


数据可用性

Optimistic Rollups和ZK Rollups都是将Layer2的交易压缩后存入Layer1以实现数据的可用性。X-Rollups中,Voucher组定期向Layer1注入压缩后的Layer2区块数据头,同样实现了数据可用性。不仅如此,Layer2的实体为万维链,其作为公链的活性和韧性进一步提升了数据的可用性。


交易合法性

在Optimistic Rollups中,Layer2交易的合法性是由欺诈证明保证的。因此至少需要一个诚实节点执行完所有Optimistic Rollups的交易并且当有非法交易提交到Layer1时提交对应的欺诈证明,这使得Optimistic Rollups容易遭受拒绝服务攻击。在ZK Rollups中,状态的迁移只有当Rollups智能合约对其零知识证明验证通过后才是有效的。不幸的是,零知识证明系统的建立需要trusted setup过程,并且计算复杂度很高。在X-Rollups中,Layer2交易的合法性是由2-Stage Proof保证的,通过存在Layer1中的区块头Merkel根可以完成验证。由于诚实大多数假设,Voucher组能够始终在Layer1中维护一个合法的区块头Merkel根。因此,没有任何一个非法交易能够通过Layer1的验证。


兼容性

Optimistic Rollups的虚拟机OVM能够实现任意的智能合约逻辑,因此几乎所有以太坊上应用均可被支持,可以基于EVM、EWASM或者其他任何虚拟机。ZK Rollups则具备较低的兼容性,因为已有的零知识证明是为特定的应用所设计,如通证转移或者原子交换。X-Rollups具有极高的兼容性,因为万维链是以太坊的一个分叉,因此所有以太坊上的生态应用均可到万维链上,甚至无需修改代码。


可扩展性

可扩展性的决定因素是压缩效率,高压缩效率意味着高可扩展性。Optimistic Rollups和ZK Rollups都是将交易作为压缩的对象。Optimistic Rollups的吞吐量为450 TPS,而ZK Rollups的吞吐量约为680 TPS。作为对比,X-Rollups使用ECA作为数据压缩算法,选取区块头作为压缩对象而不是交易,因此实现了更高的压缩比率,更高的可扩展性。理论上X-Rollups能够达到10000以上TPS。


延迟性

Optimistic Rollups为保证安全性,为欺诈证明提供了一个1到2周时间窗口。在此期间,无论是内部Rollups交易还是退出交易都不具备最终确定性。因此Optimistic Rollups存在1到2周的延迟性。而零知识证明目前需要大量的计算量,据测试在普通计算平台上生成1000笔交易的零知识证明需要大约20分钟。因此ZK Rollups的延迟性大概为20分组。X-Rollups中,延迟来源于Voucher组提交区块头的时间段,少于5分组。因此X-Rollups的延迟性约为5分钟。

5. 结论

X-Rollups是一个全新的以太坊Layer2解决方案,具备高效率和低延迟的优势。它可以为第三方的去中心化应用构建一个可扩展的、用户友好的平台。潜在的应用包括支付、原子交换、流动性、去中心化交易所、借贷等。我们相信X-Rollups会是Defi时代中一个具有竞争力的Rollups扩容方案。