https://medium.com/ethereum-optimism/the-highly-optimistic-dev-blog-03-introducing-smock-v2-d252441994a8

发布时间：2021年8月12日

作者：Kelvin Fichter

译者：wuhai#7810

Solidity 开发人员：认识Smock V2，Solidity模拟库，Optimism与DeFi Wonderland的出色团队之间的合作。

智能合约测试历来……很难？如果不难，那么只是令人困惑。在 Solidity 的早期，测试合约的最佳方式是编写另一个合约来负责进行所有测试。由于大约 20 个不同的原因，这是一个糟糕的想法。我将列举一些最重要的：

1. 你必须在 Solidity 中编写测试代码。

2. 你不得不重新编译你的测试合约来改变你的测试。

3. 你的测试合约和目标合约共享相同的链状态。

对于所有相关人员来说，这大费周章。基本上没问题，因为当时智能合约相对简单。但是，当然，缺乏测试基础设施意味着合约不会很复杂。

花了一段时间，但我们最终使用像 Truffle 这样的 JavaScript 测试框架来极大地改善测试体验。我们必须继承 chai 和 mocha 等工具的一些不错的特性。我们的测试至少变得有些清晰了。你实际上可以构建具有合理的复杂性的合约系统。

Hardhat 最终出现并改进了 Truffle 最先做的许多事情。但 Hardhat 的主要进步在于其插件系统——开发人员现在能够轻松地操作他们的测试环境，达到 Truffle 从未真正实现过的程度。

然而，在所有这些改进中，Solidity 开发人员仍然不得不处理一个绝对可怕的模式：模拟合约，用 Solidity 编写，只是为了能够对非常具体的功能进行单元测试。我是说，真的。以下是造成这种情况如此糟糕的几个原因：

1. 你必须在 Solidity 中编写测试代码。

2. 你必须重新编译你的测试合约才能改变你的测试。

3. 你的测试合约和目标合约共享相同的链状态。

是的。总而言之。我们解决了这个问题。

介绍：Smock v2，JavaScript 中的合约模拟。比你想象的更强大。永远不要再用 Solidity 编写模拟合约。

特征

伪造任何合约

操作任何合约函数

创建有真实合约支持的模拟

在模拟中操作变量

还有更多……

我真的需要说别的吗？去试试看。它会改变你的生活。严肃地。

https://github.com/defi-wonderland/smock

https://medium.com/ethereum-optimism/the-highly-optimistic-dev-blog-02-a-love-letter-to-etherscan-c415af786ae8#id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjE1NDllMGFlZjU3NGQxYzdiZGQxMzZjMjAyYjhkMjkwNTgwYjE2NWMiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJuYmYiOjE2NTkyNTA3OTgsImF1ZCI6IjIxNjI5NjAzNTgzNC1rMWs2cWUwNjBzMnRwMmEyamFtNGxqZGNtczAwc3R0Zy5hcHBzLmdvb2dsZXVzZXJjb250ZW50LmNvbSIsInN1YiI6IjEwMTE1MTAwOTAwMzMwMjE2NjA4MiIsImVtYWlsIjoibXlrZXkyMjIyMjIyQGdtYWlsLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJhenAiOiIyMTYyOTYwMzU4MzQtazFrNnFlMDYwczJ0cDJhMmphbTRsamRjbXMwMHN0dGcuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJuYW1lIjoid3Ugd3UiLCJwaWN0dXJlIjoiaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FGZFp1Y296b3ZoczNjQVQ1TDVnQ01OeGpQRFhHWUtDaEc1VndWaVRpamRDPXM5Ni1jIiwiZ2l2ZW5fbmFtZSI6Ind1IiwiZmFtaWx5X25hbWUiOiJ3dSIsImlhdCI6MTY1OTI1MTA5OCwiZXhwIjoxNjU5MjU0Njk4LCJqdGkiOiI2OTYwOGNhOTgzMWNjNjdiYzkxMWMxYmZiNTI3MzZlY2NlZjIzZDcyIn0.BniyVUv-hw0oGSkOWs9J_YY14gVH5yB0M3ETyovXilA9DZH-9nHc617STyUe-pRn14RCXbbOnHGqh3T_S5aBtO1c2u3F5CoNeaZmA09eU6iuP28dWDUDMB0KCTCNggfaVT2wA-gihM__WnoFoBOstLOnOPzGEjrGRZXvR1Jr7FiFCRKAlQ4lZZVLKv6C2HKc_vgg3b5LXxIQNdqv-tawv_gWpqCi_TDjiGFh0acgREwRpETGhyAmjQT_5bYFVxWf5P7Bj99zmOFKGcJikDzt4FT0ERaOdzR0KVOw_AwAr10QYB-p8gVdGcyDROOt2OBWhn0rW84aa2vSRRrXUEr1iQ

发表时间：2021年8月11日

作者：Matt Masurka

最亲爱的Etherscan：

如何描述你对我们的意义？让我们来数一数。你是...

知识的稳定提供者； 谦逊的王国守望者； 去中心化的天堂我们望尘莫及； DeFi的立足之地； Web3的默默无闻的骑士； 以太坊忠实的牧羊人…

任何使用过以太坊的人都知道Etherscan。但人们往往不了解这个名称背后的强大团队，不了解他们所打造的产品有多棒，以及这个产品对这个社区有多重要。

同样值得一提的是，Etherscan不提供恼人的广告，没有花里胡哨，也不兜售代币（尽管该团队肯定是当之无愧的）。它只是给你提供你正在寻找的信息，其速度令人难以置信，其结果非常可靠。

在将Optimistic Ethereum投入生产的过程中，我们很大程度上依靠了Etherscan的帮助。一些例子：

帮助L1<>L2可观察性的定制页面；

用于检索OVM上索引交易的定制API端点；

使用户能够最终完成提款的消息中继器。

可以说，Etherscan一直是我们开发过程中不可缺少的一部分。

除了建立以太坊生态系统的一个关键部分外，Etherscan团队平易近人。从他们在我们的群聊中投放的可爱贴纸，到他们对问题的快速响应，再到愿意解决任何功能请求或错误修复，他们是以太坊社区中最细心和最值得依靠的成员。

我代表Optimism的每一个人：向Etherscan表示深深的爱!

译者：wuhai#7810

https://medium.com/ethereum-optimism/the-highly-optimistic-dev-blog-01-the-mystery-of-the-missing-message-23b8ce9b9b82

发布时间：2021年7月28日

译者：wuhai#7810

编辑团队注释：

在 Optimistic Ethereum 的世界中发生了许多有趣的工作，以至于我们经常忘记花点时间告诉世界我们一直在做什么。我们从很多人那里听说，希望更详细地了解 Optimistic Ethereum 的内部运作以及帮助实现它的人。因此，我们推出了一个开发博客，在 Optimistic Ethereum 上工作的人写下他们每天应对的想法和挑战。我们不会在这些博客文章中强制执行任何特定的风格或结构——你将大致了解我们每个人对 Optimism 工作的看法。我们希望这将成为 Optimistic 体验的一个小窗口。

欢迎来到Highly Optimistic开发博客的第一节。

作者：Kelvin Fichter

摘要和背景

这是我们调查导致我们的 Optimistic Ethereum 测试网部署 在 2021 年 6 月初期的几天内停止接受新的 L1 ⇒ L2 存款错误的故事。在某些情况下，L1 ⇒ L2 的充值会占用在L1上的资产（如 Ethereum）并将它们移动到 L2（如 Optimistic Ethereum），在此期间，测试网部署无法正确记入充值。我发现这个故事很有趣，因为**我们能够在不了解错误且确切来源的情况下为该问题创建一个合理的修复程序。**这是突出为人类构建软件的混乱现实的故事之一。我还将在这篇文章中穿插一些我们从事件中学到的工程课程。

注意到特征

在几个用户直接向我们报告问题后，我们首先意识到 Kovan 存款存在问题（提醒我们需要改进对此类问题的自动警报）。报告的一般特征是用户能够通过在 L1 上发送交易来开始充值，但在 L2 上永远不会收到任何资金。显然，这是非常有问题的，因为它阻止了用户将资产转移到 L2 中。这肯定必须尽快解决。

工程学课程 #1：用户报告是最后一道防线

用户报告应该是发现问题时的最后一道防线。如果您因为用户报告而发现问题，那么你可能没有足够的警报到位。在这种特殊情况下，我们应该定期提交存款交易并监控这些交易是否失败。

启动调试过程

我们通过列出可能导致问题的软件的不同部分来开始我们的调试会话。根据用户报告，我们知道以下内容：

1. 可以在 L1 上正确启动充值

2. 充值未正确反映在 L2 上

第 (1) 点意味着该错误可能不是来自我们的智能合约（如果这是智能合约中的问题，存款交易可能会恢复）。幸运的是，我们的软件堆栈相对简单，没有多少地方可以隐藏错误。如果问题不在合约中，那么它要么在 L2 geth 节点中，要么在将事务传送到 L2 geth 的过程中（一种称为数据传输层或简称DTL的工具；这是一个非常模糊的名称，我们'正在接受替代建议）。

DTL 是一个最小的软件，通常不会出现这样的故障。我们自己做了一些存款，发现 DTL正确地发现和索引了这些存款，所以我们的怀疑转向 L2 geth。除了我们的新存款交易显然没有在 L2 上执行之外，快速浏览日志并没有透露太多信息。

幸运的是，当我们发现以下日志行时，我们的运气发生了转变：

当L2 geth 尝试执行一系列 L1 ⇒ L2 充值交易时，会发出这些日志。我们预计start值会随着时间的推移而增加，因为 L2 geth 应该执行一个事务并继续执行下一个事务。start值没有改变的事实表明 L2 geth 在尝试执行 deposit 时不知何故卡在了2500。现在我们只需要找出充值在2500发生了什么。

检查 DTL

弄清楚发生了什么的最简单方法是检查数据传输层，看看有什么被发送到 L2 geth。DTL 有一个很好的 API，我们可以手动查询它以查看发送给定序器的内容。所以我们发送了以下查询：

我们得到了什么？null. 显然，DTL 没有这笔存款的任何记录。

那么充值2501呢？

不是null！是的，DTL 有这方面的记录。在那之后，它对所有其他充值都有记录。这显然是最初问题的根源。DTL 没有2500充值记录，因此 L2 geth 无法完成超过2500的充值，但仍接受新的充值。

寻找根本原因

这个错误的奇怪性质表明它可能是非确定性的。我的意思是，为什么会在2500丢失充值？果然，一个从头开始同步的新 DTL 很好地获得了充值。这意味着我们可以通过重置生产 DTL 使系统重新上线，但我们仍然不明白为什么会发生这种情况。为了避免将来出现类似问题，我们着手寻找根本原因。

对我们来说幸运的是，DTL 是一个相对简单的软件——它的作用并不大。它基本上只是一个循环：

1. 查找与之同步的最后一个 L1 块

2. 查找下一个要同步的 L1 块

3. 在该块范围内查找、解析和存储事件

4. 更新与之同步的最后一个 L1 块

结果，没有多少事情可以导致它像这样破裂。对我们来说没有什么明显的突出之处，所以我们最终不得不做一些挖掘工作。我们按照可能性递减的顺序提出了三个潜在的错误来源。

选项 1：也许 Kovan 重组

我们的第一个直觉是，也许 Kovan 经历了一次大规模的区块重组。当发生大规模重组时，节点可能会暂时看到网络的过时视图。Kovan 上的DTL 被配置为在接受交易之前等待 12 个确认（块）。如果这是根本原因，那么我们预计会看到超过 12 个块的某种重组。

快速浏览一下Etherscan 的重组列表，我们又回到了原点。在事件发生时，近一个月没有发生重组。除非 Etherscan 经历了大规模的局部中断并且与 Kovan 的其他部分不同步，否则不太可能有任何类型的 12+ 块重组被忽视。进入下一个。

选项 2：也许我们不小心跳过了一个块

如果它不是重组，那么也许我们的软件真的只是在同步过程中不小心跳过了一个块。尽管这似乎不太可能，但我们需要确保这不是问题的根源。

为了弄清楚我们是否跳过了一个区块，我们必须找到一个特定的日志行来告诉我们是否扫描了包含存款的 L1 区块。为此，我们首先需要找到发出事件的块。所以我们回到 Etherscan搜索存款：

这里的返回值是一个结构体，形式如下：

其中timestamp和blockNumber是提交此充值的区块的时间戳和区块号。我们得到了我们想要的：这笔存款是在 25371197区块中提交的。现在我们只需要查看 DTL 日志就可以（希望）找到一个覆盖相关块的日志。果然：

此日志行中的targetL1Block与我们正在寻找的 L1 块匹配。我们肯定试图同步包含充值的区块。那么为什么我们什么都没看到呢？

选项 3：也许 Infura 破产了

我们对 DTL 日志的调查清楚地表明，DTL应该已经检测到充值，但没有。此外，DTL 在同步此块时没有发出任何错误。我们只是没有找到任何事件。

对我们的 DTL 代码相对有信心，我们开始寻找潜在的因素来责怪我们以外的人（因为这样更容易）。我们发现 Infura 在触发此错误的同时返回了各种 504 错误：

有趣的？是的。证明 Infura 有问题？没那么多。6 月 9 日，Infura 可能出了点问题。或者可能不是。谁知道。不幸的是，我们没有存储 RPC 请求的记录，因此无法仅使用日志进一步调试此问题。

工程学课程 #2：记录你的 RPC 请求。

如果以太坊节点对您的系统至关重要，请考虑记录对该节点发出的所有 RPC 请求。日志总是可以在一段合理的时间后被删除，以保持较低的存储成本。

工程学课程#3：Infura 不是共识。

考虑同时向多个节点或节点提供者发送请求，以交叉检查传入结果的有效性。考虑自己托管一个或多个节点。你绝对不应该依赖你的节点提供者将始终返回正确结果的假设。信任但要验证。

解决方案：学习、适应并继续前进。

我们陷入了一个相对不令人满意的结论：要么是 Infura 坏了，要么是我们的系统中存在我们无法弄清楚的错误。我们也承受了一些压力，因为人们依赖我们的 Kovan 测试网，而且系统中的存款仍然完全无效。我们知道我们可以重新同步 DTL 以恢复系统，但没有找到根本原因的前提下我们可能在1-2天内遇到同样的问题。

经过一番讨论，达成妥协：

1. 重新同步 DTL 以备份系统。

2. 向 DTL 添加更多逻辑，以便它可以从丢失的事件中恢复。

3. 每当触发此恢复逻辑时添加一条日志行，以便我们将来可以进一步调试。

这种策略最好的解决了问题。DTL 的新恢复逻辑使我们免受潜在问题的最坏影响。如果错误再次出现，我们将得到一个方便的日志行，而不是一个停止的系统。双赢。

工程学课程#4：根本原因不是一切。

有时可能（更为可取的）在你完全理解之前缓和问题。你仍应监视该问题未来发生的情况。动脑筋想一想这个未知的错误可能对你的系统引发的其他影响。

结论

这样一来，我们就可以在不了解其根本原因的情况下有效地缓解错误。自最初的事件以来，我们的补丁已经多次成功地从这个错误中恢复过来。在写这篇文章的时候，我们仍然没有弄清楚这个问题的根本原因——我们有太多其他的事情要做，而我们的恢复逻辑在处理这个问题上做得非常好。

我发现这个传奇故事很有趣，因为它突出了软件工程的一些更为无可奈何的一面。构建和维护软件的过程从未像我们所希望的那样简单。实际问题往往会以牺牲“理想”方式做事为代价。归根结底，好的软件工程更像是一门粗糙的科学，而不是纯数学。当人们为其他人构建软件时，你将需要处理出现的混乱情况。你所能做的就是充分利用它：学习、适应和继续前进。

我们正在招聘以建立以太坊的未来。如果你喜欢在此处阅读的内容，请查看我们的职位列表。也许你会找到你的下一个归宿。

https://medium.com/ethereum-optimism/all-gas-no-brakes-8b0f32afd466

发布时间：2021年12月17日

译者：wuhai#7810

今天是一个非常特殊的时刻，也是Optimism和整个以太坊生态系统一个令人兴奋的里程碑。

Optimism官方：白名单机制取消，任何人都可以部署到Optimism主网!

为什么有白名单？

Optimism推出白名单，这样我们就可以与在Optimism网络上构建应用程序的项目直接沟通。这种双向联系意味着我们可以很容易地与其他团队联系以规划更新，其他团队可以很容易地与我们联系以报告错误。

这种紧密的反馈回路意味着建立在Optimism上的项目对整个协议的方向有很大影响。早期采用者在为第一版OVM开发应用时经历的痛苦，推动了我们向EVM等效的方向发展。而EVM的升级之所以如此顺利，部分原因是我们能够与每个可能受到影响的人保持密切联系。

Optimism的未来

Optimism即将迎来第一个生日。在过去的一年里，我们一直忙于压力测试和加固网络，以应对接下来要发生的事情。经过大量的准备工作，我们终于准备好卸下我们的辅助轮。从今天起，Optimism不再有白名单，任何人都可以自由部署合约。

白名单的取消标志着Optimism历史上的一个新篇章。去中心化是一个具有挑战性的、循序渐进的过程。无许可合约部署使我们离我们的愿景更近了一步，我们有一个真正开放、可访问和乐观的以太坊。

白名单的删除也意味着我们不会再进行任何再生式的更新。所有未来的升级将保留所有状态、交易历史和事件数据。Optimism是一个生产系统，我们致力于保持这种状态。

我们也在努力建设Optimism的未来。在接下来的一年里，我们将推出一些令人兴奋的更新，旨在使网络比以往更快、更便宜、更安全。为了使之成为可能，我们保持中心化的防护，让Optimism团队控制网络的各个部分。例如，Optimism团队成员共同控制一个多签名钱包，该钱包有能力升级任何部署在以太坊上的Optimism合约。作为一个希望在Optimism上构建的开发者，请记住目前这种安全模式，并知道Optimism团队正在夜以继日地工作，使系统走向完全去中心化。

来和我们一起构建

白名单的取消，加上我们的EVM等效升级的完成，意味着Optimism现在比以前更容易访问链接。现在是在Optimism上构建和部署应用程序的最佳时机。我们有很多资源可以帮助你开启。

如果你正处于开发的早期阶段，或者只是想了解更多，请进入我们的Discord，Optimism社区可以回答你的问题。你也可以在https://community.optimism.io/，找到你需要的大部分文档开始使用。

如果你准备好部署你的应用程序，你可以填写这个可选的表格，以便在部署过程中获得更多的实际帮助，并帮助你传播你的项目：https://optimismpbc.typeform.com/get-in-touch。

参与进来

一如既往，乐观主义正在招聘。如果你想在加密货币领域最酷的项目之一工作，与以太坊领域最聪明的人一起工作，那就不要再找了。请查看我们的招聘栏，了解完整的公开职位列表：jobs.optimism.io。

如果你不想找一个全职职位，但仍然想帮忙，我们在GitHub上为新的贡献者保持了一个良好的首发列表。我们也经常在Gitcoin上发布这些问题的赏金。参与进来吧，我们保证这值得你花时间。

LFG

我们对Optimism和Ethereum的未来都非常乐观。我们迫不及待地想看到你在L2上部署的创新的应用。

建立一个没有商业模式的雄心勃勃的项目是非常困难的。很难获得资金，很难雇用最好的人，也很难在创造伟大事物的艰辛和障碍中坚持下去。

即使有充足的投资资金，初创企业也是出了名的困难挑战：大多数人都会失败。但它们有一个重要的优势--有可能退出。退出通过股权，为前期的资金、招聘、激励和调整创造了动力。然而，对于非营利组织、自由和开源软件以及公共产品项目来说，这种 "隧道尽头的光 "并不存在。

有鉴于此，许多最好的和最聪明的建设者，甚至那些真正想做最大限度的好事的人，最终走上了营利的道路，即使最后会在使命上做出妥协，这也不足为奇。对许多人来说，这不仅仅是财富的问题，也是公平的问题。为什么要辛辛苦苦地建设自由软件，让别人从中赚取巨额利润，而自己却没有任何收益？

那么......如果突然间，公共产品项目真的存在退出，会发生什么？一个由项目创造的公共利益的多少而不是季度利润决定的退出。我们是否会看到更多的投资和创新，使社区利益最大化的技术？我们是否会看到更多的非营利组织茁壮成长，而不是苟延残喘？

我们提出了一个实现这些目标的机制，如下。通过协议产生的收入、追溯性的公益资金和 "Results Oracle"，我们将为公共项目创造一个创业式的资金循环。我们，Optimism团队，承诺将我们从sequencing中获得的所有利润（在去中心化sequencer之前）交给公共资助实验，包括第一个公益退出。虽然现在还没有任何利润可以授予，而且细节还在发展中，但我们很高兴现在就做出这个承诺，并分享我们第一个实验的基本想法。

追溯性公共产品资金DAO如何运作？

by Vitalik Buterin

追溯性公共产品资助概念背后的核心原则很简单：在什么是有用的问题上达成一致比在什么将是有用的问题上达成一致更容易。前者仍然经常是分歧的来源，但这是一种分歧的类型，你仍然可以通过使用一些现有的投票机制（例如，二次投票甚至常规投票）来获得合理的高层判断，后者则更具挑战性。对于盈利部门，我们能做的最好的事情是建立一个生态系统，人们可以创建初创企业并对其进行投资，如果他们最终是正确的，就可以得到奖励。因此，与其完全重新发明轮子，我们将创建一个完全相同的机制的面向公共产品的版本。

一个DAO，我们可以称之为 "Results Oracle"，为公益项目提供资金。长期来看，Results Oracle可以由协议费资助（例如，如果由L2项目实施，sequencer拍卖就是一个候选项目）。但与其他公共产品资助的DAO不同，"Results Oracle"对项目进行追溯性资助，奖励那些它认为已经提供了价值的项目。

这个Oracle的设计是一个非常复杂的问题（另见：已知的像硬币投票这样的天真方法的长时间问题），最好是迭代式地处理。一个简单的早期版本可能是在实施该方案的生态系统中挑选出20-50名技术熟练的长期贡献者。随着我们对去中心化治理的理解的提高，该方案可以在此基础上不断改进。

Results Oracle 可以向任何地址发送奖励。下面是一些关于它可以向哪类地址发送奖励的可能想法。

• 一个主要负责实现项目的个人或组织

• 一个代表固定分配表的智能合约，在为项目贡献时间和/或资金的多个个人和/或组织之间分配资金

• 一个项目代币，其供应量在一个或多个为项目贡献时间和/或资金的个人和/或组织之间分配，但它可以被交易

在第一种和第二种情况下，results oracle将只是把资金发送给接受者。它们都可以实现为分配表，即接受资金并立即按照特定的分配方式将其重新分配给接受者的合同。

项目代币是一个更激进的想法，本质上是为results oracle将资助什么创建一个预测市场。results oracle可以用它的资金为代币设定一个价格底线：如果它分配了X美元的奖励，而项目有N个代币的总供应量，那么它就发布一个公开订单，以每个代币X/N美元的价格购买多达这些代币的全部供应。

通过设置价格下限（相对于一次性结算）进行资助，允许oracle对同一个项目进行多次奖励。它还允许项目代币既能从results oracle处获得奖励，也能从其他来源获得奖励（例如，其他拨款机制、类似NFT的可收集价值、项目自己的经济模型，如果它后来得到了一个）。制作多个奖励可以通过从预先存在的订单中提取资金，并使用合并的资金制作一个新的订单，设置一个更高的价格底线。

因为任何人都可以为任何东西创建分配表或项目代币，所以有可能在一个项目内对贡献水平产生分歧，导致同一项目出现多个竞争性分配表（或项目代币）。在这种情况下，results oracle必须不仅决定哪个项目是有价值的，而且决定哪个项目代币或分配表（或多个代币/表之间的分配）是对谁的贡献的更好衡量。这种判断是不能完全避免的，尽管希望只在特殊情况下才需要这种判断。

谢谢 Vitalik !

种子资金

我们上面提出的是一个多层次的生态系统，要想让一个新的生态系统从零开始迅速建立起来是很困难的！因此，我们必须要有足够的资金。不同的参与者可以采取几种策略来帮助这个生态系统的起步。

• 项目和基金会的赠款计划

• 项目在Uniswap上出售其公共物品代币

• 二次融资

结论

非盈利模式对于维护一个已经建成的代码库可能很有效，但启动一个项目的开始阶段是非常困难的。绝大多数的初创公司都无法实现任何形式的退出，而对于FOSS项目来说，这就更难了。它往往是一小群高度敬业的人的缓慢的爱的劳动。捐赠不是一个稳定的资金来源，不足以让一个团队计算出跑道。资助金不足以提供有竞争力的薪水。为 "正确的原因 "在某地工作并不能支付账单。

这些英雄们的利他主义有一种美感，但作为他们所创造的东西的狂热用户，我们难道不应该希望他们也能得到报酬吗？

通过为开源软件项目提供一个出口，我们实际上也激励了一个资金来源的出现。从出口往回走，开源项目现在可以盈利了。

译者：wuhai#7810

原文：

https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c