BlockX Documentation
  • Introduction
    • BlockX
    • Tokens
    • Transactions
    • Inflation
    • Keys
      • Keyring
      • Multisig
    • Gas Fees
    • Wallet and Accounts
      • Adding BlockX to Metamask
      • Adding BlockX to Keplr
      • Transfers Between Wallets
      • Backup
    • Deploying Smart Contracts
      • Remix
      • Hardhat
  • BlockX White Paper
  • The BCX Token
  • Governance
    • Proposals
      • Proposal Tips
      • Submit a Proposal
    • Community Pool
    • Chain Parameters
  • Technical Concepts
    • Architecture
    • Accounts
    • Chain ID
    • Encoding
    • Pending State
  • dApp Developers
    • Establishing Connections
    • BlockX Clients
    • Guides
      • Wallet Integration
      • Smart Contract Incentive Registration
      • Tracing Transactions
      • Query Balances
    • Localnet
      • Single-node
      • Multi-node
    • Testnet
      • Testnet Commands
    • Ethereum JSON-RPC
      • JSON-RPC Server
      • Running the Server
      • Namespaces
      • JSON-RPC Methods
      • Events
    • Tendermint RPC
  • Protocol Developers
    • Modules
      • auth
        • Concepts
        • State
        • AnteHandlers
        • Keepers
        • Vesting
        • Parameters
        • Client Auth
      • bank
        • State
        • Keepers
        • Messages
        • Events
        • Parameters
        • Client
      • crisis
        • State
        • Messages
        • Events
        • Parameters
        • Client
      • distribution
        • Concepts
        • State
        • Begin Block
        • Messages
        • Hooks
        • Events
        • Parameters
        • Client
      • epochs
        • Concepts
        • State
        • Events
        • Keepers
        • Hooks
        • Queries
        • Future Improvements
      • erc20
        • Concepts
        • State
        • State Transitions
        • Transactions
        • Hooks
        • Events
        • Parameters
        • Clients
      • evidence
        • Concepts
        • State
        • Messages
        • Events
        • Parameters
        • BeginBlock
        • Client
      • evm
        • Concepts
        • State
        • State Transitions
        • Transactions
        • ABCI
        • Hooks
        • Events
        • Parameters
        • Client
      • feemarket
        • Concepts
        • State
        • Begin block
        • End block
        • AnteHandlers
        • Keeper
        • Events
        • Client
        • Future Improvements
        • Parameters
      • feesplit
        • Concepts
        • State
        • State Transitions
        • Transactions
        • Hooks
        • Events
        • Parameters
        • Clients
        • Future Improvements
      • gov
        • Concepts
        • State
        • Messages
        • Events
        • Future Improvements
        • Parameters
        • Client
      • incentives
        • Concepts
        • State
        • State Transitions
        • Transactions
        • Hooks
        • Events
        • Parameters
        • Clients
      • ibc-core
      • inflation
        • Concepts
        • State
        • Hooks
        • Events
        • Parameters
        • Clients
      • slashing
        • Concepts
        • State
        • Messages
        • BeginBlock
        • Hooks
        • Events
        • Staking Tombstone
        • Parameters
        • CLI
      • staking
        • State
        • State Transitions
        • Messages
        • Begin-Block
        • End-Block
        • Hooks
        • Events
        • Parameters
        • Client
      • upgrade
        • Concepts
        • State
        • Events
        • Client
        • Resources
      • vesting
        • Concepts
        • State
        • State Transitions
        • Transactions
        • AnteHandlers
        • Events
        • Clients
    • Module Accounts
    • IBC Channels
    • Ethermint API
  • Validators
    • Quick Start
    • Telemetry
    • Security
      • Tendermint KMS
      • Tendermint KMS + Ledger
      • Validator Security Checklist
      • Validator Backup
    • Snapshots, Archive Nodes
    • FAQ
  • Delegators
    • Staking Process
  • Tokenomics
  • Block Explorers
Powered by GitBook
On this page
  • Correct Usage
  • Block-Time Drifts
  1. Protocol Developers
  2. Modules
  3. epochs

Future Improvements

Correct Usage

In the current design, each epoch should be at least two blocks, as the start block should be different from the endblock. Because of this, the time allocated to each epoch will be max(block_time x 2, epoch_duration). For example: if the epoch_duration is set to 1s, and block_time is 5s, actual epoch time should be 10s.

It is recommended to configure epoch_duration to be more than two times the block_time, to use this module correctly. If there is a mismatch between the epoch_duration and the actual epoch time, as in the example above, then module logic could become invalid.

Block-Time Drifts

This implementation of the x/epochs module has block-time drifts based on the value of block_time. For example: if we have an epoch of 100 units that ends at t=100, and we have a block at t=97 and a block at t=104 and t=110, this epoch ends at t=104, and the new epoch will start at t=110.

There are time drifts here, varying about 1-2 blocks time, which will slow down epochs.

PreviousQueriesNexterc20

Last updated 2 years ago