GIP: “0060”
Title: Early allocation closure
Authors: Ariel Barmat ariel@edgeandnode.com
Created: 2023-09-25
Updated: 2023-09-25
Stage: Draft
Category: Protocol Change
Dependency: GIP 0051
Abstract
The protocol imposes over indexers a restriction to wait for at least one epoch must pass before they can close allocations. We propose removing it and allowing them to manage allocations as they see more convenient.
Motivation
The protocol relies on a Rebate mechanism to ensure that indexers assign a security deposit in GRT proportional to the amount of queries they serve. Before the Exponential Rebate upgrade, it worked by summing all the query fees collected and stake allocated in one pool per epoch in which allocations are closed. As a consequence, it was essential to ensure that allocations last for at least one epoch to calculate the rebates using the Cobbs-Douglas function.
Coordination issues arises when a subgraph developer publishes a subgraph versions multiple times within the span of an epoch. Indexers would allocate to the first version and won’t be able to unlock their stake for use on the second version until the epoch ends reducing the network flexibity and liveliness. This condition might present more often on the L2 because transactions are cheaper and potentially more frequent.
With the introduction of GIP-0051 the rebate formula is now continuous and the pools were removed which opens the possibility of implementing this proposal.
Specification
The following lines will need to be removed from the closeAllocation() function of the Staking contract.
// Validate that an allocation cannot be closed before one epoch
uint256 epochs = MathUtils.diffOrZero(alloc.closedAtEpoch, alloc.createdAtEpoch);
require(epochs > 0, "<epochs");
The effectiveAllocation parameter that depended on the closedEpochAt variable does not longer exist since the Exponential Rebates upgrade, however, we still store closedEpochAt to mark the allocation as closed.
Indexing Rewards
Indexing rewards could still be collected in this proposal because the calculation is performed at the block number level. However, because presenting a valid POI depends on the Epoch Block Oracle for some chains and indexers won’t have the information after an epoch, we recommend setting the POI=0x0 or enforce a restriction on distributions directly in the code:
Calculate the epoch diff:
uint256 epochsDiff = MathUtils.diffOrZero(alloc.closedAtEpoch, alloc.createdAtEpoch);
And then change the rewards distribution section to:
// Distribute rewards if proof of indexing was presented by the indexer or operator
if (isIndexer && _poi != 0 && epochDiff > 0) {
_distributeRewards(_allocationID, alloc.indexer);
} else {
_updateRewards(alloc.subgraphDeploymentID);
}
Backwards Compatibility
The change keeps the current interfaces and is backward compatible. Indexer will be able to close their allocations on the same epoch they opened them immediately after governance approves the upgrade.
Copyright Waiver
Copyright and related rights waived via CC0.
