EVM Evolution in the Superchain Era: A Block Explorer’s Perspective

Transcript

[Music] Hello K. Nice to see you all here. Hope you're enjoying this conference so far. The talks, the city, the weather, everything has been super nice so far. So we wanted to kick off this afternoon session with the discussion on the offchain blockchain infrastructure like block explorers that's sitting offchain and powering the vast EVM uh network of chains and rollups and how it well it can adapt to

the new uh narrative of super chains uh crosschain interrop new standards being proposed for addressing the different problems that arise in this huge really growing space of the new networks. So, Block Scout is the probably the only one fully featured blockchain explorer for the EVM networks that powers this vast decentralized network of chains as a free open source alternative to existing proprietary solutions. The Blog Scout is fully open source, modular, customizable, modifiable. You can fork it, deploy it, and use it however you like. for free without paying any license fees. It's fully EVM compatible

and supports different layer ones, rollups, and any EVM compatible chains. And it provides different tool set features for different parties. And it's fully multi-purpose. It provides something both for users, for developers, for regular and power users, for API consumers. Soon it will provide the MCP server for AI agents, for dabs, and so much more. And today the Blog Scout is proudly powering the huge network of more than 2,000 chains. So the main piece of infrastructure we have for Blog Scout is the UI that we provide for each and every one of those networks and some of those UIs have been hosted by us on our own domain. Some of them have been operated by other

partners, third party providers, rollup as a service providers and so on. And some of them especially for smaller chains have been fully self-hosted for free by the teams themselves by the chains by independent parties researchers and so on. So block scout provides this powerful platform for a single chain that provides a fully featured experience for exploring EVM chains entities transaction blocks and token transfers and anything you would expect the typical block explorer to have these days.

We also recently launched the initiative called auto scout basically which allows you to deploy a production ready block scout instance for any chain where the single requirement is the speed of the deployment and you want to get the fully featured block explorer as fast as possible. So through autoscout it's possible to launch a production ready block scout instance for any chain in just a 5 minutes and basically the only thing you need is an archive RPC endpoint and then a few layout configurations for the UI if you want to do some basic customizations with your instance. So this makes it an ideal solution for all of the service providers and is already used by many of them but can be also used by the independent parties and single people

individuals and researchers. So we have this vast network of block scout instances and chains and we have an individual block scout explorer for each and every one of them. But not only in block explores but in general in the ecosystem when we have so many chains the problem that arises with this number of chains is the the one we call interailability problem. So it comes in a different um aspects of it but basically the main problem we have with interpolability is that it leads to the fragmented UX. Users are tired and it's hard for them to manage different wallets, gas tokens, interfaces for different chains, switching networks and

just remember where the transaction are going through where they put their funds onto and so on. Then it also impacts the security because dabs and protocols developing on one chain cannot do not have easily defined and uh uniform uh way to send different crosschain messages. There is no single interface that shares the same security properties. So if they want to communicate and build crosschain dumps that communicate with some other smart contracts on other networks, there is no single uniform way how they can do that.

that provides the single and the shared security assumptions with the Ethereum itself. So there is inconsistent standards. The application logic gets siloed to one ecosystem only without this easy way to communicate with the entire EVM space. There are security tradeoffs and it's just hard to track all of this together to index everything and to keep track of all of these things. In block scout the main issue we have the with the interailability you might think of is the fragmented UX. So as I told we already have this single instances for each network that power and index each individual blockchain and uh yeah in some sense these instances do

not interact with each other in any way and that makes hard for users to use them and to make sense of all the crosschain activity if they're heavy moving from one chain to another. if they're interacting with different dabs and use different chains and ecosystem and migrate back and forth. So overall in the Ethereum vision the proposed solution to this interailability problem was that we have to find a way to make the seamless UX across all the different rollups and chains that doesn't introduce this inefficiencies and redundant barriers.

And basically the idea is that we should find a way to make this cross to cross all to interrop invisible at the application layer and just let users use whatever apps they like without actually thinking which chains they've been settled on, what's going on and where these transactions have been sent to, what bridges are being used and how this all comes together. And the way they propose to do that is through certain standardization and unification by introducing different standards and how this all can be put together. So so far in the Ethereum space probably one of the main entities has been driving all of these efforts was the L2 working group. So basically what we have there is that we have a bunch of

different ERC standards for different of the problems I've described before. So there are a few standards that try to address this chain specific addresses and basically to find a way how you can define and give a precise definition on where you want to send your money to or where the person's user account is exactly located by providing and combining this uh tpple of user address and the chain there on in a single string. And there are different standards for putting the strings together both in the machine readable format for smart contracts and data indexers and then also provide them in a human readable format that's easier to understand by humans by wallets by AI agents and so on. Then there is also a

couple of standards for moving the onchain registration of chain ids from the GitHub by listed repositories that requires manual approval and takes time to onchain through the digital identities such as ENS. And then there are a bunch of different standards being proposed and tested and rolled out for the interop and crosschain communication between the roll-ups networks. So one of the main efforts there has been the OP interrop and then there are a couple of other interesting standards like the open intense framework the crosschain intense and the one similar one being designed by the arbitrum in the form of universal intent engine.

So when it comes back to block scout basically with all the standards and crosschain interpolability the question we might ask ourselves is that is it possible to just make get rid of this single instance block scout instances all together and put everything in a single UI and just provide a single search string and a single interface that will list all the transactions across different chains all the tokens and display everything under one UI. So and actually this approach is what we already trying and you can go and try it on blockscout.com. It already works in its uh first version and it already provides a bunch of benefits that are clearly visible to us. So it provides this single Ethereum entry point to the

entire EVM ecosystem and allows you to easily search and access all the data from the single domain from the single interface from the single UI. It provides a simple API gateway for the developers, for the indexers that are using block scout API. And then actually this single UI is much easier to use for regular people for agents. It also comes in the form of the MCP. It's much easier to them to figure out the blockchain space without using multiple different device.

But at the same time when we come when we are talking about open source products it's really hard to put everything together under a centralized domain because it also introduces a bunch of different risks and problems with it and it's probably not a big deal if you already closed source solution. If you're running in a closed source block explorer then it really is not a problem any of this and you can just combine all the domains together and put everything in a single space. But we are building open source product and for us if you try to get rid of this single block scout instances and put everything together then we are very concerned about the centralization risk about the data ownership risk that every data

would be owned by the single party and yeah it wouldn't make sense to continue building this is a fully open source product that can be run by anyone and then one of the most important here as well is the lack of flexibility is that if If you try to put all the chains together in the single UI, you of course introduce a lot of benefits. But at the same time, each chain then would lose this unique flavor they have already. Some chains prefer to have different customizations not only on the UI format and UI layout they want to see in the blog explorer but even in depth in certain transactions a chain some chains are different from each other and provide unique features in some

transaction types maybe data types and provide some aspects that they want to showcase in the block explorer itself that just wouldn't be possible to put in a single centralized UI for the multi-chain So the proposed solution from the block scout side that we believe is the right way to build a open-source multi-chain blog explorer is that we want to keep this network of single core single chain instances as a core that are still open source that is still available across the entire ecosystem can be hosted by anyone not only by us or centralized providers but by the people out there themselves.

It's modular and flexible and pretty much everything people already love about block scout stays there. But then on top of this layer, we just built additional layers for supporting this multi-chain features, L2 clusters, for showing different interrop features between the networks and between the the ecosystems themselves. We build a layer that provides this unified search across all the connected EVMS. And then we also might provide an entry point for universal dubs that provide some capabilities for the users that are that should be accessible regardless of the chain they're using such as swaps, bridges,

payments and stuff like that. The single entry point should provide these capabilities as well. And then we also try to move some chain agnostic data to some shared spaces that basically the data space u pieces that are not as critical as the whole index blockchain but stuff like name tags metadata ens domains and ENS compatible alternatives verified contracts that we are trying to push to the verifier alliance initiative. Then for the metadata there is also an interesting open labels approach and then uh we might move the all the dabs registry to the single space that can be accessed by the decentralized front ends.

So to showcase what have we have built already and what currently is being developed at block scout stage uh is one of the efforts we are currently building is related to the opi super chain interrop basically the op OP interrupt um idea is that they want to combine certain superchain networks in a single cluster that feel more like a single chain than separate chains and they have a bunch of unique features that are specifically designed to work in this L2 interrupt cluster. So they have um token addresses that are interoperable with each other across the chains. They have the same address. they can be easily and fast uh brided between

the chains seamlessly. And so it makes sense to combine this token addresses together to aggregate the balances and show it in a single UI since all of these tokens share the same metadata, the same name, the same address, the same security pro properties. And then operain also allows this fast and crosschain L2 messages for generic application. It allows you to build interailable apps and so on. And so at Blog Scout, we try to build this extra layer on top of the existing single instance Block Scout explorers for the interrupt specifically that will precisely showcase this aggregated balance,

interrupt messages, crosschain transactions, their statuses, but at the same time uh beneath it, it will still rely on the data provided by the single instance box explorers. And then some other interesting interrop efforts we have is related with nonvm blockchains. So even though we don't provide any indexing solutions for nonvm blockchains directly we do not have any explorers for nonem networks in some cases we are still able to fetch some data from them and to display the cross links maybe combine some data from the third party APIs and put it in block scout. In this way we can also achieve interrop with other ecosystems even though we do not provide the indexing

solutions for them ourselves. So one of the example here is for neon EVM we are able to link together Solana and EVM transactions that uh wrapping the neon EVM transactions in the block scout UI. And then one of the most recent example was was with the D chain tone application chain where we combine a bunch of tone transactions that are coming in parallel as synchronously by the specially developed indexer and block scout and we combine them together and we are able to show them in a single block scout interface and basically show the users and developers through all of the stages of the transaction how it was split and combined back together. um and really show this interrop between the

EVM and the ton ecosystem. So yeah, let's uh summarize what are the implications for the interrop for such essential pieces of infrastructure such as blogs blog explorers or wallets are. So we definitely see that this crosschain cross L2 transaction and crosschain transaction are becoming the new norm and are becoming more and more popular by the day and it's really becomes a must to have this visibility for them in any tab in any wallet in any blog explorer. So we are trying to approach that as well. Then there are some emerging data and and uh data types

and data standards for interoperable addresses intense crosschain transactions that should be supported in such uh off-chain indexers and off-chain pieces of infrastructure such block explorers. And then also as a side note, we definitely can observe that with the arrival of this intense account obstruction and interrupt transaction, they definitely start to produce much more complex transactions that we have seen before with different dubs. Basically, each transaction now wraps a bunch of different metransactions in it. It can contain some crosschain logic and the block explorers and other ofchain pieces should adapt accordingly and abstract

such complexities away and find a way to display this data as simply as possible and as easy to understand for the end user as they can. That was pretty much it. So, thank you much. Thank you very much. And I think we have a couple of minutes for questions if we have any. Hi. Um, I work for a company. We have an L1 blockchain, but we have mult multiple chains. And we've actually used Block Scout as our chain explorer, but we've got, for instance, five EVM chains. And we've got things running in um for for

each chain, we've got stuff running in Docker Compose, but for each chain, there's like five different Docker um containers that we have to run. And I I think we started building this in April. So, I don't know if this is a new version and something that maybe we could um move to or is this version probably the same one that we have and maybe we're just not using it right. Are you talking about Kadena, right? Yes. Yes. So, I already noted down for myself. I've attended your presentation and we definitely should catch up after the talk to see the way how we can Yeah.

Great. Co coordinate together. But, uh yeah, there's definitely some improvements to be made. Okay. for Yeah, I I'll come and see you. See you. One more question over there. Hi, thanks for the presentation. Uh just to understand today's um new efforts that you're building, will this also be open source as well or is this going to be a new core source product that you've introduced?

Yeah, we'll try to keep it as open source as possible. There is no benefit for us to keep uh such important pieces as closed source, but uh yeah, so all the things should be open source as the rest of the block scout stack. Okay, thank you. [Music] Heat. Heat. [Music] [Music]