weixin_39619174
weixin_39619174
2020-12-01 15:07

sponsor attack

该无成本攻击以及在微信群中沟通,这里同步下聊天内容:

七哥: cETH 是不是启用了代付功能? 是不是意味着,我转账 cETH 给合约,这个费用也是被代付的? QB: 是的 QB: 跨链的cToken都支持代付 七哥: 有上限的吗? 王凡: 一笔最多代付1cfx 七哥: 不够部分,可以自动被用户支付吗? QB: 是for gas fee吗?那for collateral呢? 王凡: collateral不限 QB: 那矿工岂不是可以薅羊毛了? 七哥: 反馈一个可利用攻击点:利用 cToken ERC777 的 tokensReceived,功能,我可以无限给自己的合约转账,大量消耗 cToken 的代付费用,但不会有任何经济损失。

目前我的合约高度依赖 tokensReceived 回调,这意味着,我的DAPP一部分费用实际是被 cToken 代付的。 七哥: 无成本攻击 Spark: 嗯,如果发现这样的行为,可以把这个账户踢出白名单[呲牙] QB: 赞助费用完就没了 七哥: 但你的 cToken 的代付就失效了,意味着代付功能很鸡肋。 小蜗牛: 可以加一些针对普通单个用户的访问次数? 白名单也分级别 QB: 因为现在不是真金白银,否则代付的gas fee上限不会那么高 QB: 也就意味着,代付会控制gas QB: 原则上,cToken的代付可以限制gas不超过10万,collateral不超过2个存储项 七哥: 反正基于目前的设计:

  1. 你的代付赞助费,可以被攻击者统统干趴
  2. 你无力预防 QB: 是可以,但攻击者也得不到什么,只是都给矿工了 七哥: 我只是想知道:

  3. 当 cToken 的代付赞助费不足以支付一笔交易费用时,是否让用户同时支付全部或不足部分?

  4. 如果交易超出代付的Gas上限,那么剩余部分是否可以让用户支付? Ytudio: 是有一些攻击者不考虑收益,只干坏事的。 QB: 代付更适合于上层dapp合约,冠名赞助商实现代付。 QB: cToken这种基础层面的合约确实不适合加代付,尤其对所有用户开放 Hunter PM: 可能需要考虑矿工同时就是攻击者 😂 七哥: 要相信攻击者永远存在😁 小蜗牛: 波场的转账也不需要gas费,他们是根据时间会给用户免费的能量和带宽,初始的时候这两个值都是0,随着时间的增长这两个值都会变大,最大值是5000。转账的时候可以使用能量和带宽,就不用消耗trx(trx是波场代币)。但是当能量和带宽不够用的时候,就会花费自己的trx。 我们的sponsor是否可以借鉴这种机制。也根据时间来限制是否由sponsor来承担gas费。也提供一个类似能量的概念,初始给一个小的能量值,能量随时间增长,可以当gas使用。但是始终有一个范围使得不能无限免费发送交易。 QB:  这取决于你合约怎么设计,如果存在薅羊毛的可能,那么就不用代付功能,或实行白名单代付 QB: 波场这个功能不一定是完全去中心化的解决方案吧 小蜗牛: 这个机制的本质就是防止无成本攻击的。 小蜗牛: 一方面可以让用户免费使用,一方面又限制了使用能力 QB: 功能是挺好的,不过实现起来,在公链层面未必容易 QB: 不可能去track每个用户免费使用gas的情况 QB: 又多一堆存储 小蜗牛: 嗯,得记录每个用户的状态 七哥: 能不能不要把 conflux 设计得这么胖,我看中的是Conflux的高性能,不是雪上天花的功能[Facepalm]。 小蜗牛: 这只是讨论哈😂 小蜗牛: 而且也只是针对sponser内置合约这块的,不是公链层面的 七哥: 每次重拾对Conflux的信心后,又会被打压一次。

当前Conflux系统层设计的防重入攻击、代付 ,虽然很好,但得先设计严谨下,后面慢慢上线都是可以的。功能越多,漏洞越多。先上线树图PoW共识算法,让生态繁荣,让更多的以太坊系、EOS系的DAPP可以迁入到Conflux才好呀。

做了一堆功能,万一上线没几天就爆出重大漏洞,情何以堪,何以翻身? 七哥: 不求一炮而红,只求生生不息! 七哥: 我想Conflux应该还有很多我还没发现的功能,这些功能是否严谨?有没有漏洞?满满的担忧...... FanLong: ,sponsor单次可以设置上线,总量也是有上限的。极限下被攻击也就是单次总量是上限,需要生成大量的交易,而且还收不到攻击者那里,只能到矿工那里去。

Conflux存储和交易都需要手续费,生态需要一种方式来冷启动。比起airdrop或者长期来看完全不合理的免费,能控制和逐步退出的sponsor机制是我们的选择 FanLong: 和大规模airdrop给所有潜在开发者,却大多数被直接去二级市场交易掉。sponsor已经是最不坏的机制 QB: 羊毛薅完以后,至少会fallbakc到用户自己付费 QB: 对用户而言,只有好处,没有坏处,不挺好的吗 gavin: ddos攻击者也得不到什么,只是竞争对手趴下了 Spark: 功能在我们的spec里都有描述,可以去参考 QB: 这里没有任何人受影响,除了赞助商,有什么问题呢? QB: 就是赞助费被浪费了而已,另外,dapp使用代付的时候,是需要自己去考虑是否适合代付的 七哥: 1. sponsor单次可以设置上线,总量也是有上限的。

这个会不会影响我的DAPP,我的两个顾虑 1. 当 cToken 的代付赞助费不足以支付一笔交易费用时,是否让用户同时支付全部或不足部分? 2. 如果交易超出代付的Gas上限,那么剩余部分是否可以让用户支付?

  1. 需要生成大量的交易,而且还收不到攻击者那里,只能到矿工那里去。

    攻击者不需要任何理由就可以攻击啊,比如我现在需要倒逼你们修改机制,我就可以对 cETH 发动攻击,是否会影响到 MoonDEX呢?

  2. 能控制和逐步退出的sponsor机制是我们的选择

    我也觉得这个功能挺好的,我也很喜欢。

  3. sponsor已经是最不坏的机制

    机制的好还标准是多面的,对用户有利仅仅是一个方面而已。是否会构造系统性风险?是否有副作用?对DAPP是否友好 ....这个值得思考。

我作为用户双手赞成代付机制。 QB: 赞助费不够的时候是用户自己付费的 QB: 但是一笔交易执行过程中,赞助费不够了,貌似是会fail。 ,目前是这个行为吧? QB: 我看目前的文档里这么写的,不知道code里有没有更新 QB: 不过 说的case很好,当交易执行时候,发现赞助费不够了,剩下部分由用户支付也挺好的 QB: 至少不会造成交易失败 Spark: code应该和这个说明是一致的 FanLong: 现在刚好最后一点钱不够,是会fail的 QB: 这个确实很影响dapp业务层面的逻辑 Spark: 嗯,但是每一笔的上限被超过了,是用户自己付超出的部分 QB: 这些细节很适合更新到文档里,从用户角度补充各种corner case Spark: 这个还好吧,如果sponsor不再增加,那也就fail最后一笔这样的交易 QB: 比如在dex的场景里,如果交易fail了,异步处理是很麻烦的 刺客: Conflux北斗计划还需要助教[奸笑] FanLong: ,难道大家写都假设交易扔出去一定打包么? FanLong: 这也太粗暴了 QB: 如果赞助费不够了,剩下部分用户自己承担,这样的行为更合理一些吧 QB: 如果高频的发交易,确实更方便些 FanLong: 检查交易status是必须的吧。万一你发的交易就是给了一个傻逼node,这个node就不怎么转发就挂了呢? QB: 比如,我可以接受自己付费,但奈何合约有赞助费,我只希望交易成功,不在乎是否免费 FanLong: at some point总是要check的,要不然这个程序迟早要出事[尴尬] QB: 检查交易status是必须的,但是慢,至少等待秒级的时间 理ྂ想ྂ: 我不行,我得跟同事沟通,近些年管理工作为主,代码碰得少了[奸笑] QB: 还有一点特别重要的是,例如DEX有交易先后顺序的区别,是影响业务逻辑的。如果因为赞助费不够导致交易失败的话,会严重影响交易的执行顺序的 QB: 因为交易执行失败,nonce也会++

该提问来源于开源项目:Conflux-Chain/conflux-rust

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

5条回答

  • weixin_39789101 weixin_39789101 4月前

    We could consider draft a CIP to fix "the last transaction before the sponsor running out" issue.

    点赞 评论 复制链接分享
  • weixin_39692045 WRovo 4月前

    I remembed that the last transaction before the sponsor running out case has been already handled in the current codebase. https://github.com/Conflux-Chain/conflux-rust/blob/master/core/src/executive/executive.rs#L1325

    点赞 评论 复制链接分享
  • weixin_39984442 weixin_39984442 4月前

    There is no "last trasaction issue". In case the sponsor balance is not enough, the sender will pay for the whole transaction.

    
            let gas_free_of_charge =
                gas_sponsored && gas_sponsor_balance >= gas_cost;
    
    点赞 评论 复制链接分享
  • weixin_39789101 weixin_39789101 4月前

    That's wonderful. So we need to update the spec somehow? Is it part of a CIP or it is just the specification needs to be updated?

    点赞 评论 复制链接分享
  • weixin_39984442 weixin_39984442 4月前

    That's wonderful. So we need to update the spec somehow? Is it part of a CIP or it is just the specification needs to be updated?

    It has already been in spec.

    点赞 评论 复制链接分享