以太坊智能合约的规范编码

区块链的特征之一是不变性。也就是说事务和状态是不可变的。这意味着，一旦部署到链上，智能合约就无法更改。由于多种原因而导致的需求延迟更改可能会产生一系列后果，这与硬件设计类似。当然，也有一些缓解措施，比如重新部署，但也有一些问题(比如合约地址的变更会耗费时间、燃料甚至名誉，因此会产生错误的解决方案)。目前对智能合约的普遍关注是通过审计预防安全性和 bug, 但未来在实现改进之后关注点可能会被人们忽略。

有时很难预测未来的业务需求和变化。此外，构建通用的或可升级的智能合约可能很棘手，但这并不意味着计划应该以草率的方式完成。尽管如此，智能合约的开发通常适合进行团队开发，在这种开发中，用户故事应该被分解成任务并以适当的方式进行规划。综上所述，很明显，计划过程和智能合约审计一样重要。规划过程的输出应该是某种书面上的规范，同时这可以作为开发的输入，也可以作为未来使用和集成的指导。

不管团队的总体开发过程是什么，每个智能契约开发过程都应该有几个步骤，大致如下:

1.需求收集和计划——包括从多个来源收集输入事实，同时注意需求的可追溯性

2.规范编写——这是一种非标准化的技术指定收集的需求

3.编码——编写符合指定需求的程序代码

4.测试——手动测试自动单元的功能，通常智能合约的代码覆盖率为90%。

5.审核——首先在内部审核代码，然后在所有前提条件下提交外部安全审核

6.部署流程——“推进生产”的手动或自动流程

当智能合约以适当的方式完成时，它可以适合敏捷的迭代或增量。或者可以以增量的方式进行，看起来就像水流落下一样通畅。它的缺点是，测试应该在整个过程中就全部完成，因为智能合约是安全关键。所以，V和W的模型很合适。无论如何，它通常取决于团队的偏好或项目管理决策。

以一种不仅对开发有帮助，而且对以后的任务也有帮助的方式编写规范是至关重要的。有几个方面需要考虑。首先，安全性是一个高级需求，它可以归结为对已知攻击的测试和维护安全的编码原则。这包括对不同用户的访问限制

可以从最初的需求中识别的角色。UML用例图可以用于此目的，其中角色很容易被识别。如果存在多个RBAC模型，则可以用访问控制矩阵表示RBAC模型。稍后，在开发过程中，可以归结为编写函数访问修饰符。

有时需要部署多个依赖的合约来完成指定的需求。如果复杂性更高，其他的选项是UML通信图和N2图表。但是，智能合约不是一个孤立的岛。它与正在构建的产品的其他部分有连接和交互。其中一些只是读取状态，另一些可以执行事务。然而，DApp通常使用ABI作为合约的接口。对于通信序列，UML序列图是最好的解决方案。如果合约中涉及的各方更多，数据流程图也是一种选择。此外，部署前和部署后的维护操作应该在规范中进行预见和编写。

编码风格通常是开发人员抉择的，但是实现干净的代码应该始终是一种高级追求。Antoine DE Saint-Exupery 曾经说过:“完美的实现不是没有什么可添加的，而是没有什么可带走的。”在编写代码时，应该始终强调这一原则。它意味着对模式的需求和使用有清晰的理解。此外，有必要考虑智能合约的通话性能，这可以归结为天然气成本最小化。

综上所述，智能合约与标准编码有一定的区别。它们应该是简单和直接的，所以在实际开发它们之前，适当的计划至关重要。作为第一步，应该进行适当需求收集和分析，以便以令人满意的方式编写规范。然后, 充分的编码原则会产生高质量的代码, 作为测试和审核阶段的输入。最后，部署过程是最后一步，走到这一步就没有回头的选择了。因此，确保以最佳方式进行规划和审计至关重要。