Shade Agent Docs

[PiVortex]

This PR adds docs for Shade Agents.

Pages:

• Introduction
• What can you build
• Deploying an agent
• Key components
• Plugins (WIP, included some resources for now, full docs will be added later)
• AI and NEAR page

Other changes:

• Added media
• Edited sidebars
• Added chain signatures and shade agents support component

[mattlockyer]

Looking great overall, just a couple of questions and consistency points.

[thisisjoshford]

@PiVortex I think Shade Agents should be under Chain Abstraction > Chain Abstraction Services. @gagdiez @bucanero wdyt?

[PiVortex]

I think what we're doing with Shade Agents is too big to be put under Chain Abstraction. And I wouldn't really call it a chain abstraction product it just uses chain signatures. Happy to explore where else we can put this.

[thisisjoshford]

Ok cool, lets schedule a call to chat about this :)

[gagdiez]

This does not sound like part of "AI and NEAR", but part of a different page related to AI and Smart Contracts

[PiVortex]

Dont really understand this, smart contracts are on NEAR. Do you not think it should go in this page? I think its worth mentioning here.

[gagdiez]

Suggested change

	Shade Agents provide verifiability, non-custody, and persistent accounts by operating in TEEs and implementing decentralized key management. Any agent running with the same code inside a TEE can access the same accounts.
	Shade Agents provide verifiability by operating in TEEs, but leverage the NEAR tech stack to gain non-custody, and persistent control of accounts across multiple blockchains.
	Particularly, Shade Agents register their code-hash (unique to the agent) on a NEAR smart contract, which allows them to control multiple accounts through chain signatures. This way, if the agent is deployed in a different environment, it can easily recover their accounts (as their code-hash is verifiably the same)

[gagdiez]

Suggested change

	These agents can autonomously sign transactions across any chain, interact with AI models and external data sources, manage assets, and perform privacy-preserving, verifiable computations, offering the flexibility and performance of Web2 with the verifiability of Web3.
	Thanks to combining TEE with the NEAR tech stack, Shade Agents can autonomously sign transactions across any chain, interact with AI models and external data sources, manage assets, and perform privacy-preserving, verifiable computations, offering the flexibility and performance of Web2 with the verifiability of Web3.

[gagdiez]

Suggested change

	The worker agent calls the `register_worker` function on the agent contract, providing two pieces of information generated inside the TEE:
	The worker agent calls the `register_worker` function on the `agent smart contract`, providing two pieces of information generated inside the TEE:

[gagdiez]

Suggested change

	If the attestation quote is valid and the code hash matches the expected code hash of the worker agent (defined during agent contract deployment), the worker agent's accounts are added to a list of valid worker agents.
	If the attestation quote is valid and the code hash matches the expected code hash of the worker agent (defined during agent contract deployment), the worker agent's accounts are added to a list of valid worker agents inside the `agent smart contract`.

[gagdiez]

Suggested change

	Once registered, the worker agent can call the `sign_tx` function on the agent contract, enabling it to sign transactions on behalf of the Shade Agent. The Shade Agent utilizes [chain signatures](../../chain-abstraction/chain-signatures.md) for decentralized key management, allowing it to hold assets and sign transactions on nearly any chain.
	Once registered, the `worker agent` can call the `sign_tx` function on the agent contract, enabling it to sign transactions. This way, the agent can leverage [chain signatures](../../chain-abstraction/chain-signatures.md) for decentralized key management, allowing it to hold assets and sign transactions on nearly any chain.

[gagdiez]

Suggested change

`Anyone` can deploy the same Docker image of the worker agent to a TEE and have it register as a valid worker agent and access the sign_tx function to use the same accounts. This means the accounts are never lost and the service is `always live`. Worker agents are designed to be stateless to facilitate this functionality.

`Anyone` can deploy the same Docker image of the worker agent to a different TEE. Since the Docker image will have the same hash, it can be then registered as a new valid `worker` for the agent, and thus gain access to signing transactions using the agent's accounts. This means the accounts are persisted across TEE instances of the agent. To facilitate this functionality, `worker` agents are designed to be stateless

[gagdiez]

maybe this goes when we first say TEE, or closer to the first time we say TEE on this sub-section

[gagdiez]

Suggested change

	After contract deployment, a `code hash` is set to ensure that only worker agents running the correct worker code can register.
	After the contract is deployed, a `code hash` is set to ensure that only worker agents running the correct code (i.e. the code identified by the `code hash`) can be register in the contract.

[gagdiez]

Suggested change

	Developers or protocols may need to modify the code running inside worker agents. When the contract is first deployed, it's initialized with an `owner` account Id. Only the owner can call the approve code hash function to update the worker agent code.
	Developers or protocols may need to modify the agent's code. Because of this, when the contract is initialized a `owner` is set, which is the only account allowed to approve updates to the stored `code hash`.

[gagdiez]

Suggested change

	The register worker function verifies that the worker agent is running in a TEE and executing the expected code. Upon successful verification, the worker agent's account Id becomes registered and gains access to `gated functions` (sign_tx).
	The register worker function verifies that the worker agent is running in a TEE and executing the expected code (as defined by the registered `code_hash`).
	Upon successful verification, the worker agent's account ID becomes registered and gains access to signing transactions.

[gagdiez]

Suggested change

	The `sign_tx` function serves as the gateway to access the Shade Agent's multichain accounts and sign transactions. It employs `method access control` so that only valid worker agent account Ids are able to use this function. Developers should not sign transactions from the worker agents themselves (except for functions on the agent contract) as these accounts will be lost if the worker agent goes down. The magic of Shade Agents is that the multichain accounts are tied to the agent contract, which are persistent and accessible by any instance of a valid worker agent.
	The `sign_tx` function serves as the gateway to access the Shade Agent's multichain accounts and sign transactions. It employs `method access control` so that only the registered `workers` are able to use this function.
	:::tip
	Developers should not sign transactions from the worker agents themselves (except for functions on the agent contract) as these accounts will be lost if the worker agent goes down.
	The magic of Shade Agents is that the multichain accounts are tied to the agent contract, which are persistent and accessible by any instance of a valid worker agent.
	:::