Coq 认证计划的定义

我看到了几个不同的研究小组，至少有一本书，讨论了使用Coq设计认证项目。对于认证项目的定义是否有共识？据我所知，它真正意味着程序被证明是完整的，并且类型正确。现在，程序的类型可能真的很奇特，比如一个列表，它证明它是非空的，排序的，所有元素>=5，等等。然而，最终，一个认证的程序是否仅仅是Coq显示的一个完整的和类型安全的程序，其中所有有趣的问题归结为最终类型中包含的内容

---

编辑1 根据wjedynak的回答，我看了Xavier Leroy的论文“真实编译器的形式验证”，这篇论文链接在下面的答案中。我认为这包含了一些很好的信息，但我认为在这一系列研究中，更多信息可以在Sandrine Blazy和Xavier Leroy的论文中找到。这是“正式验证”论文中添加优化的语言。在这本书中，Blazy和Leroy介绍了Clight语言的语法和语义，然后在第5节讨论了这些语义的验证。在第5节中，有一个用于验证编译器的不同策略的列表，从某种意义上讲，它提供了创建认证程序的不同策略的概述。这些是：

手工审查

语义性质的证明

经核实的翻译

测试可执行语义

交替语义等价

在任何情况下，可能有一些要点可以补充，我当然希望听到更多

回到我最初的问题，什么是认证项目的定义，我仍然有点不清楚。Wjedynak提供了一个答案，但实际上Leroy的工作涉及在Coq中创建一个编译器，然后在某种意义上验证它。从理论上讲，这使得现在证明C程序的事情成为可能，因为我们现在可以进行C->Coq->PROFICE。从这个意义上说，似乎有这样的工作流程，我们可以

用X语言编写一个程序

Coq或其他证明辅助工具中步骤1中程序模型的形式。这可能涉及在Coq中创建编程语言模型，也可能涉及直接创建程序模型（即在Coq中重写程序本身）

证明模型的一些性质。也许这是一个关于价值观的证明。也许这是语句等价性的证明（比如3=1+2或f（x，y）=f（y，x），等等）

然后，根据这些证明，将原始程序称为已认证

或者，我们可以在证明助手工具中创建程序的规范，然后证明规范的属性，但不能证明程序本身

---

在任何情况下，如果有人有其他定义，我仍然对它们感兴趣。

我同意这个概念似乎很模糊，但在我的理解中，认证程序是一个配备了正确性证明的程序。现在，通过使用丰富且富有表现力的类型签名，您可以使其不需要单独的证明，但这通常只是一个方便的问题。真正的问题是我们所说的正确性是什么意思：这是一个规范问题。你可以看看例如Xavier Leroy

首先要注意的是，“认证”一词有点法国化的倾向：在其他地方经常使用“已验证”或“已证明”一词

在任何情况下，重要的是要问这到底意味着什么。Leroy和CompCert是一个很好的起点：这是一个关于C编译器验证的大项目，Leroy总是热衷于向他的听众解释为什么验证很重要。尤其是与来自“认证机构”的人交谈时，他们通常指的是测试，而不是证明

---

另一个大型验证项目是使用Isabelle/HOL的。本部分解释了实际陈述和证明的内容，以及后果。不幸的是，实际证明是绝密的，因此不能公开检查。

这可能意味着没有运行时错误（数字溢出、无效引用…），这与大多数开发的软件相比已经很好了，但仍然很弱。根据领域形式化证明另一个含义是正确的；也就是说，它不仅要在形式上没有运行时错误，还必须证明它能完成预期的任务（必须精确定义）。

我的理解是，在这个意义上，“认证”是法语国家选择的一个英语单词，而母语为法语的国家可能会使用“正式验证”。Coq是在法国开发的，拥有许多法语开发者和用户

至于“正式验证”的含义，维基百科（许可证：）表示：

是证明。。。使用数学的形式化方法，针对某一形式规范或属性，系统底层预期算法的正确性

（我知道你想要一个比这个更精确的定义。如果我找到答案，我希望在将来更新这个答案。）

维基百科特别指出了验证和确认之间的区别：

• 验证：“我们是否在尝试做出正确的产品？”，即产品是否符合用户的实际需求
• 验证：“我们生产了我们想要生产的产品吗？”，即，产品是否符合规范要求

论文（Klein等人，2009年）证实了这一解释：

愤世嫉俗者可能会说，实现证明只表明 实现的bug与规范中的bug完全相同 包含。这是事实：证据不能保证 规范描述了用户期望的行为。这个 差异[在已验证的ap中]