作者：Alex Graebe (Hiro PBC)
由于可验证和好用的智能合约来源，每个新的 Clarity 合约都可以 引入100 个 Stacks 开发人员。
我于 2020 年初加入 Hiro，担任开发人员产品主管。在最初的几周里，我开始研究和学习有关新 Stacks 2.0 区块链的一切知识。最初，我对一些非常特殊的工程设计决策感到惊讶，但也很感兴趣。 Stacks 正在研究区块链技术的新颖和细微的实现方式，并且总是倾向于在其他人往左时它往右。在设计新的 Stacks 区块链时，Stacks 具有在智能合约领域成为快速学习者的优势。可吸收在 ICO 热潮期间和之后在以太坊空间展开的学习。
这篇文章旨在强调 Stacks 区块链的两个看似很小但具有巨大潜力的设计决策：真正可验证和可用的智能合约来源。让我来解释…
随着智能合约的兴起，个人不再需要相互信任合同义务会得到履行。虽然这可能确实如此，但信任现在已经转移到智能合约的开发者身上。有人可能会争辩说，将接力棒交给不熟悉的开发人员会使问责制变得更加困难。我们中有多少人认识并信任我们可能想要与之交互的智能合约的开发人员？
如今，这一挑战主要通过以下几种方式来解决：
• 开发人员正在开源未编译的合同源。这是一个好主意，但并不能保证所签署的合同基于此源版本。
• 公司正在审计智能合约，开发商发布报告。这是一个非常有价值的解决方案，但以类似的方式将接力棒传递给我们必须信任的另一个实体。
• 区块链浏览器使开发人员能够手动上传已部署合约的来源。探索者会收集一些信息，并根据网络上合约的字节码对其进行验证。这是一个很好的解决方案，但依赖于手动工作和资源管理器的支持。
为了缓解其中一些透明度痛点，Stacks 做了两件不同的事情：首先，它决定使用一种非编译的智能合约语言 Clarity。二是强制公开每份合同的来源。因此，部署在 Stacks 网络上的每个智能合约都包含可执行、未编译和人类可读的源代码。
这是一个非常重要的结果：个人不必信任其他实体！他们可以验证并信任部署的合约本身。
现在，这些设计决策如何影响开发人员？简而言之，它启用了“智能合约的 GitHub”。
在区块链界的现阶段，智能合约开发者的任务特别艰巨。通常，他们必须学习新的语言（或其风格），很难找到工作示例代码，并且经常有一种新的做事方式或最佳实践被标准化。
最成功的智能合约平台会尽最大努力收集优秀的示例项目，对代码片段进行注释和评论，并使它们更容易被发现。 OpenZepplin Contracts 就是这样一个集合的很好的例子。像这样的解决方案的困难是很好理解的：它们要么必须不断维护，要么会开始产生负面影响（过时的示例代码）。
由于上述设计决策，Stacks 网络在这方面表现出色。由于 Stacks 区块链上部署的任何智能合约都可以获得可执行的、未编译的、人类可读的源代码，因此开发人员可以访问始终最新的、功能性的智能合约。 GitHub 等网站可以让开发人员轻松发现相关代码示例、学习其他开发人员的代码并启动自己的项目。
我认为在接下来的几年里，我们将看到 Stacks 智能合约飞轮起飞：
合约的可用性将吸引开发者。开发人员将能够在现有的智能合约上构建，为更多的开发人员提供更多的合约。
所有这一切中最好的部分是：这不是对未来的愿景！我们不必等待太久，Clarity 合约的可发现性已经被利用。前往工具 Clarity Search，查找部署到 Stacks 主网上的 70 多个有效智能合约，并开始在比特币上构建您自己的智能合约！这个新的智能合约档案直接从区块链中提取数据，并显示一个按最近部署排序的有组织的列表。您不再需要通过浏览器来查找特定合同。 Clarity Search 是一个强大的搜索引擎，可让您选择某些参数和过滤。它还显示有趣的指标，例如文件执行的合同调用次数或代码的整体复杂性。这对于快速浏览网络上已经发布的智能合约来说绝对是不可或缺的。
英文原文：https://www.hiro.so/blog/theres-nowhere-to-hide-with-clarity