“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!
