I think we all agree that a block explorer is an essential resource that every parachain needs access to, and also that we prefer to pay less to receive more from providers of these services.
However, as sourabh points out, paying a service provider for 50 or 100 or 200 parachains doesn’t really solve the core challenge.
This challenge isn’t limited to the long-term future; the introduction of pay-as-you-go parachains eliminates the possibility of “solving this” with an up-front payment for a predefined # of parachains.
I’d love to see a treasury proposal from a service provider who wants to win support for all of Polkadot’s parachains. However, spinning up a block explorer for a new parachain is not an insignificant amount of effort for these service providers. Unless we can reduce (or eliminate) this effort, we should be skeptical of any service provider that claims an ability to scale parachain support infinitely.
Main thing I want to add/underscore real quick is this:
Team A is charging teams ~$30,000 - $50,000
Team B is charging teams ~$500/month
That is a significant difference & also the current reality. So, I don’t understand why the former is pushed more than the latter.
In an ideal world, this would have been something produced by Parity as a common-good de facto feature of building in the ecosystem & being a parachain on the relay. However, that’s not the case, so we should at least prioritize a more accessible option.
Otherwise, individuals are going to be navigating from this block explorer to that block explorer to no explorer at all. Institutions, at the least, are going to look at the ecosystem funny.
Subscan supports non-Polkadot blockchains.
This is a critical use case in these early days and will become more so going forward.
In another context @rphmeier made a claim close to asserting that Polkadot is a natural monopoly in terms of PoS for Substrate Relaychains.
I asked for him to substantiate that claim and nothing was forthcoming - when I looked around I could only find subscan supporting Substrate Relaychains, and when I looked at those non-Polkadot Substrate Relay chains I’m even more skeptical of his claim.
As I noted elsewhere, capital scarcity is a permanent fact of life, and I don’t want this thread to be sidetracked by that.
Rather I’m giving a concrete use case where it is important to have a block explorer that isn’t limited to Polkadot - even though Polkadot is a critical PoC for other relaychains to discover what works and what does not.
Please note that polkaholic only services the Polkadot and Kusama Relaychains.
However, if you take a broader view of the Substrate world then Polkaholic’s approach is unhealthy - it further entrenches the Dotsama Parachain oligopoly/cartel. While Subscan’s approach (emphasis added):
and
is healthy in terms of being more open, or more precisely, fostering competition.
@taqtiqa-mark you’re putting me in a difficult position here and I don’t feel you are engaging with intellectual honesty. I substantiated my claims very thoroughly in other threads and blog posts, and here I find you both misrepresenting my words and saying that I didn’t engage on push-back. The public record is clear there. This is low-signal and off-topic, so please consider it a warning for future moderation. I have no issues with criticisms to Polkadot or its architecture but they need to come from a place of understanding, honesty, and genuine attempts to improve things. Not to create drama.
If we didn’t want Substrate to be used outside of Polkadot we wouldn’t have written it to be general. i.e. we’ve created open-source common goods only to be criticized as doing the opposite.
Respectfully, the warning stands. Your previous post brought me into this thread, which I was not part of, to misrepresent statements that I had made in other threads.
If the point you wanted to make was that block explorers should support Substrate chains which aren’t deployed as parachains, then sure, that’s a valid point and you have made it. The tone & content of your post seems intended to cast me as “close to” being in favor a Polkadot monopoly on blockspace and (in this context) to connect that to being against general Substrate block explorers. This is along with a pattern of posts using inflammatory language. Maybe I have already taken too much bait, but here we are, and it’s time to stop this type of behavior.
@taqtiqa-mark you got us! We have been proud supporters of the Polkadot cartel. We will take your advice and see if there is an opportunity for substrate-etl to index non-Polkadot substrate chains this summer, thank you for asking.
Our idea of a great multichain block explorer to cover the entire ecosystem would not stop at Substrate but continue to EVM Chains and then whereever else BridgeHub/CCTP/Axelar/LayerZero/… users come from. Most businesses that are serious about growing from Polkadot / Substrate starting point have the same idea, but it would nice if everyone can freely speak about other cartels without feeling that they are committing cartel heresy.
A good modular open source architecture would have parachain teams (Substrate projects) taking their chains pallet innovations and making sure their dashboards+explorers of calls/events/storage is well covered by actually writing code or working with the community to make it happen. Within Polkadot, I have always thought Polkadot’s go to “multi chain block explorer to rule them all” was polkadot.js apps (and it even covers Substrate chains lol), but the contributions usually almost stop with RPC endpoint additions… parachain teams didn’t go in and make it prettier and extend it to be connectable to third party APIs like ours and subscans, nor did Parity finesse it in this direction. Instead, the first N teams went off and started paying Etherscan and Subscan to get some basic customization services, while the next N teams are wishing those services cost $500/mo AND show all the deep goodness of their chain. I checked in with @XCAstronaut last week and I think the best idea to get those N teams what they want is to rely on a loving ChaosDAO type community. We are ready to work with them with the right APIs that does comprehensive justice to the problem.
For our own efforts of substrate-etl, we are pursuing an approach not of beauty (which is always subjective, thus semi-hopeless) but instead inspired by Dune and blockchain-etl’s treatment of EVM projects – which basically mapped ABIs into call + evt tables with a little bit of project setup… but often a lot more. But with Substrate chains instead of a project’s smart contract ABIs, these substrate-etl tables (inside BigQuery) can be generated from the chain metadata, which only radically changes super rarely and thus needs no setup at all [this is one of 7 reasons why we are supporters of the cartel]. These pallet-specific calls/events/storage tables will enable multichain block explorers (plural) to serve users with Third Party APIs, many of which are obviously shared across many (para)chains. We hope that Polkadot governance systems parent/child bounty will support this approach and also enable a scalable business model for us and other data businesses within the Polkadot/Substrate ecosytem.
