智能合约的审计报告有什么内容？又该如何去审读

一个数字货币、去中心化应用或服务（DAPP）和所有的商品一样都有它的用户，因此用户对它也有一个最基本、最底线的要求----那就是质量要过关。和传统商品一样，数字货币、DAPP的质量如何不能自说自话，还需要用户或第三方机构对其进行检测。但和普通商品不同的是，这个商品一旦被用了，发现质量不行退货都没用，因为它可能已经对用户造成了经济上的损失。所以在区块链领域，对DAPP质量的检测就必须交给第三方审计机构在产品正式上线前先严格把关。而这个严格把关的检测过程最后所形成的结果就是我们常说的智能合约的审计报告。一份智能合约的审计报告对审计机构来说相当于一本书的读后感，这本“书”是一套智能合约的源代码；而对读者尤其是合约的使用者来说又相当于一份“质量检测报告”。审计报告的这种双重角色决定了它的作用就像是用户和DAPP之间的一个桥梁，这个桥梁的制造者就是审计公司。这个桥造得好不好一方面决定了用户能不能很好、很准确地把握这个DAPP的质量，放心地使用它；另一方面也决定了这个DAPP能不能走向更广大的用户，达到它的理想市场状况。所以一份审计报告一定要极尽所能的客观公正，如实反映审计机构看到的合约的真实“质量”，并罗列出所有的问题。审计公司除了要把被审计合约的“读后感”完整、真实地展现出来，还要想想怎么能让读者尤其是绝大多数非专业领域的读者更容易地读懂这份报告、很准确地把握这份报告的精髓和精华。所以一份审计报告还要尽可能地让读者读得懂、抓到重点、读到精华。既然一份报告既要客观公正、准确详实，又要通俗易懂、清晰明了，所以我们在写一份审计报告时采取了提纲挈领、层层展开的方式。所谓的提纲挈领就是用最简单最概括性的语言把读者最关注的重点和痛点首先写出来，让读者直接从这部分内容看到整篇报告最重要、最精华的部分。所谓的层层展开就是让读者在读完这部分内容后，如果还想更进一步了解审计机构的审计详情以及被审计合约的详细细节则可以随着后续的章节一步步展开，进一步阅读，进一步深入。基于这个思路，我们对一份审计报告的内容布局就有了如下的安排：我们的审计报告通常包含12章内容。我们首先就会在第一章介绍所审计的合约文件，包括文件名、文件所能被公开查询、访问的位置、对文件内容的存证标识（这种标识保证了文件内容的唯一性）、审计机构的审计方式及流程、审计机构审计时所依赖的客观材料及这些材料的出处、本审计报告的责任声明、本次审计的最终结论（即被审计合约是否存在风险、风险的数量及等级）。对于绝大多数读者而言，当他只关注被审计合约的最终质量和风险评估时，他可以只看这一章内容，而略掉后续章节。这一章也可以说是我们审计报告的精华和重点。接下来的章节则主要就是对审计过程和更多审计细节的披露和展开。我们会在第二章介绍我们的公司、官网、背景、业务范围等。第三章介绍被审计项目的应用及服务。第四章介绍本审计报告所审计的合约的主要功能。第四章和第三章是相辅相成缺一不可的。对于第三章很多读者能够理解它的存在必要，但对第四章，有些读者不理解。实际上在我们所审计的一些项目中，存在这样的问题：项目方所开发的项目是个庞大的应用，它涉及诸多功能，而项目方给我们所审计的合约仅仅只是这诸多功能中的一个或几个。举个例子：通常一个去中心化交易所，它有通证交易的功能、提供流动性的功能、发行治理代币及分发治理代币的功能等。而则个交易所的项目方可能只给审计机构审查了提供流动性的功能和发行治理代币的的功能。所以第四章是对第三章的进一步说明和对审计范围的进一步细化。第五章介绍了审计机构在本次审计过程中具体做了什么工作。第六章介绍了审计机构在审计过程中可能涉及审查的风险种类。第七章介绍了审计机构对每一个罗列的风险进行的等级评定。这些等级通常分为：致命风险（这是必须要立刻解决的）、高危风险（这是必须尽快解决的）、中度风险（这是由于条件限制暂时无法立刻解决，但最终还是要解决的）和低风险（这是建议要解决的）。第八章介绍了审计机构在全面阅读了项目代码后根据项目的应用场景和功能特别关注的可能产生风险的领域和功能。第九章罗列了根据风险等级，每个等级中审计机构所发现的风险数量。第十章罗列了根据合约文件，每个文件中审计机构所发现的风险数量。第十一章是第十章的细化，在第十章的基础上对每个风险，详细描述了这个风险的名称、等级、产生的位置、风险描述、审计机构给出的修改建议以及项目方对此风险的回应（是否知晓，是否修改或是否有计划修改等）。第十二章是在第十一章的基础上对项目方的进一步建议。这一章所罗列的不是风险，也不是项目方必须修改的问题，而是为了让代码有更好的可维护性、可读性、可扩展性、抗风险性等特点审计机构额外提出的一些完善建议和质量提升建议。对此，项目方可采纳也可不采纳。至此，一份审计报告就完成了。