TL:DR: The Moonbeam team talks about how indexers can best index and support the Moonbeam network, an Ethereum-compatible smart contract parachain on Polkadot.
Opening remarks
Hello everyone, and welcome to the latest edition of Indexer Office Hours! Today is April 9, and we’re here for episode 152.
GRTiQ 163
Catch the latest GRTiQ Podcast with Zubin Pratap, Software Engineer and Developer Relations Engineer at Chainlink Labs.
Repo watch
The latest updates to important repositories
Execution Layer Clients
- sfeth/fireeth: New releases:
- v2.4.2 :
- Fixes a Substreams context leak causing tier1 responses to slow down progressively.
- v2.4.1 :
- Fixes thread leak in metering affecting Substreams.
- Reverts a Substreams scheduler optimization that causes slow restarts when close to head.
- Adds substreams_tier2_active_requests and substreams_tier2_request_counter Prometheus metrics.
- v2.4.0 :
- A single substreams-tier2 instance can now serve requests for multiple chains or networks. All network-specific parameters are now passed from Tier1 to Tier2 in the internal ProcessRange request.
- This allows you to better use your computing resources by pooling all the networks together.
- Since the tier2 services will now get the network information from the tier1 request, you must make sure that the file paths and network addresses will be the same for both tiers. (e.g., if –common-merged-blocks-store-url=/data/merged is set on tier1, make sure the merged blocks are also available from tier2 under the path /data/merged .) The flags –substreams-state-store-url , –substreams-state-store-default-tag , –common-merged-blocks-store-url , –substreams-rpc-endpoints stringArray and –substreams-rpc-gas-limit are now ignored on tier2. The flag –common-first-streamable-block should be set to 0 to accommodate every chain. Non-Ethereum chains can query a firehose-ethereum tier2, but the opposite is not true, since only the firehose-ethereum implements the eth_call WASM extension.
- Arbitrum-nitro New release v2.3.4-rc.2 :
- This release improves sequencer reliability and node performance, in addition to adding metrics for chain pricing data.
- Set default –execution.sequencer.max-revert-gas-reject=0 to improve sequencer reliability.
Comments from Matthew on Firehose release:
- The new Firehose changes the architecture quite a bit. You can still run it the same way as you’re used to, but if you’re running Firehose on a lot of blockchains at once, as we will as indexers (plus hopefully the number of chains coming to the decentralized network is going to go up fast and soon), which means if you want to process Substreams on those different blockchains, then you need a pile of nodes to process that.
- So now you can just set it up once and then you can point your different chains at the same set of worker nodes. This makes it easier to configure, especially for people who are using bare metal and not in a Kubernetes cluster. Even with Kubernetes, this is still way more efficient.
- Basically, you run Firehose Ethereum as your Tier 2 Substreams processing, and then you can pass any of the other Substreams from any other chains to the same Firehose Ethereum binary.
- We’ve worked through some little glitches, and one issue remains with one of the Substreams.
Consensus Layer Clients
Information on the different clients
- Prysm: New release v5.0.3 :
- Prysm v5.0.3 is a small patch release with some nice additions and bug fixes. Updating to this release is recommended for users on v5.0.0 or v5.0.1. There aren’t many changes since last week’s v5.0.2, so upgrading is not strictly required, but there are still improvements in this release, so update if you can!
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 24. 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
The latest updates on important changes to the protocol
Contracts Repository
- [WIP/Experimental] BREAKING CHANGE: Horizon draft changes #944 (open)
- [WIP/Experimental] Horizon Staking changes #956 (closed)
- [WIP/Experimental] BREAKING CHANGE: add subgraph data service #946 (open)
- [WIP/Experimental] BREAKING CHANGE: add subgraph dispute manager #965 (merged)
Network Subgraphs
The analytics subgraph for Arbitrum is experiencing some issues that we are investigating with the Graph Node team. It seems to be a case of too many delegators on indexers in Arbitrum, which is a growing pain. A hotfix has been released, and we are checking on the syncing progress on the resync. Hopefully, the availability issues with the subgraph will be resolved soon.
Open discussion
- Exponential rebates explanation + Q&A
- Chain Watch: Moonbeam team is joining us to share the best practices for indexers
- Useful links:
Exponential Rebates
- Justin joined to clarify any confusion about exponential rebates and revisit the purpose of exponential rebates.
- He highlighted that the purpose of exponential rebates is to eliminate the gaming that would go on with the Cobb Douglas rebates.
💡 If you think back, the amount of rebates an indexer would receive depends not only on their stake but also on the other indexers within the network. We felt that this was unnecessary and overly complicated.
After clarifying the purpose of exponential rebates, a question was raised:
Q: Do you have any ideas about how the allocation optimizer could better account for appropriate allocation sizing given expected query revenue?
Answer:
I think right now, the allocation optimizer is mostly for indexing rewards. I will have to double-check the exact numbers, but that would be the main driver.
If, instead, we change the objective of the allocation optimizer to care a little bit more for query fees and to weight them more relative to indexing rewards for, you know, extraneous purposes, we might be able to do something like that.
Chain watch: Moonbeam
Kevin Neilson, a developer relations engineer from the Moonbeam team, talked about the project and how indexers can best index and support the network.
He defined Moonbeam as an Ethereum-compatible smart contract parachain on Polkadot. At the time, there was no natively EVM-compatible parachain on top of Polkadot.
And so you’ve got lots of DeFi dApps, lots of developers, and lots of builders who have launched, let’s say, on Ethereum, and they’ve launched on Binance Smart Chain.
They wanted to bring their apps to Polkadot, but it was not easy for them. So, we used several things to provide seamless Ethereum compatibility, including the tools that Polkadot already has.
That includes building an EVM that’s natively compatible with all of your typical EVM smart contracts. It’s not something where it’s a compromise, the opcodes are different, or there’s any sort of different experience.
It replicates the EVM on top of Polkadot and is built with substrates. So, as a dApp developer, you won’t notice any changes. You can deploy to Moonbeam without having to learn the intricacies of Polkadot or anything like that.
And, of course, this goes for our PC support. So you’d make the same requests that you would to an Ethereum node. You’d say, eth get balance. You’d say, eth get logs, all of that. There are no changes; all of that works exactly as you’d expect.
EVM with expanded features
Questions
While he was giving the presentation, a few questions were raised.
Q1: Can EVM applications running on top of Moonbeam interoperate with other Polkadot chains via XEM?
Answer:
Yes, absolutely. They can. Interoperability with other Polkadot chains that go through XEM is a substrate feature, but we expose this functionality to the EVM via our precompiles.
Our precompiles allow things like sending funds to other chains and calling contracts on remote chains, which is both possible and really cool.
Q2: What was the main feature of Polkadot versus Cosmos SDK and interchain security (ICS) that onboarded Moonbeam?
Answer:
One of the things that is extremely attractive is Polkadot’s model of shared security and the idea that the chains do not have to provide their own security. So, Cosmos has since implemented a similar technology.
I think the chains give up a piece of their inflation, or there’s a way for them to pay for this ongoing security. But that was different when we were doing research into launching on top of Polkadot.
Q3: Can EVM applications running on Moonbeam interoperate with other Polkadot chains via XEM?
Answer:
With precompiles, you don’t have to learn about Rust or substrates. And Polkadot can be, you know, a little bit intimidating if you’re coming from another EVM chain, and so we want to make that as easy as possible.
Q4: What are Moonbeam’s chain parameters? E.g., block time and EVM gas per block.
Answer:
Moonbeam’s block time is currently 12 seconds. And on our test net right now, we have a block time of 6 seconds. That’s because there’s a new feature release called asynchronous backing.
The asynchronous backing feature has dropped the block times from 12 to 6, and this will be rolled out to Moonbeam in a couple of months as well. Gas per block is 15 million gas. The largest transaction can be about 12 million gas.
Running a Moonbeam node
Gil, a DevOps engineer at OpsLayer, presented how to run a Moonbeam node. He focused specifically on setting up a Moonbeam node that you can connect your Graph indexer to rather than exactly setting up the indexer itself.
The presentation was very detailed. He went through the steps of setting up a Moonbeam node using the Moonbeam documentation.
You can also reach out on Moonbeam’s Discord for support.
Some important points to note from his presentation:
💡 To set up a Moonbeam node for The Graph indexer, you need a tracing node. - When running a parachain node, you are essentially running two nodes: a parachain node and an embedded relay chain node. - You need an archive node to keep all the blocks' information. - You need 16GB of memory to run a substrate node.
You can find a list of all the dApps on Moonbeam on their apps directory.
No Comments