fhevm/sdk 版本演进全解读从协议兼容到统一解密许可体系【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm本文以 sdk/js-sdk/docs/release-notes.md 为主线系统梳理 fhevm/sdkfhEVM 全同态加密框架的 JavaScript 客户端从 v1.1.0-alpha.1 到 v0.15.0 的完整演进脉络。你将掌握SDK 如何随链上协议版本v11v15自动解析并选择匹配的 TFHE/KMS WASM 模块、解密许可Decryption Permit从 V1 走向统一 V2 的 API 变化与迁移路径、ERC-1271 智能合约钱包签名的支持机制以及面向 Next.js/Turbopack 等现代运行时的兼容性保障。读完本文你可以依据版本演进表完成项目升级评估并借助破坏性变更清单快速迁移既有代码。版本地图一条从 cleartext 模式到协议 v0.15 的主线release-notes.md记录的时间线与版本号并不严格递增因为它同时承载了main分支的 v0.15.0unreleased、v0.14.x / v0.13.x 维护线以及 v1.1.0-alpha.x 的预发布系列。将它们按发布时间排列可以得到如下主线版本发布时间核心主题v1.1.0-alpha.12026-05-22cleartext 模式、多版本 WASM 支持、RelayerAsyncRequest 重试引擎v1.1.0-alpha.22026-05-27readPublicValue*→decryptPublicValue*更名、默认 WASM 版本升级、docs/compatibility.mdv1.1.0-alpha.32026-05-29修正 KMS 响应重构的threshold传参v1.1.0-alpha.42026-05-29自定义 HTTP 头、严格 relayer URL 校验、GET 请求携带 authv1.1.0-alpha.52026-06-24自动协议版本 / WASM 版本解析、moduleVersions、epochId跟踪v1.1.0-alpha.62026-06-29Next.js/Turbopack 修复、TFHE WASM 1.6.2、纯 JS inflaterv1.1.0-alpha.72026-07-03统一signDecryptionPermit()签名、durationSeconds、公共 API 清理v0.13.32026-08-21polygon/polygonAmoy 链定义、legacy permit 固定、forge-fhevm v1 cleartextv0.14.1-02026-08-24协议 v0.14 支持、统一V2permit 可用、ERC-1271 钱包签名v0.15.0unreleasedmain分支协议 v0.15 支持、npm 包瘦身可以看到v0.13.x / v0.14.x / v0.15.0 是面向链上协议版本的对链维护线而 v1.1.0-alpha.x 是面向 API 形态与运行时体验的功能演进线两条线在 v0.14.1-0 处通过devex/js-sdk引擎分支的大规模合并汇合。以下各节按协议兼容 → 解密许可 → WASM 解析 → 链配置 → 运行时 → 迁移的顺序展开。协议支持演进SDK 如何说v11v15 的链上协议协议 API 版本的编译期常量SDK 对链上协议的支持由一个静态常量控制。在 sdk/js-sdk/src/core/runtime/sdkProtocolApiVersion.ts 中可以看到export const SDK_PROTOCOL_API_MAJOR_VERSION: number 0; export const SDK_PROTOCOL_API_MINOR_VERSION: number 15; export const SDK_PROTOCOL_API_PATCH_VERSION: number 0;release-notes.md记录了它的演进v0.13.3 时代引入的sdkProtocolApiVersion.ts定义了SDK_PROTOCOL_API_MAJOR/MINOR/PATCH_VERSION三元组用于表达某次 SDK 构建所支持的协议 API 面v0.14.1-0 中该常量从13升到14v0.15.0 中再次从14升到15。这一常量与链上动态读取的protocolVersion是两个概念前者是编译期常量可被打包器作为恒真/恒假分支折叠tree-shake 掉后者是运行时从链上宿主合约解析出的真实协议版本。从 v13 到 v15 的向后兼容语义根据release-notes.mdSDK_PROTOCOL_API_MINOR_VERSION 15意味着 SDK 原生支持链上 FHEVM 协议 v11 至 v15 的 API并凭借协议自身的向后兼容保证继续兼容 v16 的链。这一承诺的基础在 sdk/js-sdk/docs/compatibility.md 中有详细展开协议版本 → 宿主合约版本每个协议版本都会至少提升一个宿主合约的版本这是 SDK 能通过ACL.version反推协议版本的先决条件。例如协议 v0.14.0 对应ACL 0.5.0 / FHEVMExecutor 0.5.0 / KMSVerifier 0.4.0 / HCULimit 0.4.0 / ProtocolConfig 0.2.0。协议版本 → 离链组件版本协议 v0.14.0 对应TFHE 1.6.2、KMS 0.14.0-1、extraDatav2v0.15.0 的对应矩阵在文档中仍标记为待定?。核心限制链上没有直接信号告知 SDK 解析某个 PubKey/CRS 所需的最低tfhe.wasm版本且该格式在 minor 版本之间不向前兼容tfhe.wasmv1.5.3无法解析 v1.6.2 生成的 PubKey/CRS。因此 SDK 只能按读ACL.version→ 映射协议版本 → 按发布时快照解析 PubKey/CRS 版本 → 映射到tfhe.wasm版本的启发式链路选择 WASM。版本支持的实际效果对 SDK 用户而言协议版本提升的可见影响集中在两点默认 KMS WASM 模块切换v0.14.1-0 将内置 KMS WASM 提升到0.14.0-1TFHE 保持在1.6.2并使其成为协议 0.14.0的默认 TKMS 模块显式指定moduleVersions.kms为0.13.10/0.13.20-0的旧配置在 v0.14.0 协议上下文中仍然被接受。permit 版本分裂协议 v0.13与 v0.14分别对应 V1 / V2 解密许可详见下一节。解密许可Decryption Permit体系从 V1 到统一 V2解密许可是 fhevm/sdk 用户解密流程的核心概念用户为某个密文句柄签署一份 EIP-712 结构化数据KMS 验证签名后返回解密份额。这一体系在近几个版本中经历了最剧烈的重构。统一签名 APIv1.1.0-alpha.7此前signDecryptionPermit()存在 self / delegated 两套重载与两套参数类型。从 v1.1.0-alpha.7 起合并为单一签名signDecryptionPermit(fhevm, parameters: SignDecryptionPermitParameters): PromiseSignedDecryptionPermit传入delegatorAddress即得到委托许可省略则为自签许可SignSelfDecryptionPermitParameters/SignDelegatedDecryptionPermitParameters两个类型被移除统一使用SignDecryptionPermitParameters破坏性变更durationDays整天数替换为durationSeconds迁移示例// Before await signDecryptionPermit(fhevm, { ..., durationDays: 7 }); // After await signDecryptionPermit(fhevm, { ..., durationSeconds: 7 * 24 * 60 * 60 });SignedDecryptionPermit始终直接暴露isDelegated: boolean字段许可新增version字段1或2反映其签发时所对应的链上协议。针对不同协议版本签发的许可不可互换——不过通常无需自行分支SDK 在序列化/解析/校验时内部处理。从源码看这一统一入口、按协议分派的架构落地在 sdk/js-sdk/src/core/kms/SignedDecryptionPermit-p.tssignDecryptionPermit解析许可的version字段后分派到SignedDecryptionPermitV1-p.ts协议 ≤ v0.13或SignedDecryptionPermitV2-p.ts协议 ≥ v0.14。同一...V1-p.ts/...V2-p.ts分裂模式也应用于fetchKmsSigncryptedShares与 KMS 的 EIP-712 类型定义。V1 许可的显式固定v0.13.3为让希望保持 V1 许可形状稳定的用户免受未来协议 API 升级影响v0.13.3 新增了可摇树tree-shakeable的createUnsignedLegacyDecryptionPermitEip712和signLegacyDecryptionPermit以及客户端方法client.signLegacyDecryptionPermit(...)用于显式固定 V1 许可形状。同时破坏性变更signDecryptionPermit不再作为独立 action 从fhevm/sdk/actions/base导出import { signDecryptionPermit } from fhevm/sdk/actions/base失效该 barrel 只导出 legacy 两个函数client.signDecryptionPermit(...)作为客户端方法仍可用V1 行为但标记为deprecated。破坏性变更serializeTransportKeyPair()与serializeSignedDecryptionPermit()变为async内部需先解析客户端的 frozen 版本上下文。破坏性变更TransportKeyPair.tkmsVersion由必填的TkmsVersion改为string | undefined——解析/反序列化出的传输密钥对不再必然携带创建时固定的版本而是在用于解密时依据当前协议上下文动态解析generateTransportKeyPair()不受影响。统一V2许可真正可用v0.14.1-0v0.14.1-0 中V2 许可从已编译进库变为可用createUnsignedUnifiedDecryptionPermitEip712(fhevm, parameters)与signUnifiedDecryptionPermit(fhevm, parameters)支持 self 与 delegated语义同signDecryptionPermit正式导出并可用。能力探测canUseUnifiedDecryptionPermit(fhevm, { options })在依赖v3/user-decrypt路由之前报告连接的 relayer 是否支持该路由。探测机制是每个 client 对空请求探测一次存在则返回 400、不存在返回 404缓存结果并去重并发探测。若对不支持该路由的 relayer 调用 V2 permit 操作现在会得到指向canUseUnifiedDecryptionPermit的明确错误而非盲目猜测。源码实现位于 sdk/js-sdk/src/core/actions/base/canUseUnifiedDecryptionPermit.ts它读取ensureRelayerFeatures解析出的relayerSupportsV3UserDecryptRoute特性位。特性每 client 解析一次并固定重复调用零成本且不会漂移options.auth仅用于解析需要密钥的 relayer如 mainnet的特性无密钥 relayer如 Sepolia可省略且结果缓存后后续调用无需再传 auth。运行时路由decryptValuesFromPairs中的 permit 路由改为按被签许可自身的version字段分派V1 →v2/user-decryptV2 →v3/user-decrypt而不是按 SDK 编译期协议版本上限——V1/V2 分裂重新成为许可的运行时属性。ERC-1271 智能合约钱包签名v0.14.1-0v0.14.1-0 起解密许可的signature不再局限于 65 字节的 EOA ECDSA 签名还可以是 Safe 风格的多签 blob 或空0x预批准哈希签名。新的预防性检查verifyErc1271UserDecrypt在许可送达 KMS 前自动判别65 字节签名本地通过ecrecover验证视为 EOA其他形态对IERC1271(userAddress).isValidSignature(digest, signature)发起 STATICCALL仅当返回 ERC-1271 magic value0x1626ba7e时接受本地确定性拒绝会快速抛出带类型的错误Erc1271EoaMismatchNoCodeError、Erc1271EmptySigOnEoaError、Erc1271WrongMagicError、Erc1271RejectedError而非先往返 KMS。KMS 仍然是权威方并独立复核但这让本地失败路径更快更清晰。该检查替换了旧的仅 EOA 的verifyKmsUserDecryptEip712V2。类型定义在 sdk/js-sdk/src/core/errors/Erc1271Error.ts实现与测试分别在 sdk/js-sdk/src/core/utils-p/decrypt/verifyErc1271UserDecrypt-p.ts 与同名.test.ts覆盖空签名、EOA 无代码、错误 magic value、130 字节多签等多种分支并接入 sdk/js-sdk/src/core/kms/SignedDecryptionPermitV2-p.ts 的 V2 签发路径。自动协议版本解析与 WASM 版本选择零配置的默认路径v1.1.0-alpha.5v1.1.0-alpha.5 引入 RFC-005 的自动解析能力Fhevm客户端在初始化时读取链上宿主合约数据自动解析出protocolVersion字段ProtocolVersionResolution并据此自动挑选匹配的tfhe.wasm/kms_lib.wasm构建——常见场景无需任何配置。同版本还引入moduleVersions覆盖选项FhevmOptions以及更具体的FhevmEncryptOptions/FhevmDecryptOptions接受moduleVersions字段值为auto默认或显式的{ tfhe?, kms?, checkCompatibility? }供需要固定特定 WASM 构建的高级用户使用checkCompatibilitythrow | warn | off控制显式版本与链上协议预期不符时的行为。epochId跟踪RFC-005KMS 上下文中在现有 signer/threshold 数据之外携带epochId以支持在上下文内做密钥轮换的协议版本。内部实现与兼容性矩阵该能力的内部落点包括ProtocolVersionResolver与 resolveFhevmVersions-p.ts协议版本解析、semver 区间匹配配套单元测试ProtocolVersionResolver-p.test.ts/HyperWasmSolver-p.test.tsHyperWasmSolver从开放式SemverRangege/lt改为SemverIntervallowerBound/upperBoundv0.14.1-0使0.13.x/0.14.x协议窗口各自被精确表达而非依赖规则排序sdk/js-sdk/src/core/runtime/sdkProtocolApiVersion.ts 作为静态协议 API 版本常量详见上文新增 semver 解析工具模块core/base/semver.tsgetVersion更名为getHostContractVersion宿主合约 reader 中的泛型address字段改名为合约专属名aclAddress、fhevmExecutorAddress等。兼容性矩阵的权威来源是 sdk/js-sdk/docs/compatibility.md其中明确列出协议的 TFHE/KMS 对应关系v0.14.0 → TFHE 1.6.2 / KMS 0.14.0-1 / extraData v2、KMS 与tfhe-rscrate 的固定 pinning如 KMS0.13.20-0固定tfhe-rs 1.6.1、已部署链的 PubKey/CRS 版本以及 TFHE/KMS WASM 的 API 面清单。WASM 版本相关的缺陷修复TFHE 默认版本升级v1.1.0-alpha.2默认tfhe.wasm从1.5.3升至1.6.1默认tkms从0.13.10升至0.13.20-0。文档特别提醒这影响未显式配置版本时 SDK 预期的密钥/CRS 格式主要影响跑本地/开发链而非公开测试网的用户——relayer 的密钥材料可能不匹配新默认值。TFHE 1.6.2v1.1.0-alpha.6initTfheModule默认tfheVersion与HYPER_WASM_SOLVER_CONFIG兼容矩阵升级到1.6.2与最新 coprocessor 兼容的 TFHE 构建对齐。KMSthreshold传参修正v1.1.0-alpha.3WASM 侧解密重构调用process_user_decryption_resp_from_js不再显式传入从kmsSignersContext.threshold推导的threshold它与KMSVerifier.getThreshold()是不同的值改为留undefined以按服务器地址数量自动计算修复了两者分歧配置下的解密重构。extraData容错v1.1.0-alpha.1 / alpha.2v11 协议 relayer 响应省略extraData时不再被拒——校验前回填0xfromKmsExtraData()/assertIsKmsExtraData()同时接受裸0x空值。链配置与 cleartext 模式的持续扩展polygon / polygonAmoy 链定义v0.13.3 将polygonPolygon 主网chain id137与polygonAmoy加入fhevm/sdk/chainsv0.14.1-0 又为polygon补齐了acl/inputVerifier/kmsVerifier/protocolConfig与 gateway 地址并补上了mainnet此前未设置的protocolConfig地址。以 sdk/js-sdk/src/core/chains/definitions/polygon.ts 为例其结构为export const polygon: FhevmChain /*#__PURE__*/ defineFhevmChain({ id: 137, fhevm: { contracts: { acl: { address: 0x6737F17e31cf26a1b62fb0362acC5a16CB156F49 }, inputVerifier: { address: 0xf40BD204B035522EaAc8E5afAdc55113Acac96ca }, kmsVerifier: { address: 0x14e609595474874Dd6b6128376E336EfADfdBE37 }, protocolConfig: { address: 0x17f62Ab3A1Ea519703cD597410147A30Fa1a7f1e }, }, relayerUrl: https://relayer.mainnet.zama.org, gateway: { id: 261_131, contracts: { /* decryption / inputVerification 地址 */ } }, }, });v1.1.0-alpha.5 同时为 localTestnet、mainnet、sepolia、devnet 及 localstack 变体补上了ProtocolConfig合约地址并接入FhevmChain/HostContract类型与resolveFhevmConfig。cleartext 模式与 auth 类型导出cleartext 模式v1.1.0-alpha.1新增createFhevmCleartextClient、createFhevmCleartextBaseClient、createFhevmCleartextEncryptClient、createFhevmCleartextDecryptClient工厂从fhevm/sdk/ethers/cleartext与fhevm/sdk/viem/cleartext导出让应用可针对明文宿主合约如本地/开发测试运行无需完整 FHE 栈etherscleartext 工厂接受任意ethers.ContractRunner与非 cleartext 客户端一致可直接传 signer。forge-fhevm v1 兼容v0.13.3cleartext 客户端现在也支持本地forge-fhevmv1 部署——通过其著名的单一 KMS signer 地址检测 v1 部署并在链下重构 public-decrypt / user-decrypt / input-proof 结果从CleartextFHEVMExecutor.plaintexts读取原始明文并本地重算 EIP-712 摘要不依赖普通forge-fhevm部署不暴露的Cleartext*view 合约。参见 sdk/js-sdk/test/scripts/HOWTO_RUN_FORGE_FHEVM_V1.md。类型导出v0.13.3Auth、AuthType、AuthBearerToken、AuthApiKeyHeader、AuthApiKeyCookie从fhevm/sdk/types导出此前已支撑RelayerCommonOptions.auth但不可直接 importasEncryptedValue与isEncryptedValue在 v1.1.0-alpha.1 中正式导出。运行时兼容性Next.js、Turbopack 与 WASM 加载Turbopack/Next.js 支持修复v1.1.0-alpha.6Turbopack 无法静态分析 SDK 的动态import(node:worker_threads)会静默替换为抛Cannot find module unknown的桩导致 Next.js 服务端组件中多线程 TFHE 静默失效。修复方式为每个 Node 内置导入添加打包器专属 magic commentvite-ignore、webpackIgnore、turbopackIgnore使 Vite、webpack、Turbopack 均保留该导入原样恢复 Turbopack/Next.js 下的多线程 TFHE。新的 sdk/js-sdk/docs/runtime-compatibility.md 记录了完整支持矩阵浏览器、Node、Bun、Deno、Electron、Next.js CSR/SSR以及 Vercel Edge / Cloudflare Workers 不受支持的原因。WASM 解压与加载的鲁棒性DecompressionStream 探测某些运行时尤其 Next.js Edge Runtime全局存在DecompressionStream但构造时抛错。SDK 现在通过实际构造来探测可用性而非typeof判断不可用时回退到内置纯 JS inflater保证压缩内嵌 WASM 在受影响运行时与旧浏览器Firefox 113、Safari 16.4上仍可加载。wasmBaseUrl解析修复内部 URL 解析器不再被注入 Node 形状全局如被 shim 的__filename的打包器/浏览器环境误导先区分真实 Node CJS 与 browser-like / Bun 运行时再决定 WASM 资源 URL 的解析方式。内部实现上运行时/环境检测重构进 core/base/environment.tsisNodeLike、isBrowserLike、getNodeBuffer、getNodeFs、getNodeUrl、getNodeWorker、supportsWebWorkerApi、supportsDecompressionStream并新增纯 JS inflatercore/base/inflate.ts与Sha256VerificationError错误类型。打包体积优化v1.1.0-alpha.2发布的 npm 包排除vitest.config.ts与tsconfig.jsonv1.1.0-alpha.1修复noble/curvesv2.x 下内部sign()的 secp256k1 签名解析恢复字节从末位移到首位此前会破坏解密许可与委托请求的签名v0.14.1-0发布的 tarball 不再携带约 2 MB 的仅开发用wasm/tfhe/v1.6.0-dev/构建v0.15.0unreleasedtkmsWASM 版本目录与tfhe一样从发布的 tarball 排除通过src/package.json的files字段叠加 v0.14.1-0 已落地的 base64 WASM 负载去重。relayer 交互增强自定义 HTTP 头与严格 URL 校验v1.1.0-alpha.4RelayerCommonOptionsRelayerUserDecryptOptions、RelayerInputProofOptions等均继承它新增headers: Recordstring, string会合并进每一次 relayer 请求encryptValue()/encryptValues()、decryptValue()/decryptValues()、public decrypt便于附加自定义 API key 或追踪头。relayer base URL 现在前置解析与校验必须http:/https:、无内嵌凭据、无 query/fragment设置 auth 凭据时要求 HTTPS除非主机是 localhost。此前被容忍的畸形 URL 现在提前抛InvalidUrlError。所有传入 SDK 的头名/头值按 RFC 7230 规范化与校验小写化名字、拒绝 CR/LF/NUL 防头注入、对大小写冲突的重复头键抛错。认证与错误信息alpha.4 / alpha.5 / alpha.7API key 现在也随 relayerGET请求转发异步解密/加密任务轮询状态用 GET此前按设计省略了 auth修复了对每个请求都要求认证的 relayer 部署上的轮询失败。relayer/边缘返回 401relayer或 403Cloudflare/Kong 等边缘代理拦截时RelayerResponseStatusError新增Details:行携带服务器实际发送的消息取代硬编码的通用 unexpected status。v1.1.0-alpha.7 起relayer 错误响应识别新增not_allowed_on_host_acl400与insufficient_balance/insufficient_allowance503。v0.14.1-0 起配置的Logger贯穿 relayer 请求重试/节流/超时处理、FHE 加密密钥获取/缓存驱逐、WASM/协议上下文初始化失败等路径。缓存与探测优化v1.1.0-alpha.7KMS/coprocessor signer 上下文缓存从 24 小时缩短到 15 分钟链上 signer 轮换能更快被反映不可变的合约版本查询仍保留 24h 缓存。v0.14.1-0 修复了一个缓存 TTL 笔误CACHE_TTL_15MIN实际是15 * 1000ms15 秒而非 15 分钟导致 signer/threshold 读取被过度频繁重新拉取。v1.1.0-alpha.4 / alpha.5RelayerAsyncRequest重试/退避/轮询引擎与readErrorMessage()最佳努力 JSON 错误体读取器均有配套单元测试。破坏性变更与迁移速查以下是本系列版本中面向 SDK 用户的最关键破坏性变更汇总变更出现版本迁移动作durationDays→durationSecondsv1.1.0-alpha.7durationSeconds: 7 * 24 * 60 * 60signDecryptionPermit统一签名、self/delegated 重载合并v1.1.0-alpha.7委托时传delegatorAddress省略则自签低层 EIP-712 / signer-context / input-proof 导出移除v1.1.0-alpha.7按官方替换表改用signDecryptionPermit()、encryptValue(s)、decryptValue(s)等高层 action如createKmsUserDecryptEip712→signDecryptionPermit()、fetchKmsSigncryptedShares→decryptValue(s)readPublicValue*→decryptPublicValue*v1.1.0-alpha.2client.decryptPublicValue({ encryptedValue })KmsDecryptEip712Like→Eip712Likev1.1.0-alpha.5更新fhevm/sdk/types引用signDecryptionPermit不再从actions/base导出v0.13.3使用createUnsignedLegacyDecryptionPermitEip712/signLegacyDecryptionPermit或client.signLegacyDecryptionPermit(...)serializeTransportKeyPair()/serializeSignedDecryptionPermit()变 asyncv0.13.3调用处补awaitTransportKeyPair.tkmsVersion→string \| undefinedv0.13.3反序列化后的密钥对版本动态解析勿假设固定测试与验证路径对应的 e2e/单元覆盖包括v0.14.1-0 的 ERC-1271/多签 e2eSafe 风格多签 mock、unified permits 单元套件、extraDatav2 套件、HyperWasmSolver区间规则套件v1.1.0-alpha.1 起构建了test/browser-next/真实 Next.js Turbopack/webpack CSR/SSR 构建与test/infra/harness测试目录test/browser更名为test/browser-smokev0.14.1-0dod.sh更名为run-tests.sh。你可以通过仓库中的 sdk/js-sdk/src/core/kms/SignedDecryptionPermitV2-p.test.ts 与 sdk/js-sdk/src/core/utils-p/decrypt/verifyErc1271UserDecrypt-p.test.ts 继续深入阅读对应测试。内部工程与交付质量CI/SDLC 加固v0.14.1-0license-checker白名单接入npm run dod、新增 Trivy SCA 扫描工作流、Dependabot 纳入 npm、README 补充外部贡献政策dev 工具链固定到精确版本eslint、typescript、typescript-eslint、vitest、wasm-feature-detect 等。供应链安全v0.13.3移除relayer-sdk-test测试应用针对 TanStack npm 供应链事件e2e 套件此后仅依赖fhevm/sdk不再依赖zama-fhe/relayer-sdk。结构重构v0.13.3新增FhevmClientFrozenContext抽象core/frozenContext/合并原先分别跟踪的 protocol/tfhe/tkms 版本字段每 client 解析一次、跨并发 init 去重以单一不可变版本基础贯穿内部 helpersKMSextraData处理重构为kmsExtraData-p.tsgetSignersForKmsContext-p.ts并入KmsSignersContext-p.ts/readKmsSignersContext-p.ts。文档体系v0.13.3docs/大规模重写README、GLOSSARY、SUMMARY、api-reference、architecture、chains、clients、decryption、encryption、getting-started、migration、runtime-configuration、security、types新增actions.md与error-handling.md替代 errors.md、runtime-compatibility.md另有scripts/list-sdk-exports.mjs静态审计公共 API 面、DRAFT_RFC_016.md设计文档。测试基础设施v1.1.0-alpha.2多 localstack 支持localstack_v11/v12/v13/v14链配置、fhevm-info.sh、chain-defaults.json清单test:localstack:v11等 npm 脚本test/scripts/fhevm-info.sh转为.mjsv1.1.0-alpha.7fhetest-deploy.sh在未部署ProtocolConfig的链localstack_v11/v12、v0.13.0 之前打印占位符而非失败setupCommon.ts中 Foundrycast强制 30s 超时避免 Anvil RPC 卡死v0.15.0。小结纵观 sdk/js-sdk/docs/release-notes.md 记录的这段演进fhevm/sdk 的发展主线清晰可辨协议侧跟随链上 FHEVM 协议从 v11 稳步推进到 v15并通过SDK_PROTOCOL_API_MINOR_VERSION编译期常量与运行时protocolVersion解析的配合实现一个 SDK 客户端、自动适配多协议链API 侧将解密许可从分裂的 self/delegated 重载收敛为统一入口再演进到 V1/V2 运行时路由与 ERC-1271 钱包签名配套canUseUnifiedDecryptionPermit能力探测避免对旧 relayer 的错误调用工程侧则持续在打包体积、运行时可移植性Turbopack/Edge、缓存正确性与 CI 安全上加固。对集成方而言升级前先对照破坏性变更与迁移速查表、确认目标链的协议版本与默认 WASM 版本是否匹配参考 sdk/js-sdk/docs/compatibility.md并借助moduleVersions完成显式固定即可平滑跟随这套版本体系。【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考