Original author: CP, Artela Founder

0) Too long, didn't read version

The first step in fully implementing the on-chain Eliza: Don't believe it! Go verify it!

Eliza running in TEE can free itself from manual manipulation and execute according to Eliza's own code.

So, how does the outside world know exactly what Eliza did, and further development is needed: the outside world can read Eliza's running log, and these logs can be verified to come from Eliza inside the TEE. Eliza must use key pairs derived from TEE to sign these logs, so that the logs can be verified to indeed originate from Eliza inside TEE.

focEliza's plugin plugin-tee-verifiable-log implements this feature: it derives a key pair dedicated to signing logs through TEE. The logs generated using this key pair (including received and responded AI messages, as well as performed operations) are signed to create verifiable logs and stored in the database. It also provides an RPC interface that allows external entities to:

· Obtain the verifiable log public key of the AI agent through remote authentication.

· Check these verifiable logs and use the public key to verify the signature, confirming that the AI agent has performed the corresponding operation.

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

!

1) Start with a question!

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

How do you distinguish if the responses you interact with come from the AI agent (referring to Eliza + LLMs) or if they are artificially controlled responses from developers?

2) Is this issue important?

This issue is important sometimes and unimportant sometimes.

· Sometimes not important: for example, a chatbot that helps write articles. As long as you get the desired content, it may not matter whether the response comes from LLM or humans.

· Sometimes it can be slightly more important; for example, if a trading bot manages your trades. You need to transfer funds to a wallet controlled by an AI agent, and you will be concerned whether decisions are made by LLM running program rules or by humans who may have malicious intent.

· Sometimes it is very important: When it comes to fairness, this issue becomes extremely important. For example, when an AI agent manages a community and distributes rewards to contributors. As the community grows and the value of rewards increases, the risk of human corruption or manipulation leading to unfair outcomes increases significantly.

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

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

But in order for external parties to know what specific operations Eliza has completed, further functionality is needed: external parties need to access Eliza's operation logs, and these logs must be verifiable as coming from Eliza in the TEE.

plugin-tee-verifiable-log implements these functions and completes the following tasks:

· Key Pair Derivation: Derive key pairs dedicated to signing logs through TEE.

· Remote Attestation: Embedding the public key into the remote attestation report, allowing external parties to retrieve and verify that it does indeed come from Eliza in the TEE.

· Log Signature: Use this key to sign the logs generated during Eliza operations (including received and responded messages, as well as actions taken) and store them in the database.

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

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

What is the meaning of the verification result?

· Through: the operation is indeed performed by Eliza.

· Failure: The operation may not have been performed by Eliza. For example, the log may be intercepted (e.g., deleted) during transmission to the client, making it impossible for external parties to confirm whether Eliza has performed a specific operation.

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

focEliza is a set of Eliza plugins designed for comprehensive on-chain AI agents. It is fully compatible with Eliza, which means that any AI agent running on Eliza can achieve comprehensive on-chain functionality by integrating focEliza.

If you are interested in verifiable comprehensive on-chain autonomous AI agents, feel free to try!

5) End

We are excited to be able to build a comprehensive 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 more developers joining us!

Welcome to check out our code.

6) Next function of focEliza: On-chain status! Achieve autonomous activities!

Eliza running in TEE possesses private keys and sensitive data. However, it relies on the physical machine that supports TEE. 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 solve this problem, we need to encrypt the key 'life' data of AI agents in TEE, such as role definition, short-term to long-term memory, and key storage. Then upload this data to the blockchain or DA network.

If the TEE that hosts the AI agent is turned off, another TEE machine should be able to download the encrypted data, decrypt and restore the 'life' of the AI agent, allowing it to seamlessly continue running.

Original Link

：