Open MaxMustermann2 opened 2 weeks ago
This update introduces changes across several modules and scripts. Key modifications include updating import paths to align with the new Exocore
structure, refining workflow configurations for better CI support, and enhancing epoch management functionalities. Additionally, new functionalities for initializing, querying, and managing epochs have been added, accompanied by corresponding test enhancements to ensure robust validation of these features.
File(s) | Change Summary |
---|---|
.github/workflows/proto.yml |
Added token configuration for GitHub Actions under buf-setup-action@v1.26.1 . |
.github/workflows/super-linter.yml |
Added conditional configurations for running with act . |
.semgrepignore |
Added exclusion pattern x/*/simulation/ . |
app/app.go |
Updated import paths for epochs package to ExocoreNetwork/exocore . |
local_node.sh |
Modified test parameters for epoch duration and unbonding in the dogfood module. |
proto/exocore/epochs/v1/genesis.proto |
Introduced EpochInfo and GenesisState messages defining epochs with metadata. |
proto/exocore/epochs/v1/query.proto |
Updated package name, endpoint URLs, field descriptions, and added pagination for epoch queries. |
testutil/utils.go |
Added InitTime field to BaseTestSuite , adjusted block parameters, and added functions for managing block commits. |
x/dogfood/keeper/impl_epochs_hooks.go , x/dogfood/types/expected_keepers.go , x/dogfood/types/... |
Updated import path for epochsTypes package. |
x/dogfood/keeper/keeper.go |
Modified Hooks function to check for nil before returning k.dogfoodHooks . |
x/epochs/README.md |
Documented AfterEpochEnd and BeforeEpochStart hooks, and provided EpochInfos and CurrentEpoch queries in the epochs module. |
x/epochs/client/cli/query.go |
Added CLI query commands for querying epoch information and the current epoch number. |
x/epochs/keeper/... |
Introduced and enhanced functionalities for initializing, querying, managing, and testing epochs. |
The changes made span across various modules and do not focus on a single feature or control flow modification. Thus, generating sequence diagrams is not applicable here.
In lines of code we dwell so deep,
Epochs wake from endless sleep.
Exocore’s network, grand and bright,
Guards the epochs in their flight.
Tokens set and queries shown,
Our code of legends, swiftly grown.
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Query the epoch information with two successive command exocored q epochs epoch-infos
, look into the minute
epoch information, the current_epoch increase by 1 while the time latency for two successive command is obivioulyless than one minute. and the current_epoch_start_time
in the minute identifier is incorrect.
NOTE: the genesis_time is "2024-06-14T08:34:18.95676475Z"
[root@testnet-exochain testscript]# exocored q epochs epoch-infos
epochs:
- current_epoch: "3"
current_epoch_start_height: "3"
current_epoch_start_time: "2024-06-16T08:34:18.956764750Z"
duration: 86400s
epoch_counting_started: true
identifier: day
start_time: "2024-06-14T08:34:18.956764750Z"
- current_epoch: "68"
current_epoch_start_height: "68"
current_epoch_start_time: "2024-06-17T03:34:18.956764750Z"
duration: 3600s
epoch_counting_started: true
identifier: hour
start_time: "2024-06-14T08:34:18.956764750Z"
- current_epoch: "423"
current_epoch_start_height: "423"
current_epoch_start_time: "2024-06-14T15:36:18.956764750Z"
duration: 60s
epoch_counting_started: true
identifier: minute
start_time: "2024-06-14T08:34:18.956764750Z"
- current_epoch: "1"
current_epoch_start_height: "1"
current_epoch_start_time: "2024-06-14T08:34:18.956764750Z"
duration: 604800s
epoch_counting_started: true
identifier: week
start_time: "2024-06-14T08:34:18.956764750Z"
pagination:
next_key: null
total: "4"
[root@testnet-exochain testscript]# exocored q epochs epoch-infos
epochs:
- current_epoch: "3"
current_epoch_start_height: "3"
current_epoch_start_time: "2024-06-16T08:34:18.956764750Z"
duration: 86400s
epoch_counting_started: true
identifier: day
start_time: "2024-06-14T08:34:18.956764750Z"
- current_epoch: "68"
current_epoch_start_height: "68"
current_epoch_start_time: "2024-06-17T03:34:18.956764750Z"
duration: 3600s
epoch_counting_started: true
identifier: hour
start_time: "2024-06-14T08:34:18.956764750Z"
- current_epoch: "424"
current_epoch_start_height: "424"
current_epoch_start_time: "2024-06-14T15:37:18.956764750Z"
duration: 60s
epoch_counting_started: true
identifier: minute
start_time: "2024-06-14T08:34:18.956764750Z"
- current_epoch: "1"
current_epoch_start_height: "1"
current_epoch_start_time: "2024-06-14T08:34:18.956764750Z"
duration: 604800s
epoch_counting_started: true
identifier: week
start_time: "2024-06-14T08:34:18.956764750Z"
pagination:
next_key: null
total: "4"
[root@testnet-exochain testscript]# date
Mon Jun 17 04:09:16 UTC 2024
[root@testnet-exochain testscript]# date
Mon Jun 17 04:09:18 UTC 2024
[root@testnet-exochain testscript]# date
Mon Jun 17 04:09:20 UTC 2024
NOTE: the genesis_time is "2024-06-14T08:34:18.95676475Z"
Given that is the case, this behavior is expected. It is the same functionality as the one implemented in the Cosmos SDK and the previously imported module.
The current epoch, given any identifier, indicates the number of periods of that epoch since the epoch counting start time (which defaults to the genesis time, if not set). For example, if the day epoch is reported as 3, it means that the 3rd day (since counting started) is ongoing.
However, the number is incremented only once during a block. This is an intentional design, since doing otherwise would result in epochs being skipped. This is the cause for the deviation that you observed.
Starting a chain with a genesis time in the past causes each produced block to increase the current epoch number by 1 until the epoch's scheduled end time (= current start time + duration) < block time.
In the provided example, the chain's genesis time was 2 days, 19 hours, 32 minutes and ~16 seconds ago. The start_time for each epoch is set to the genesis time.
Since the start_time, the 3rd day has started, which is accurately reflected in your query. Similarly, it is the 68th hour that is currently ongoing, which is also correctly reported. The week is the first week since the genesis time, which is again accurate.
The minute, however, is increasing by 1 at each block. 4052.3 minutes have completed between the genesis time and now, so it will increase till 4053 blocks (+ some extra for the time it takes for block production to get there) and then continue on its regular minute-wise schedule.
The comments in the code describe this detail as well. https://github.com/ExocoreNetwork/exocore/blob/91a9681fd5448474b76229e6ef3b7193107fcc32/proto/exocore/epochs/v1/genesis.proto#L33-L51
@coderabbitai review
[!NOTE] Currently processing new changes in this PR. This may take a few minutes, please wait...
Commits
Files that changed from the base of the PR and between 002d277d27b2d88d85853959d0382bef0bb4b9e3 and 53863434195b96fa51a2fb6f0ad7f000ff86b24a.Files ignored due to path filters (4)
* `SAFU.pdf` is excluded by `!**/*.pdf` * `x/epochs/types/genesis.pb.go` is excluded by `!**/*.pb.go` * `x/epochs/types/query.pb.go` is excluded by `!**/*.pb.go` * `x/epochs/types/query.pb.gw.go` is excluded by `!**/*.pb.gw.go`Files selected for processing (34)
* .github/workflows/proto.yml (2 hunks) * .github/workflows/super-linter.yml (1 hunks) * .semgrepignore (1 hunks) * app/app.go (1 hunks) * local_node.sh (1 hunks) * proto/exocore/epochs/v1/genesis.proto (1 hunks) * proto/exocore/epochs/v1/query.proto (2 hunks) * testutil/utils.go (4 hunks) * x/dogfood/keeper/impl_epochs_hooks.go (1 hunks) * x/dogfood/keeper/keeper.go (1 hunks) * x/dogfood/types/expected_keepers.go (1 hunks) * x/dogfood/types/params.go (2 hunks) * x/epochs/README.md (1 hunks) * x/epochs/client/cli/query.go (1 hunks) * x/epochs/keeper/abci.go (1 hunks) * x/epochs/keeper/abci_test.go (1 hunks) * x/epochs/keeper/epoch_infos.go (1 hunks) * x/epochs/keeper/epoch_infos_test.go (1 hunks) * x/epochs/keeper/genesis.go (1 hunks) * x/epochs/keeper/grpc_query.go (1 hunks) * x/epochs/keeper/grpc_query_test.go (1 hunks) * x/epochs/keeper/keeper.go (1 hunks) * x/epochs/keeper/setup_test.go (1 hunks) * x/epochs/keeper/utils_test.go (1 hunks) * x/epochs/module.go (1 hunks) * x/epochs/simulation/genesis.go (1 hunks) * x/epochs/types/codec.go (1 hunks) * x/epochs/types/errors.go (1 hunks) * x/epochs/types/events.go (1 hunks) * x/epochs/types/genesis.go (1 hunks) * x/epochs/types/genesis_test.go (1 hunks) * x/epochs/types/hooks.go (1 hunks) * x/epochs/types/identifier.go (1 hunks) * x/epochs/types/keys.go (1 hunks)_________________________________________________________________________________________________________________ < Estimate the order of your algorithms. Get a feel for how long things are likely to take before you write code. > ----------------------------------------------------------------------------------------------------------------- \ \ \ \ /\ ( ) .( o ).
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
This PR is a backport of the Cosmos SDK's epochs module. The backport allows us the flexibility to define our own epochs as default epochs and fixes a bug wherein the first epoch in the hook was always 2.
Summary by CodeRabbit
New Features
Bug Fixes
Chores
Documentation