🚧 Project Abundance 🚧

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.

This week has been mainly focused on refining a bit the design for plot identification and sector expiration. I think that I finally have a model with which I am comfortable with, and that I think solves all of our previous problems. Nazar had this idea to drastically simplify how plot IDs were derived, and how sectors were linked to plots. The high-level idea made sense, but there were still some details that weren’t clear. This week I managed to come up with a design that I think satisfies all of our requirements.

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.