4. MPC工程环境搭建

MPC协议实现与普通应用开发最大的区别在于：它同时依赖密码学原语、网络通信和多方协同计算。一个能在单机上跑通的协议，放到真实网络里可能因为延迟、丢包或并发调度而性能骤降。因此，工程环境搭建的目标不是“装好编译器”，而是构建一个可复现、可观测、可对比的开发闭环：工具链保证代码能编译和链接密码学库，网络模拟器保证能控制通信条件，基准测试框架保证性能数据可比较，代码仓库初始化保证多人协作时依赖和构建方式一致。

开发工具链：从编译器到密码学依赖

MPC工程通常使用C++或Rust作为主语言，因为需要精细控制内存和性能。以C++为例，推荐使用CMake作为构建系统，编译器选择GCC 11+或Clang 14+，并开启C++17标准。密码学依赖方面，常见组合包括：OpenSSL用于AES、SHA等对称原语，GMP或NTL用于大整数运算，RELIC或MCL用于椭圆曲线配对，libOTe或emp-toolkit用于不经意传输和混淆电路。这些库的版本必须锁定，否则不同机器上编译出的协议行为可能不一致。

一个可复现的工具链配置应包含以下要素：

• 编译器与标准库：g++ 11.4.0，-std=c++17 -O2 -march=native，开启-Wall -Wextra。
• 构建系统：CMake 3.22+，使用FetchContent或ExternalProject管理第三方依赖，避免手动下载。
• 密码学库：OpenSSL 3.0.x、GMP 6.2.1、libOTe（固定commit hash），通过CMake的find_package或自定义Find模块引入。
• 调试与性能工具：gdb、valgrind、perf、heaptrack，用于定位内存泄漏和热点函数。

下面是一个最小CMakeLists.txt示例，展示如何引入OpenSSL和GMP：

cmake_minimum_required(VERSION 3.22)
project(mpc_env LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_FLAGS_RELEASE "-O2 -march=native")

find_package(OpenSSL 3.0 REQUIRED)
find_package(GMP REQUIRED)

add_executable(ot_demo src/ot_demo.cpp)
target_link_libraries(ot_demo PRIVATE OpenSSL::Crypto GMP::GMP)

编译时使用cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j，确保所有依赖都能被正确找到。如果某个库找不到，优先检查CMAKE_PREFIX_PATH是否指向了自定义安装路径。

网络模拟器：控制延迟、带宽与丢包

MPC协议对网络条件非常敏感。半诚实协议在局域网内可能达到毫秒级，但在跨地域广域网中，由于多轮交互，总耗时可能放大数十倍。因此，开发阶段就需要一个可控的网络模拟环境。常用工具是Linux的tc（traffic control）配合netem模块，可以在回环或虚拟网卡上注入延迟、带宽限制和丢包。

例如，模拟两个参与方之间50ms延迟、100Mbps带宽、0.1%丢包的环境：

# 在参与方A的网卡eth0上添加延迟和丢包
sudo tc qdisc add dev eth0 root netem delay 50ms loss 0.1% rate 100mbit

# 查看当前规则
tc qdisc show dev eth0

# 清除规则
sudo tc qdisc del dev eth0 root

更复杂的场景可以使用Mininet创建虚拟网络拓扑，为每个参与方分配独立IP和链路参数。Mininet的优势在于可以模拟多跳路由和不对称带宽，更接近真实部署。对于需要精确控制时钟同步的协议，还可以结合chrony或PTP模拟时钟偏移。

网络模拟的关键是记录每次实验的网络参数，否则性能数据无法解释。建议在基准测试输出中附带延迟、带宽、丢包率三个字段。

基准测试框架：让性能数据可比较

MPC工程的基准测试不能只测“总耗时”，因为总耗时受网络轮次、计算复杂度和数据规模共同影响。一个实用的基准框架应至少记录以下指标：

• 协议轮次（rounds）：交互次数，直接决定网络延迟的放大倍数。
• 通信量（communication）：发送和接收的字节数，反映带宽压力。
• 计算时间（compute time）：纯CPU时间，排除网络等待。
• 端到端时间（wall-clock time）：实际耗时，用于用户体验评估。
• 参数配置：参与方数量、输入位宽、安全参数（如128-bit）、协议变体（半诚实/恶意）。

推荐使用Google Benchmark或自定义计时器。对于多参与方协议，需要确保各参与方的时间测量是同步的。一个简单做法是：所有参与方在开始前通过NTP对齐时钟，或者由协调方发送开始信号，各参与方记录相对时间。

下面是一个基准测试结果示例（数据为合理假设，非实测）：

从表中可以看出，恶意协议由于需要额外的承诺和校验，轮次和通信量都显著增加。基准测试的价值在于：当优化代码后，可以明确知道是计算时间下降了，还是通信量减少了，从而判断优化是否有效。

代码仓库初始化：目录结构与依赖锁定

MPC项目通常包含协议实现、密码学原语、网络层、测试和基准测试等多个模块。一个清晰的目录结构能显著降低协作成本。推荐如下布局：

mpc-project/
├── CMakeLists.txt
├── cmake/                  # 自定义Find模块
├── third_party/            # 第三方依赖（git submodule或FetchContent）
├── src/
│   ├── crypto/             # 密码学原语封装
│   ├── network/            # 网络通信与序列化
│   ├── protocol/           # MPC协议实现
│   └── utils/              # 日志、计时、配置解析
├── test/                   # 单元测试
├── benchmark/              # 基准测试
├── scripts/                # 网络模拟、环境检查脚本
└── docs/                   # 协议说明与实验记录

依赖锁定方面，建议使用git submodule管理libOTe、RELIC等库，并在README中明确记录每个submodule的commit hash。如果使用FetchContent，则在CMake中指定GIT_TAG为具体commit，而不是分支名。此外，应提供scripts/setup_env.sh，自动安装系统包（如build-essential、cmake、libssl-dev、libgmp-dev）并初始化submodule。

环境验证：从编译到一次完整交互

环境搭建完成后，需要一次端到端的验证。可以编写一个最小的两方OT协议：参与方A输入两个128位消息，参与方B输入选择位，双方执行OT后B只得到其中一个消息。验证步骤包括：编译通过、单元测试通过、在tc模拟的50ms延迟下运行、基准测试输出轮次和通信量。如果B得到正确消息且A不知道B的选择位，则环境基本可用。

下图展示了MPC工程环境各组件之间的依赖与数据流关系：工具链提供编译和密码学原语，网络模拟器控制通信条件，基准测试框架采集性能数据，代码仓库统一管理依赖和构建脚本，最终通过一次OT交互验证整个环境是否闭环。

环境搭建不是一次性任务。随着协议迭代，可能需要新增密码学库、调整网络模拟参数或扩展基准测试指标。因此，代码仓库中的scripts/目录应持续维护，确保新成员能通过一条命令完成环境初始化。建议在CI中定期运行一次完整的环境验证，包括编译、单元测试和基准测试，防止依赖更新导致构建失败。

最后，记录每次实验的环境快照：编译器版本、库版本、网络参数、CPU型号。这些信息在复现性能结果时至关重要。一个简单的做法是在基准测试输出中自动附加uname -a、g++ --version和tc qdisc show的结果，保存为JSON或CSV，与性能数据一起归档。