This article includes contributions from Ramtin Mehdizadeh Seraj and Layne Lafrance.

Real ownership is a promise that individuals can access the things they value anytime, anywhere, through a broad range of service providers. The value of this promise was first validated with Bitcoin and again with Ethereum - both offering an opportunity to access value seamlessly. But, unfortunately, neither is fully able to fulfill that promise as we now know it needs to be filled… 15 years later. 

Bitcoin ownership is limited to what can be captured on the ledger (UTXO model) which means it can attach your keys to a value and only your keys can submit a transaction to change that value but, if you ever lose your keys, you’re sunk.

EVM-based blockchains like Ethereum take a different approach  with a Contract model which lets developers use the blockchain to manage more complex user value relationships that can be captured strictly on a ledger. This improves on the real ownership promise because it expands the value available to users; smaller cryptocurrencies (like those issued during the infamous 2017 ICOs) are able to represent and capture the specific needs and wants of a small group of people and ensure that small group of people is able to enforce redeemability among themselves even if acceptance of the broader network token (ETH or BTC in these examples) falls drastically. A huge improvement!

However, the Contract model suffers a major flaw - it recreates an economic system that crypto was, originally, aiming to avoid - a system where small parties make decisions about the fate of your value. Smart contracts offer a lot of freedom for developers to both serve and steal from customers and unfortunately that is the nature of the contract model. On Ethereum, interactions with anything you value requires core contract approval which is holding the value for you - your ownership is dictated by rules defined by those developers and a reference to their core smart contracts, rather than real cryptographic control. 

Real Ownership in digital comes down to the irrevocability of an item, from your possession, without your explicit consent. Said differently, it’s the right, freedom, and ability to access items you own without approval from another party (an application  you use, for example).  The irrevocability is formally guaranteed by a system that operates autonomously from any single government or institution - public blockchains tend to fill this niche. Flow is one such system, a public blockchain (a.k.a. platform) which supports, enforces, and enables irrevocable access to digital items. Where Flow improves upon other chains is ensuring access to those items is ultimately entirely within the authority and rights of the user - not any of the apps that serve them.  Flow set out to provide real ownership - irrevocable, autonomous access to (digital) items -  for all participants and in this article we’ll explain how it achieved just that. But, if you’re looking for the 

Tl;dr

The Account model is a way of defining ownership and access such that value is always available to users, protected by best-in-class security in the system, and accessible to developers - safely - meaning they can tap into user accounts to offer services but they can’t remove value from a user’s account without their express permission in the process of offering that product or service. Flow’s Account Model builds on important ideas from the Contract Model and is still largely centred around smart contracts, with a few important differences! We’ll detail the observations and motivations that led Flow to reconsider the industry standard and detail the differences between Ethereum’s EVM-based Contract model and Flow’s FVM based Account model below. 

1. Access management

One of the benefits of Flow accounts in comparison to what EVM-based accounts supports right now (e.g accounts on Ethereum, Polygon, Avalanche) is powerful access management capabilities. These natively-supported account management features solves many problems by design and ensure developers and users have access to best-practices for safety by default. Here is a list of some properties:

Supporting multiple keys per account 

Every Flow account can be controlled by multiple public keys. Each public key attached to an account is allocated a unique compact id used by transactions (the combination of account address and key index). This allows reusing the same public key on different accounts. Using valid keys on a Flow account, user could add/revoke keys at any time. This allows users to rotate their keys and revoke a key that its private key might be at risk. 

On EVM-based account only a single public key is allowed to control an account which is set at setup time and could not be rotated or changed. In the case of the potential risks with a key, user has to setup a new account and have to transfer all the assets to the new account which is a very expensive and time consuming process. 

Another benefit of supporting multiple keys per account is controlling an account from multiple locations. Currently the only way to control an EVM account from multiple devices is to extract the private key seeds out of a device and transfer them to other devices. This introduces unnecessary risks and also might not be an ideal option in the area of modern on-device signature hardware modules like secure enclaves. Instead of copying your keys from your laptop to your phone (which exposes them to many forms of malware), your laptop and phone have private keys generated on each device which never need to leave.

Native support for key weights 

When an application requires coordination between multiple parties (such as a DOA), it can often be useful for certain operations to require signatures from multiple keys before being executed.

Having various keys with different weights participating to control an account  supports both technical redundancy (multiple people authorized to make changes in a group) and financial security (requirement of multiple holders on an account to sign before withdrawal of funds, for example). This is not natively supported by EVM but has proven to be a necessary feature in the modern web3 stack, as is evidenced by the popularity of Gnosis Safe and Argent Vault.

Each public key attached to a Flow account has a fixed weight (range: 1-1000) and an account is authorized for the context of a transaction if it holds more than 1000 weight of valid signatures. Supporting weights enables many applications such as threshold signatures (e.g. an account with 5 keys each given a weight of 335 could be distributed to 5 entities which allows threshold signature of 3 out of 5).

Lack of native support of these properties on EVM accounts, has forced users to deploy and rely on smart contract wallets, which are usually very expensive to deploy and use and most of the time results in security risks like the Parity’s Multi-signature Wallet Hack, or Parity User-Triggered Wallet Freeze. 

Native support of industry-standard signature algorithms and setups

Flow accounts are designed to support authorization using various cryptographic signature algorithms (e.g ECDSA, EdDSA, …) and different setups (e.g. different curves). 

As you may have noticed, the most advanced security for most blockchains requires the purchase of a custom hardware device for key management (Ledger being the most well-known example).

Maybe through an accident of history, Bitcoin and other blockchains opted to use a less-common key-signing setup (secp256k1 curve) that makes their keys incompatible with today’s widely-used signing algorithms (P-256 curve). In the years since Bitcoin launched, security researchers have concluded that the "crypto-popular" curve and the "industry-standard" curve are both safe to use. Flow decided to let users decide which they prefer.

As such, Flow works just fine with Ledger and other crypto-specific hardware encryption devices, but it also works equally well with the hardware encryption device you already have in your pocket! That's right: Flow allows you to use the hardware security enclave included in nearly every smart phone and even many modern laptops. Full, military grade hardware security, with the devices you already own.

The lack of EVM native support of various setups, limits the users and developer to only on-chain implementation of signature verification, that is very expensive and sometime not even possible in a single transaction as it could result in gas consumption up to a million and transaction max gas limit is way smaller that.

The Ethereum community is also moving towards these features under the umbrella term of "account abstraction", and has plans to introduce them via smart contracts. We look forward to seeing this proposal finalized and adopted so that Ethereum users can have access to this functionality, although the additional gas costs associated with implementing this at the smart contract level are still not clear.

2. Address Allocation

As mentioned in the previous section, Flow accounts allow having multiple keys per account and naturally unlike EVM-based account addresses, Flow addresses are not derived from the public keys and each Flow account is allocated a unique compact and verifiable address at the time of account creation. This offers a number of benefits discussed below.

Unique, compact and verifiable

Every allocated Flow address by design has a robust way to validate the correctness of address baked into the address. Each address is represented by a 16-hex character (case-insensitive) and the internal checksum that prevents accidental mistakes in entering an account. Since the network allocates these unique addresses, there is no need to have very long addresses. 

In comparison, EVM addresses are derived from the public keys and in order to prevent potential chance of collision of the account address, it has to be represented as a very long 40-hex character string.  While there is a way of checksum for account addresses, it requires sending addresses in a proper case-sensitive way which is most of the time either not known by the developers and users or platforms that sign transactions often accept lowercase versions. This has resulted in a transfer of assets to the wrong address no one holds any key to it. If you check this Ethereum account, you will realize how frequently someone accidentally send assets to this account by making mistakes when accidentally they leave the destination empty. Many assets have ended up in this account, making it a big lottery that someone might win 1 day when they successfully generate a private key that can have that public address. This is not possible on Flow given not every combination of hex-letters is not a valid address and if a user accidentally tries to send assets to an invalid address, transaction would fail gracefully and assets won’t get locked up or lost. 

Network-specific allocation

Another benefit of Flows address is its network specific, i.e. an address that is valid on Flow’s Mainnet network is invalid on Flow’s Testnet.
Note that this doesn’t mean that you can’t use the same public key for multiple networks, you could still attach the same key to multiple accounts on multiple networks, but It boosts safety of the Flow accounts by design while maintaining flexibility. 

As mentioned earlier EVM addresses are derived from the public keys and if public keys are used on multiple networks they would yield the same address. We have seen many time many times a developer or a user has accidentally sent a transaction to the Ethereum Mainnet instead of a test network, resulting in an unfortunate loss of funds.

Mitigating fake account creation

Many blockchain applications and their developers have to deal with fake accounts every day. Either doing a token drop as a way of appreciation of early users of an application or security a DAO by diverse distribution of tokens, assumes that accounts are not fake. But unfortunately, generating a public/private key pair has no cost for anyone out there, thus constructing a massive number of accounts by anyone who is willing to do something with these accounts. So many accounts have been created with no asset just for the sake of benefiting from token drops, drawing Sybil's attacks against dapps.

This has been addressed by Flow’s storage model - Flow account addresses are allocated at the time of account creation given the newly created account has deposited a minimum balance of FLOW (native token of Flow network). This deposit is relative to the storage used by the account but has a minimum which alleviates the problem of massive account creation and corresponding attacks mentioned earlier. 

3. Contract Storage

Flow contract storage model has pushed the limits of smart contract developments in terms utility, safety and composability drastically. Listed are some of the features:

Multiple contracts stored per account 

Every Flow account can home any number of contracts. Each contract is stored under a unique name under an account. This makes credibility checking of an smart contract attached to a reputable account like NBATopShot way easier. Flow’s model of contract storage is more natural and flexible in comparison to EVM models where each account can only be one of these type: externally-owned account which won’t be able to hold any contracts, or contract account which could only hold a single contract. In the EVM world if you need to deploy multiple contracts you have to create multiple contract accounts. 

Open sourced smart contracts

Each contract on Flow is stored as a source code in Cadence and publicly available to anyone out there. On-chain storage of the source code instead of compiled byte codes makes it easier for developers and users to review the content of contracts and prevent malicious activities. It also opens up the space for composability. On EVM based blockchains like Ethereum, contract code is not stored on-chain. Only the compiled program of the contract is stored on-chain, which requires external applications to accept the source code from the community and cross-reference it with the byte code stored on the chain. This sometimes opens up the door for malicious activities that keeps the actual code hidden from users. One could claim this could provide privacy over the programs, though based on our experience almost every bytecode could be analyzed and decompiled but with more effort and complexity than you’d expect for a “public, open blockchain”.

Upgradability

Updates to fix bugs and patches to address vulnerabilities are necessary actions to maintain safety and liveness of any software and web3 applications are no different. Flow provides a safe way of upgrading smart contracts while protecting user assets. An smart contract is a collection of code (its functions) and data (its state). On Flow, data is stored directly under user accounts instead of living inside the contract, this enables option to update the code but protecting the data. Updates to the codes also has to follow specific set of rules that prevents accidental mistakes and malicious actions. As a decentralized app foundation become stronger and bug free over time and the community of a project grows the contract owner has the option to lock the contract for the future updates. 

On EVM world, every contract is immutable forever and not upgradable. The only possible change to a contract is removal through calls to `selfdestruct` which could results in loss of user assets and it seems it has done more harm than benefits. 

To be continued…

There is more to these design decisions, especially how accounts stores data (separation of code and data, storage paths, capabilities, to name a few) and how transactions are formed (separation of payer from authorizers, supporting multiple authorizers, expiry) which will be covered in a series of follow-up posts.