Blocktorch
Listen Now
About This Episode
Gery from Blocktorch returns to DevNTell to showcase the updated beta version of their Web3 observability platform. Blocktorch is designed to help developers monitor their decentralized applications across multiple chains (Ethereum, Polygon, and BNB) and layers. The episode highlights features like smart contract monitoring, event-based alerting, and the Dragon SDK, which captures frontend errors that never reach the blockchain. Gery also discusses the future roadmap, including non-EVM chain support and integration with Web2 monitoring standards like OpenTelemetry.
Key Takeaways
Blocktorch is an observability platform aimed at simplifying the monitoring and debugging process for Web3 engineers.
The platform bridges the gap between on-chain data and off-chain frontend events using the Dragon SDK.
Users can set up specific monitors for metrics like gas price spikes, failed transactions, or account balances with automated alerts for platforms like Slack and Telegram.
Blocktorch is building toward an ecosystem-agnostic future, planning to support non-EVM chains and decentralized storage solutions like IPFS.
The tool is designed to be compatible with OpenTelemetry, allowing developers to integrate Web3 data into existing observability stacks like Datadog or Sentry.
Featured Guest
Gery Pollak
Founder @ Blocktorch
Timestamps(click to jump)
Episode Transcript
Read full transcriptHide transcript
All right, we're live. GM, GA, GE everybody, welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute window for builders to showcase something they're passionate about or been working on in Web3. This can be an awesome project you've been working on, demonstrating testing best practices, automation goodies, smart contract slash how to structure a project, etc. Basically if you've got a passion for something, this is your opportunity to share it with the community here. And today I am ecstatic to have back Gery from Blocktorch who will be giving us a updated look of his project Blocktorch.
Thanks for the invitation.
My pleasure, my pleasure. Thanks for coming back on. I guess for our viewers that didn't catch you the first time, maybe do you want to do a brief introduction of yourself, how you got into Web3, how you started Blocktorch, how you got into DD?
Totally. So we started Blocktorch, or to work on the idea of Blocktorch pretty much a year ago. That was also pretty much the time when I joined DD. That was around the time of ETH Amsterdam, which I believe was mid-April 2022. And Amine, my co-founder, and I, we basically started with that idea that we believe better observability tooling, or in general better dev tooling, that makes the life of developers easier for Web3 engineers is needed. To not only kind of have the chance to build great applications, but then also to actually observe them and monitor them and scale them up and understand are there any problems that the users are facing due to any problem in the tech stack or not. And I personally actually started investing in crypto in like 2017. I started to learn Solidity in like 2020, yeah 2020, with the whole DeFi summer where I started from a user and then was like, okay what is actually happening there in the back after a couple of rug pulls. And then, so after a couple of being a victim of rug pulls. And then, and then basically that was my journey to Web3 and then I decided that I also really want to build something and believe it's, even though it's like a tough market right now, it's a great actually market to start building and to think there is great dynamics and great motivation from everyone in the space to really give a push to Web3 in total and blockchain technologies in total and build cool stuff.
Yeah man, that's pretty parallel to many people's stories in just like you start out, start out as a speculator, you get wrecked a couple times and then you become a builder. So yeah, I've been there. And I believe the last time we met you were quite a small team. Have there been any changes in that? Have you guys expanded or whatnot?
Yes, totally. So basically the last time we spoke we were kind of like three and a half-ish people, we are right now six people. We are working as a fully remote team out of the European time zones. So basically from the London time zone to the Istanbul time zone. And yeah, we will also announce some interesting funding news next week. So definitely keep an eye out for that.
Excellent. Yeah, can't wait to hear it. And yeah, looking forward to seeing what you have in store for us today in that updated look here at Blocktorch.
Totally. So let me share my screen and I will basically jump right into our beta that is not yet available for everyone. So if you basically want to be updated as soon as it is going live, you can just go over to our website blocktorch.xyz and request access to the beta and then send us an email and we'll have you basically on our list. Or otherwise just wait for a couple more days and then revisit back the website and it will have a new look and feel and it will also basically give you access directly to our beta.
So what you see here is the login screen. You don't need to sign up or anything like you can just either login by email, you will get a magic link or you just for example login with your socials or with your wallet. So we support all of it. So I'm now logging in simply with my GitHub. And there was some home screen that you saw that basically is not done yet. So there was some mock data there. But yeah, the idea is that you will first add your contracts. So for that purpose I will be adding the contract of the CODE token from Developer DAO. So let me get the address. You can see already here that we are supporting with the beta Ethereum, Polygon and BNB Chain. So if we look for the CODE token from Developer DAO it should now find it. Yeah, great. There indeed also are two contracts that are not verified with the same contract address on Polygon and Binance Chain that we detected. But in that case you can see here this is the CODE verified smart contract. So we're going to add it. We are still a bit work in progress. So in that case even though it's verified, we have to copy-paste the ABI directly. Otherwise that's the idea, we're going to fetch it from the block explorer, in that case Etherscan, if it's already a verified and published contract. So there will not be anything to do for the user. And you can give it a title that can be different to the one that is public. So also if you have any smart contract that is not verified, you can also upload a JSON or paste the ABI here and it will stay private. So basically all of that information that you add within Blocktorch is not going to be shared with anyone. Just basically the public information that is on the blockchain available of course can be seen by everyone that's by nature by the blockchain, right? And then let's give it some kind of description. So it's like the DevNTell demo. Save the contract and with that it should show up here. So this is a live demo right now of the product. It's not a mockup or anything. Okay, seems like the contract service maybe is under construction right now. So then you will see here like your contract. The idea of the overview is that once we go live with the beta you will basically be able to add as many contracts as you want. And then you will also see some key metrics about it. And you will also at the end of the day be able to kind of like visually see if any contract is impacted by any anomaly or any behavior that you would wish not to be the case. So you can at one glance see directly, okay what's kind of like the topology of my contracts, is there anything that I need to dive into or not, or any contract that I could maybe kind of like monitor more closely.
And then coming to the monitoring part. So one big important piece of observability is of course monitoring and setting monitors and setting so-called service level objectives. So you'll be able to set service level objectives on your contracts, but not only on your contracts, also actually on off-chain data. So we have developed an SDK called Dragon that is open-sourced. So already even today if you check for like @blocktorch/dragon on npm you will find it and you can add it to your frontend and with that we are able to fetch transactions that are failing in the frontend already. So you can for example set a monitor which is monitoring the number of failed transactions in your frontend that never make it on-chain. So when a user tries to transact, the wallet pops up and it basically acts as a like it tries to propagate that call already to an RPC node and there if there's any error there already because there is some bug in the frontend code, then you will never see that on-chain but the user actually is experiencing an error. You could also for example say okay from the frontend, from Dragon being triggered to a successful transaction being mined, what's for example the latency. But let me show you an easy example. So as said there are service level objectives as well. So this is more of like a percentage metric. This would be an event-based monitor for us or we do a metric-based monitor. Let's just do a metric one where we say for example the contract of the CODE token, of course if you could have added or if the contract service would work correctly, then this should now here be easier to choose. I just copy-pasted it again. We say the aggregation function is count and we choose transactions. For example we want to monitor transactions with a gas price of more than 70 Gwei. I believe at the current state of gas price this is quite expensive. We can say this should be monitored on a one-hour rolling basis. We can also make it longer. We probably will also add like by block even if if you want to set specific monitors that are just block specific like for example your position in the block. If that's something that's relevant for you, you could basically monitor it by block and say okay the position should always be a percentage target or or like a specific value. And here let's say the number of transactions that has a gas more than 70 within one hour, you would expect it to be zero. And let's call it DevNTell gas monitor spike demo monitoring gas spikes and then you can add this. We will basically be able to show you the data right away. This is under construction. So what you're seeing right here is just a line because it's not working exactly as it should but here you can already see that basically this is the monitor that we have just added. You can add as many monitors as you want. You can play around with it. We're going to have some examples in our documentation but any kind of state change, any kind of like you can also look for nonces changes, you can analyze wallets, let's say for example you want to know whenever someone with a nonce less than 10 is interacting with your smart contract that means that basically it's a completely new wallet or someone maybe inexperienced you might actually want to somehow have in your frontend some some action that maybe supports this user better going through the flow as it might be a very new person to Web3 or it's just a new wallet. But I think you can get kind of like the idea and then we support bar charts and line charts for now and then you will be able to visualize all of it and whenever your targets are being breached then it will trigger an alert and you will basically see that alert. And then in the next iteration in the next couple of days we'll also add a notification engine then you can basically also get a notification to Slack or Discord or Telegram or wherever you would like to get your alert sent.
And then third part is the log manager. So one thing is basically adding your sources. So that can be Dragon for your frontend as said, the SDK, or all the smart contracts that you want to add. And then you can also search through the logs as well as the traces and any kind of transactions and showing you there what I mean. So basically you can for example search for Dragon. Let's see if we have some data here right now. You will see here from the Dragon data so that is frontend data for example, okay one has was an error so that is a transaction that never really made it on-chain at the end of the day with the error message. So VM exception while processing transaction, reverted with bad intentions. We triggered that on purpose. So we tried something out earlier today. Then here you see for example success. So what does it mean if Dragon shows a success? It means that basically Dragon caught a transaction that was triggered and it was then also mined on the blockchain and then we could basically put it together. And if we click and expand the details we not only see the transaction data but you will also be able to see the full stack trace. So here we can see that that was a static call and we're working on basically fine-tuning the data here right now to make it more digestible and really see every single step of the transaction as it makes the journey from the frontend to actually being picked up by a node and then also being mined. If we for example only search for traces, we will see here the different basically trace elements and again we will show additional information about that transaction data so that you can always basically see all of it. And then searching for transactions would just be the classic kind of like okay let's search for transactions on Ethereum and Polygon. Okay both of it would not work but here if we only go for Ethereum right now we would basically see the transactions on Ethereum. We are working on kind of like the idea and that is something that we will also gather feedback if we should just support to see all logs from Ethereum right now which is the case right now or if we should only show the transactions or if we should only make it possible to search for transactions that are the contracts that the user has added. So in this case we would like to maybe only see the transactions of the CODE token without having to specify the contract. So we could of course also say okay we only want to see the transactions of the CODE token but we have not fetched any here right now. I also have to say I didn't check before when was the last transfer. It was five hours ago there was a transaction on the CODE token. So probably like the data here right now could not show that. But so basically that's the idea. We will be able to and we're still working on that as said to fine-tune it to add more facets, to make the data more relevant and to make the data also richer so that you can look for everything from like transactions to transaction details, to stack traces, to specific data within transactions. Let's say you only want to see transactions where the balance of your contract has been impacted in a certain way so that if you think about it in a holistic way you can set monitors, you have monitors for specific data and then you will be able to see whenever there are any spikes or any problems or any anomalies that occur to also see all the logs that basically go hand in hand. So let's say you have a monitor where you get notified when there are no transactions with your contract after a certain period of time like a liveness detector or so or from a specific wallet where there are suddenly no transactions from that wallet anymore. You might want to basically dig into like the logs okay what happened there is it because suddenly there was a bug in my frontend so Dragon still catches transactions actually but they just fail or is there no transaction at all anymore. Like what's going on and then you can basically identify the root cause better. That is kind of everything I wanted to show you guys. As said it's still a bit work in progress. Oh true maybe one more thing to show as it's interesting. So in that way you can basically invite new users, you can add emails and then they will be added to your project and they can also see the monitors that you have set if you're like working in a team. You can create an API key if you want to use Dragon. So for Dragon you will have to create an API key. And for the search one nice feature also is like let's say you build a complex search. Right now the complexity maybe with the current facets would be rather limited. But let's say you like you build something very complex or you also just want to maybe look for some easy thing and you want to share your exact search result with someone else so that person can look at the exact same logs that you looked at. You can just take the URL from the log manager which is not shared right now in the screenshare. You can just copy-paste it, send it over to your friend, your colleague, someone you trust with and you want to look at your project and your search and your logs. And then that person can click that link and basically is directly invited to it and can open it and sees exactly the same as you shared. So in that case if I would share this link here right now with you Narb, you would be able to access it and see exactly the same.
That's excellent. Yeah, especially for troubleshooting and reporting, say you're on call or something like that.
Yeah, exactly. So that's the idea.
And I have a couple of questions from my end, but for our viewers, if you have any questions, please post them in the comments section here and I will ask on your behalf. But I saw you supported three chains I believe at the moment: Ethereum, Polygon and Binance Smart Chain if I'm not mistaken. Are there any plans to go beyond that and expand beyond the reach of EVM, so say like Solanas and Nears of the world?
Totally. So basically we see the stack of the transaction kind of being let's call it like multi-layered. One layer are kind of like the blockchains that the decentralized applications are built upon. And there like the initial idea now was okay we support the three biggest EVM chains. They are still by far the largest of all ecosystems and then we go from there and see okay where is the need the biggest instead of us kind of like making bets on certain let's call it like developer ecosystems. So yes definitely we also built the product in a way that this is not too hard to just add other chains as data source. And that also leads me to other data sources. So we are basically not only going to add other chains but we're also going to add other data sources. So the end goal is like you should be able to see logs from your oracle in there for example. You should be able to see logs from from your data storage like a decentralized data storage like IPFS on there. You should be able to maybe if you're like a Web2.5 app developer, you might be using some observability tools already from the Web2 world like Datadog or Sentry and they are all using a data form called OpenTelemetry which is like a standard and we also ensure that we are compatible like we are using OpenTelemetry as well. So it will be able to kind of like either take Blocktorch data and ingest it into Datadog for example or take Sentry data and ingest it into Blocktorch and then kind of like have all in one place instead of having to jump between different tools.
Yeah, that was actually my next question is like if a dApp, if you wanted to monitor your dApp, your frontend with all the blockchain data, is there an easy way to kind of congregate that data together without having to go from like Datadog to Blocktorch to whatever. But sounds like you guys thought of that.
Yeah. We do not have an API yet for the initial beta release to expose the data through an API. But yes, the format is 100% compatible. Like it is interoperable. You can directly take the data as we basically use it and can put it into Datadog and it will work out of the box.
Beautiful, love it. And in terms of the like alerting on the monitors, do you foresee yourself adding that capability in like the standard way like Datadog has it or whatever observability stack, like thresholds?
Exactly. So basically you set a threshold. If it's like an event-based, basically means the threshold is a percentage. So like the calculation, the general calculation is you take like your specified events and you divide it by the total events that kind of like make sense to your specified events. So if it's a transactions like let's say failed transactions divided by all transactions that gives you a percentage of failed or successful transactions and then you set your percentage target. If it's like a metric-based, let's say a count for example, so you don't want to or you want to be notified when I don't know the liquidity level of something drops below a certain threshold then it's like in that case it would be like in Ethers for example.
Gotcha, gotcha. And I guess on that alerting part, do you have plans to integrate, I know you mentioned that you will be able to send notifications via Slack and Telegram, are there plans for an integration with something like PagerDuty for example to get that full end-to-end?
Yeah, so we thought about kind of like from the beginning we will do like Slack and maybe Telegram and or some webhooks or email. And then we basically want to hear feedback from the users and from potential users which kind of channels they would prefer the most. We digged into the idea of using for example Push Protocol or XMTP which are kind of like these tools for wallet-to-wallet communication and sending push notifications to wallets. And so we even thought about okay it would actually be cool because it's the Web3 way right, to send an alert to a wallet. But then we would need to see whether actually a large number of users really wants that or not.
Yeah, that's true. You don't want to build something that like maybe 1% of your user base actually uses and not the other. Yeah, I feel that. I guess like what was the biggest or a set of the biggest challenges you faced like going from your alpha version to this version?
Yeah. So I think the biggest challenge was the whole pipeline. So we scraped the full kind of like like everything we had for the alpha we all threw away and we kind of restarted to build the beta from scratch with the learnings we made from the alpha. And to have like a pipeline that is fast, not only powerful but also fast with multiple chains being extendable so that we can actually iterate over it at other chains, other data sources. That was I would say probably the biggest challenge. And then the second part was also coming up with a really neat UI that and product design that allows users to build monitors and so on really fast. Like we have heard from so many builders in Web3 that they're super low on capacity. So building scripts themselves like or subgraphs or Forta bots or these kind of likes is just super time consuming for them and they don't have that much resources. So we're like okay we need to make it super fast and intuitive to start it off but still have the powerful capacity to kind of like write queries and build monitors that go deep into the data of for example a node.
Yeah, totally makes sense. You want to make that the developer's life, the developer experience as easy as possible and like having something like this like easy to set up ready to go is going to be like awesome, awesome going forward. And I guess can you reveal a little bit about your project's roadmap? I know you were saying your release of this beta version is coming up soon. Do you have or can you speak on what's kind of beyond that at this point of time?
Yeah, so as said like the beta release is going to happen next week and then for us it's all about learning about how users interact with Blocktorch, learning about their feedback. So please either through the Developer DAO Discord or just on Twitter or any other means like please reach out if you have comments, feedbacks and whatsoever. We really want to kind of like learn from you guys on how you're using the product and what you like about it, what you hate about it, what do you think needs to be done differently. And then the future roadmap will really be also kind of defined by that feedback. We have a lot of ideas and things that we want to add and want to build and again make that life of developers even more easy and build out a more and more powerful observability platform. But it all has to go hand in hand with what the user really needs. So yeah, so at the end of the day there is nothing concrete I can say about the future because it really depends on what we're going to learn in the next couple of weeks and months.
Makes sense, makes sense. And I guess if people do have feedback, you mentioned reaching out over Discord or Twitter. What are your handles on that and is there a form perhaps that people can fill out with like a feature request or feedback?
Yeah, so on the handles probably the best is if I write them here into the chat right and you can include them. My Twitter handle is @gery_po. Discord oh I actually don't know the full Discord handle. Like I don't know the number that is attached to it by heart. But yeah, so if they look for Gery they will definitely already find me in the Developer DAO users. And there is no form on the website yet but there will be a form in the app to give feedback. So when people try it out of course we'll have like a form or a link embedded to just reach us and then they can also just send an email to contact@blocktorch.xyz.
Beautiful. Love to hear it. And yeah, I guess with that we're basically at time here. So thank you very much again Gery for coming on. Really looking forward to to that launch next week and getting this in front of builders' hands to start playing with and you're more than welcome to come back on the show and show us what you've developed just like the last time so looking forward to it. Also nice, happy Friday and happy weekend. All right guys, cheers, all the best. Bye!
Listen On
Share This Episode
Share on XWatch Episodes Live!
Subscribe to our event calendar and never miss a live episode.
View Event Calendar