fhEVM Coprocessor Backend 深度解析架构、组件与部署配置【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevmfhEVM Coprocessor Backend 是 fhEVM 全同态加密FHE方案中负责链下实际 FHE 计算的核心服务它运行在 geth 全节点旁边通过事件监听、PostgreSQL 任务队列与 TFHE 工作线程把链上符号执行产生的 FHE 操作真正算出来。本文以 coprocessor_backend.md 为主线结合 fhevm-engine 的源码、数据库迁移脚本与配套文档完整讲解 Coprocessor Backend 的组件构成、进程模型、多租户机制、FHE 计算链路、命令行配置以及构建部署方法帮助你从知道有这个东西进阶到能独立搭建并调优一个 Coprocessor Backend。Coprocessor Backend 在 fhEVM 中的定位在 FHEVM-coprocessor 模型中区块执行被拆成两部分详见 FHE ComputationSymbolic Execution链上在 EVM 内的 FHEVMExecutor.sol 合约中完成。EVM 只累积一个区块内所有被请求的 FHE 操作及其输入 handle、结果 handle并把操作作为链上事件logs发出不需要真正的 FHE 密文。FHE Computation链下由 Coprocessor Backend 完成。它从链上事件中恢复计算请求执行真实的 FHE 计算并把结果密文写回数据库。因此Coprocessor Backend 必须与 geth 节点并排alongside运行一个节点只负责记账和发事件另一个负责把事件变成真正的密文运算。密文只有在解密decryption和重加密reencryption——即用户想要看到明文时——才必须真实存在这也是 FHE 计算可以延迟到区块提交之后的原因。Coprocessor Backend 的代码实现集中在 coprocessor/fhevm-engine 目录这是一个 Rust workspace从 Cargo.toml 可以看出它由host-listener、gw-listener、tfhe-worker、sns-worker、zkproof-worker、transaction-sender、consensus-detector、upgrade-controller等多个子 crate 组成。四个核心组件原文档将 Coprocessor Backend 归纳为以下四类组件下面逐一展开1. Listeners把事件传播到 DB 与 Gateway监听器负责链上 → 链下的数据搬运主要包括host-listener订阅主链host blockchain上的 FHE 操作事件、ACL 事件与解密事件。合约在符号执行阶段主动发出事件即符号执行轨迹host-listener 通过节点的 pubsub 功能订阅这些事件并把它们转换为数据库中的 TFHE 工作量参见 host-listener/README.md。gw-listener监听 GatewayGW侧的事件例如 InputVerification 合约的输入证明验证事件并把它们插入 DB 的verify_proofs表然后通过event_zkpok_new_work数据库通道通知 zkproof-worker 处理参见 gw-listener/README.md。sns-worker执行 Switch-and-Squash 计算从pbs_computations与ciphertexts表读取(handle, compressed_ct)对计算large_ct并回写ciphertexts表同时发出事件提示大密文已就绪参见 sns-worker/README.md。2. Server处理来自 Gateway 的输入写入与密文读取请求Server 侧处理两类请求输入插入请求input insertion requestsGateway 把用户提交的加密输入写入 Coprocessor 的 PostgreSQL DBFHE 密文读取请求ciphertext read requestsGateway 从 DB 读取 FHE 密文用于后续解密/重加密流程。在架构上Gateway 负责输入验证、解密、重加密以及主链验证者集合更新全部经由 KMS而密文的存取则落在 Coprocessor 上参见 architecture.md 中的组件关系图。3. PostgreSQL DB计算请求与 FHE 密文的存储DB 是 Coprocessor 内部的事实来源核心表定义在 20240722111257_coprocessor.sqlcomputations存储计算请求。字段包括tenant_id、output_handle、output_type、dependenciesBYTEA 数组第二个依赖可以是标量、fhe_operation、is_scalar、is_completed、is_error、error_message等主键为(tenant_id, output_handle)。ciphertexts存储 FHE 密文字段包括tenant_id、handle、ciphertext、ciphertext_version、ciphertext_type、input_blob_hash、input_blob_index等主键为(tenant_id, handle, ciphertext_version)。tenants租户表详见下文多租户章节记录每个租户的 API Key、chain_id、合约地址以及公私钥pks_key/sks_key。4. Worker读取计算请求、执行 FHE 计算、回写结果密文Worker 即tfhe-worker它周期性从computations表获取待计算任务读取输入密文执行 TFHE 计算再把结果密文写回ciphertexts表。它是整个 Coprocessor 中真正算 FHE的执行者其调度逻辑在 tfhe-worker/src/lib.rs 与 daemon_cli.rs 中实现。进程模型Server 与 Worker 可分离、可合一Coprocessor Backend 的 Server 和 Worker既可以作为两个独立进程运行也可以作为单一进程运行。无论哪种方式两者都通过数据库通信——Worker 不是由 Server 直接调用而是轮询/订阅数据库中的任务。这一设计带来的直接好处横向扩展可以同时启动多个 tfhe-worker 进程/副本并行消费任务Worker 通过--worker-id区分身份通过依赖链锁--dcid-ttl-sec等机制避免重复处理见 daemon_cli.rs。异步解耦FHE 计算可以发生在区块提交之后的任意时刻Server 无需等待计算完成即可响应 Gateway 的请求。端到端 FHE 计算链路结合 FHE Computation 中的时序图一次完整的 FHE 计算链路如下关键点host-listener 通过eth_subscribe等 pubsub 机制订阅事件把 FHE 操作写入 DBhost-listener 还支持 catchup 追赶模式--start-at-block、--end-at-block、--catchup-margin等参数见 host-listener/README.md。tfhe-worker 从 DB 读取输入密文、执行计算、写回结果密文并通过is_completed等标记任务状态。关于符号执行的更多细节参见 Symbolic Execution。并行执行依赖链dependence chain调度由于 Coprocessor 能从摄入的事件中提取数据依赖关系每个计算请求的dependencies字段指向其输入 handle它可以据此并行执行 FHE 计算。当前 Coprocessor 使用简单的调度策略把 FHE 计算分配到多个线程上执行更优的调度策略未来会引入并做成可配置项。在实现层面依赖关系以dependence_chain表与 DCIDdependence chain ID机制落地tfhe-worker 按依赖链获取任务、加锁--dcid-ttl-sec控制租约 TTL、分时间片处理--dcid-timeslice-sec还支持 fast/slow 双车道--dependent-ops-max-per-chain超限的链会被标记schedule_priority 1进入慢车道见 host-listener/README.md。数据可用性DA说明当前实现暂未接入 DA 层仍处于进行中状态Coprocessor 只把 FHE 密文写入本地 DB未来计划将 FHE 密文也写入 DA使任何人都可以通过检查 Coprocessor 发布到 DA 的结果来验证其行为参见 architecture.md。多租户Multi-tenancy机制Coprocessor Backend 支持多租户它可以为不同的主链host blockchains在不同的 FHE 密钥下执行 FHE 计算。从数据库迁移脚本可以看到租户的完整模型20240722111257_coprocessor.sqlCREATE TABLE IF NOT EXISTS tenants ( tenant_id SERIAL PRIMARY KEY, tenant_api_key UUID NOT NULL DEFAULT gen_random_uuid(), -- for EIP712 signatures chain_id INT NOT NULL, -- for EIP712 signatures verifying_contract_address TEXT NOT NULL, acl_contract_address TEXT NOT NULL, pks_key BYTEA NOT NULL, sks_key BYTEA NOT NULL, public_params BYTEA NOT NULL, -- for debugging, can be null cks_key BYTEA, -- admin api key is allowed to create more tenants with their keys is_admin BOOLEAN DEFAULT f );要点每个租户拥有独立的tenant_api_keyUUID、chain_id、验证合约/ACL 合约地址以及独立的公私钥对pks_key/sks_key这正是不同主链、不同 FHE 密钥的落点。computations、ciphertexts等表都以tenant_id作为主键的一部分保证不同租户的数据物理隔离。租户的插入与冒烟测试可以通过cli子命令完成cli insert-tenant向指定数据库插入租户cli smoke-test运行 Coprocessor 冒烟测试见 fhevm-engine/README.md 中的cli --help。Worker 端通过--tenant-key-cache-size源码中已改名为--key-cache-size默认 32见 daemon_cli.rs缓存多个租户的 FHE 密钥避免每个任务都重新加载密钥。命令行配置与运行参数完整帮助屏幕在配置文档 configuration.md 中可以通过--help得到如下帮助屏幕coprocessor --help Usage: coprocessor [OPTIONS] Options: --run-bg-worker Run the background worker --generate-fhe-keys Generate fhe keys and exit --work-items-batch-size WORK_ITEMS_BATCH_SIZE Work items batch size [default: 10] --tenant-key-cache-size TENANT_KEY_CACHE_SIZE Tenant key cache size [default: 32] --coprocessor-fhe-threads COPROCESSOR_FHE_THREADS Coprocessor FHE processing threads [default: 8] --tokio-threads TOKIO_THREADS Tokio Async IO threads [default: 4] --pg-pool-max-connections PG_POOL_MAX_CONNECTIONS Postgres pool max connections [default: 10] --metrics-addr METRICS_ADDR Prometheus metrics server address [default: 0.0.0.0:9100] --database-url DATABASE_URL Postgres database url. If unspecified DATABASE_URL environment variable is used --service-name SERVICE_NAME Coprocessor service name in OTLP traces [default: coprocessor] -h, --help Print help -V, --version Print version各参数含义如下参数默认值作用--run-bg-worker关闭以后台 worker 模式运行即同时充当 FHE 计算 Worker--generate-fhe-keys关闭生成 FHE 密钥后直接退出--work-items-batch-size10每次从 DB 批量获取的工作项数量--tenant-key-cache-size32租户 FHE 密钥缓存大小源码中该参数已改名为--key-cache-size--coprocessor-fhe-threads8文档FHE 计算线程数注意当前 daemon_cli.rs 中默认值已演进为 32具体以你所用版本的--help为准--tokio-threads4Tokio 异步 IO 线程数--pg-pool-max-connections10PostgreSQL 连接池最大连接数--metrics-addr0.0.0.0:9100Prometheus 指标服务监听地址--database-url环境变量DATABASE_URLPostgreSQL 连接串未指定时读取DATABASE_URL环境变量--service-namecoprocessorOTLP 追踪中的服务名线程模型两个线程池Coprocessor Backend 内部有两个线程池调优时务必区分tokio 线程池--tokio-threads负责异步任务DB 访问、网络 IO 等这些线程不应被阻塞FHE 计算线程池--coprocessor-fhe-threads真正执行 FHE 计算的线程属于 CPU 密集型。在实际部署中FHE 计算线程数应结合 CPU 核心数与并发负载来设置tokio 线程数则应与 IO 密集程度匹配过少会拖慢 DB 交互过多会增加上下文切换开销。RDS IAM 认证使用 AWS RDS/PostgreSQL IAM 数据库认证时DATABASE_URL不应包含密码例如postgresql://coprocessormy-db.cluster-xyz.eu-west-2.rds.amazonaws.com:5432/coprocessor设置DATABASE_IAM_AUTH_ENABLEDtrue运行时将从默认 provider chain 获取 AWS 凭据自动生成 15 分钟有效的 IAM token并在池化连接过期前自动刷新。同时设置DATABASE_IAM_REGION固定 token 签名的 AWS 区域与DATABASE_SSL_ROOT_CERT_PATH对 RDS 端点启用verify-fullTLS 所需的 CA 证书参见 configuration.md。构建、密钥生成与本地开发依赖按照 fhevm-engine/README.md 与 tfhe-worker/README.md构建与开发 Coprocessor 需要docker-compose本地起 PostgreSQLrust工具链sqlx-clicargo install sqlx-clianvil测试用Foundry 自带的本地以太坊节点安装二进制$ cd fhevm-engine/coprocessor $ cargo install --path .生成测试密钥$ cd fhevm-engine/fhevm-engine-common $ cargo run generate-keys密钥默认存放在fhevm-engine/fhevm-keys仓库中的 fhevm-keys 目录。本地开发流程按 tfhe-worker/README.md 的步骤# 1. 启动数据库 docker compose up -d # 2. 导出数据库 URL export DATABASE_URLpostgres://postgres:postgreslocalhost/coprocessor # 3. 创建数据库 sqlx db create # 4. 运行迁移 sqlx migrate run # 5. 运行首个可工作的冒烟测试重建数据库并应用 schema make recreate_db # 6. 启动后台 FHE worker cargo run -- --run-bg-worker --worker-polling-interval-ms 1000运行测试cargo testoperators_from_events默认使用完整类型矩阵如需更轻量的本地矩阵可设置TFHE_WORKER_EVENT_TYPE_MATRIXlocal。使用预生成 Docker 镜像Coprocessor Backend 节点既可以使用预生成的 Docker 镜像也可以按 fhevm-engine/README.md 中的说明自行构建。注意三个执行 FHE 工作的服务tfhe-worker、sns-worker、zkproof-worker还可以发布 GPU 镜像GPU 镜像按计算能力compute capability构建tag 形如...sns-worker:v0.15.0-cuda12.2-sm90部署时必须选择与硬件匹配的 tagsm_90镜像可运行在 H100 上、不能运行在 L40 上详见 fhevm-engine/README.md 的 GPU-enabled images 章节。周边微服务的补充配置Coprocessor 由多个微服务组成参见 fhevm-engine/README.md除核心的 tfhe-worker 外常用服务的关键参数如下host-listenerhost_listener --url ws://0.0.0.0:8545 \ --acl-contract-address ACL_CONTRACT_ADDRESS \ --tfhe-contract-address TFHE_CONTRACT_ADDRESS \ --database-url postgresql://postgres:postgreslocalhost:5432/coprocessor \ --start-at-block START_AT_BLOCK \ --catchup-margin 5 --catchup-paging 100 \ --reorg-maximum-duration-in-blocks 50 \ --catchup-finalization-in-blocks 20其中--start-at-block支持负数表示相对最后区块的偏移--catchup-margin默认 5相对最后已见区块的追赶余量--catchup-paging默认 100追赶分页的区块数--reorg-maximum-duration-in-blocks默认 50检测重组的时间窗口--dependent-ops-max-per-chain默认 0禁用慢车道启用后超限依赖链进入慢车道。gw-listenergw_listener --gw-url GW_URL \ -i --input-verification-address INPUT_VERIFICATION_ADDRESS \ --verify-proof-req-database-channel event_zkpok_new_work \ --database-pool-size 16 \ --get-logs-poll-interval 1s --get-logs-block-batch-size 100gw-listener 通过 WebSocket 订阅输入证明验证事件插入verify_proofs表并通过event_zkpok_new_work通道通知 zkproof-worker建议将provider-max-retries与provider-retry-interval配置为较高值以保证事件不丢失参见 gw-listener/README.md。transaction-sendertransaction_sender -i INPUT_VERIFICATION_ADDRESS \ -c CIPHERTEXT_COMMITS_ADDRESS -g GATEWAY_URL \ -s private-key -p PRIVATE_KEY \ --gas-limit-overprovision-percent 300 \ --verify-proof-resp-database-channel event_zkpok_computed \ --add-ciphertexts-database-channel event_ciphertexts_uploaded--signer-type支持private-key与aws-kms后者读取标准AWS_REGION、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY等环境变量。蓝绿升级upgrade-controllerupgrade-controller配合consensus-detector实现 Coprocessor 的蓝绿BCS→GCS无缝升级GCS 在独立 schema如gcs-0.15.0中并行计算到达end_block后自动 cutover——把 GCS schema 合并进 public、BCS 置为 PAUSED、GCS 变为 LIVE全程通过upgrade_state表与event_upgrade_activated数据库通知驱动具体步骤见 upgrade-controller/README.md。版本号由 fhevm-engine-common/src/lib.rs 中的STACK_VERSION统一管理可通过--stack-version查看编译进二进制的版本。可观测性Prometheus 指标各服务默认在0.0.0.0:9100暴露指标--metrics-addr可覆盖。OTLP 追踪通过--service-name或OTEL_SERVICE_NAME环境变量指定服务名上报链路追踪数据。项目建议统一使用tracingspan 作为遥测 API遵循以函数/span 名称作为操作名、不在 span 属性上挂高基数标识符、异步工作使用.instrument(...)、错误退出时设置 OTEL error status等规范具体见 fhevm-engine/README.md 的 Telemetry Style Guide 章节。健康检查host-listener 默认在:8080提供健康检查--health-port。小结Coprocessor Backend 是 fhEVM 把区块链 全同态加密落到实处的关键链下组件以 PostgreSQL 为中枢、以 listeners 为入口、以 tfhe-worker 为计算引擎Server 与 Worker 解耦通信天然支持横向扩展与多租户隔离。理解它的组件划分、进程模型与命令行参数是搭建 fhEVM-coprocessor 测试环境、进行性能调优线程池、批量大小、依赖链调度以及参与 Coprocessor 微服务开发的前提。后续可以继续阅读 Configuration 与 FHE Computation 获取更底层的运行细节。【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考