fhEVM Relayer 完全指南桥接 FHE 主机链与 Zama Gateway 的事件驱动 Rust 服务【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm本文深入解析 fhEVM 生态中的核心基础设施组件 Relayer它如何将 fhEVM 主机链如 Ethereum与 Zama Gateway 连接起来对外提供公开解密、输入证明验证、用户解密与密钥材料分发四大 HTTP 能力。读完本文你将掌握 Relayer 的事件驱动架构原理、Mainnet/Testnet 自托管部署全流程、完整的配置项语义以及超时回收与数据保留等生产级运维机制。一、Relayer 在 fhEVM 网络中的角色Relayer 是 fhEVM 主机链Host Chain例如 Ethereum与 Zama Gateway 之间的桥接服务bridge。它向外部暴露以下四类核心能力Public Decryption公开解密中继 HTTP 公开解密请求返回明文响应Input Proof Verification输入证明验证中继 HTTP 输入证明验证请求返回有效性证明User Decryption用户解密中继 HTTP 用户解密请求在携带密文句柄ciphertext handle访问控制的前提下将数据在用户提供的公钥下重新加密Key Material密钥材料对外提供密钥材料 URLFHE 公钥与 CRS 的 URL供链上应用与 SDK 获取。任何第三方都可以自托管一个 Relayer从而以无需许可permissionless的方式独立接入 fhEVM 网络摆脱对第三方基础设施的依赖。相关能力描述见 relayer/README.md 与 relayer/docs/SELF_HOSTING.md。二、事件驱动架构Relayer 采用事件驱动event-driven架构核心组件包括组件职责Orchestrator编排器事件流与处理的中枢协调器Gateway listeners / handlers监听并处理 Gateway 区块链事件HTTP Handlers处理 V2 API 请求SQL Repositories持久化请求状态支撑状态轮询Transaction Engine Throttlers可靠的交易管理与背压backpressure控制Metrics TracingAPI、队列与链上流程的运行时可观测性官方架构图Mermaid如下从源码看编排器的核心实现在 relayer/src/orchestrator/orchestrator.rsOrchestrator持有事件分发器TokioEventDispatcher、健康检查器HealthChecker、任务管理器TaskManager以及一个可恢复的 detached task 集合。事件处理是可重放的——任务可从 PostgreSQL 与链游标chain cursor恢复因此优雅关停shutdown不会丢弃未完成任务。编排器还提供new_internal_request_id/new_ext_job_id用于生成内部请求 ID 与对外 job ID实现内外标识隔离。典型的事件流转如下HTTP APIv2提交请求 → Orchestrator 的事件路由器Gateway ListenerWSS 订阅捕获区块链事件 → 同样进入事件路由器路由器经由 Hooks持久化、日志、指标分发到 DispatcherDispatcher 调用具体的 Event HandlersInputProof / PublicDecrypt / UserDecrypt / KeyUrlHandlers 向 Gateway 区块链发送交易Gateway 的响应事件再被 Listener 捕获形成闭环请求状态通过 Hooks 落库到 PostgreSQLHTTP 侧可轮询数据库获取状态。三、项目结构与代码地图Relayer 以 Rust workspace 组织主目录结构如下见 relayer/README.mdsrc ├── bin/ # 二进制入口点 │ └── fhevm-relayer.rs # 主服务二进制 ├── config/ # 配置加载与校验 ├── core/ # 核心领域事件、ID 与共享类型 ├── gateway/ # Gateway 监听器、处理器与交易引擎 │ ├── arbitrum/ # Arbitrum 监听器与交易处理 │ └── readiness_check/ # 就绪检查处理流水线 ├── http/ # HTTP 服务、API 处理器与中间件 │ ├── admin/ # 运行时管理端点 │ ├── endpoints/ # API 实现common、v2、v3 │ ├── middleware/ # OpenAPI/docs 与请求中间件 │ ├── retry_after/ # 动态 Retry-After 估算 │ └── utils/ # 解析与校验工具 ├── logging/ # 结构化日志工具 ├── metrics/ # Prometheus 指标与仪表盘文档 ├── orchestrator/ # 事件编排系统 ├── store/sql/ # SQL 模型与仓库 ├── lib.rs # 库入口 ├── startup.rs # 服务启动装配 ├── startup_recovery.rs # 启动恢复编排 └── tracing.rs # Tracing 初始化 relayer-migrate/ # 独立 crate数据库迁移含连接重试与回滚 config/local.yaml.example # 本地配置模板 dev/docker-compose.yaml # 本地 Postgres compose tests/ # 集成与 API 测试 test-support/ # 测试辅助如 Ethereum RPC mock docs/ # 补充项目文档 design-docs/ # 设计与架构笔记 openapi-async-design.yaml # OpenAPI 规范 Makefile # 测试、lint 与迁移辅助几点值得注意gateway/arbitrum/包含交易引擎transaction/engine.rs、tx_throttler.rs、nonce_manager.rs等与监听器listener.rs、polling_listener.rs说明 Relayer 面向 Arbitrum 系 Gateway 链实现了订阅式与轮询式两种监听策略relayer-migrate/是独立 crate负责带连接重试与回滚能力的数据库迁移见 relayer/relayer-migratetest-support/提供了 Ethereum RPC mock集成测试可脱离真实链运行。四、环境准备Prerequisites自托管或开发前需要准备以下工具链Rust 工具链 Cargo仓库以rust-toolchain.toml固定工具链版本见 relayer/rust-toolchain.tomlDocker Docker Compose v2用于启动本地 PostgreSQLFoundrycast仅在网络接入阶段make preflight-*、make mint-zama-*、make approve-payment-*需要Node.js npm仅用于make api-lint。运行make help可查看全部可用 target见 relayer/Makefile。配置机制配置通过以下三层由低到高加载后者覆盖前者YAML 文件默认读取config/local.yaml若存在可选 CLI 配置文件--config-file参数指定环境变量以APP_为前缀、__表示层级嵌套覆盖文件值。环境变量示例APP_GATEWAY__BLOCKCHAIN_RPC__HTTP_URLhttps://rpc.example.org该机制在 relayer/src/config/settings.rs 中通过configcrate 的Environment与File源实现并附带完整的validate()校验逻辑例如 RPC URL 必须以http://或https://开头。五、自托管部署指南完整的生产部署说明、安全注意事项请参见 Self-Hosting Guide。以下快速开始覆盖让 Relayer 在 Mainnet 或 Testnet 上运行的最小步骤。所有命令需在relayer/目录下执行。主网Mainnet快速开始make db-start # 启动本地 PostgresDocker Compose端口 5433 make db-migrate # 应用数据库迁移 make preflight-mainnet # 交互式配置、私钥、余额检查、授权 make run-mainnet # 启动 Relayer make health # 验证健康端点测试网Testnet快速开始make db-start # 启动本地 PostgresDocker Compose端口 5433 make db-migrate # 应用数据库迁移 make preflight-testnet # 交互式配置、私钥、余额检查、授权 make run-testnet # 启动 Relayer make health # 验证健康端点主网上线前置条件Gateway 链上的 ETH用于支付 gas需通过 Zama Bridge 从 Arbitrum One 桥接到 Gateway 链Gateway 链上的 $ZAMA 代币购买后经 Zama Bridge 从 Ethereum L1 桥接到 Gateway 链一个 Ethereum L1 RPC 端点。测试网流程相同但资金来源不同ETH 需从 Arbitrum Sepolia 桥接$ZAMA 则需向 Relayer 团队申请测试网不提供自助铸造。preflight 向导详解make preflight-mainnet/make preflight-testnet是一个交互式接入向导实现见 relayer/Makefile 中的_preflight目标依次执行若config/local.mainnet.yaml或 testnet 对应文件不存在则从示例模板创建提示输入钱包私钥由私钥推导钱包地址检查 Gateway 链 ETH 余额检查 $ZAMA 余额主网余额不足时向导会提示购买/桥接指引测试网则提示联系团队检查钱包是否已授权ProtocolPayment合约花费 $ZAMA若未授权向导会询问是否执行make approve-payment-mainnet/make approve-payment-testnet授予最大额度MAX_UINT256授权。向导通过YES1/NO1环境变量可自动接受/拒绝交互提示适合 CI 场景。mint-zama-testnet目标会明确提示测试网 $ZAMA 非自助铸造需联系团队获取。私钥管理最佳实践配置文件中私钥存放于gateway.tx_engine.private_key字段建议遵循绝不提交config/local.mainnet.yaml或config/local.testnet.yaml到版本控制已在.gitignore中优先使用环境变量覆盖设置APP_GATEWAY__TX_ENGINE__PRIVATE_KEY0x...可完全避免私钥落盘为 Relayer 操作使用专用钱包。签名器除private_key外还支持AWS KMS签名器type: aws_kms配合key_id/region/ 可选endpoint字段见 relayer/config/local.yaml.example适合生产部署场景。六、配置参考以下为运维可调的核心配置字段默认值来自 relayer/config/local.yaml.example 与 relayer/docs/SELF_HOSTING.md字段说明默认值http.endpointAPI 监听地址0.0.0.0:3000log.format日志格式compact/pretty/jsonprettygateway.tx_engine.tx_throttlers.*.per_seconds每类操作的 TX 节流速率20storage.app_pool.max_connections应用连接池最大连接数10storage.cron.timeout_cron_interval超时 worker 运行周期60sstorage.cron.public_decrypt_timeout公开解密请求超时30mstorage.cron.user_decrypt_timeout用户解密请求超时30mstorage.cron.input_proof_timeout输入证明请求超时30mstorage.cron.expiry_enabled是否启用自动数据清理falsestorage.cron.public_decrypt_expiry公开解密记录保留期365dstorage.cron.user_decrypt_expiry用户解密记录保留期7dstorage.cron.input_proof_expiry输入证明记录保留期7dhttp.retry_after.max_secondsRetry-After 请求头最大值300http.enable_admin_endpoint是否启用/admin/config运行时配置注意安全说明false配置层级为YAML 文件 → 环境变量APP_前缀、__嵌套→ CLI 参数。关键配置区块语义1. host_chains 与 protocol_confighost_chains: - chain_id: 8009 url: http://localhost:8545 acl_address: 0x339EBB773A9bC1deCFfD5ef4BC7c907e26C1f836 protocol_config: ethereum_http_rpc_url: http://localhost:8545 address: 0x1234567890123456789012345678901234567890 retry: max_attempts: 3 retry_interval_ms: 200host_chains声明主机链及其 ACL 合约地址protocol_config提供协议配置合约信息与重试参数。2. keyurl 密钥材料来源keyurl: source: chain # chain 轮询主机链或 config 直接提供静态值 kms_generation_address: 0x... poll_interval_ms: 12000/v2/keyurl的数据来源有两种模式chain轮询主机链上的 KMSGeneration 合约或config直接返回静态配置适用于没有ProtocolConfig.getCurrentKmsContextAndEpoch方法的协议部署。实现上relayer/src/host/keyurl_poller.rs 中的轮询器按poll_interval_ms周期在已定稿区块finalized block读取链上状态通过tokio::sync::watch通道将最新密钥/CRS/KMS 上下文推送给端点——因为密钥激活事件稀疏且订阅不可靠周期比较是幂等且自愈的。轮询器从NewKmsContext事件中恢复 KMS 节点的存储前缀并构造{storage_url}/{storage_prefix}/{segment}/{id_hex}形式的对象 URL。3. gateway 区块gateway: blockchain_rpc: http_url: http://localhost:8757 # 必须支持 eth_sendRawTransactionSync 方法 read_http_url: http://localhost:8757 # 读请求可指向全节点分摊负载 chain_id: 654321 ws_health_check_timeout_secs: 5 http_health_check_timeout_secs: 5 contracts: decryption_address: 0x... input_verification_address: 0x... user_decrypt_shares_threshold: 9其中http_url是写节点必须支持eth_sendRawTransactionSyncread_http_url可指向只读全节点以分摊负载。user_decrypt_shares_threshold是用户解密所需的最小份额阈值。4. listener_pool 统一监听器池listener_pool: reconnect_config: max_attempts: 20 retry_interval_ms: 500 polling_max_attempts: 40 # 轮询型监听器的最大连续失败次数 recycle_interval_mins: 30 # 连接回收周期分钟错峰执行 poll_interval_ms: 2000 # 轮询型监听器轮询间隔 max_blocks_per_query: 1000 # 单次 eth_getLogs 的最大区块跨度 dedup_ttl_seconds: 5 # 事件去重 TTL1-10 秒 dedup_max_capacity: 100000 # 事件注册表最大容量约支撑 5500 events/sec listeners: - type: subscription # subscriptionWSS或 pollingHTTP url: ws://localhost:8757 - type: subscription url: ws://localhost:8757监听器池支持多类型监听器WebSocket 订阅与 HTTP 轮询混布共享去重dedup与错峰回收staggered recycling。dedup_max_capacity的容量公式为events_per_second × num_listeners × dedup_ttl_seconds × 1.2示例值见配置文件注释。生产环境建议为不同监听器配置不同 URL 以提升冗余度。5. tx_engine 交易引擎与节流器tx_engine: signer: type: private_key # 或 aws_kms private_key: 0x... max_concurrency: 100 retry: max_attempts: 100 retry_interval_ms: 500 tx_throttlers: input_proof: per_seconds: 20 capacity: 11000 safety_margin: 1000 user_decrypt: # 结构同上 public_decrypt: # 结构同上每类操作input_proof / user_decrypt / public_decrypt拥有独立的令牌桶节流器per_seconds速率、capacity容量、safety_margin安全余量实现背压保护。6. readiness_checker 就绪检查readiness_checker: host_acl_check: retry: { max_attempts: 3, retry_interval_ms: 1000 } gw_ciphertext_check: source: coprocessor_attestations # 或 gateway_chain链上检查 retry: { max_attempts: 75, retry_interval_ms: 3000 } head_timeout_ms: 5000 request_timeout_ms: 240000 registry_refresh_ms: 60000 max_concurrent_handles: 8 gateway_config_address: 0x... public_decrypt: { max_concurrency: 250, capacity: 11000, safety_margin: 1000 } user_decrypt: { max_concurrency: 250, capacity: 11000, safety_margin: 1000 }密文检查支持两种来源coprocessor_attestations链下协处理器证明共识RFC 023与gateway_chain链上 Gateway 检查。前者额外配置 S3 存储桶 HEAD 请求超时、注册表刷新间隔与并发句柄数。7. http 与 retry_after 动态重试http: endpoint: 0.0.0.0:3000 api_retry_after_seconds: 4 # 队列响应默认 retry-after 秒数 enable_admin_endpoint: false retry_after: min_seconds: 1 max_seconds: 300 safety_margin: 0.2 # ETA 安全余量系数 nominal_times: readiness_check_seconds: 4 input_proof_processing_seconds: 2 user_decrypt_processing_seconds: 6 public_decrypt_processing_seconds: 6 tx_confirmation_ms: 250 copro_kms_backoff_intervals: - [0, 4] # 0-60s每 4s 轮询一次 - [60, 10] # 60s-2m每 10s - [120, 30] # 2-5m每 30s - [300, 60] # 5-15m每 60s - [900, 300] # 15m每 5m可能已卡死http.retry_after根据队列大小、排空速率与处理阶段动态计算Retry-After响应头最终 ETA 计算值 × (1 safety_margin)。nominal_times定义了各阶段的名义处理耗时可在运行时通过/admin/config更新copro_kms_backoff_intervals则针对ReceiptReceived状态唯一无法计算动态 ETA 的状态提供退避策略——注意安全余量不作用于退避区间。8. storage 与 cronstorage: sql_database_url: postgresql://postgres:postgreslocalhost:5433/relayer_db app_pool: { max_connections: 10, min_connections: 2, acquire_timeout_secs: 10, ... } cron_pool: { max_connections: 5, min_connections: 1, ... } cron: timeout_cron_interval: 60s public_decrypt_timeout: 30m user_decrypt_timeout: 30m input_proof_timeout: 30m expiry_enabled: false expiry_cron_interval: 5m public_decrypt_expiry: 365d user_decrypt_expiry: 7d input_proof_expiry: 7d cron_startup_delay_after_recovery: 30s # 必须小于最小超时/保留期的 10%9. shutdown 与 dispatcher_lock高可用单活语义shutdown: lb_propagation_wait: 5s # 停止 Ready 后继续服务的时长让 LB 先摘除实例 lock_release_timeout: 3s # 释放 dispatcher 锁的预算 dispatcher_lock: standby_poll_interval: 2s # 备实例抢锁间隔即故障转移延迟 holder_heartbeat_interval: 5s # 持锁方心跳间隔 query_timeout: 3s exit_after_consecutive_failures: 20 # 连续心跳失败 20 次后让位约 100s可跨越 RDS Multi-AZ 故障转移 connect_timeout: 5s idle_session_timeout: 60s # Postgres 会话空闲超时需 Postgres 14 key_override: null sweep: interval: 500ms # 持锁方扫描无人驱动请求的间隔dispatcher_lock通过 PostgreSQL 会话级锁实现单活single-activedispatcher语义同一数据库下的多个 Pod 中只有持锁方驱动事件分发与请求清扫备实例以standby_poll_interval周期尝试抢锁idle_session_timeout在持锁节点异常退出未关闭 socket时自动释放锁实现故障转移。七、API 端点健康端点端点说明GET /liveness存活探针GET /healthz就绪 / 健康检查GET /version构建版本信息GET /docsOpenAPI 文档密文操作与密钥 URL 端点密文端点遵循异步任务语义POST提交请求并返回job_id随后用GET .../{job_id}轮询结果。操作端点输入证明验证POST /v2/input-proof公开解密POST /v2/public-decrypt用户解密POST /v2/user-decrypt委托用户解密POST /v2/delegated-user-decrypt密钥材料 URLGET /v2/keyurl完整请求/响应 schema 见GET /docs或 relayer/openapi-async-design.yaml。从源码看v2 用户解密请求体relayer/src/http/endpoints/v2/types/user_decrypt.rs包含handle_contract_pairs句柄-合约对、request_validity、contracts_chain_id、contract_addresses、user_address、EIP-712signature130 字符无0x前缀的原始十六进制、用户重加密公钥public_key以及extra_data所有字段都有 validator 校验。委托用户解密/v2/delegated-user-decrypt则额外携带delegator_address、delegate_address、start_timestamp与duration_days委托参数。POST响应返回status: queued、request_id与排队结果。仓库还提供了v3 用户解密端点/v3/user-decrypt见 relayer/src/http/endpoints/v3/handlers/user_decrypt.rs它接受统一 EIP-712 类型的证明信封转换为共享的UserDecryptRequest后与 v2 走同一条去重/排队流水线与收据处理路径其GET轮询则直接委托 v2 处理器响应 schema 不变。管理端点GET /admin/config POST /admin/config由enable_admin_endpoint开关控制关闭时返回403 Forbidden。支持运行时调整节流器 TPS 与 retry-after 字段主要用于测试与压测。安全注意这些端点默认禁用且刻意不提供应用层认证。启用时必须通过网络层手段限制可达性——将http.endpoint绑定到回环地址或内网子网或将该端点置于认证层之后。八、可观测性日志与追踪策略relayer/LOGGING_POLICY.md指标与仪表盘指南relayer/src/metrics/docs_and_dashboards/http_metrics.md同目录下还有 SQL、状态、交易等指标的文档应用指标端口9898上的GET /metricsPrometheus 格式。健康探针在:3000/liveness、/healthz指标在:9898。日志格式支持compact/pretty/json并可通过show_file_line、show_thread_ids、show_timestamp、show_target开关细化输出。九、请求超时机制后台 worker 会在 Gateway 链未在配置的超时窗口内响应时将卡在receipt_received状态的请求标记为timed_out。该 worker始终启用作为后台 cron 任务运行实现在 relayer/src/store/sql/repositories/timeout_repo.rs。超时时间按请求类型在配置的cron区块中设置配置键默认值说明storage.cron.timeout_cron_interval60sworker 检查陈旧请求的频率storage.cron.public_decrypt_timeout30m公开解密请求超时storage.cron.user_decrypt_timeout30m用户解密请求超时storage.cron.input_proof_timeout30m输入证明请求超时源码中的实现要点以用户解密为例time_out_stale_requests使用 CTECommon Table ExpressionFOR UPDATE SKIP LOCKED的原子方式一次性完成定位陈旧行 → 更新状态为timed_out→ 记录错误原因Gateway chain did not respond within the expected timeframe三个动作SKIP LOCKED用于避免多 worker 并发时的行冲突同时更新updated_at并记录状态迁移指标。三类请求user_decrypt / public_decrypt / input_proof按相同模式依次处理。十、数据保留策略Relayer 可定期从数据库中清除陈旧请求数据以控制存储增长。公开解密、用户解密、输入证明验证的旧记录会基于可配置的保留窗口被周期性删除该清理任务作为后台 cron 实现于 relayer/src/store/sql/repositories/expiry_repo.rs。expiry worker 默认禁用。可手动对数据库执行等价的DELETE查询来清理陈旧数据若需启用自动清理在配置cron区块设置expiry_enabled: true并确保数据库用户对相关表拥有DELETE权限。源码细节purge_stale_data只删除处于终态completed、timed_out、failure的记录——这是刻意设计任何查询都不会从这些状态继续写入req_status因此这类行已结束、可按年龄安全清理若updated_at陈旧但状态非终态说明请求卡死而非完成删除会掩盖故障。清理前会先统计待删状态保持 gauge 与真实删除行一致再执行DELETE并分别记录查询与删除指标。保留窗口默认值公开解密365d、用户解密7d、输入证明7dexpiry_cron_interval默认5m。此外cron_startup_delay_after_recovery默认30s在恢复完成后延迟启动 cron worker给恢复中的请求留出处理时间避免误判超时校验规则必须小于最小超时与最小保留期的 10%。十一、开发与测试面向源码开发者relayer/docs/DEVELOPMENT.md 提供了完整指南。核心工作流首次搭建make setup # 一键完成启动 Postgres 迁移 复制配置模板该命令依次启动端口 5433 的本地 PostgreSQL避开系统默认 5432执行数据库迁移若config/local.yaml不存在则从config/local.yaml.example复制。运行测试测试在 nextest 下运行需先安装cargo install cargo-nextest --locked make test # 完整套件与 CI 一致需要 Postgres make test-unit # 仅 src/ 单元测试无需 Postgres测试按组group划分每组对应一个测试二进制——或是一个 API 流程如public-decrypt或是一个跨流程的横切特性如listener-redundancymake test-groups # 列出可用组名 make test-group GROUPpublic-decrypt # 运行单个组的全部用例 make test-group GROUPpublic-decrypt CASEacl # 仅运行匹配子串的用例 make test-group GROUPpublic-decrypt SKIPtimeout # 排除慢速超时用例默认 8 个并发测试线程与 CI 一致每个测试使用独立隔离的 schema约占用 3 个 Postgres 连接。本地可追加TEST_THREADS32提速或TEST_THREADS1串行调试。测试组的完整清单与映射见 relayer/Makefile包括user-decrypt、delegated-user-decrypt、input-proof、admin-endpoint、keyurl、restart、schema-isolation、dispatcher-lock、epoch-fencing、two-instance等 18 组。数据库管理make db-start # 启动本地 Postgres5433并等待就绪 make db-stop # 停止保留数据 make db-destroy # 停止并清空数据 make db-reset # 清空并从头重跑迁移 make db-status # 容器状态 连接测试 make db-shell # 打开 psqlsqlx 相关需安装sqlx-cli 0.8.6因为 0.9.0 的 MSRV 高于仓库固定的 rustc 1.91.1make sqlx-migrate # 通过 sqlx-cli 执行迁移 make sqlx-prepare # 重新生成离线元数据供 CI/Docker 构建本地全栈与 Docker本地全栈模式可借助 fhevm 仓库的fhevm-cli部署完整 Zama 协议需至少 12 GB Docker 内存再构建并注入本地 Relayer 镜像随后用./fhevm-cli test input-proof运行 E2E 测试相关脚本位于仓库的 test-suite/fhevm。Docker 构建与发布make docker-build # 构建 Relayer 镜像 make docker-build-migrate # 构建 relayer-migrate 镜像 make docker-build-all # 两者 make docker-release TAGv0.9.0-rc.1 # 带 registry 前缀构建注意Relayer 的 Dockerfile 在构建时挂载.git/HEAD、.git/objects、.git/refs以嵌入版本信息因此必须在主克隆primary clone上构建——在 Git worktree 中.git是文件而非目录挂载会失败。Lint 与格式make check # fmt clippy推荐作为 push 前门禁 make fix # 自动修复 fmt clippy make clippy # 仅 clippy make fmt # 仅格式检查十二、故障排查Postgres 使用 5433 端口而非 5432relayer/dev/docker-compose.yaml 中的本地 Postgres 映射到端口 5433以避免冲突。若遇到 connection refused请确认目标端口是 5433。sqlx 离线元数据必须保持最新Docker 构建依赖预计算的查询元数据.sqlx/目录。新增或修改 SQL 查询后必须在构建镜像前运行make sqlx-prepare。Git worktree 会破坏 Relayer Docker 构建如上文所述Relayer Dockerfile 挂载.git/HEAD、.git/objects、.git/refs用于构建期版本嵌入。在 Git worktree 中.git是文件非目录挂载失败。请从主克隆构建。配置模板包含 localhost/mock URLconfig/local.yaml.example内置了localhost:8757RPC 地址与0.0.0.0:3001密钥 URL仅对本地 mock 栈有效。目标为 Testnet/Mainnet 时请使用make preflight-testnet/make preflight-mainnet——它们会自动复制正确的示例配置。本地全栈的 Docker 内存运行./fhevm-cli deploy需要至少12 GB的 Docker 内存。十三、结语fhEVM Relayer 是 fhEVM 网络去中心化接入的关键拼图它以事件驱动架构统一处理公开解密、输入证明验证、用户解密与密钥材料分发借助 PostgreSQL 实现请求状态持久化与可恢复编排通过事务引擎、节流器、动态 Retry-After、超时回收与数据保留策略保证生产级可靠性与可运维性。无论是希望自托管接入 fhEVM 网络的团队还是想深入理解 FHE 区块链基础设施内部机制的开发者都可以从 relayer/README.md、relayer/docs/SELF_HOSTING.md 与 relayer/docs/DEVELOPMENT.md 出发结合 relayer/config/local.yaml.example 与 relayer/src 源码逐步深入。本项目采用BSD 3-Clause Clear License见 relayer/README.md 末尾与仓库根目录 LICENSE。【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考