fhEVM JS SDK 多 WASM 版本浏览器测试矩阵基于 Playwright 的 multi-wasm 测试套件设计与实现【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm本文是 fhEVM JS SDK 中多 WASM 版本Multi-WASM测试计划的落地指南围绕 notes/TEST_PLAN.md 阐述如何用 Playwright 构建一套覆盖全部 WASM 配置组合的浏览器测试矩阵并深入解析仓库中已实现的 test/multi-wasm 套件包括 JSON 测试矩阵与 schema、五种wasmAssetLoadMode加载模式、CLI 坐标筛选、FHETest 加解密往返链路以及 localstack 生命周期管理。读完本文你将能理解并独立运行这套多版本共存回归测试并掌握为多版本 WASM 模块编写矩阵化浏览器测试的完整方法。背景为什么需要多 WASM 版本测试fhEVM JS SDK 在浏览器中通过 WASM 完成同态加密操作加密Encrypt侧依赖TFHE模块src/wasm/tfhe解密Decrypt侧依赖TKMS模块src/wasm/tkms。仓库中同时保留了多个版本的 WASM 产物TFHEv1.5.3、v1.6.0-dev、v1.6.2TKMSv0.13.10、v0.13.20-0、v0.14.0-1多版本并存的根本原因是格式兼容性docs/compatibility.md 明确指出tfhe.wasmv1.5.3无法解析由tfhe.wasmv1.6.2产生的 PubKey/CRS且序列化格式在 minor 版本之间不向前兼容。链上或 Relayer 侧没有直接信号告知 SDK 当前链需要哪个版本的tfhe.wasm因此 SDK 只能通过协议上下文ACL 合约版本 PubKey/CRS 版本做启发式推断。由此带来的问题非常现实不同链、不同协议版本需要不同组合的 WASM 模块而同一页面/同一 JS realm 内可能同时存在多个版本的模块——这正是多 WASM 测试要覆盖的核心风险面。notes/TEST_PLAN.md的定位十分明确它只聚焦新的多 WASM 支持多版本支持这一项能力要求建立一套覆盖所有可能 WASM 配置的完整测试套件测试矩阵定义在 JSON 文件中并且可以跑在真实浏览器页面中。测试计划核心要求速览原测试计划提出了一组清晰的验收条件它们全部在 test/multi-wasm 中得到了落地实现计划要求落地位置测试矩阵定义在 JSON 文件中matrix.json matrix.schema.json套件位于./test/multi-wasmtest/multi-wasm使用 Playwright 且可在浏览器页面运行playwright.config.ts、roundtrip.html每个测试执行一次加密/解密往返scripts/roundtrip.ts每个测试使用全新页面一个页面无法运行多个 FhevmRuntimespecs/roundtrip.spec.ts 中每个test()独立page.goto复用/重启 localstackanvil 已在跑则跳过耗时重启support/localstack.ts scripts/localstack-restart.sh支持--tfhe、--kms、--mode运行单个矩阵坐标run.mjs测试wasmAssetLoadMode各模式五种模式全量枚举见下文测试 CDN 场景URL 写进 JSONassetUrlSets中的jsdelivr、unpkg一个值得注意的版本演进计划初稿给出的首版矩阵为tfhe 1.5.3 tkms 0.13.10与tfhe 1.6.1 tkms 0.13.20-0而当前 matrix.json 实际落地为tfhe 1.6.2 tkms 0.13.20-0SDK 源码中保存的是v1.6.2而非v1.6.1并额外增加了tfhe 1.6.2 tkms 0.14.0-1与仅限本地 CDN 的tfhe 1.6.0-dev行。这说明矩阵本身是持续演进的配置数据——这正是矩阵放在 JSON 中设计价值的体现。测试矩阵的 JSON 设计matrix.json版本对 × 资产 URL 模板matrix.json 是整个套件的配置核心其结构分三层{ $schema: ./matrix.schema.json, schemaVersion: 1, defaults: { roundTrip: { clearType: uint8, contractMethod: setEuint8, makePublic: true, value: 42 } }, supportedVersionPairs: [ { tfhe: 1.5.3, kms: 0.13.10 }, { tfhe: 1.6.2, kms: 0.13.20-0 }, { tfhe: 1.6.2, kms: 0.14.0-1 }, { tfhe: 1.6.0-dev, kms: 0.13.20-0, cdns: [local] } ], assetUrlSets: { local: { tfheWasm: /src/wasm/tfhe/v{tfhe}/tfhe_bg.wasm, tfheWorker: /__raw_wasm/src/wasm/tfhe/v{tfhe}/tfhe-worker.mjs, kmsWasm: /src/wasm/tkms/v{kms}/kms_lib_bg.wasm }, jsdelivr: { tfheWasm: https://cdn.jsdelivr.net/npm/tfhe{tfhe}/tfhe_bg.wasm, tfheWorker: /__raw_wasm/src/wasm/tfhe/v{tfhe}/tfhe-worker.mjs, kmsWasm: https://cdn.jsdelivr.net/npm/tkms{kms}/kms_lib_bg.wasm }, unpkg: { tfheWasm: https://unpkg.com/tfhe{tfhe}/tfhe_bg.wasm, tfheWorker: /__raw_wasm/src/wasm/tfhe/v{tfhe}/tfhe-worker.mjs, kmsWasm: https://unpkg.com/tkms{kms}/kms_lib_bg.wasm } } }设计要点supportedVersionPairs声明所有受支持的 TFHE/TKMS 版本组合。每行可带可选的cdns白名单——tfhe 1.6.0-dev只允许本地 CDN因为 dev 版本不会发布到公共 CDN。assetUrlSets按 CDN 分组定义三件套资产 URL 模板TFHE wasm、TFHE worker、KMS wasm使用{tfhe}、{kms}占位符在运行时由 support/matrix.ts 的renderAssetUrlTemplate替换成具体版本号。这正是测试计划中在 JSON 文件中加入 CDN 测试 URL的落地。defaults.roundTrip全局默认的往返参数——本轮默认加密uint8类型、值42调用FHETest.setEuint8并开启makePublic同时验证公开解密路径。matrix.schema.json矩阵的契约matrix.schema.json 基于 JSON Schema Draft 2020-12为矩阵数据定义了严格的类型契约顶层必需字段schemaVersion必须是常量1、defaults、supportedVersionPairsminItems: 1、assetUrlSetsversionPair必需tfhe与kms均为 string可选cdnsstring 数组minItems: 1、uniqueItems: trueassetUrlSets对象必须至少包含local且每个assetUrlSet必需tfheWasm、tfheWorker、kmsWasm三个 URL 字符串roundTripclearType枚举bool/uint8/uint16/uint32/uint64/uint128/uint256/addresscontractMethod枚举对应的setEbool…setEaddressvalue允许 boolean/integer/string。schema 的约束在运行时还会被 support/matrix.ts 的validateMatrix/validateAssetUrlSets二次校验版本对不允许重复以tfhe\0kms为 key 去重、cdns引用的 CDN 必须真实存在于assetUrlSets、assetUrlSets必须包含local等。笛卡尔积生成与坐标筛选support/matrix.ts 是矩阵的运行时大脑两个核心函数generateMatrixEntries(matrix)对每个版本对 × 每种wasmAssetLoadMode× 每个 CDN 做笛卡尔积生成带id形如tfhe-1.5.3__kms-0.13.10__verified-blob__local和label的矩阵条目。注意两个例外规则embedded-base64模式只与localCDN 组合其资产内嵌在 SDK 包中天然没有 CDN 概念版本对声明了cdns白名单时只取白名单内的 CDN。selectMatrixEntries(matrix, selection)按tfhe/kms/mode/cdn四个坐标过滤条目一个坐标都没命中会抛出列出全部可用条目的错误——这正是运行单个矩阵坐标的底层机制。版本号统一经normalizeModuleVersion处理接受v前缀如v1.5.3与1.5.3等价。wasmAssetLoadMode五种加载模式全解析测试计划明确要求覆盖verified-blob、precheck-direct-url等加载模式。这些模式的权威定义在 src/core/types/wasmAssets.ts 的类型注释中五种取值及其语义如下模式传输方式Blob 封装SHA-256 校验行为说明embedded-base64base64 内嵌是否读取内置于 SDK 模块的 base64 worker 源码浏览器中解码为 Blob URL 后创建 module workerverified-blobURL是是先从 URL 拉取字节并做 SHA-256 校验复用已校验缓存然后把这些精确字节作为 Blob worker浏览器/ eval workerNode执行——真正的一致性保证precheck-direct-urlURL否是预检先取一次 URL 校验哈希实现 fail-fast但随后把 URL 直接交给运行时二次拉取执行——两次拉取相互独立执行的字节并未被校验。注释明确警告这不是完整性检查只用于快速暴露配置错误/构建不匹配trusted-direct-urlURL否否直接把配置的 worker URL 交给浏览器/Node 运行时加载执行不做任何 SDK 侧字节校验auto———若配置了workerUrl则先用verified-blob尝试失败或未配置则回退embedded-base64理解这五种模式是读懂负向测试的前提verified-blob是唯一把校验过的字节真正交给执行器的模式因此它必须对 SHA-256 失配负责trusted-direct-url是唯一裸 URL直连模式因此它对 COOP/COEP 响应头最敏感详见负向测试一节。在 scripts/roundtrip.ts 中模式通过 URL 查询参数mode传入并做白名单校验随后通过setFhevmRuntimeConfig({ wasmAssetLoadMode, locateFile })注入运行时配置const WASM_ASSET_LOAD_MODES [ auto, embedded-base64, verified-blob, precheck-direct-url, trusted-direct-url, ]; // ... if (!WASM_ASSET_LOAD_MODES.includes(mode as WasmAssetLoadMode)) { throw new Error(Unknown wasmAssetLoadMode: ${mode}); } if (mode embedded-base64 cdn ! LOCAL_CDN) { throw new Error(embedded-base64 is incompatible with cdn ${cdn}); }非内嵌模式下资产 URL 由resolveAssetUrls按 CDN 模板渲染再通过locateFile回调把 SDK 请求的文件名如tfhe_bg.v1.5.3.wasm、tfhe-worker.v1.5.3.mjs、kms_lib_bg.v0.13.10.wasm映射到具体 URLembedded-base64模式则不给locateFile走 SDK 内嵌资产。CLI 运行器按矩阵坐标精确筛选run.mjs 是整个套件的统一入口通过 npm scripttest:localstack:multi-wasm:full见 package.json调用。其设计思路是所有标志都是对自动生成矩阵的独立过滤器省略某个标志即运行该轴上的全部取值Usage: npm run test:multi-wasm -- [options] [-- playwright args] Options: --restart-localstack 重启 localstack 后再运行浏览器套件 --fhevm-cli-profile name 透传给 localstack-restart.sh 的 profile 文件名 --tfhe version 按 TFHE 版本过滤接受前导 v --kms version 按 TKMS 版本过滤接受前导 v --mode mode 按 wasmAssetLoadMode 过滤 --cdn cdn 按 CDN 过滤默认所有 CDN -h, --help 显示帮助典型用法示例来自脚本内置帮助文本# 全量运行所有矩阵条目 npm run test:localstack:multi-wasm:full # 只跑 tfhe 1.5.3 kms 0.13.10 的全部条目 npm run test:multi-wasm -- --tfhe 1.5.3 --kms 0.13.10 # 该版本对 本地 CDN 的所有加载模式 npm run test:multi-wasm -- --tfhe 1.5.3 --kms 0.13.10 --cdn local # 精确到单个坐标一个模式 一个 CDN npm run test:multi-wasm -- --tfhe 1.5.3 --kms 0.13.10 --mode verified-blob --cdn jsdelivr # 强制重启 localstack 并指定协议 profile npm run test:multi-wasm -- --restart-localstack --fhevm-cli-profile v0.11.0-mainnet.json # 透传 Playwright 参数如 headed 模式 npm run test:multi-wasm -- --mode auto --cdn local -- --headedCLI 的校验逻辑值得注意--mode必须是五种模式之一--cdn必须存在于matrix.json的assetUrlSets--mode embedded-base64与--cdn非 local互斥直接报错--fhevm-cli-profile必须搭配--restart-localstack使用。解析出的筛选条件会写入环境变量MULTI_WASM_TFHE_VERSION、MULTI_WASM_KMS_VERSION、MULTI_WASM_MODE、MULTI_WASM_CDN、MULTI_WASM_RESTART_LOCALSTACK、MULTI_WASM_FHEVM_CLI_PROFILE随后以stdio: inherit方式 spawnnpx playwright test --config test/multi-wasm/playwright.config.ts过滤逻辑在 specs/roundtrip.spec.ts 中通过读取这些环境变量生效。FHETest 加解密往返页面页面入口与参数协议pages/roundtrip.html 加载 scripts/roundtrip.ts后者是每个矩阵坐标对应的浏览器执行体。测试计划要求每个测试执行一次加解密往返与既有 fheTest 文件一致页面通过 8 个查询参数描述一个矩阵坐标tfhe / kms / mode / cdn / chainName / rpcUrl / mnemonic / fheTestAddress往返主链路roundtrip.ts的run()按如下顺序执行完整往返对照既有fheTest测试形态解析并校验坐标读取查询参数校验mode合法性、embedded-base64 × CDN兼容性并从/test/multi-wasm/matrix.json加载矩阵、校验tfhe/kms是否为受支持版本对配置运行时setFhevmRuntimeConfig({ wasmAssetLoadMode, locateFile, logger })其中locateFile通过文件名映射表把版本化资产请求路由到 CDN 模板渲染出的 URL出现未预期的资产请求会直接报错解析链配置用import.meta.glob按chainName从test/chains/localstack*.ts动态加载对应链配置并用 COEP 安全的 Vite 代理地址/__localstack_relayer覆盖relayerUrl解决 MinIO 问题创建客户端createFhevmClient({ chain, provider, options: { moduleVersions } })其中moduleVersions { tfhe, kms }显式固定版本覆盖自动路由保证测试确定性地落在指定坐标上await client.ready完成 WASM 模块加载与 worker 启动加密client.encryptValues({ contractAddress, userAddress, values: [typedValue] })生成密文与inputProof上链调用FHETest.setEuint8(inputHandle, inputProof, clearValue, makePublic)并等待交易收据receipt.status ! 1即判失败私有解密generateTransportKeyPair()生成传输密钥对signLegacyDecryptionPermit(...)签名解密许可decryptValues(...)取回明文并断言与原值一致公开解密若矩阵默认makePublic: true再走decryptPublicValues断言公开解密结果输出结果全部通过时在 DOM 写入div idresult>const matrix loadMatrix(); const entries selectMatrixEntries(matrix, { tfhe: process.env.MULTI_WASM_TFHE_VERSION, kms: process.env.MULTI_WASM_KMS_VERSION, mode: process.env.MULTI_WASM_MODE, cdn: process.env.MULTI_WASM_CDN, }); for (const [entryIndex, entry] of entries.entries()) { test(multi-WASM encrypt/decrypt round-trip: ${entry.label}, async ({ page }) { // ...构建查询参数page.goto(roundtrip.html?tfhe...kms...mode...cdn...) await page.goto(/test/multi-wasm/pages/roundtrip.html?${query.toString()}); const result page.locator(#result); await result.waitFor({ timeout: 600_000 }); expect(await result.getAttribute(data-status)).toBe(pass); }); }实现细节与测试计划的对应关系每个测试一个全新页面Playwright 默认每个test()获得独立page与浏览器上下文天然满足一个页面无法运行多个 FhevmRuntime、必须 fresh page的要求套件级进度报告spec 订阅页面console消息前缀[multi-wasm]并通过ENTRY_PROGRESS_MILESTONES把页面日志行Matrix entry:→Creating FHEVM client→Encrypting→Private decrypting→Public decrypting→All checks passed映射为 0~100% 的条目进度实时打印形如[suite 42.0% | entry 3/8]的进度行若页面未输出实时日志则失败时回退打印#log完整内容便于排查600 秒超时多 WASM 初始化与加密是重计算timeout: 600_000与result.waitFor保持一致单 worker 串行playwright.config.ts 设置workers: 1、仅 Chromium 项目保证多个矩阵条目不会互相干扰也避免同时打爆 localstack。Localstack 生命周期优先复用按需重启测试计划强调两点套件必须对localstack-restart.sh运行若 localstack 已在运行则不要重启非常耗时。这一策略在三个文件中分层实现global-setup启动前就绪检查global-setup.ts 读取环境变量const restart process.env.MULTI_WASM_RESTART_LOCALSTACK 1; const chainName process.env.CHAIN ?? localstack; const { rpcUrl } loadLocalstackChainDefaults(chainName); await ensureLocalstackReady({ restart, rpcUrl, chainName, fhevmCliProfile });ensureLocalstackReady两级判定support/localstack.ts 的判定逻辑若restarttrue先以--force --chain chainName以及可选的--fhevm-cli-profile运行localstack-restart.sh通过向rpcUrl发eth_chainIdJSON-RPC POST 检查 anvil 是否存活isJsonRpcReady若已就绪直接返回若未就绪且未要求重启抛出明确错误Start it first, or rerun with --restart-localstack若重启后仍无响应则报still not responding after restart。localstack-restart.sh守护脚本scripts/localstack-restart.sh 是守护脚本本体默认端口8545、RPChttp://127.0.0.1:8545支持--force/-f、--chain/-clocalstack、localstack_v11~localstack_v14、--fhevm-cli-profile、--dry-run/-n等选项。其核心策略与测试计划完全一致默认无--force若 anvil 正在8545端口监听则只做健康校验——读取chain-defaults.json解析FHETest地址cast code确认有字节码、cast call CONTRACT_NAME()确认是FHETestv2——全部通过即退出 0不重启若端口被非 anvil 进程占用则报错退出无进程则走完整启动--force先fhevm-cli down再fhevm-cli up [--lock-file profiles/profile]然后forge clean并执行./scripts/fhetest-deploy.sh --chain chain重新部署 FHETest最后再次校验部署。链的 RPC 地址、助记词与 FHETest 合约地址统一维护在 test/chains/chain-defaults.jsonlocalstack系列默认http://localhost:8545、测试助记词、0x61a8e950...由 support/chainDefaults.ts 读取助记词缺省时回退到test/.env或MNEMONIC环境变量对应测试计划中localstack 使用专用 RPC URL的要求实现上统一收敛到了 chain-defaults.json 与.env。版本自动路由与测试目标的衔接虽然 multi-wasm 矩阵用moduleVersions: { tfhe, kms }显式固定版本但理解 SDK 的自动路由机制能帮你判断这些版本为什么需要共存。自动路由实现在 src/core/runtime/HyperWasmSolver-p.ts它根据解析出的协议上下文protocolVersionpubKeyCrsVersion命中兼容规则表协议版本区间PubKey/CRS 版本TFHE 版本TKMS 版本 0.13.0 1.6.01.5.30.13.10[0.13.0, 0.14.0) 1.6.01.6.20.13.20-0[0.13.0, 0.14.0) 1.6.01.6.20.13.20-0 0.14.0 1.6.01.6.20.14.0-1 0.14.0 1.6.01.6.20.14.0-1该表以compatibilityRules常量的形式内联在源码中规则要求区间互斥否则自动解析直接抛错。每条规则还声明compatible白名单例如协议0.13.x下显式指定 TFHE1.5.3仍然合法但必须通过兼容性检查——src/core/types/moduleVersions.ts 定义了checkCompatibility: throw | warn | off三种策略throw默认在不兼容时直接抛错warn仅告警off跳过检查。分辨率优先级源码注释明确说明客户端选项moduleVersions: auto强制走协议自动解析且故意忽略运行时回退客户端选项moduleVersions.tfhe/kms优先于一切回退再对照白名单检查运行时全局配置moduleVersions作为回退否则从解析出的协议上下文自动解析。由此可以推出矩阵测试中显式指定1.5.3 0.13.10与1.6.2 0.13.20-0等组合等价于验证了同一 JS realm 内、多个协议时代的 WASM 模块必须能够同时存活而 test/MULTI_WASM_TEST_PLAN.md 则将这一目标细化为专门的共存coexistence计划见下文。负向测试留待独立套件的未来工作测试计划明确将负向测试排除在 happy-path 矩阵之外作为独立套件的未来工作并给出两个必须覆盖的场景无效 KMS SHA当服务器提供的kms_lib_bg.wasm字节与期望的 SHA-256 不一致时wasmAssetLoadMode: verified-blob必须在日志中报SHA-256 mismatch而失败。这直接对应verified-blob校验后执行的语义——它是唯一真正把校验过的字节交给执行器的模式缺失 COOP/COEP 响应头本地模式当托管 worker 脚本的服务器没有设置Cross-Origin-Opener-Policy: same-origin和Cross-Origin-Embedder-Policy: require-corp以及/或Cross-Origin-Resource-Policy: same-origin时wasmAssetLoadMode: trusted-direct-url必须给出清晰、可操作的错误而不是当前的通用Worker error而其余模式embedded-base64、verified-blob、precheck-direct-url、auto在同样的破损响应头配置下仍应成功——因为它们都把 worker 字节封装进 Blob URL绕过了 COEP 限制。这两个场景与 src/core/types/wasmAssets.ts 中五种模式的注释一一对应可作为实现负向套件时的验收基准。注意负向测试不属于support/matrix.ts 的笛卡尔积生成器需要独立编排。延伸共存coexistence与鲁棒性测试同一目录树下的 test/MULTI_WASM_TEST_PLAN.md 是 multi-wasm 矩阵的姊妹计划聚焦同一 JS realm 内多版本模块共存的更深层能力与notes/TEST_PLAN.md互补。它的核心结论之一是生命周期边界已加载的 WASM 模块应被视为JS realm 生命周期资源——TFHE 多线程 worker 启动是每个生成模块版本的一次性操作终止后再初始化同一版本在同一 realm 中不受支持因此 SDK 的支持范围是一个 JS realm 可以在其生命周期内并行运行 N 个受支持版本的给定 WASM 模块而不支持同 realm 内的卸载/重启/替换。该计划给出了分层测试金字塔单元 Vitest → Node 集成worker_threads→ 浏览器 Playwright smoke和分阶段实施路径版本路由单测 → 单版本 smoke → Node 双客户端并行共存 → 跨版本污染防护 → 轻量浏览器共存并提出了资源断言基线显式配置numberOfThreads推荐 1 或 2、每个 TFHE 模块上报精确线程数、多线程场景下浏览器必须crossOriginIsolated true。其实现在 test/browser-smokemultiWasmHarness.ts 集中了运行时配置wasmAssetLoadMode: verified-blob、singleThread: false、numberOfThreads: 1、双 TFHE1.5.3、1.6.2 三 TKMS0.13.10、0.13.20-0、0.14.0-1模块的并发初始化、就绪断言threadsAvailable、URL-backed 资产、dummy 链构造与密钥注入test/keys/key.1.4.0-alpha.3.json、key.1.5.4.json、key.1.6.1.json等公共能力smoke-coexistence.ts 构造了(模块版本 × 提供的密钥格式)兼容矩阵如1.5.3 key.1.6.1必须失败、1.6.2 key.1.6.1必须成功并基于TFHE-rs 序列化格式向前兼容、不向后兼容的规律对每个链定义shouldRun期望随后用Promise.all并发执行全部迷你加密再按定义顺序做确定性断言smoke-coexistence.spec.ts 将显式多线程共存 smoke 限定为 Chromium-only跨浏览器 smoke 保持单版本/单线程保证廉价与确定性。MULTI_WASM_TEST_PLAN 还规划了四个鲁棒性测试跨模块对象拒绝模块 A 的对象不能用于模块 B且拒绝后两个模块仍健康、并发幂等初始化风暴同版本并发 init 必须折叠为单一模块与单一 worker 池——对一次性 TFHE worker 尤其危险、单槽位缓存竞争与失败后恢复利用globalFheEncryptionKeyCache的_pendingChained待定链式合并、交错轮询耐力交替使用1.5.3/1.6.2与 TKMS 操作监测跨模块状态漂移与内存增长把内存视为高水位预算而非收缩检查。快速上手如何运行这套测试前置条件仓库已安装依赖sdk/js-sdk下npm install本地可访问test-suite/fhevm的 fhevm-cli 环境与 Foundrylocalstack-restart.sh会调用fhevm-cli up/down与forge clean。# 1. 在 sdk/js-sdk 目录下全量运行矩阵localstack 已在跑则自动跳过重启 npm run test:localstack:multi-wasm:full # 2. 单坐标排查只跑某个版本对 某个加载模式 npm run test:localstack:multi-wasm:full -- --tfhe 1.5.3 --kms 0.13.10 --mode verified-blob --cdn local # 3. 需要强制重启 localstack 并指定协议 profile 时 npm run test:localstack:multi-wasm:full -- --restart-localstack --fhevm-cli-profile v0.13.0.json # 4. 浏览器共存 smoke npm run test:browser-smoke运行中可通过 Playwright 控制台观察套件级进度行失败时页面#log会给出从矩阵条目、运行时配置、加密、上链、解密到断言的全链路日志data-statusfail与堆栈信息会一并回传。参考文件索引测试计划notes/TEST_PLAN.md、test/MULTI_WASM_TEST_PLAN.md矩阵与 schematest/multi-wasm/matrix.json、test/multi-wasm/matrix.schema.json矩阵引擎与运行器test/multi-wasm/support/matrix.ts、test/multi-wasm/run.mjs浏览器往返链路test/multi-wasm/scripts/roundtrip.ts、test/multi-wasm/specs/roundtrip.spec.ts、test/multi-wasm/playwright.config.tslocalstack 管理test/multi-wasm/global-setup.ts、test/multi-wasm/support/localstack.ts、test/scripts/localstack-restart.sh、test/chains/chain-defaults.json加载模式与版本路由src/core/types/wasmAssets.ts、src/core/runtime/HyperWasmSolver-p.ts、src/core/types/moduleVersions.ts版本兼容表docs/compatibility.md浏览器共存 smoketest/browser-smoke/scripts/multiWasmHarness.ts、test/browser-smoke/scripts/smoke-coexistence.ts、test/browser-smoke/specs/smoke-coexistence.spec.ts测试密钥资产test/keyskey.1.4.0-alpha.3.json、key.1.5.4.json、key.1.6.1.json小结notes/TEST_PLAN.md所描述的多 WASM 测试计划在仓库中已经是一套可运行的完整工程JSON 矩阵驱动、schema 约束、Playwright 浏览器执行、五种wasmAssetLoadMode全覆盖、CDN 资产模板化、CLI 坐标筛选、localstack 智能复用以及为未来负向测试预留的明确接口。这套设计既回答了多版本 WASM 如何在真实浏览器中回归验证也为verified-blob等加载模式的安全性SHA-256 校验、COOP/COEP 隔离提供了可观测的验证载体。无论你是要为新版本对扩展矩阵、为某个加载模式定位问题还是要补全负向测试都可以从 test/multi-wasm 这个坐标体系出发按版本对 × 加载模式 × CDN三个维度精确投放测试。【免费下载链接】fhevmFHEVM, a full-stack framework for integrating Fully Homomorphic Encryption (FHE) with blockchain applications项目地址: https://gitcode.com/GitHub_Trending/fh/fhevm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考