当前位置：首页 → 资讯 → 软件资讯 → Google向银行推MPC数字资产签名服务，2027年初目标上线意味着什么

Google向银行推MPC数字资产签名服务，2027年初目标上线意味着什么

发布时间：2026/10/12 9:51:40来源：游吧乐编辑

Google面向银行展示的多方签名服务，把数字资产安全问题从一把完整私钥扩展到了跨环境协作、审批和恢复流程。服务仍处私有预览，2027年初是目标时间；密钥分散能降低部分单点风险，最终授权与治理责任却仍需要机构承担。[1][2]

银行收到的是签名基础设施方案，产品仍在预览

2026年10月28日20时35分（美国东部时间），Unchained报道Google Cloud向银行展示Google Multi-Party Compute数字资产签名服务：密钥份额可以分布在银行自己的硬件、Google Cloud和其他云环境，服务处于私有预览，目标于2027年初进入广泛可用阶段。本稿于10月30日读取了该报道，以及Google官方概览和发布说明。[1][2][3]

官方概览更新日期为10月27日，页面仍标为Preview，并说明预正式发布产品按现状提供、支持可能有限。它将Multi-party Compute定义为数字资产签名密钥的托管平台，组合门限签名、交易策略和企业治理控制。[2] 因而，2027年初是报道中的目标时间，不能写成已经正式商用，也不能改写成已向所有银行开放。

“托管”在这里还需要分层理解。Google为密钥生成、份额保存和交易授权提供基础设施，与银行作为客户资产托管人承担的法律义务不是同一件事。本次资料没有证明Google因此取得某个法域的银行托管牌照，也没有证明使用该服务的银行自动具备所有数字资产经营资格。技术能力、客户合同和监管许可需要分别核实。

真实图片说明

图注：核验来源的原文摘录排版，非网页截图；完整出处见文末资料来源。

新进展在于把门限签名接入企业治理

根据官方概览，独立且有硬件保护的参与方分别生成并持有隔离的密钥份额，在签名时共同运行协议，无须在一个位置组装完整私钥。攻击者若控制的参与方少于签名门限，就不能伪造签名或重建密钥；在仍有足够参与方达到门限时，个别参与方暂时不可用或永久失效，也不必立即停止签名。[2]

这改变了银行设计安全架构的取舍。把完整密钥复制到多处，可以提高可用性，却也增加可以独立失陷的副本；门限机制允许分散故障和攻击风险，但前提是份额、权限和恢复流程真的具有独立性。不同地理位置未必意味着独立控制，同一管理员能够接管多个环境时，形式上的分散可能高估实际防护。

Binance全球顶级交易所 v3.22.3

类型：金融理财大小：306.0M语言：多国语言[中文]时间：10-25评分：10.0

官方文档将用户角色分为Admin、Policy Author和Signer，并说明API调用权限与实例内部角色共同作用；团队、KeyRing和KeyPolicy进一步规定谁持有份额、签名需要多少参与者以及份额存放位置。[2] 银行需要评估的因此不仅是加密算法，还包括谁能新增人员、修改策略、批准异常交易，以及这些权力是否被不恰当地集中。

Unchained报道提及银行自有硬件、Google及竞争云之间的分布式安排。[1] 这对减少对单一基础设施提供商的依赖有吸引力，但具体部署仍须确认所选组合能否实际运行、如何维护和恢复。报道描述的架构设想不能替代客户环境测试，也不能从中推导出任意云之间已经具备相同的服务保证。

一个容易被标题漏掉的细节：拒绝意见能够被覆盖

官方概览说明，交易策略使用Cedar规则，可以设置支出上限或目标地址允许名单。规则会对交易给出允许或拒绝的判断，但该结果指导签名者，并不强制决定最终结果；如果足够多的签名者批准，自动策略拒绝的交易仍可以执行。[2]

这一点决定了“策略保护”的准确含义。若机构希望设置绝对不可绕过的限额，就不能仅凭产品具有策略引擎，认定任何超额付款都必定失败。它需要进一步检查签名者权限、异常审批与内部控制如何衔接。人为覆盖可以为紧急处置保留空间，也会让足够多签名者的串通或共同误判成为必须管理的风险。

假设一笔付款目标因尚未加入允许名单而被拒绝，授权人员可能有合理原因批准；但如果攻击者利用相同的例外流程诱导批准错误地址，门限签名仍可能忠实地产生有效交易。这是根据官方行为说明推演的风险情景，并非报道中的真实事故。加密协议保护签名过程，不会自动判断商业指令是否合理。

支持算法的更新，不能等同于所有链已就绪

10月1日的官方发布说明记录，产品增加了使用Curve25519密钥、按标准Ed25519挑战哈希生成分布式Schnorr签名的能力。8月的条目也显示，该预览产品持续调整API校验、策略和交易数据处理。[3] 这些记录证明产品确实在迭代，却不是完整生产环境已经验收的证据。

读取到的概览将ECDSA与比特币、以太坊及EVM兼容链对应，将EdDSA与Solana对应，但Solana旁仍写着“coming soon”。[2] 因而不能仅因底层签名算法已有更新，就宣布所有Solana托管功能已经正式可用。算法、交易格式、地址处理、策略解码以及链上广播，共同决定一个机构流程是否可用。

概念示意

概念示意：银行与不同运行环境分别持有密钥份额，经门限批准后形成链上签名；图中路径用于解释控制关系，不代表Google客户的实际部署或性能测试结果。

预览阶段的版本变化也会产生迁移成本。官方概览说明，10月文档已转向v1beta API，并提醒仍用v1alpha1的客户迁移，旧版部分页面计划12月移除。[2] 对银行而言，评估不能停留在“已经能签名”，还需要确认版本变更是否影响审批证据、系统接口和审计留档。测试可运行与稳定承载客户资产之间仍有实施距离。

资金进入币圈之前，银行先要完成责任和流程整合

这类服务最直接的潜在影响，是降低金融机构自行建设一整套密钥与授权系统的工程负担。如果银行能够把签名流程接入现有人员管理、审批与审计，开展数字资产服务时可能更容易复用已有的治理能力。这是成本与运营效率的条件性推断，现有材料没有披露足以测算节省幅度的价格或客户生产数据。

市场常把大型云服务商进入该领域解释为机构买盘即将扩大，但签名设施只是其中一环。银行仍需决定提供哪些资产、面向哪些客户、如何处理反洗钱审查与会计记录，以及发生错误付款时由谁承担责任。如果这些环节没有完成，即使技术预览顺利，也不会自动形成交易量或新增持币需求。

欧易okx交易所 v6.194.0

类型：金融理财大小：540.5M语言：中文时间：10-23评分：10.0

对稳定币支付和代币化资产而言，可靠签名有助于支撑高频授权与结算流程，但基础链的拥堵、合约限制和赎回安排仍会影响最终服务。某家银行能够安全签出一笔交易，不等于资产已经完成法律交割，也不意味着收到的代币可以随时按面值兑换。需要分清签名成功、链上确认和客户权利生效这几个阶段。

对代币价格的传导则更不直接。基础设施提供商的收入可能来自云资源和服务费用，采用服务的银行也可能主要处理客户已有资产。即使业务增加，某条公链或某枚代币能够获取多少价值，还取决于实际交易路径、费用模型和客户偏好。现阶段没有依据把这一消息转换成以太坊或Solana的涨幅预测。

分散密钥以后，剩余风险会转移到哪里

MPC降低了单一完整密钥泄露的风险，但机构还要防止合法授权被错误使用。恶意目标地址、被篡改的业务指令、签名者共同依赖的审批界面，都可能让多方认真批准同一个错误。份额分散可以限制单点入侵，却不能自动保证多名人员依据的信息相互独立。

恢复机制也需要接受同样严格的审查。门限设置较高可能增加故障期间的协调难度，设置较低则可能降低攻击者需要控制的参与方数量。官方保证有明确前提：仍有足够参与方满足门限，签名才能继续。[2] 机构必须考虑人员离职、授权密钥丢失与云故障同时出现时，是否还有可执行的恢复路径，而不是仅在单节点故障中测试通过。

另一个边界是底层链的风险。即使签名过程完全符合设计，合约漏洞、资产冻结权限或交易不可逆性仍可能造成损失。MPC解决的是密钥协作与授权问题的一部分，不能替代对资产、合约和业务对手的审查。报道中的量子安全升级设想同样需要区块链本身采用相应密码体系，不能据此声称现有链上资产已经消除量子风险。[1]

下一阶段应核对可用性，而不是提前计算市场增量

后续最有信息价值的变化，是正式可用日期、明确支持的链与功能、价格和服务条款，以及银行公开确认的生产使用范围。若2027年初目标调整，应以新的官方状态为准；若仍停留在试用和匿名合作方阶段，就不能按全面落地估算市场份额。[1][2]

安全层面则应关注签名门限与策略覆盖权如何配置，多个环境是否具有独立管理边界，恢复流程是否经过真实演练，以及交易和策略修改能否形成完整审计证据。本文没有进行产品实测，也没有获得客户故障率、延迟或管理规模数据，不对这些指标作推断。

Google此次进展扩大了银行可评估的数字资产基础设施选项，官方文档也让产品边界变得更具体：服务仍处于预览，算法支持与链支持要分开确认，自动策略的拒绝可以被足够签名者覆盖。[2][3] 对币圈的长期影响，要看这些能力能否转化为持续生产业务。先核实谁能签、在什么条件下签，以及签错后谁负责，才能判断这次基础设施消息的实际分量。