Super User Account

🛠️ Builders 🏄🏻‍♀️ Cadence
,
15

While thinking through how entitlements for accounts could look like it occurred to me that we do not even need the distinction between AuthAccount and PublicAccount anymore.

Here is an example of how a refactoring a part of the account type could look like:

struct interface ContractAdmin {

    auth(ContractAdmin) let contractAdmin: auth &Account.Contracts
}

// ... other entitlement interfaces granting access to keys, capabilities, etc.

struct Account: ContractAdmin {

    let address: Address

    // ... other fields, functions, and types

    let contracts: &Account.Contracts

    auth(ContractAdmin) let contractAdmin: auth &Account.Contracts

    struct Contracts {

        fun get(name: String): DeployedContract?

        auth fun update__experimental(name: String, code: [UInt8]): DeployedContract

        // ... other fields and functions
    }
}
  • We would only have one type Account
  • Previous uses of PublicAccount would become &Account. Note that the reference is non-auth, meaning that informational fields like address, but also fields like contracts could be accessed and would allow “read-only operations”.
  • Previous uses of AuthAccount would become auth &Account, effectively granting access to all auth fields
  • A signer type auth(ContractAdmin) &Account would only allow access to managing contracts, but not to e.g. managing keys
  • One small downside is that we would need to expose two fields for each nested reference, one non-auth and one auth, e.g. contracts and contractAdmin
  • (Note that naming is just strawman syntax, suggestions welcome)

@sainati Did I apply https://github.com/onflow/flips/pull/54 here correctly?

1 Like