Introducing OWS, the Open Wallet Standard

  • moonpay
  • 发布于 1天前
  • 阅读 45

Open Wallet Standard (OWS) 是一种安全、本地优先的协议,旨在为AI代理和开发者工具提供统一的跨链密钥存储、钱包管理和交易签名解决方案。它解决了当前AI代理钱包碎片化和不安全的密钥管理问题,并支持本地部署,避免了对云服务的依赖和高延迟。

Image

今天我们开源了 Open Wallet Standard (OWS),这是一个安全的、本地优先的协议,它为 AI 智能体和开发者工具提供了一种统一的方式,可以在所有主流区块链上存储密钥、管理钱包和签署交易。

一个保险库,一个界面,所有链。

智能体支付堆栈已经到来。首次通过 x402、MPP 和 A2A,AI 智能体可以在无人参与的情况下支付费用——例如 API、计算和数据。

但这个堆栈中存在一个尚未解决的空白。

所有这些协议都假设你的智能体已经拥有一个钱包。

x402 需要一个已签名的 EIP-3009 授权。MPP 需要一个来自有资金账户的已签名支付。它们定义了智能体如何支付。但它们都没有定义私钥存放在哪里、如何存储、如何保护,或者两个不同的工具如何共享同一个钱包的访问权限。

问题

具体来说,你正在构建一个智能体。它需要签署交易。

如今,情况是这样的:

你的私钥是一个 .env 文件中的十六进制字符串,或者一个环境变量,或者 JSON 配置中的一个明文字段。你的智能体进程在启动时读取它,在会话期间将其保存在内存中,并传递给你正在使用的任何签名库。如果你在 EVM 上,你正在使用 ethers.js 或 viem。如果你也在 Solana 上,你正在使用 @solana/web3.js,它使用完全不同的密钥格式。Bitcoin 呢?又是另一个库,另一个派生方案,另一组潜在的错误。

现在你有三个私钥、三个签名实现,以及三个可能导致这些密钥泄露的途径——通过日志、通过崩溃转储,甚至通过 LLM 上下文窗口本身(如果你的智能体框架不小心处理它向上游传递的内容)。

云 KMS 服务解决了部分问题,但它们引入了不同的权衡:每次签名都会有网络延迟、对第三方基础设施的托管依赖、对专有 API 的厂商锁定,以及随交易量增加而产生的经常性成本。对于许多智能体用例——尤其是高频小额支付、离线系统和自托管部署——每次签名操作都需要进行云往返是不可接受的。

核心问题不是没有人构建钱包。而是没有关于智能体钱包应该如何工作的共享标准。

没有通用的存储格式。没有通用的签名界面。无法让一个工具创建的钱包被另一个工具使用。每个 SDK 都自行开发,结果是私钥分散在 dotfiles、环境变量和专有格式中,没有共享的安全模型。

我们构建了什么

Open Wallet Standard 是一个开放协议,用于本地钱包存储和签名,专为 AI 智能体及其服务工具设计。

其理念很简单:你的机器上有一个加密保险库,所有链通用一个界面,并且采用一种安全模型,其中你的私钥永远不会暴露给智能体、LLM 或任何父进程。

具体来说,这意味着:

  1. 一个助记词,所有链。 一个 BIP-39 助记词通过标准 HD 派生路径为所有受支持的链派生账户——包括 EVM、Solana、Bitcoin、Tron、TON、Cosmos 等。
  2. 一个签名界面。 智能体永远看不到你的私钥。
  3. 一个 Rust 核心,所有运行时。 该实现完全用 Rust 编写,并提供 Node.js 和 Python 绑定。
  4. 静态加密,签名后清零。 密钥使用 AES-256-GCM 和 scrypt KDF 加密——与自 2015 年以来一直在生产中使用的 Ethereum Keystore v3 格式相同。密钥只在生成签名时解密,保存在 mlocked memory 中(固定,永不交换到磁盘),并立即清零。

对于开发者来说,界面是这样的:

import { createWallet, signMessage } from "@open-wallet-standard/core";

const wallet = createWallet("agent-treasury");
const sig = signMessage("agent-treasury", "eip155:1", "hello");

三行代码。原生性能。没有网络调用。

OWS 在堆栈中的位置

OWS 不是一个支付协议。它是一个位于支付协议之下的钱包层。

当 x402 服务器返回带有支付请求的 402 错误时,需要有东西来生成已签名的授权。当 MPP 服务定价时,需要有东西来签署支付。这个“东西”就是钱包——而在此之前,每次集成都必须从头开始构建这部分。

OWS 为 x402、MPP、A2A 和任何未来协议提供了一个通用的钱包界面。该规范定义了七个模块——存储格式、签名界面、策略引擎、智能体访问层、密钥隔离、钱包生命周期和支持的链——因此协议实现者可以依赖一个定义明确的钱包 API,而不是自行开发。

基础设施转变使其不可避免

本地优先钱包现在成为正确模型存在结构性原因,它们并非哲学性的——它们是架构性的。

智能体的部署方式正在改变。OpenClaw——这个开源 AI 智能体平台——在 60 天内获得了 25 万颗 GitHub 星星,使其成为历史上增长最快的开源项目。它的整个架构都是本地优先的:你在自己的机器或 VPS 上运行它,你的数据保留在你的文件系统上,工具执行在本地进行。像 Hostinger、Contabo 和 OVHcloud 这样的 VPS 提供商现在提供专门的 OpenClaw 托管计划。百度和腾讯正在举办研讨会,帮助用户在中国自托管智能体。德勤预计到 2026 年,至少 15% 的企业将转向私有 AI 部署。

这就是趋势:智能体正在从供应商云转向你控制的基础设施。私有 VPS 实例。自托管运行时。具有 Shell 访问权限和完整执行控制的本地文件系统。当你的智能体在你的 VPS 上运行时,你拥有一个文件系统。你拥有你可以控制的内存。你拥有你信任的进程边界。

在那个世界里,云钱包提供商正在解决一个不存在的问题。如果你的智能体已经在你的 VPS 上运行,将每个签名操作都通过 Turnkey 的 AWS Nitro enclave 或 Privy 的云基础设施路由,意味着增加 100-175 毫秒的网络延迟、对第三方的托管信任依赖、按交易收费,以及对网络连接的硬性要求——所有这些都为了一个在本地只需微秒的操作。你正在花钱让别人在他们的服务器上保存你的密钥,而你的密钥可以在你自己的服务器上以相同的安全保障和零开销的方式进行加密保存。

签名是一个本地操作。私钥、哈希和椭圆曲线数学——这些都是本地计算。唯一的网络调用应该是将已签名的交易广播到 RPC 端点。OWS 正是围绕这个现实构建的:你的保险库在你的文件系统上,签名在你的进程中发生,只有当你选择发送时,网络才会介入。

为什么开源,为什么现在

为什么开源:因为钱包互操作性需要共享格式。

如果 Phantom、WalletConnect、Turnkey 和你的自定义智能体框架都以不同的方式存储密钥,那么你将无法在它们之间移动,除非导出原始密钥材料——这正是你想要尽量减少的操作。一个带有指定存储格式的 CC0 许可标准意味着任何工具都可以读取任何钱包,并且你永远不必为了切换工具而暴露私钥。

为什么现在:因为需要钱包的智能体数量增长速度快于钱包标准的数量。

OpenClaw 本身已经催生了自己的钱包生态系统(agent-wallet-cli,OpenClawCash)——这些都是因为没有标准而构建的临时解决方案。每周都有一个新的智能体框架推出其自己的密钥管理方法。每一个烘焙到生产系统中的专有格式都是某人最终必须进行的迁移。我们宁愿现在就标准化这一层,趁着生态系统仍在形成,而不是在几十种不兼容的方法固化之后再试图改造一个标准。

联盟

@OpenWallet Standard 与 21 家创始组织一同发布:

其中几家组织已将其 SDK 集成了 OWS。

开始使用

该标准今天已上线。

curl -fsSL https://docs.openwallet.sh/install.sh | bash
ows wallet create --name "agent-treasury"

或者安装 SDK:

npm install @open-wallet-standard/core
pip install open-wallet-standard

阅读规范并在 GitHub 上贡献。

访问 openwallet.sh 开始使用。

在 X 上关注更新:@OpenWallet

每个支付协议都需要一个底层的钱包。我们相信这个钱包应该是开放的、本地的,并且在任何地方都保持一致。

一个保险库。一个界面。密钥永不离开你的机器。

  • 原文链接: x.com/moonpay/status/203...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
moonpay
moonpay
江湖只有他的大名,没有他的介绍。