​

Mini Block Production

Similar to traditional blockchain building, mini blocks are used to achieve 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 River Chain: This mini block header is then integrated into the river 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.