Data Architecture Take-Home

Introduction

Osmosis is a decentralized exchange that is focused on providing traders with the best in-class opportunity to swap tokens.

Being an app-chain, Osmosis has its own network operated by 150 validators.

As a result, it heavily relies on applications such as blockchain explorers that would offer users and developers the opportunity to inspect the historical state.

Some examples of the Osmosis explorers created by the community:

• Mintscan
• Celatone

Task

Osmosis now wants to build an in-house data indexer and a blockchain explorer application using it.

Application requirements:

• Must be able to display all pool types
• Must be able to inspect blocks
• Must be able to inspect transactions
• Custom Requirement #1 (Optional Bonus)
• Custom Requirement #2 (Optional Hard Bonus)

To start, focus on the first 3 requirements. We suggest attempting to integate bonus requirements on top of the acrhitecture that is already defined.

Custom Requirement #1

The current indexer implementations do not display human readable denoms. Instead, they show on-chain representations that, oftentimes, start with "ibc" prefix.

• Ref

We would like to have the opportunity to toggle the view and see the human-readable denoms on every screen. Especially, in the transaction inspection view.

Note, that we track all translations via this file that is auto-updated on new token listings.

Keep in mind that not all tokens are listed. If the translation does not exist and we toggle the human redable denom option, we would like to still show the on-chain denom to the user.

Define your data architecture in a way where this functionality can be enabled.

Custom Requirement #2

Osmosis has the notion of epochs where every epoch (e.g. day) the chain distributes rewards to liquidity pools.

We would like to design a custom screen that would breakdown the incentive rewads distribution to each pool per epoch.

The screen is to have a list of epochs. Each epoch can be expanded with a dropdown where pools a paginated. 50 pools per page. Each pool has a reward distribution associated with it during that epoch.

Deliverables

• Written summary describing the architecture. Provide as much context as you think is necessary for an Osmosis leadership stakeholder to understand the design and trade-offs.
  • Data ingestion patterns
  • Types of data ingested, transformed and stored
  • Data retrieval patterns
  • Storage
  • Tools to be used
  • Ensure that you take into account Osmosis-specific constraints such as events and attributes format, block times and any other consideration that you think is important
• Architecture Diagram
  • Ensure that all 3 system components are taken into account:
    • Osmosis Node
    • Indexer
    • Web Application
  • Include any other components based on your choice of the architecture

Resources

• Transactions Indexing in Tendermint/CometBFT
• Cosmos SDK Events Documentation
• Concentrated Liquidity GRPC Query Server
  • Note that each Osmosis and Cosmos SDK module (modules are under x/ folder in root) has their own gRPC server.
  • These are code-generated from proto files under the proto directory.
• Osmosis Pool Models
  • Balancer
  • Stableswap
  • Concentrated
  • CosmWasm
• Swap Message Example