面对网络拥堵与黑客攻击，BSC 将如何规避和优化？

　　HashQuark 、DODO、Mask Network、EigenPhi 以及安比实验室就「如何规避和优化 BSC 网络宕机、节点服务缓慢、黑客攻击频繁等问题」话题展开了深度讨论。

　　撰文：Zoe Zhang

　　对于任何公链来说，安全都是重中之重的问题。新兴公链中虽不乏佼佼者，但网络性能及安全方面仍有优化空间，即使是自去年 9 月上线以来就表现亮眼的 BSC 也无法避免。过去几个月里，BSC 出现了多次网络停止和黑客攻击的事件，给 BSC 带来不少的负面影响。有人说 DeFi 协议本身有问题，也有人说项目代码重合度高，社区的热烈讨论进一步推动了我们的思考。

　　2021 年 6 月 8 日，在由 Hash Global、Mask Network 主办，链闻、Winkrypto 联合主办了一场主题为「BSC 迭代演进之路」的 Meetup 闭门会活动圆桌对话环节中，链闻研究总监潘致雄、HashQuark CMO Dora、DODO 联合创始人兼 CEO 雷达熊、Mask Network 创始人兼 CEO Suji Yan、EigenPhi 联合创始人程显峰以及安比实验室合约安全总监孙志鹏六位嘉宾围绕「如何规避和优化 BSC 网络宕机、节点服务缓慢、黑客攻击频繁等问题」话题展开深度讨论。

　　本文为该场圆桌讨论的精彩内容集锦，内容有所编辑。

　　潘致雄：更早之前 BSC 网络还出现了网络停机问题，这些问题的根本原因是什么？当时给各个协议带来的影响有多大？

　　Dora：Hash Quark 作为身处战斗一线的节点，发现虽然在 BSC 大面积拥堵期间面临较大压力，但我们的服务器没停过，所以 BSC 网络宕机、停机的说法其实并不存在。究其原因，我们可以从 BSC 发展路径以及它的机制设计上来看这个问题。

　　第一，相对以太坊来说，BSC 设置了更大的区块，出块速度更快，性能更优越。我认为正是因为 BSC 好用又便宜，用的人多，才导致了堵。

　　第二，很多人会觉得 BSC 21 个节点机制会有中心化问题，但 BSC 服务器的要求和成本非常高，Hash Quark 运营了大概 40 条公链的节点，BSC 服务器硬件要求以及投入成本可以排进前五，高门槛保障了节点平稳运行。另外一方面，随着硬件不断的升级，BSC 的性能也有提升的空间。

　　潘致雄：大家的项目都部署在 BSC 上了吗？

　　雷达熊：DODO 在 BSC 上的业务此前也受到比较大的影响，广播节点和验证节点不同步导致区块延迟，网络节点受到比较大的冲击，直到 BSC 更新节点服务器后问题才解决。

　　经历过这件事情之后，我认为物理世界是有限制的，不要以对任何链产生过高的期待。随着 BSC 发展规模的扩大，谁也无法保证可用性。现在我们在接每一条新链时都会做很多准备，这是从 BSC 身上吸取的经验。我们相信 BSC 未来能够很好的解决这类问题，发展的越来越稳。

　　Suji Yan：BSC 的问题谁都可以在上面写代码，谁都敢在上面写代码，就可能会导致节点资源浪费在没有意义的地方，所以从另一个角度来说，Gas 费贵一点也不是没有好处。现在每次看到很多大项目即将上线我们就很紧张，担忧他们大概要在主网上做什么测试以及将会出现什么状况，这是我们的一些经验，其实还是很脆弱的。

　　大家觉得 BSC 比较中心化，但在我眼中，BSC 和以太坊都有中心化的弊端。

　　90 年代的时候大家都在做网页，没有人做服务器，后来导致大面积网页陷入瘫痪等问题，后来才发展成为一个服务器链条产业的。我认为随着公链的深化发展，不管是多节点公链还是少节点公链，像 PoS 或者 BSC 这样的公链很有可能会进入到大型提供商自建机房的阶段，自己把客户端代码重新全部读一遍，或者像安比实验室这样查验一遍。

　　潘致雄：补充问一下 Dora，BSC 遇到这些问题之后，具体采取哪些措施？

　　Dora：其实 BSC 本身并没有被 DDOS 攻击，所以我们也没有特别紧急的。但是有一个数据可以分享一下：

　　作为最早一批 BSC 做节点的团队，目前我们的 BSC 节点一共做了 18 次客户端升级，其中有 16 次都是发生在 4 月和 5 月上旬，也就是 BSC 最拥堵的这一段时间。这一段时间技术同事们压力很大，经常半夜收到短信，就要爬起来升级客户端，非常感谢所有同事的团结努力帮助我们一起让度过难关。

　　潘致雄：5 月份 BSC 网络超过 10 个项目遭遇黑客攻击产生连锁效应，涉及闪电贷等问题，导致这一问题的本质原因是什么？

　　孙志鹏：我认为可能是因为各个项目之间代码互相 Copy，导致漏洞也在这些项目之间传播，造成一个项目被攻击、多个项目接连被攻击的现象。

　　除此以外，造成 BSC 在 5 月接连爆出黑客攻击的原因，和很多开发者对于无论是闪电贷还是对于 DeFi 协议间相互组合的风险意识较为薄弱有重要关系。另外，目前可能有些工具可以辅助帮助快速发现类似的漏洞，这加快了这些漏洞被利用的速度，但是闪电贷在这里只是降低了攻击门槛，提高了攻击收益。

　　程显峰：我一直对智能合约上的攻击持悲观态度，例如现在 2021 年，windows 平台依旧有病毒。面对无穷无尽的组合去防范风险非常难，从另一个角度来说，大家觉得攻击是不好的东西，但攻击反向推动了智能合约的进步。

　　闪电贷既是核武器也是核能，它虽然展现了更高的效率、更好的资金杠杆以及更有效率的资金使用率，但同时它也有很大的破坏力。

　　Suji Yan：攻击还包括与人相关的问题，即用 DAO 攻击别人。在 DAO 治理模型中，虽然链上是透明的，但是 DAO 的治理投票机制也存在风险，例如，Gitcoin 社区通过提案投票将 Vitalik Buterin 捐赠的 49 万亿枚 AKITA 兑换为 ETH，对于 AKITA 来说造成了影响。这是新的风险，DAO 的风险，有控票现象而且不讲道理。经济体系很大的时候不要太相信自治投票。

　　潘致雄：Suji Yan 聊到了一个关于攻击的新思路。

　　雷达熊：我认为在构建 DeFi 项目的代码时开发者应该思考经济学相关的问题，开发者除了技术知识还需要掌握相关的经济学知识。

　　潘致雄：接下来聊一下，既然存在这么多问题，对我们未来的开发有什么建议？无论从安全审计上还是经济学，如何尽可能地避免？有没有缓解的方案？

　　雷达熊：很多项目因为寻求创新而开发复杂的系统，但这种创新会带来整体风险的增加，建议开发者用简单的代码让系统变得简单。能用简短代码写完，不要多加很多东西，这是我对开发者的一些建议。

　　Suji Yan：我建议不要太相信自己投票机制，现在大部分的自己投票的体系都很脆弱，经济体系很大的时候，容易出现很多问题。

　　原来我非常反对留后门这种行为，我认为不应该有这种东西。但我现在觉得应该留一个后门，然后设计某个机制让这个后门不要被滥用，这对于项目后期的优化发展比较重要。

　　程显峰：我很同意这个观点。很多开发者觉得代码即法律，但经验不可能覆盖到未来的所有情形，法律本身是不可能做到尽善尽美的，一般的合同都有一个未尽适宜等等，换句话说法律都有后门，经济模型的设计更是如此。我们不要写死，留一点改变空间。因为很多时候，开发者认为自己已经设计的很完备了，但总有人能找到漏洞。

　　孙志鹏：对开发者的建议有两方面：一是开发者真正去了解一下漏洞深入原理，提高后续的代码安全性；二是借助专家的力量。另外，建议开发者适当放慢节奏，很多项目从开发到上线，时间太短了。相反，我个人最喜欢的 Uniswap 核心代码，不仅代码极简，而且有非常详细的测试用例，甚至还带有形式化验证，非常值得学习。

　　Dora：我对用户的建议就是永远不要考验人性，大家对于参与的项目应该做一个基本的尽调，当你发现这个项目里面有不合理设计的时候，应该保持怀疑和警觉的态度。