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

chore: collapse module spec and readme #13143

Merged
merged 20 commits into from
Sep 5, 2022
Merged
Show file tree
Hide file tree
Changes from 1 commit
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
Prev Previous commit
Next Next commit
epoching
  • Loading branch information
tac0turtle committed Sep 4, 2022
commit 64c9e23261dc1bd074a6bd95907da7b69b6fb335
91 changes: 88 additions & 3 deletions x/epoching/README.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,92 @@
<!--
order: 0
order: 8
title: Epoching Overview
parent:
title: "epoching"
-->

# Epoching
## `x/epoching`
julienrbrt marked this conversation as resolved.
Show resolved Hide resolved

* [Epoching](epoching/spec/README.md) - Allows modules to queue messages for execution at a certain block height.
## Abstract

The epoching module allows modules to queue messages for execution at a certain block height. Each module will have its own instance of the epoching module, this allows each module to have its own message queue and own duration for epochs.

## Example

In this example, we are creating an epochkeeper for a module that will be used by the module to queue messages to be executed at a later point in time.

```go
type Keeper struct {
storeKey sdk.StoreKey
cdc codec.BinaryMarshaler
epochKeeper epochkeeper.Keeper
}

// NewKeeper creates a new staking Keeper instance
func NewKeeper(cdc codec.BinaryMarshaler, key sdk.StoreKey) Keeper {
return Keeper{
storeKey: key,
cdc: cdc,
epochKeeper: epochkeeper.NewKeeper(cdc, key),
}
}
```

### Contents

* [State](#state)

# State

## Messages queue

Messages are queued to run at the end of each epoch. Queued messages have an epoch number and for each epoch number, the queues are iterated over and each message is executed.

### Message queues

Each module has one unique message queue that is specific to that module.

## Actions

A module will add a message that implements the `sdk.Msg` interface. These message will be executed at a later time (end of the next epoch).

```go
type Msg interface {
proto.Message

// Return the message type.
// Must be alphanumeric or empty.
Route() string

// Returns a human-readable string for the message, intended for utilization
// within tags
Type() string

// ValidateBasic does a simple validation check that
// doesn't require access to any other information.
ValidateBasic() error

// Get the canonical byte representation of the Msg.
GetSignBytes() []byte

// Signers returns the addrs of signers that must sign.
// CONTRACT: All signatures must be present to be valid.
// CONTRACT: Returns addrs in some deterministic order.
GetSigners() []AccAddress
}
```

## Buffered Messages Export / Import

For now, the `x/epoching` module is implemented to export all buffered messages without epoch numbers. When state is imported, buffered messages are stored on current epoch to run at the end of current epoch.

## Genesis Transactions

We execute epoch after execution of genesis transactions to see the changes instantly before node start.

## Execution on epochs

* Try executing the message for the epoch
* If success, make changes as it is
* If failure, try making revert extra actions done on handlers (e.g. EpochDelegationPool deposit)
* If revert fail, panic
58 changes: 0 additions & 58 deletions x/epoching/spec/01_state.md

This file was deleted.

44 changes: 0 additions & 44 deletions x/epoching/spec/03_to_improve.md

This file was deleted.

37 changes: 0 additions & 37 deletions x/epoching/spec/README.md

This file was deleted.