Discussions on the Snarketplace design

stumbled upon a discussion on twitter about snarketplace: https://twitter.com/valardragon/status/1480740355419029506?s=20 , and thought there are various points that are worth debating, especially some criticisms which I paraphrase here:

  1. it may be a mistake separating snark proving from block producing;
  2. the separation adds redundacy requirement and latency, difficulty for economic modelling, and complexity of the protocol, without gaining too many real benefits;
  3. a potentially dangerous consequence is that snarking could be a winner-take-it-all thing, meaning that one entity capable of producing cheaper snarks end up producing all snarks. Snarketplace just created the perfect platform for the ultimate centralisation to happen - if snarking was bundled with BP, at least it can be as decentralised as BP;
  4. the level of centralisation on snarking could be worse than POW of Bitcoin - for the latter, at least owning % of hashpower = % of reward, for snarking, owning % of slower hashpower could be = nothing.

I tend to agree with many of these points. Snarketplace was based on good intention, but so far has not worked well, and the snarking job are mostly done right now by BPs anyway - almost the same result as bundling with BP. There have been some discussions before within the community, but worth some more debating about the design again IMHO.

4 Likes

Do I understand correctly that this is more a question of framing and nudging BPs to do snarking by creating a client that does it by default?
Because on a fundamental level I don’t think it can be prescribed whether BPs would outsource parts of their computations or not.

Also I think it’s worth mentioning that snarking being centralized has not nearly as bad implications for security as POW being centralized would have for bitcoin

That being said, I agree that creating a strong default where BPs do snarking seems to make things simpler and more resilient. My question would then be: If this is already basically the status quo, and if it can’t fundamentally be prescribed, is it worth changing anything? (the answer could very well be yes :D)

1 Like

thanks for your comments Gregor. Currently the daemon has a snarking setting which can be optionally turned off, so the client can just run the block producing functionality. Most of the snarks are produced by Block Producers (BPs) when they have a long period without block producing duties, and it needs to turn off well before block producing, because snarking competes for computing resources.
apart from centralisation, the current setup also does not have a feedback mechanism. It has happened a few times before, when there were sudden increase of activities (eg binance listing), there was no available snarks in snarketplace, and block production was halted. It needed the team to call for people in Discord to turn on snarking to get things going, which was obviously not ideal…

1 Like

Thanks for the insights! Makes total sense to me :slight_smile:

While I disagree with the premise that it was a mistake separating snark and block proving - I think the design is quite elegant and scales well as block production time isn’t limited by the transaction throughput - I agree the economics of snark workers aren’t great. BPs are of course incentivized to produce proofs so they don’t pay excessively for them, more so for the larger block producers. I think it would take something more radical like snark workers receiving a share of block rewards to create any sort of real market (or the additional snarking incentives that were touted).

Snark pools are another idea (the current snark coordinator requires trust), as this would go someway to reduce the redundancy with snark proofs (albeit increases centralization). Given the current tx volume it wouldn’t take much computational power to produce all the required proofs for the network.

1 Like

Thanks for the comments Gareth . Separating snarking from BP is done through the scan state though, isn’t it? my understanding is that it’s independent of who does snarking? I also agree that a more sophisticated coordinator would make a lot of the problems mentioned by the guy go away, and I’d love to see some comment on these from the team.

Right, the scan state design is what I was referring to, so we’re probably in agreement here :slight_smile: Do you mean that block producers should be forced to be snark workers also? Is this via the protocol or just on by default in the daemon?

I think if average snark fees ever got meaningfully high (not just the lucky one sneaking in) then, at a minimum, the large producers would simply only purchase their own snarks or a private pool etc… So the incentives are there for the block producers, as you point out, they are probably already doing the vast majority of the snark work. That’s why I think the entire incentives of snark workers likely needs to be reconsidered if we want a market outside of the block producers.

I don’t know what the best strategy is tbh. It seems almost impossible for Snark fees to rise meaningfully enough to incentivise non-BP nodes to get in, unless there is larger need for snarks than the capacity of all the BPs combined. Only in that case, a free market might exist.
Until that happens, we will live with the fact that snarks will most likely be produced by BPs. The bare minimum improvement would be to add in a feedback mechanism, so that when a sudden increase of demand happens, more snarking power can be automatically turned on to avoid stall of the network.

1 Like