Subscribe to dias.xyz to receive new posts directly to your inbox.
Subscribe to dias.xyz to receive new posts directly to your inbox.
In this post I share my thoughts about observability in blockchain applications. While this post is mostly valuable for blockchain developers, it can also be useful for financial analysts. Blockchain analysts and researchers need to understand operating systems and observability to analyze crypto activity.
World computer is a new way to describe how blockchains enable new forms of applications. Instead of developing an application and running it on your personal server, you can create and run it on a world computer. Your program will keep living even after you or your company die, as long as the world computer lives.
Blockchains are so-called world computers that provide decentralized infrastructure for decentralized applications. (More about world computer at world computer day)
While developer experience is different in crypto, developer practices are not completely new. Applications need observability tools. While it's easy to configure the observability of off-chain components, on-chain logic requires a slightly different approach.
Observability in centralized services revolves around three core pillars: logs, metrics, and traces. Modern observability tools like Datadog APM, New Relic, Splunk, and Grafana help developers implement and manage these pillars.
Logs: Logs record system events and errors, and provide insights for debugging and analysis. Tools like Splunk and Datadog help aggregate and search logs efficiently. (Collected by Splunk or Datadog, visualized in dashboards.)
Metrics: Metrics track performance indicators like CPU usage and response times. Grafana and New Relic visualize these metrics for better monitoring. (Collected via New Relic or Prometheus, visualized in Grafana.)
Traces: Traces follow the flow of requests across services, help developers detect bottlenecks, and improve performance. Tools like Datadog APM, OpenTelemetry, and Jaeger enable tracing in simple and distributed applications. (Instrumented with Datadog APM or OpenTelemetry and analyzed in Jaeger.)
By combining these tools, developers gain insights into application performance and security. Datadog has a portal with great resources if you want to learn more about application observability.
Developers of centralized applications use tools like Datadog, New Relic, or Prometheus to monitor performance across layers: application (code execution and APIs), operating system (CPU, memory, and disk I/O), and hardware (health and network performance).
In contrast, decentralized application (dApp) developers have no control over the execution environment since their code runs on the "world computer" (a virtual machine shared across network nodes). Instead, they adopt alternative strategies:
Since smart contract developers don't control the runtime environment and it's not trivial to directly query the world computer, they rely on indexing tools to track events, state changes, and transaction traces. Indexed data can be queried for insights, debugging, and analytics.
Data Warehouses and Cloud Indexing Tools: Platforms like Dune index logs, metrics and traces, and decode them into human-readable format. Dune and traditional data warehouses like BigQuery or Clickhouse provide infrastructure to query indexed and decoded data.
Local Indexing Tools: Tools like Sim, Envio and Ponder enable indexing of contract events and metrics locally. They provide faster access and greater control over data.
To test and debug smart contracts, developers use simulations and forks to reproduce real blockchain environments.
Cloud-based Simulations:
Services like tenderly make it easy to simulate contract transactions and visualize how things will play out without deploying smart contracts to the mainnet. sim and shadow take simulations further by letting users instrument their transactions for better observability.
Local Forking and Simulation:
Most of the EVM developers run local copies of blockchain nodes to test contract logic. Foundry is a powerful tool for local forking and simulation in EVM development. Foundry lets developers fork any EVM network and create a local replica of the blockchain state, simulate contract interactions and possible on-chain scenarios.
In traditional systems, observability relies on logs, metrics, and traces, collected from your app, server, and infrastructure. On-chain, you don’t control the infrastructure - so you observe what the blockchain records.
Traditional (e.g., Datadog) | Blockchain (Dune) | |
|---|---|---|
Logs | App/server logs (custom, structured) | Smart contract |
Traces | Request spans across services | Internal calls between contracts |
Metrics | CPU, memory, latency, custom KPIs | Derived from logs/traces (e.g., usage, errors, financial metrics) |
Environment | Fully controlled by devs | Public, immutable world computer |
Tools | Dashboards, alerts, live metrics | SQL queries, alerts, dashboards on indexed data |
Local forking and simulation are straightforward for small EVM chains, but become far more complex on high-throughput blockchains like Solana or parallelized systems. Analyzing smart contract behavior at that scale often requires navigating hundreds of terabytes of data. As blockchains evolve into true world computers, cloud-based indexing and simulation will become critical for observability.
To build reliable, scalable applications on decentralized infrastructure, developers need the same level of visibility they’ve come to expect in traditional systems - only now, it has to work on an open, shared, and immutable runtime. The world computer requires world observability.
