Skip to content

Development Milestones Deeper Dive

Jump to bottom
pharr117 edited this page Oct 15, 2023 · 2 revisions

Milestone 1 – Cosmos SDK v0.47 Refactor + Probe Extension

Summary

Goal

Refactor the application to use Cosmos SDK v0.47 and the easier to maintain/extend DefiantLabs/Probe repository. The Probe repository provides the RPC querying functionality necessary for the application to query blockchain data and parse protobuf type implementations for Transaction Messages.

Objectives

  1. Dependence on Cosmos SDK: Use version 0.47 for all base Cosmos module functionality.
  2. Easy Extension: Support Transaction message types in the future by including protobuf type implementations for custom/non-base modules.
  3. Custom Querying: Extend custom querying methodology for module-specific query commands for custom indexing capabilities.
  4. Replace and Update Cosmos SDK: Move to the official v0.47 release of Cosmos SDK and update the codebase accordingly.
  5. Probe Dependency: Depend on the simplified Probe repository for all RPC querying and Protobuf Message type definition support.
  6. Extend and Validate Protobuf Definitions: Handle all supported Protobuf Message type definitions and validate the dependency on the latest definitions for Messages in base Cosmos modules and custom modules.

Milestone 2: Generalized Indexer Implementation

Summary

Milestone 2 focuses on implementing a generalized indexer that can accommodate various data points consistently. This system will index information into tables to manage and query data effectively. However, it does not offer fine-grained control over data shaping.

Goal

Rework the application indexer loop to index all data in the lifecycle of a block and transaction. The indexer will index a blockchain with customizable configuration values to indicate the desired level of granularity for the generalized indexer implementation.

Introduction

Every Block has a consistent set of data points. This milestone is intended to index these consistent data points into a general data format.

Indexing Details

For example:

  • Blocks: Will be indexed into a Block table.
  • Transactions: Will be indexed into a Transaction table.
  • Messages: Will be indexed into a Message table.
  • Block Events: Block events and their attributes will be indexed into a BlockEvent and BlockEventAttribute table.
  • Message Events: Message events and their attributes will be indexed into a MessageEvent and MessageEventAttribute table.

Ruleset

  1. If Indexing Blocks Only, Then Index: a. Basic Block data b. All Block BeginBlocker events c. All Block EndBlocker events d. Events with all key/value pairs indexed
  2. If Indexing Block Transactions, Then Index: a. Basic Block data b. For each Transaction in a block, index basic Transaction data c. For each Message in each Transaction, index: i. Basic Message data ii. All events per Message iii. Events with all key/value pairs indexed

Objectives

  • Rework database models to extend indexed data for Blocks, Transactions, and Messages
  • Extend models for Block and Transaction Message Events and Key/Value Attributes
  • Add configuration values for fine-grained control over event indexing

Milestone 3: Custom Block Event and Transaction Message Parser Interface

Summary

Milestone 3 enables users to index data in a custom format, allowing for better querying and organization. This caters to specific user needs, offering more flexibility compared to the generalized indexer in Milestone 2.

Goal

Implement generalized custom Block Event and Message parser interfaces for developer indexing extensions. Extend the indexer parsing loop for both Generalized Indexer implementations (from Milestone 1) and custom block event/message parser interfaces.

Introduction

When a Block event or Transaction message is encountered, the user of the indexer may want to index the data into a custom format for better querying/organization of the data. This milestone is intended to provide users the ability to implement custom parsers for their own particular use-cases.

Custom Parser Example

For example, say a user is interested in voting patterns and wants to index the MsgVote transaction message into a custom database table format.

This user would create a custom parser that executes when a MsgVote message is encountered. The custom parser would transform the message into the desired data format and insert it into their custom table. They would then be able to more easily query for voting patterns rather than relying on the generalized indexer dataset as described in Milestone 2.

Objectives

  1. Implement interface definitions for adding custom Block Event indexer parsers, handlers, and models
  2. Implement interface definitions for custom Transaction Message indexer parsers, handlers, and models
  3. Add pre-validation functionality
  4. Manage custom models with database handling functionality
  5. Include custom parsers and handlers for Block Event indexing
  6. Include custom parsers and handlers for Transaction Message indexing
  7. Index data returned from custom parsers and handlers
  8. Add error handling methods for ease-of-development/debugging for custom implementation errors
Clone this wiki locally