Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.towns.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Mini Block Production

Similar to traditional blockchain building, mini blocks are used to ensure data integrity and achieve consensus for the ordering of valid events in a given stream. The following is a detailed description of each step in the process:
  1. Election of Responsible Node: A responsible node is elected to construct the mini block. This election is based on the block number and incorporates an element of randomness, utilizing randdao.
  2. Initiation of Voting Process: The elected leader initiates a voting process. In this stage, each participating node contributes by sending hashes of the events present in their mini-pool.
  3. Combination of Votes: The leader combines these votes and selects events that are present in the majority of the mini-pools.
  4. Authority of the Leader: The leader has the discretion to determine the order of events within the mini block.
  5. Formation of Mini Block: The events chosen are then combined to form the mini block.
  6. Mini Block Header Creation: A header for the mini block is generated and subsequently signed by the responsible node.
  7. Integration into Towns Chain: This mini block header is then integrated into the Towns chain and disseminated to all participating nodes.
  8. Request for Missing Events: If a node does not possess all the events in the newly received mini block, it must proactively request these missing events from other participating nodes.
  9. Local Storage Update: Participating nodes update their local storage to reflect the new mini block. They also remove old mini-pools that were included in that mini block.
  10. Formation of New Mini-Pool: Events not included in the current mini block form the basis of a new mini-pool for the next generation.
  11. Event Effectuation at Block Boundaries: Certain events, such as joins and leaves, are only effectuated at block boundaries. This is to maintain consistent ordering across the network.
This procedure ensures a transparent and efficient process for mini block production, critical to the stability and reliability of the protocol.

​
Active Minipool Reconciliation

The system is designed to actively propagate events across stream nodes. Once a valid event reaches a majority of nodes, it is virtually guaranteed to end up in the block. Therefore, during an StreamService.AddEvent operation, the event is actively forwarded to other stream nodes. If a stream node notices that it lacks an event referenced in a NodeToNode.NewEventInPool message, it proactively attempts to fetch it from the node that sent this message. A node actively fetches missing events if one of the following conditions occurs: The hash of an event is received through the NodeToNode.NewEventInPool RPC, but the NodeToNode.NewEventReceived RPC for the same hash is not received after a short delay. A miniblock header is received that contains hashes of events missing from the local minipool. Once such an event is fetched from the node containing it, the NodeToNode.NewEventReceived server-side workflow is executed.