GIP-0080: Optimistic EBO #53
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(Edited the PR title to show the GIP number) |
RembrandtK
reviewed
Nov 30, 2024
| --- | ||
| GIP: "0080" | ||
| Title: Optimistic EBO | ||
| Authors: mono <[email protected]>, shaito <[email protected]> |
There was a problem hiding this comment.
Suggested change
| Authors: mono <[email protected]>, shaito <[email protected]> | |
| Authors: "mono <[email protected]>", "shaito <[email protected]>" |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| The EBO defines the source of truth for the block number corresponding to a new epoch in each indexed chain. It fetches the block for each epoch on each chain and records it on-chain on the protocol chain (Arbitrum One). An epoch is a period determined by the [EpochManager](https://github.com/graphprotocol/contracts/blob/main/contracts/epochs/EpochManager.sol), which lasts approximately one day but is measured in blocks. | ||
|
|
||
| Indexers use the EBO subgraph to get the block number for each chain and use it to build the POI, which is published when closing allocations to claim rewards. |
There was a problem hiding this comment.
While most people know what this is, I suggest at least once in the document being explicit.
Suggested change
| Indexers use the EBO subgraph to get the block number for each chain and use it to build the POI, which is published when closing allocations to claim rewards. | |
| Indexers use the EBO subgraph to get the block number for each chain and use it to build the POI (Proof Of Indexing), which is published when closing allocations to claim rewards. |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| - A Rust process that reads information from RPCs. | ||
| - A [Data Edge](https://github.com/graphprotocol/block-oracle/blob/main/packages/contracts/contracts/DataEdge.sol) contract where updates get posted (compressed and encoded). | ||
| - A [Subgraph](https://github.com/graphprotocol/block-oracle/tree/main/packages/subgraph) that indexes the Data Edge allows indexers to craft the POI easily. |
There was a problem hiding this comment.
Suggested change
| - A [Subgraph](https://github.com/graphprotocol/block-oracle/tree/main/packages/subgraph) that indexes the Data Edge allows indexers to craft the POI easily. | |
| - A [Subgraph](https://github.com/graphprotocol/block-oracle/tree/main/packages/subgraph) that indexes the Data Edge allowing indexers to easily craft their POI. |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| The optimistic approach allows off-chain agents to propose updates to the Optimistic EBO, which other participants can dispute by staking tokens or using alternative resolution mechanisms to align incentives and ensure accuracy. | ||
|
|
||
| For this, we will use [Prophet](https://github.com/defi-wonderland/prophet-modules/tree/dev), an optimistic, modular, and public-good oracle that abstracts the complexity of the proposal and dispute process while offering the flexibility to customize its functionality as needed. For more details on Prophet, refer to the documentation [here](https://docs.prophet.tech/content/modules/index.html). |
There was a problem hiding this comment.
https://heyoka.medium.com/dont-use-click-here-f32f445d1021
While at it, cleaner URL.
Suggested change
| For this, we will use [Prophet](https://github.com/defi-wonderland/prophet-modules/tree/dev), an optimistic, modular, and public-good oracle that abstracts the complexity of the proposal and dispute process while offering the flexibility to customize its functionality as needed. For more details on Prophet, refer to the documentation [here](https://docs.prophet.tech/content/modules/index.html). | |
| For this, we will use [Prophet](https://github.com/defi-wonderland/prophet-modules/tree/dev), an optimistic, modular, and public-good oracle that abstracts the complexity of the proposal and dispute process while offering the flexibility to customize its functionality as needed. For more details see [Prophet documentation](https://docs.prophet.tech/content/modules/). |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| - Any staked actor can propose an update for the EBO, which is published in a contract and remains open for a set period to allow for potential disputes. | ||
| - Any staked actor can also challenge the proposed update. If a dispute arises, the initial proposal is discarded, and a new one can be submitted. | ||
| - If a dispute occurs, the resolution mechanism is triggered, and the winner of the dispute will receive the counterparty’s bond as a reward. |
There was a problem hiding this comment.
To avoid certain attack vectors, this should be not the full bond, but half of it?
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| Operators can update the block number of one chain at a time, allowing for ongoing disputes and resolutions for each updated chain. This improves the system's scalability. | ||
|
|
||
| The [Detailed Specification](https://www.notion.so/DRAFT_I-GIP-0XYZ-Optimistic-EBO-74a0b9df7008464e9dc1215c46920213?pvs=21) section will provide further details on how contracts and off-chain agents interact. |
There was a problem hiding this comment.
That specification is not, and likely will not be, publically visible? We should only link to information in the public domain?
RembrandtK
reviewed
Nov 30, 2024
| The optimistic approach allows off-chain agents to propose updates to the Optimistic EBO, which other participants can dispute by staking tokens or using alternative resolution mechanisms to align incentives and ensure accuracy. | ||
|
|
||
| For this, we will use [Prophet](https://github.com/defi-wonderland/prophet-modules/tree/dev), an optimistic, modular, and public-good oracle that abstracts the complexity of the proposal and dispute process while offering the flexibility to customize its functionality as needed. For more details on Prophet, refer to the documentation [here](https://docs.prophet.tech/content/modules/index.html). | ||
| ~~~~ |
There was a problem hiding this comment.
Is this meant to be an HR? It seems to be causing subsequent text to render as code. Might need a blank line or another change.
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| The “overtake” mechanism improves resolution time and reduces Arbitrator calls, while the second answer (before resolution) improves the answering time to the request. | ||
|
|
||
| .png) |
There was a problem hiding this comment.
I wonder if better to cleanup image filenames to not have version suffixes such as "(1)", and not have spaces in the filename?
RembrandtK
reviewed
Nov 30, 2024
| - Anyone can dispute while the dispute window is open and if staked. To dispute, you need to post a bond. | ||
| - The resolution system is triggered once the participants have completed the maximum number of rounds. | ||
| - If the disputant “overtakes” the Min Bond, the answer is considered incorrect until the proposer responds. The proposer must overtake the disputant's Bond to escalate the answer further. This process can be repeated up to N times. | ||
| - After each dispute, the original update gets deleted and can be answered again, even before resolution. This option makes the process quicker for the requestor. This answer can be disputed using the same method as described above. |
There was a problem hiding this comment.
Likely want to use one consistent spelling in the document.
Suggested change
| - After each dispute, the original update gets deleted and can be answered again, even before resolution. This option makes the process quicker for the requestor. This answer can be disputed using the same method as described above. | |
| - After each dispute, the original update gets deleted and can be answered again, even before resolution. This option makes the process quicker for the requester. This answer can be disputed using the same method as described above. |
RembrandtK
reviewed
Nov 30, 2024
| - After each dispute, the original update gets deleted and can be answered again, even before resolution. This option makes the process quicker for the requestor. This answer can be disputed using the same method as described above. | ||
| - An honest proposer will be rewarded more for the won resolution than the original update. | ||
| - Disputers are incentivized to post the new answer, as they have already computed the query. | ||
| - The payment from the requester will end up going to the proposer with the correct answer |
There was a problem hiding this comment.
Term 'requester' is used just twice (with different spellings) and not defined. Is the requester the dispute raiser (might be simpler to say disputer)?
I believe that this should not be the entire payment.
RembrandtK
reviewed
Nov 30, 2024
| - **Min Bond**: Minimum amount required for five rounds of escalations to reach the Bond threshold, set at 11111 GRT. | ||
| - **Dispute Window**: An indexer's maximum response time to a dispute is 30 minutes. | ||
|
|
||
| These values are based on an economic security analysis that evaluates the potential gains from corruption across various attack scenarios. You can read the complete analysis [here](https://www.notion.so/Economic-security-considerations-1009a4c092c780b6afb1fa8bb8c266be?pvs=21). |
There was a problem hiding this comment.
Not publicy accessible. Also note: https://heyoka.medium.com/dont-use-click-here-f32f445d1021
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| - **Bond threshold**: The amount of stake that triggers a call to the Arbitrator (virtual bond in the escalation system), set at 100K GRT. | ||
| - **Round**: The maximum number of rounds a dispute can escalate, set at 5. | ||
| - **Min Bond**: Minimum amount required for five rounds of escalations to reach the Bond threshold, set at 11111 GRT. |
There was a problem hiding this comment.
Not sure if I missed it, how much higher does bond need to be relative to previous bond? (Or is that in Prophet docs?)
RembrandtK
reviewed
Nov 30, 2024
| - **Bond threshold**: The amount of stake that triggers a call to the Arbitrator (virtual bond in the escalation system), set at 100K GRT. | ||
| - **Round**: The maximum number of rounds a dispute can escalate, set at 5. | ||
| - **Min Bond**: Minimum amount required for five rounds of escalations to reach the Bond threshold, set at 11111 GRT. | ||
| - **Dispute Window**: An indexer's maximum response time to a dispute is 30 minutes. |
There was a problem hiding this comment.
Suggested change
| - **Dispute Window**: An indexer's maximum response time to a dispute is 30 minutes. | |
| - **Dispute Window**: The maximum time a proposer has to respond to a dispute, set at 30 minutes. |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| Interaction with Prophet requires the following modules that we will use/build to support the EBO: | ||
|
|
||
| - **RequestModule:** Used to request data in prophet. We will build the EBORequestModule which will allow users to create epoch-block requests to the oracle with the needed data for it. Compatible with partial requests (a subset of all the chains) and will contain the epoch number and the chain to fetch for that epoch. |
There was a problem hiding this comment.
I note sometimes ":" is bold too, other times not. I prefer not personally, but mainly suggest being consistent.
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| - **RequestModule:** Used to request data in prophet. We will build the EBORequestModule which will allow users to create epoch-block requests to the oracle with the needed data for it. Compatible with partial requests (a subset of all the chains) and will contain the epoch number and the chain to fetch for that epoch. | ||
| - **ResponseModule:** Used by data providers to answer requests. | ||
| - **DisputeModule:** Provides the framework to automatically solve disputes before going into the resolution module. The [BondEscalationModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/dispute/BondEscalationModule.sol) manages disputes by allowing users to bond tokens to vote for the user that is telling the truth. The only modification we need to add is that only one propose per request can be solved through escalation. We can safely remove this. |
There was a problem hiding this comment.
I am not clear if you are suggesting we need or that we do not need more than one.
Suggested change
| - **DisputeModule:** Provides the framework to automatically solve disputes before going into the resolution module. The [BondEscalationModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/dispute/BondEscalationModule.sol) manages disputes by allowing users to bond tokens to vote for the user that is telling the truth. The only modification we need to add is that only one propose per request can be solved through escalation. We can safely remove this. | |
| - **DisputeModule:** Provides the framework to automatically solve disputes before going into the resolution module. The [BondEscalationModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/dispute/BondEscalationModule.sol) manages disputes by allowing users to bond tokens to vote for the user that is telling the truth. The only modification we need to add is that only one proposal per request can be solved through escalation. We can safely remove this. |
RembrandtK
reviewed
Nov 30, 2024
| - **RequestModule:** Used to request data in prophet. We will build the EBORequestModule which will allow users to create epoch-block requests to the oracle with the needed data for it. Compatible with partial requests (a subset of all the chains) and will contain the epoch number and the chain to fetch for that epoch. | ||
| - **ResponseModule:** Used by data providers to answer requests. | ||
| - **DisputeModule:** Provides the framework to automatically solve disputes before going into the resolution module. The [BondEscalationModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/dispute/BondEscalationModule.sol) manages disputes by allowing users to bond tokens to vote for the user that is telling the truth. The only modification we need to add is that only one propose per request can be solved through escalation. We can safely remove this. | ||
| - **ResolutionModule:** Is the last instance to solve disputes and the ultimate source of truth. In our case we will be using the [ArbitratorModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/resolution/ArbitratorModule.sol) (Council) with a custom periphery contract so that The Graph's Arbitrator can push resolutions to the few disputes that can't be solved by escalation. |
There was a problem hiding this comment.
I think this is what is meant.
Suggested change
| - **ResolutionModule:** Is the last instance to solve disputes and the ultimate source of truth. In our case we will be using the [ArbitratorModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/resolution/ArbitratorModule.sol) (Council) with a custom periphery contract so that The Graph's Arbitrator can push resolutions to the few disputes that can't be solved by escalation. | |
| - **ResolutionModule:** Used as the last resort to solve disputes and the ultimate source of truth. In our case we will be using the [ArbitratorModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/resolution/ArbitratorModule.sol) (Council) with a custom periphery contract so that The Graph's Arbitrator can resolve escalated disputes. |
RembrandtK
reviewed
Nov 30, 2024
| - **ResponseModule:** Used by data providers to answer requests. | ||
| - **DisputeModule:** Provides the framework to automatically solve disputes before going into the resolution module. The [BondEscalationModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/dispute/BondEscalationModule.sol) manages disputes by allowing users to bond tokens to vote for the user that is telling the truth. The only modification we need to add is that only one propose per request can be solved through escalation. We can safely remove this. | ||
| - **ResolutionModule:** Is the last instance to solve disputes and the ultimate source of truth. In our case we will be using the [ArbitratorModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/resolution/ArbitratorModule.sol) (Council) with a custom periphery contract so that The Graph's Arbitrator can push resolutions to the few disputes that can't be solved by escalation. | ||
| - **FinalityModule:** Executes code when a request is fully finished. We will be forking the [CallbackModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/finality/CallbackModule.sol) to add the events and functions necessary to be able to index it into the subgraph. This new FinalityModule will behave like the previous DataEdge contract. It will receive finalized requests for each chainId-block and emit events for them for the subgraph to index. Gated functions will also be included to allow The Graph's Arbitrator to amend any errors or publish data needed in case an emergency happens. |
There was a problem hiding this comment.
Suggested change
| - **FinalityModule:** Executes code when a request is fully finished. We will be forking the [CallbackModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/finality/CallbackModule.sol) to add the events and functions necessary to be able to index it into the subgraph. This new FinalityModule will behave like the previous DataEdge contract. It will receive finalized requests for each chainId-block and emit events for them for the subgraph to index. Gated functions will also be included to allow The Graph's Arbitrator to amend any errors or publish data needed in case an emergency happens. | |
| - **FinalityModule:** Executes code when a request is fully finished. We will be forking the [CallbackModule](https://github.com/defi-wonderland/prophet-modules/blob/dev/solidity/contracts/modules/finality/CallbackModule.sol) to add the events and functions necessary to be able to index it into the subgraph. This new FinalityModule will behave like the previous DataEdge contract. It will receive finalized requests for each chainId-block and emit events for them for the subgraph to index. Gated functions will also be included to allow The Graph's Arbitrator to amend any errors or publish data needed in case of emergency. |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| ### **Subgraph** | ||
|
|
||
| - **The EBO** subgraph will contain the indexed data generated by the FinalityModule. It will register new data published from prophet and also amendments pushed by the Council. |
There was a problem hiding this comment.
Slightly strange bolding to me? Either just EBO or none needed?
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| ### **Periphery** | ||
|
|
||
| - **EBORequestCreator:** Will simplify and validate the creation of requests plus also allowing The Graph to add rewards to data providers in the future if they wish to. Checks that the requested epoch hasn't been requested before and that it has already started. The EBORequestCreator will also include the accepted chains. The Graph's Arbitrator will have the ability to add or remove them. |
There was a problem hiding this comment.
One minor tweak inline. Second question 'they' is 'The Graph'? Normally we identify a particular group and consider 'The Graph' more like an ecosystem than an entity or group? I think this sentance might need some adjustment?
Suggested change
| - **EBORequestCreator:** Will simplify and validate the creation of requests plus also allowing The Graph to add rewards to data providers in the future if they wish to. Checks that the requested epoch hasn't been requested before and that it has already started. The EBORequestCreator will also include the accepted chains. The Graph's Arbitrator will have the ability to add or remove them. | |
| - **EBORequestCreator:** Will simplify and validate the creation of requests and also allow The Graph to add rewards to data providers in the future if they wish to. Checks that the requested epoch hasn't been requested before and that it has already started. The EBORequestCreator will also include the accepted chains. The Graph's Arbitrator will have the ability to add or remove them. |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| # **Dependencies** | ||
|
|
||
| The [horizon staking contract](https://github.com/graphprotocol/contracts/pull/944), as described in GIP-0066, needs to be deployed to integrate with it. |
There was a problem hiding this comment.
I suggest should link to GIP-0066, however GIP-0066 never got merged onto https://github.com/graphprotocol/graph-improvement-proposals/tree/main/gips?
It does exist, resulting from GIP-0066 and GIP-0068 PR, as a commit that does not belong to any branch on the repository.
We should merge it onto main branch?
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| ### **Testnet** | ||
|
|
||
| We propose a trial period on testnet for the new Optimistic EBO implementation, with the participation of volunteer indexers running the new instances. The goal is to test as many connected chains to the system as possible. |
There was a problem hiding this comment.
Suggested change
| We propose a trial period on testnet for the new Optimistic EBO implementation, with the participation of volunteer indexers running the new instances. The goal is to test as many connected chains to the system as possible. | |
| We propose a trial period on testnet for the new Optimistic EBO implementation, with the participation of volunteer indexers running the new instances. The goal is to test as many connected chains with the system as possible. |
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| Our mission is to discover, partner, and empower innovators in the creation of open, permissionless, and decentralized financial solutions. Our pledge is to stand by our partners, supporting them in every way we can. | ||
|
|
||
| We have partnered with some of the most successful and promising protocols in Web3 – including Aztec, Optimism, Everclear, Safe, MakerDAO, Gitcoin, Layer 3, Eigen Layer, Keep3r, Reflexer, and Yearn – to find solutions to complex engineering challenges and help them reach their full potential. |
There was a problem hiding this comment.
Would be nice to link to them, so easy to look them all up. :)
RembrandtK
reviewed
Nov 30, 2024
|
|
||
| We propose a trial period on testnet for the new Optimistic EBO implementation, with the participation of volunteer indexers running the new instances. The goal is to test as many connected chains to the system as possible. | ||
|
|
||
| ### **Internal Reviews** |
There was a problem hiding this comment.
Great GIP, as you can tell my feedback is mainly minor tweaks rather than seeing anything of substance wrong.
I wonder if we want to avoid the 'process and planning' of this section being a part of a GIP, and try to keep the GIP about a technical proposal. Not a big deal in this case, but what if those plans or details change? Do we update the GIP? If so, unnecessary churn, if not, cannot rely on what is written here, and it might mislead.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GIP-0080: Implement Optimistic EBO
This PR introduces the Optimistic Epoch Block Oracle (EBO), replacing the current EBO with a decentralized, optimistic oracle design outlined in GIP-0080.
Key Changes:
This update enhances security and aligns with The Graph's goal of progressive decentralization.