🚧 Project Abundance 🚧

We keep iterating on the best way to discuss and make progress on the design of the protocol. Using issues for discussions have shown less efficient than originally expected. The inability to make in-line threads, and having to quote every single detail of the spec that we want to discuss about was really cumbersome. I started the shard block submission issue as an attempt to start iterating the low-level details of specific protocol mechanisms in a way that is narrow enough and easy to track, but it didn’t fulfill all our needs. The solution? Creating discussion PRs that I don’t expect to get merged, but gives us all that we need to have low-level discussions about specific parts of the protocol, track our progress, open ideas, and discussions, and have them public so anyone can contribute or follow along.

This week was very similar to the last one with a bunch of refactoring in cleanups. There were important archiver improvements/fixes (depends on point of view) and more work on Merkle Trees. Two more crucial crates were moved from subspace to crates.

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). When I started writing this spec, it was meant to be for a broader audience, but we realised after a few rounds of feedback that the project is still in a really early stage and in constant change, so it would be more efficient to focus on detailing the parts of the protocol that are currently under-defined instead of trying to give a deep overview of the overall operation of the protocol from the get-go. The actual goal behind this protocol specification is to unblock the implementation of a prototype that can help us gain certainty about the design decisions that we are making, and surface potential blind spots in the design, and not to have a reference spec (just yet).