TL;DR: Hear from delegator, Josh, about his journey into delegation on The Graph and what he looks for when evaluating which indexers to delegate to.
Opening remarks
Hello everyone, and welcome to the latest edition of Indexer Office Hours! Today is April 2, and we’re here for episode 151.
GRTiQ 162
Catch the latest GRTiQ Podcast with Red Sheehan, Protocol Research Analyst at Messari.
Repo watch
The latest updates to important repositories
Execution Layer Clients
- Erigon v2.0 New releases:
- v2.59.3 :
- This release sets the Napoli hard fork on the Amoy testnet at block #5423600.
- v2.59.2 :
- This patch release fixes an MDBX size/performance regression introduced in v2.58.0.
- v2.59.1 :
- Fixes for block production in Caplin.
- v2.59.3 :
- Arbitrum-nitro New releases v2.3.3 :
- This release improves EIP-4844 support. It’s a recommended upgrade for any L2 batch posters, along with anyone having inbox reader issues reading blob batches. It also improves batch poster support for parent chains that have unknown transaction types.
Consensus Layer Clients
Information on the different clients
- Prysm: New release v5.0.2 :
- This release has many optimizations, UX improvements, and bug fixes. Due to the number of important bug fixes and optimizations, we encourage all operators to update to v5.0.2 at their earliest convenience.
- In this release, there is a notable change to the default value of –local-block-value-boost from 0 to 10. This means that the default behavior of using the builder API / mev-boost requires the builder bid to be 10% better than your local block profit. If you want to preserve the existing behavior, set –local-block-value-boost=0.
- Teku: New release 24.3.1 :
- This is a recommended update for mainnet nodes with improvements to CPU and bandwidth issues observed since the Deneb upgrade.
- Nimbus: New release v24.3.0 :
- Nimbus v24.3.0 is a low-urgency upgrade that brings additional beacon API support and resilience to suboptimal network conditions.
- Lighthouse: New release v5.1.3 :
- This hotfix release includes several bug fixes related to the handling of blobs. Upgrading to this release should result in less cache misses, lower peak memory usage, reduced bandwidth, and greater stability. This is a medium priority release.
- We recommend that all users upgrade at their convenience. We particularly recommend upgrading if you are seeing either of the logs below.
- Mar 13 10:26:50.229 WARN Peer sent invalid response to parent request., reason: ExtraBlocksReturned, peer_id: ..., service: sync - Mar 24 23:20:56.001 WARN Did not advance head state reason: Err(HeadMissingFromSnapshotCache(...)), service: state_advance
Graph Stack
- Subgraph-radio: New releases 1.0.2 :
- Fixes unexpected message frequency where the expected behavior is that the batch message sending logic should be triggered roughly every 5 minutes, but instead sometimes the interval is ~5 minutes but there were prolonged times where 25 minutes would pass and the message sending function was not triggered.
Graph Orchestration Tooling
Join us every other Wednesday at 5 PM UTC for Launchpad Office Hours and get the latest updates on running Launchpad.
The next one is on April 10. Bring all your questions!
Blockchains Operator Upgrade Calendar
The Blockchains Operator Upgrade Calendar is your one-stop solution for tracking hard fork updates and scheduled maintenance for various protocols within The Graph ecosystem.
Simplify your upgrade process and never miss a deadline again.
Protocol watch
Contracts Repository
Network Subgraphs
- Activity Subgraph:
- Fix for latest crash (fix: missing ‘-‘ on some event IDs #13).
- Currently only fixed on hosted, but it will be released soon on the decentralized network.
Open discussion
Delegator Fireside Chat
This section of today’s session will be similar to the one we had with PaulieB two weeks ago.
- In this conversation, Josh, a delegator and a crucial part of our ecosystem, shares his valuable experience with delegation.
- He shared a few things that have been going well for him and what he would recommend for improvement.
- This was a dynamic opportunity for everyone to engage, ask questions about delegation, and gain insights from a delegator on making themselves more attractive as indexers.
Questions
1. Tell us about your journey into The Graph ecosystem and how you started delegating.
Answer
I initially got involved with The Graph in November 2021. I then started to learn more about the protocol, why it’s essential, and its mission and vision.
I became particularly interested and just knew that I wanted to get involved.
It wasn’t until July 2022 that I started to feel safe and comfortable about delegation, how the network could benefit, and how I could strengthen the network and participate.
So it took me seven months to familiarize myself and get to the point where I was ready to commit to delegating.
2. When considering which indexer to delegate to, which factors are the most important?
Answer
When you’re evaluating indexers, you want to strike a good balance between risk and reward.
What do I mean by that? I think we have to acknowledge the inherent risk involved in delegating as it relates to indexers slashing reward cuts or increasing fees. As a delegator, you also expect to be adequately rewarded for taking those risks.
As I alluded to in the introduction, the number one thing for me was to feel safe, comfortable, and reassured that I could be successful with this because, for myself and I think a lot of people who are maybe contemplating delegating as well as which indexer to delegate to, you know, people magnify risk in their brains. We have to be able to feel like the effort is easy.
3. Are there any requirements you favor regarding transparency, performance, and communication?
Answer
Let’s remove communication from the equation for now and focus on transparency and performance. Let’s start with transparency. You know you want an indexer that’s transparent about its operations, infrastructure, and performance.
I’m performance and results-driven in my everyday career, so how does that translate into delegation? I mean, you want to try to maximize your rewards, right? You want to make sure that your indexers aren’t missing the boat on closing out potential allocations.
So yeah, I’m looking at performance reliability. Potential metrics that others should look at are query fees and how often those are being changed.
Then, I pay attention to the rewards that other delegators are earning with that indexer over time just to get a sense of other delegators who are having positive experiences with the same indexer.
I pay attention to what kind of regular updates and any potential issues or maintenance.
Still, I’m paying attention to APY and trying to understand how meaningful this might be for me with my contribution to the network over time.
4. Do you delegate full time to being a delegator? To what extent do you keep an eye on these metrics?
Answer
Yes, I’m a full-time delegator.
Secondly, I’m paying attention to the metrics, but it doesn’t have to be that way. I think people should come up with the amount of time they feel is appropriate to keep an eye on what’s happening.
No Comments