Blog on Project Abundance

There were a lot of changes to the RISC-V interpreter I announced a while back, and I think it is now in a state that is usable for more people.

I’ve been procrastinating recently on the primary objectives, so I figured I’d share something useful for the broader Rust community in the meantime again.

The last few weeks were a confusing mix of both some decent work and procrastination with way too many blockers faced.

Another two weeks or so wrestling with compilers.

I like posting updates with substantial performance improvements, but sometimes that is just not happening despite plausible approaches and substantial effort.

I spent a lot of time working on the RISC-V interpreter in the last few weeks and got some substantial improvements.

Good news!

The first batch of crates is now available on crates.io!

It has been a while since the last update.

In the last update I introduced a basic RISC-V interpreter, but its performance was underwhelming, which was to be expected, but still was something that I’d like to improve.

It has been around a year since the project started, and I would like to share a brief summary of what has happened so far, where the project is at and what’s coming next.

Switching to something that I thought would be more fun, I decided to look into ELF and RISC-V last week or so.

Last time I shared challenges and next steps in making consensus shard-aware.

So far the block production was basic and very similar to Subspace, despite some key underlying differences.

In the previous update I shared that the block production started to work on the beacon chain.

It has been a month since the last update, and I finally have more exciting news to share here.

All the updates in recent weeks were about Proof-of-Space performance improvements, but what was really driving it is my exploration into how to efficiently implement it for GPU.

It has been a couple of weeks since the last status update about performance improvements in Proof-of-Space and I am finally at a decent stopping point where all architectural changes are done and I can share them with you.

This is just a short note about something that was not possible to do as cleanly before.

This third part has fewer improvements and could have been called “Adventures with rust-gpu part 2” given how much time I spent wrestling with it.

In the part 1 I shared some background information, performance improvements and future opportunities.

In the last update I shared that I plan to work on GPU plotting some more, so that is what I did.

The state of the codebase is slowing approaching the state in which block production might be finally possible.

This week I continued working with the client database and integrating it closer with the rest of the node.

The biggest update since the last blog post is that an initial prototype of the database was merged.

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.

This week has been mainly focused on refining a bit the design for plot identification and sector expiration.

There are buzzwords in any industry that are thrown around easily, and blockchains are no exception.

I have to admit that I am a bit disappointed with my progress this week.

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.

As mentioned on last week’s status update, one of the key pieces that I was missing to have the detailed operation of plot membership allocation was the impact of sector expiration on the protocol.

Last week I shared a model that can help us reason about the security of shards assuming an honest majority in the beacon chain.

This was a lighter week on meaningful changes, but there are still few things to share.

This week has been all about objectively assessing the security of the system.

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.

Last week I shared a high-level of how I was thinking farmer membership selection should work.

There have not been an update from me last week, how come?

This week has been another of those weeks where I am pretty happy with the progress made.

I started the week thinking about the mechanics of shard segment commitment into the global history of the beacon chain.

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?

I am pretty happy with the progress this week.

This week has been mainly focused on clearing the fog around shard archiving and trying to start fleshing the low-level details for the protocol.

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.

This week was very similar to the last one with a bunch of refactoring in cleanups.

We keep iterating on the best way to discuss and make progress on the design of the protocol.

The last week was lighter on major changes, but there was a lot of cleanups and refactoring done to prepare Subspace components reuse for building a new blockchain from scratch.

We started last week with two PRs that attempted to describe in detail the operation of sharded archiving (PR192), and the data availability layer of the system (PR193).

Most blockchain implementations are pieces of software that include the logic to support many different roles/features, possibly all at once: bootstrap node, block producer, RPC node, archival node, light client, etc.

Over the past weeks, my updates have highlighted many of the ideas emerging from our open design discussions.

Last time I mentioned that I was looking into Merkle Trees to replace KZG.