RP for plugin-tee-verifiable-log-api

[gene-zhan]

Relates to:

1. Run verifiable Eliza in the TEE.
2. Verifiable log for Eliza in the TEE
3. RP for plugin-tee-verifiable-log #1331

Risks

Low

Background

What does this PR do?

This PR builds upon plugin-tee-verifiable-log by modifying the direct client to add remote attestation and query interfaces for verifiable logs.

To better understand what verifiable logs are and why we implemented this feature, it is necessary to refer to the preceding PR that introduces plugin-tee-verifiable-log and provides the context for its development.

What kind of change is this?

• Feature
• TEE plugin
• Verifiable feature

Documentation changes needed?

Yes, we will add documentation about api detail.

Testing

Where should a reviewer start?

1. Understand the existing plugin-tee

   1. We rely on Eliza's existing plugin-tee and use its key derivation interface.

2. To better understand what verifiable logs are and why we implemented this feature, it is necessary to refer to the preceding PR that introduces plugin-tee-verifiable-log and provides the context for its development.

3. Understand what plugin-tee-verifiable-log does

   1. Derive a key pair for verifiable logs: It uses the TEE to derive a key pair specifically for signing verifiable logs.
   2. Remote attestation: The public key of verifiable logs is embedded in the remote attestation report, making it accessible for external verification.
   3. Sign logs: This plugin accepts logs passed in from external modules (e.g., tweets sent and received by a Twitter client, or executed actions), signs them with the TEE-derived key pair, and stores them in the database.
   4. Verification: External entities can use the remotely attested public key to verify these logs, ensuring that certain actions were indeed performed by TEE Eliza.

Detailed testing steps

It have completed the integration tests and can run the xx file in the test directory.

[odilitime]

is this a duplicate of #1260 or a progression? should we close #1260 ?

[gene-zhan]

@madjin I noticed that PRs #1331 and #1333 were reopened and the #1260 PR closed, which has left me a bit confused about the current direction. Should I merge my changes into the develop branch, or is there a different branch we should treat as the standard? I’ve submitted #1369. both cpppppp7 and I have been working diligently to make progress on this code contribution. I’d appreciate any clarification to ensure we align our efforts effectively. 😊

[shakkernerd]

Closing in favor of #1369