It’s been discussed among Indexer and Subgraph Developers that perhaps the cost of the curation tax is too onerous, particularly in instances where the subgraph needs to be upgraded multiple times due to bugs in the subgraph or due to the subgraph being under active development.
I’ve written a proposal to reduce the curation tax to 1% from it’s current value of 2.5%.
You can find the proposal on the Radicle GIPS repo under zerim/reduce-curation-tax or for convenience read a copy of the proposal here.
As this touches on some core economic parameters, I look forward to hearing community input from a number of stakeholder groups on the proposed change.
Brandon, I like this proposal. Just to clarify this would change the developer’s side of the tax to 0.5% and the curators migrate tax to 0.5%, correct?
Thinking out loud here: This point stood out to me,
The attacker earns indexing rewards on the subgraph up until indexing rewards are disabled on the subgraph. Even though allocations are measured in epochs, indexing rewards accumulate continuously on a per block basis. Thus the revenue from an attack is determined by the number of blocks until a Subgraph Oracle detects the unavailable subgraph and disables indexing rewards.
Has changing the per-block rate to a per-epoch rate been considered? Why or why not is that a possible solution?
Secondly.
I also am struggling to see the direct tie in to lowering the curation tax rate. While I have looked through the maths, and understand the point that is being made, I still don’t see how it ties back directly to a “need” to lower the curation tax rate. You mentioned how this attack vector was one constraint from holding back the lowering of it, but that implies that it should be lowered.
As you wrote in the post “in instances where the subgraph needs to be upgraded multiple times due to bugs in the subgraph or due to the subgraph being under active development.”. In my mental model of a role of a Curator, these two things are paramountly their “responsibility” (for lack of a better term). They should be curating which subgraphs do/do not have bugs, and are suitable for production use (versus needing frequent updates).
I may be missing some context, or perhaps something isn’t “clicking” for me as of yet, and I would love to be pointed in that direction.
Wouldn’t slashing a curator when they remove signal/ unsignal work better if you’re trying to mitigate Subgraph Witholding Attack? You could decide if the curator has actually attacked the network and slash them with a penalty at that time (when they withdraw). It would also motivate Curators to look more deeply into what they’re signaling on. Just an idea.
Changing the per block rate to a per epoch rate would be tough as it would change how the rewards manager works. Likely it would be too much work, to fix this scenario of this attack. It could be something considered in another GIP though
Yes I don’t think we provided enough context here. Mainly the problem is that the consensus around Subgraph Developers is that the fee is too high. The 2.5% was originally chosen before the network launch, to protect against this attack, and we had to assume what numbers the live network would end up with. So now that curation is live, and we have confirmed we could lower it, we are in a position to lower the tax if needed.
It might be worthwhile for us to do a Snapshot poll and vote on this. Because when I say Subgraph Developers are complaining about the high tax, it is from personal experience talking with a few of them - I think getting a public vote would be great.
There are ramifications to this - mainly that it will be 250% cheaper to spoof subgraphs, and distract Indexers with new Subgraphs they need to watch for. Indexers commenting on this aspect would be helpful.
I am in favor of this GIP. I think the friction against subgraph developers is not good this early in the network. Some of them have been baffled by the fees they need to pay - and when I put myself in their shoes I agree. Upgrading a subgraph with 1,000,000 GRT will cost the developer 12,500 GRT at todays taxes. I feel with the original 2.5% we overshot, and now the 1% is appropriate, but still incurs a large enough tax.
Curators already pay a 2.5% tax upon entry. The choice is really between taxing upon entering, or taxing upon exiting, as there is no need to tax twice - it is just added overhead.
I think the dynamics of the attack would only change slightly if the tax is moved to the exit, I think what would happen is the attack would actually be 2.5% more effective, since the attacker does not lose 2.5% at the start of their curation.
We’d have to make sure we mitigate the risk of developers updating to mainnet before they test it out(which happens often on hosted service). Otherwise the reduction in tax ends up being zero sum if they publish more often.
Has changing the per-block rate to a per-epoch rate been considered? Why or why not is that a possible solution?
In addition to what Dave said, this carries the risk of letting the attacker time their signal and allocation towards the very end of an epoch and receiving a full epoch’s worth of rewards instead of just a few blocks. There might be other book-keeping we could do to mitigate this, but this adds complexity.
I also am struggling to see the direct tie-in to lowering the curation tax rate. While I have looked through the maths, and understand the point that is being made, I still don’t see how it ties back directly to a “need” to lower the curation tax rate.
You’re correct that the math doesn’t justify a need to lower the curation tax, only establishes a lower bound. At this point, as @davekaj noted, the need is anecdotal based on feedback that has come in from subgraph developers.
I don’t know of a way of mathematically proving a “correct” level of curation tax, though one thing we could do w/ more time would be to do a full accounting of the costs to subgraph developers of using the decentralized network and making sure they are not excessive when compared to centralized alternatives.
If we do adopt the change, we may assess whether we have lowered the curation tax by too much:
We see instances of the attacks that Curation Tax was designed to mitigate.
Indexers provide feedback that the costs of indexing subgraphs that upgrade too frequently for a given amount of signal are excessive.
In some ways, #2 actually seems self-correcting in the sense that I would expect Indexers to simply increase the threshold of signal + query fees that they require of subgraphs before indexing them, which in turn would again increase the total costs to subgraph developers.
This proposal has advanced to a Community Snapshot Vote. Cast your vote here to share your opinion on whether you support a curation tax reduction from 2.50% down to 1.00%
To add on to @cryptovestor’s response, here are some thoughts to think about engagement levels and building reputation in the community that can help achieving your goals.
We also have active discussions on specific delegation enhancements listed in the prioritization list that @cryptovestor refers to. The Indexer Cut Simplification Proposal is very much geared towards the delegator community and you are welcome to join the discussions there.
In addition to what @cryptovestor and @Oliver have said, I’ll note that Subgraph Developers are the primary way in which value flows into The Graph ecosystem, by building dapps that integrate subgraphs published to the network and send query fees.
By unblocking the UX and cost hurdles they’ve had with migrating from the hosted service to the decentralized network, we aim to benefit every other role in the ecosystem (rising tide raises all ships, and all that).
That being said, at the E&N offsite 2 weeks ago, we brainstormed a number of ways that we can address some of the feedback that has accumulated from Delegators, and you can expect to see some proposals in the forums on this topic in the not too distant future.
