Category: Updates

For those who are just tuning in to our updates (better late than never!), the team has finished with the Research and Discovery phase and has bravely stepped into the Proof of Concept phase. 

The key aim of this phase is to make a workable PoSv2 blockchain prototype which is, as you might expect, no easy task.

Now let’s check out what they’ve done so far.

Getting down to the nitty-gritty

Since the onset of this phase, they’ve worked on the first iteration of the blockchain software from scratch while sticking to a straightforward peer-to-peer network paradigm.

After some time, the team realized something: they’ve discovered that some requirements need to be additionally specified in the PoSv2 (Proof of Stake version 2) analysis, and more descriptions added to clarify the specifications.

This wasn’t a blocker for the team, as they’ve made significant progress in the preliminary work leading up to the creation of the first blockchain prototype. 

The major components were designed and implemented — e.g., Network, Mempool, Wallet, Storage, Blocks, Accounts, and the first part of the Consensus engine.

If you consider yourself a crypto connoisseur and you are curious about the development details, here’s a list of functionalities that were realized.

Network

So, what was done regarding the network?

The team worked on:

• Adding data serialization and deserialization (bincode);
• Posting a message (gossip), sending a message, receiving a message, etc.;
• Introducing bootstrap node;
• Introducing channels for connecting various software modules, for example, communication and data exchange between mempool and network threads;
• Adding a request/response functionality to the network manager;
• Network enhancement.

For those who are interested in going even further in-depth, here are some additional explanations. Introducing bootstrap nodes means allowing them to exchange routing tables of already connected nodes to the new node, accelerating the process of nodes discovering themselves. Regarding the request/response functionality, it is utilized for block synchronization and, in some situations, consensus because it allows nodes to request data from one other and get responses. As for the work done on network enhancement, it consisted of reducing the need for bootstrap nodes in the local network by enabling mDNS discovery for nodes in the local network (for testing and development purposes).

Mempool

Let’s start by defining a mempool (memory + pool) — it’s a mechanism for storing information on unconfirmed transactions. Basically, it’s a waiting room for transactions that have not yet been included in a block.

Regarding this component, the team boasts enabling fundamental functions like add, remove, prune, etc., and storing data to each node. They also worked on establishing channels for module communication (network – mempool connection), and they added transaction verification which is a checking process that the signature is valid and the sent amount is available in the account balance.

Wallet

How are things going with the wallet?

For the purpose of creating a cryptographic key pair, the wallet generates a mnemonic phrase and a cryptographic seed. A private key is used to sign a transaction, while the public key checks the transaction’s signature. The block producer signs a block using the private key, and the verification of the block signature is done by using a public key. 

All is well on the wallet side! 

Storage

In terms of storage, here are some strategic decisions that the team made:

• Using RocksDB to implement a storage system;
• Dividing data into columns to improve the database read and write process;
• Adding a mechanism to serialize and insert a single value into the database;
• Adding a method for reading data from a database and deserializing a single value;
• Including a technique for iterating through key/value pairs from the database while sorting them.

Blocks

What work was done on the blocks?

• Implementation of block structures with transaction headers carrying information on the block itself, such as the previous block hash, transaction headers’ hashes (Merkle roots), the block’s current height, the block proposer’s signature, etc.;
• Publishing newly created blocks to other peers in the network;
• Verifying block validity (verifying block header data);
• Genesis block creation – initializing the state of new nodes in the network;
• Storing of valid blocks into the database;
• Node synchronization implementation.

In order to join and take part in the consensus, a new node must first build a genesis block from its local configuration and then download and update any existing network blocks (become a validator of newly proposed blocks). 

For those who are baffled by all the terminology, “genesis block” is the first block recorded on a blockchain. 

Account

Now, we come to one of the parts most significant to most users — their account. 

The team created their test accounts, and for now, they’ve added account balances to enable sending transactions. Balances were added through the completion of the Genesis block. Things are looking good! 

Consensus (first part)

As mentioned, the team got down to the first part of the consensus engine as well. This includes:

• Initiator of the block proposer (manual for now);
• Requesting the committee a vote in favor of the block;
• Verifying inbound voting requests;
• The transmitted block is validated;
• Voting in favor of the block in response to the request vote;
• Responding only to the leader.

The next steps

As the project moves forward, it naturally increases in complexity, so the code base is updated constantly. But this is day-to-day stuff for our team. They’ve told us that in the coming weeks, the implementation of the Consensus model will take precedence. 

The report for this period concludes here but don’t worry, the team continues at full speed – until next time!

How persistent is our team from 0 to “I broke my hand, but I’m performing as if nothing happened”?

It’s not difficult to guess, it’s the latter. Yes, one of our team members has had a mishap, but that hasn’t slowed him down one bit.

So, let’s see where’s our team currently at. 

Rapid Risk Assessment

Although it resembles a tongue twister, RRA is more of a mind twister.

The team decided working on Rapid Risk Assessment is a necessity. Why? Because evaluating risks that could impact the protocol is an essential part of pre-development work.

So, this previous month the team labored over the analysis of risks associated with data stored and processed by GRN Grid to understand the impact of that data on the GRN Grid’s service.

What components of this service they paid special attention to? 

1. Wallet application 
2. Bootstrap nodes
3. Network Nodes

Wallet application 

Critical data of this component are the apps’ key pair and bootstrap node information that tells the wallet how to access the network as the wallet application interacts with the network.

Bootstrap nodes 

Critical data of this component are its key pair and the database of peers in the network, which is public, but its integrity is critical. These nodes are in charge of network p2p (peer-to-peer) exchange and represent a root for the discovery of other GRN Nodes: Clients and Validators.

Network Nodes (Blockchain nodes) 

Critical data associated with network nodes are again the peer database and validator selection algorithm, which must be unpredictable and fair. Speaking of network nodes, they can have two roles:

• Client node — provides a read-only functionality to the network, similar to ETH light nodes
• Validators — Clients can be Validator nodes if they have staked GRN (Running PoS algorithm) and need to run a “virtual machine” to run smart contracts

The team was very thorough: various attack scenarios were described and numerous security recommendations for all three components of the service.

Getting started with PoC

After this, they took their first official steps in the Proof of Concept phase.

These initial efforts were aimed at the construction of peer-to-peer networking, and the team decided to implement specific protocols. 

Concerning this stage of development, the work on the network layer is complete, although it may need to be modified in the future. Nodes now successfully discover other peers both from local networks or by connecting to boot nodes and exchanging routing tables between themselves.

The team is proud to say that the exchange of basic messages was accomplished, and the messages were disseminated throughout the network.

What’s next?

In the next weeks of the development of the Proof of Concept phase, the team plans to focus on developing the mempool, implementing serialization and deserialization of messages sent across the p2p network, developing a peer manager to handle communication on the system level, and block generation. We’ve got a busy period ahead! 

Watch this space for the next update.

It’s time for another project update!

Apart from an occasional sigh, the office was super quiet this previous month. That is until it’s time for the daily meetings. 

This is when things get heated up as every team member argues their standpoint to show why their solution is the optimal one. But every lively discussion ends with a consensus, which is what teamwork is all about.

But where exactly is our team at this point?

Wrapping up the first phase

As announced in our previous update, the team has just concluded the research and discovery phase, i.e., the first phase of the project.

During the previous month, the team was busy researching blockchain architecture and different components such as 

• data structure
• Genesis block mining, structure and definition
• peer-to-peer network
• communication, transactions, file handling and storage
• validation and verification processes
• incentives, stakes and consensus algorithm
• security

All of these elements were researched in general, but the team also took a deep dive from the perspective of the previously mentioned blockchains: Avalanche, Solana, PeerCoin, NEAR, and Stealth.

Setting a firm basis is only possible if one makes informed decisions. Naturally, to be able to make them in the first place, you need extensive research and analysis. For all of you interested to learn more about this painstaking process, let’s take a closer look at the building blocks.  

Bit by bit, byte by byte

Data structure 

Nailing the data structure is essential as it represents the foundation of the blockchain architecture. It’s a specialized format for organizing, processing, retrieving, and storing data; to be more specific, with blockchain technology, it represents a list of blocks of transactions. The team, of course, has a basic notion of what each node, transaction, message, etc., will contain, but the specifics are yet to be determined.

Peer-to-peer

Peer-to-peer network is a structure in which there is no “main” node — all of the peers (a.k.a. nodes) are equal, which makes it decentralized. This is very important in terms of security because storing all data in one place means you are leaving it vulnerable to hacking and manipulation, which in turn compromises the integrity of the data. This makes it a top priority component for the team. 

Communication, transactions, file handling, and storage

Blockchain combine peer-to-peer data-sharing technology with public key cryptography and what the team is striving to test now is communication, transactions, file handling, and storage. Besides discussing it in theory and making comparisons between the solutions different blockchains use, the team is also approaching this hands-on. 

They are running virtual machines locally to create a simple network of, let’s say, three nodes. With this small-scale blockchain “concept”, they intend to exchange messages and store and send certain information. This “test” provides the team with ample opportunity to put all their problem-solving skills to practice. They will create a model of their network and design all components. 

A step closer

One of the definite decisions the team has made so far is which database they will use. They work round the clock to determine the processes of adding and reading the data to the database and the node. 

Whenever data, storage, and block building are mentioned, there’s always one fear looming in the back of everyone’s mind — what if the data is incorrect or the node is malicious? And this problem leads us to data validation and verification processes, which are components of major importance. 

In the meantime, the PoS2 model is all set for them to implement their code. The model will ensure data is safe from any hacking attempts on the network, as well as preserve data integrity via continuous calculations and monitoring the network.

What’s next?

We are entering into the second phase of the project called Proof of Concept. 

As the name suggests, the time has come to prove that the concept can be done in reality.

During the next period, the team will get cracking on

• Defining and building a test blockchain network, that is, a group of nodes that can communicate with each other (i.e., exchange messages)
• Defining and building a “primitive” shared ledger – this is a system for storing transactions (similar to a bookkeeping ledger in which everything is entered)
• Building and implementing a simplistic version of the consensus algorithm (these are the decision-making nodes)

We won’t reveal more for now: you’ll hear all about our team’s latest challenges next time.

“Preparation is the key to success” – Alexander Graham Bell.

We couldn’t agree more, Mr. Bell, we couldn’t agree more.

As a little reminder, as announced a while ago, GRN Association partnered up with Barrage, a software development company, on the development of the GRNGrid blockchain (Grid) and GRNWallet application.

We’ve been somewhat quiet, but that doesn’t mean we weren’t busy!

If you are interested in keeping up with the GRNGrid project, tune in to our first update to see how the team has kick-started the project.

Begin at the beginning

The first phase of the project, the research and discovery phase revolves around trial and error.

In an attempt to simplify this complex process, let’s say it involves: a lot of reading, compiling data, racking your brain about things, and enthusiastically presenting your findings to the team, only to have them disillusion you by pointing out something faulty in your logic. And then you masochistically return to do it all over again.

It’s necessary to look into the future and think through every detail to ensure that you define strong building blocks for the development phases. 

If done thoroughly, this phase helps:

• estimate (and decrease) costs
• create a more precise roadmap 
• reduce risk

Decisions, decisions…

The first decision – choosing the consensus mechanism – was made even before the phase began. In truth, PoW was never an option. 

In their race to win a reward, PoW miners spend significant amounts of energy to validate transactions. Of course, this wasn’t always the case, but as more miners joined, the “game” became more merciless, requiring more power. Simply put, PoW’s excessive energy consumption goes against everything GRN Association stands for. 

Since Ethereum’s PoS upgrade will lower its blockchain’s energy consumption by 99.9%, rooting for PoS2 as a mechanism has even more sense. PoS2 will enable maximum all-around sustainability and scalability of the GRN blockchain, therefore correcting some of the POS’ flawed features.

Another major decision based on the initial assessment was that Rust is the perfect programming language for the code base. 

Besides being the “weapon of choice” of most modern blockchains, it’s also crucial to mention that Rust is:

• memory-safe, a.k.a. protected against software bugs and vulnerabilities related to memory access
• thread-safe, a.k.a. ensures that all threads behave appropriately in a multi-threaded code

This makes it fast and secure. Regarding “famous” use cases, we can mention Mozilla’s browser engine Servo, and Figma’s (collaborative interface design app) real-time syncing server.

Test ‘em all

Once they had some basic postulates set, it was time to get down to the nitty-gritty: how do you know what you’ll be up against and what elements you want to include if you don’t know what’s out there and how it works? 

So, the initial code assessment started with analyzing the existing blockchain solutions and their elements. 

The team decided to dive deep into 5 blockchains: 

• Avalanche
• Solana
• PeerCoin
• NEAR
• Stealth

Each team member was tasked to work on one blockchain and inspect each aspect of each blockchain solution. Analyses such as these provide an overview of the challenges that wait for them once they start building GRN Grid blockchain. Besides these, the team plans to check out several more blockchain software solutions.  

The idea is to be able to create custom configurations of each selected blockchain software solution, check whether the nodes and APIs function properly, and of course, if the performance is optimal (e.g., that there are no system flow restrictions).

As each of these blockchain solutions is unique, a lot of reverse engineering had to be done – that is, devising the requirements specifications, functions and design by analyzing the code. Don’t worry, it isn’t complicated as it sounds, basically, the team is trying to find solutions that can be useful so we don’t reinvent the wheel and use well-tested solutions to achieve GRN Grid’s goals.

Each day the team meets to talk about what they did, share if they ran into any challenges and what they intend to work on next. The challenges they experienced are then turned into a team sport for everyone to pitch a solution to. 

Each day, the same team member always comes with a short and decisive “I didn’t figure out much today” or “I have no clue what I’m doing”, only to deliver a 20-minute speech when asked a question about that one thing “he has no clue about”. Ambitious undertakings put everything to the test: the team’s perseverance, willpower, resourcefulness, and knowledge. Luckily, our team possesses enough know-how and experience to truly see these situations as opportunities for growth.

What’s next?

There’re a lot of solutions out there, but not a lot of wholesome ones. 

With these types of complex projects, one of the worst things that could happen is being a couple of months deep into the development and then realizing that your basis is flimsy, to say the least. Code refactoring is not uncommon or problematic in itself, but making major changes to a project that has already gone far ahead can seriously affect your roadmap and the end result.

Therefore, proper research is a crucial step that can allow developers to work faster because many of the processes and functionalities have already been considered. 

This phase will last about another month – until that time, the team is documenting their findings. Those findings will not only help them in the following phases, but they are also creating unique intellectual capital for GRN Association. 

We want to keep the community updated, so you can expect more updates like these in the following months!