前言：

在我们于今年EthDenver期间举办的的Stay SAFU, Security Day活动中，我们邀请了行业的安全专家一起对区块链项目的安全周期（Security Life Cycle）进行圆桌讨论。对比于5年前，当下的智能合约逻辑更加复杂，并且合约之间有了更多的相互调用和可组合性拼接，因此安全问题也变得更棘手。在这个安全相关的圆桌中，Runtime Verification的CTO Everett Hildenbrandt提到了一个很好的概念“Security Shift Left”, 即让安全评估、测试更早的介入到项目中，并且更多运用构建Invariant去评测某个系统的预期行为。

参与讨论的嘉宾包括：

🎙️Everett Hildenbrandi, CTO @Runtime Verification;🎙️Jon Stephens, CTO @Veridise;🎙️Yi Sun, Founder @Axiom;🎙️Michael Lewellen, Head of Solutions Architecture @OpenZeppelin;🎙️Vince Almeida, Director of Engineering @Blockswap

视频链接： https://www.youtube.com/watch?v=f06rbLjHBPw&t=2s 

以下为各位嘉宾分享的insight原文：

🎙️[Everett Hildenbrandi] - host

感谢大家参加这次的专题讨论。让我们从自我介绍开始吧，我是Runtime Verification的CTO Everett Hildenbrandt，非常高兴能参加并主持这次活动，我一直在享受与这里的人们进行交流，这里有非常好的听众，大家真正对这个领域感到兴奋。接下来请大家简单自我介绍一下吧，聊一聊你的项目、角色，以及在ETHDenver让你感到兴奋的事情。

🎙️[Michael Lewellen]

我是Open Zeppelin的 Solutions Architecture负责人Michael Llewellyn。ETH Denver大家对于账户抽象的讨论让我很兴奋。我将和我们的合作伙伴zkSync一起组织一个讨论会。此外，我也非常期待看到人们如何hack和build，我们的安全平台Defender有一个悬赏计划，如果您能够build出一些东西并展示出来，那么就有10,000美元的奖金等待着您。

🎙️[Vince Almeida]

我是Blockswap的工程总监Vince Almeida。我们对很多事情都感到兴奋。刚刚Blocknative的CEO发表了一次演讲，因为我们将要谈论PBS。它并不是三到四年后才会到来，实际上比那要更早。我们将讨论如何连接Restaking和其他许多事情。这个专题讨论非常重要，因为在Blockswap，我们非常关注安全性。这是我们所做的一切工作的核心重点。

🎙️[Jon Stephens]

嗨，我叫Jon，我是Veradise的CTO。我在ETH Denver感到兴奋的是，一方面我们分享正在从事的内容并获取人们的反馈，另一方面是看看其他人在build什么，尤其喜欢人们走到我们面前，告诉我们他们在ZK领域里正在build什么。我听说了一些非常酷的应用，所以这很有趣。

🎙️[Yi Sun]

大家好，我是Yi。我是Axiom的创始人之一。我们正在为以太坊构建一个ZK协处理器，作为其中的一部分，我们将在ETH Denver推出我们的开源计划。如果您想申请与我们一起构建开源的ZK circuit，请访问我们的网站 axiom.xyz/open-source 。

🎙️[Everett Hildenbrandi, host] - Question 1

谢谢大家的介绍。我想让大家知道，我们在这里有一群非常出色的人并且大家有着多元化的背景。我们有几位builder在这里，有基础设施专家，有了解ZK的人，也有了解MEV的人。我认为这将是一个非常有趣的讨论。

本次专题讨论的主题是“安全生命周期（Security Lifecycle）”，这是我们很多人长期从事的领域。我想知道，对于你们来说，“安全生命周期”意味着什么？在2018年，这意味着你给以太坊基金会的朋友打电话询问他们能否为你检查你写好的智能合约。但是现在安全这个概念已经发生了翻天覆地的变化，从你们的角度来看，安全现在意味着什么？

🎙️[Michael Lewellen]

我先来回答一下。现在的Security Lifecycle是一个更长的过程，不仅因为需要花很长时间等待审计的结果，现在需要在早期考虑更多因素，主要是因为我们发现了过去的一些错误。比如：我们需要预先考虑如何设置访问控制，合约是否可以升级，如果可以升级，如何治理升级的权力，是否需要跨链等等。EVM已经不再像以前那样静态了，至少不是我们预期的那样。我们预计大多数应用程序都会转移到Layer 2 并且这些基础设施的架构标准还在不断变化。在这些因素中，我们需要考虑今天要Build什么，同时也需要预见未来协议会出现什么变化。

🎙️[Vince Almeida]

是的，我认为Michael触及了一个很好的点。在一个行业中，有些事情必须要在行业发展途中解决，这些模式在非区块链领域中不会成为问题。例如，函数的Reentrancy。一般情况下，如果你使用Java或Python编程，重新进入函数不会造成什么麻烦。但是，考虑到项目的合约逻辑经常会存在管理向用户分发的代币数量等逻辑，如果以特别的方式重新进入合约，攻击者可能会在合约在下一次正确更新其状态之前把合约内资产抽干(drain the contract）。像这样的模式使得在EVM内，甚至在非EVM平台进行智能合约开发变得非常困难。归根结底，Solidity是一种图灵完备语言。你拥有巨大的权力，关键在于如何管理这种权力。在Blockswap，我们内部遵循的流程随着时间的推移而不断发展，并且我们正在整合越来越多的方法。

我们正在进行协议的形式化一个基于智能合约的机制。这意味着编写正式模型和高层次描述系统的不变量(Invariants)，系统应该如何运作。因为你实现智能合约的方式并不一定是你期望系统运行的方式。智能合约非常复杂，比起2018年，现在有多个智能合约相互调用和写作。因此，重要的是将整套系统简化为核心不变量（译者注：Invariant是人们预期某个系统最终达到的状态，比如在一个区块链网络中不同钱包地址之前的相互转账行为不应该导致钱包total balance发生变化），什么事情应该始终是真实的，以及事情如何会出错。这是将复杂的事物化繁为简的过程，我们发现形式化验证总是带来良好的结果。我们目前正在与 Runtime Verification等合作伙伴合作，他们在帮助我们构建形式化的过程。

🎙️[Jon Stephens]

是的，我喜欢听人们谈论如何构建不同系统的不变量规律，因为很少人做这件事。我认为在理想的安全生命周期和实际上很多项目实现的生命周期之间存在一定的差距。理想情况下，人们会在选择区块链时评估其安全性问题。因为不同的链有不同的权衡，然后在开始构建项目时，他们会开始考虑这些项目中应该保持的不变量，并对它们进行记录，并整合各种工具以进行检查。在Veridise，我们已经看到了一些非常高质量的项目，这些项目使用了这种开发生命周期，从一开始就考虑到安全性，并使用可用的工具检查这些不变量，然后才向我们寻求帮助。

虽然我们在他们的项目中发现了漏洞，但这使得事情变得更容易，并且也消除了一些低风险问题。测试和使用其他工具是发现这些漏洞的重要方法。过去已经证明，这是实现强大项目所必需的，因为审计能做到的是有限的。审计加上测试是确保安全性的一种方式。之后，要么聘请某人进行审计，让另一组眼睛查看代码总是有好处的；要么以某种方式公开发布并提供赏金计划以激励人们查看它。这并没有就此结束，许多人在发布后继续在其协议上build。这是一个连续的过程，人们需要确保在整个过程中遵循适当的安全协议。

这是理想情况。然而，在实践中，基本上是，某人有一个很酷的想法，其他人也在实现相同的东西，所以他们赶着上市，面临着来自投资者的压力等等。因此，他们会很快地实现某些东西。他们没有时间做所有的测试。他们只有50%的覆盖率。这足够了，对吧？我会把它发送给我的审计员。审计员会发现其余的漏洞，然后再把它放到区块链上，一切都可能很好。这就是我们希望摆脱并朝着理想情况更接近的方向发展。

🎙️[Yi Sun]

我认为其他三位发言人提出了一些非常好的观点，主要涉及智能合约系统。我想Axiom 考虑到的一些问题中更关注有关 ZK 的内容。我认为当你将 ZK安全性与智能合约安全性进行对比时，一个重要的区别在于 ZK 的工具和框架不那么成熟，因此会有更多的方式让我们遭受攻击。说实话，我们认为防范这种情况的最好方法是写更少的代码，可以是功能更少，也可以是编写更具表现力的代码。我们花了很多时间编写 Halo Two 的新框架，它使我们能够用更少的代码编写相同的功能。我们认为这既有益于提升开发人员的工作效率，也能提升安全性。

另一个方面，我认为在ZK上比较独特的一个方面是你经常会使用更新颖的加密协议。我们认为重要的是要检查这些协议所需的所有假设，并确保你的智能合约与其整合的一切匹配。与编写完整的ZK circuit相比，这是一种相对琐碎的检查，但我们发现这些地方实际上是我们内部发现最多漏洞的地方。

🎙️[Everett Hildenbrandi, host] - Question 2

谢谢各位详细的回答。我想和Vince以及Yi谈谈，因为你们两位builders都已经部署了链上代码。Vince负责整个Blockswap系统。Yi负责链上系统用于验证在链下完成的零知识证明。在过去的一年中，我们看到了很多这样的情况，我们在Runtime Verification 中也在积极推广，我知道其他几家公司也在这样做，这就是Security Shift Left（译者注：安全评估发生在项目周期更早的时间）的思维方式，也就是更多的安全措施在公司内部实施，向客户提供更多工具。Jon刚刚也提到了这一点，客户在进行审核之前应该已经完成了尽可能多的尽职调查。

审计团队不是一个能确保找到所有漏洞的魔法盒子，项目方需要提前自行进行尽职调查。我想问问Vince和Yi，这种的Security Shift Left理念对你们来说意味着什么？这如何转化为你们公司的实践呢？

🎙️[Vince Almeida]

是的，我们尽可能地在内部完成尽可能多的工作，以便我们有能力进行迭代。我喜欢Yi提到的写更少的代码的想法。如果有正确的工具，如果有形式化建模（formal modeling），那么让大量的测试工具接入就显得并不是那么必要。你可以从一个可能比实际更大的东西开始，如果有正确的工具，你可以迭代并检查系统是否仍然按你的期望运行。另一个问题是，有各种事情需要注意，包括你的盲点。一个不太被人们谈论的盲点是Solidity编译器中的编译器漏洞。Solidity编译器的漏洞比你想象的要常见得多。有各种公司和工具，例如数据，它们拥有漏洞库和教程指南，也有许多人发现了Solidity编译器中的错误。

显然，Solidity 作为一种语言和生态系统来说，我们仍处于早期阶段，因此出现这种情况是可以预料的。无论你的代码有多好，编译器都可能将其转换为表现不好的代码。我们尝试使用字节码工具。我们正在使用Certora的工具，并与 Runtime Verification 合作在 Foundry 中编写属性测试和所有这些测试，以便我们可以将 Foundry 插入Foudry Decay。随着工具变得越来越容易，我们对系统的信心也越来越高。我们把那些容易被发现的漏洞Low Hanging Fruit自己找出来，以便于外部审计员进行下一步的更高阶的安全审计工作，因为我们总是需要对代码和发生的情况进行外部的客观查看，并检查我们忽略了什么。现在，我们来谈谈你所提及的在链上部署代码以及部署后会发生什么？

安全性是一个持续的进程。你不能只是把合约部署到链上然后希望一切顺利。Blockswap在以太坊执行层和共识层都有监控和可观测性的解决方案，这是很多人没有考虑的共识层。我们有这些核心的协议不变量，Stakehouse协议是基础层协议，我们有最高的安全性和最高的形式化验证，我们知道这些属性存在，所以我们会在内部监控它们，并在出现问题时获得警报。你不希望出现Axie infinity那样的情况，七天后才发现运行和桥梁被黑客攻击了对吧？你需要尽早知道什么时候出了问题，但你也需要赋予社区能力，让社区找出什么时候出了问题。

我们有一个监控仪表板，任何人都可以看到系统红色、黄色、绿色和其他属性。你要与社区合作，让安全性成为不只是内部的事，作为一个公司，你只能做到那么多。你要向社区寻求帮助，向社区寻求形式化验证的帮助。我们在这方面与多个团队合作，这是一个不断发展的过程，非常有趣。希望工具会越来越好，帮助团队做到这一点，因为单个测试是不够的。你需要结合几种方法。

🎙️[Yi Sun]

我回应一下Vince的观点，关于社区驱动，我们发现使用在不同项目之间共享的共同primitives对我们的框架开源是非常有帮助的，这鼓励了其他人使用相同的代码。我们发现这样可以让代码得到不同的检验，当有人将你的zk circuits用于不同的目的时，会从你看不到的视角对其进行压力测试。除了标准的智能合约部署之外，我们还在思考如何利用开源来创建我们认为的最高安全标准。

🎙️[Everett Hildenbrandi, host]

我喜欢开源这个话题。我觉得你们也会喜欢的。在开放的智能合约库方面，我认为你们也会喜欢的。我想听听你们对这个Security Shift Left有什么看法。对我来说，这意味着审计公司现在可以关注其他方面的安全生命周期。我也想听听来自Open Zeppelin和Veridise的朋友们的看法。

🎙️[Michael Lewellen]

简而言之，任何一个注重Security Shift Left的人，在审计之前就十分考虑安全性，审计过程本身会更加顺利。报告会更加整洁、更加优美。严重问题会更少，发布前修复的时间也会更短。我们偶尔会遇到一些客户，他们对审计或者他们的代码有一些不切实际的期望。通常最好的回应是：“下次你来找我们审计时，让我们先进行一些初步的代码审查。”事实上，有时候有人来找我们审计，我们会说你还没有准备好审计，我们会给你进行代码审查，但这不会是你想公布的审计结果。虽然我们不太专注于测试框架，我们也开展工作坊和做其他的事情，我们肯定会鼓励它。

形式化验证肯定是最成熟的项目之一，而且它已经准备就绪。越早有人认真对待它，并记录下来，几乎可以将威胁和需要关注的事项编码化，这会让我们的工作越轻松。我们可以发现更微妙、更可怕的安全漏洞，这是安全扫描器或他们自己的安全团队找不到的。我们和其他审计师擅长发现真正的深层次、有趣但潜在可怕的漏洞。然后，你所说的关于监控的事情是正确的，因为一旦你确定了不想发生的威胁，你也需要监控并密切关注它们。

我们正在尝试与客户做的不仅仅是测试他们的智能合约以及测试他们的部署，而是测试他们的监控。比如，在测试网或硬分叉环境中运行整个系统，然后尝试破坏某些东西，看看你的监控是否真的捕捉到了它，并且你能否做出响应并采取行动。在你把噩梦变成现实之前，先尝试体验一下。

🎙️[Jon Stephens]

是的，我认为这些是很好的观点，我完全同意。我们也曾经审核过一些过早来找我们的项目，我们花了几周时间后，告诉他们基本上一切需要推倒重来，因为有一些问题应该在来找我们之前就解决了，这对双方都有些令人失望。开发人员使用工具甚至有时开发自己的工具，这是我认为非常棒的事情，应该更常见。我之前提到过我们做过的另一个审核，他们实际上创建了自己的模糊测试工具。这非常有趣。他们基于 Truffle 测试框架构建了一个特定于他们协议的模糊测试工具，这非常有用，因为它帮助他们发现了很多漏洞。

开发者或者说是较大公司的安全部门开发出针对其协议的特定工具，可以识别出它们的API应该在哪些情况下被调用，因为这是与其协议相关的不变量，对于所有相关方都非常有用。最终，他们可以来找我们，我们可以发现更为隐蔽的漏洞。我认为这是Veridise 正在努力实现的一部分，也可能是其他人正在做的事情，就是为这些公司提供框架，让他们在其上进行开发，开发出可能是针对其协议的、不一定适用于其他用户的东西，以便能够早期发现其漏洞。至少在Veridise，我们非常有兴趣构建这些框架并尽可能开源，以便让人们也可以在我们的工具上build。

🎙️[Everett Hildenbrandi, host] - Question 3

没错，你之前做了一个很好的演讲，介绍了你们正在发布的一些开源 ZK 工具。我认为在智能合约开发的世界中，大多数人都了解这里所涉及的信任基础，对吧？比如说，如果你正在开发 Solidity 代码并使用 Truffle tester，你的信任基础包括 Solidity 编译器，包括测试框架。我认为在 ZK 的世界中，正如你所说，工具的发展远远不够。从你们的角度来看，这里的信任基础是什么样子的呢？

🎙️[Yi Sun]

是的，我认为在ZK的所有正常智能合约工作之上，你正在证明某些函数的有效执行，通常通过一个证明框架实现，可能是用Rust实现的库。在Axiom，我们使用Halo Two，这是一个加密证明系统的实现。有三个新的事情你必须信任。第一，这些新的ZK协议背后的密码学数学确实是可靠的，这是基于某些学术论文。第二，你必须相信实现这个协议的证明系统在Rust中实际上正确地实现了这个协议。最后，许多这些协议涉及某些称为可信设置的东西。这是一种多方计算，你必须有一个1到N的信任假设。如果N个参与方中有一个是诚实的，那么你可以信任整个系统。如果所有的N个参与方勾结起来，那么可能会破坏很多担保方。

我们认为记录下正在发生的事情非常重要。对于大多数用户来说，这些东西相当晦涩，我认为整个ZK行业必须非常透明地说明什么被保证，什么没有被保证，并且至关重要的是，用户如何自行检查这些内容？在普通的智能合约中，在 etherscan的合约验证就是一个很好的例子。这是一种非常经济和简单的方式来确定在链上运行的是代码。你会发现，在Zak中并没有这样的标准，但我认为我们正在朝着这个方向努力。

🎙️[Jon Stephens]

Yi的回答很全面我没有太多要补充的。我认为在这里有一个更大的信任空间，因为显然你必须信任这些额外的参与方。安全社区，或者至少是安全研究社区，肯定正在努力消除这种情况。我们已经通过可信设置进行了验证，每次有人想要启动他们的协议时，他们都必须经过这个可信设置过程。现在有一些其他的证明系统，你只需要一个可信设置，然后可以被多个协议重复使用。研究社区现在正在研究无信任设置的情况。这肯定正在改进，这是我想要补充的唯一一件事。

🎙️[Everett Hildenbrandi, host] - Question 4

好的，谢谢。我想回到部署后的安全性这个话题。Vince，你在Blockswap工作，你们对自己的工具进行了很多内部监控。这显然是一个非常具体的需求，非常具体的用例。OpenZeppelin与Forfa密切相关，它更具有通用性监控，更面向消费者。我们谈谈它们如何适应人们的安全生命周期。看看我们能想出什么？

🎙️[Michael Lewellen]

是的，我想先介绍一下Forta，因为对于一些新人来说可能有些陌生。实际上它是一个分布式协议，用于运行安全机器人。基本上，你可以在JavaScript中配置整个机器人，将其放入docker文件中。我认为现在也可以用其他语言编写它，它将在一个由五个不同实例组成的分布式网络上运行。我们有冗余，这个想法是真正面向社区的监控。现在有些情况下，人们可能会说，我不想让我的安全监控完全公开，我希望第一个知道发生了什么，不是每个人都知道。其实有办法让Forta变得私有，或者只是使用传统的安全监控基础设施。我认为有用的是不仅能在发生重大严重漏洞时向整个社区发出警报，还可以像通知可疑的事情一样，让整个社区强烈意识到发生了什么。

有时候你会发现一些本来不会被你团队发现的问题，因为不仅仅是你的团队在监控，你的整个社区也在监控。这通常是你必须处理的方式。这也像是监控访问控制。谁是多重签名？哪些 DAO 决策即将出炉？要多留意。我最喜欢但也最悲惨的 DAO 治理失败的例子之一是去年的 Beanstalk。那是一个周末提出的提案。我想它只有一个审查期，如果你获得了三分之二的多数票，就可以通过 Quorum 立即执行，没有时间锁。基本上，有人提出了一个建议，让他们拿走了整个财政部，并且他们能够做一次闪电贷，并借走所有资金，然后立即通过了提案。他们本来可以看到很多迹象。

你可以发现一个提案，可以有一些检测来指出：嘿，这个提案包含了大量的国库资金转移，你也可以看到大量的资金借贷来表示出有什么问题。除此之外，还有几个方面他们可以关注，还有就是建立更好的治理体系。但那只是一个例子。对于协议团队来说，尽可能多地获取信息并尽早获得警报，对于防止问题失控至关重要。

🎙️[Vince Almeida]

“文件夹”这个例子非常有趣，因为在 Stakehouse 协议中，我们基本上处理的是以太坊所称的两层，但在某个时候它是两条链，以太坊的执行层和共识层。在 Stakehouse 协议中，没有更新用户拥有的资产余额的预言机。在执行层中，用户做自我报告。这个机制在运行验证的审计报告中有所体现。现在的挑战是得知道什么时候出现问题。用户将他们在共识层的余额报告到执行层，我们必须同时检查单个合约的两个状态。文件夹方面通常关注执行层，但我们面临的挑战是在两个状态之间具有可观测性和共识层节点基础设施的可用性。与执行层相比，公共节点的选择非常有限。

你可以从许多来源获取节点信息，但共识层不是这种情况。希望随着时间的推移，共识层监测的工具将得到发展，但我们必须在这方面推动界限并给用户解释。当您构建像这样对行业来说是新的东西时，需要这样做。我们有深入的注释、清晰的文档和技术文档，这样人们就可以重新计算相同的东西，以便更多的人可以关注问题。这是我们正在做的。

🎙️[Everett Hildenbrandi, host] - Question 5

谢谢，各位。当我想到高功率的Web3技术时，我想到的是监控、形式验证、属性测试、零知识证明，还有MEV，对吧？我想知道，你们是否担心MEV？你们是否考虑过它？它处于ZK和监控的交叉点。许多零知识应用程序试图用不同程度的成功来打击MEV。监控对于试图参与MEV的人显然非常重要。他们想要观察潜在的机会来提取价值。我知道这有点出乎意料，如果你们没有任何评论，那没关系。我要一个接一个地问你们，你们对MEV有什么看法？

🎙️[Michael Lewellen]

这既是迷人的又是可怕的。我记得我曾经是我们审计团队唯一的项目经理，所以我能看到所有的事情，包括最可怕的部分。我记得当MEV和闪电贷款等其他事情变得更加普遍时，我们的审计工作从传统的安全研究人员和黑客思维转变为像华尔街恶意交易者的思维。这是一种非常不同的心态。我认为从长远来看，找到解决方案是好的。但是，我认为要想找到永久的安全解决方案是很棘手的，因为MEV的整个目的就是不断变得更加高效，找到更好的隐藏你试图推动的捆绑交易的方法。我听说过有趣的安全想法，比如监视攻击事务，然后能够提前运行它自己，我认为这很酷，希望人们继续在这方面工作。但是我认为长期来看，最好的防范 MEV 的方法就是始终假设它会发生在你的协议上，并针对它进行设计。

🎙️[Vince Almeida]

Flash loan发生时真的在整个行业引起了巨大的震荡，因为它是一个全新的范例，没有人预料到。它能够在一个区块中借入任何金额的资金，并在同一个区块中偿还，这完全打破了一些协议，导致了可怕的黑客攻击。但它是可组合性的一个结果。在Blockswap，我们真正需要考虑的是协议的可组合性。如果某人要在一个区块中使用多个交易来组合你的协议，这会带来什么样的副作用？现在并不是说它是不好的，事实上，如果没有套利交易，Uniswap将无法正常运作。Uniswap的机制是基于协调的机制，用于管理Uniswap的库存。因此，Uniswap没有Oracle，也没有任何依赖。

这些也是我们在Blockswap内部做的事情。我们有无Oracle依赖，并使用智能合约机制设计。这意味着为了管理您的库存，您需要支付某些外部参与者来进行管理。这些仲裁者会检查虚拟价格与库存之间的差异并将其保持更新，他们会通过协议为执行该操作而获得报酬。实际上，在Uniswap的情况下，这是一项被期待的操作。你确实需要了解什么是期待的和不期待的，并从那里开始考虑，同时也要尝试看看组合性如何影响你的协议。是的，MEV肯定会留下。从我们的角度来看，我们正在构建一个名为“中立性证明”的单独协议，旨在更民主化。这确实使更多人能够访问所提出的区块构建空间。

🎙️[Jon Stephens]

是的，我们已经探讨了 Mev 对审计或安全方面的影响。我认为，从工具的角度来看，我们现在确实没有很多能够以非常准确的方式推理这个问题的工具。我的意思是，如果考虑像查找前置攻击这样的问题，现在就需要考虑某人何时提交交易以及何时被挖掘出来。现在你必须考虑到这种乱序执行。如果工具试图产生实际漏洞的具体证据，那么这就是工具必须能够重现的东西。这变成了一个更加困难的问题，因为这基本上意味着他们必须进行大量的推理。

你也会遇到相同的问题，因为很多时候你的工具只会在隔离状态下推理你的协议。因此，我们需要更多的工具。这是我们在Veridise一直在研究的问题，我们正在以更广泛和大的视角理解区块链，以便定义攻击你的工具。这要求要么拥有一些关于区块链状态的知识，要么模拟这些类型的攻击，这是我们正在研究的解决方案，以便向使用这些工具的审计师和开发人员提供有趣的反馈，使他们能够轻松使用和理解实际发生的情况。

🎙️[Yi Sun]

我认为 Mev 对 Axiom 有两种影响。首先，我们以类似预言机的方式将数字引入链上来满足 Axiom 中的查询。当我们与项目合作时，我们意识到查询满足可能会产生相当多的 Mev。也许协议可以设计自己以将其最小化。其次，更有趣的是，我们对如何利用 Axiom 改变建立、提出或甚至提取 Mev 的系统感兴趣。实际上，我们能够深入研究链上的历史交易数据，并事后评估人们建立的区块质量、区块中的 Mev 量、区块中是否存在夹击攻击等。我们有兴趣探索这些方向，以尝试在某种程度上缓解 Mev。

🎙️[Everett Hildenbrandi, host] - Question 6

我觉得这种数据驱动的方法非常好。看看历史数据，说实话，对于 Mev，甚至没有很好的监控解决方案。我觉得如果你问某个人他们的用户交易有多少是 Mev，可能他们甚至都无法回答自己的 DAP，但谁知道呢？我们涉及了很多主题，我想我们还剩下两三分钟。这个panel讨论的主题是安全生命周期。安全涉及到一切，它涉及到部署前、部署时、部署后的各个方面，我们讨论了很多不同的事情。有什么结论或者你想要告诉大家的事情吗？再一次强调，在讨论结束后，你们可以问任何这些人任何问题。

🎙️[Michael Lewellen]

我对账户抽象感到兴奋，今天以太坊基金会将发布一些有关它的公告，这可能会对安全生命周期产生一些影响，可能是很大的影响，但很难区分。账户抽象会改变很多方面，尤其是交易被支付主机路由的方式以及智能钱包的本地操作。它提供更好的钱包恢复机制，可以创建更多本地多重签名，也可以为用户提供更多保护，同时还可以为他们与协议互动的方式提供保护。我们最近为以太坊基金会进行了账户抽象的审计，因此我们得以看到它改变的许多不同方式。

我非常期待的是，当人们知道账户抽象的存在，或者当它真正得到推广时，人们设计协议的方式将会发生怎样的变化、如何应对事故以及保护用户的可能性。我最喜欢的加密货币标准是，当我的爷爷能够使用它，并且我们可以给我父亲掌管他的账户，这样每当他被骗子联系并试图将资金转移出去时，我父亲都可以在实际转移之前关闭它。他有一些基本能力，可以让普通人使用加密货币，并拥有加密货币的监管权，但在此基础上还具有一些保护措施，这意味着他们不会轻易地把自己的资金交给某个黑客。我认为，这就是大规模采用加密货币的真正期望所在。

🎙️[Vince Almeida]

Boxops在安全方面是一个不断发展的情况。今天我们使用的工具不一定是明天我们使用的工具，但我们只是试图跟上形势的变化，不依赖于项目，而是依赖于正在发布的协议。当涉及到智能合约安全时，了解EVM的工作原理，基本上了解执行流程是非常有优势的。要注意编译器错误，并努力获得更好的正式工具，以更快地发现漏洞。是一个不断发展的情况，我们期待看到它如何发展。

🎙️[Jon Stephens]

是的。就我们这边而言，我已经提到了正在开发的一些工具。我们正在为 Defi 和 ZK 开发工具。显然，我之前谈到了 ZK 工具，我们将在稍后的另一次活动中谈论我们即将推出的 Defi 工具。实际上，我们目前正在努力找出发布这些工具的最佳方式，因为其中一些将是开源的，而另一些则将集成到 SaaS 服务中。如果您对我们正在开发的一些东西感兴趣，请跟随我们，因为我们将很快发布关于正在开发的工具的公告。

🎙️[Yi Sun]

在我们这边，我们最为关注的ZK安全趋势与Jon提到的相关，即Shift Left和形式验证。我们的梦想是能够正式验证我们自己的合约，从而大大加快我们的发布周期并提高安全性。我认为我们还有很长的路要走，但像Veridise正在开发的这些工具应该是这一进程中的一大步。最后，我建议你申请Axiom开源项目。

🎙️[Everett Hildenbrandi, host]

好的，让我们感谢我们的演讲嘉宾们，感谢大家的关注。

🎙️[Attendee] - Question 7

非常棒的座谈会，感谢各位嘉宾。你们谈到了许多项目需要注意的问题，比如形式验证、单元测试等等。对于刚刚开始的新项目，如何学习这些技术呢？我们需要做什么？

🎙️[Jon Stephens]

这是一个非常好的问题。很难知道该怎么做，这需要一定的个人探索。从我们的角度来看，你需要做的是，当你决定要参与某个生态系统时，必须去寻找它们。调查一下可用的安全工具，大多数生态系统的工具数量相对较少，但尽可能利用多的工具总是一个很好的选择。显然，你的时间是有限的。重要的是要了解: 1. 可用的工具；2. 对你的协议影响最大的工具。例如，很多人发现静态分析器非常有用，因为它非常快速，不需要太多的配置。

静态分析器是一种可以快速反馈并具备可操作性的工具。唯一的问题是它可能会占用开发人员的时间，他们现在必须评估静态分析器报告的所有内容，因为它可能产生误报。这就是你可能需要研究其他工具并找到不同权衡方案的地方，这些方案可能是协同的。例如，你可以使用模糊测试工具来尝试找到静态分析器报告的一些漏洞。或者如果你在使用开源自动验证器的情况下，可能会更难一些，因为验证通常需要更多的努力，包括开发不变量和理解可能阻止验证通过的内容。

有些情况下，如果验证你的协议的关键部分过于艰巨，可能需要寻找开发人员或至少寻找审计员。我认为这是探索和尝试理解工具的功能以及你的问题的答案。

🎙️[Vince Almeida]

我想对此补充一点，学习成为一个智能合约开发者需要面对巨大的学习曲线。从我2017年开始接触到现在，已经有了一些被提到的工具，如Truffle、Hard Hat框架。现在，最热门的是Foundry测试框架，因为它既具有速度，又将许多工具打包成了一站式服务。你可能不知道模糊测试，但是使用Foundry，你可能会发现它有这个功能，从而找到了需要在你的合约上采用不同测试方法的方法。另外一个非常成功的方法是与社区合作进行教育。我们举办了一个形式化验证竞赛，并鼓励学习。

我认为区块链安全领导们应该与社区互动，真正阐明应该做什么。我认为工具应该成熟到一个程度，使得所有的工具都在一个平台下，这样你就可以在开发智能合约时节省时间。像 Foundry 这样的工具非常方便，你可以编写单元测试、属性测试，还可以进行 Fuzz 测试。希望使用 Foundry Decay，你也可以正式验证你的合约。

🎙️[Michael Lewellen]

好的，简单来说，有一个很好的资源可以作为入门，那就是EEA ETH Trust。这是一个以太坊企业联盟组织，他们提供了一个基本的漏洞列表，按照栈分析工具能检测到的、手动代码审查能检测到的，以及需要进行真正审计的漏洞分类。这个列表可以为您提供良好的生命周期指导。然后，选择Truffle、Hardhat或Foundry中的一个（当然，本次讨论中Foundry比较受欢迎），选择你的团队最熟悉的工具，并开始构建测试。随着时间的推移，你们希望能够逐渐发展成更成熟的测试方法。但我见过一些团队犹豫不决，不确定要选择哪种工具，最终却没有花时间去至少尝试一下。

🎙️[Everett Hildenbrandi, host]

我想那是EEA ETH Trust，对吧？以太坊企业联盟。是的，他们有一些很好的指南。我认为包括Open Zeppelin在内的许多审计公司，也可能最近查看了您的网站，我知道我们会这样做，Trail of Bits也会做。他们有博客文章，介绍如何准备安全审计，如何测试您的合约，如何编写属性测试，如何考虑不变量。这也是一个很好的资源。好了，我们时间到了。让我们再次为嘉宾们鼓掌，再次谢谢大家参与！