With web3 growing rapidly, observability is essential to ensure a better operation of decentralized applications and smart contracts as complexity is reaching new levels. Till now, web3 developers had no developer friendly observability tooling for the decentalized stack.
Blocktorch is solving this problem for developers in web3.
Amine and Gery founded blocktorch. With their passion for Web3, they saw the need to bring more mature builder tools to market to consequently achieve web3 mass market readiness. One core pillar of tooling needed at large scale are dev tools to enable more efficient ways to maintain reliability and security of decentralized applications. At blocktorch they transfer established web2 observability principles to web3 and enhance them with new concepts suited for the decentralized stack.
Amine completed his Bachelors in Applied Mathematics in Morocco to consequently graduate from reputable universities in Germany and France with two Masters in Computer Science. He has 7 years of experience as a software engineer and technical product manager in tech giants as well as a unicorn scale-up.
Gery is a 1st generation college graduate who holds one Master in Management from London Business School and one from Fudan University Shanghai. He has 3 years of experience in business development in FAANG and 3 years of experience in supporting and investing in software start-ups as venture capital investor. He also has self-taught skills in writing smart contracts and developing UI for Dapps.
In the beginning, they investigated node health monitoring and sought to identify any errors occurring at the node's execution level. They then realized this was less important, though, and moved on to researching the reliability and security of smart contracts function executions. They began with Ethereum and considered other EVM chains and options outside of EVM, such as Solana and Near Protocol. The original plan was to provide a simple status summary of smart contract performance. Still, while developing, they understood the need to cover the three pillars of observability: traces, metrics, and logs in the whole decentralized stack.
Blocktorch offers superior developer experience and covers all observability pillars to view and analyze smart contracts. They provide observability as code, enhanced alerting capabilities via customizable Service Level Objectives, and intuitive search and visualization tools (with elastic search & dashboarding). Additionally, you receive built-in support for various different chains.
Furthermore, the blocktorch team aspires to provide a comprehensive observability platform that goes beyond smart contracts, enabling users to see any request made to oracles, decentralized persistence layers, smart contracts, node providers, and the user interface. Basically, your one-stop shop for all things web3 observability.
How blocktorch works?
Blocktorch is your one-stop for analyzing your smart contract capabilities and relevant, customized metrics in the best possible manner, all from a single dashboard. Here is what it looks like!
Adding Smart Contracts
- Any newly deployed contract is automatically uploaded to blocktorch by interacting with the deployment process, enabling more advanced functionalities like the tagging of functions and smart contracts.
- Users can also manually add contracts through the deployer wallet or the specific contract address if they do not wish to use the integration with the deployment pipeline or for smart contracts that have already been deployed.
Viewing contract page
- Contracts can be clicked to go to the contract information page. The red color coding shows an identified anomaly at that contract.
- Each contract's summary displays its methods, metrics, and SLO (service level objective).
Viewing the SLO method board
- Investigations should be conducted if there are Alerts or Warnings in the SLO status; clicking the alerts navigates to the board for the particular contract's SLO method.
- The SLO method board draws attention to all SLOs specified for a given contract and displays a time series to show which methods have resulted in SLO breaches and when.
Opening log manager
- Simply clicking on an SLO will open a log manager that lists all transactions and events connected to that method.
- The log manager is powered by elastic search and enables robust search capabilities with human-readable search functionality.
Users can use the log manager to search all queries they are interested in to rapidly discover the information they need. When analyzing an anomaly, the search query will be constructed automatically to find the context even faster.
Additionally, the log explorer displays metrics on the filtered transactions, including top wallet interactions and the progress of transaction execution over time.
Expanding transaction views
- Any transaction has extensive information that can be obtained by expanding the transaction.
- The full details of each transaction, including the stack trace and gas breakdown, are available in the transaction details.
- Multiple transaction details can be opened next to one another to compare comparable transactions, such as the variance in gas prices.
Setting up a new SLO
- The SLO status board displays a list of all established SLOs together with their current state and fundamental requirements. Simply adding new SLOs allows for the addition of additional SLOs.
- The first step in setting up a new SLO is to specify the Service Level Indicator, a query that users can construct to establish the appropriate benchmarks for their product.
- One can establish a percentage gauge for the performance of a single method execution by defining the good events and dividing this by the total events. If necessary, users may also utilize absolute numbers rather than percentages.
- Indicators can be configured with as much flexibility as the user needs across contracts and chains. Additionally, blocktorch can suggest off-the-shelf SLOs for similar services..
- Once the indication has been created, the target must be determined within a specific time frame.
- Teams using blocktorch can assign names, descriptions, and tags to the SLOs to ensure efficient teamwork.
- An alert that specifies the message, the recipient, and the channel—such as Slack or PagerDuty—can be configured as the last step in creating the SLO. Blocktorch guarantees that no anomaly is ever missed while preventing alert fatigue.
- Error budgets can be used for particularly important SLOs. The appropriate user will be alerted at the set thresholds while the error budget is being used up.
What does blocktorch hold for the future?
Blocktorch's overarching goal is to offer observability for the entire decentralized stack. They gradually introduce observability for additional decentralized services such as off-chain data storage, decentralized file storage, decentralized hosting, and so on. Additionally, they also wish to support every blockchain engineers are using and are considering other chains to expand, for example, Near Protocol or Polkadot, while starting with EVM and already developing support for Solana.