So, How Are Accounts on Flow Different from Accounts on Ethereum?

October 16, 2020

This blog post is for developers learning about the Flow blockchain.

Developing use cases on different blockchains can be quite daunting at first, especially when each blockchain presents a whole new architecture to understand and then build upon. In this blog post, we’ll explore how accounts on Flow are different from accounts on Ethereum

Moving forward, we'll assume that you have basic knowledge in the field of blockchain and cryptography.

So, let’s get started!

An Ethereum account is derived from a private key. An Ethereum private key is a hex number of length 64 (256 bits / 32 bytes). Keep in mind that the chances of guessing the same number as an actual Ethereum account are REALLLLYYYYYYY small. Formally speaking, the odds of guessing an Ethereum private key is 1 in 115 quattuorvigintillion (1075). Or, simply speaking: 1/2^256. Let’s try to imagine this number; Adrian Bednarek compares the task of identifying a random Ethereum key to choosing a grain of sand on a beach, and later asking a friend to find that same grain among a "billion gazillion" beaches. Crazy, isn’t it?

Once a private key is successfully generated, mathematical operations are performed on it to derive a public key. And finally, the public key is subjected to some more mathematical operations to derive a valid address. 

Note that the above mentioned process is one-way. It is impossible to generate a private key from a given address.

In short, that’s how you generate an account on the Ethereum blockchain.

Now let’s take a look at accounts on Flow.

The notion of ‘account’ is very different on the Flow blockchain. On Flow, an account is auto-generated by the blockchain and can support multiple public keys. 

To create an account on Flow, first public and private key pairs have to be generated using either P-256 or secp256k1 ECDSA (Elliptic Curve Digital Signature Algorithm) curves (see the compatibility table here), and then a transaction has to be submitted to the blockchain. By virtue of this transaction, a fresh account storage is initialized and the generated keys are then assigned to this account. To learn more about account generation on Flow, see this.

Each account on Flow may have 1 to n public keys associated with it, and corresponding to each public key there will exist a private key closely held by the account owner. Each key has an associated weight ranging from 1 to 1000. When transactions are signed, the aggregate weight of the signing keys must be greater than or equal to 1000.

Smart Contracts on Flow

On the Ethereum blockchain, smart contracts are deployed to their individual accounts. Such an account does not have a private key. However, on the Flow blockchain, an account is analogous to a container. In other words, smart contracts are a part of an account and this account can have multiple, deployed smart contracts at the same time. (Note: In the future mainnet will support multiple smart contracts but at present, it just supports one.) The Flow blockchain also gives developers the power to delete a smart contract (if it is not being used elsewhere) using the private key of the account to which the smart contract belongs.

Resources as first-class citizens in Flow

Flow supports a new paradigm of programming called “resource-oriented programming” using Cadence (a programming language to build on Flow). Cadence makes it a lot easier for developers to create crypto assets similar to CryptoKitties. In formal terms, such assets are known as resources. A resource is a special type within Cadence that is governed by strict move semantics. Resources can only exist in one location at a time, cannot be copied, and cannot be accidentally lost or deleted.

As a developer, you have the ability to use resources from other accounts by borrowing from them. For example, you can borrow a crypto asset like a CryptoPokemon from its creator and use it freely for your own purpose (with the owner’s permission of course). For a developer to allow access to his/her resources, the developer must create a capability. Capabilities are identified by a path and link to a target path, not directly to an object. Capabilities are either public (any user can get access), or private (access to/from the authorized user is necessary).

Users will often want to make it so that specific other users or even anyone else can access certain fields and functions of a stored object. This can be done by creating a capability.

However, note that the creator may delete this resource at any time they like. The good part is that the Flow blockchain prevents the creator from doing so if the resource is currently in use.

Now, let’s expand upon what a typical account on the Flow blockchain may look like.

Along with private keys and smart contracts, these resources also reside in the account. These resources can be found under ‘Storage’. This ‘Storage’ is indexed and can be accessed using APIs. Three domains exist on the ‘Storage’ block:

  1. /storage/: This is where resources are stored. Let’s try to understand this better by taking the Ethereum blockchain as an example. There are different tokens on Ethereum like USDT, MKR etc. Now the question arises; — can an Ethereum account keep track of all the tokens and smart contracts it has interacted with since its inception? Technically, yes using Ethereum logs. But, Ethereum does not provide a single store for an account’s assets across smart contracts. Fortunately, Flow does this. You can keep track of all the smart contracts your resources have interacted with.

Account has the ability to manage data 

  1. /private/: This allows other developers to manipulate storage in an account. However, this is not open for all developers. You must explicitly grant access to the developer. Access to stored data is governed by the tenets of Capability Security. This means that if an account wants to be able to access another account's stored objects, it must have a valid capability to that object. This is one of the reasons why the Flow blockchain is also an account-centric/resource-centric blockchain.
  2. /public/:  This lets you grant developers access to certain capabilities. An interface for these capabilities is published in this block. 

For example, you might want anyone to read which NFTs you own, so that capability (getNFTs(), for example) will go into /public, but you only want someone you are trading with to be able to access (tradeNFT(), for example) so you put it in /private.

One final important differentiator is that the smart contracts on the Flow blockchain are upgradable. There's a reason for this ‒ software can be hard to get right in the first go even if super talented teams created it. Therefore, on the Flow blockchain smart contracts can be deployed to the mainnet in a “beta state”, where smart contract code can still be updated. Once the smart contract creators are positive that their code is safe, they can finalize it, making the smart contract perfectly immutable.

In this post, we:

  • Explored how the structure of accounts on the Ethereum blockchain and the Flow blockchain vary drastically
  • Learned that the Cadence programming language will facilitate development on the Flow blockchain
  • Discussed what resources are and how are they placed within a Flow account

Hope you enjoyed reading! For more developer-focused content, be sure to subscribe to Decentology news.

Interested in building on Flow? Get started in less than 15 minutes with DappStarter.