Intro to the Laconic Stack

Here’s the main problem: reading data from the Ethereum blockchains is either cheap and sloppy or expensive and correct. As a result, Dapp developers have come to rely on inexpensive centralized services that do not provide evidence to verify the correctness of the data they are serving to Dapps.

Not only is it expensive to get verifiable data but it can also be challenging to parse out the subset of data you really need. In the early days of SQL, you had to be proficient at the command line in order to use the product, and so use was limited to those that had that specialized capability.

Eventually, GUIs were built such that anyone with basic computer skills could use drop-down menus and create database schemas without writing a single line of code. Web3 is still in the early days of SQL, it is not easy onboarding new users and developers who are otherwise quite capable with the latest Web2 technologies.

Right now, there’s all this data on Ethereum and as a Dapp developer, you only want a tiny fraction of it. But, to verify that fraction, you have to (among several other things) maintain an archive node - this is prohibitively expensive for the majority of developers. To solve this problem, centralized services such as (Infura, The Graph, and Alchemy) have popped up and currently account for the majority (if not most) of Dapp queries to Ethereum.

Laconic was created to address these and several other problems in the blockchain ecosystem. Not only does Laconic make it easy to get verifiable data - quickly and cheaply - it also provides a framework for data transformation and aggregation that are difficult or impossible to do in other systems.

Architecting a solution to this requires many moving pieces; these have been developed by core Ethereum & Cosmos contributors over the past 5 years. In this post, we will walk you through the various components of the Laconic Stack.

There are three different ways to participate in the Laconic Network: Member Validators, Service Providers, and Dapp Developers. To describe the responsibilities and benefits of each role, we must first start grounded in the technicalities of the Laconic Stack.

Refer back to the diagram at the top of this page. It intentionally leaves out several repositories (e.g., codecs, utilities, rpc shims). This is done for simplicity reasons and anyone diving deep into the stack will discover them.

The two repositories at the top are also the main entry points for most developers. `stack-orchestrator` is a command-line tool for, well, orchestrating the stack. It uses docker-compose to deploy a specified collection of networked docker containers, thereby eliminating the need to set up a variety of services independently. Every user of the Laconic Stack will at some point - if not regularly - use the stack orchestrator.

The `watchers-ts` repo contains the core watcher generator codebase. Watchers are TypeScript that is generated from one or more Solidity smart contracts. Dapp Developers can participate in the Laconic Network by either 1) writing a custom watcher for their Dapp or 2) writing a generally useful watcher and publishing it to the Laconic Registry, thus earning a fee every time it is used. We’ll come back to Watchers later.

Down at the bottom left is the `laconicd` repository and it is indeed the “bottom” of the stack. It is built from the Cosmos SDK and has custom modules specific to operating the Laconic Network (e.g., fork of Ethermint/Evmos, auction, nameservice). It is likely that in the future there will be a public testnet, however, because the Laconic Network is a permissioned validator set, only Member Validators that have officially joined the Laconic Network will be included in the mainnet. Just because the validator set is permissioned does not prohibit anyone from running a full node and Service Providers or others may choose to do so for a variety of reasons.

The `laconic-sdk` is a library for facilitating talking to `laconicd`. Both the `laconic-registry-cli` and the `laconic-console` use it. While `laconic-registry-cli` is a command-line tool for doing so, the `laconic-console` is a user interface for writing and reading records on the Laconic Network. These general-purpose tools are useful for a wide variety of use cases across the stack.

A key goal of the Laconic Network is to provide accurate, verifiable data from the Ethereum blockchain. Comparisons to currently available solutions are for another post, however, no service currently exists to provide inexpensive evidence that the data being served is correct. The Laconic solution (one of) to this is in something called “statediffing”, a part of the stack run by Member Validators and, likely by Service Providers.

It starts with a maintained fork of `go-ethereum (geth)` that has an added real-time state-diffing service. Statediffing gives a clear picture of the state between any given blockheights. This allows Laconic to minimize the amount of computation required for providing proofs. Three additional “helper” services perform different tasks required to get a full picture of the state as required by an application. Together, these comprise the Full Index Node (FIN).

The `eth-statediff-service` provides historical state data, while the `eth-statediff-fill-service` uses the historical state data to fill statediff gaps as required. Finally, the `ipld-eth-state-snapshot` loads a complete state at a certain blockheight, which helps to bootstrap the system. 

There is more to be written about statediffing, however, what’s important to note here is that each service is writing independently to `ipld-eth-db`. The latter serves as a bucket for state data that has been indexed in IPLD. Rather than querying this database directly, the `ipld-eth-server` provides an API layer for Watchers to easily query relevant pieces of data from the Ethereum state. Additionally, `ipld-eth-server` recapitulates the native Ethereum JSON RPC interfaces on top of the `ipld-eth-db` database.

And so we’ve come full circle back to the Watchers. As previously mentioned, they are generated from one or more Solidity smart contracts and configured to query specific pieces of data relevant to a Dapp. Watchers make it easy to query the data you need from Ethereum and - along the way - get evidence in order to generate proofs that your data is correct. This is in contrast to currently available solutions for Dapp developers, who must currently rely on centralized providers that don’t provide evidence to generate proofs.

Web3 is (still!) in its early days, and like the early days of SQL, Dapp developers need advanced knowledge of complex data structures to build their Dapp. Watchers simplify this by exposing a GraphQL endpoint, a solution familiar to an order of magnitude more developers than querying the Ethereum blockchain directly.

Laconic is building a suite of tools to address core problems in Web3. Today, we’ve provided an overview of the main components of the Laconic Stack. Developers interested in Laconic should start with `stack-orchestrator` to get a sense of running different parts of the stack, then check out `watcher-ts` to experiment with different watchers and progress to making their own.