Blockscout Workshop - ETHGlobal Bangkok 2024

e hey everyone my name is Kil I'm the head of research at blog Scout so let's jump into the blog Scout Workshop so if you haven't heard about block Scout before block Scout is an most widely used open source blockchain Explorer for evm networks rollups May Nets Dev Nets anything evm related so in this Workshop we will talk what is block Scout and why you should care about it why you should use it why chains should use it we'll talk about the apis that available to the hackers throughout this hackaton to be eligible for Block Scout Bounty of 20K we'll talk about the contract verification which is also one of the requirements to be eligible for the uh haakon Bounty and then we'll talk about the bounty in a bit more details so why should you care about block Scout basically in the past couple of years we have seen this exploding growth in a number of networks launched basically any everyone is now launching their own rollup based on op St carbit room and so much more everyone is having test Nets death Nets are being spun out and shutting down basically only throughout this week we have seen a couple of I think five Network launchers or something and so for all of these networks any network which is evm compatible and even not evm compatible it needs some sort of blog Explorer and U so there exist a couple of proprietary solution but it's obvious that they are too expensive for everyone to use they are too rigid too hard to launch they are cannot be launched quickly in a matter of few hours so the the only feasible option we see here is that there should exist an open source blockchain explorer that anyone can use for free that someone may host for a small fee but open soural Explorer are just something that any blockchain page should absolutely have so blog Scout has been very successful in this journey and is now being used by more than a thousand different networks this includes all the different Mains Dev Nets test Nets some of these networks are hosted by us some of them are hosted by different other providers rup is a server provider ERS and something like that and then and the the most majority of these block Scout instances are selfhosted by the teams running the chains by the teams operating their all up sequencers and they run it absolutely for free on their own infrastructure in the public cloud in a private cloud and there is no limits where you can use blog Scout so block Scout is fully open source it has a bunch of different components that are all open source that can be configured and optimized and customized for the specific needs your chain have it has a bunch of different models that can be turned on and turned off for the specific chains for supporting user operations data availability indexing and so much more it's user friendly it's step friendly it has a lot of contributors from the open source space so Lo Scout is fun so now let's get back to the work um to the hackaton to the Bounty and what you should use throughout this hackaton to be ible for the block Scout Bounty so we'll start with the apis what block Scout apis we have that are available to the hackers what can you use some different use cases for them so we have a bunch of different types so let's start from the first one which is the rest API so basically we have this public fager on every of the block Scout instance you can go and see through a bunch of different rest API end points basically all these end points are the ones that are power the block Scout UI itself so all the information that you see in the block Scout UI such as the address info the number of transactions the transaction list itself the source code of the particular contract the different token transfers nft transfers and basically anything you can find throughout the UI this is all fetched through the blog Scout rest API and you can use the same in for you see in the UI by looking and finding the respective API from this list and then if you like a little bit different format you don't like rest apis you can pretty much use the same data and query it through the graph curl interface so among those rest API end points I mentioned on the previous slide one of the most recent additions to that list was the transaction interpretation endpoint so basically this is a simple endpoint that is available on most of the block count instances that allows you to pass a random transaction hash of an existing transaction on this network and then the blocks will collect a bunch of different data about these transactions what happened in it this data will include some low level information raw information as well as decoded INF about logs token transfers the called smart contract method and it will use then llm model to aggregate all of this data and to categorize and trying to interpret this transaction in an easy to grasp and easy to understand format that can be displayed within a couple of lines to the user user just to give them the idea what actually happened inside these transactions so whether some token or nft was minted transferred maybe something got burned maybe some tokens were swapped was just random unspecified method was called on a specific contract so what this API does in the end is you give it transaction hash and it outputs you um one of the templates from the fixed set of templates we support and have and then so it outputs you the template string you can see on the slide and then the variables you should fill this template with such as what's the token name the token amount the nft ID and stuff like that so if you want to display some summaries of transactions within the UI or something like that you can use the block Scout rest transaction interpretation API and microservice for that so then the second API model we have at blog Scout is an RPC compatible uh API basically this is the API that you may be familiar with from other Explorers so a bunch of different explorers support this API format so if you have some library that operates and uses this particular API format and you don't want to rewrite it to Fork it you just want to use it as is or you're just very confid you feeling very confident about using this particular API type basically we support it too you can use it to query pretty much the same information that is available through the rest API but in a slightly different format through the different API query parameters but again that's just a different interface you can query all the tokens token transfers logs information about accounts blocks contracts transactions anything and then the last API we have available at block Scout is just an RPC compatible API basically it's the same API you use when connecting to the raw just on RPC endpoint but here so we support almost all of the E name space just on RPC methods and uh basically the best usage for for this API in your front ends in your dabs as a fallback option to the existing Json RPC provider so if you're using infura or something like that you can add at the end of the list as a second fallback uh just on RPC provider blog Scout just on RPC on point and your app will just more more redundant it will be more available and will use an additional source of information Fork whereing its data if the first one goes down doesn't respond timeouts or something happens so that's pretty much it about the apis available now let's talk about the contract verification for a bit so the idea behind contract verification is that we are trying to verify the contracts that are available on the network in the form of the bite code we are trying to match them with the specific source code that you have used to compile to deploy this bite code so the way it works is that once you have an unverified bite code on some of the networks we support you can go through the UI or through different clis we support that I'm going to talk about a little bit further down the line and you just send your source code files you specify the settings you used for the compilation such as the solidity version the number of Optimizer runs and so on and then the block Scout back end will compare the it will recompile your provided uh source code and compare if the bite codes match to what we have seen on chain and if it does then you will see this beautiful green tick uh in the block Scout UI and the UI will tell you that the contract is now verified you'll be able to browse through its source code you'll be able to interact it with the read and write contract tabs and yeah so actually in many cases block Scout can automatically verify and import some contracts that it have seen already in the past on on either the same block Scout instance under the different address so for example if you deploy same contract multiple times to just test it multiple times again and again High chances that these contracts will be automatically verified because the bite codes are identical and if you verify the first one then the second and subsequent ones will be verified automatically then we are able to import identical contracts also from other blog Scout instance connected through the blog Scout by code DB database then we're able to automatically import uh smart contracts from other source code verification providers such as sourcify and then in the future this source code import will be also available to you you will be able to directly import any verified contract through that was ever verified on some other different networks through some other different blog Explorer and this will all work with the help of a verifier Alliance initiative which is basically idea that we want to create this Shar database of all verified contracts and we are working on it with a couple of different partners routes can tenderly sortify and block Scout so this is coming very soon and if your contract is deployed for the very first time then you'll have to do some manual actions to be able to verify it so basically there are a few ways you can do it so the simplest way that works best for small and single file smart contracts is you can just go to the block Scout UI click some buttons fill in a couple of settings submit copy paste to your source code and verify the contract through the UI so this was works best for the most simple contracts and for Viper contracts then you can build your custom verification pipelines by using the raw block Scout API for the verification you can verify VI via any verification plugin for example in sourcify and then import the contracts into block Scout this works well too you can use some automation tools or Dev Frameworks to verify and automate your verification tool so if you're confident in using Foundry there is a flag for that for verifying your contracts automatically using Foundry CLI there is the same for hardhead or you can use some automation tools like catapulta to verify your contracts automatically on multi-chain deployment and if you want to learn more about the verifier lines initiative please scan the QR code and uh follow the news join the community and yeah see what's going on there and the last point I want to talk about in contract verification is that we also support a bunch of different proxy patterns so proxy patterns is a very common way of deploying contracts nowadays so whenever you want to do some upgradeability stuff or you want to reduce the onchain footprint of your smart contracts to reduce the gas cost and so on that's the typical use case for proxies so and there are different proxy types that we support there are immutable minimal proxy standards there are some storage slot based proxy standards that put the implementation address under the specific slot and there a few others and we support all of them the block Scout UI will automatically detect so you don't have to click any butons to detect this proxy it will be automatically detected once someone opens this contract in the block Scout UI and yeah we'll conveniently show the detected proxy type will be the UI will also allow you to interact with the underly implementation directly through the UI when you are going to the proxy address so now a few quick words about the bounty we have so we have a very simple Bounty throughout this hackaton so basically it's a 20K of the pull price and that's it and we're going to split that evenly across all qualifying projects and teams that qualify the following requirements basically depending on the specific de your building or specific projects we understand that everyone has their own requirements their own needs some teams have Smart contracts some don't some need API some don't so just try to use blog Scout as much as you can throughout your project if you have some smart contracts go ahead and verify them check that they verified and lock Scout try to interact them with blog Scout if you need some data such as token transfers for a specific address use the block Scout API to query that if you have some links linking from your dub to onchain transactions that the User submitted through the um onchain wallet you can put the blog Scout links on that after the transaction submission if you want to include your dab in the blog Scout dab Scout Marketplace which is the marketplace of DBS we have for a bunch of different Networks you can also fill out this um Marketplace submission form and basically the most important requirement after that is we just want to see how you use block Scout in your final presentation either it going to be live in front of our desk or when you record the video just mention how you use block Scout interact with the block Scout when you go through and show a bunch of different transactions to the judges so just show how you use blog Scout in your final presentation and that's it you're good you're qualified you'll definitely get a share of this 20K price so that's it for this Workshop if you have any questions please ask otherwise Happy hiking join our communities and uh if you have questions after this Workshop please come to our or if nobody's there please an ask them in their if Global blog Scout partner Discord all right thanks guys