finish 2025-11-21 ppt
This commit is contained in:
508
2025-11-21/main.typ
Normal file
508
2025-11-21/main.typ
Normal file
@@ -0,0 +1,508 @@
|
||||
#import "@preview/typslides:1.3.0": *
|
||||
#import "@preview/codly:1.3.0": *
|
||||
#import "@preview/codly-languages:0.1.1": *
|
||||
#import "slides_component/figures.typ": *
|
||||
#show: codly-init.with()
|
||||
#codly(languages: codly-languages)
|
||||
#show raw: set text(font: ("0xProto Nerd Font", "WenQuanYi Micro Hei"))
|
||||
|
||||
// Project configuration
|
||||
#show: typslides.with(
|
||||
ratio: "16-9",
|
||||
theme: "yelly",
|
||||
font: ("0xProto Nerd Font","WenQuanYi Micro Hei"),
|
||||
font-size: 20pt,
|
||||
link-style: "color",
|
||||
show-progress: true,
|
||||
)
|
||||
|
||||
// The front slide is the first slide of your presentation
|
||||
#front-slide(
|
||||
title: "MPC的通信架构设计思路",
|
||||
authors: "梁俊勇",
|
||||
info: [2025-11-21],
|
||||
)
|
||||
|
||||
// Custom outline
|
||||
#table-of-contents()
|
||||
|
||||
#title-slide()[
|
||||
MPC通信常见问题
|
||||
]
|
||||
|
||||
#slide[
|
||||
在底层通信里，我们常常会遇到这样的场景: \
|
||||
一段代码需要重复调用send()或者recv()方法 \
|
||||
但是这里有较大的性能问题
|
||||
]
|
||||
|
||||
#slide(title: "场景1: 一方向另一方发送多个数据")[
|
||||
```python
|
||||
# 发送方
|
||||
for item in items:
|
||||
socket_to_peer.send(item)
|
||||
```
|
||||
|
||||
```python
|
||||
# 接收方
|
||||
for i in len(items):
|
||||
items[i] = socket_to_peer.recv()
|
||||
```
|
||||
]
|
||||
|
||||
#slide(title: "场景2: 一方向多方发送数据")[
|
||||
```python
|
||||
# 发送方
|
||||
for peer in peers:
|
||||
socket_to_peer.send(data)
|
||||
```
|
||||
|
||||
```python
|
||||
# 接收方
|
||||
for peer in peers:
|
||||
data = socket_to_peer.recv()
|
||||
```
|
||||
]
|
||||
|
||||
#slide(title: "问题1: 通信中的数据依赖问题")[
|
||||
这其中的问题在于，每次发送与接受，都会存在数据的依赖关系。具体表现为：
|
||||
- 阻塞式操作: 同步编程中，`send()` 和 `recv()` 是阻塞的，程序会暂停执行，直到当前通信操作完全完成。
|
||||
- 严格串行: 在循环中，后一次的通信操作（无论是发送还是接收）必须等待前一次操作彻底完成后才能启动。
|
||||
- 性能瓶颈: 这种强制性的顺序等待，极大地限制了通信效率，尤其是在需要与多个参与方进行大量数据交换的场景下，导致系统无法充分利用并行处理能力和网络带宽。
|
||||
]
|
||||
|
||||
#slide(title: "以场景2为例")[
|
||||
```python
|
||||
# 手动展开发送方循环代码
|
||||
# peers = [alice, bob, carol]
|
||||
# for peer in peers:
|
||||
# socket_to_peer.send(data)
|
||||
|
||||
socket_to_alice.send(data)
|
||||
socket_to_bob.send(data) # 在alice没有确认收到数据前，此行代码不会执行
|
||||
socket_to_carol.send(data) # 在bob没有确认收到数据前，此行代码不会执行
|
||||
```
|
||||
]
|
||||
|
||||
#slide(title: "以场景2为例")[
|
||||
```python
|
||||
# 手动展开接收方循环代码
|
||||
# peers = [alice, bob, carol]
|
||||
# for peer in peers:
|
||||
# socket_to_peer.recv(data)
|
||||
|
||||
socket_to_alice.recv(data)
|
||||
socket_to_bob.recv(data) # 在没有接收到alice数据前，此行代码不会执行
|
||||
socket_to_carol.recv(data) # 在没有接收到bob数据前，此行代码不会执行
|
||||
```
|
||||
]
|
||||
|
||||
#slide(title: "流程图表示")[
|
||||
#align(center)[#show: serial_timeline()]
|
||||
]
|
||||
|
||||
#slide(title: "问题2: 传统通信协议的瓶颈")[
|
||||
我们常用的 `TCP` 和 `HTTP/1.1` 协议虽然可靠，但在大规模、高并发的MPC场景下会遇到显著的性能瓶颈：
|
||||
|
||||
- 连接开销大:
|
||||
- TCP三次握手: 每次新建连接都需握手，带来固有延迟。
|
||||
- TCP慢启动: 连接初期传输速度受限，短连接无法有效利用带宽。
|
||||
|
||||
- 协议效率低:
|
||||
- HTTP/1.1队头阻塞: 单个慢请求会阻塞同一连接上的后续所有请求。
|
||||
- 冗余的报文头: HTTP头部是文本格式，存在大量冗余信息。
|
||||
|
||||
- 数据传输未经优化:
|
||||
- 默认无压缩: 协议本身不强制压缩数据，增大了网络负载。
|
||||
- 序列化开销: 使用JSON等文本格式比二进制格式体积更大，处理速度更慢。
|
||||
]
|
||||
|
||||
#title-slide[
|
||||
预备知识
|
||||
]
|
||||
|
||||
#slide()[
|
||||
在我们讲解后续思路与方案之前，我们先来了解一下异步编程。
|
||||
]
|
||||
|
||||
#slide(title: "异步编程")[
|
||||
异步编程是实现并发的一种主要方式。
|
||||
|
||||
我们可以用在餐厅点餐的例子来理解：
|
||||
|
||||
- 同步（等待的方式）：
|
||||
你在柜台点完餐，然后就站在那里一直等到餐做好。中间什么也做不了。
|
||||
|
||||
- 异步（不等待的方式）：
|
||||
你在柜台点完餐，服务员给你一个震动的取餐器。你可以回到座位上玩手机、聊天。当取餐器震动时，你再去取餐。
|
||||
|
||||
在程序中：
|
||||
- “点餐”就是发起一个网络请求。
|
||||
- “取餐器”就是一种通知机制。
|
||||
- “玩手机”就是程序在等待期间可以去执行的其他代码。
|
||||
]
|
||||
|
||||
#slide(title: "并发与异步的关系")[
|
||||
简单来说，它们是“目标”与“手段”的关系。
|
||||
|
||||
- 并发是我们的目标：
|
||||
- 我们希望程序能同时处理多个任务，提高效率。
|
||||
|
||||
- 异步编程是达成目标的手段之一：
|
||||
- 它是我们编写并发程序的一种具体方法。
|
||||
|
||||
好比我们的目标是“同时做好一顿饭（炒菜、煮饭、煲汤）”。
|
||||
|
||||
- 多线程方案：
|
||||
- 请三个厨师，每人负责一项。速度快，但“雇佣成本”高，且需要协调。
|
||||
|
||||
- 异步方案：
|
||||
- 一位经验丰富的厨师，他先按下电饭煲和汤煲的开关（发起异步操作），然后在等待的间隙去炒菜。通过合理安排，一个人高效地完成了所有事情。
|
||||
]
|
||||
|
||||
#slide(title: "为什么不选择多线程方案")[
|
||||
尽管多线程也能实现并发，但在网络编程中，它常常带来一些挑战：
|
||||
|
||||
- 数据竞争与复杂性：
|
||||
- 当多个线程同时尝试修改同一份数据时，很容易出现混乱，导致程序出错。
|
||||
- 就像多个人同时在同一块白板上写字，最终结果可能一团糟。
|
||||
- 为了避免这种混乱，程序员需要使用复杂的“锁”机制来协调，这非常容易出错，并且难以调试。
|
||||
|
||||
- 特定语言的限制：
|
||||
- 像Python这样的语言，由于其内部机制（全局解释器锁GIL），即使使用多线程，也无法真正同时运行多个计算任务，这限制了其在CPU密集型场景的性能。
|
||||
- 即使是C/C++这类语言，虽然没有GIL，但手动管理线程间的同步和数据安全，也是一个巨大的挑战。
|
||||
]
|
||||
|
||||
#slide(title: "为什么不选择多线程方案")[
|
||||
- 逻辑直观性：
|
||||
- 即使是像Rust这样能保证线程安全的语言，多线程的逻辑也可能不如异步编程模型（特别是async/await）那样直观和易于理解，尤其是在处理大量网络I/O时。
|
||||
|
||||
因此，在许多网络设计场景中，异步编程往往是更简洁、高效且易于维护的选择。
|
||||
]
|
||||
|
||||
#title-slide[
|
||||
通过有向无环图(DAG)实现通信批次化
|
||||
]
|
||||
|
||||
#slide()[
|
||||
我们可以将数据依赖转换成图问题，进而使用拓扑排序来批次化无依赖关系的数据。\
|
||||
例如刚刚的循环发送。我们可以创建一个缓冲区，将数据先填充至缓冲区，然后在一轮循环结束的时候，统一发送。\
|
||||
接收方同理，创建缓冲区，通过循环解包出对应的数据。\
|
||||
]
|
||||
|
||||
#slide(title: "手动批次化示例")[
|
||||
```python
|
||||
# 手动批次化发送方代码
|
||||
# items = [item1, item2, item3]
|
||||
# for item in items:
|
||||
# socket_to_peer.send(item)
|
||||
|
||||
buffer = []
|
||||
for item in items:
|
||||
buffer.append(item)
|
||||
socket_to_peer.send(buffer)
|
||||
```
|
||||
]
|
||||
#slide(title: "批量化流程图表示")[
|
||||
#align(center)[#show: batched_timeline()]
|
||||
]
|
||||
|
||||
#slide()[
|
||||
然后是并发化，如果多个步骤可以并行进行，那么拓扑排序也可以将这些步骤一起发送处理。\
|
||||
例如刚刚的发送给多个参与方的模式。我们便可使用一次并发，在等待确认的时候，发送其他数据。
|
||||
]
|
||||
|
||||
#slide(title: "并发化示例")[
|
||||
```python
|
||||
# peers = [socket_to_alice, socket_to_bob, socket_to_carol]
|
||||
|
||||
# 创建一组并发的发送任务
|
||||
tasks = [
|
||||
socket_to_peer.send(data) for peer in peers
|
||||
]
|
||||
|
||||
# 同时执行所有发送任务
|
||||
await asyncio.gather(*tasks)
|
||||
```
|
||||
]
|
||||
|
||||
#slide(title: "并发流程图表示")[
|
||||
#align(center)[#show: async_timeline()]
|
||||
]
|
||||
|
||||
#slide(title: "动态DAG方案")[
|
||||
主流的动态DAG框架是阿里的隐语框架 @Ma2023。
|
||||
#align(center)[#image("./pics/secretflow.png")]
|
||||
此方案的核心思想是：
|
||||
- 运行时构建：计算图（DAG）不是预先生成的，而是在程序执行过程中动态构建。这允许更灵活的编程，例如，计算的流程可以根据秘密计算的中间结果发生改变。
|
||||
- 通用语言：开发者使用 Python 来编写MPC逻辑。
|
||||
- 分布式框架：底层依赖一个强大的分布式执行框架（Ray @moritz2018raydistributedframeworkemerging）来调度和执行图中的计算任务。
|
||||
]
|
||||
|
||||
#slide()[
|
||||
优点：
|
||||
- 灵活性高，易于上手，可以处理具有复杂、数据依赖控制流的算法。
|
||||
- 中文社区，有问题回复较及时。
|
||||
缺点：
|
||||
- 运行时动态调度和框架自身的开销较大(如传输的是整个Python对象)，性能不如静态方案。
|
||||
- 框架组件多，使用起来复杂度高。
|
||||
]
|
||||
|
||||
#slide(title: "静态DAG方案")[
|
||||
主流的静态DAG框架是 MP-SPDZ @mp-spdz。其工作流程完全不同：
|
||||
- 编译时构建：开发者使用一种专门为MPC设计的领域特定语言（DSL）编写协议。
|
||||
- 提前优化：编译器将DSL代码转换成一个固定的、静态的计算图，并进行大量优化（如指令调度、通信批处理）。最终生成高效的字节码。
|
||||
- 虚拟机解释：项目使用C++实现了一个虚拟机，在运行时加载并执行这些预先编译好的字节码。由于所有依赖关系都已确定，执行过程非常高效。
|
||||
]
|
||||
|
||||
#slide()[
|
||||
优点：
|
||||
- 性能极高。由于在编译时就掌握了全部计算信息，可以进行全局优化，运行时开销非常小。
|
||||
缺点：
|
||||
- 灵活性差。计算流程必须在编译前完全确定，很难实现依赖于秘密数据的动态分支。
|
||||
- 需要学习相应的DSL。
|
||||
]
|
||||
|
||||
#title-slide[
|
||||
选择快速的通信协议
|
||||
]
|
||||
|
||||
#slide[
|
||||
传统方案是使用同步TCP来实现。但是这个方案因为TCP的握手和同步阻塞问题，性能上比较差。\
|
||||
对此，我们有多种优化方案。
|
||||
]
|
||||
|
||||
#slide(title: "TCP长链接")[
|
||||
非常简单的一个方式就是使用TCP长连接。这个方案需要额外维护一个连接列表。可以解决频繁建立TCP连接的握手开销。
|
||||
]
|
||||
|
||||
#slide(title: "TCP长链接代码示例")[
|
||||
核心思路是实现一个 `ConnectionManager`，它内部持有一个 `HashMap` 作为连接池。当需要通信时，我们向管理器请求一个连接。
|
||||
- 如果连接已存在，管理器直接返回它。
|
||||
- 如果不存在，管理器负责建立新连接，存入池中，然后返回。
|
||||
|
||||
这样，无论上层逻辑是发送还是接收，都无需关心连接是否已经建立。
|
||||
|
||||
```rust
|
||||
use std::collections::HashMap;
|
||||
use std::net::{TcpStream, ToSocketAddrs};
|
||||
use std::io::{self, Write};
|
||||
|
||||
struct ConnectionManager {
|
||||
connections: HashMap<String, TcpStream>,
|
||||
}
|
||||
|
||||
impl ConnectionManager {
|
||||
// 获取或建立一个新连接
|
||||
// 这个函数体现了“维护链接”：调用者只管要连接，不用管是否已存在
|
||||
fn get_connection<A: ToSocketAddrs + ToString>(
|
||||
&mut self, addr: A
|
||||
) -> io::Result<&mut TcpStream> {
|
||||
let addr_string = addr.to_string();
|
||||
|
||||
// .entry().or_insert_with() 是更地道的写法，这里为了清晰而展开
|
||||
if !self.connections.contains_key(&addr_string) {
|
||||
let stream = TcpStream::connect(addr)?;
|
||||
self.connections.insert(addr_string.clone(), stream);
|
||||
}
|
||||
|
||||
Ok(self.connections.get_mut(&addr_string).unwrap())
|
||||
}
|
||||
}
|
||||
```
|
||||
]
|
||||
|
||||
#slide(title: "WebSocket：全双工通信")[
|
||||
WebSocket 是另一种在TCP之上，但比原始TCP更现代化的协议。它特别适合需要频繁、实时双向通信的场景。
|
||||
|
||||
- 单次握手: WebSocket通过一个类似HTTP的请求发起握手，一旦成功，连接就升级为WebSocket连接，后续通信不再需要HTTP的开销。
|
||||
- 全双工通信: 连接建立后，客户端和服务器可以随时互相发送消息，实现了真正的双向通信，延迟极低。
|
||||
- 轻量级: 相比HTTP，WebSocket的消息帧头非常小，减少了网络开销。
|
||||
|
||||
对于需要参与方之间进行大量实时交互的MPC协议，WebSocket是一个比传统TCP长连接或HTTP轮询更高效的选择。
|
||||
]
|
||||
|
||||
#slide(title: "序列化：数据的高效编码")[
|
||||
序列化是将内存中的数据结构（如对象、结构体）转换为可以存储或传输的格式（如字节流）的过程。在MPC中，我们需要在网络间传输大量数据，因此序列化的效率至关重要。
|
||||
|
||||
- 文本格式 (如 JSON):
|
||||
- 优点: 人类可读，易于调试。
|
||||
- 缺点: 体积庞大，解析速度慢，对于性能敏感的MPC通信是巨大的瓶颈。
|
||||
|
||||
- 二进制格式 (如 Protobuf, Bincode):
|
||||
- 优点: 极其紧凑，解析速度飞快，是高性能场景的首选。
|
||||
- 缺点: 人类不可读。
|
||||
|
||||
在Rust生态中，`serde` 框架配合 `bincode` 库是实现高效二进制序列化的黄金搭档。
|
||||
]
|
||||
|
||||
#slide(title: "序列化代码示例 (Rust)")[
|
||||
通过 `serde`，我们只需在结构体上添加一个派生宏，就能轻松实现序列化和反序列化。
|
||||
```rust
|
||||
use serde::{Serialize, Deserialize};
|
||||
|
||||
// 1. 使用serde的宏来自动实现序列化/反序列化
|
||||
#[derive(Serialize, Deserialize, PartialEq, Debug)]
|
||||
struct MyData {
|
||||
id: u32,
|
||||
payload: String,
|
||||
}
|
||||
|
||||
fn main() {
|
||||
let original = MyData {
|
||||
id: 101,
|
||||
payload: "hello".to_string(),
|
||||
};
|
||||
|
||||
// 2. 使用bincode将结构体序列化为字节
|
||||
let serialized_bytes: Vec<u8> = bincode::serialize(&original).unwrap();
|
||||
println!("Serialized: {:?}", &serialized_bytes);
|
||||
|
||||
// 3. 从字节反序列化回结构体
|
||||
let deserialized: MyData = bincode::deserialize(&serialized_bytes).unwrap();
|
||||
println!("Deserialized: {:?}", &deserialized);
|
||||
|
||||
assert_eq!(original, deserialized);
|
||||
}
|
||||
```
|
||||
]
|
||||
|
||||
#slide(title: "流式压缩")[
|
||||
在序列化之后，我们可以通过一些压缩算法来降低传输的数据量，从而减少网络传输时间和带宽消耗。流式压缩特别适用于MPC中需要传输大量中间计算结果的场景。
|
||||
|
||||
优点：
|
||||
- 减少数据量: 直接降低网络传输的数据大小，加快传输速度。
|
||||
- 降低带宽需求: 对于带宽受限的环境尤其重要。
|
||||
- 实时性: 流式压缩/解压缩可以在数据传输的同时进行，不会引入额外的显著延迟。
|
||||
|
||||
常用算法：
|
||||
- Zlib/Deflate: 广泛使用的通用压缩算法，兼顾压缩比和速度。
|
||||
- Snappy: Google开发，以极快的压缩和解压缩速度著称，但压缩比略低于Zlib，适用于对速度要求更高的场景。
|
||||
- LZ4: 另一种非常快速的无损压缩算法，解压缩速度尤其快。
|
||||
|
||||
在选择压缩算法时，需要根据具体的MPC协议和网络环境，权衡压缩比、压缩/解压缩速度以及CPU开销。
|
||||
]
|
||||
|
||||
#slide(title: "gRPC协议")[
|
||||
gRPC 是由 Google 开发的一个现代、高性能的RPC（远程过程调用）框架，它能很好地解决我们之前提到的一些通信瓶颈。
|
||||
|
||||
- 基于 HTTP/2：
|
||||
- gRPC 使用 HTTP/2 作为其传输协议，天然支持多路复用。这意味着可以在单个TCP连接上同时处理多个请求和响应，彻底解决了队头阻塞问题，也实现了长连接复用。
|
||||
|
||||
- 高效的 Protobuf：
|
||||
- 默认使用 Protocol Buffers (Protobuf) 进行序列化。相比于 JSON，Protobuf 是二进制格式，体积更小、解析更快。
|
||||
|
||||
- 支持流式通信：
|
||||
- 除了常规的“请求-响应”模式，gRPC 还原生支持客户端流、服务端流和双向流。这对于需要连续交换大量数据的MPC场景非常有用。
|
||||
]
|
||||
|
||||
#slide(title: "QUIC协议")[
|
||||
QUIC 是一个更前沿的传输层协议，它被用作 HTTP/3 的基础。它的设计目标是彻底解决TCP的固有顽疾。
|
||||
|
||||
- 构建于 UDP 之上：
|
||||
- QUIC 抛弃了 TCP，选择在更底层的 UDP 上重新实现了可靠传输、拥塞控制等功能。
|
||||
|
||||
- 解决了真正的队头阻塞：
|
||||
- HTTP/2 在单个TCP连接上多路复用，但如果一个TCP数据包丢失，整个连接上的所有流都必须等待它重传。这是传输层的队头阻塞。
|
||||
- QUIC 将“流”作为一等公民。每个流的数据包被独立处理，一个流的丢包不会阻塞其他流。
|
||||
|
||||
]
|
||||
|
||||
#slide(title: "QUIC协议")[
|
||||
|
||||
- 更快的连接建立：
|
||||
- QUIC 将传输层的握手（类似TCP三次握手）和加密握手（TLS）合并了。对于已有连接，它甚至可以实现 0-RTT（零往返时间）的连接恢复，速度极快。
|
||||
]
|
||||
|
||||
#slide(title: "协议对比")[
|
||||
为了更好地理解不同通信协议的优劣，我们来对比一下它们在MPC场景下的表现。
|
||||
|
||||
#block[
|
||||
#set text(size: 16pt)
|
||||
#table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: (center, left, left, left),
|
||||
// Header
|
||||
[特性], [传统TCP/HTTP/1.1], [gRPC (HTTP/2 over TCP)], [QUIC (HTTP/3 over UDP)],
|
||||
// Rows
|
||||
[传输层], [TCP], [TCP], [UDP],
|
||||
[队头阻塞], [应用层和传输层], [传输层 (TCP HOLB)], [无 (流独立)],
|
||||
[连接建立], [慢 (TCP 3次握手 + TLS)], [慢 (TCP 3次握手 + TLS)], [快 (0-RTT/1-RTT)],
|
||||
[多路复用], [无], [有 (应用层)], [有 (传输层)],
|
||||
[序列化], [通常文本 (如JSON)], [Protobuf (二进制)], [协议无关 (二进制)],
|
||||
[性能], [较低], [中高], [高],
|
||||
[适用场景], [简单请求/响应], [微服务/RPC], [实时通信/高并发]
|
||||
)
|
||||
]
|
||||
]
|
||||
|
||||
#slide(title: "异步TCP方案")[
|
||||
使用异步的发送可以让我们无须等待I/O。也就是说，我们在调用`send()`/`recv()`的时候，线程不会一直阻塞，而是会将CPU时间片交给其他任务。
|
||||
|
||||
异步编程有多种模型，最主流的是 `async/await` 方案。
|
||||
]
|
||||
|
||||
#slide(title: "async/await 方案的优劣")[
|
||||
优点：
|
||||
- 代码直观: 代码的线性逻辑使其看起来像同步代码，非常易于读写和维护。
|
||||
- 资源占用低: 基于无栈协程，单个任务内存开销极小，可以轻松创建海量并发，且上下文切换在用户态完成。
|
||||
- 统一的错误处理: 可以使用语言内建的错误处理机制（如Rust的 `?`），避免了回调地狱中的错误处理难题。
|
||||
|
||||
缺点：
|
||||
- 心智负担: 需要理解 `Future`、执行器等概念，并手动处理CPU密集型任务（放入线程池）。
|
||||
- 函数染色: `async` 关键字具有传染性，`async` 函数不能被同步代码直接调用，反之亦然，割裂了生态。
|
||||
]
|
||||
|
||||
#slide(title: "Rust中的异步实现对比")[
|
||||
在Rust生态中，同时存在Stackful和Stackless两种异步实现，代表了不同的设计哲学。
|
||||
|
||||
Stackful (`may` 框架):
|
||||
- `may` 提供了类似Go Goroutine的体验，每个协程拥有自己的栈。
|
||||
- 开发者可以像写普通同步代码一样进行编程，网络IO等操作会被框架自动调度，对用户透明。
|
||||
- 同样是“无色”函数，不强制区分同步和异步函数。
|
||||
|
||||
Stackless (`tokio` 框架):
|
||||
- 这是Rust官方和社区的主流方案，基于 `async/await` 语法。
|
||||
- 编译器将异步代码转化为状态机，内存占用极低。
|
||||
- 必须遵循 `async/await` 的语法规则，存在“有色”函数问题，但换来了更高的性能和更精细的控制。
|
||||
]
|
||||
|
||||
|
||||
#title-slide[
|
||||
设计异步化的通信流程
|
||||
]
|
||||
|
||||
#slide()[
|
||||
我们目前学习的方案大部分是同步的协议，即协议的数据几乎要依赖于上一步的状态或结果。
|
||||
Damgård @Dam2009 提出一个全异步的协议设计概念，即协议的正确性不依赖与消息是否在规定时间内到达。
|
||||
同时这篇文章提出#link("https://github.com/mgeisler/viff")[VIFF]框架（现已archive，且继任为MP-SPDZ）
|
||||
]
|
||||
|
||||
#slide()[
|
||||
近年来，还提出了一些新的方案。如hbMPC@hbMPC ，还有Dumbo-MPC@Dumbo-MPC。
|
||||
]
|
||||
|
||||
#title-slide()[
|
||||
总结
|
||||
]
|
||||
|
||||
#slide()[
|
||||
综合前面讨论的通信瓶颈、异步编程思想以及各种优化协议，我们可以勾勒出MPC中异步化通信流程的设计思路：
|
||||
|
||||
- 核心思想：非阻塞与并发
|
||||
- 充分利用异步编程模型，确保通信操作不会阻塞主计算线程，从而提高CPU利用率。
|
||||
|
||||
- 通信调度：DAG驱动
|
||||
- 将通信任务抽象为有向无环图（DAG），通过拓扑排序实现通信的批处理和并发执行，最大限度地减少等待时间。
|
||||
|
||||
- 协议选择：高效可靠
|
||||
- 优先选用基于HTTP/2 (如gRPC) 或 QUIC (如HTTP/3) 的协议，利用其多路复用、快速握手和高效序列化等特性。
|
||||
|
||||
- 连接管理：长连接与复用
|
||||
- 维护连接池，实现长连接的复用，避免频繁建立和关闭连接的开销。
|
||||
]
|
||||
|
||||
// Bibliography
|
||||
#let bib = bibliography("bibliography.bib")
|
||||
#bibliography-slide(bib)
|
||||
|
||||
Reference in New Issue
Block a user