ROL:以太坊 Layer 2 资产桥方案解析:Arbitrum、zkSync 与 DeGate Bridge_混biking

以太坊Layer2生态将迎来百花齐放的局面,如何在各Layer2之间以及与Layer1通信或成为一个核心问题。

以太坊自2015年诞生以来,快速成长为最活跃、最繁忙的区块链,无论是从应用的丰富性、链上的资产规模还是从交易量、安全性等指标看,以太坊都是当前无可争议的公链之王。而随着以太坊生态的快速发展,特别是DeFi的彻底引爆,导致原本设计的吞吐量严重不足,根据etherscan.io的每日交易数据统计,当前以太坊TPS在17左右,动辄几十甚至上百美元的Gas费和超长的交易等待时间成为限制以太坊生态进一步蓬勃发展、进入主流世界的主因。

长期以来,整个以太坊社区都在为解决吞吐量和高昂手续费问题而努力,其中一个主要解决方案即以太坊2.0,它将大幅增加每秒交易数量,并将最快于2021年底发布;而如EIP-1559提案,则希望对交易手续费计费方式进行调整,来变相达到降低Gas费用的目的。

与此同时,有一个声音出现了:真的有必要将所有交易都放在主链上计算处理么?

Layer2简介

将本应在以太坊主链即Layer1上处理的交易,转移到Layer2上处理,随后再将结果从L2传回L1确认,我们将这种解决方案称为以太坊Layer2。L2的理论TPS达到了2000-4000,这已经超越了Visa的处理能力——每秒1700笔交易。因此,许多人认为L2方案是以太坊赢得主流用户的关键。

目前存在的L2方案,主要包括以下几个:

OptimisticRollups:数据上链、欺诈证明。应用团队包括Optimism、OffchainLabsArbitrumrollup、FuelNetwork;

ZKRollups:数据上链、零知识证明。应用团队包括Loopring、Starkware、MatterLabszkSync、Aztec2.0;

Validium:数据链下保存、零知识证明。应用团队包括Starkware、MatterLabszkPorter;

Plasma:数据链下保存、欺诈证明。应用团队包括OMGNetwork、MaticNetwork、Gazelle、LeapDAO;

StateChannels:应用团队包括Connext、Raiden、Perun.

需要重点指出的是,侧链方案因为其共识安全性没有继承L1,所以我们并不认为侧链属于L2方案。

在众多方案中,Rollups正逐步取得市场的认可,成为以太坊最可靠的扩容解决方案,一方面该方案直接继承了L1的共识机制和安全特性,另一方面它也不会损害L1的安全性和主权。事实上,Vitalik直言不讳的说过,Rollup是以太坊长期扩容解决方案中可以最快被实现的一个。而Rollups的两种方案OptimisticRollups和ZKRollups最大的区别是它们分别使用了欺诈证明(fraudproofs)和有效性证明(validityproofs)来确保batches里的后状态根(post-stateroot)的正确性。

对于Rollups方案而言,如何将资产从L1存入L2,再从L2提回L1,更进一步的,如何从一个L2网络提取到另一个L2网络,是一个核心问题,我们将承担这一责任的基础设施称为桥。

原生桥实现

我们研究了当前主流的Rollup方案的原生桥实现原理,并从Optimistic和zkSync方案中各选取一个代表,进行对比。

Arbitrum

Arbitrum协议利用其L1、L2之间的通信能力,理论上可以无须信任的将任意形式的以太坊资产在L1、L2之间转移。当将资产从L1转入L2时,资产被存入一个L1上的Arbitrum桥合约中,之后一笔相同数量的资产在L2上被铸造并存入指定地址;而将资产从L2转回L1时,资产将在L2上被销毁,随后等量的资产将在L1的桥合约中变为可用。此外,从L2赎回资产到L1时,有一个关键性的区别是,用户发送交易后,必须等待一个挑战期的结束,才能最终在L1上执行。这是由OptimisticRollup安全模型决定的。

值得注意的是,官方建议使用「可重试票据RetryableTickets」机制进行L1、L2之间的通信。可重试票据的运作方式大致如下:L1向L2发起的交易首先被存入inbox中,并附带calldata、callvalue、gasinfo等交易参数。当这笔交易首次执行失败后,它将被放入L2的「重试缓冲区」中,这意味着在一段时间内,任何人都可以通过重新执行这笔交易来赎回票据。L2至L1的重试交易没有时间限制,争议期结束后的任何时间点都可进行。

这种机制设计主要是为了应对这样的场景:当某个用户希望将某笔token从L1存入L2,首先会将这些token存入L1的桥合约中,同时在L2上铸造等量的token。假设L1上的交易已经完成,但是L2上的交易却因为手续费不足失败了,这会导致一个严重问题:用户在L1上的token已经转出,但是在L2上却没收到token,实际上,这些token被锁在了L1的合约里。通过可重试票据机制,用户,可以在一周内,使用足够的手续费重新执行这笔交易,并最终在L2上获得token。

以下是Arbitrum原生桥的基本步骤:

L1->L2

用户从L1发起Deposit交易

资产存入L1合约,交易被批量存入Inbox中

交易在L2被执行,铸造资产转入指定地址

如果交易失败,则交易被存入L2的重试缓冲区,用户可以在一个挑战期内发起重试

L2->L1

用户在L2发起Withdraw交易

L2链将在一定时间内收集到的交易打包,生成默克尔树,并将根节点作为OutboxEntry发布到L1的Outbox中

用户或者任何人可以对根节点和交易信息进行默克尔验证

挑战期结束后,用户即可在L1完成交易,如果交易失败,则用户可以发起重试。

zkSync

在桥实现上,zkSync和Arbitrum相比,主要的区别在于Withdraw时,对交易的验证采用了基于零知识证明的有效证明,而非欺诈证明,其基本步骤为:

L2—>L1

用户在L2发起Withdraw交易:将交易数据编码为字节串,并使用正确的zkSync私钥对该字节串进行签名,并为交易描述生成Ethereum签名或提供EIP-1712签名,通过相应JSONRPC方法发送交易

发送交易到L1:交易进入zkSyncoperator创建的区块,并发布到L1上的zkSync智能合约中

对区块进行验证:若干分钟后,证明该区块正确性的ZKproof将生成,该proof会通过一个验证交易发布到L1上,直到这个验证交易完成,Withdraw交易完成。

可以发现,在退出时间上,zkRollup方案明显优于OptimisticRollup方案,但由于zkRollup要实现完全兼容EVM尚需时日,所以预计OptimisticRollup仍然会成为前期主流L2方案。也正因此,利用第三方桥来解决OptimisticRollup退出期太长的问题,来带给用户更好的使用体验,成为一些团队努力的目标。

DegateBridge设计理念和实现原理

DeGateBridge的目标是在Rollup生态早期能够帮助以太坊资产迁移门槛最大程度的降低,服务基于以太坊Rollup的二层基础设施的应用大规模落地。我们认为在现阶段基础设施条件下,优秀且足够好的流动性解决方案需要具备:

第一,能够通过市场方式对不同层的流动性分布进行自动调节。

第二,能够实现资金效率最大化的0资金冻结的非预付方案。

第三,最低的Gas消耗和最优的用户体验也至关重要。

DeGateBridge基于优化稳定币AMM曲线和交易市场的方式实现跨层资产转移的快速通道,受限于提供L2状态的预言机的咱不完善,首期的DeGateBridge将通过中心化托管资产的方式实现,当以太坊L2上出现成熟的预言机服务后,DeGateBridge将转向以去中心化的方式实现资产的桥接。

Bridge方案对比

在这一小节中,我们将对已上线生产或者测试网的原生Bridge和DegateBridge进行实测,并主要考察以下几项指标:

上下桥Gas费用;

上下桥时效性;

操作复杂度;

我们在测试中统一使用ERC20代币而非ETH,同时我们按ETH价格$4000,GasPrice为100Gwei对手续费进行拟合。

最终对比结果如下

Withdraw手续费计算方式说明:

Optimism(SNX):提币操作会聚合多笔交易,按总手续费除以交易笔数计算

Arbitrum(Testnet):二层费用不计,只计算一层交易消耗Gas费

zkSync:费用在二层以多种token支付,通过一层到账交易计算大概成本

DegateBridge:费用在二层以多种token支付,通过一层到账交易计算大概成本

通过对比可见:

时效性:OptimisticRollup的下桥时间普遍需要2天-1周,表现较差,DegateBridge的表现较好,接近即时;

Gas费用:Optimism表现最差,DegateBridge的手续费消耗最少,特别是还节省了Approve的手续费;

操作复杂度:DegateBridge可以在无需用户Approve的情况下直接交易,对用户体验更加友好;

展望

我们相信Layer2和以太坊2.0的相继落地,将有机会成为以太坊的二次增长曲线,使以太坊进化为承载数万亿美元规模的经济带宽。而L2Bridge将作为区块链基础设施之一,在这一进程中发挥重要的作用。

撰文:DeGate

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

大币网

[0:0ms0-5:594ms