Builders / Developers
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.
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 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 FCL (Flow Client Library) you can query for events.
This is documented 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:
FCL (Flow Client Library) enables applications to easily integrate with all FCL-compatible wallets and other services (e.g. profiles, private information, notifications). This offers developers a strong foundation to compose their apps with existing building blocks. FCL is currently supported for browser applications, and will be extended to other platforms.
With FCL, you can:
- Integrate all compatible wallets without any custom code or code injection
- Authenticate users
- Query users' Flow accounts
- Send transactions (e.g. initializing resources, sending assets, purchasing, etc.)
- Sign transactions through wallet integration to avoid key management (especially helpful for non-custodial apps)
You can find details about accessing Flow mainnet here https://docs.onflow.org/access-api.
The access is via a GRPC interface. Transactions can also be submitted using the GRPC SendTransaction call. A GRPC client written in any language should be able to talk via the Access API. We have a Go SDK and FCL-JS (Flow Client Library) that can be used if you are using a Go based or a JS based client respectively.
The Mainnet and Testnet are two separate networks. The difference is which network will be undergoing the down time. Since the main application for NBA TopShot exists on Mainnet, only Mainnet sporks will affect the main applications uptime.
Currently NBA Top Shot runs on Mainnet and NBA Top Shot test app runs on Flow Testnet.
Temporarily, transactions on Flow are free - the node operators are receiving compensation via rewards issued by the network to ensure your transactions are correctly processed. In the future, you may pay a transaction fee yourself but, more likely, the dapp or wallet you’re using will pay those fees for you. Flow supports the ability for someone other than you to pay for your transaction (if you so choose otherwise, you’d acquire FLOW and indeed pay fees). These fees are for spam prevention and will be low and fixed for most transactions.
During the beta period, you will need to submit your contract to the Flow team for review and then you’ll be able to submit it to the network. As soon as you’ve tested your dapp on devnet and the Flow team has reviewed your contracts, you can deploy!
Info here: https://docs.onflow.org/dapp-deployment
During the beta period, you will need to submit your contract to the Flow team for review and then you’ll be able to submit it to the network.
After submission, a member of the review team will contact you to discuss how long the review will take, though the minimum timeline is usually 2-3 weeks.
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.
If you know the /public/ storage path to the FungibleToken.Balance capability for a particular FT vault type, you can borrow that and check its balance. If you wish to know which vaults an account has, you will currently have to check a list of well-known paths. There is an issue that may help with this in future - https://github.com/onflow/cadence/issues/208
If you know the /public/ storage path to the NonFungibleToken.CollectionPublic capability for a particular NFT type, you can borrow that and call getIDs() on it. If you wish to know which token collections an account has, you will currently have to check a list of well-known paths. There is an issue that may help with this in future - https://github.com/onflow/cadence/issues/208
Flow doesn't yet provide functionality to inspect all of the resources on an account, but it is possible to execute a Cadence script that checks for resources at known storage paths.
Instructions to generate an address are here: https://docs.onflow.org/flow-go-sdk/creating-accounts. You don't need a service account.
Is there a tutorial about how to access flow testnet? From scratch, getting testnet, Flow token etc..?
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.