it may be a mistake separating snark proving from block producing;
the separation adds redundacy requirement and latency, difficulty for economic modelling, and complexity of the protocol, without gaining too many real benefits;
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;
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.
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)
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…
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.
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 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.
Practically, I think concerns about centralization are overblown. Snarking a transaction is so easy and cheap that anyone can do it, so if there was any censorship that came from centralization then another snark producer would jump in to claim in the fees. This is discussed in §2.3 of the economic whitepaper.
I think there is a good point on inefficiency, but coupling with the block production does add more compute strain for the the BP nodes, which isn’t cost free. If there’s a possibility it could add to block latency, or BP reliability, in my view, it’s not worth the trade-off of theoretically lower snarking fees (which are tiny at this point in time).
I agree with @garethtdavies that it could make sense for snark producers to form voluntary off-chain coordinators if they wish to make snark production more efficient, and they could distribute some gains in the form of lower fees and profits to those who participate.
Thanks Brad, good to have a co-author of the economic whitepaper replying to this!
so if there was any censorship that came from centralization then another snark producer would jump in to claim in the fees.
That’s true, but it won’t be without any disturbance of the network in the short term. Similar to Bitcoin mining migrating out of China, if Mina gets that big and its snarking is dominated by a big player, block production could be significantly interupted. We’ve already seen a few times when new CEX listed Mina, there weren’t enough snarks for BP. It’s not bad per se, but would be good to have the daemons or other snarkers have more autonomous agility when sudden uptick of snark demand happens.
My intention early on was to form a snark pool; however, the fees do not justify it. That may change as utilization increases. I also think centralization concerns are overblown, and that the current mechanism is working quite well. Any real centralization risk (halt of majority of snark producers) would be quickly noticed and the void easily filled. There may be a short-lived impact, but I don’t see it as a serious potential impact. If the complexity or hardware requirements of snark work were to significantly change, this could warrant more interest.
The current snarketplace is working well for Mina, and for Block Producers. It is not incentivizing work by would-be snark producers that are not block producers. That may change over time, but is not inherently bad for the protocol.
Lamps - on the original points: 1) I agree with Gareth that separating snark work from block production is quite elegant, and 2) the separation actually helps with latency vs. a single BP trying to general all the necessary snarks. 3) As already stated, I’m not very concerned about the winner-takes-all risk - even with many producing snarks at 0, we maintain a viable market, and there is ample capacity available should there be a decrease in snark availability. 4) still think centralization is not an actual issue - hypothetically, or in reality as we observe the current market.
That said - I do think there is something to consider re: the snarketplace design, which is the sneaking through of extremely expensive snarks. This seems to be an unintended consequence of the design, and may be worth exploring. Despite repeated attempts, I’m not clear on the scan state and snark ordering, so I don’t have a great solution in mind, but if I were to invest energy on snarketplace design, it would be in that area.
The forced sequence of snark purchases combined with network gossip timing has created a game where block producers are faced with extortion: pay excessive fees for this one snark, or don’t create a block. Perhaps this is a symptom of a malfunctioning market currently and will resolve (Investigation: snark work inclusion rate · Issue #10430 · MinaProtocol/mina · GitHub), but if it proves to be an inherent feature of the design, I think that is worth searching for alternative approaches to mitigate this behavior.
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?