Accounts and Keys
Flow introduces new features to give applications and end users more safety and flexibility when managing keys, accounts and the assets inside them.
Accounts
An account on Flow is a record in the chain-state that holds the following information:
- Address - unique identifier for the account
- Balance - default token balance
- Public Keys - public keys authorized on the account
- Code - Cadence contracts deployed to the account
- Storage - area of the account used to store resource assets
Account Creation
Unlike Ethereum and Bitcoin, Flow does not use cryptographic public keys to derive account addresses. Instead, accounts have unique IDs that are deterministically generated by the network.
This allows for multiple public keys to be associated with one account, or for a single public key to be used across several accounts.
Users must submit an account creation transaction to create a new account. These transactions behave like any other transaction, and therefore must have a payer.
Who will pay to create my account?
Account creation fees are relatively low, and we expect that wallet providers and exchanges will cover the cost when a user converts fiat to crypto for the first time.
Conceptually, this isn't much different than Ethereum or Bitcoin. Although private keys can "reserve" account addresses off-chain, new accounts aren't visible to the network until somebody submits (and pays for) a transaction to that address.
What does an account creation transaction look like?
Here's an example of how to submit an account creation transaction with the Go SDK: Account Creation Example.
What about smart contracts?
Ethereum draws a distinction between accounts and contracts, both of which are addressable. Ethereum contracts are immutable and cannot be upgraded after deployment.
To achieve the same in Flow, simply create an account with deployed code and an empty list of authorized keys. This renders the account immutable by making it impossible to authorize a transaction that would mutate the account code.
Account Addresses
Flow addresses are generated in a deterministic sequence using the linear code [64, 45, 7] as an error-detection code.
The address of the i-th
account created on Flow is simply the
codeword corresponding to the original value (i
).
This linear code allows generating 2^45 distinct addresses, with each address being encoded over 64 bits. Two different addresses are guaranteed to have at least 7 different bits, which reduces the risk of confusing two addresses.
Moreover, the linear code used is non-systematic, which means it's not possible to separate the extra bits from the original value bits in the codeword. This makes the generated addresses look like random numbers and two consecutive account addresses look very different. A quick off-chain test can determine if a 64 bit word is a valid Flow address.
The generation of an account address is an on-chain mechanism that happens when a Flow network receives an account creation transaction. The network keeps track of the number of accounts already created and returns the newly created address.
Keys
Flow accounts can be configured with multiple public keys that are used to control access. Owners of the associated private keys can sign transactions to mutate the account's state.
Adding a Key to an Account
When adding a public key to an account, you must specify the following information:
- Raw public key
- Signature algorithm (see codes below)
- Hash algorithm (see codes below)
- Weight (integer between 1-1000)
The signature algorithm is included because Flow supports a variety of signatures schemes with different parameters. The included hash algorithm specifies the hashing function used to verify signatures.
How are keys added to an account?
To add keys to an account, you can submit a transaction that is authorized to access that account.
Here's an example of how to add an account key with the Go SDK: Add Account Key Example.
Revoking a Key From an Account
Feature and documentation coming soon...
Supported Signature & Hash Algorithms
Flow has initial support for a predefined set of signature and hash pairings, but more curves and algorithms will be added in the future.
Signature Algorithms
Algorithm | Curve | ID | Code |
---|---|---|---|
ECDSA | P-256 | ECDSA_P256 | 2 |
ECDSA | secp256k1 | ECDSA_secp256k1 | 3 |
Hash Algorithms
Algorithm | Output Size | ID | Code |
---|---|---|---|
SHA-2 | 256 | SHA2_256 | 1 |
SHA-3 | 256 | SHA3_256 | 3 |
Compatibility Table
SHA2_256 | SHA3_256 | |
---|---|---|
ECDSA_P256 | ✅ | ✅ |
ECDSA_secp256k1 | ✅ | ✅ |
Weighted Keys
Every account key has a weight that determines the signing power it holds.
A transaction is not authorized to access an account unless it has a total
signature weight greater than or equal to 1000
, the weight threshold.
For example, an account could contain the following keys:
- Key ID: 1, Weight: 500
- Key ID: 2, Weight: 500
- Key ID: 3, Weight: 500
This represents a 2-of-3 multi-sig quorum, in which a transaction is authorized to access the account if it receives signatures from at least 2 out of 3 keys.