hiero-ledger / hiero-ledger/hiero-consensus-node
Quiescence feature
- Dominant language
- Java
- Stars
- 406
- Forks
- 226
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 210
Description
### Problem
If there are no transactions, there is no need to create events or gossip. This is only useful if the network does not have constant traffic.
### Solution
Stop event creation and gossip if there are no transactions that need to reach consensus. Since this feature has been previously implemented, here are some lessons learned from the previous implementation.
- To track the transactions that need to reach consensus, the simplest way is to have a counter that increases as events with transactions are received, and decrease the counter if events reach consensus or become stale.
- State signature transactions should be handled differently. Since there will always be signature transactions, not all of them will need to reach consensus. We only need to send out the signatures for the state that has all modifications.
- Since freeze is based on consensus time, quiescence has to stop as the wall clock time approaches the freeze time, otherwise the freeze will not work.
- If there are transactions waiting to be put into an event, quiescence should be broken. If there are any rules that prevent the creation of events, these might need to be broken in order to break quiescence. A typical example is the "do not reuse other-parents" rule. If only 1 node has transactions waiting, and it has used up all other-parents, it will need to break this rule. Otherwise the transaction waiting will have to wait for other nodes to create events first.
### Alternatives
_No response_
Contributor guide
Research direction
No files, tests, or entry points are named. Start by tracing event creation, gossip, transaction consensus tracking, and freeze-time handling. Define how pending transactions and state signature transactions affect quiescence, including when quiescence must be broken; done means validating these behaviors across the consensus lifecycle.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100