As an engineering manager, this “V1” project looks extremely ambitious. It attempts to invent three entirely new engineering systems which have thus far only been in ‘research’ mode: sharding, POS & stateless clients.
I think Justin’s suggestion to make V1 (V0) a single-shard version of this system is a fantastic one, because you can punt a lot of the engineering complexities of cross-shard management into future phases of work.
My initial gut reaction was to punt stateless clients out of V1 because I think this is where most of the engineering complexity lies. Stateless clients create unpredictability in the system which will require significant engineering to mitigate. What do I mean by this? Bandwidth between archival nodes and collator nodes will be sporadic depending on the utilization of state. Gas prices to do transactions will be unpredictable for application developers, who will have to closely monitor the usage of state, making the programming model significantly more complicated. These engineering problems will make it dificult to get a smoothly functioning system off the ground and difficult for developers to adopt as a result of the added complexity.
Frankly I like the idea of getting a stateful client POS solution out with single shard. This could be built very quickly, and sets up for a rapid release of multi-shard capability shortly thereafter.
One of the concepts that I think is missing from the longer term vision is the concept of dynamic shards. With dynamic shards, application developers could, in the fullness of time, select shards with properties that best match with their application: high collation cadence, high statefulness, large transaction payload, large collation size, etc. With this concept introduced into the vision for the platform, it might even make sense to launch POW shards to unlock the scaling bottlenecks of the system very quickly.