Original Author: CP, Artela Founder

0) TL;DR Version

The first step in achieving full on-chain Eliza: Don't trust, verify! Run Eliza in a TEE, freeing it from human manipulation to execute based on Eliza's own code.

So, how does the outside world know what Eliza specifically did? Further development is needed: the outside world can read Eliza's execution log, and these logs can be verified to come from Eliza within the TEE. Eliza must sign these logs using a key pair derived from the TEE, allowing the logs to be verifiable as originating from Eliza inside the TEE.

focEliza's plugin plugin-tee-verifiable-log achieves this: it derives a key pair from the TEE specifically for signing logs. Logs generated using this key pair (including received and responded AI messages, as well as executed operations) are signed to create verifiable logs and stored in a database. It also provides an RPC interface, allowing external entities to:

· Obtain the AI agent's verifiable log public key through remote attestation.

· Query these verifiable logs, and verify the signatures using the public key to confirm that the AI agent executed the corresponding operations.

Verifiability is the cornerstone of achieving a fully on-chain AI agent, making magic a reality!

1) Starting From One Question!

A developer has deployed an Eliza AI agent on their server and launched a webpage for users to interact with.

Now, how do you distinguish if the entity you are interacting with is indeed responding from the AI agent (referring to Eliza + LLMs) and not artificially from the developer behind the scenes?

2) Is This Question Important?

This question is sometimes important and sometimes not.

· Sometimes not important: For example, a chatbot helping with article writing. As long as you get the desired content, it might not matter whether the response comes from an LLM or a human.

· Sometimes Somewhat Important: For example, when a trading bot manages your transactions. You need to transfer funds to a wallet controlled by an AI agent, and at this point, you will be concerned whether the decision was made by the running program rules of the LLM or by a human operator who may have malicious intent.

· Sometimes Very Important: When fairness is involved, this issue becomes extremely critical. For instance, an AI agent managing a community and distributing rewards to contributors. As the community grows and the value of rewards increases, the risk of human corruption or manipulation leading to unfair outcomes significantly escalates.

3) Eliza can now prove through verifiable logs what operations it executed!

Eliza running in a TEE operates independently of human control and performs tasks according to its own code.

However, to let external parties know exactly what Eliza accomplished, further functionality is required: external parties need access to Eliza's operation logs, and these logs must be verifiable to indeed originate from Eliza within the TEE.

The plugin-tee-verifiable-log achieves these functionalities and accomplishes the following tasks:

· Key Pair Derivation: Derives a key pair within the TEE dedicated to signing logs.

· Remote Attestation: Embeds the public key in a remote attestation report, allowing external parties to retrieve and verify that it indeed comes from Eliza within the TEE.

· Log Signing: Signs the logs generated during Eliza's operation (including messages sent and received, as well as actions taken) using the key and stores them in a database.

· Verifiability: External parties can use the public key from remote attestation to verify these logs, ensuring that certain operations were indeed performed by TEE Eliza.

· Queryability: External parties can subscribe to the latest verifiable logs or query specific logs based on message content.

What are the implications of the verification results?

· Passed: The operation was indeed carried out by Eliza.

· Failed: The operation may not have been carried out by Eliza. For example, logs could have been intercepted (e.g., deleted) during transmission to the client, preventing the external party from confirming whether Eliza performed a specific operation.

4) Enable the plugin-tee-verifiable-log for your Eliza!

focEliza is a set of plugins designed for a fully on-chain AI agent based on Eliza. It is fully compatible with Eliza, which means that any AI agent running on Eliza can achieve full on-chain functionality through the integration of focEliza!

If you are interested in a verifiable, fully on-chain autonomous AI agent, feel free to give it a try!

5) Closing

We are thrilled to build a fully on-chain autonomous AI agent based on Eliza and TEE. This is the first TEE plugin released by focEliza, and we have submitted a PR to the @ai16zdao and @shawmakesmagic teams. Looking forward to having more developers join us!

Feel free to check out our code.

6) focEliza's Next Feature: On-chain State! Achieving Autonomous Operation!

The Eliza running in TEE holds private keys and sensitive data. However, it relies on a physical machine that supports TEE to operate. If the administrator shuts down the machine, the "life" of the AI agent may be permanently terminated, and the managed assets and data may be lost forever.

To address this issue, we need to encrypt the key "life" data of the AI agent in the TEE, such as role definitions, short-term/long-term memory, and key storage. Then, upload this data to the blockchain or a DA network.

If the TEE hosting the AI agent is shut down, another TEE machine should be able to download the encrypted data, decrypt it, and restore the "life" of the AI agent to seamlessly continue its operation.

"Original Article Link"

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia