By: Geeq  on Jun 5, 2023

In May, the dev team focused on stabilizing v4.8 of the Geeq protocol and continued working on v5.1 in parallel. This month’s update highlights Geeq’s Network Communications. Milestones were completed in the following categories:

Application Payloads
Network and Systems Operations

The rest of this update will describe the flow of network messages required for validation. This workflow is code complete.

Geeq Network Communications

For simplicity, the schematic below shows an active network with only three nodes: Node 1, Node 2, and the Relay. In reality, the size of the active network may vary. Message structures are defined for each network actor’s role. The hub role is rotated each block. In general, we refer to refer to Node_i where i = {1, 2, … N} and N is the number of nodes in the active network.

Let’s follow the network communications to build the next block B, where users send a transaction with a data payload, such as they would if they use Geeq Data.

Simplified Network Diagram

Explanation of Message Elements and Communications Pathway

User to Node_i [1]:
From the app or dashboard, a user selects an honest active node, such as Node 1 or Node 2. The app formats the user’s data. Finally, the user signs the transaction with their private key, and sends the transaction.

Node_i to Hub [2]:
As Nodes 1 and 2 receive transactions, called unverified user transactions (UUTs), each node sees only the UUTs it has received itself. Each node checks the set of UUT_i for sanity and runs single validation checks. An example of a non-sane transaction is a transaction that is not targeted to the chain supported by this network of nodes.

If an unverified user transaction (UUT) fails these checks, it is considered non-sane and discarded. An honest node will not forward a non-sane transaction.

Next, Nodes 1 and 2 individually format a message containing its Node Block Triple (NBT_i), defined below and shown in the diagram above.

1. Node Content Statement (NCS_i):
   The NCS_i includes node_i’s chain state view at block height (B-1) and the merkle roots of the two lists (the NTL_i and NPL_i) it is submitting for consideration for block B. The node is held accountable for its chain state view and the merkle roots by signing its NCS_i with its private key.
2. Node Transaction List (NTL_i):
   The NTL_i includes the count of UUTs in its list and its list of sane UUTs. These may or may not carry a data payload, depending on its transaction type. An Unverified Validation Transaction (UVT) does not carry a data payload. An Unverified Application Transaction (UAT) does.
3. Node Payload List (NPL_i):
   The NPL_i includes the count of payloads and its list of payloads that are hash referenced in the Unverified Application Transactions (UATs) it has received.
   

Each Node_i sends its Node Block Triple (NBT) to the node acting as the Hub for block B. No further validation checks are done by Node_i until it receives the entire list of candidate transactions for Block B. Notice Geeq’s applications use standard transaction logic and do not require smart contracts.

The purpose of the content statement is to put each network actor on record with an irrevocable statement of what it views as the current chain state view.

Geeq Transaction Logic

Hub to Relay [3]:
The hub does not validate any transactions at this time. Its sole responsibility as a hub is to check that only the correct nodes have submitted statements and the statements are signed correctly. It checks whether Node_i is in the active network for this block B and the message is signed with the correct key for Node_i.

A node that is not in the active network may try to submit a Node Block List. The hub ignores these.

The hub collects all the content statements from nodes that pass these checks. It then generates a Hub Content Statement (HCS) which it signs with its private key and sends to the relay.

Hub Content Statement (HCS):
The HCS includes the hub’s own chain state view at block height (B-1), a count of the NCS_is it is including, and the NCS_is for the active nodes that have signed their statements correctly.

By signing the Hub Content Statement, the hub has gone on record to attest the information the hub is including are from nodes in the active network and each Node_i has signed its NCS_i properly.

The Hub’s Content Statement includes the merkle roots for every node’s list of candidate transactions, including its own.

Relay to Node_i [4]:
The relay’s only job is to check whether the HCS is signed by the correct hub in the active network for block B, the message is intended for block B, and the message is signed by the correct key for the hub.

The Relay exists to prevent an indefinite stall.

Geeq Transaction Logic

If the Relay receives a correctly signed message from the correct hub for block B, it includes the HCS in its signed Relay Content Statement (RCS) and sends it to nodes in the Active Network and to Listening Nodes.

If the Relay does not receive a correctly signed message from the correct Hub for block B within the designated time period, it generates a RCS without including a HCS for block B. Nodes are then required by protocol to write an empty block.

Each node validates the collected lists of candidate transactions and builds its block [5]

The nodes see the signed content statements and collect the lists of candidate transactions. They are able to validate all the candidate transactions with sanity, single validation, and joint validation checks.

An example of a joint validation check failure occurs if a user tried to double spend by sending separate transactions to Node 1 and Node 2. In the first phase, the transaction each node receives from the user passes the sanity and single validation check. It is only when both transactions are included in the collected list that these transactions fail a joint validation test.

To be Valid, Transactions must satisfy a series of conditions, all stated as Indicator Functions where the output is in a true or false state.

Geeq Transaction Logic

Each node validates the set of transactions and adds to its blockchain. In practice, it builds a Validation Layer Block B and an Application Layer Block B. Then it updates its Validation Layer Ledger and Application Layer Ledger. Both valid and invalid transactions are recorded for reference.

Summary

Geeq is a multi-chain, no smart contracts, Layer 0 platform. Each chain is validated by its own network of nodes and the communications pathways are built into the protocol. By standardizing transactions, separating data payloads into application layer blocks, coding requirements for signed statements by every network actor and checks for each network actor’s status, Geeq’s protocol replicates easily to ensure data integrity for every blockchain.

We hope you enjoyed reading and, as always, thank you for your support!

– The Geeq Team