adlrocha

Over the past weeks, my updates have highlighted many of the ideas emerging from our open design discussions. Now that we have a clearer direction for the design, I wanted to consolidate these ideas into a draft spec. This will serve as a foundation for implementing the first few prototypes, while also providing a structured way to gather feedback and uncover potential blind spots. I expect this spec to suffer significant changes, but it felt like the perfect way to consolidate the ideas, get feedback from the community, and unblock Nazar in case he wants to start prototyping some of the ideas we’ve been discussing.

This week has been another good week of progress. I finally have a good idea of how shard archiving should work in the happy path, and I’ve started writing a low-level spec for it (that I am hoping to push to this repo soon). Unfortunately, there is still a slight gap in the spec that we need to fill before we can move forward: the data availability problem.

This week I’ve gone a bit deeper into the design of the multi-shard Subspace protocol idea which I briefly introduced in my last update. The protocol is conformed by the following parts: Sharded archiving, responsible for creating a global canonical history of the whole system, and of creating the history records that will eventually become part of farmers’ plots. Sharded plotting, which takes records from the global history and seals them in plots that include segments of the history of every shard of the system, and that will be used for the farming process. And finally, merged farming, which is the protocol responsible for challenging farmer plots, and deriving the corresponding winning tickets that elect block proposers in specific shards. Let me introduce the high-level operation behind each of these sub-protocols, while digging deep in the one that I’ve focused the most on this week: sharded archiving.

After a lot of thinking, this week I came to the realisation that a sharded architecture like the one we are trying to build can be designed leveraging the current design of the Subspace protocol and all its underlying mechanisms as a base. While this was the idea from the beginning, either for lack of familiarity with the protocol or plain ignorance, I was missing the big picture of how this could be done.

Overall, I am really happy with the progress I’ve made this week. I’ve been mainly focused on unravelling one of the papers that I mentioned in my last update, Proof-of-Stake Sidechains. While is true that we don’t want our system to have anything to do with PoS, and there is no 1:1 matching of the concepts from the paper with what we are trying to build, the paper presents a framework that can come pretty handy to evaluate the correctness of our designs. This paper is from 2018, and after a first pass the first thing that I did is to check if there were any follow-up papers that built upon the abstractions of this paper. I came across Proof-of-Work Sidechains from the same authors, but without a doubt, the most complete proposal is the one that I started with. Let’s dive right into it.

I want to kick-off my first weekly update in the project thanking Nazar for the warm welcome and the opportunity to work with him on this exciting project. I was really pumped to see other teams actively working on a similar problem to the one I started researching more than three years ago. For several reasons, I wasn’t actively contributing to this problem any more, but this opportunity was the perfect excuse to get back to the game.