FAQ (2024)

Composability refers to developers building on top of shared standards - for example: contract standards like those that define fungible and non-fungible tokens or integration standards like the Flow Client Library (FCL) - or shared resources like an existing user base (i.e. community), public data, or existing platforms.

This opportunity for integration allows developers to jump start their own applications and ecosystems by building on existing infrastructure without platform risk (i.e. the risk that the service built on could be turned off). This is something made uniquely possible by standards and resources existing on decentralised blockchains like Flow.

Jesse Walden of a16z says ""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

The Flow Architecture defines an Access role specifically to provide cryptographic proofs of transaction outcomes. Furthermore, Access Nodes are also designed to answer general state queries and supply proofs of correctness. Client software works with Access 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 Access 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 a technical paper. 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 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.

When porting dapps from Ethereum to Flow, the following should be considered:

1. ACID properties can be assumed, just like on Ethereum. Thus, all dapps can assume a single shared state space, and don't need to be rearchitected to support a sharded environment or asynchronous function calls.

2. The programming language for Flow is Cadence. It is not compatible with EVM. Thus, smart contract logic needs to be re-implemented. The effort for the implementation largely depends upon the context and complexity of the application. Porting will be simple for NFT-based projects primarily off-the-shelf use cases: transferring, minting, selling on secondary market places, royalties, etc. It will be much more involved if Ethereum-specific ecosystem tools and services were utilized. For instance, the stablecoins compatible with the Flow ecosystem might be different to the ones dapp builders used on Ethereum. Right now, Flow supports FUSD, tUSDT, and USDC.

3. The integration of blockchain interactions into web applications can be done with FCL, a JS library. While architecturally different, it accomplishes similar goals as web3.js. Web applications will need to be updated to support FCL (handling transactions, handling authentication, and handling queries to Flow).

4. The token standards for Flow are implemented differently to account for the resource-oriented programming model represented in Cadence.

5. The wallets compatible with the Flow ecosystem are not the same wallets users and dapp builders are familiar with. Their users accounts would need to be re-created.For a comparison of building blocks for common NFT use cases, please check out the Flow documentation.

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.

The Scalability Trilemma is an important conjecture made by Vitalik Buterin that is not formally proven, but is almost certainly correct for hom*ogenous 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 decentralised 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.

Yes. A very high level guide of building a Web3 app on Flow is available here.
‍

If you want to start building, here's a few hands-on resources:

• If you are just getting started, we recommend following the Flow App quickstart tutorial.
• If want to jump right in and tackle a more complex project, get a fully-fledged NFT marketplace up and running with the Kitty Items demo app.
• To learn how to write smart contracts using Flow's revolutionary new smart contract programming language, Cadence, explore the tutorials in the interactive playground.

The Flow Client Library (FCL) JS is a package used to interact with user wallets and the Flow blockchain. When using FCL for authentication, dapps are able to support all FCL-compatible wallets on Flow and their users without any custom integrations or changes needed to the dapp code.

It was created to make developing applications that connect to the Flow blockchain easy and secure. It defines a standardized set of communication patterns between wallets, applications, and users that is used to perform a wide variety of actions for your dapp. FCL also offers a full featured SDK and utilities to interact with the Flow blockchain.