docs: Account abstraction developer docs #1188
Conversation
✅ Deploy Preview for preeminent-bienenstitch-606ad0 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| ### Implementing at protocol vs application layer | ||
|
|
||
| Account abstraction can be implemented at the application layer of a network using smart accounts and meta-transactions. The tx being sent to the network is still an Ethereum tx, but its payload is interpreted as a "transaction execution request" that is validated and run by the smart contract wallet. |
There was a problem hiding this comment.
The tx being sent to the network is still an Ethereum tx...
It may not be clear prior to this statement that we are talking about AA on Ethereum L1 here. It might be best to say "For AA on Ethereum L1, a meta-transaction is still an Ethereum tx, but..."
| ### Nonces and replay protection | ||
|
|
||
| Every execution in the protocol emits the hash of the request as a nullifier, preventing the same transaction from being executed more than once. Nonces, on the other hand, are left to the account contract implementation. This allows building accounts with strictly incremental nonces or where transactions can be processed out-of-order. |
There was a problem hiding this comment.
Every execution in the protocol emits the hash of the request as a nullifier...
It might be best to be more verbose here for clarity 🤔 Maybe "Every transaction execution considered valid by the protocol emits the hash of the transaction execution request as a nullifier, ..."
| Since the `entrypoint` interface is not enshrined, there is nothing that differentiates an account contract from an application one in the protocol. This means that a transaction can be initiated in any contract. This allows implementing functions that do not need to be called by any particular user and are just intended to advance the state of a contract. | ||
|
|
||
| As an example, we can think of a lottery contract, where at some point a prize needs to be paid out to its winners. This `pay` action does not require authentication and does not need to be executed by any user in particular, so anyone could submit a transaction that defines the lottery contract itself as `origin` and `pay` as entrypoint function. For an example implementation of a different use case, refer to the `pokeable_token_contract` in the repository. |
There was a problem hiding this comment.
Link pokeable_token_contract
| ### Encryption and nullifying keys | ||
|
|
||
| Aztec requires users to define [encryption and nullifying keys](./keys.md) that are needed for receiving and spending private notes. Unlike transaction signing, encryption and nullifying is enshrined at the protocol. This means that there is a single scheme used for encryption and nullifying. These keys are derived from a master public key, which is committed to as part of the address. |
There was a problem hiding this comment.
... which is committed to as part of the address.
🤔 I suspect that many readers won't understand what this means. Maybe, "An account's encryption and nullifying keys, along with its address, are derived from a master public key."
There was a problem hiding this comment.
Okay considering the next paragraph, we probably want to explain what "commit" means here.
Maybe: 'An account's encryption and nullifying keys are derived from a master public key. That master public key is "committed to" as part of the account address, or in other words, the address is derived deterministically from that master public key.'
| Aztec requires users to define [encryption and nullifying keys](./keys.md) that are needed for receiving and spending private notes. Unlike transaction signing, encryption and nullifying is enshrined at the protocol. This means that there is a single scheme used for encryption and nullifying. These keys are derived from a master public key, which is committed to as part of the address. | ||
|
|
||
| A side effect of committing to a master public key as part of the address is that _this key cannot be rotated_. While an account contract implementation could include methods for rotating the signing key, this is unfortunately not possible for encryption and nullifying keys (note that rotating nullifying keys also creates other challenges such as preventing double spends). We are exploring usage of the slow updates tree to enable rotating these keys. |
There was a problem hiding this comment.
maybe put "slow updates tree" in quotes with a link if there is one
| ### Fee management | ||
|
|
||
| Fees are not implemented in the protocol at the time of this writing. Our goal is to abstract fee payments as well. This means that a transaction, in order to be considered valid, must prove that it has loocked enough funds to pay for itself. However, this does not mandate where those funds come from, opening the door for easy implementation of paymasters or payment-in-kind via on-the-fly swaps. |
There was a problem hiding this comment.
Already caught by @jeanmon :-P
Adds initial documentation on account abstraction aimed at devs. Background section is copied from this post.