🎙️Grace Period Increase Proposal (Deposition Signatures)

FSP: Grace Period Increase for Signature Deposition

Overview

Flare Time Series Oracle (FTSO) uses a commit-reveal scheme to ensure fair submission of data. In this scheme, providers commit data (e.g. price values) in one voting epoch (n) and reveal their submissions in the next epoch (n+1). The reveal window is for 45s and once it’s completed, medians are calculated off-chain and signed Merkle roots are submitted for finalization. The Flare Data Connector (FDC) uses the same 45s window for bit-voting. Based on the bit-voting result the signature of the Merkle tree of attestations is submitted.

Currently, there is a 10s grace period after the 45s reveal window allowing some time for providers to submit signatures for both protocols and data providers can submit signatures ideally in one submitSignatures transaction, but when one of the protocols needs more time for result of calculation, two transactions are issued. Increasing the grace period slightly would adjust incentives in order to improve system gas usage on the network. Parameters need to be adjusted on the level of Flare Systems Protocol (FSP). FIP.11 and SIP.05 allows for increasing this grace period should a need arise.

Rationale to increase grace period

There have been instances where data providers are having to make 2 submissions - one for FTSO and the other for FDC due to the limited grace period of 10s. This is because FDC Merkle tree calculations sometimes take a few seconds longer when compared to FTSO. Submitting signatures twice increases gas and impacts the overall efficiency of the protocol. In addition, the submitSignature transaction is subsidized only once per voting epoch per data provider. Consequently the change will contribute to a reduction of fee costs for data providers.

Increasing the grace period by 5s would allow sufficient time for FDC finalizations to complete and providers can make a single submission thereby making the system more efficient. Signature deposition is currently 45s to 55s. This would change to - 45s to 60s. Finalization would remain the same at - 45s to 65s.

Voting Process

~ An official request proposal posted in open forum on Discourse for MG members to voice their support or raise any concerns

~ The Flare Team will then initiate transactions from the polling contracts on Flare and Songbird for MG members to cast on-chain votes either for or against increasing the grace period after reveals

~ Voting is rejection based and would require 66% participation amongst all eligible MG members and more than 50% of the votes going against the proposal for it to be rejected. Otherwise, the Foundation will proceed with increasing the grace period on both Flare and Songbird sometime after the voting period expires

2 Likes

We agree to this proposal.

We will vote FOR.

FTSOCAN supports this proposal.

Makes sense… Anything to improve efficiency within the system is always welcome. FTSO London supports this proposal.

Agree with this proposal.

Aimlezz FTSO finds this proposal good

This is an easy YES vote!

Voted FOR in support of this proposal.

FTSOCAN has voted FOR the proposal, on both Flare and Songbird.

With the recent vote to increase grace period passing, we’ve now changed the suggested default configuration in the deployment repo:

github.com

GitHub - flare-foundation/flare-systems-deployment at v1.0.7

v1.0.7

Contribute to flare-foundation/flare-systems-deployment development by creating an account on GitHub.

If you wish to use the new suggested default, please run:

./populate_config.sh

~ We’ve also bumped the fsp-observer to reflect the above changes

~ Grace period changes are effective this epoch (304)

~ Providers leveraging the default are encouraged to update when feasible. However, it’s not critical as impact to rewards is expected to be negligible

~ Fixes for reward logic will be published by the end of epoch 304

Thank you