nazar-pc

This week I continued working with the client database and integrating it closer with the rest of the node. A key integration point that was missing completely and still not implemented was state management. The core parts of the consensus do not involve state management, but transaction processing will. So I was considering various ways to process transactions and came up with an idea I’ll be pursuing that should work nicely, but is also a bit unlike most of the blockchains out there.

The biggest update since the last blog post is that an initial prototype of the database was merged. It lays the foundation in terms of fundamental architecture and will now be extended to support more features. There were also updates in a few other areas.

After adventures with rust-gpu, which I still monitor periodically, I moved on to the client database implementation, which is required for proper blockchain operation, and which is one of the bigger undertakings. Unfortunately, the database as such isn’t quite ready yet, but I did some preparation and would like to share some details about the database architecture.

There are buzzwords in any industry that are thrown around easily, and blockchains are no exception. In this post, I want to focus on “scalability”. Turns out when you say “blockchain scalability” different people hear different things. The prevalent opinion seems to be that scalable blockchains are able to process more transactions than non-scalable ones or something along those lines. Essentially making the ability to scale equivalent to peak performance. Sure, peak performance is an important metric, although it is often a theoretical one. But I don’t think that is the most useful property, especially without clarifying the conditions under which it can be achieved.

GPU plotting was one of the items on the roadmap last week and that turned into a week+ long side quest, so let me share some details about that.

This was a lighter week on meaningful changes, but there are still few things to share. First of all, last week’s block import was (and still is) and incomplete prototype, but this week it was extended to become a bit more complete. I was also working on bringing up more components frm Subspace, including farmer, which lead me to attempt GPU plotting in Rust, so let’s get into it.

There was no update last week again since I didn’t feel like there was enough to share at the time, but now that more things have settled I’d like to share what I’ve been busy with.

There have not been an update from me last week, how come? Well, it didn’t seem like there was anything particularly substantial to share, mostly some refactoring, so I decided to skip it. This week though I have a few words to say about the path towards block production (not there yet, but getting closer). Some this is a boring process, I procrastinated some too, diving into various topics with some interesting performance improvements and new learnings.

The question might seem somewhat obvious: you have a header and a body with transactions, many blockchains have it, what might be so difficult about it? Well, as I mentioned in the previous update, there are some complications and part of the challenge is related to the fact that we’re dealing with sharded architecture, which most blockchains don’t need to deal with.

The discussions with Alfonso and attempts to start building an actual blockchain led to spending a big part of last week working on block structure. That work is not done yet. However, I like to have some sort of accomplishment at the end of the week if possible, so I spent some time to finally implement the formatting of addresses, which will be the main part of this update.