Consensus

Each HotPocket node collects specific kinds of information to be subjected to consensus. These pieces of information are used to compare and contrast themselves with the same types of information heard from other nodes in the cluster. Primarily, HotPocket subjects the following information for consensus: users, user inputs, user outputs and state. Using a fingerprinting mechanism (hashing) for efficiency, the information is checked to verify whether most of the nodes are in “agreement” with each other about observed information. After checking which node is agreeing with what, each node independently arrives at a conclusion of what would be considered as the final view of the cluster. This decision is made according to a predetermined “consensus” algorithm. This process happens according to a pre-configured time schedule (usually every few seconds) which is called a consensus “round”.

Ideally, at every consensus round, a HotPocket node should be able to arrive at a fair conclusion that has the majority agreement of other nodes in the cluster. In such a case, HotPocket creates a “ledger” containing the final conclusion it arrives at. It then invokes the DApp to act on the information which was subjected to consensus.

If HotPocket could not reach a consensus agreement at the end of a round, it would simply give up and start the next round without creating a ledger or invoking the DApp.

UNL - Unique Node List

Each HotPocket node maintains a list of other nodes that it trusts. This is called the Unique Node List (UNL) and it is required for consensus, where the process is carried out only among trusted nodes on this list. A trusted node is identified by its ed22519 public key which is presented and cryptographically verified at the time of establishment of a connection between the two nodes. If the public key of a connected node is among the UNL, HotPocket chooses to consider the information presented by the other node in its consensus checks.

LCL - Last Closed Ledger

At the end of each consensus round (once consensus is reached and before DApp execution is started), HotPocket creates a ledger. Every ledger has a hash which includes the previous ledger hash and the current data hash. Together, this builds the chain where every ledger hash is based on the previous ledger hash. Furthermore, the ledger includes the state hash, user hash, user input/output hashes, etc. Every ledger has a sequence number that increments upon ledger creation.

Consensus round

The following depicts a simplified overview of what happens during an arbitrary consensus round N.

  1. The job of consensus round N is to finalize the “consensed” data based on “local” data. Local data are the things that were captured on a single HotPocket node.

  2. The local data for round N consists of:

    • New user inputs recently submitted by users to this node.

    • User outputs generated by contract execution from round N-1.

    • Filesystem state hash from round N-1.

  3. Consensus round N will then circulate the above data between UNL nodes and arrive at a consensus conclusion. Nearing the end of round N, we have “consensed” data.

  4. At this point, HotPocket creates a ledger that contains consensed data hashes. So it includes:

    • Hashes of consensed user inputs for round N

    • Hashes of consensed user outputs from round N-1

    • Filesystem state hash from round N-1

  5. After ledger creation, HotPocket communicates to users.

    • For consensed user inputs, we send back a status update to relevant users that their inputs made it to the ledger.

    • Consensed user outputs from round N-1 will be sent to relevant users.

  6. Then the DApp is executed.

    • Filesystem represents the consensed state that’s in the last closed ledger (the state from round N-1).

    • User inputs that are fed into the contract are the ones that are in the last closed ledger (user inputs from round N).

  7. After the contract exits, the generated “local” user outputs are collected for the use of round N+1. Then we move on to round N+1 and repeat the process.

Privacy

Consensus can work in public or private modes. In public mode, all consensus messages exchanged between UNL nodes are also received by any other connected nodes as well. In private mode, the consensus messages are restricted to UNL nodes only.