DAPPCON 2024: The Evolution Of Explorers To Meet The Diverse Needs Of Web3 Users - Kirill Fedoseev

Transcript

hi everyone yeah unfortunately my name is not Igor my name is Kil I will be replacing Igor today so I'm the head of research protocols research at blog Scout so yeah let's talk about it let's talk about blog Scout what we do why we do it what's going on for the past couple of months what we have been developing and how BL Scout helps you to get through this Dark Forest of different layer data availability layers account abstraction and so much more so let's start with a simple question just why do people regular people users do actually need something like block Explorer what do they expect in exchange for for using something like that so our answer to this is that

people generally expect block explorers to perform this role of providing the transparent access to the user's data so that users can access the real time and historical data about their account their transaction the stuff that other people and accounts are doing on chain they also rely on the Block explorers for the different types of visualization and interpretation of this raw blockchain elements how they rely on block explorers on the decoding and interpreting particular transaction on the decoding and interpreting like um parsing different accounts visualizing what happens within the smart contracts

and the last but not least people expect blog explorers as well to perform some security due diligence and help them to actually understand what looks more secure within this um permissionless setup and what's more secure and what's less and so it's really important from the security perspective as well to have this transparent access for everyone to see what's going on on blockchain and to have this observability property is also helping to increase this uh security of the entire open source space because if no one is monitoring what's going on within the open source blockchain or open source protocol then this open

source property really hurs the security instead of helping it to to be better so basically the main challenge for the blog Scout is to how to find the path for conversion for visualizing this raw data that's coming from raw just on RPC API or similar endpoints similar sourcers and provide a way to visualize and to display it to the users in a simple and easy to understand format to find the necessary details and to guarantee that everyone is capable to get what they want from this UI and to just yeah continue with their blockchain journey and simplify their life on on chain as much as possible

so if we look at the current state of the industry industry what's been going on over the past year I think with the just number of networks what's been going on is that I've been revisiting the slide over and over again and like when I'm coming back to it one month later I just increase this number of networks that exist by like a 100 so we can probably estimate that 100 new networks including May Nets and test Nets have been launched every month and so it's clear that no proprietary or no Clos Source blog Explorer would be able to to support this kind of growth to be able to launch in this vast amount of

networks to support them all in a flexible fast and cheap most importantly way then any other solution like building an in-house Explorer for each particular network is also a bad approach because of the different costs associated with the development of your own Explorer because of the just of the complexity and of the UI difficulties the your users are going to expect they're going to have if just every chain will continue to have their own UI that doesn't look uniformly across across the industry so it's just better to have some open source alternative to to have an open source blockchain Explorer with a uniform UI that everyone

is kind of familiar with and then at the same time this Explorer can be flexible enough easy enough to launch and it can be hosted on your own or on the different service providers such as ourselves or any other rollups as a service provider for example so if you take a look at the Block Scout as of today block Scout is by far the most widely used and widespread open source blockchain Explorer for evm networks so there are many reasons why it's the case so blog Scout is fully open source it's easy to launch for for your own chain for any evm compatible chain with a

bunch of different customizations for layer one layer two support with different plug-in play modules you can enable and disable depending on your needs depending on the needs and specification of the particular protocols for users on your network yeah it's easy to install it can be run by anyone it can be hosted on your own infrastructure for free or it can be host through us to simplify the burden of configuring and maintaining and updating block Scout Explorer so yeah that's probably all the reasons why the block Scout is so successful and have all this different integration and de facto became the primary Explorer for any new launching chain out there

so a part of this reasons is actually also all of the stuff we have been doing at the blog Scout for the past couple of months so our focus and effort have been spent in these directions so we've greatly enhanced the the support for specific features on different layer to families we have discussed and planned to implement different nice to have features for the specific up chains which we're going to mention throughout this talk we have some cool features for the data availability providers and the data availability uh narrative in general then we have a bunch of features for account obstruction support within the blog Scout and yeah a bunch of other features we have worked on so hard as

well so let's start with the this rollup support so whenever you launching a Block Chain Explorer for rollup which can be any layer two layer three chain so a bunch of typical features you can typically expect from such kind of Explorer on top of what a basic evm Explorer can provide for indexing all the blocks transaction and accounts is the support for indexing the bridge operation that is that is the deposits and withdrawals that are happening throughout native uh layer to bridge then there is typical a request to support uh transaction batches indexing which is

kind of an an abstraction between the transaction and the blocks on on the layer two side and then a lot of effort actually goes to supporting all of the different layer to spec changes so whenever the main har works or something going on within the particular rollup family there are also like kind of a parallel hardw Fork schedule for any rollup which have to be supported so whenever the new data availability is implemented within a particular rollup or the fees are somehow the fee mechanism is somehow changed due to a different data availability provided again or something else this should also be supported by the infrastructure such

as plog Explorer so that's what we are hardly working on as well so far we have fully supported the op stack and polygon cdk rollup families and the support for the the full support for the ZK sync and arbitrum nro chains is coming throughout the upcoming months so probably this will be fully completed and launch on a bunch of chains with the full support during the summer another interesting narrative we believe in the blog Scout is that blog Scout should be not only a readon portal that users refer whenever they just want to access some lowlevel information about a particular transaction and just get some

information and that's the end of story We believe that blog Scout can also be a portal for active operation of the users for some active stuff they they are doing so we are doing a bunch of integration in that direction as well so one of them is the the project within the block Scout called up Scout which is a market place for apps that helps especially on a low level CH low value chains to help with the discovery of the new dab and protocols that are getting launched uh throughout this chain so one of the cool features about dab Scout is that can you can also open any particular D app within the block Scout and not open a separate tab not worry

about opening their one link or something like that so it's all happening within the same portal so people can interact with their defi positions or do whatever onchain stuff they want throughout this Marketplace without leaving the whole block Scout portal at any moment of time we have a very cool state-of-the-art features for interacting verifying and using the smart contracts for developers so whenever you need some Universal basically front end for any arbitrary verified smart contract block Scout is a way to go to to read some particular method to write some data to the to the smart contract to to do some debugging stuff the block Scout is a good feature

reach Explorer to to do something like that and then on the up chain side we've been also working on integration like the first one that's coming is the integration with the Redstone team so Redstone is a up chain for specifically for games and each game has like their own infrastructure deeply encoded within the smart contract of this game and basically the idea there is that instead of each game having their own game specific Explorer for all the actions that happened inside this game or instead of redstone developing their own Explorer for getting through these games instead we went with this approach where

we can basically integrate this all the games Explorer and all the information that happens within these games within the blog Scout natively so that people can simplify and speed up the process of discovering the games discovering and sharing the stuff that's been going on within the games and to actually keep those within the single portal so on the data availability side what we have been trying to do at blog Scout is kind of keep the Synergy between how layers are organized on the blockchain level between the data availability such as the consensus layer or something like Celestia and then the next layer is the execution layer and

then we have the bunch of different rollups that are running on top of this execution layer so with our block Scout stack we are kind of trying to replicate this this hierarchy so that layer to block Scout that indexes the stuff that's been going on in particular rollup has access to a lower level block Scout API and uses that to access the particular blobs or transaction with the transaction batches happened on the lower level and then the layer one block Scout uses the underneath data availability infrastructure to index the actual blobs or some stuff that happened on the data on the data level so one of the nice examples we did for a 4844 is we implemented of course

the full support for the blob transactions and so you can use blockc to actually as an archive storage of the of the EAP 4844 blobs you can download them if they are able to decode them as images so this was just a nice example did by the someone from theosis team which was basically um meme feed uh on theosis chain and on the her Manet as well where you can post this cheap blobs with the images as well so what we did is that we implemented this par parsing and decoding mechanic for indexing and displaying this images as well so that it's kind of a nice way to to use these

blobs apart from just submit and raw batches so yeah the next uh direction of our research was related to the account obstruction so the the problem with the current way how account obstruction Works in ethereum we think is that everyone is trying to abstract away a lot of complexity from the end user so that the total user experience of sending and interacting with the wallets and sending transaction is as simple and as easy as possible this works by obstructing away U the gas mechanics the different fee mechanics the transaction execution mechanics and so there is a

lot of effort spent in abstracting a way this complexity from the user but it always there is always a tradeoff there and in this place the trade off is between the complexity for the user versus the complexity that happens on the lower level and so whenever you're decreasing the complexity for the end user you actually increase the complexity and increasing the amount of low level stuff that's happening on chain behind this decreased user complexity and some of the contracts become more complex more harder to analyze and if you actually try to open any raw transaction that interacts and goes to some deck and tries to swap something

and compare it to the simple transaction that does the same but without the account obstruction framework it's actually much simpler to understand the usual transaction when that is to understand the the same stuff that's been going on within the user operation so here basically as a Blog Explorer we see our mission as to find a way to simplify this user experience back as well and so abstract it way not only on the wallet side not only on the daab side but on the Explorer side as well so whenever researchers or any developers inspecting this user operations on chain it's actually as simple to understand them as the regular

transactions so at the blog Scout we've done this by implementing a separate Standalone account obstruction indexer that does all this complexity and pares this user operations or meta transactions and stores them in a similar to transaction model within the database so this indexer is now part of the blog Scout stack and you can launch it on any chain supporting ERC 4337 any version of it so so far they have two entry point version contracts so the way it works within the block Scout interface is that it's very simple to how you can see the normal transaction and what you expect to see

about the normal transaction within the block Explorer so you see pretty much the same basic details about the transaction about the fees about the gas used you can even access the the all logs and token transfers and different draw information that are specific to this particular user operation even despite of that in the same transaction a bunch of other stuff happened a bunch of other different user operations a bunch of stuff related with the pay Master contracts bunch of contract creation might have happened so this all is abstracted way and just we keep this really specialized view which is very similar to How You observe and what you see about regular transaction you see

the same thing about the user operation so one of the examples what we are actually trying to abstract way is how the the way of actually decoding the cold function and the cold operation uh Works in comparation between the regular transaction and the user operation so whenever you're looking at a regular transaction and they try to understand what actually happened the easiest way to just go and see what Contra what contract has been called with which method and from just name of the method name of the arguments you can try to deduce what happened uh within this transaction for the user operations it's

actually a bit more complicated because because of this nesting level within the the internal transaction so you actually need to go three times deeper to find an actual contract that has been called within a particular meta transaction or user operation and to actually try to understand what happened what contract has been called what function and what was the purpose of this user operation so this all should be obstructed away on the infrastructure level and that's what what we do within our account obstruction integration basically yeah and uh probably the last thing I wanted to mention today is related to the our efforts spent for the smart contract developers and

simplifying their DFX as well so one of the most LED features in the block Scout depending on the amount of different instances we have a block Scout was this feature called ethereum B code database block Scout by database which is basically was a way to verify some particular contract ones on one network which has the block Scout support and then this contract will be automatically verified if whenever we find a similar contract with the same bite code on any other network that is supported by the same kind the cluster of block Scout instances so this has been working very well it has simplified a lot how the developers

approach this problem of contract verification within their multi-chain and multi multiversion deployments and um yeah the only problem with that was that it it's only supported by blog Scout the standard was not supported by any other infrastructure provider any other Explorer so that's why we created this and co-authored this initiative called verifier lines which is basically a way to continue this feature of BL Scout by code database and the feature of sharing the verified information about smart contracts about bite code verification on different chain on different networks between a bunch of different connected providers blog explorers debug and

Analytics tool and to share this knowledge about contract verification so that developers lives became much easier than they were before so a bunch of updates related to the verifier allines going through throughout this year so I think they're going be they're going to be separate talks throughout the Brussels and upcoming conferences so if you're interested and wanted to join this ecosystem Collective feel free to connect and join and also feel free to keep in touch with the blog scout team connect with us if you're planning to run your own rollup layer one or whatever compatible with the evm you want any feedback you

have any feedback related to the potential features we might add to block Scout or you are missing something in the block Scout instances feel fre to conact with us as well and tell us your feedback okay thank you and now we have a open floor so if anyone has any questions please your hands yes thanks that was very interesting uh does the the AA indexer work on historical data so for example could I use it to uh follow the trade of something that went into dydx V3 four years

ago yes the a a indexer indexes the whole history of the user operation so we don't support any account abstraction standard Beyond ERC for 337 now but whatever happened within this entry point contracts we do index and it will be index historically so we use the historical data from the RPC directly and from the already existing blocks how that base whenever we can to speed up this index so yeah it does work well thank you go thank you so much everyone give a big round of applause again people