Not all transactions are equal, so throughput numbers alone doesn't tell the whole story. Flow’s transaction throughput depends on a variety of factors, such as networking bandwidth available to the nodes and optimizations in our implementation. The dominant factor is transaction complexity, impacted by the number of instructions your transaction executes, the number of ledger reads and writes your transaction performs and how many signatures have to be checked to confirm that your transaction has the required privileges. For benchmark loads of simple token balance transfers (essentially an addition and subtraction plus two signature verifications), our current implementation easily sustained a throughput of significantly more than 100 tps. However, we observed that transactions on Mainnet are generally considerably more complex (requiring several signature verifications; many ledger reads and writes; and running relatively complex computations). For the near-term future, 100tps seems like a realistic magnitude. We are working hard towards sustaining 100tps of the kind which are currently run on Mainnet. If your transactions are much simpler than the average Mainnet transaction, Flow potentially already satisfies your desired throughput. The best way to find out would be to test a benchmark set of your specific transactions on TestNet.
Flow targets 1 second block times but the protocol is still early in its development and further optimizations are needed to achieve that. As of Feb 2021, the rate of block finalization on Mainnet is 0.4 blocks/s; with a standard deviation of ±0.1 blocks/s. Hence, a new block is finalized on average every 2.5 seconds. Note that block height only has a loose correlation with time, as the block rate naturally fluctuates.
There are two block explorers live today. You can find them here:
Once you have connected to an access node, you can fetch information regarding accounts, contracts, blocks, collections, transactions, and events. You can also execute scripts to query the current state of the Flow blockchain.
These types are documented on the Access API page.
The SDKs expose Flow data as types. For example the Go Flow Block data type implementation can be found here:
You can query historical data and fetch contract code using the SDKs.
Flow allows you to actively query the state of the blockchain using scripts written in the Cadence programming language. You can find out more about Cadence here:
Running scripts and parsing their output is supported by the SDKs.
Scripts can access multiple contracts and accounts, calculate values, and ensure that data is correct using Cadence's type system. They can only access the current state of the blockchain.
You can download the FCL (Flow Client Library) here:
Here are examples of querying an access node at the bottom of this page:
Here are examples of creating a script and Cadence data types:
And here are examples of parsing script output:
You can download the Go SDK here:
To connect to an access node you will need to provide a URL to the SDK. testnet: access.devnet.nodes.onflow.org:9000 mainnet: access.mainnet.nodes.onflow.org:9000
You can find examples of querying an access node at the bottom of this page:
You can find examples using the emulator that can be adapted to use an access node here:
And here is an example of using a script:
For an example of implementing access node communication using another programming language, see "Interact with Flow using Ruby" by Daniel Podaru: https://www.onflow.org/post/interact-with-flow-using-ruby
Flow transactions can emit informative "events" containing data intended to be used by off-chain observers. Events can be used to trigger backend or UI events, for example.
Note that a single transaction may emit many events, and that the order of events may surprise you if a non-standard transaction is being used. Event parameters may be optional, which means that they might be nil in some scenarios. All of this means that you must be careful when parsing events.
Events are implemented within Flow smart contracts using the Cadence programming language.
You can find out more about events in Cadence here:
As an example of the kinds of information events can contain, see the documentation of the events that the staking protocol emits:
To consume events, you must query a Flow Access Node and specify the type of event and the range of blocks you wish to fetch those events from. You can then parse any returned events and handle the information that they contain.
Once you connect to an Access Node using the Go SDK you can query for events.
This is documented here:
And there is an example of usage here:
Once you connect to an Access Node using the FCL (Flow Client Library) you can query for events.
This is documented here:
https://github.com/onflow/fcl-js/tree/master/packages/sdk#getevents-usage And there is an example of usage here:
Currently, we only provide Go and FCL-JS (Flow Client Library) for Flow. For an example of accessing the Flow blockchain and consuming events from it using another programming language, see "Interact with Flow using Ruby" by Daniel Podaru:
Once you complete a successful staking or delegation request, your tokens are sent to the staking contract. Your tokens are not lost - they are staked! To view your active stake or delegation, navigate to the Stake & Delegate page on Flow Port (left side bar, or this URL + your address after the last slash (https://port.onflow.org/stake-delegate/)
What do I do when I get this error: Node start up issue - could not process block proposal: invalid extension of protocol state?
It sounds like you didn't wipe your
data folder? Turn off your node, remove the
data folder and restart the node.
No errors should be considered acceptable. If there are ones that are constantly recurring, please bring it to our attention, and if we determine that they are not truly errors, we will adjust the logging to reflect.
There is an access node for you to develop against on the testnet/devnet. You can learn more about it here https://docs.onflow.org/dapp-deployment/testnet-deployment#accessing-flow-testnet
Yes, an access node is publicly accessible to submit transactions and read data from the blockchain. If you’d like to access the devnet access node to build against, you can do so here
Is it possible to add multiple public keys to a given account/address so that it can be controlled by more than one private key?
Yes, accounts support multiple, weighted keys, here
fun addPublicKey(_ publicKey: [UInt8])and
fun removePublicKey(_ index: Int) functions.
Accounts are created with associated keys. There can be multiple keys on an account. To execute transactions from the account, a total of 1000 weight keys need to sign. The account holds a field for FLOW balance. When transactions move flow, that balance is updated by the protocol. The account also holds place for storage and contract code.
FLOW supports a variety of signature schemes for adding keys to an account.
Instructions to generate an address are here: https://docs.onflow.org/flow-go-sdk/creating-accounts. You don't need a service account.
You can query the access API to get events for a block range. See Access API spec here: https://docs.onflow.org/access-api.
You can follow Flow node software releases here: https://github.com/onflow/flow-go/releases.