为什么我们基于 TEE 构建完全链上的 Eliza

本文从技术角度探讨使用 TEE + Eliza 的原因,借鉴了我在构建由 TEE、PPML 和区块链驱动的隐私计算解决方案方面的经验。

让我们暂时跳过宏大的叙事,专注于我在 AI 代理方面遇到的两个真实困境:

1) 作为 CTO,我不能将公司的官方 Twitter 账号和密码交给第三方 AI 代理服务。

目前,如果我想让 AI 代理管理我们的 Twitter 账号,我必须给他们用户名、密码和 cookies。

这意味着公司必须信任 AI 代理背后的服务器管理员。如果他们恶意行事或被黑客入侵,这些凭证的泄露可能会给我们的社区带来重大经济损失。

通过 OAuth 授权,我可以撤销访问权限,但在当前设计中,我们可能完全失去对账号的控制权,包括密码可能在我们不知情的情况下被更改。

2) 作为交易者,我不能将大量资金委托给专注于交易的 AI 代理。

就像我永远不会使用 Telegram 上的中心化交易机器人一样,我不能让它们集中托管我的私钥。中心化部署的 AI 代理在这方面本质上没有任何不同。

总之,加密 AI 代理的下一阶段将不可避免地涉及管理钱包、处理用户资产和敏感信息,以及与链上系统进行更深入的交互。

因此,使 AI 代理能够自主行动,不受人类控制,并证明 AI 代理的决策仅来自 AI 过程,成为关键挑战。

当前的 TEE + Eliza 解决方案是否足够?

从工程角度来看,这些解决方案还需要实现更多细节才能发挥其潜力。

当前工作: Phala network 和 @NousResearch 已经完成了出色的基础工作:他们将 Eliza 容器化到可以在 TEE 内运行的 Docker 环境中。他们还消除了手动配置钱包私钥的需求,通过从 TEE 的根密钥派生只有 AI 代理可以访问的私钥。

然而,作为 AI 代理的构建者,我看到需要额外的组件来增强信任最小化:

a) TEE Eliza 的可验证性需要增强功能

Eliza 在 TEE 内部到底在做什么,不在做什么? 需要一个具体的验证方式。 Eliza 已经记录了所有传入的消息、响应和它执行的操作。这些日志必须可读且可验证,确保它们是由 Eliza 生成的。

因此,TEE Eliza 的第一个基础功能是可验证日志。Eliza 应该使用在 TEE 内派生的密钥签署这些日志,提供查询接口,并允许用户验证其真实性。

b) TEE Eliza 需要解决活性问题

TEE 内的 Eliza 持有私钥和敏感数据。然而,它运行在支持 TEE 的物理机器上,如果管理员关闭机器,AI 代理的"生命"可能永远终止。它管理的资产和数据可能永远丢失。

为了解决这个问题,我们需要在 TEE 内加密 AI 代理的关键"生命"数据(如其角色定义、长短期记忆和密钥库)。这些数据应该上传到区块链或 DA 网络。

如果托管 AI 代理的 TEE 关闭,另一个 TEE 机器应该能够下载加密数据,解密它,并恢复 AI 代理的生命,使其能够无缝继续运行。

c) 额外功能:构建 TEE 工程与构建区块链一样具有挑战性

用户对 AI 代理的控制:AI 代理必须允许用户以信任最小化的方式定义策略,类似于智能合约,来管理代理如何管理资产。

区块链交互组件:需要在 TEE 内运行可信区块链客户端、数据同步器和其他组件,以实现与区块链系统的无缝交互。

focEliza 的当前进展:两个基础 TEE 插件正在开发中

1) plugin-tee-verifiable-log

当 Eliza 在 TEE 内运行时,它使用派生的密钥对签署其操作。这确保所有操作都确实是由 Eliza 执行的。第三方可以使用 Eliza 的公钥远程验证这些操作。

2) plugin-tee-onchain-da

Eliza 将指定 AI 代理的"生命"数据(例如,角色文件、记忆、密钥库)近实时写入区块链或 DA 层。如果运行代理的 TEE 节点关闭,另一个 TEE 节点可以下载加密的"生命"数据,恢复代理,并恢复其运行。

ps: 在这里查看 focEliza

这就是我发起 focEliza 的原因和背后的详细技术愿景。

下一个问题是为什么选择构建在 Eliza上? 我的思考

1***) Eliza 有潜力成为加密 x AI 代理领域的 EVM***。

我们不是来定义它会给世界带来什么改变的—让它先发生吧! 让 AI 代理在链上生存!

为什么我们基于 TEE 构建完全链上的 Eliza ​