作者： Snownad & Danny

编译：深潮 TechFlow

Monad Labs 首席执行官兼联合创始人 Keone Hon 和开发者关系工程师 Kevin G 参加了 The Pipeline 播客的第三期节目，讨论 Monad Labs 团队过去两年的工作内容。

嘉宾介绍

Keone 是 Monad Labs 首席执行官兼联合创始人，此前在 Jump Trading 担任量化分析师，专注于高频交易（HFT）领域；

James Hunsaker 是 Monad 联合创始人兼首席技术官；

Kevin G 是 Solana Labs 核心开发人员，此前在苹果公司工作，专注于 Airpods 的本地系统工程设计。

为什么选择 Monad？在 L2 和其他扩展解决方案如此流行的环境下，您为什么要改造 EVM？

Keone：几年前我们刚开始时，很多人问我们：「为什么不建立一个 L2？」我们当时的答案和现在是一样的：我们认为有人需要专注于提高 EVM 执行堆栈的性能。通过引入优化，如并行执行、自定义状态数据库、流水线执行和对异步 IO 的支持，Monad 能够更好地利用硬件，实现更高效、更去中心化的系统。

随着时间的推移，越来越明显的是，以太坊虚拟机中的许多瓶颈可以通过合适的工程师团队来解决和优化。回到 2020 年，当 Monad 首次概念化时，并没有太多团队专注于这些优化，尤其是与投入到其他基础设施（如 rollup、零知识证明或数据可用性）的努力相比。

作为智能合约的主导标准，EVM 链拥有最多的 TVL、最大的开发者和研究网络，以及一个经受住时间考验（和多个熊市）的令人难以置信的社区。当我们希望扩大采用并支持更复杂的应用程序时，这使得优化变得更加重要。

「使 EVM 性能大幅提升确实是一个有趣且具有挑战性的问题。我很高兴我们的团队在当时就开始着手这个项目。这让我非常兴奋，期待在未来几个月向全世界展示。」

EVM 性能满足 Monad 上的可扩展性

Kevin G：Monad 正在做的很多事情都是将计算机科学的最佳实践应用于区块链网络。这是可能实现的，因为团队在这个领域拥有如此深厚的背景。

并非每个开发团队都能够解决协议的根本问题并提出高性能的解决方案。这些优化不仅令人兴奋，它们在也充满雄心。

你是如何挑选出能够应对这一挑战的团队的？

Keone：我只是觉得非常幸运，能够在 Monad Labs 这里拥有一群了不起的工程、增长、市场、社区建设和商业开发方面的人才。我们大约有 25 人，试图保持超级精简的团队，以便能够专注于需要解决的问题。

随着时间的推移，我们的团队将会不断壮大，以支持我们试图达到的规模和采用率。这肯定需要更广泛的技能和额外的人力。

大多数工程团队在构建高性能、低延迟系统方面拥有丰富的经验。开发真正高性能的基础层系统的一个常见模式是，你需要对整个系统的性能有所了解。有时候你需要深入到内核级别，以获得你需要的优化。最终，区块链实际上本身就是一个数据库。

一些深受喜爱的 Monad 角色在社区传说中巩固了自己的地位

为什么建设者要来看看 Monad？

Keone：一个关键优势在于 Monad 的潜力，它可能能够促进广泛的可组合性，超越以太坊现有的限制，甚至比 Solana 等更高性能的系统还要好。

因为 Monad 与 EVM 字节码和 RPC 兼容，工程师的学习曲线比在许多其他环境中要低得多。我们很高兴能够利用大量的研究和工具，这些研究和工具为 EVM 的蓬勃发展铺平了道路，并让开发人员能够在他们已经了解和信任的环境中构建性能更高、可扩展的应用程序。

Monad 在更广泛的 Layer 1 解决方案领域的战略定位是什么？

Keone：最终目标是创建一个更可扩展、成本更有效的平台，用于构建多样化的应用程序，消除现有区块链生态系统中阻碍可组合性的限制。

在以太坊最初设计的背景下：目的是使构建者能够在其生态系统内创建任何东西。Monad 是这一概念的加速发展，摆脱了十多年来一直存在的限制。我们可以用燃油汽车过渡到电动汽车的转变作为类比，标志着当引入新技术时所能实现的事物的范式转变。

考虑到以太坊开发者面临的实际挑战，如 Gas 限制。如果没有这些限制，以太坊上会有更多的应用程序和功能，但是因为费用过高而被禁用。Monad 的主要目标之一是将现有的 EVM 应用程序从当前的 Gas 限制中解放出来。

Monad 还利用了 EVM 生态系统中丰富的现有代码和产品，为雄心勃勃的建设者提供了一个平台，让他们真正能够构建在其他地方不可能的 dApp。

总的来说，Monad 的重点是加密社区的集体性质。当前阶段是一个实验期，在这个期间，加密爱好者正在为去中心化个人金融构建应用程序。Monad 旨在使这些应用程序更具成本效益，解锁它们真正的潜力，扩展到更广泛的用户群。

你最希望在 Monad 上看到哪种类型的应用程序？

Keone：对我来说，我最希望看到两个领域——去中心化金融（DeFi）和面向消费者的应用程序。

• DeFi

任何能够让普通人以去中心化的方式管理个人财务的应用程序。当然，像货币市场、去中心化交易所、衍生品、高精度和高规模的预言机等应用程序。这是一个我非常兴奋的垂直领域。

在 Monad 之前，我是 Jump 加密团队的一员。Jump 对 Solana 生态系统深感兴趣并兴奋不已，因为这是有道理的。如果费用只有一美分的几分之一，并且您可以扩展到数百万用户，那么你实际上基本上可以取代现有的主导者所做的事情。中心化交易所对数据收取非常高的费用。

我们喜欢 Solana 的原因之一是它是一项非常棒的技术。尽管它缺乏 EVM 兼容性，这可能使得开发体验有些棘手，但自 2021 年 James 和我致力于开发它以来，Solana 已经取得了长足的进步。

• 消费者应用程序

我也对 Monad 上的面向消费者的应用程序感到非常兴奋。例如，体育博彩、赌场、社交，基本上任何在手机上作为移动应用程序有意义的事情都可以。

如果我知道我所有的数据都在我的钱包里，我会更愿意与应用程序、服务和内容互动；这是因为钱包是加密安全的。

EVM 的哪些方面让您对 Monad 路线最感兴趣？

Keone：对我来说，关键在于构建能够最终帮助最多开发者扩展他们应用程序的东西。归根结底，Monad 是一个开发者平台。前往开发人员所在的地方并解决他们真正紧迫的问题非常重要。我认为纯粹的 EVM 兼容性是解决这些问题的一部分，但未来还会出现其他问题，本质上使对更多加密功能的支持变得更容易、更便宜。

归根到底，这只是为了解决阻碍开发者构建在 iOS 商店中排名第一的应用程序的问题。对于我来说，我觉得 EVM 是实现这一目标的最佳场所。

令人惊讶的是，真的没有人专注于执行栈。鉴于我们团队以前的背景，以及我们认为解决这个问题的迫切性，这是一个非常自然的工作领域。

Monad 为 EVM 和以太坊社区的理想提供了一条真正实现产品规模的道路。

「归根结底，Monad 是一个非常酷的组合，我们可以在 EVM 上拥有类似 Solana 的用户体验。然后，开发人员就可以根据系统的需求来选择他们想要构建的位置。」

合作确实很重要。我们的团队意识到我们并不知道所有问题的答案。我们是专家。我们对构建高性能并行系统、拜占庭容错共识和其他非常具体的问题了解很多。但还有很多人在以太坊的研究方面投入了精力，重点关注 MEV 最小化、治理和密码学等问题。所以我认为遵循标准，我们所做的工作与他人的工作可组合的地方也很重要。

Kevin G：EVM 是如此多应用密码学研究、构建应用程序、发展更好的安全实践的中心。能够处于标准的位置并帮助推动整个领域向前发展是非常好的。

因为这样，我们可以深入专注于扩展基础层（这是我们擅长的）同时利用研究社区在该领域的专业知识。此外，我们不必重新构建已经为 EVM 开发的所有开发者工具。

在 EVM 环境中做 Builder，最大挑战是什么？

Keone：我认为有几个。对构建者来说，吸引资金现在相当具有挑战性；投资者社区非常偏向美国。对国际构建者来说，获得资金真的很难。

此外，从安全角度来看，构建 dApp 是具有挑战性的。有大量黑帽黑客不断探寻漏洞，寻找攻击的机会。这使得环境非常具有对抗性。我们需要更好的安全实践，包括 Gas 优化。

通过大幅降低 Gas 成本，Monad 消除了开发者面临的一个巨大抉择；是否包含额外的防御性断言（这会消耗更多 Gas）。

一位 Monad 社区成员在土耳其展示他的新壁画

构建加密产品，被忽视的优势是什么？

Keone：加密社区的强大令人惊叹。如果你正在建立一个传统的科技创业公司，假设你的 Twitter 没有关注者，你可以发布更新，但没人会关心。没有人急于去尝试你的产品。你必须费尽周折，才能让人们免费试用它。

在加密领域，我们有如此强大的社区（社区实际上是核心的一部分），这实际上是对其他科技领域的巨大优势，也是加密最终会成功的一个原因。这实际上只是利用优势并尽量减少劣势，然后我们就可以作为一个行业进行扩展。

2023 年 11 月，社区为 Monad 制作了早期生态系统地图

作为一个行业，区块链刚刚开始成熟。随着时间的推移，区块链将变得更加高性能（到那时，我不希望 Monad 仅因其性能而与其他区块链不同）。

其他系统将做出额外的改进，将会有理念或技术的交叉传播。这最终将推动空间向前发展，使更高性能的应用程序得以构建。我们将继续推动区块链可能性的极限，并引入其他基础设施支持新的实现。

加密 Twitter 上有很多关于 TPS 作为一般交易和投票交易指标的讨论。 TPS 什么时候是一个有价值的指标？

Keone：关于 TPS 的一般测量，我们认为它应该仅计算真实交易，即发生在链上的智能合约互动和转账：而不仅仅是投票交易。对于 Monad 来说，我们不会在任何 TPS 展示中包括投票。

一般来说，关于什么应该算作真正的交易存在很多混淆。许多团队使用不同的指标来计数交易。现在这个领域在如何宣传性能方面非常不统一。例如，有些人将一次交易计为一条指令。所以如果有一个单一的智能合约调用执行了几个子指令，其他人会将其计为约 10 笔交易，这实际上是不正确的。

你真正能够衡量的只是通过系统的交易数量。如果在任何给定时刻，系统没有达到满负荷，那么实际可观察的 TPS 会低得多。所以在这里也存在很多混淆。

我认为真正的解决方案是在 GitHub 仓库中有可重复的基准测试。每个团队都应该为这个仓库做出贡献，并推出一个完整的脚本，定义了在世界各地部署许多不同服务器的过程。然后，脚本能够向系统中的各个节点发送大量交易，并实际重现完整的交易吞吐量测试。

这是我们团队计划引入的东西，至少对于 Monad 来说是这样，但希望也适用于其他竞争性基准测试。这类似于正常的科学研究过程，你不仅要发布你的结果，还要发布你用来生成这些结果的过程。这样，第三方可以重新实验并重现这些基准。这对我们来说非常重要，也是我们打算做的事情。