Skip to content

Commit da8c354

Browse files
magurhmagurh
committed
Merge branch 'fip12-fdc' into 'main'
Fip.12: FDC See merge request flarenetwork/docs-team/governance-proposals!21
2 parents a7a3b33 + 9aa18c1 commit da8c354

File tree

2 files changed

+171
-1
lines changed

2 files changed

+171
-1
lines changed

‎FIP/FIP_12.md‎

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
---
2+
nav_order: 10012
3+
title: FIP.12
4+
---
5+
6+
# FIP.12: Add Support for the Flare Data Connector
7+
8+
| Type | Flare Improvement Proposal |
9+
| :----------------- | :------------------------------------------ |
10+
| Author | Flare Foundation |
11+
| Created | 22-Jan-2025 |
12+
| Document Status | Draft |
13+
| Majority Condition | 50% (required) |
14+
15+
16+
17+
## 1. Brief Description
18+
19+
20+
This proposal introduces the Flare Data Connector (FDC), a protocol that will allow applications to securely import external events onto the Flare networks.
21+
The introduction of the FDC will strengthen Flare's position as the blockchain for data.
22+
The goals of the proposal are to:
23+
24+
* Introduce the FDC protocol as an evolution and replacement of the State Connector.
25+
* Add the FDC protocol contracts to the Flare network.
26+
* Assign part of the network's yearly inflation to rewarding the FDC protocol to incentivise provider participation.
27+
* In its initial deployment, the FDC protocol will include support for attestation types required for the FAsset system, as well as EVM Transaction type.
28+
29+
The rewarding structure, minimum participation requirements, and implementation details are described in the next section.
30+
The FDC protocol is also described in more technical terms in the [whitepaper](https://flare.network/whitepapers/).
31+
32+
## 2. Technical Description
33+
34+
The goal of the FDC is to improve the range of available data in a trustless manner - trust will be derived from the underlying security assumptions of the Flare network.
35+
To this end, the FDC is a request based system that allows users to request attestations of external data be published on the Flare networks.
36+
This process is secured by Flare's data providers, so that when the user requires this data for e.g. a smart contract, interested parties can trust that the data is genuine.
37+
38+
The introduction of the FDC is needed on Flare to facilitate importing external data on to the network, solving two key problems:
39+
40+
* Trusting the data - the FDC is secured by Flare's providers, and thus can be trusted within the setting of the Flare network.
41+
* Filtering for useful data - the FDC is request based, so only data that is desired by a user is attested to, rather than wasteful monitoring or importing of all data from given sources.
42+
43+
The FDC protocol runs in voting epochs, synced with the FTSOv2 protocol.
44+
Each round of the FDC is roughly split into:
45+
46+
* **Collect phase:** the period during which users submit requests for the round.
47+
Note that a new collect phase starts immediately after the previous round's collect phase ends, ensuring that requests can be sent at all times.
48+
* **Choose phase:** during this period the data providers collate the requests and determine which ones can be confirmed in the current round.
49+
* **Resolution phase:** the set of confirmed attestation requests is published on-chain as a Merkle root, if enough data providers support the outcome.
50+
51+
The events represented by a published Merkle root are then considered true according to consensus on the network.
52+
53+
### 2.1 Attestation Types
54+
55+
In order to be correctly handled by the FDC, each attestation request must conform to one of the predefined attestation types, which specify the data source and response method for requests of the chosen type.
56+
Well-defined response methods must specify the type of information that is sufficient to prove the veracity of the attested event, which will be included in the attestation response.
57+
58+
59+
To begin with, the attestation types that will be supported by the FDC are chosen in preparation for the FAsset system, namely:
60+
61+
* `AddressValidity`: verify the validity of an address format on an external chain.
62+
* `BalanceDecreasingTransaction`: verify a transaction that either decreases the balance of a given address, or is signed by the source address.
63+
This attestation could prove a violation of an agreement.
64+
* `ConfirmedBlockHeightExists`: an assertion that a given block at specified height is confirmed on a specified chain.
65+
* `Payment`: a relay of a transaction on an external chain that is considered a payment in a native currency.
66+
* `ReferencedPaymentNonexistence`: an assertion that an agreed-upon payment has not been made by a certain deadline.
67+
* `EVMTransaction`: a relay of a transaction from an EVM chain together with a part of its receipt.
68+
69+
The `EVMTransaction` attestation type will support `ETH`, `FLR`, and `SGB` source chains, while the remaining attestation types will be supported on `BTC`, `DOGE`, and `XRP`.
70+
71+
72+
#### 2.1.1 Process to Add new Attestation Types
73+
74+
75+
The community can propose new attestation types, which would be accepted if they gain the support of the majority of the data providers.
76+
The process is as follows:
77+
78+
1. A request to include a new attestation type can be made on Flare's Discord server, in the `Discuss-Ideas` developer channel, which should include:
79+
1. A set of rules that precisely define the new attestation type.
80+
2. Motivation and potential software requirements (verifier server).
81+
3. A proposal for the base fee of such attestation requests.
82+
2. The Flare Foundation will forward the request to the [Management Group's forum](https://proposals.flare.network/FIP/FIP_2.html) and request a vote.
83+
3. If the majority of data providers support the new type and the base fee, the requested attestation type will be added to the system.
84+
85+
A more formal process for adding new attestation types will be introduced in a future proposal.
86+
87+
### 2.2 Rewarding Structure
88+
89+
FDC rewards will be provided for voting on and attesting to requests, with providers being rewarded relative to their total active weight.
90+
Rewards for the FDC will come from two sources.
91+
The first of those is the network's yearly inflation, previously used to reward data providers for their participation in the FTSO protocol.
92+
This will be modified in the following manner:
93+
94+
| Protocol | Proposed Inflationary Share |
95+
| :----------------------------- | :----------------------------- |
96+
| Staking | 30% |
97+
| FTSOv2 | 35% |
98+
| FDC | 35% |
99+
100+
The secondary source of rewards comes directly from the users of the FDC protocol.
101+
Each attestation request has an individual reward offer provided by the users in the form of a fee.
102+
Requests with higher fees will be prioritized by the system, being thus more likely to be attested by the data providers.
103+
These fees will be distributed among the data providers that responded to the requests.
104+
105+
### 2.3 Minimal Requirements
106+
107+
In line with [FIP.10](../FIP/FIP_10.md), the FDC protocol will introduce certain minimal participation requirements for the data providers.
108+
If these requirements are not met in a given reward epoch, a data provider may not be eligible for rewards in any of the network protocols, as described in the [FIP.10](../FIP/FIP_10.md) proposal.
109+
110+
Successful participation in a voting round requires getting rewards for that round (participating in correct Merkle root voting).
111+
Initially, the minimal requirements for a reward epoch will be defined as:
112+
113+
* Successful participation in 60% of all voting rounds in that reward epoch.
114+
115+
This percentage will gradually increase in the following months up to 80%, unless the requirement is deemed too restrictive.
116+
117+
### 2.3 Parameter Adjustments
118+
119+
In line with [FIP.11](../FIP/FIP_11.md), this proposal will also allow for future adjustments to the FDC protocol parameters.
120+
The Flare Foundation will directly communicate these changes to the data providers in a timely manner, before they are submitted for a vote within the [Management Group](https://proposals.flare.network/FIP/FIP_2.html).
121+
These changes include:
122+
123+
* Share of inflationary rewards.
124+
* Optimizations in reward distribution calculation, including reward split between signing and finalization, as well as the fraction of rewards burnt for providers who did not bit vote but did sign the correct Merkle root.
125+
* The minimal fee required for an attestation request.
126+
* Improvements to the bitvoting process.
127+
* Duration of grace periods.
128+
129+
130+
131+
### 2.4 Wider Ecosystem Implications
132+
133+
The FDC protocol offers a versatile framework for applications that require external data from both on-chain and off-chain sources, with far reaching implications for the Flare ecosystem.
134+
The FDC protocol will be a key part of the FAssets system, which will allow non-smart contract tokens to be used trustlessly with smart contracts within the Flare networks.
135+
136+
The FDC protocol recently demonstrated its capabilities in a [prediction market dApp](https://oipredict.xyz/about/) for verifying real-world events during the 2024 Summer Olympics.
137+
Note that while the necessary attestation type for this type of applications will not be initially supported, they could be added in the future as previously described.
138+
139+
140+
### 2.5 Deployment Strategy
141+
142+
Enabling the FDC protocol does not require a hard fork of the network.
143+
Instead, the new contracts listed in the next section will be deployed, and the inflation allocation updated as previously described.
144+
145+
During the 90 days following the deployment, the Flare Foundation may change some of the system's parameters to fine-tune it.
146+
147+
148+
## 3. Links to Code Repositories and Contracts
149+
150+
* [FDC client](https://github.com/flare-foundation/fdc-client)
151+
* [Flare system client](https://github.com/flare-foundation/flare-system-client)
152+
* [Smart contracts](https://github.com/flare-foundation/flare-smart-contracts-v2)
153+
154+
155+
## 4. Proposed Implementation Date Range
156+
157+
Implementation is expected to start shortly after the voting finishes.
158+
The exact date will be announced in time for FTSO data providers to prepare.
159+
160+
161+
## 5. Voting Details
162+
163+
To pass, the proposal requires a simple majority of votes in favor of it.
164+
165+
166+
## 6. Deadline for Voting
167+
168+
* **Notice period**: 24-January-2025 to 27-January-2025
169+
* **Voting period**: 28-January-2025 to 03-February-2025

‎index.markdown‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,6 +29,7 @@ Proposals aimed at improving the Flare network.
2929
| 9 | [Introduce FLR Protocol Emissions](./FIP/FIP_9.md) |
3030
| 10 | [Add an Incentive Structure for Participating in All Protocols](FIP/FIP_10.md) |
3131
| 11 | [Optimize Rewarding Structure and Adjust Protocol Parameters](FIP/FIP_11.md) |
32+
| 12 | [Add Support for the Flare Data Connector](FIP/FIP_12.md) |
3233

3334
## Songbird Improvement Proposals (SIP)
3435

@@ -57,7 +58,7 @@ Proposals aimed at improving the Flare network by being tested first on the Song
5758
| 6 | [Add Support for the Flare Systems Protocol and FTSO Scaling](STP/STP_6.md) |
5859
| 7 | [Add Support for FTSO Fast Updates](STP/STP_7.md) |
5960
| 8 | [Update FTSO Data Feeds and Define Process to Add New Ones](STP/STP_8.md) |
60-
| 9 | [Add Support for the Flare Data Connector](STP/STP_9.md) |
61+
| 9 | [Add Support for the Flare Data Connector](STP/STP_9.md) |
6162

6263
<style>
6364
table thead tr th:first-child {

0 commit comments

Comments
 (0)