The Flow team is excited to share community-focused Flow ecosystem priorities. Since the launch of The Flow blockchain in December 2020, multiple independent teams from various disciplines ranging from distributed systems to programming languages, cryptography, and game theory are constantly advancing the research and development of Flow. Flow’s ecosystem has grown from a small group of enthusiasts to a global community of over 10,000 developers, over 17 million user accounts, and over 2 million monthly active wallets.
An integral part of continuing the decentralization of Flow is collaborating with our community on how core elements of the network are built. To make it easier for Flow to collaborate across entities, different working groups exist for various focus areas. These groups enable teams in the community to contribute to different components in parallel and scale coordination more efficiently. The collaborative plan is executed by contributors worldwide, including but not limited to Dapper Labs, Graffle, Coinbase Cloud, Blocto, Lilico, Outblock, GetBlock, academic institutions, including the University of Waterloo and the University of BC, and other independent researchers.
The ecosystem priorities have been organized into several focus areas. Each area has a set of deliverable outcomes. Here you will find an overview of key improvements expected in each area and descriptions of the core functional components, links to associated academic research, status updates, and core contributors.
The Developer Tooling & Ecosystem working group is focused on making Flow the most user-friendly Web3 developer platform. Success for this group will translate into higher developer satisfaction, reduced friction, and ultimately more applications launched on Flow.
Flow requires robust tools that support the most important developer environments, simplify the development lifecycle, enable fast iterations, and increase developers’ confidence. This area focuses on improvements to various tools, including SDKs, libraries, CLI, Emulator, and the VSCode Extension. Specific projects include, but are not limited to:
Developer education is critical to onboard millions of Flow developers. There is a need to build best-in-class documentation and samples, and a cutting edge developer playground. This requires understanding developer journeys and information architecture as much as the content. Priorities for this working group are:
Mobile applications have the potential to increase user engagement and reach mainstream consumers through app stores. With Flow, mobile developers can improve security through support for Secure Enclave & Keystore, minimize their needs for backend service by building on-chain logic, and ramp up quickly to Cadence – Flow’s smart contract language inspired by modern languages like Swift and Kotlin. This focus area is concerned with bringing the value proposition to light by
Unlock progressive user onboarding with world-class mainstream experience
The self-custody is perhaps the single most important feature of a web3, but the next billion blockchain users don’t have self-custodial wallets yet. Flow has the potential to unlock the real barrier to mainstream adoption, which is first-time user experience (FTUE). For most new users, the crypto scene currently feels a bit like the wild, wild west. There is a myriad of situations where they are uncertain of how to interact with the wallet and they lack trust and security in the services they are attempting to use. Flow needs to provide tooling for developers to onboard users with wallet-less onboarding via email or social identities so they can get immediate value seamlessly and then upgrade to self-custody when they’re ready or as the app demands it.
Demonstrate service-less dapps to eliminate platform risks, create trust, and unlock new experiences
Flow was designed to enable new experiences through composable building blocks that improve transparency. Getting more on-chain logic on Flow is critical to enable this future. Flow’s account model, modern smart contract language, and multi-node architecture enable on-chain mechanics with great user experiences without needing backend services. This focus area will use gaming as the primary use case by delivering:
Flow is building a vibrant ecosystem of builders to fill essential web3 building blocks, like tools and services. The Developer Grants program is allocating FLOW tokens to support the development of these ecosystem gaps.
Some of the projects listed above are driven by Flow community members who received grants to support their efforts.
If you are interested in participating in the program, you can:
--------------------------------------------------------------------------------------------------------------
Flow contributors include: Bjarte Karlsen, Alexander Zwerner, Matt Hichana, Tyron Brand, Maggo, Emerald DAO, Inconfido, Flowser, Outblock, GetBlock, SoulMade, Dapper Labs, Dev Spotlight & independent researchers. The working group is building in public and coordinating via the Developer Grants program and GitHub.
--------------------------------------------------------------------------------------------------------------
The Cadence Language working group is focused on all things related to the smart contract language experience, including interactions with the account storage, security, and scalability of the network. Focus areas are designing, developing, and optimizing smart contract language and Flow virtual machine (FVM).
One of the top priorities for Cadence is to design and implement the first stable and long-term-supported release of Cadence (aka Stable Cadence). This would be a long-term process in which Cadence achieves feature completeness, the core smart contracts are sufficiently battle-tested, and the economics of the system are sufficiently understood to provide long-term support without suffering from any breaking changes and maintenance issues. Based on the feedback from the community so far, this milestone was separated into two phases:
If you have any thoughts or questions about the overall idea of Stable Cadence, please comment on the blog post or participate in Cadence FLIPs on GitHub.
The Cadence Language working group is collaborating with the Core Protocol working group to achieve the goal of 1000 transactions per second (TPS). There are several workstreams currently under development or consideration:
Cadence compilation will be a long-term investment that we will build in stages to deliver several benefits, including
The first few milestones should focus on the performance benefits of on-chain compilation, specifically the execution of pre-compiled contracts and evaluation of potential performance impacts of a parallel compilation of transactions.
If you have any thoughts, use cases, or questions regarding the Cadence experience, please participate in the open design meeting or use this Discord channel.
--------------------------------------------------------------------------------------------------------------
The current chair of the Cadence working group is Bastian Müller and the core contributors are Dapper Labs, NCC Group, Halborn and other independent contributors. The working group is building in public and coordinating via monthly public language design meetings, GitHub, and community FLIPs.
--------------------------------------------------------------------------------------------------------------
The Smart Contract Engineering group is focused on all things related to applied design, architecture, and security considerations when using Cadence for developing decentralized applications on Flow. Specifically, the group supports the evolution of contract standards and the establishment of design patterns, guidance and methods for composability and other best practices around extensibility and security.
Cadence brings together several novel programming concepts in the context of decentralized application development which can be challenging for builders to understand and adjust to. Lowering these barriers through improved documentation, examples/prototypes, online articles and other research and development (R&D) expands the Cadence knowledgebase and adoption. Current priorities include:
The Smart Contract Engineering group collaborates with stakeholders from across the community and Dapper Labs to establish new standards (i.e. NFT Storefront v2, and to support new proposals for standards over time.
The group works to ensure the engagement of stakeholders throughout the development of solutions such as standards, patterns, or models that simplify the work required of builders and strengthen the network effects of Flow. Efforts currently under development or consideration include:
The value of any standards, patterns, or practices to the ecosystem depends significantly on adoption rates, without which network effects remain muted. As such, this group also focuses on ensuring as smooth as possible onboarding to standards for the community. Current focus areas include:
--------------------------------------------------------------------------------------------------------------
The current chair of the Smart Contract engineering group is Josh Hannan and the core contributors are Dapper Labs and other independent contributors. The working group is building in public and coordinating via monthly Smart Contract Open House meetings, GitHub and community FLIPs.
--------------------------------------------------------------------------------------------------------------
Protocol working group responsibility is dedicated to the security, scalability, progressive decentralization, and maintenance of the different subsystems of the protocol.
It operates at the intersection of distributed byzantine fault tolerance systems, protocol economics, Cadence smart contract language, and Governance.
One of the top priorities is to improve the network throughput TPS to better support the growth and adoption of applications with high transaction volume. While increasing throughput is critical, it is essential that results from achieving this goal remain decentralized and secure. It's imperative that any performance gain does not raise the barrier to entry for node operators.
There is sufficient low-hanging fruit in the performance realm to expect 1000 TPS in the near future. The Core Protocol working group is focused on several workstreams:
Another important priority for the core protocol is improving the scalability and performance of the execution storage. These workstreams are being prioritized to tackle the long-term state bloating by:
Software upgrades and maintenance are an inevitable part of any decentralized service, and for Flow, these are achieved via “sporks.” A spork usually happens about once every two months, currently with a temporary downtime of roughly 90 minutes. Community node operators and the protocol engineering team are responsible for improving the network uptime, reducing spork maintenance windows and getting to the state of rolling upgrades with zero downtime. The current goal is to move toward a zero downtime protocol upgrade when no data migrations are required, which normally only occur when the data format has changed. This can be achieved through a height coordinated protocol upgrade, similar to strategies used by other chains. In the near term, a spork may still be required until the height coordinated upgrade process matures and if there has been an update to data storage format. Because of this, the current migration and sporking process are also being optimized, and it should be possible to spork within a 30-minute period when a spork does not involve any data storage format upgrade. Reducing spork frequency to every quarter plus frequent rolling upgrades will ensure that the protocol is providing more seamless upgrades without compromising the pace of innovation.
The Core Protocol working group is working on more concrete ideas for achieving zero-downtime state migrations and will update this page at an appropriate time.
At the moment, Flow's core protocol does not specify any means for permanently storing all of the execution state changes that it commits over time. The amount of data is too large to achieve this, plus it would be a waste of valuable on-chain storage for storing historical data. Introducing observer and archival nodes would allow users to extract data locally for archival and verification purposes. Still, there is a need for an economically viable solution to access historical data without running a full archival node, which currently requires full data center grade hardware. There are a few ideas on who will store the historical data including:
The P2P network can be designed to ensure that clients participating in these networks can do so with minimal networking bandwidth, CPU, RAM, and HDD resources. In the short term, historical access can be provided by Dapper Labs’ archival nodes. However, in the mid to long term, serving historical access through other protocols or community incentives will be more efficient.
We invite the community to propose additional features for Flow’s execution-state sync protocol. The goal is to enable valuable add-on services utilizing the execution state that are beyond the scope of the core protocol but require (small) additional protocol functionality to be implemented. The community can contribute to this workstream via the Flow developer grants program. If you would like to contribute, please get in touch.
Byzantine fault tolerance [BFT] refers to the network's ability to securely operate even in the presence of actively malicious (aka byzantine) nodes in a decentralized network, which is key to unlocking permissionless node operations. It necessitates that all nodes must be resilient to any conceivable malicious actions originating from the permissionless nodes. BFT can be partitioned into three classes of attacks: message-level attacks (including impersonation or masquerade attacks), protocol-level attacks (multiple individually-valid messages constitute a protocol violation), and spamming.
As a first step, a network-wide framework for mitigating impersonation or masquerade attacks needs to lay the foundations. A new BFT protocol for execution-state replication will complement the network's protection and close the remaining surface for protocol-level attacks by Access Nodes, Observer Nodes, and Archival Nodes, thereby enabling their permissionless operation.
In later steps, core contributors should focus on further hardening the execution-state replication protocol against large-scale spamming and DDoS attacks, thereby allowing us to further increase the number of permissionless Access, Observer, and Archival Nodes.
At this time, the Core Protocol working group is seeking peer reviews for the execution-state-replication protocol for spamming vulnerabilities.
Flow uses HotStuff, a leader-based consensus algorithm. Over the last two years, considerable research advancements have been made in this domain. Specifically, the Jolteon protocol (June 2021) improves on the original HotStuff [v6] in two important areas:
Jolteon's PaceMaker utilizes dedicated messages for BFT view synchronization, which substantially improves the protocol's resilience to a broad class of failure scenarios, including successive leader failures, network partitions, unfavorable bootstrapping conditions, etc. Jolteon's key advancements have also been adopted by the Diem team (formerly Facebook) resulting in DiemBFT v4 (August 2021).
After a comprehensive review of cutting-edge approaches, the Core Protocol team has decided to adopt Jolteon (with some minor revisions). Furthermore, the PaceMaker-generated Timeout Certificates are also a prerequisite for byzantine-resilient Epoch switchover in Flow. The research and implementation are already ongoing since the beginning of the year.
At this time, the group is inviting help to further modularize the Flow protocol code base. A standalone consensus implementation for research purposes that shares the code base with Flow's production implementation would be particularly helpful (see details here). Furthermore, we are grateful for contributions from the academic community regarding the optimal parametrization of the Jolteon PaceMaker (see details here).
The goal is to be fully permissionless for all node types, but the network can enable active ownership with an increasingly broad set of community node operators through progressive decentralization and a stepwise process. In short, we are committed to fully empowering any willing participant to contribute and benefit from their efforts within the Flow ecosystem. This is accomplished through progressive decentralization — a process in which we will relinquish control by degrees over time. Taking a step-by-step approach allows us to focus and create a path toward a secure network.
With the introduction of the Observer Node and, soon, the Archival Node, the network unlocks participation opportunities for everyone without any staking. Having your own node means you do not have to rely on third parties for the state of the network. You may not reap the same financial gains as the fully-staked nodes but you may see other benefits such as privacy, security, balanced load distribution, reduced reliance on third-party servers, and network decentralization.
The permissionless node operations for a staked Access Node will need a new operator selection algorithm that is transparent to the community. Extensive research has gone into implementing byzantine fault tolerance [BFT] protection against any attacks that may arise from a permissionless byzantine actor in the ecosystem. This workstream can unlock permissionless operations for other node types (Verification, Collection, Consensus) in the future.
At this time, the working group is seeking peer review and inviting bounty proposals for battle-testing the feature. If you want to know more, you are invited to get in touch!
Historically, to become a node operator, you would need to ensure you meet the minimum staking and the program requirements to be approved. While this manual process ensured the continued security of the network, the amount of $FLOW required to be eligible to become a staked node operator was extremely high, which ruled out many aspiring operators. The selection process also lacked transparency to the public. Flow should introduce a process of node operator selection which can relinquish control by degrees over time. This can be done in two steps:
The idea of staking slots is to build an automated process for including new nodes in the staking table while managing the max number of nodes per node type. This process can be extended in the future with an auction mechanism for selecting node operators in a fully permissionless way.
Reducing minimum staking requirements is still under research to ensure the stake is high enough to not compromise the network's security.
Flow’s execution state is stored in a merkle trie data structure. The current implementation of this in the Flow node software, called mtrie, resides fully in-memory and is optimized for high-performance applications on Execution nodes. Since the execution state is very large, there is a tradeoff between performance and node hardware requirements. As a result, Execution nodes require large amounts of memory (512 GB of RAM) to store the entire trie plus a small amount of history fully in memory.
For other applications like Archival nodes, storage capacity and relaxed hardware requirements are more important than performance so a scalable trie optimized for large data sets is desired. This would allow for nodes running on consumer-grade hardware but with large disks.
We would like to invite community contributions to this workstream via the Flow Developer Grants program.
Integration of Cryptography advancements
Currently, the core group is hardening the implemented cryptography primitives and protocols further to improve the byzantine fault tolerance of the chain. Such improvements include integrating the proof of possession (PoP) of the BLS private key of node operators into the staking process. PoP is the defense chosen by the protocol to secure the multiple BLS signature aggregations and the BLS-based SPoCK scheme. BLS signatures and BLS-based threshold-signature implementations are continuously being updated to include the latest performance advancements and improve their standard compliance. The Pedersen-based distributed key generation of the random beacon is also being updated to be more resilient against malicious behaviors.
Moreover, the protocol attempts to use a few additional cryptography research areas to improve the chain's security and performance. One such area is the BLS-based Specialized Proof of Confidential Knowledge (SPoCK), which is being extended to support aggregations and optimize the protocol's sealing mechanism.
Other possible research topics include exploration into crypto accumulators and vector commitments.
--------------------------------------------------------------------------------------------------------------
The current chair of the Core Protocol working group is Alex Hentschel and the core contributors are Dapper Labs, Coinbase Cloud, NCC Group, Halborn and Metrika. The working group is collaborating in the Core Protocol GitHub and in the near future will host a public R&D meeting to discuss updates to work streams, cross-functional brainstorming, and receive feedback from one another.
--------------------------------------------------------------------------------------------------------------
The Protocol Economics working group is responsible for the token economy, which optimizes token distribution, governance, and security of the Flow network. The group works towards designing incentive systems that reward users for adhering to the publicly stated rules of the network and penalize them for inappropriate behaviors. The group relies on mathematics, game theory, and economic theory to improve the design of staking, delegation, transaction fees, token distribution, and monetary inflation.
Flow has a multi-node architecture where all nodes specialize and fulfill a specific role in the operation of the network. Execution nodes (ENs) maintain state computation and have a cryptographically verifiable data store for all user accounts and smart contract states. However, other node types in the network – Collection, Consensus and Verification nodes – do not deal with state concerns. With this separation of roles and concerns, state bloating has been isolated to a handful of ENs that can scale independently without impacting other nodes in the ecosystem. ENs store the account state along with 100 previous blocks, exerting pressure on the actual storage requirements as new accounts and smart contracts on the network grow.
Storage fees were implemented to regulate the state's growth, limiting the maximum amount of storage each account could use. This incentivizes developers to use on-chain storage efficiently and avoid storing unnecessary data. While the minimum balance has been extremely low (0.001 FLOW) in the network's early onboarding days, the working group must revisit the storage pricing to account for current and future state growth. Any storage fee changes must be carefully executed to minimize the impact on Dapps in production and to nurture Flow as a cost-effective platform for future developers. This part of the ecosystem is under consideration and we will update this page at an appropriate time.
Recent work around segmented transaction fees introduced variable execution fees, which ensure fair pricing based on the impact on the network. For instance, heavier operations will require more resources to process and propagate transactions.
Similarly, this working group can explore and test a new model to enhance network security for spamming attacks with variable inclusion fees and surge pricing. A network surge may be applied when the network is either under pressure due to:
Currently, the network surge factor is fixed at 1.0. Costs for inclusion will be impacted by the byte size of the transaction and the number of signatures required. Most importantly, the fee-management experience for developers must remain intuitive and the network should continue to offer high throughput and scalability, such that Flow endures as a cost-effective platform for developers.
Flow, like many other blockchains, uses protocol-level rewards paid to the operators of nodes in its network. The original FLOW Token Distribution plan detailed a strategy of using 5 percent token rewards for the first 18 months, then suggested adjusting the rewards rate as decided by the community. Given the current macroeconomic headwinds faced by the industry and global economy, the Flow team released a proposal suggesting that the 5 percent inflation remains unchanged.
Flow faces the classic trade-off of minimizing the inflation rate to reduce the implicit cost of holding FLOW tokens with synchronously incentivizing the node operators to run nodes via sufficient rewards. The network must balance transaction fees, new token issuance, the minimum stake required to be a node operator, and the number of nodes in the system. All things considered, this part of the ecosystem is under consideration, and the page will be updated at an appropriate time.
While no single node is solely accountable for the network’s overall security, node operators are mandated to stake minimum financial security comprised of FLOW tokens for a protocol-defined lock-in period to disincentivize faulty behavior. For node operation to be an accessible and rewarding activity, the current minimum staking amounts must be revisited. First, the team would undertake a practical analysis of operator COGS over the last two years. Then, through a democratized process, decisions on the new staking thresholds would be made to maintain network security and promote decentralization, while making it worthwhile for operators to participate across different node roles.
At this time we are inviting other node operators to share their COGS analysis through this publicly visible forum.
--------------------------------------------------------------------------------------------------------------
The core contributors for this working group include entrepreneurial support organizations, non-profits, Dapper Labs and academic institutions including Berkeley, Purdue, UC Davis, and Rochester Institute of Technology. Any proposed protocol economics improvements are collaborated in public using Governance FLIPS. And in the near future will host a public R&D meeting to discuss updates to work streams, cross-functional brainstorming, and receive feedback from one another.
--------------------------------------------------------------------------------------------------------------
For Flow to continue toward progressive decentralization, it will require not only the distributed infrastructure but also the capacity to be maintained and governed over time by more node operators. The Protocol Governance working group operates at the intersection of all the other groups and is responsible for the development and governance of the network. This group is responsible for technical governance, which includes updating system parameters, rolling out larger-scale changes in the protocol, and fixing bugs.
With weekly improvements to the multi-sig signing of Flow transactions, processes, and automated network operations, it has become possible to expand the number of signers for multi-sig operations on Flow accounts. The Flow multi-sig signers should be from across the ecosystem and have an interest in the long-term development and health of Flow. Currently, two main accounts are used to manage parts of the protocol:
The staking reward system is ready to have automation turned on. Doing this will reduce the number of weekly transactions from the service account and improve the predictability of payment timing for stakers and delegators. With automation enabled, the service account can focus on less frequent transactions such as changing fees and assisting in sporks.
As the network matures, operations such as slashing validators for policy violations should be increasingly automated. Work can begin on slashing systems as well as validator payouts based on work done instead of simple staking. These ideas have yet to be formalized or implemented. We look forward to community involvement in the design of these features.
Flow Governance needs to expand its use of FLIPS to gather feedback and communicate governance priorities. Governance FLIPs will provide a standard mechanism for community members to propose changes actions taken by the Flow Service Account signers, execute certain actions such as adding and removing node operators, and proposing changes to Flow’s fee structures.
--------------------------------------------------------------------------------------------------------------
The core contributors include Dapper Labs, Blocto, Find.xyz, Outblaze, Animoca. Anyone is welcome to contribute to governing the protocol and community efforts. For more information please refer to the FLIPs repository and the Flow Governance Forum. And in the near future will host a public R&D meeting to discuss updates to work streams, cross-functional brainstorming, and receive feedback from one another.
--------------------------------------------------------------------------------------------------------------
Flow is approaching a pivotal point with faster ecosystem growth and contributions to multiple working groups as it continues to grow and mature. Going forward, the Flow team will release blueprints of ecosystem priorities on a regular quarterly cycle. This document of ecosystem priorities will always be a work in progress — a living document. By making information more accessible and organized, we can reduce the threshold for contribution and make collaboration easier.
If there is something you would like to report or see in this document, please do not hesitate to open a new issue under the GitHub project for a working group.
