@0xbeary Appreciate your post here about Subsquid. Thank you!
In selecting the underlying framework ENSNode uses for indexing, I can confirm metrics like the following are valuable:
- Sync speed (on a practical basis this is really about backfill time).
- Sharable RPC-caches & reindexing cost reduction (which would also accelerate initial backfill time and reduce initial costs for self-hosting a new ENSNode instance).
At the same time, these performance optimizations are relatively low priorities for where we are today in the overall ENSNode roadmap. All our current roadmap priorities are well supported by Ponder and we’re happy with the support the Ponder team has been delivering to date.
Next steps in the ENSNode roadmap includes work on completely new ENSv2 compatible indexed data models and new APIs built on top of those data models. This will be a meaningful engineering effort that requires focus. It’s not the time to explore alternative indexing backends.
Looking further into the future, ENSNode is built using a modular architecture and all indexing logic is constrained to a distinct layer of responsibilities. After the ENSv2 work matures it may be relevant to explore supporting multiple / alternative indexing backends. Introducing additional indexing backends introduces meaningful complexity though and would require truly meaningful benefits to justify it.
Ponder continues making noteworthy improvements on the performance optimization points flagged above. We are also already exploring specialized tooling that will nicely solve the “Sharable RPC cache” opportunity.
For the other points shared, Ponder’s approach aligns well with the vision for ENSNode.
We’re happy to continue observing how Subsquid / Ponder / and other indexing frameworks evolve in the future. If situations change then of course ENSNode will make use of whatever indexing framework(s) are best for our needs.