spec: account requirements
enitrat opened this issue · comments
Feature Request
During our incremental work on the account structure, we drafted the following requirements
- The account MUST be upgradeable, such that transactions are executed per the latest account class rules
- The account MUST get the latest class available from an external, upddateable registry
- The account update MUST be invisible to the user
- The account MUST be able to communicate with Cairo1 functions through an external Cairo1 Class
- The account MUST be able to call the Kakarot contract
We have some limitations at the protocol:
- The
__validate__
function CANNOT make external calls - As such,
__validate__
will always be run in the context of the account's current class
From these rules, and limitations we can derive:
- The account WILL store the Cairo1Helpers class to be able to use it inside validate.
- The account WILL store the Kakarot address to be able to make calls to it
- The account WILL update its internal storage variables to the registry's latest values before executing a transaction
- The account WILL delegate the transaction execution to the latest class, if it is not the latest class
- The registry WILL have a frozen interface for the functions used in the accounts