The STP.06 and FIP.06 governance proposals will soon be open for voting. They include updates required to scale Flare Time Series Oracle (FTSO) capacity for both the Flare and Songbird networks.
The FTSO
The FTSO is a system running on Flare, which delivers decentralized data feeds to dapps on Flare without relying on centralized providers. Currently the only data feeds available are for cryptocurrency price pairs, for example BTC USD. The supported feeds are ADA, ALGO, ARB, AVAX, BNB, BTC, DOGE, ETH, FIL, FLR (on Flare), SGB (on Songbird), LTC, MATIC, SOL, USDC, USDT, XDC, XLM, and XRP.
Independent infrastructure providers, including Google Cloud, Ankr, and Figment, have an important dual role in the system: they are responsible for both securing the network as validators, and contributing to Flare’s enshrined oracles as data providers.
To achieve a secure, decentralized system, they retrieve data from external sources, such as centralized and decentralized exchanges, and supply it to the FTSO system. This information is weighted according to each provider’s vote power (amount of community delegated tokens), and a weighted median is calculated to produce the final estimate.
FTSO Scalability
The current FTSO (v1) is implemented mainly as an on-chain smart contract. We currently provide updates for 18 data feeds every 180 seconds.
To support new use cases requiring faster updates and a wider variety of data, a more scalable redesign of the system was required. With FTSO Scaling, data providers will be able to provide up to 1000 data feeds (cryptocurrency price pairs, stock prices, weather data, and more) every 90 seconds.
The proposed new design is more gas-efficient because calculations are performed off-chain and only a rolled-up representation of all the data providers’ results, known as a Merkle Root hash, is stored on-chain. Such a representation makes the on-chain data more lightweight and scalable than performing calculations on-chain and storing all individual prices on-chain.
The improved protocol enables more data feeds to be provided. At first, feeds for about 25 cryptocurrency price pairs will be added. There is also a plan to incrementally include more crypto assets such as stocks, bonds, commodities, and forex, based on developer demand.
FTSO Scaling should not be confused with FTSO Fast Updates, which will be the subject of a future governance proposal. FTSO Fast Updates will enable dapps to request and pay for data on demand with 1-2 block latency (approx 1-3 seconds). If the governance proposals are approved by the Flare community, the combination of FTSO Scaling and FTSO Fast Updates will deliver our vision for FTSO v2.
Role of the Flare Community
The Flare community will continue to engage with the FTSO in the same way. These changes are technical changes. You can continue to delegate to FTSO data providers and claim delegation rewards just as you did before.
Role of the Data Provider
With FTSO Scaling, data providers continue to supply useful information such as price pairs. Data that is too far from the median (outliers) continue to be removed. The resulting data estimates are rewarded and made available on-chain. Data providers continue to use a commit and reveal process that enables all data to be committed. The commit phase enables estimations to be submitted without some data providers being able to cheat by seeing other data provider estimations. The reveal phase enables data providers to access the committed estimations for verification.
If approved, FTSO Scaling will introduce two new phases: The Sign Phase and the Finalization Phase.
- In the Sign Phase, data providers filter out reveals that do not match commits. Only valid reveals are used to calculate the median feed values and rewards. The results are represented by a code (“hashed”) and the data providers sign it.
- In the Finalization phase, once a sufficient voting weight of signatures is submitted, any entity can collect them and submit them to the voting smart contract. A check is performed to verify whether the proposed signatures cumulatively reach the required weight threshold (at least 50% of the total weight of all eligible data providers). If successful, the Merkle Root is published on the voting contract for a given voting round ID. It then becomes available to all other smart contracts that can use the data to verify calculation results.
Rewards Split
As in FTSO (v1), data providers will continue to receive rewards for submitting data that is close to the median value. If the governance proposal is approved, when FTSO Scaling is fully implemented, the major share of the total available FTSO data provision rewards, 80%, will continue to be distributed to data providers who accomplish this.
Likewise, if and when FTSO Scaling is fully implemented, it will also reward submitting signatures in the Sign phase and triggering finalization in the Finalization phase. For the signature submission in the Sign phase, 10% of data provision rewards will be distributed to data providers who submit a single, valid signature. For triggering the finalization in the Finalization phase, up to five entities can carry out finalization: the first five that cause the threshold weight to be met successfully. 10% of the available data provision rewards goes to these data providers.
Penalties
FTSO Scaling penalizes data providers for Reveal Withholdings or Double-Signing:
- Reveal withholdings: Data providers must be able to verify that the hash of the revealed data matches the hash of the committed data. When the reveal for a commit is ommitted or it doesn’t match, it’s referred to as a Reveal Withholding and will be penalized.
- Double-signing: Providing invalid signatures or signatures for more than one result in the same voting round will be referred to as Double-Signing and will be penalized.
In both cases, the penalty will be 30 times the offending data provider’s expected relative share of rewards in that voting round, and it will be deducted from the total amount of rewards at the end of the reward epoch. The maximum amount that can be deducted is equal to the data provider’s total reward in the epoch. The deducted amount will be burned.
Deployment Phases
Scaling the FTSO system to allow up to 1000 data feeds will require a series of substantial updates. To provide time for the Flare Foundation to test and for data providers to adapt to the changes, if approved, the update will consist of a trial phase, a beta phase, and a deprecation phase.
During these phases, current and upgraded data providers will coexist. Current data providers are those running the existing FTSO (v1) code and upgraded data providers are those running the new code that includes FTSO Scaling. 70% of Flare’s total inflation still goes to FTSO data provision rewards, but it will be split among data providers in the following fashion:
- Trial phase: During this phase, reward allocation will not change: current data providers will continue to receive 100% of the FTSO data provision rewards distributed among them; whereas upgraded data providers will receive no rewards.
- Beta phase: During this phase, the Flare Foundation will update the Inflation contract so that current data providers will receive 50% of the total FTSO data provision reward allocation, and upgraded data providers will receive the other 50%. At this time, all data providers will be able to claim their rewards. For example, let’s say that during the beta phase, we have 100 FLR inflation for rewards. So current data providers will have 50 FLR distributed among them and upgraded data providers will have the following distribution among them: 40 for median closeness, 5 for valid signature submission, and 5 for contributing to finalization.
- Deprecation phase: During this phase, the Flare Foundation will update the Inflation contract again so that only upgraded data providers will receive rewards. Therefore, with the inflation amount in the example above, 100 FLR, upgraded data providers will receive the full distribution among them: 80 for median closeness, 10 for valid signature submission, and 10 for contributing to finalization.