I’ve read through SubspaceBlockImport::import_block and it’s clear that lower solutions implies higher weight, and the chain with the highest weight will be the canonical chain and get finalized.
What’s unclear to me is how subspace chooses a proper solution_range so that not too many proposers will propose a block for the same slot?
I believe this is what you’re asking for:
TL;DR: It adjusts solution range such that we have 1 block per 6 slots on average.
@nazar-pc Thanks for the reply! I see the idea behind derive_next_solution_range, I think it’s quite similar to how ethereum pow adjusts the difficulty. But there’s some difference, ethereum pow doesn’t have a concept like slot(it has this concept after merge, in POS), so the actually timing to propose a block is not known in advance, once a block is mined, most probably other miners will try to propose subsequent blocks on top of the previous one.
But in subspace, there’s the concept of slot, miners don’t have to race to propose a block, when the slot comes(when on_slot is called), they just check the s buckets for candidate solutions. If one miner proposes a block with matching solution for slot N, other miners will still continue to try to propose a block for the same slot since they can’t rush to propose block for slot N+1 since the timing hasn’t come yet.
Or is there something wrong with my understanding that subspace miners have to wait for the slot ?
Slot is how our blockchain measures time, so it is very similar.
We call them farmers, but they do actually race still. Block time is just 6 seconds, so if block is not announced quickly, the rest of the network will move on and even if block is valid, it will end up being on a short fork. So farmers are definitely interested to announce their block as soon as possible. Also consensus is probabilistic, meaning there could be more than one solution for the same block too.
No, they will move on as soon as possible. In fact they already have since auditing is very quick and everyone audits a few seconds into the future, while Proof-of-Time forces them to hold onto their solution for a little bit before future proof of time is available so they can create a block.
I’d recommend to read Medium articles and specifications if you want to dig deeper into it.
I just finished reading this article: Securing Dilithium with Proof-of-Time | by Dariia Porechna | Oct, 2023 | Subspace Network
It seems it’s quite close to what I thought.
if block is not announced quickly, the rest of the network will move on
In fact I’m more interested in the opposite case: if the block is announced quickly, will this announced block cancel other farms from auditing for the same slot? I think the answer is no according to the codebase. (It’ll be great if you can confirm about it though, as it’s mostly where my conclusion comes from)
In filecoin there’s a concept called tipset which refers to the blocks for the same height. This is what I mean by forking blocks in the title. Since announced block doesn’t cancel others from auditing, I suspect the tipset size for subspace network should be quite high, maybe 1 dozen for each height?
Using the concept of tipset, the question can be restated as: how does subspace control tipset size?
If they already audit that slot then no, in fact they can still produce a vote at that slot and it will be valid for inclusion into the next block.
I’d be surprised to ever see this on the network. Remember, there is solution range adjustment that prevents multiple blocks from being created at the same time.
They are just forks, IIRC there is some limit beyond which node will refuse to accept more, but in practice it is almost guaranteed to be irrelevant and unreachable.
Remember, there is solution range adjustment that prevents multiple blocks from being created at the same time.
It seems derive_next_solution_range is for adjusting block height growth rate, not for adjusting forks? In theory, it can happen that there’re many forks per height, but the height growth rate is limited by solution_range.
How? You’d have to add as much space as network already has to create 2 blocks every ~6 seconds instead of 1. For 12 blocks you’ll have to add A LOT of plotted space, which while is possible theoretically, would break consensus and allow such participant to fork the network and control liveness almost completely.
You’d have to add as much space as network already has to create 2 blocks every ~6 seconds instead of 1.
Why? As mentioned previously, the 1 block every ~6 seconds result comes from derive_next_solution_range, which can only adjust the block/slot rate, but can’t control the forks.
（Now I think about it again, it seems controlling block/slot rate also controls the forks, since the former means there is in average only 1 block every 6 slots network wide.）
Even so, by as much space as network already has, do you mean Blockchain History Size? It grows very slowly(currently 18 GB), compared with Total Space Pledged(currently 5531.61 TiB). So it seems quite easy to add as much space as network already has(18 GB).
(Oh now I think you actually mean Total Space Pledged)
How else do you generate more valid solutions?
Forks only appear when you have more than one solution created at about the same time, solution range ensures this is rarely the case. You might want to read about work difficulty in PoW chains, the mechanism is generally the same.
Space pledged of course.