By: Geeq  on Oct 15, 2019

In the coming months and years, there are going to be plenty of new developments to discuss with you, our growing community. To ensure it’s easy to find all the news in one handy article, we want to make sure you have transparent, periodic updates on what is happening in your favorite revolutionary blockchain ecosystem.

For our first update, we are pleased to report that we have completed the first stage of the foundation build.

Basic Node Client

A major part of the foundation build has been the basic node client. The basic node client is the element of the Geeq distributed consensus network which:

• Accepts user transactions on the blockchain.
• Communicates these transactions across the network between hubs and nodes.
• Validates the transactions according to the Geeq Proof-of-Honesty protocol.
• Commits the validated transactions into blocks and adds them to the chain of existing records which is made up of other completed transactions (ledger).

The Docker Test-bed

This is quite a technical element, but to put it simply, this is where multiple instances of the node client (mentioned above ?) are deployed in containers that run as independent validating nodes in the Geeqchain network. i.e. The docker test-bed is where the validators operate.

Logging Server

The logging server is the part of the blockchain that receives reports from each of the nodes. This allows the team to collect performance statistics such as transactions per second and resource utilization data like the bandwidth, computation and the storage requirements of the network.

What was learned during this period?

The team calls this the “foundation build” because this stage has allowed us to put in place the basic infrastructure elements that will support future builds.

The test-bed and logging server, for example, create a development environment that allows the team to optimize the code for the individual node clients, as well as the communications layer between them.

As we move forward, this foundation build allows us to test the platform in a few different scenarios. So we can work out how a Geeq network handles strenuous situations such as:

• Having a large or small number of nodes.
• Large fractions of dishonest or unresponsive nodes.
• The presence of other types of adversaries attempting to subvert the network.
• The effects of latency, partitioning, and message loss.

We also spent a considerable amount of time optimizing the formal structure of account records, transactions, messages, block, and other data elements in a ‘Protocol Buffer framework’.

We look forward to keeping you in the loop and up-to-date as often as our Geeqs can update us with milestones and progress.

Keep looking out for future updates and thanks for reading!