想象你要在城市中心建一座玻璃图书馆。施工队可以在交付前请上百个壮汉,穿着铁靴在每一块地板上反复跺脚——这是“测试”。踩过的地方确实没塌,但没人踩过的那条角落里的梁呢?某天一阵风来,它可能就断了。形式化验证换了一种思路:请一位结构审计师,把墙、梁、地基全部翻译成数学图纸,再按力学公理一步步推导,证明所有可预见的荷载组合都不会让楼塌。软件世界也一样,函数、模块、系统就是墙和梁;Hoare 逻辑、模型检测、定理证明,就是三种写“数学安全证明”的方式。本文会带你认识它们,并看看如何让它们从论文走进真实的工程流水线。

岗位关联

懂得形式化验证,等于掌握高可靠软件的最后一道防线:你不再用“踩过多少块地板”来证明安全,而是用数学告诉所有人“每一块地板都安全”。

目录
  1. 可视化演示
  2. 1. 为何需要验证:从“踩地板”到“算受力”
  3. 2. Hoare 逻辑:给程序写施工合同
  4. 3. 模型检测:让安检员走遍每个房间
  5. 4. 定理证明:用公理画出承重证明
  6. 5. 可扩展性:当房间数量爆发式增长
  7. 6. 工具集成:把验证装进工程流水线
  8. 7. 方法对比:三种审计方式怎么选
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示深入理解软件形式化验证的核心机制,通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

深入理解软件形式化验证:软件形式 软件形式化验证的基本概念与价值 Hoare逻辑与程序推理方法 核心机制可视化 深入理解软件形式化验证整体架构与关键组件

1. 为何需要验证:从“踩地板”到“算受力”

玻璃图书馆交付前,施工方请来一支测试队,每人穿铁靴反复踩地板。这就是测试:踩过的地板证明安全,没踩过的未必。弱电井里一条无人踩过的支梁,可能在某天凌晨悄悄折断。对航空、医疗、金融系统来说,一次“没踩过”的路径就可能是灾难。

形式化验证把问题从“找几个场景试试”换成“对全部合法输入做推理”。验证员先写出前置条件 Pre,比如“楼高不超过 100 米”“输入必须是合法订单”;再写出程序必须满足的后置条件 Post,比如“屋顶位移小于 5 厘米”“返回的余额永远不小于零”。然后证明:只要 Pre 成立,执行程序 P 后 Post 一定成立。

这栋楼不再靠运气,而是靠数学图纸背书。测试依然有用,像现场踩踏验收;但形式化验证给出的是“全楼结构安全”的结论。两者的关系不是二选一,而是测试负责找眼前的问题,验证负责证明看不见的未来。

∀σ∈Σ: Pre(σ)⇒Post(P,σ)\forall \sigma \in \Sigma:\ \mathrm{Pre}(\sigma)\Rightarrow \mathrm{Post}(P,\sigma)
这是软件版的安全承诺书:所有符合入场条件的输入,都会得到符合出场要求的输出。
  1. 全称量词对状态集合里的每一个状态都成立,而不是抽查几个状态。
    ∀σ∈Σ\forall \sigma \in \Sigma
  2. 前置条件状态在进入程序前必须满足的条件,相当于进入工地的入场券。
    Pre(σ)\mathrm{Pre}(\sigma)
  3. 蕴含关系只要前置条件为真,就必然推出后面的结论。
    ⇒\Rightarrow
  4. 程序与后置条件程序 P 执行之后,结果状态必须满足 Post 这个验收标准。
    Post(P,σ)\mathrm{Post}(P,\sigma)

2. Hoare 逻辑:给程序写施工合同

如果把软件工程看作盖楼,Hoare 逻辑就是施工合同。开工前写明场地状态 P,中间写明施工方法 S,完工后写明验收状态 Q。记号 {P} S {Q} 读作:只要 P 成立,执行完 S 之后 Q 一定成立。这就像合同里写着“场地平整、材料齐备,按图纸施工后,墙体垂直度误差不超过 5 毫米”。

它的真正威力在于组合。整栋楼不会被一句话合同建完,而是被拆成一层层、一段段。Hoare 逻辑提供顺序、条件、循环等推理规则,把大型程序拆成一个个局部契约。验证循环时,我们还需要找到“循环不变量”——可以理解为每一层楼都永远保持的承重条件,比如“所有承重墙都立在轴线上”。

这里说的是“部分正确性”:它不保证 S 一定会终止;如果 S 永不结束,那么 Q 根本无处安放。要证明“总会结束”,还要额外做终止性证明。但即便如此,Hoare 逻辑已经像一张张合同把高楼从地基到屋顶串成了一条完整的合同链。

{P} S {Q}\{P\}\ S\ \{Q\}
三个花括号把程序夹在中间,像一份由“入场条件、施工动作、验收条件”组成的迷你合同。
  1. 前置条件花括号里的 P 描述程序运行前必须成立的事实,相当于甲方提供的场地状态。
    PP
  2. 程序片段中间的 S 是一段代码、一个函数或一条语句,相当于施工队的操作方法。
    SS
  3. 后置条件花括号里的 Q 描述程序运行后必须成立的事实,相当于监理的验收清单。
    QQ
  4. 三者的整体含义如果 P 在 S 执行前为真,那么 S 执行后 Q 一定为真。
    {P} S {Q}\{P\}\ S\ \{Q\}

3. 模型检测:让安检员走遍每个房间

如果说 Hoare 逻辑是审合同,模型检测就是拿着建筑竣工图,从大厅出发把每个房间都打开检查。计算机先把你写的程序转换成一个有限状态图:每个节点是一个房间,每个箭头是一条走廊,房间里的灯和锁就是变量取值。这个图描述了系统所有可能的行为。

然后验证员写下一句安全属性,比如“任何房间都不会同时出现燃气泄漏和门窗锁死”。模型检测器从所有初始状态出发,沿着走廊穷尽地搜索;只要找到一个坏房间,它就会带回一条从门口到坏房间的完整路线。这条路线的学名叫反例路径,它比“程序有错”四个字有价值得多,因为它直接告诉你错误的现场。

模型检测自动、直接、能找到反例,但它要求系统状态有限,而且状态一多就会遇到爆炸。它就像工地安检员:只要图纸准确,他会一间一间查到底,每一个可疑房间都会被他拖出来示众。

M,s⊨AG(¬deadlock)\mathcal{M}, s \models \mathrm{AG}(\lnot \mathrm{deadlock})
这句话的意思是:在这个状态模型 M 中,从状态 s 出发,所有可到达的状态都永远不会进入死锁。AG 中的 A 代表所有路径,G 代表“一直如此”。
  1. 模型数学对象 M 描述程序的有限状态图,相当于一份正式的竣工图。
    M\mathcal{M}
  2. 起始状态从状态 s 开始检查,m 表示模型的入口或初始位置。
    ss
  3. 满足关系符号 ⊨ 表示“在语义上成立”,属于数学上的“真的满足了”。
    ⊨\models
  4. 所有路径全局成立AG 是时态逻辑运算符,表示沿着所有路径、在所有时刻都成立。
    AG\mathrm{AG}
  5. 安全性质永远不发生死锁,也就是不会出现“门锁死、房间无法通行”。
    ¬deadlock\lnot \mathrm{deadlock}

4. 定理证明:用公理画出承重证明

如果模型检测是走遍房间,定理证明就是请一位数学家研究结构受力。它不枚举房间,而是把程序和规约都表达成数学命题,然后从公理和推理规则出发,逐步推导出“此楼安全”的完整证明。在 Coq、Isabelle 这类证明助手中,验证不是一个黑盒按钮,而是一段交互过程:人类负责找思路,机器负责核对每一步推导是否合法。

证明助手把“程序满足规约”编码成一种特殊的类型,而程序本身是这种类型的一个值。下面这条判断读作:在上下文 Γ 中,程序 e 具有“对所有满足前置条件的 x,运行 f(x) 的结果满足后置条件”的类型。

数学推导不需要打开每个房间;它通过公理和逻辑规则让整栋楼的安全变成一条定理。代价是证明工作量大,往往需要大量人工引导。为了省力,现在常用 SMT 求解器自动补步骤,甚至用 AI 猜不变量和引理,把工程师从重复劳动中解放出来。

Γ⊢e:∀x:S, Pre(x)→Post(f(x))\Gamma \vdash e : \forall x{:}S,\ \mathrm{Pre}(x) \to \mathrm{Post}(f(x))
这里的类型就是规格:程序 e 是一份“证明”,它证明了自己会把每一份合法输入变成合法输出。
  1. 上下文Γ 是公式前面的背景板,存放公理、变量声明和之前已经证明的引理。
    Γ\Gamma
  2. 可推导符号⊢ 表示后面的公式可以从前面的公理和上下文推导出来,相当于“可以开证明”。
    ⊢\vdash
  3. 程序即证明项e 既是被验证的程序,也是这条规格的证明证据,这体现了定理证明中“证明即程序”的思想。
    ee
  4. 全称类型对所有属于类型 S 的 x,程序都要保证前置条件蕴含后置条件。
    ∀x:S\forall x{:}S
  5. 函数规格箭头表达“如果输入满足前置条件,则输出满足后置条件”。
    Pre(x)→Post(f(x))\mathrm{Pre}(x) \to \mathrm{Post}(f(x))

5. 可扩展性:当房间数量爆发式增长

一个小公寓加一扇门,就有开和关两种状态。整栋楼每多一扇门,房间组合的数量就翻一倍。模型检测最怕的就是这种“状态爆炸”:门还是那些门,但房间已经多到不可能逐一打开。

假设程序里有 n 个布尔变量,所有可能的状态数就是 2 的 n 次方。n=30 时,状态数已经超过十亿;就算一秒钟查一百万个房间,也要查很久。所以形式化验证不能只会“硬扫”,还要学会给建筑做抽象和分区。

应对方法有声世界常见的抽象、对称约简,还有把整栋楼分成防火分区的组合式验证。抽象相当于把精确的楼层平面图换成比例沙盘:忽略不影响安全的小摆设,集中验证承重结构。这样,安检员不必真的走遍每一间房,而是证明同一批“结构相同的房间”只要代表房安全,整批就安全。

∣States∣=2n|\mathrm{States}| = 2^{n}
每增加一个布尔开关,状态就翻倍。这不是线性增长,而是指数爆炸,也是可扩展性问题的根源。
  1. 状态总数竖线表示集合的大小,这里指程序所有可能状态的数量。
    ∣States∣|\mathrm{States}|
  2. 等号连接状态数被完全由变量个数决定,等于 2 的 n 次方。
    ==
  3. 布尔变量个数n 表示程序中有多少个独立的布尔变量,比如 n 个开关。
    nn
  4. 指数表达式底数 2 表示每个开关只有两种取值;n 次方表示组合数翻倍增长。
    2n2^{n}

6. 工具集成:把验证装进工程流水线

形式化验证要真正产生价值,就要像把质检站搬进工地一样进入开发流程。每个模块在交付时都带一份契约:前置条件、后置条件和关键不变量,这相当于预制板的验收单。只要每块预制板都贴了验收单,整栋楼的安全就有了基础。

组合规则让模块契约可以拼成系统证明。下面的顺序组合规则说:如果第一段代码 C1 把 P 变成 Q,第二段 C2 再把 Q 变成 R,那么把两段代码串起来,就能直接从 P 证明到 R。这种规则的工程意义很大:验证不必总从零开始,而是可以在模块边界上做组合。

工程上,这套思路会被装进 CI 流水线:每次代码提交都自动跑验证脚本,像工地每天巡检一样发现问题。工具链负责把 C、Java 代码翻译成验证器输入;契约文档变成机器可读的接口规格;AI 模型则越来越常被用来生成不变量或证明脚本。安全不再是一个项目结束才补的验收单,而是每一块砖进入流水线时的默认工序。

{P} C1 {Q}{Q} C2 {R}{P} C1;C2 {R}\dfrac{\{P\}\ C_1\ \{Q\}\quad \{Q\}\ C_2\ \{R\}}{\{P\}\ C_1; C_2\ \{R\}}
分子是两个已验证的小合同,分母是它们合并后的总合同。只要小合同靠谱,总合同就自动成立。
  1. 第一条契约代码 C1 在 P 成立时执行,保证 Q 成立。
    {P} C1 {Q}\{P\}\ C_1\ \{Q\}
  2. 第二条契约代码 C2 在 Q 成立时执行,保证 R 成立。
    {Q} C2 {R}\quad \{Q\}\ C_2\ \{R\}
  3. 顺序组合分号表示先执行 C1,再执行 C2,像施工队先打地基再砌墙。
    C1;C2C_1; C_2
  4. 组合结论横线下方省略了中间状态 Q,直接得到从 P 到 R 的完整保证。
    {P} C1;C2 {R}\{P\}\ C_1; C_2\ \{R\}

7. 方法对比:三种审计方式怎么选

三种方法像三种执照不同的审计师:Hoare 逻辑是合同审计员,模型检测是全楼巡检测验员,定理证明是数学结构顾问。选谁不取决于谁更高级,而取决于你手头有多少时间、多少图纸、以及事故发生后的代价。

模型检测自动化程度高,但状态一多就容易爆炸;定理证明能处理无限状态、精度极高,但需要大量专家智慧和交互;Hoare 逻辑擅长模块化验证,适合嵌进持续集成,但写不变量本身也是一门手艺。它们不是互相替代,而是组合使用:先用模型检测找反例,再用定理证明攻克最关键模块,最后用 Hoare 契约管住接口。

选型建议并不复杂:需要绝对安全证明的,选定理证明;系统状态有限、希望快速自动化找漏洞的,选模型检测;团队迭代快、希望每个模块都能持续验证的,用 Hoare 契约加 CI。最终目标不是让验证取代测试,而是给最关键的那几层楼,焊上一份数学安全证书。

⊢φ  ⇒  ⊨φ\vdash \varphi \;\Rightarrow\; \models \varphi
这是验证的“可靠性”铁律:只要工具证明了一个命题,那么这个命题在真实语义中一定为真。它保证审计师不会乱开证明。
  1. 可证明左边的符号表示能从公理和规则推出命题 φ。
    ⊢φ\vdash \varphi
  2. 蕴含箭头表示“如果左边成立,右边必然成立”。
    ⇒\Rightarrow
  3. 语义真右边的符号表示在所有满足规约的解释中,φ 都成立。
    ⊨φ\models \varphi

AI 应用场景

智能合约安全审计

阶段:发布前安全验证阶段

解决的问题:传统审计主要靠人工读代码加测试用例,很难覆盖所有交易路径和金额组合。利用形式化验证中的模型检测和契约检查,可以把资金池合约转换成一个有限状态图,穷举所有可达状态,找出“余额不变量被破坏”“重入攻击”等缺陷。

具体案例:一支 DeFi 团队在部署借贷协议前,用模型检测器把“存款、提款、清算”建模为状态迁移,结果搜索到一条反例路径:用户可以在一次交易中重复调用提款函数,使池子余额变成负数。团队根据反例路径修复了漏洞,避免上线后的巨大损失。

航天与汽车嵌入式软件验证

阶段:需求层与代码层的联合验证

解决的问题:飞控、线控转向等系统状态极多,传统测试只能覆盖少数飞行剖面,无法证明“所有组合情况都安全”。模型检测可以把控制状态、传感器取值和驾驶员操作建模成有限状态机,遍历所有可达状态,寻找与安全属性冲突的状态。

具体案例:某汽车团队验证纯电动车电池管理系统的“过充保护”逻辑。他们把电池温度、电压、充电桩状态编码成状态图,模型检测器在几分钟内找出一条反例:低温脉冲充电时,保护模块会延迟 200 毫秒才切断电路,存在过充风险。

AI 辅助定理证明

阶段:证明脚本生成与回归验证

解决的问题:Coq、Isabelle 这类证明助手虽然严谨,但证明脚本编写门槛高、耗时长。AI 模型可以根据当前证明状态和上下文,自动生成下一步 tactic 或完整的循环不变量,把“写证明”从纯人工劳动变成“AI 生成 + 机器核对”。

具体案例:操作系统内核项目 seL4 的传统验证曾耗费数十人年。现在团队用大语言模型辅助生成引理和证明策略,再交给证明助手逐条检查,显著缩短了新模块的验证周期。AI 的每一句“猜测”都必须经过形式化验证,不能被当成真话。

Python 演示

python53 行
from collections import deque  def flip(state, i):    s = list(state)    s[i] = not s[i]    return tuple(s)  def model_check_with_path(size, start, is_bad):    transitions = {}    for code in range(1 << size):        state = tuple((code >> i) & 1 for i in range(size))        transitions[state] = [flip(state, i) for i in range(size)]     queue = deque([start])    parent = {start: None}     while queue:        state = queue.popleft()        if is_bad(state):            path = []            while state is not None:                path.append(state)                state = parent[state]            path.reverse()            return False, path        for nxt in transitions[state]:            if nxt not in parent:                parent[nxt] = state                queue.append(nxt)    return True, []  def main():    size = 3    start = (False, False, False)     def is_bad(s):        return s[0] and s[1]     ok, path = model_check_with_path(size, start, is_bad)    if ok:        print("All reachable states satisfy the safety property.")    else:        print("Counterexample found:")        for step, state in enumerate(path):            bits = "".join("1" if b else "0" for b in state)            print("  step %d: %s" % (step, bits))  if __name__ == "__main__":    main()
目的:用 BFS 实现一个微型模型检测器,在全部布尔状态上穷举搜索,并输出第一条违法反例路径。
  1. transitions[state] = [flip(state, i) for i in range(size)]为每个房间预生成全部走廊,即所有可能的状态转移。
  2. queue = deque([start])把大厅入口房间放进待检查队列,代表广度优先搜索的开始。
  3. parent = {start: None}记录每个房间是从哪个房间来的,最后才能重建完整反例路径。
  4. if is_bad(state):一见到坏房间就立刻停止,模型检测不需要走完全部状态也能给出结论。
  5. path.reverse()把从坏房间回溯到起点的路径倒过来,输出从入口到事故现场的路线。

常见误区

误区形式化验证和单元测试差不多,只不过多写一些断言,跑一遍就能证明程序没问题。

正解单元测试是采样,验证是穷尽推理。断言只能检查执行过的几条路径,形式化验证则对全部合法输入或全部可达状态做数学论证。就像踩地板证明不了没踩过的梁,断言也证明不了没执行到的分支。

为何常见:日常开发中最熟悉的是测试,看到验证工具也会输出“通过”,就容易把两者混为一谈。

误区模型检测器说“安全”,那程序就是绝对正确,可以直接上线。

正解模型检测的结论是针对“模型”和“性质”的。如果建模时漏掉一个状态,或安全属性写错了,结论就失去意义。就像审计师照着一张漏画了隔间的图纸查房,当然会发现不了藏起来的问题。

为何常见:验证通过的输出听起来绝对,人们容易忘记“模型不是代码”“性质不是需求”这两层抽象。

误区Coq、Isabelle 叫定理证明器,应该像编译器一样,把代码放进去,回车就输出安全证书。

正解定理证明更接近“交互式证明助手”。它负责核对每一行推理是否符合公理,但关键的引理、归纳策略、循环不变量通常需要人来设计。AI 可以把这件事变得更容易,但仍不是全自动魔法。

为何常见:自动 SMT 求解器太强大了,让初学者误以为所有证明都能一键完成,忽略了证明工程中真正的复杂度。

误区形式化验证只能在论文里教小学生程序用,工业项目预算和排期都不允许。

正解seL4 操作系统内核、CompCert 编译器、AWS 云基础设施都采用了形式化验证。通过组合验证、模块契约和 CI 集成,可以把验证范围收窄到最关键模块,让成本变得可控。审计师不用检查整栋楼的每颗螺丝,只查承重结构就够了。

为何常见:很多人看到的案例是教学玩具,没看到成熟工具链和工业落地路径,于是高估了成本、低估了价值。

误区既然有了数学证明,测试就是多余的,反正测试也证明不了没 bug。

正解验证证明的是“代码符合规格”,不是“规格符合真实需求”。需求理解错、建模错误、工具本身有 bug,都可能让验证结论失真。测试和验证是两条互补的防线:测试贴近真实环境,验证覆盖所有状态空间。

为何常见:把“验证通过”等同于“产品绝对安全”,是一种对抽象边界的不自觉夸大。

面试题

Q1. 形式化验证与单元测试最本质的区别是什么?

单选题 · easy

  • A.形式化验证需要的代码更少
  • B.形式化验证使用穷尽数学证明← 正确答案
  • C.形式化验证不需要编译器参与
  • D.形式化验证只负责检查性能

答案:B。单元测试是抽样检查,形式化验证是对全部状态或输入进行数学推理。前者像踩几块地板,后者像证明整栋楼每一根梁都能承重。

Q2. Hoare 三元组 {P} S {Q} 中的 Q 是?

单选题 · easy

  • A.程序运行前必须满足的输入条件
  • B.程序运行过程中产生的全部日志
  • C.程序执行后成立的结果保证条件← 正确答案
  • D.程序执行时操作系统调用栈信息

答案:C。Q 是后置条件,描述程序执行完成后必须成立的事实。P 才是前置条件;日志和调用栈都不是 Hoare 逻辑关心的验收条件。

Q3. 模型检测主要靠什么方式来确认安全属性?

单选题 · easy

  • A.随机抽取若干条执行路径做测试
  • B.审查代码风格与注释是否完整
  • C.穷尽遍历所有可达的系统状态← 正确答案
  • D.反复运行压力测试观察性能指标

答案:C。模型检测在有限状态图上做穷尽搜索。它的核心优势是完整覆盖所有可达状态,这正是它与随机测试的本质差异。

Q4. 状态爆炸问题最直接的成因是什么?

单选题 · mid

  • A.程序员写代码时注释写得过多
  • B.状态数量随变量数目指数增长← 正确答案
  • C.编译器优化时生成的选项过多
  • D.运行平台之间的切换频率过高

答案:B。每增加一个布尔变量,状态组合数就翻倍,呈现 2 的 n 次方增长。状态爆炸是模型检测可扩展性的主要敌人。

Q5. 下列哪些是缓解状态爆炸的常用手段?

多选题 · mid

  • A.使用抽象与对称归约缓解爆炸← 正确答案
  • B.采用有序二叉决策图压缩状态← 正确答案
  • C.把系统拆成模块做组合验证← 正确答案
  • D.靠增加测试用例数量覆盖错误

答案:ABC。抽象、对称归约、决策图和组合验证都能压缩搜索空间。增加测试用例属于测试策略,并不能证明所有状态,反而会让验证工作量不必要地上升。

Q6. 定理证明中的“证明项”指的是什么?

单选题 · mid

  • A.程序满足规约的数学证明证据← 正确答案
  • B.软件安装包制作过程中用的脚本
  • C.代码测试覆盖率统计结果报表
  • D.编译器自动生成的目标机器代码

答案:A。在基于 Curry-Howard 的证明助手中,证明项既是一段程序,也是规格的构造性证明。它不是安装脚本、覆盖率报表或目标代码。

Q7. 组合式验证的核心思想是什么?

单选题 · mid

  • A.先验证整体再向下层层分解
  • B.用随机数据穷举所有输入分支
  • C.单独验证每个模块契约再组合成整体← 正确答案
  • D.用性能测试代替正确性验证过程

答案:C。组合式验证强调在每个模块边界定义契约,先独立验证模块,再通过推理规则组合成系统证明。它不是先整体后细化,更不是用性能测试代替正确性验证。

Q8. 下面哪一项最接近形式化验证中的“可靠性”(soundness)?

单选题 · hard

  • A.凡是可证明的定理在语义上为真← 正确答案
  • B.凡是真命题都必定可以被证明
  • C.模型检测比定理证明效率更高
  • D.测试全部通过就说明绝对安全

答案:A。可靠性指“可证明 ⇒ 真”。B 描述的是完备性;C 与可靠性无关;D 是测试神话,不属于可靠性。

Q9. 关于模型检测中的抽象与反例,下列说法正确的是?

多选题 · hard

  • A.抽象建模可能产生假反例← 正确答案
  • B.假反例可以指导抽象细化← 正确答案
  • C.抽象结果必然等价于原系统
  • D.真实反例能帮助定位软件缺陷← 正确答案

答案:ABD。抽象可能丢掉信息,产生原系统里不存在的假反例;按段假反例可以细化抽象模型,真实反例则直接指向缺陷。抽象结果通常只是近似,不会与原系统完全等价。

Q10. 关于 assume-guarantee 组合验证,正确的是?

多选题 · extreme

  • A.模块需要写明假设与保证契约← 正确答案
  • B.验证环境需要考虑模块间交互← 正确答案
  • C.组合后可推出整体安全属性← 正确答案
  • D.模块之间接口无须任何契约

答案:ABC。assume-guarantee 的核心是每个模块写清楚“假设的环境”和“保证的契约”,并在组合时考虑互相干扰。只要假设与保证匹配,就能推出整体安全属性;没有接口契约则无法组合。