By: Geeq  on Jul 3, 2023

• Geeq Data v4.8 released
• Merkle root computation code complete for validation layer blocks (VLBs)
• Merkle proof generation code complete for validation layer blocks (VLBs)
• Work on a websocket API to surface the merkle proofs has begun

Geeq Data v4.8 released

In June, the dev team updated the community blockchain data environment, including the blockchain running v4.8 of the protocol and support for Geeq Data and its block explorer.

We invite all readers to test the apps and send suggestions and bug reports to the Service Desk. If you are new to Geeq and would like to know what problems blockchain-based attestation services solve, please read the Geeq Data FAQs.

V4.8 of the protocol includes the encryption upgrade and subsequent validation of the active nodes’ signed node block triple messages as they traverse the workflow in Geeq’s network communications.

The work we are most proud of this month is the work on Geeq’s proofs at the validation layer.

A blockchain system must deliver proofs in order to be credible. The proofs must be irrefutable for the blockchain to be reliable. The proofs must be timely for the services to be useful.

Finally, the proofs must be independently and easily verifiable by a non-technical user. If the proofs aren’t, then you might as well be asking the users to trust the system.

The implication of this is profound. At Geeq, a user may ignore any node that does not produce the correct proof. Users then have the security of knowing they only have to transact with nodes who are keeping a provably uncorrupted blockchain and ledger.

Geeq’s merkle proof methods apply to every Geeq chain, private or public, and regardless of the features included in the chain. For example, NFTs and fungible tokens are two different categories designated within groupType. Similarly, chainNum designates the correct chain in any multi-chain environment, whether it is private, public, or hybrid.

Specifications for Geeq Network Operations

Non-technical readers may wish to skip the rest of the update and go straight to this article: Proofs – An Essential Value Proposition of Blockchain.

The next two sections are for technical readers.

The following tables and guides are intended for those who understand the following statements:

Merkle Trees for Network Groups are constructed so that Nodes can attest to their own Chain State View and also to determine whether or not other nodes share the same view and have reached the same conclusions. Merkle Trees also allow Nodes to send Merkle Proofs of existence or state to Users.

Geeq’s Merkle Tree Schemas

Geeq’s design requirements for its merkle tree schemas are consistency and utility.

• Trees are constructed in layers with merkle roots of contained groups being Leaves 🍃 or End Points for the merkle trees of the containing groups.
• Sets of leaves 🍃 that form merkle trees must be ordered consistently. We will use the following conventions.
  1. If the leaves of a merkle tree are derived from groups that were created by nodes, then they will be ordered by the node numbers of the creators. This rule is used for Network Actor Records also.
  2. Validation and Application Layer Records are ordered by Identification Record Number (IRN), and all remaining sets of leaves are placed in hash or binary order.
• Merkle root position specifies the placement of the merkle hash input as an element in the local Merkle Tree for Network Groups. This is denoted: #Xy, which is interpreted as follows:
  # − The depth or level of the merkle hash.
  X − Whether the merkle hash is concatenated on the Left (L) or Right (R) for the next level merkle hash.
  y − Indicates the pair index of the merkle hash, that is, pairs of hashes that are concatenated, and then hashed, to find the next level hash in the merkle tree.
• The Merkle Path (merklePath) is encoded as a set of one byte data elements that indicate whether each merkle hash in a merkle proof should be concatenated to the Left (= 0) or Right (= 1).

The Merkle root computation and Merkle proof generation for validation layer blocks (VLB) are code complete.

Geeq June 2023 Technical Update

The schema for a Geeq Validation Layer Block (VLB) merkle tree is shown in Table 1 below.

Geeq’s Merkle Paths for Independent Verification

Table 2 shows the Merkle Path to valid and invalid transactions recorded in a Validation Layer Block (VLB). The merkle paths are entirely derived from the merkle tree schema defined in Table 1. They do not contain or require any new information.

The third column in Table 2 shows the elements of the blockchain that are produced for proofs, by protocol. These element names refer to the contents of Table 1. The question mark “?” represents the point where the path begins to depend on the size of the block which, in turn, determines how many layers of leaves 🍃 are in the merkle tree for that block.

If a user has exact data on a transaction, it is straightforward to dive quickly into the Merkle trees for valid transactions (green) or invalid transactions (orange) of any VLB of any Geeq chain. The same methods will be used to provide Merkle paths and proofs for data in the Validation Layer Ledger (VLL), Application Layer Blocks (ALB), and Application Layer Ledgers (ALL). Each of these, as well as chain hash proofs and proofs of network actor records, content statements, and parameters has its own well-defined schema.

Check out our glossary to learn the difference between blocks and ledgers. To see how Geeq provides secure validation for applications at scale, check out this explainer in our video resources page.

The Importance of Proofs : The Geeq Difference

We can’t emphasize enough the significance of Geeq’s proofs. Many other blockchain protocols have tremendous difficulty constructing credible and timely proofs to prove the integrity of their chain data.

Confidence in any blockchain’s validation methods and on-chain data is required for those chain data to be used as the basis for any scaling method, interoperability between chains, or smart contract. If proofs are subject to error, manipulation, or changes in protocol, users take on the risk and must trust the projects rather than being able to verify the results for themselves.

The diversity of methods in the rest of the blockchain space imposes an immense cognitive load for users and developers alike, posing significant barriers to adoption.

In stark contrast, the structures and proof methods built into Geeq’s protocol are consistent and immediately useful. While it was more work upfront, the clarity and standard frameworks for the calculation of merkle roots and merkle proofs are settled and will be carried forward for every transaction type validated by Geeq.

Furthermore, Geeq’s merkle proofs are calculated for each transaction that is validated, whether the final determination is valid or invalid. All transactions that are validated are included.

Having a complete set of data validated on-chain at Geeq provides a new level of accountability for models and business practices that may wish to select a partial set, such as a specific training set for AI or a subset of scraped data. The merkle proofs available at Geeq will be easily used for vendors and businesses to provide independent and unbiased verification of their ethical practices regarding any of their data.

Summary

This month’s achievement demonstrated the feasibility of Geeq’s method of proofs for validation layer blocks. Geeq’s standard merkle trees and merkle proofs were implemented, as well as a novel way to encode a merkle path all the way to the transaction level in any node’s block.

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

– The Geeq Team

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.