报邹、瞧，大卫；帕夫涅特辛格科赫哈尔；乐，宣-巴赫d；夏、辛；冯、杨；陈、振宇；还有徐、智能合约开发：挑战与机遇。(2019) .软件工程汇刊。1-20.计算与信息系统学院。https://ink.library.smu.edu.sg/sis_research/4496
1.摘要智能合同，最初是指法律合同的自动化，由于区块链技术的出现而引起了人们的兴趣。最近，这个术语被广泛用于指代在区块链平台上运行的底层代码脚本。我们的研究集中在智能合同上。智能合约越来越受欢迎，在现实世界中已经发现了很多重要的应用(比如众筹)。尽管智能合约开发越来越受欢迎，但由于其特殊的设计和应用，许多开发人员仍然面临一些问题。智能合约开发和传统软件开发有什么区别吗？开发者在开发智能合约的过程中会面临怎样的挑战？这些问题很重要，但研究人员还没有探索它们。在本文中，我们进行了一项探索性研究，重点是以太坊(最受欢迎的智能合约公共区块链平台)，以了解开发人员在开发区块链智能合约时面临的现状和潜在挑战。为此，我们的研究分为两个阶段。在第一阶段，我们对来自GitHub的20名开发人员和从事智能合约的行业专家进行了半结构化采访。在第二阶段，我们调查了232名员工，以验证访谈结果。我们的采访和调查结果揭示了开发人员在智能合约开发过程中面临的几个主要挑战：(1)没有有效的方法保证智能合约代码的安全性；(2)现有的开发工具还很基础；(3)编程语言和虚拟机还是有一定的局限性；(4)在资源有限的运行环境中，性能问题难以解决；(5)在线资源(包括高级/更新的文档和社区支持)仍然有限。我们的研究提出了几个方向，研究人员可以在这些方向上努力工作，以帮助改善开发人员在开发高质量智能合同方面的体验。
关键字：智能合同，挑战，实证研究，区块链
2.简介近年来，区块链技术的潜力已经发展到加密货币之外，其中智能合约在区块链是一个很有前途的应用。“智能合同”一词最初用于指法律合同的自动化。这个术语用来指一个法律契约，或者至少它的一部分可以用软件来表达和实现。最近，随着区块链技术的出现，智能合约引起了人们极大的兴趣。该术语通常用于指在分布式分类账(如区块链)的多个节点上同步运行的代码脚本。本文重点关注智能合约的更具体的定义，即在区块链中运行的底层代码脚本。
越来越多的职业和领域与智能合约相关，相关开发者也开始努力在不同领域实现智能合约。为了帮助促进智能合约开发的研究，我们进行了一项实证研究，重点是以太坊，以探索开发商在区块链智能合约开发中的工作实践和面临的潜在挑战。我们采用了访谈(定性)和调查(定量)相结合的方法。首先，我们采访了20名具有不同背景和专业知识的开发人员，询问了参与者在智能合约开发的不同阶段(如编码、测试和调试)的正常工作实践和相关挑战。然后我们用开放卡分类对面试结果进行分析。开卡分类生成的结果类别分为六组，分别是安全、调试、编程语言、以太坊虚拟机、gas、在线学习资源、社区支持。之后，我们对232名开发人员进行了验证调查，以确认采访中的各种见解，包括挑战、最佳实践和需要改进的地方。
通过访谈和调查，我们发现开发人员非常关心代码的安全性，但是却没有有效的方法来证明自己代码的正确性、可靠性和安全性。与此同时，缺乏强大的工具，尤其是分步或交互式调试器，往往使编写智能合同变得很痛苦。开发人员面临的另一大挑战是性能――他们感兴趣的工具和资源可以帮助他们编写高效的智能合同，并消耗更少的区块链资源。此外，缺乏先进和最新的文档以及在线社区的延迟响应也影响了智能合同的发展。
我们研究的主要贡献如下：
1.
据我们所知，这是第一个通过访谈和调查来探讨从业者对智能合约发展现状和未来挑战的看法的深度研究。
2.
我们分析定性和定量数据，并强调可操作的见解和含义，开发者、工具构建者和研究人员可以使用这些见解和含义来改善智能合约开发过程中的开发者体验。
本文其余部分的结构如下：在第2节中，我们提供了关于智能合同的背景材料。第三部分详细介绍了我们的实证研究方法。我们的研究结果见第4节。第五节根据我们的发现提出了一些潜在的研究方向。第6节讨论了对这项研究有效性的威胁。最后一部分介绍了相关工作，并对我们的研究进行了总结。
3.背景区块链。
ong>区块链的简单形式是一个称为块的记录链，其中的块使用密码学进行链接和保护。区块链可以被认为是一个公共记录报，其中每个块包含一些交易记录。它不是存储在单个位置，而是存储在一个网络节点中，每个网络节点都有这个区块链的副本。这意味着所有记录都是公开的，并且很容易对所有网络节点进行验证，这使得一个节点修改区块链中的任何数据都非常昂贵。一旦一个区块被添加到区块链，在没有获得所有节点的一致意见的情况下，修改区块交易是非常困难的。智能合约。智能合约一词是由 Nick Szabo 在 20 世纪 90 年代中期创造的。他建议将合同条款翻译成代码，并将其嵌入到软件或硬件中，使其自动执行，以最大限度地降低交易各方之间的合同成本，并避免在合同履行过程中意外的例外情况或恶意行为。目前，不同学科的人们以不同的方式使用智能合约这个术语。一种将智能合约表述为一种可以用软件来表示的合法合约，而另一些则将智能合约作为代码脚本，在满足预定义条件后执行特定任务。在本文中，我们主要关注在区块链运行的底层代码脚本。从技术上讲，智能合约是一个既包含数据（如账户余额）又包含可执行代码的程序，可以存储在区块链中，并在满足一定条件时自动执行。
Corda上运行的智能合约。Corda 是一个开放源代码的区块链平台，它是为金融服务行业高度监管的环境而设计的。Corda 节点之间的通信是点对点的，交易历史是完全加密的，仅对必要的一方私有。运行在 Corda 上的智能合约同时包含代码和法律散文。在智能合约执行过程中出现法律纠纷时，相关的法律文本可以追溯到传统的法律体系。
在线/离线智能合约。由于区块链技术的性质，部署在区块链的智能合约（即在线智能合约）通常需要由每个节点执行和验证，所有相关交易都对整个区块链网络可见。离线智能合约在区块链之外执行，只需要由感兴趣的参与者签署和执行。为了保存区块链的属性和好处，在实践中，离线智能合约的结果将是例如登录到链上。
智能合约的区块链平台。区块链可以分为公开类和非公开类。公开的区块链平台允许任何用户加入网络，而非公开的区块链平台只允许允许用户加入。不同的区块链平台对智能合约提供不同的支持。
以太坊。自 2015 年 7 月发布以来，以太坊已发展成为最受欢迎的智能合约区块链平台。以太坊提供了一个去中心化的图灵完备机器，即以太坊虚拟机（EVM），用于使用公共计算节点的国际网络执行脚本。
Gas（燃料）。以太坊采用一种内部定价机制，即对在其上运行的所有交易使用 gas。Gas 是一种衡量一笔交易需要多少计算资源的方法。
可信执行环境（TEE）：为了保护智能合约的机密性或隐私，正在努力将可信执行环境（TEE）与区块链集成在一起。TEE 是主处理器的一个安全区域，它确保敏感数据在一个称为 enclave 的隔离环境中被存储、处理和保护。
4、方法图 1 是我们的方法设计的概述。总的来说，我们的研究包括两个部分：对 20 名专家开发人员的一系列访谈，以深入了解智能合约开发，以及后续调查，以验证访谈的结果。下面我们将详细描述我们如何进行采访和调查。
图 1 方法设计概述
4.1 采访协议。在我们的研究中，我们进行了半结构化访谈。具体地说，我们在每次访谈开始时都有一个介绍，一个对我们的研究的简短解释以及一些关于受访者的人口统计问题。接下来，我们使用了一些开放问题来指导讨论，开放问题的完整列表可以在 https：//github.com/SurfGitHub/smartcontractStudy/blob/ master/interview questions.pdf 上找到。这些开放式问题探究了我们的受访者对智能合约开发和传统软件开发的主要差异的看法，以及它们对执行各种智能合约开发活动所带来的影响、挑战等。
我们总共有 31 位采访者候选人。在访谈过程中，我们遵循所采用的方法来决定何时停止访谈，即在调查结果达到饱和时停止访谈。更具体地说，如果认为所收集的数据已经足够，而进一步的数据收集没有产生新的信息，那么就不应该继续进行抽样。
考虑到行为和脑科学中的研究结果“不同人群的实验结果有很大的差异性”。在决定是否达到饱和之前，我们确定采访了来自不同背景的参与者（如表 2 所示）。在每次访谈中，进行访谈的人共同提出问题并做笔记。面试结束后，他们会将自己的笔记与之前的笔记进行比较，看看这次面试是否带来了新的见解。最后，在采访了 20 个人之后，当我们的调查结果达到饱和时，我们停止了采访。
表 2. 受访者基本情况
表 2 为受访者的基本人口统计资料。从表中可以看出，受访者在访谈时，一般软件开发的平均经验为 11.35 年，智能合约开发的平均经验为 1.27 年。此外，他们还扮演着各种角色，包括开发人员、测试人员、项目经理、架构师、设计师、首席执行官/CTO、研究助理和智能合约培训师。这在很大程度上保证了这 20 人的异质性。
4.2 调查
设计。我们的调查包括一些人口统计问题和智能合约问题。人口统计问题主要是为了了解被调查者的背景和经验。具体来说，我们创建了 8 个人口统计问题，询问受访者的主要角色（如开发、测试等）、在软件工程和智能合约开发方面的经验、国家、最高学历，以及他们主要从事的项目和区块链类型。
智能合约问题的设计是为了验证我们通过分析受访者的评论得到的见解。对于我们通过分析访谈回答确定的六个类别（即安全、调试、编程语言、以太坊虚拟机、gas 和在线资源及社区支持）中的每一个，我们都创建了一组调查问题。我们总共创造了 27 个问题。对于其中一些问题，我们要求受访者在 1 到 5 的李克特量表（1 =非常不同意，5 =非常同意）上对陈述进行评级。对于其他一些问题，我们要求受访者从众多选项中选择一个或几个。我们调查问题的完整列表可以在 http：//github.com/SurfGitHub/smartcontractStudy 上找到。
5、发现
在本节中，我们首先报告通过对访谈内容使用开放卡片分类确定的六个类别中的每一个的发现。每个类别都有几个子类别。对于每个子类别，我们挑选了一些最有意义的评论，并突出了一些我们根据调查反馈得出的统计数据，以突出调查结果的普遍性。然后，我们介绍了每个人口群体针对这些挑战和受访者提到的期望改进的投票结果，以及对这些结果的相关显着性检验。最后，我们对我们的访谈和调查结果进行了简要的总结。
5.1 安全性
5.1.1 关注智能合约安全性
根据我们的采访和调查，我们发现确保智能合约的代码安全性重视度很高。在我们的调查中，我们发现 75.0%的受访者同意智能合约开发对代码安全性的要求比传统软件开发高得多的说法。基于受访者所强调的原因，我们可以找到三个主要的主题，来解释为什么在智能合约开发中越来越关注安全性。
信息处理的敏感性。由于智能合约通常控制和管理敏感的数字资产（如虚拟货币、令牌、数字艺术文件等），人们自然会比传统软件更关心其安全性。正如 P20 所述：开发人员通过代码处理资金或资金流动。人们当然会对代码安全性有很高的要求，因为它控制着他们的资产。
不可逆转的交易。与传统的软件开发不同，用户在基于区块链的金融系统上使用智能合约进行交易时，无法挽回他们所经历的任何损失。由于智能合约在区块链运行（交易无法恢复），如果你损失了你的钱，你将永远失去它。一位开发人员提到：智能合约开发是非常无情的，因为你可能会损失很多钱，而且不可能收回。你知道，我们无法恢复区块链（P12）上的任何交易。
代码在部署后不可修改。智能合约的代码部署到区块链后不能更改。与传统软件不同，开发人员不能提供补丁来修复错误。正如 P9 所述：由于区块链的存在，智能合约从根本上不同于常规编程语言。一旦部署，智能合约就很难改变。71.6%的调查受访者一致认为，在开发过程中难以保证智能接触的安全。根据我们的采访，我们能够发现这些困难的四个主要方面：公共代码访问、编译器的缺陷、缺乏编写安全代码的最佳实践、缺乏验证代码正确性的工具/技术。
5.1.3 当前的安全最佳实践
由于编写安全代码是开发智能合约应用程序的主要关注点之一，我们询问了开发人员，在面临诸多挑战时，他们遵循哪些步骤来确保安全性。受访者提到，测试和代码评审是他们确保智能合约正确性的主要方式，下面将详细讨论。
测试：为了更好地理解智能合约测试在实践中的情况，我们询问受访者他们进行了什么样的测试，使用了什么样的代码覆盖率，然后我们询问了他们在智能合约测试中面临的潜在挑战。调查结果显示，84.9%的开发人员进行了单元测试，61.6%的开发人员执行了集成测试，25.4%的开发人员执行了性能测试。尽管智能合约项目规模不大，但 72.4%的受访者认为测试智能合约比测试传统软件项目更困难。表 3 列出了测试受访者所评价的智能合约的主要挑战。最大的三个挑战是：（1）开发者需要考虑所有的极端情况和场景；（2）编译器和虚拟机本身存在潜在的看不见的缺陷；（3）没有像其他语言那样成熟的测试框架，例如 Java。
表 3. 测试智能合约的主要挑战
代码评审：84.9%的受访者同意代码评审是确保智能触点正确性的重要途径。我们的调查统计数据确实反映了现实中执行的不同类型的评审：83.6%的受访者表示他们会经常在团队内部执行同行代码评审；26.3%的受访者表示，他们经常在 GitHub 上请求帮助进行代码审查；27.2%的开发人员表示，他们经常会雇佣第三方代理来审计他们的代码。
5.2 调试
在我们的采访中，大多数参与者抱怨与传统的软件开发相比，调试智能合约代码更痛苦。在我们对开发人员的后续调查中，88.8%的受访者也认为智能合约应用程序调试困难。
正如前一节所强调的，缺乏对智能合约开发调试的支持；我们很好奇地探索智能合约开发人员在调试代码时是否遵循某些实践。根据我们的访谈和调查结果，我们总结了智能合约开发人员当前的调试实践如下：
1.
在我们的调查中，65.1%的受访者表示他们使用现有的调试工具，例如 Remix 或 truffle debugger 来调试有 bug 的代码。然而，另外 65.1%的受访者提到，他们经常手动注释代码，逐步缩小有 bug 的代码搜索空间。
2.
56.5%的受访者提到，他们通常会编写额外的方法或者事件来检查变量和事务状态。这可以归因于现有的工具不支持检查变量值和事务状态。
3.
17.2%的受访者提到他们在遇到 bug 时会经常通过一些论坛寻求 GitHub 社区或其他开发者的帮助，比如 Stack Overflow。
5.3 编程语言5.3.1 稳定性的限制性
与用成熟的通用编程语言（如 Java/Python）开发的传统软件不同，大多数智能合约是用专门设计的编程语言（如 Solidity）开发的。根据我们的调查和访谈发现，Solidity 的主要局限性包括：缺乏通用库、缺乏对错误记录或报告的支持、
缺乏标准和规则、缺乏对数据类型的安全检查、调用外部函数的不方便方式、缺乏对内存管理的支持、局部变量的约束数量。
5.3.2 最理想的 Solidity 改进
为了帮助社区解决开发人员最关心的限制，我们要求每个调查受访者选择多达 3 项他们希望在 Solidity 中看到的改进。 由于不可能通过访谈涵盖所有限制，因此我们提供了“其他”文本选项，该选项使受访者可以填写他们希望获得的相关改进，而这些改进在访谈中是没有的。 此外，我们提供了一个我认为 Solidity 足够完善答案的选择。
表 4 显示了投票结果。在表 4 中，我们发现只有 6.5%的受访者认为 Solidity 足够好。大多数开发人员关注的主要是库的可用性（包括通用库（53.0%投票）和一些标准接口（45.7%投票））、错误报告函数（48.7%投票）、数据类型检查（44.8%投票）和调用外部函数的更好方式（占 35.8%投票）。
表 4. 开发人员最希望在 Solidity 上的改进。
5.4 以太坊虚拟机（EVM）5.4.1 对 EVM 的限制性
与在 JVM 和 CLR 等成熟且经过良好测试的虚拟机上运行的传统软件不同，以太坊区块链的智能合约由相对较新的虚拟机（以太坊虚拟机（EVM））执行。 与诸如 JVM 之类的传统 VM 相比，当前的 EVM 具有多个限制。 我们的调查结果表明，有 35.3％的受访者投票认为，当前 EVM 的局限性是阻碍他们有效开发智能合约的三大主要挑战之一。 我们的受访者提到的 EVM 的四个主要局限性如下：
对调试的支持有限、缺乏对传统语言的支持、字节码执行效率低下、栈大小有限。
5.4.2 对 EVM 最理想的改进
接下来，我们要确定 EVM 最可取的改进，社区应该更加关注这些改进。 我们的调查列出了从最初的访谈中得出的 EVM 的一些令人希望的改进。根据调查结果发现，对调试的更好支持是最需要的（65.5%的调查对象选择了这种改进），其次是字节码的执行速度的改进（31.9%）。26.7%的受访者希望能够支持其他编程语言。有趣的是，虽然我们的许多受访者一开始希望 EVM 放松堆栈大小限制，但在调查中只有 27.6%的受访者希望这样做。对 EVM 目前提供的功能感到满意的受访者仅占总票数的 12.5%。
5.5 Gas一些受访者提到，智能合约开发与传统软件开发的一个显著区别在于 gas 机制。gas 机制是智能合约开发所特有的，执行智能合约需要花费 gas，用户需要支付 gas 费。因此，开发人员在开发智能合约时需要特别注意用 gas 容量问题。一些受访者也提到了他们在处理 gas 问题时遇到的困难。一方面是特别注意 gas 消耗，像以太坊这样的平台使用 gas 机制来控制智能合约的执行。另外一个是处理 gas 问题的困难，在不损害代码可读性的情况下优化 gas 通常是一个棘手的问题。
5.7 调查结果
表 5 列出了受访者在 4.1 至 4.6 小节中提到的 28 个挑战和需要改进的地方。C1 到 C6 是整个智能合约开发的六大挑战。C7 到 C17 是开发人员在智能合约开发的不同阶段（如编码、测试、调试）所面临的挑战。I18 到 I28 分别代表了对可靠性和 EVM 的期望改进。表 5 的最后一列是投票支持相应挑战或期望改进的应答者的数目（比率）。对于挑战或改进（前 3 位），该值表示有多少受访者将其列为前 3 位挑战或期望改进之一。例如，232 名受访者中有 166 名（71.6%）将 C1 列为智能合约开发中的前 3 大挑战之一（六分之一）。
表 5. 28 个挑战和期望的改进(受访者提到)和调查投票结果
整体投票结果的个人挑战或需要改进 4.1 到 4.6 节中提到的，这里我们在此主要集中于分析针对这 28 个挑战和期望改进的不同人群的投票结果（请参阅第 3.2 节，我们遵循的方法）。
投票结果在不同的人口群体中有所不同。例如 C2 组 scExpM 和 scExpL 的比值分别为 57.9%和 58.1%，而 scExpH 组 scExpM 和 scExpL 的比值仅为 34.4%。以 C3 为例，Dev、Test 和 PM 的比值分别为 38.4%、83.3%和 47.6%。为了检验观察到的比率差异是否具有统计学意义，对于每一个挑战/期望的改进，我们在五组人口统计学组中应用了 Fisher 精确检验和 Bonferroni 校正，即不同角色的组（Dev vs. Test vs. PM），在通用软件开发方面有不同经验的小组（seExpH vs. seExpM vs. seExpL），在智能合约开发方面有不同经验的小组（scExpH vs. scExpM vs. scExpL），有不同教育程度的小组（Adv vs. nAdv），以及在不同类型的区块链工作的小组（pubBlk vs. nPubBlk vs. bothBlk）。
5.8 结果总结通过对访谈和调查数据的分析，我们可以发现：
1.
智能合约对代码安全性要求很高。然而，开发人员目前没有有效的方法来确保代码安全性；一些工具，如代码审核和正式的验证技术是非常需要的。目前，开发人员主要使用测试和代码审查来帮助确保代码的正确性。
2.
现有的调试工具原始且效率低下的，这使得调试在实践中非常痛苦。 迫切需要功能更强大的交互式调试器，该调试器可以提供有用的错误消息。
3.
Solidity 语言的不良特征（例如，难以将数据传递给外部函数、变量数量的限制）、编译器（由于快速变化的编译器及其看不见的缺陷而导致的向后兼容性和可靠性问题）和 EVM（例如，无信息的错误消息、有限的堆栈大小、
4.
单线程 EVM 导致的低效执行），使得在实践中有效和高效地编写智能合约非常具有挑战性。
5.
需要考虑代码可读性的源代码级 gas 估计和优化工具。
6.
缺乏最佳实践、代码示例、社区支持、第三方库、以及智能合约开发的标准。
6、未来发展方向6.1 智能合约的安全性和可靠性开发人员认为安全性对智能合约至关重要。过去的报告强调了大量影响智能合约安全性的漏洞，例如，可重入漏洞等。由于许多从事智能合约开发的开发人员是该领域的新手，他们可能没有意识到这些漏洞。智能合约中也存在很多代码重复；复制-粘贴是一种常见的开发方法。通过复制粘贴，易受攻击的代码很容易感染其他代码。因此，需要工具支持来帮助开发人员不仅检测而且修复漏洞，以防止它们进一步扩散。
6.2 影响智能合约发展的其他因素除了安全性之外，还有许多其他因素还会影响智能合约的开发。在这里，我们强调了智能合约开发的五个不同方面，它们提出了需要该领域进展的开放研究问题。
6.2.1 编程语言与虚拟机的设计
Solidity 和以太坊 VM 还处于起步阶段，由于它们的局限性（例如类型检查、内存管理、多线程支持等），开发人员在开发智能合约时经常会遇到困难。这凸显了研究在 Solidity 和以太坊 VM 中添加额外功能的机会。现有提出的研究解决方案往往存在权衡或引入可能阻碍其采用的额外复杂性；需要进一步研究以开发其他解决方案，这些解决方案可以考虑其他折衷办法，以帮助以太坊 VM 和 Solidity 语言设计人员/维护人员确定社区应采取的最有希望的方法或方向。另一个可能的方向是使开发人员能够使用他们选择的语言（或该语言的受限子集）进行编码，并将其代码转换为 Solidity。最近的研究已经探索了将 Java 转换为 c#的方法。还可以开发一些解决方案，将用 Javascript（它有一个庞大的开发人员基础，并且类似于 Solidity）等语言编写的代码转换为 Solidity 代码。
6.2.2 更好的资源管理
智能合约开发人员需要在受堆栈大小、局部变量数量等限制的情况下优化 gas 和效率。这使得开发人员更难专注于设计出色的新功能。手工优化这些注意事项也会带来其他问题（例如，可读性）。因此，需要新的支持来帮助开发人员在考虑各种约束条件的情况下优化 gas。当前的解决方案只提供字节码的估计，但是开发人员可能需要对源代码的支持，并且开发人员可能还需要关于优化代码方法的建议。
6.2.3 函数库建设
开发人员非常需要函数库。部署的智能契约的代码冗余程度很高，这表明开发人员经常重新发明代码框架。这并不奇怪，因为现代软件通常构建在函数库之上。例如，函数库可以包含超过 90%的 web 应用程序。需要一些工具来识别许多智能合约中使用的可重用公共组件，并将它们组织成易于查找和使用的类、方法和库。
6.2.4 智能合约的演变、维护和部署
正如一位开发人员所提到的，一旦部署了智能合约，就不可能对其进行修改。有一些变通方法可以解决合同的演变（对用户的难度和影响程度各不相同），例如使用 detegatecall（即，将智能合约的数据和逻辑分离到单独的合约中，并让数据合约通过 delegatecall 调用逻辑合约），或者使用注册表合同来存储合同的最新版本，等等。然而，目前还没有对不同维修方案的优缺点进行系统研究的论文。
7、结论和未来工作智能合约最初指的是法律合约的自动化，最近由于区块链技术的兴起，人们对它产生了浓厚的兴趣。如今，它被广泛用于指运行在区块链上的底层代码脚本。在本研究中，我们调查了开发人员在开发此类智能合约时所面临的挑战，特别是在以太坊平台上。我们的访谈和调查结果表明，智能合约开发仍处于起步阶段：没有普遍接受的方式来保护智能合约代码；现有的开发工具链不够强大；开发和运行时平台（例如，编程语言，虚拟机）仍然有很多限制；在线学习资源和社区支持有限。基于我们的发现，我们总结了一些研究人员和实践者在未来可以采取的具体和可操作的方向（例如，自动化智能合约补丁、solidsolidcompiler 测试、源代码级 gas 优化、自动化 Solidity 库构建等）。这些方向的进展将进一步促进智能合约的发展。
8、致谢本文由南京大学软件学院 2021 级硕士石孟雨翻译转述。
