contracts icon indicating copy to clipboard operation
contracts copied to clipboard

Validate the POI is from the canonical chain and close to chain head

Open abarmat opened this issue 4 years ago • 5 comments
trafficstars

Summary

The current function signature for closing an allocation is closeAllocation(address _allocationID, bytes32 _poi). This doesn't allow an Indexer to specify the block for which they are providing a ProofOfIndexing. If their transaction gets mined later than they expected, due to congestion in the network for example, then it's possible they might accidentally submit a bad PoI.

In addition to that, the current arbitration charter allows to present a non-fresh POI from the start block of an epoch, this can cause issues by having indexers that are not incentivized to be indexing close to chain-head.

Solution

Allow the indexer to pass the poiBlockHash for the presented POI, then check that the blockHash is included in the canonical chain within an amount of blocks. Update the AllocationClosed event to add the poiBlockHash.

Original proposal in: https://forum.thegraph.com/t/require-that-more-recent-pois-are-submitted-in-order-to-collect-indexing-rewards/2500

abarmat avatar Sep 23 '21 14:09 abarmat

Is 256 blocks enough time, or does it create a very narrow window when it is possible to close allocations (the first 256 blocks of the epoch)? Also worried that this on-chain validation here won't extend to indexing other chains, which we want to support soon.

azf20 avatar Nov 11 '21 11:11 azf20

@azf20 the max blocks are 256 which is roughly one hour, and about 50 min post merge. For the context of data freshness I think it is enough, while it can be challenging to increase if we ever need to.

The on-chain validation is very Ethereum specific, if we were to validate through a contract that some blockhash presented is from the canonical chain in the context of multiblochain we would need to do something else, like keeping track of that in a different contract and use that for validation. This is probably the main point against enforcing through the blockhash.

abarmat avatar Nov 11 '21 13:11 abarmat

Sure, I guess my thinking was as follows:

  • Close allocation needs to use the first block of the epoch (first block of a 24 hour period)
  • With this new validation, the block needs to be within the last ~hour on chain
  • This means that indexers will only be able to close allocations for one hour per day (start of the epoch plus one hour) This seems like quite a big constraint (vs. the current state where you can close an allocation at any time during the epoch)

azf20 avatar Nov 11 '21 14:11 azf20

The idea is to change the Charter so instead of using the first block of the current epoch you just need to present a fresh POI, that meaning one within the bounds of the 256 blocks.

abarmat avatar Nov 11 '21 15:11 abarmat

OK got it, that makes sense. Sorry I maybe landed in this PR without full context!

azf20 avatar Nov 11 '21 23:11 azf20

This would require a lot of changes to fix conflicts and to work for multiple chains with the EBO, so closing for now

pcarranzav avatar Dec 06 '23 19:12 pcarranzav