FHEVM 原生模式（FHEVM-native）Executor 配置指南：线程池、调度策略与 `FHEVM_DF_SCHEDULE`

FHEVM 原生模式FHEVM-nativeExecutor 配置指南线程池、调度策略与FHEVM_DF_SCHEDULE【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevmFHEVM-native 是 fhEVM 项目中的一种部署形态链节点full node/validator node与独立运行的 Executor 服务分离FHE 计算被外包给 Executor 执行。本文基于coprocessor/docs/getting_started/fhevm/native/configuration.md展开讲解 Executor 的命令行与环境变量配置方式包括三大线程池模型、FHEVM_DF_SCHEDULE调度策略并结合fhevm-engine中调度器与 worker 的源码实现帮助你正确理解、调优并在 Helm 部署中落地这些配置。FHEVM-native 架构与配置现状在 FHEVM-native 模式下一个节点由两部分组成full node / validator node运行 EVM负责符号执行Symbolic ExecutionExecutor 服务一个 gRPC 服务器接收来自节点累积的 FHE 计算请求并执行它们。整体流程是区块执行期间EVM 只把 FHE 操作opcode、输入 handle、结果 handle累积在区块的计算列表中不做任何 FHE 计算区块结束时节点通过SyncCompute调用把计算列表发送给 ExecutorExecutor 完成 FHE 计算后通过SyncComputeResponse返回结果节点再把被SSTORE过的密文持久化上链。详细的架构与执行流程可参考 coprocessor/docs/fundamentals/fhevm/native/fhe_computation.md 与 coprocessor/docs/getting_started/fhevm/native/executor.md。需要特别说明的现状与官方文档一致截至本文撰写时FHEVM-native 尚未完全实现geth 集成即 full node/validator node 侧还没有完成详见 coprocessor/docs/getting_started/fhevm/native/geth.mdExecutor 几乎已完全可用但目前没有提供官方 Docker 镜像需要按普通 Rust 工程自行构建fhevm-engine工作区见 coprocessor/fhevm-engine/Cargo.toml因此Executor 的配置项会在其实现完成后逐步列出并生效本文所讲解的参数即当前已定义、随实现推进逐步可用的那部分。Executor 的命令行配置Executor 通过命令行开关command line switches与环境变量进行配置。查看全部参数直接运行executor --help Usage: executor [OPTIONS] Options: --tokio-threads TOKIO_THREADS [default: 4] --fhe-compute-threads FHE_COMPUTE_THREADS [default: 8] --policy-fhe-compute-threads POLICY_FHE_COMPUTE_THREADS [default: 8] --server-addr SERVER_ADDR [default: 127.0.0.1:50051] -h, --help Print help -V, --version各参数含义如下参数默认值作用--tokio-threads4tokio 异步线程池的线程数用于处理异步任务--fhe-compute-threads8FHE 计算线程池的线程数默认调度策略下实际执行 FHE 计算的线程--policy-fhe-compute-threads8策略 FHE 计算线程池的线程数使用非默认调度策略时生效--server-addr127.0.0.1:50051gRPC 服务监听地址节点通过该地址向 Executor 发起SyncCompute请求从实现结构看fhevm-engine工作区内的计算组件如 tfhe-worker使用 clap 解析同样的长参数命名风格。例如 coprocessor/fhevm-engine/tfhe-worker/src/daemon_cli.rs 中同样定义了--tokio-threads默认4注释为 Tokio Async IO threads并且有名为chart_documents_every_cli_flag_and_default的单元测试强制要求 Helm chartcharts/coprocessor/values.yaml记录每一个 CLI flag 及其编译期默认值任何增删改都会导致构建失败——这说明CLI 参数 默认值是这些计算组件的权威配置入口文档中的--help输出与源码定义保持一致。三大线程池模型tokio、FHE compute 与 policy FHE computeExecutor 内部维护三个相互独立的线程池理解它们的职责是正确调优的前提1. tokio 线程池--tokio-threads用于承载异步任务如 gRPC 请求处理、I/O 等待。官方文档特别强调这些线程不应被阻塞。FHE 计算是 CPU/GPU 密集型的阻塞工作如果放在 tokio 线程上执行会拖垮整个异步事件循环导致节点请求无法被及时响应。因此它通常保持较小规模默认4即可满足多数场景。2. FHE compute 线程池--fhe-compute-threads在默认调度策略下真正执行 FHE 计算的就是这些线程默认8。FHE 计算彼此独立时可以并行执行详见下文调度策略这个值决定了单个 Executor 实例上并行执行同态运算的规模。调大该值通常能提升吞吐但需要以机器物理核数与内存带宽为上限。3. policy FHE compute 线程池--policy-fhe-compute-threads只有当使用非默认调度策略时才会启用这一池线程来执行 FHE 计算默认8。也就是说调度策略由FHEVM_DF_SCHEDULE决定会决定实际计算负载落到--fhe-compute-threads还是--policy-fhe-compute-threads。调优提示如果机器是多核/超线程架构通常将 tokio 线程保持为小值、把 FHE 计算线程设为接近物理核数的值若不确定调度策略先保持默认策略再对--fhe-compute-threads做基准扫描。注意这些默认值与 coprocessor 模式tfhe-worker不同例如 charts/coprocessor/values.yaml 中记录的 tfhe-worker--coprocessor-fhe-threads32、--tokio-threads4说明不同组件/模式下线程规模需要独立评估不能照搬。调度策略FHEVM_DF_SCHEDULE环境变量Executor 可以从SyncCompute请求中提取出 FHE 运算之间的数据依赖关系handle 级依赖从而把相互独立的计算并行执行。调度策略通过环境变量FHEVM_DF_SCHEDULE设置可选值为LOOP、FINE_GRAIN、MAX_PARALLELISM、MAX_LOCALITY。使用方法# 以最大并行度策略启动 FHEVM_DF_SCHEDULEMAX_PARALLELISM executor # 以最大局部性策略启动 FHEVM_DF_SCHEDULEMAX_LOCALITY executor源码中的实际处理逻辑调度器的核心实现在 coprocessor/fhevm-engine/scheduler/src/dfg/scheduler.rsScheduler::schedule约第 152–185 行读取FHEVM_DF_SCHEDULE环境变量命中MAX_PARALLELISM时调用schedule_coarse_grain(PartitionStrategy::MaxParallelism)命中MAX_LOCALITY时调用schedule_coarse_grain(PartitionStrategy::MaxLocality)遇到任何未识别的取值会记录error级日志 Scheduling strategy does not exist并回退到默认策略MAX_PARALLELISM日志同时注明这是总体性能最佳的默认策略当环境变量未设置时Err(_)分支CPU 与 GPU 构建均直接使用PartitionStrategy::MaxParallelism作为默认。从源码结构看当前PartitionStrategy枚举只定义了MaxParallelism与MaxLocality两种分区策略见 scheduler.rs 第 77–80 行文档中列出的LOOP与FINE_GRAIN在当前调度器代码中没有对应的分支实现——可以推断它们是文档中保留的候选/历史策略名实际运行时会落入未识别取值分支并回退到MAX_PARALLELISM。在实验这两种策略前应先在目标版本源码中确认其是否已被实现。作为佐证tfhe-worker 的基准测试工具 coprocessor/fhevm-engine/tfhe-worker/benches/utils.rs约第 1581–1584 行在读取FHEVM_DF_SCHEDULE时同样以MAX_PARALLELISM作为兜底默认值进一步印证了未配置即最大并行度这一默认行为。策略取舍MAX_PARALLELISM默认推荐以并行度优先的方式对 FHE 计算图做粗粒度分区coarse-grain partitioning尽量把无依赖的运算分到不同线程并行执行是当前实现中标注为总体性能最佳的默认策略MAX_LOCALITY以数据局部性优先的方式分区适合对缓存友好性更敏感、或依赖链较长且共享输入密文较多的计算场景吞吐特征与MAX_PARALLELISM不同建议用基准实测对比LOOP/FINE_GRAIN文档保留的候选策略名当前调度器源码中尚未看到对应实现分支。在 Helm 部署中落地这些配置FHEVM-native 的 Executor 目前尚未提供容器镜像但同一套CLI flag 环境变量的配置约定在 coprocessor 模式的 Helm chart 中已有成熟落地方式可作为参考范式charts/coprocessor/values.yaml 的tfheWorker.extraArgs区块完整记录了每个 CLI flag 及编译期默认值如--tokio-threads4、--coprocessor-fhe-threads32、--worker-polling-interval-ms1000等并附有两条重要约定--flagvalue表示带值参数--flag表示纯开关参数clap 会拒绝--flagfalse的写法开关只能通过列出/省略来控制如需关闭默认开启的开关则通过其环境变量该区块与daemon_cli.rs中的Args由测试强制保持同步保证 chart 是部署者可依赖的权威参数清单。环境变量类配置如FHEVM_DF_SCHEDULE、TFHE_WORKER_MAX_BATCH_TTL_SECS、FHEVM_GPU_STREAMS_PER_DEVICE等则通过 Deployment 的env注入例如 charts/coprocessor/templates/coprocessor-tfhe-worker-deployment.yaml。这意味着即使未来 FHEVM-native Executor 提供容器化部署其--tokio-threads、--fhe-compute-threads、--policy-fhe-compute-threads、--server-addr以及FHEVM_DF_SCHEDULE均会以同样的方式暴露给运维侧。总结FHEVM-native 模式下 Executor 的配置体系可以归纳为线程模型tokio异步、不可阻塞、FHE compute默认策略下的计算线程、policy FHE compute非默认策略下的计算线程三个池分别由--tokio-threads、--fhe-compute-threads、--policy-fhe-compute-threads控制默认分别为 4/8/8服务入口--server-addr控制 gRPC 监听地址默认127.0.0.1:50051供节点在区块结束时调用SyncCompute调度策略FHEVM_DF_SCHEDULE环境变量支持LOOP、FINE_GRAIN、MAX_PARALLELISM、MAX_LOCALITY四个名义选项但当前 scheduler.rs 仅实现并默认采用MAX_PARALLELISMMAX_LOCALITY可选未识别值会回退到默认并打 error 日志部署落地参考 charts/coprocessor/values.yaml 的extraArgs区块约定与源码中的同步测试确保参数与默认值始终可查、可依赖。最后提醒由于 geth 集成尚未完成上述 Executor 参数目前更多是面向实现中的预留配置在官方宣布 FHEVM-native 完整可用之前生产环境请优先采用文档 coprocessor/docs/getting_started/fhevm/coprocessor/configuration.md 所描述的 coprocessor 模式。【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考