About HIPs

    GitHub Logo HIP-1238: Network Quiescence

    Author Lazar Petrović, Kelly Greco, Mark Blackman
    Working Group Richard Bair
    Requested By Hashgraph
    Discussions-To https://github.com/hiero-ledger/hiero-consensus-node/pull/20069
    Status Approved ⓘ
    Type Standards Track ⓘ
    Category Core ⓘ
    Created 2025-07-11
    Updated 2025-09-02

    Table of Contents

    Abstract

    The Quiescence feature introduces a mechanism to pause event creation in Hiero networks during periods of no transaction activity, optimizing resource usage in low-volume networks. By halting event generation when all user transactions have reached consensus and are in fully signed blocks, Quiescence minimizes network traffic, computational overhead, and long-term storage of event data and system transactions. This feature is particularly advantageous for private or low-traffic Hiero networks, reducing operational and reoccurring long term storage costs. Quiescence maintains compatibility with existing consensus mechanisms, ensuring no impact on network security, performance, or functionality. This HIP details the quiescence conditions, mechanisms for pausing and resuming event creation, and implementation considerations, including impacts on mirror nodes and SDKs. By prioritizing efficiency across the transaction lifecycle, Quiescence aligns with Hiero’s commitment to sustainable, efficient distributed ledger technology.

    Motivation

    Current Hiero mainnet specifications mandate continuous event creation and gossip, even in the absence of transaction activity, to maintain consensus and network state. While robust for consistent network traffic, this approach is inefficient for networks with periodic usage where prolonged periods without transactions are common.

    The constant generation of events and blocks in such scenarios produces unnecessary data resulting in increased bandwidth, CPU, and long-term storage usage. These inefficiencies lead to increased operational costs and unnecessary resource utilization, misaligning with the needs of lightweight or intermittently active networks.

    Rationale

    By enabling the network to pause event creation when all known transactions are part of a fully signed block, the Quiescence feature can greatly reduce the operating costs of a low volume networks. It thus provides a cost-effective mode of operation for Hiero networks with intermittent usage, with no impact on end users.

    User stories

    1. As a Hiero consensus node operator, I want the Hiero network to implement Quiescence, pausing event creation when no transactions are submitted, to minimize CPU, network, and memory usage during idle periods, so that I can reduce bandwidth, storage, and operational costs for my low-traffic Hiero network.
    2. As a Hiero consensus node operator, I want to enable or disable Quiescence via a configuration value, so that I can flexibly control resource optimization based on varying traffic patterns and operational requirements in my Hiero network.
    3. As a block node or mirror node operator, I want Quiescence to reduce the flow of unnecessary event data during idle times, so that I can optimize storage and processing resources on my node.
    4. As a network participant with scheduled transactions, I want a Hiero network to come out of Quiescence automatically before the target consensus timestamp, so that my scheduled transactions execute on time without manual intervention.
    5. As a network participant with non-scheduled transactions, I want a Hiero network to come out of Quiescence to process my non-scheduled transactions.

    Specification

    Requirements

    • When transactions stop being submitted to the network, the network should stop producing events in a timely manner. This will happen after the submitted transactions end up in a fully signed block or become stale.
    • The amount of time it takes the network to stop should be close to the network’s consensus latency (the time it takes for a submitted transaction to reach consensus).
    • When a transaction is submitted to a quiesced network, the network should start producing events, and this newly submitted transaction should become part of a fully signed block.
    • When an action (i.e. scheduled transactions, staking weight updates) needs to occur at a specific point in consensus time, the network shall break quiescence and produce events in order to reach that consensus time.
    • When a node is in a state of quiescence, it shall report a status reflecting the new state.

    Quiescence mechanisms

    The quiescence feature can be broken up as follows:

    • Detecting when to quiesce (quiescence conditions)
    • Quiescing
    • Breaking quiescence

    Quiescence conditions

    Rule 1: Unprocessed transactions

    In its simplest form, detecting when to quiesce is done by tracking non-processed transactions. A transaction’s lifecycle is as follows:

    • A transaction is submitted to the network
    • An event is created with the transaction
    • The event is gossiped to the network
    • More events build on top of it, until it reaches consensus or becomes stale (a stale transaction will never reach consensus)
    • Consensus transactions are handled and a block is produced
    • The block is signed by a majority of nodes, these signatures become part of events and are gossipped
    • Once a node collects enough signatures, a block is considered fully signed

    Event creation is needed for a transaction’s lifecycle to complete. A transaction will either end up in a fully signed block or become stale. Once all known transactions have completed their lifecycle, there is no need to create more events and the network can quiesce.

    Rule 2: Don’t track signature transactions

    A complication comes from block signature transactions. These transactions do not need to reach consensus. However, they do need to be gossiped. If we want a fully signed block with all transactions, we need to create events with these transactions and then gossip them. If we were to try to reach consensus on these signature transactions as well, we would produce another block that would again need signatures, this way the network would never quiesce. So the mechanism outlined in Rule 1, signature transactions should be ignored.

    Rule 3: Target consensus timestamp (TCT)

    Another reason to create events is to advance consensus time so that a specific consensus time is reached. There is functionality that relies on consensus time advancing such as freeze and scheduled transactions. Because these mechanisms rely on consensus time advancing, they won’t work if the network is quiesced. To solve this problem, nodes will keep track of what consensus time needs to be reached. These times will be called Target Consensus Timestamps (or TCTs). If the wall clock time is within a configurable duration (tctDuration) of the next TCT, the network should not quiesce, or will break quiescence if already quiesced.

    Quiescing

    Once all the conditions are met, we can quiesce. This is done by simply stopping event creation. The consensus module will stay in this state until one of the following conditions is met:

    • A transaction is submitted to the node that needs to be put into an event
    • A node sends us an event with transactions that need to reach consensus and become part of a fully signed block
    • wallClockTime + tctDuration is greater than the next target consensus timestamp (TCT)

    If either of these conditions is met, we will break quiescence.

    Breaking quiescence

    Breaking quiescence is simply starting event creation again. The complication comes from the tipset algorithm, which optimizes event creation that advances consensus. Creating an event that does not advance consensus is generally considered a bad thing. But if only one node receives a transaction from an end user, it might not be possible to create an event that advances consensus. This means that for quiescence, we need to introduce an exception.

    The proposal is that we can have events that do not follow the same rules in the tipset and other algorithms. These events will be used for breaking quiescence in situations like the one described above. An event used to break quiescence will be called a QB (Quiescence Breaker). A QB can have any other-parent, even if it does not advance consensus.

    Other conditions for breaking quiescence are that the wall-clock time is nearing the next TCT, or we have received an event with a user transaction. If this occurs, while the network is quiescing, the network should resume creating events regularly. There is no need to create a QB in this case, since the whole network should be resuming event creation.

    Impact on Mirror Node

    The only impact on Hiero Mirror node is that blocks will not flow constantly. If the network is quiesced, the mirror node will not receive blocks until the network breaks quiescence. The mirror node will need to distinguish between a failure and a quiesced network, since they can appear similar.

    Impact on Block Node

    Similar to the mirror node, the block node will not receive blocks while the network is quiesced.

    Impact on SDK

    No impacts on Heiro SDKs are expected.

    Backwards Compatibility

    There are no impacts to backwards compatibility.

    Security Implications

    There are no security implications of this HIP. The worst case scenario is that the network does not quiesce when it should, which leads to increased resource usage. This is not a security issue, but rather an efficiency issue.

    How to Teach This

    For network operators:

    Your Hiero network is optimized to reduce energy usage and emissions. One of the features that supports this optimization is called “quiescence” where the network pauses when there is no work to be done. You may be able, depending on your usage, to further reduce your energy usage by grouping transactions together to extend this quiescence period.

    Reference Implementation

    No reference implementation exists for this HIP at the moment.

    Rejected Ideas

    TCT alternative

    One of the rejected ideas was a substitute for Rule 3. Instead of keeping track of TCT, the idea was to submit a no-op transaction to the network at this time. The main benefit of this idea was that it would remove one of the rules for quiescence, simplifying it. However, this idea was rejected because of the following reasons:

    • It would require a new transaction type that would have no other effect than to advance consensus time.
    • Each node would have to submit this transaction, which would lead to a lot of unnecessary transactions being created.
    • If a node’s wall-clock is off, we would break quiescence at the wrong time, which would lead to unnecessary events being created.

    Consensus concern

    We considered having the consensus module keep track of all three quiescence conditions, but this was rejected because they are already concerns of the execution module. Pushing these concerns into the consensus module would create several new touchpoints between the two modules, which would complicate the design and muddle responsibilities.

    Open Issues

    • How will mirror nodes detect quiescence?

    References

    N/A

    Copyright/license

    This document is licensed under the Apache License, Version 2.0 — see LICENSE or https://www.apache.org/licenses/LICENSE-2.0.

    Citation

    Please cite this document as: