TL;DR: Hear from delegator Josh as he talks about his delegation journey on The Graph and the parameters he uses when evaluating which indexers to delegate to.
Opening remarks
Hello everyone, and welcome to the latest edition of Indexer Office Hours! April 2, Issue 151
GRTiQ 162
Listen to the latest GRTiQ podcast with Red Sheehan, Protocol Research Analyst at Messari.
Content Review
Latest updates to important repositories
Execution Layer Client
Erigon v2.0 new product release:
v2.59.3 version:
This release sets the Naples hard fork at block#5423600on the Amoy testnet.
v2.59.2 version:
This patch release fixes an MDBX size/performance regression introduced in v2.58.0.
v2.59.1 version:
Fixed block production in Caplin.
Arbitrum-nitro new version v2.3.3:
This release improves support for EIP-4844. An upgrade is recommended for any L2 batch posters, and for anyone experiencing issues with the inbox reader when reading blob batches. It also improves batch poster support for parent chains with unknown transaction types.
Consensus layer client
Information about the different clients
Prysm: New version v5.0.2:
This version features many optimizations, UX improvements, and bug fixes. Due to the large number of important bug fixes and optimizations, we encourage all operators to update to v5.0.2 as soon as possible.
In this release, the default value of –local-block-value-boost has changed significantly, from 0 to 10. This means that the default behavior using the builder API/mev-boost requires the builder bid to be 10% higher than your local block profit. If you want to preserve the existing behavior, set –local-block-value-boost=0.
Teku: New version 24.3.1:
This is a recommended update for mainnet nodes and provides improvements to the CPU and bandwidth issues observed since the Deneb upgrade.
Nimbus: New version v24.3.0:
Nimbus v24.3.0 is a low-urgency upgrade that provides additional Beacon API support and resiliency for suboptimal network conditions.
Lighthouse: New version v5.1.3:
This patch release includes multiple bug fixes related to handling blobs. Upgrading to this release should result in fewer cache misses, lower peak memory usage, lower bandwidth, and improved stability. This is a medium priority release.
We recommend that all users upgrade at their convenience. We especially recommend upgrading if you see any of the following logs.
- 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 WARNING Head state not advanced Reason: Err(HeadMissingFromSnapshotCache(...)), Service: state_advance
Graph Stack
Subgraph-radio: New version 1.0.2:
Fixed unexpected message frequency where expected behavior was to trigger batch message sending logic approximately every 5 minutes, but sometimes the interval was ~5 minutes, but there were long periods where 25 minutes passed and the message sending functionality was not triggered.
Graph Orchestration Tools
Join our Launchpad virtual meeting time every other Wednesday at 5pm UTC to get the latest updates on running Launchpad.
The next one is April 10. Bring all your questions!
Blockchain Operator Upgrade Calendar
The Blockchain Operator Upgrade Calendar is your one-stop solution for tracking hard fork updates and maintenance schedules for various protocols in The Graph ecosystem.
Simplify your upgrade process and never miss a deadline again.
Protocol Observation
Contract Repository
[WIP/Experimental] Breaking change: Add subgraph dispute manager#965(draft)
Network subgraph
Activity subgraph:
Fixed a recent crash (Fix: missing "-" on some event ID #13).
It is currently only fixed in escrow, but will be released on the decentralized network soon.
Open discussion
Client Fireside Chat
This portion of today's meeting will be similar to the meeting we had two weeks ago with Paulie B.
In this conversation, Josh, a delegator and a vital part of our ecosystem, shares his valuable experience with delegating.
He shares some of the things that went well for him, as well as areas where he suggests improvements could be made.
This is a dynamic opportunity for everyone to get involved, ask questions about delegation, and get insights from delegators on how to make themselves more attractive as an indexer.
question
1. Tell us about your journey into The Graph ecosystem and how you got started delegating.
answer
I initially got involved with The Graph in November 2021. I then started learning more about the protocol, why it is essential, and its mission and vision.
I became particularly interested and just knew I wanted to be a part of it.
It wasn’t until July 2022 that I started to feel safe and comfortable with how the Delegated Empowerment Network could benefit and how to strengthen networks and engagement.
Therefore, I spent seven months getting familiar with and ready to participate in the GRT commitment delegation.
2. What factors are most important when considering which indexer to delegate to?
answer
When evaluating indexers, one looks for a good balance between risk and reward.
What does that mean? I think we have to acknowledge the inherent risk involved with delegation as it relates to the index maker cutting rewards or increasing fees. As a delegator, you are adequately rewarded for taking on those risks.
As I mentioned in the introduction, the most important thing for me is to feel safe, comfortable, and confident that I can succeed, because for myself, and I think a lot of people are probably thinking about delegating and which indexer to delegate to, you know, people magnify the risk in their brains. We have to be able to feel that the effort is easy.
3. Do you have any advice on transparency, performance, and communication?
answer
Now, let's remove communication from that and focus on transparency and performance. Let's start with transparency, you know you want an indexer that is transparent about its operations, infrastructure, and performance.
In my day-to-day professional life, I'm performance and results oriented, so how does that translate into empowerment? I mean, you want to try to maximize your rewards, right? You want to make sure that the indexer doesn't miss out on closing out on a potential allocation.
So yes, I'm looking at performance reliability. Potential metrics that others should look at are query charges and how often those charges are changed.
I then look at the rewards other delegators have earned over time using that Indexer, just to get an idea of other delegators who have had positive experiences using the same Indexer.
I pay attention to what kind of regular updates are coming as well as any potential issues or maintenance.
Nonetheless, I’m keeping an eye on the APY and trying to understand how much my contributions to the network will mean to me over time.
4. Are you a full-time delegate? Do you keep an eye on these indicators?
answer
Yes, I am a full-time client.
Second, I pay attention to metrics, but not all the time. I think people should take the time they see fit to pay attention to what's going on.
