Rollup Bridge 介绍(六):Orbiter Finance

作者:NicLin,imTokenLabs资深区块链工程师

本文受众:区块链开发者、对Rollup有所了解的区块链爱好者

本篇是RollupBridge介绍系列的第六篇。

OrbiterFinance和这系列介绍过的HopProtocol很相似,两者都透过Rollup本身和L1之间资讯传递的功能来达到跨L2转账的安全性:只要Rollup本身及其L1<->L2讯息传递的功能正常,就能确保使用者转账的安全性,而不需要去相信validator不会作恶。

而HopProtocol和OrbiterFinance主要的差异在于,Hop仰赖合约送出的讯息能够正确地被relay到L1及目标L2,Orbiter则仰赖L2的交易能够正确在L1被读取。而他们的共同点则是有challenge机制,平常预期交易都是合法的,但当有人造假交易或是拒绝完成交易时,一定能够拿出证据证明,并惩罚造假的人。

概念来源

Hop和Orbiter的概念其实都来自于Vitalik在ethresearch的一篇文章,这篇文章介绍的是如何在只有RollupB支援智能合约功能时能够完成从RollupA转账到RollupB的操作。大致上的运作方式是:使用者在RollupA转账给流动性提供者,Maker在RollupB上转账给使用者。如果Maker装死,则使用者可以在RollupB上的合约申请challenge,并提交自己在RollupA转账给Maker的交易证明,证明自己在RollupA的确有转账给Maker。

Cyber Capital创始人:建议以太坊通过Roll-ups或执行分片回到Layer 1扩展:金色财经报道,Cyber Capital创始人Justin Bons在社交媒体上称,以太坊正面临着一个严重的困境,激励机制的大规模错位是造成深度腐败的原因。在Layer 2向这个生态系统倾注资金的推动下,盖过了Layer 1的资金。几百万和几百亿之间的差异是ETH放弃Layer 1扩容的原因,这是很自然的,我们应该期待任何系统性的规模。

问题是,在这种情况下,它导致ETH走错了路,这就是为什么它是一个反常的激励措施,开发者、影响者和领导者在短期内通过遵循Layer 2叙事赚取更多收入,虽然Layer 2通过支持限制Layer 1容量的叙述来赚取更多,但支持通过Layer 2专门扩展这在以太坊网络的长期成功与Layer 2的短期利润之间造成了明显的利益冲突。

我建议以太坊通过Roll-ups或执行分片回到Layer 1扩展,我还应该提到ZKEVM,它仍然受到ETH开发者的关注,并且可以扩展到Layer 1。然而,它的发展太过遥远,目前还不被认为是可行的。我们需要的是链上治理,将资金从区块奖励引导到去中心化的金库。这将创建一个Layer 1倾向的资金来源,能够与对立的利益竞争,这种方法已经被XTZ、DASH和DCR等老牌公链所检验。[2023/5/28 9:46:27]

注:这会需要RollupB能够读取到RollupA的区块或交易记录。

而Orbiter和当初概念不一样的地方就在于当Maker装死、使用者要challenge的时候,实际接受challenge并验证交易的合约不是在RollupB上,而是在L1。因为要能在RollupB上验证交易,表示RollupB一定要支援智能合约。但如果思考一下就会发现,如果Rollup的资讯都会写到L1,而L1又有支援智能合约的话,那就干脆直接统一在L1验证交易就好了!

a16z crypto推出新OP Stack rollup客户端:金色财经报道,a16z crypto工程师ncitron.eth发推称,推出用Rust编写的OP Stack rollup客户端“Magi”,“Magi”执行(op-node)相同的核心功能,并与执行节点(如op-geth)一起工作以同步到任何OP Stack链,包括Optimism和Base。作为一个独立的实现,Magi旨在增强整个OP Stack生态系统的安全性和活跃性。

“Magi”正在开发中,可能需要数月的时间才能成为op-node的可行替代方案。[2023/4/20 14:14:36]

所以Orbiter实际上不需要Rollup支援智能合约,这也让Orbiter能够支援比Hop还多的Rollup。

注:Hop支援的Rollup都必须要能支援智能合约。

架构

如同上面讲到的,Orbiter在Rollup上不需要有合约,但在L1上它需要针对每个Rollup去写相对应的SPV合约,SPV合约的功能就是证明一笔交易存在在该Rollup的区块或交易记录里。

另外在L1上的合约还会包含MakerDeposit合约及EventBinding合约

MakerDeposit合约负责管理Maker的押金,如果使用者challenge成功,会从Maker的押金中补偿给使用者。EventBinding合约负责验证使用者在RollupA送出的交易,包含验证交易格式是否正确,并且它会算出Maker在RollupB「应该」要送出的交易的格式内容。注:会说「应该」是因为Maker有可能会装死。如果今天Maker被challenge了,他就要提出证据证明他在RollupB上真的有转钱给使用者,而这笔转钱给使用者的交易的交易内容就必须要和EBC算出的TargetTx的内容一样。底下是官方提供的流程图,SourceNetwork是RollupA、TargetNetwork是RollupB,ChainX则是L1。图中左边虚线包起来的部分会是正常的交易流程:Maker在RollupB上如实转钱给使用者,皆大欢喜;右边虚线包起来的部分则是challenge的过程,步骤比较繁琐。

zkRollup项目Intmax完成约488万美元种子轮融资:4月13日消息,zkRollup二层网络项目Intmax开发公司Ryodan Systems AG宣布完成约6.5亿日元(约合488万美元)种子轮融资,HashKey Capital、Scroll、Yusaku Maezawa旗下MZ Web3 Fund和Alchemy Venture,以及以太坊密码学家Justin Drake和前Coinbase首席技术官Balaji Srinivasan等天使投资人参投。

该公司表示,将利用zkRollup建立基于以太坊加密技术的基础设施,从而实现近乎零的gas成本和数据主权,此外Intmax预计将在2023年第二季度(4-6月)在以太坊主网上开始试运行,第四季度(10-12月)进行主网上线。[2023/4/13 14:01:19]

流程

正常情况

使用者到MDC合约确认Maker资讯,包含押金数量、收取的手续费高低,及透过过往历史看到的Maker的表现使用者在RollupA转钱给MakerMaker侦测到RollupA有人成功转钱给他Maker把SourceTx喂进去EBC合约,算出TargetTx的内容,例如TargetTx转给使用者的金额会是扣掉保留给自己的手续费的金额不正常情况

接续自使用者在RollupA转钱给Maker之后,Maker没有在时限内在RollupB转钱给使用者

使用者首先先到RollupA的SPV合约证明SourceTx的存在,这个proof会存在SPV合约的storage,等待MDC合约来查询使用者接着到MDC合约申请仲裁MDC合约收到仲裁申请后会去SPV合约拿SourceTx的proof,并请EBC合约验证SourceTx的有效性,都确认没问题后就开始倒数,等Maker来回应如果Maker过了一段时间都没有来回应,则使用者可以触发MDC合约作出仲裁,在L1上完成TargetTx,从Maker的押金转给使用者,其中会包含补偿金手续费

Vitalik:Rollup有可能使以太坊TPS达到每秒10万笔交易,甚至更多:7月24日,“2021世界区块链大会·杭州”在杭州未来科技城学术交流中心开幕。以太坊创始人Vitalik Buterin(V神)受邀出席并发表主题演讲《以太坊进入2.0之后,会发生什么?》。他表示,现阶段, Rollup可以扩展到每秒大约4000到5000笔交易。假设整个以太坊生态都可以用上Rollup,然后有了数据分片之后,我们可能有20到50倍更多的空间。Rollup有可能使以太坊TPS达到每秒10万笔交易,未来甚至更多。分片首先会添加一些基础的安全性,然后再增加更多的安全性,然后分片会迎来越来越多的改进。(巴比特)[2021/7/24 1:12:51]

Maker在存押金到MDC合约时,要指定他会收取的手续费比例,所以TargetTx转的金额会以MDC合约里记录的手续费为准,例如假设Maker手续费指定为1%,使用者在RollupA送1Ether到Maker地址,则Maker应该要在RollupB送0.99Ether给使用者。

如果被challenge,Maker要提供TargetTx到RollupB的SPV合约。如果Maker转错转成0.98Ether,则Maker要自己认赔,因为EBC合约算出来TargetTx里转的金额就一定要是0.99Ether。

Maker押金

为了避免出现多个使用者同时转钱给Maker,导致Maker因为其押金小于总共收到的金额所以选择装死的情况,Orbiter有针对不同Rollup订出不同押金规则:

SpringRole集成印度支付网关服务RazorPay:区块链专业身份认证平台SpringRole集成印度支付网关服务RazorPay,以接受那些希望在求职时需要自我验证的用户的付款。SpringRole由人力资源技术公司Springworks所有。SpringRole允许用户实时验证身份、就业和教育证书,并将这些信息作为永久记录写入去中心化区块链。(BusinessWire India)[2020/8/6]

1.针对支援合约功能的Rollup,我们可以把一个Rollup区块拆成更小的单位slot。

假设可以拆成5个slot,那Maker抵押的押金就是5倍的limit。limit是协议订的最高的转账金额上限。2.针对不支援合约功能的Rollup,则要看那个Rollup一个区块最高可容纳多少笔交易。

例如zkSync1.0的TPB约是100,那Maker抵押的押金就是100倍的limit。这两个规则都可以看出,Orbiter为了防止Maker收到大于其押金金额的转账而有动机选择装死的情况,它参考的依据是一个区块最多可以塞多少笔交易,并假设最差的情况就是刚好一个区块塞满的交易都是转账给同一个Maker的交易,这种情况Maker的押金刚好能够cover所有的转账请求。

MakerAPY

这个链接里有Orbiter团队利用过去一个月的数据来估算Maker的APY:

可以看到,如果将这段时间的平均转账金额当作limit的话,在不同Rollup的TPB对应到的不同押金数量。再搭配上这段时间的流动性总额及日均手续费获利,可以算出预期的APY。

可能的问题

不支援指定接收地址

Orbiter目前还不支援指定RollupB的接收地址,如果要支援指定接收地址,会需要挪用Rollup交易里其他栏位。像是目前Orbiter就挪用转账金额的最小的几个位元来当作不同Rollup的识别码。

经济激励机制尚不完整

使用者要challengeMaker是不需要放押金的,表示使用者challenge的成本很小,这是否会让使用者有动机每次都去challengeMaker,只要Maker忘记回应challenge或是Maker转账完就离线,那使用者就有机会获得额外的报酬。

但引入challenger押金的机制也会有一些问题,像是

使用者必须要在L1有钱才可以challenge而且Orbiter的补偿金是固定的,不像Hop的challenge机制里奖金和金额成比例另外Hop里会有第三方有经济动机成为challenger,但在Orbiter里只有使用者自己才有动机去challenge,因为那笔转账会影响的只有使用者自己而已,不像Hop里造假影响的会是其他Bonder押金机制针对极端情况的处理还不完整

押金的参考依据是一个区块最多能塞下几笔交易,再假设最糟情况是一个区块都是转账给同一个Maker,所以Maker的押金是TPB*limit。

但这只要有交易还在pending中、没被完成,就能绕过这个押金机制的防护,因为pending中的交易是在之前的区块,如果在有pending交易的情况下出现最糟情况?-?区块里大家同时转账给该Maker,则这时候Maker收到的总金额就会超过他的押金,他就有动机装死了。

我们可以反过来请使用者在看到一个Maker有pending交易时,先不要动作,等到pending交易都完成后再转账给Maker。但第一个问题是如果有很多人同时要透过同一个Maker,使用者会不知道要等多久。第二个问题是如果使用者都等待其他人的交易处理完才转账,那表示基本上一个区块就只会有一个转账,那这样设置TPB*limit的押金机制就没有意义了。

不过这其中当然还有可以更细致的调整可以尝试,例如依照使用者的风险承担程度,去决定当前pending金额占Maker押金多少百分比的情况下,使用者愿意送出交易。就看未来Orbiter团队会怎么设计。

如果要接上的Rollup可以接受InvalidTx,且要支援nativeasset以外的转账,会有挑战性

针对会收入InvalidTx的Rollup,而且要转账的不是nativeasset而是ERCtokens时,会有点棘手,因为这种情况下协议不只要能证明交易存在,还要能证明执行成功,因为交易存在不等于交易执行成功,就像当前在区块链你可以看到失败的交易还是会被收入到区块里面。

如果不证明交易执行成功会发生什么事?攻击者可以做一笔InvalidTx夹带在其他使用者的ValidTx后,然后去challengeMaker。

注:InvalidTx和ValidTx的转账内容一样,只是攻击者余额不够所以交易会失败。

考慮以下三種驗證機制

1.如果协议像当前的设计,只验证交易存在、发生过。那攻击者只要证明InvalidTx被收录在Rollup的区块里就好,challenge一定可以成功,表示Maker要平白无故赔钱给攻击者。

所以我们除了验证交易存在,还要验证state的变化,确保Maker的余额有增加。

2.协议除了验证交易存在,还验证区块前后的state变化,确认Maker的余额是否真的增加了。但攻击者这时候只需要将InvalidTx和使用者的ValidTx夹带在同一个区块就可以,因为协议单靠区块前后state变化,分不出Maker余额增加是因为使用者的ValidTx还是攻击者的InvalidTx。

3.协议除了验证交易存在之外,还要能验证交易前后的state变化。如此协议才能确认交易真的有导致Maker的余额增加。

加入3.这样的验证机制除了会更复杂之外,这会需要Rollup本身有commit每一笔交易的post-stateroot。如果没有的话,就只能退而求其次,在那个Rollup上只开放nativeasset的转账,因为nativeasset的转账失败不会被收录到区块里。

Hop和Orbiter比较

Orbiter能够支援没有智能合约功能的RollupOrbiter架构会比Hop简单,合约也比Hop少很多Orbiter主要只会focus在nativeasset的转账,Hop则是除了nativeasset外,也能支援ERCtoken转账Hop需要仰赖AMM有足够的流动性,否则除了Bonder向使用者收的手续费外,AMM的价格太差还会导致使用者换不到或损失更多钱极端情况下,Orbiter使用者可能因为Maker装死、押金也不够付,所以拿不到钱,但Hop只要Rollup运作正常,使用者就一定能拿到该拿的钱Orbiter的Maker的在L1的押金是没办法挪作他用的,而且会是一笔不小的金额,而Hop对Bonder则没有这个要求,除非真的发生challenge风险提示:本文内容均不构成任何形式的投资意见或建议。imToken对本文所提及的第三方服务和产品不做任何保证和承诺,亦不承担任何责任。数字资产投资有风险,请谨慎评估该等投资风险,咨询相关专业人士后自行作出决定。

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

银河链

[0:31ms0-2:167ms