Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(aep-61): Akash Network store optimizations #4

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion INDEX.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,4 +59,5 @@
| [57](spec/aep-57) | Automatic Escrow Top Up | Draft | Standard/Interface | 2024-01-05 | | 2025-01-30 |
| [58](spec/aep-58) | Per Node Resources in Console | Draft | Standard/Interface | 2024-01-05 | | 2025-05-15 |
| [59](spec/aep-59) | Provider Notifications | Draft | Standard/Interface | 2024-01-05 | | 2025-03-15 |
| [60](spec/aep-60) | Akash at Home | Draft | Meta | 2024-12-01 | | 2026-03-30 |
| [60](spec/aep-60) | Akash at Home | Draft | Meta | 2024-12-01 | | 2026-03-30 |
| [61](spec/aep-61) | Akash network store optimizations | Draft | Standard/Core | 2025-01-30 | | 2025-02-28 |
1 change: 1 addition & 0 deletions ROADMAP.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,7 @@
| [56](spec/aep-56) | Unified Akash Integration API | 2025-02-15 | Major |
| [30](spec/aep-30) | Cosmos SDK v0.47 Migration | 2025-02-28 | Major |
| [33](spec/aep-33) | Escrow Balance Alerts in Akash Console | 2025-02-28 | Minor |
| [61](spec/aep-61) | Akash network store optimizations | 2025-02-28 | Major |
| [34](spec/aep-34) | Workload Log Forwarding via Akash Console | 2025-03-15 | Minor |
| [59](spec/aep-59) | Provider Notifications | 2025-03-15 | Minor |
| [35](spec/aep-35) | Realtime Pricing In Akash Console | 2025-03-30 | Minor |
Expand Down
12 changes: 12 additions & 0 deletions index.json
Original file line number Diff line number Diff line change
Expand Up @@ -715,6 +715,18 @@
"estimated-completion": "2026-03-30T00:00:00.000Z",
"roadmap": "major"
},
{
"aep": 61,
"title": "Akash network store optimizations",
"author": "Artur Troian (@troian)",
"status": "Draft",
"type": "Standard",
"category": "Core",
"created": "2025-01-30T00:00:00.000Z",
"updated": "2025-01-30T00:00:00.000Z",
"estimated-completion": "2025-02-28T00:00:00.000Z",
"roadmap": "major"
},
{
"aep": 7,
"title": "Incentivized Testnet 1: Akashian Challenge Phase 1",
Expand Down
88 changes: 88 additions & 0 deletions spec/aep-61/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
aep: 61
title: "Akash Network store optimizations"
author: Artur Troian (@troian)
status: Draft
type: Standard
category: Core
created: 2025-01-30
updated: 2025-01-30
estimated-completion: 2025-02-28
roadmap: major
---

## Motivation

Improve read performance of blockchain API by optimizing prefixes in x/stores based on object state.

## Summary

A lot of Akash Network API clients (e.g. Console and provider service) query blockchain to get specifics about certain leases, orders, etc.
Current implementation implies single unordered index per store, which create challenges for clients when they need to query items of specific state, for example active leases, or open orders.
At this moment, market store contains over 1.3M order records, and for provider service to catch up with them at startup it has to iterate over all of them to and filter out open orders. Specifying filters like state in the query is not effective, and in-fact reduces performance due to way store keys are built.

In majority of the cases API client is interested in objects that are in any state other than closed (i.e. active, open, paused, etc), therefore it is feasible to split single store into multiple stores, each of them will contain only objects of the certain state.

Certain stores (x/market, x/authz) will also benefit from reverse indexes to be added for improved reading performace. With x/market for example, adding reverse index for bids and leases will greatly improve queries when client is looking for bids/leases by provider.

## Implementation details

State of the object will be considered as part of the store prefix and will be prepended to the store key.
Such approach has following pros and cons:
- Pros:
- reduce number of items to iterate over when querying for objects of certain state
- retains pagination logic
- Cons:
- Finding specific object by id will be O(N), where N is number of states particular object can be in.
- Cost of certain transactions will likely increase due necessity of checking object via multiple prefixes

### x/deployment

**Deployments** store will be updated with following prefixes:
- {0x11, 0x00} - deployments
- {0x01} - active deployments
- {0x02} - closed deployments
- {0x12, 0x00} - deployment groups
- {0x01} - open deployment groups
- {0x02} - paused deployment groups
- {0x03} - deployment groups with insufficient funds
- {0x04} - closed deployment groups

### x/market

**Orders** store will be updated with following prefixes:
- {0x11, 0x00} - orders
- {0x01} - open orders
- {0x02} - active orders
- {0x03} - closed orders

**Bids** store will be updated with following prefixes:
- {0x12, 0x00} - bids
- {0x01} - open bids, normal order
- {0x02} - active bids, normal order
- {0x03} - lost bids
- {0x04} - closed bids
- {0x12, 0x01} - bids, with reverse index
- {0x01} - open bids, with provider address as first token of the key
- {0x02} - active bids, with provider address as first token of the key

**Leases** store will be updated with following prefixes:
- {0x13, 0x00} - leases
- {0x01} - active leases
- {0x02} - insufficient funds leases
- {0x03} - closed leases
- {0x13, 0x01} - leases, with reverse index
- {0x01} - active leases, with provider address as first token of the key

### x/authz

Store will update with following prefixes:
- {0x01} - grantor prefix (remains unchanged)
- {0x03} - grantee prefix. Format of the key is `0x03<granteeAddressLen (1 Byte)><granteeAddress_Bytes><granterAddressLen (1 Byte)><granterAddress_Bytes>: grants count`

**NOTE**: Index {0x02} is reserved to retain compatibility with future upgrade to Cosmos-SDK 0.47 upgrade. This upgrade introduces prefix `0x02` for `GrantsQueue`message.

## Copyright

All content herein is licensed under [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0).