-
Notifications
You must be signed in to change notification settings - Fork 19
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Messages v2 included migration (#1738)
# Goal The goal of this PR is to propose and implement messages v2 compatible with PoV Closes #198 # Discussion - Refactored Messages to minimize used PoV - Added storage migration (single block) # Migration Details - Based on data used in rococo and main-net and calculations we don't need to do a multi-block migration. (only around 15%) of the block is being used. - Was not able to test with upgrading on local due to getting errors when running relay nodes - Was able to successfully run try-run-time cli tool against rococo # Checklist - [x] Chain spec updated - [x] Design doc(s) updated - [x] Tests added - [x] Benchmarks added - [x] Weights updated
- Loading branch information
Showing
17 changed files
with
407 additions
and
242 deletions.
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
# On Chain Message Storage | ||
|
||
## Context and Scope | ||
The proposed feature consists of changes that is going to be one (or more) pallet(s) in runtime of a | ||
Substrate based blockchain, and it will be used in all environments including production. | ||
|
||
## Problem Statement | ||
After introduction of **Proof of Validity** or **PoV** in runtime weights, all pallets should be | ||
re-evaluated and refactored if necessary to minimize the usage of **PoV**. This is to ensure all | ||
important operations are scalable. | ||
This document tries to propose some changes on **Messages** pallet to optimize the **PoV** size. | ||
|
||
## Goals | ||
- Minimizing Weights including **execution times** and **PoV** size. | ||
|
||
## Proposal | ||
Storing messages on chain using **BlockNumber** and **SchemaId** and **MessageIndex** as main and secondary | ||
and tertiary keys using [StorageNMap](https://paritytech.github.io/substrate/master/frame_support/storage/trait.StorageNMap.html) data structure provided in Substrate. | ||
|
||
### Main Storage types | ||
- **MessagesV2** | ||
- _Type_: `StorageNMap<(BlockNumber, SchemaId, MessageIndex), Message>` | ||
- _Purpose_: Main structure To store all messages for a certain block number and schema id and | ||
index | ||
|
||
|
||
### On Chain Structure | ||
Following is a proposed data structure for storing a Message on chain. | ||
```rust | ||
/// only `index` is removed from old structure | ||
pub struct Message<AccountId> { | ||
pub payload: Vec<u8>, // Serialized data in a user-defined schemas format | ||
pub provider_key: AccountId, // Signature of the signer | ||
pub msa_id: u64, // Message source account id (the original source of the message) | ||
} | ||
``` | ||
## Description | ||
|
||
The idea is to use existing **whitelisted** storage with `BlockMessageIndex` type to store and get | ||
the index of each message to be able to use it as our third key for `StorageNMap`. | ||
|
||
We would store each message separately into `StorageNMap` with following keys | ||
- primary key would be `block_number` | ||
- secondary key would be `schema_id` | ||
- tertiary key would be the `index` of the message for current block which starts from 0 | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.