Flow is a fast, decentralized, and developer-friendly blockchain. Brought to you by the team behind CryptoKitties, Flow is the foundation for entire ecosystems of consumer applications starting with games, collectibles, and the apps that interact with them. Flow is based on a novel architecture that achieves the performance required for mainstream applications without compromising decentralization – or sharding the network. This means developers on Flow can build secure and composable applications to enable new possibilities for billions of consumers around the world.
FLOW is the native currency for the Flow network, the exclusive token for staking, governance, payment of transaction fees, and the principal reserve asset on the network.
Yes. Flow was originally developed by Dapper Labs, the creators of CryptoKitties, NBA Top Shot, and the Dapper wallet. Today, less than 1/3 of total nodes are operated by Dapper Labs and a community-controlled service account governs key protocol factors.
Yes – the native token for the Flow network is FLOW. All decentralized blockchains use cryptographic tokens (cryptocurrencies) to ensure the security of the system. Flow is committed to a diverse and decentralized participation in the Flow Network, and therefore the distribution of the token, in compliance with securities law and other relevant regulatory frameworks.
You can start building on Flow immediately! Visit docs.onflow.org to get going.
Composability refers to developers building on top of shared resources such as an existing user base, data, security and running code. “A platform is composable if its existing resources can be used as building blocks and programmed into higher order applications. Composability is important because it allows developers to do more with less, which in turn, can lead to more rapid and compounding innovation.” – Jesse Walden, 4 eras of blockchain computing
Flow was explicitly designed to support games and consumer applications on day one, with the throughput necessary to scale to millions of active users.These goals necessitated a number of significant technical innovations:
A pipelined architecture that separates the jobs typically done by a single miner or validator across five different node types, significantly reducing redundant effort and improving efficiency.
A new cryptographic technique we call Specialized Proofs of Confidential Knowledge (SPoCKs) to address the Verifier’s Dilemma.
A single shared state for all smart contracts, ensuring that each transaction has full ACID guarantees. This unlocks rich interactions between smart contracts (“Composability”) and creates strong network effects for apps built on Flow.
Flow also introduces a series of important design choices to improve usability for developers and consumers alike. See the How Flow Works section of the Primer for more details.
The Flow Architecture defines an Observer role specifically to provide cryptographic proofs of transaction outcomes. Client software works with Observation Nodes to provide users with a view of the network that is accurate and secure, without requiring those clients to keep up with the torrent of traffic flowing through the entire network.
The number of Observer Nodes in the network has no fixed limit, which will support a practically unbounded number of light clients fetching full state proofs.
Specialized Proofs of Confidential Knowledge (SPoCKs) are a new cryptographic technique developed by the Flow team, formally defined in our Technical Papers. SPoCKs allow any number of provers to demonstrate to a third-party observer that they each have access to the same confidential knowledge. These proofs are non-interactive and don’t leak any information about the confidential knowledge itself. Each prover’s SPoCK is specialized to them, and can’t be copied or forged by any other prover.
Flow uses SPoCKs to address the Verifier’s Dilemma by requiring Execution and Verification Nodes to “show their work”. In order to get paid, these nodes need to provide a SPoCK showing access to confidential knowledge that can only be obtained by executing all of the transactions assigned to them.
All smart contracts and decentralized applications (“dapps”) built on Ethereum today share two important characteristics: they are architected assuming an ACID development environment, and they are written in Solidity, the programming language of the Ethereum Virtual Machine (EVM).
The first property holds on Flow: all dapps and smart contracts on Flow can assume a single shared state space, and don’t need to be rearchitected to support a sharded environment or asynchronous function calls.
The second property does not: while the EVM was a massive improvement over non-programmable blockchains, even Ethereum is moving towards a more flexible and performant programming model. Flow will not directly support the EVM, and you can expect more details about the Flow programming model this fall.
The workhorses of the Flow architecture are the Execution Nodes. You shouldn’t simply think of Execution Nodes as fast computers; each of them is likely to be an entire cluster of high-end server hardware colocated in a professional data center.
Execution Nodes are super fast and have very high staking requirements, but are only ever entrusted with executing the deterministic block transition function. All of the work they do is verified and confirmed by the network of Consensus and Verification Nodes.
Collectively, the Verification Nodes will confirm every part of the block computation many times over, but each individual Verification Node will only do a fraction of the work. For example, if there are 1000 Verification Nodes, each Verification Node would only need to check 4% of the total block for the entire block has been inspected 40 times over. Our Technical Papers provide the full details and security analysis of this approach.
The Scalability Trilemma is an important conjecture made by Vitalik Buterin that is not formally proven, but is almost certainly correct for homogenous blockchain designs. If every node in the network has the same role, you have to compromise on at least one of those dimensions.
Flow doesn’t “break” or disprove the Trilemma, it dodges around it. The trick is noting that, if we let different nodes participate in different roles, we can choose the right trade-offs for each part of the system.
Flow maximizes security and decentralization for the Consensus Nodes, the part of the system most vulnerable to Byzantine attacks. This limits their scalability, of course, but that isn’t actually a problem because we don’t ask the Consensus Nodes to do anything computationally expensive.
On the other hand, we crank up the scalability for Execution Nodes to dramatically increase computation throughput. This compromises the security and decentralization of those nodes, which we address by ensuring that every step of every transaction is confirmed by the high security and decentralization Verification Nodes.
For each node type, the Trilemma holds as expected, but the overall effect is a system where the weaknesses of one part of the system are more than offset by the strengths of the other parts.
Both Cadence and Move are resource-oriented. They enforce careful rules about how resource assets are managed, and are built with security and reliability as some of the most important considerations in how the languages are structured.
Move was designed “bottom up”, with a focus on performance and efficiency. It has a virtual machine and a compact bytecode that can be efficiently executed, leading to high scalability. However, the syntax is minimal, designed for machines first and humans second. Cadence was designed “top down”, with an emphasis on readability and clarity. It has an ergonomic syntax that is easy to learn, easy to use, and easy to audit. The differences allow us to explore ways that Cadence can complement Move.
Unlike other virtual machine environments (like EVM or WASM), the instruction set of the MoveVM supports resource types natively. This guarantees that resources, which are used to represent assets of value on Flow, are properly protected even on this lower level. Virtual machines and their instruction sets typically allow random access into memory, which is not suitable in a blockchain context, as this could allow transactions and smart contracts to perform malicious actions, such as duplicating or modifying protected assets.
We are currently finishing the implementation of our first version of Cadence, and have started investigating how to compile Cadence to the MoveVM. We have no timeline for when this integration will be completed.
The Flow and Move teams have an open line of communication to collaborate as the Flow team works to compile Cadence down to the MoveVM. Both teams are committing time and effort to ensure this work goes smoothly, and the results will be published as open source. The relationship between Flow and Libra is still in an exploratory phase.
Interoperability between blockchains is much more complicated than just sharing a language, but this is a great start. Flow is open and permissionless, so we expect multiple teams from the community to work on direct bridges between Flow and other blockchains.
The biggest difference between Libra and Flow is that Flow will be permissionless and fully decentralized, with a Turing-complete smart contract environment. As a result, there may be contracts on Flow that could not be supported on Libra without explicit approval by the Libra Association. That said, if both blockchains end up using the same version of Cadence, major sections of code should be portable with little to no effort.