0-Fee SNARK Work

[aneesharaines]

Because of this, the chance that other users can sell their SNARK for higher fees is very small, and the challenge is not leading to the market dynamics that we'd like to see. Do people feel that this is worth engineering's time to address? If we don't address this, then many of our testnet users will likely get frustrated, because they cannot score any points for this challenge, and there is nothing that they can do about it. It might affect the testnet participation.

[yourbuddyconner]

TL;DR: This scenario won't occur in a mainnet because the nature of the testnet disrupts the incentive structure. There are plenty of ways we can craft challenges such that users are incentivized to use the SNARK work functionality in different ways, and we have done in previous testnets.

There are also many things we can do to improve the UX of running a SNARK Worker. ex:

• SNARK Worker scalability https://github.com/CodaProtocol/coda/issues/5100
• improved SNARK work selection algorithm
• better fee structure
• ignore snarks below a fee (?)
• (BP) affinity for snarks from a public key
• SNARK Pool framework
• Review of SNARK metrics and logs
• much more suggestions from community

Attaching a transcript of a conversation that was had on Discord:

conner Yesterday at 5:05 PM Deepthi I just typed this in #testnet-general and it got me wondering:

Yeah it brings up a larger conversation, would we ever want to allow a zero-fee SNARK in a mainnet situation? Could allow some nefarious money-bags types to undercut the network at the cost of electricity.

cc @nholland94

nholland94 Yesterday at 5:10 PM

What would be the incentive for setting zero-fee SNARKs? Seems like you would only lose money doing so. IMO, it's actually not bad to have 0 fee SNARKs because it enables to extra market play wrt block producers internally producing SNARK proofs to offset what they would have to pay with the network. Some may see that as a behavior that should be discouraged, but I also don't see allowing people to have different choices for how they optimize their profits to be an issue. The goal is that snark workers would set their fees just enough such that they are providing a cheaper alternative to buy through them, just from the perspective of not having to maintain your own extra compute nodes and infrastructure. If we disallow market practices like that, then there isn't much of a force to drive the fees to be competetive at that level. That said, I'm not an economist, I just lean towards "keep the market free" in general, and can't see a major issue with 0 fee SNARKs from that perspective. If somebody decides to produce free SNARKs, it's not a bad thing for the chain, only for other SNARK workers. I guess the big downside there is that it could erase the snarketplace temporarily, at the benefit to block producers. But it would just be someone burning money to do this, so it doesn't fully make sense.

conner Yesterday at 5:12 PM Yeah, it's interesting because we're seeing a weird market dynamic in this testnet so far, there is incentive to produce a few, really high-priced SNARKs and then a ton of 0-fee SNARKs to disallow other users from getting fees And I wonder if there would ever be a real-world situation where some actor would want to rob the network of proceeds in fees

Deepthi Yesterday at 5:15 PM I think, like @nholland94 mentioned, it would not be sustainable because the moment one stops creating 0- fee snarks, other snark workers will start competing

nholland94 Yesterday at 5:15 PM Yeah, the market dynamics now are different than what we will see when money is real. Right now, money is "price is right" points, and people are manipulating the market for non-monetary purposes.

conner Yesterday at 5:16 PM Yeah so how could we craft a better testnet environment such that we can better play with these mechanics? theoretically I agree that the market dynamics seem sound from a Mainnet perspective, it would only be expensive to do this and there wouldn't be much, if any gain beyond spiting some SNARK work operations

nholland94 Yesterday at 5:17 PM That's a hard question to answer. We could put custom rules on txns just for testnets, but that seems like it wouldn't do too much, because someone will just find another way. So long as fees are meaningless, lowest fee will always be the best option. At least making the min > 0 would make it so others can still make some kind of money for testnet points.

conner Yesterday at 5:18 PM Would it be possible to add an 'affinity' for a certain SNARK worker in the block producer code? without having to recompile the daemon myself to get this functionality such that BPs could choose their own SNARKs if available? (seems reasonable for Mainnet too)

nholland94 Yesterday at 5:18 PM Not without a recompile

conner Yesterday at 5:19 PM Well like, could we add it as a feature theoretically? Some list of Public Keys in the config.json or something

nholland94 Yesterday at 5:20 PM

Well, what I want to see at mainnet is something even more generically configurable than that, but that's for another time. We need to write up some user stories for how block producers and snark workers can configure (or write algorithms for) selection of snark work to buy and selection of pending work to perform and how to price that work. I'd like to have that discussion first, because I would prefer to give people the tools to do anything with that, rather than just building a couple of configurables around a small set of possibilities. I feel like the market dynamics are only interesting if we don't prescribe a set of them.

My absolute ideal (potential pipe dream, but totally doable in < 1 month time) would be to allow the daemon to execute (or talk to) an arbitrary external program to make decisions for block production proof purchases/txn selection and snark work distribution/pricing. Like, daemon just knows where this custom program is, executes it at that time, json stdin, json stdout, and the daemon does whatever the output tells it to. Then you could write a dead simple python library that lets people write their own python programs which will make these decisions. Then market dynamics are truly open and anyone with some basic programming knowledge can write their own strategy, and share it with other people if they so choose.

Deepthi Yesterday at 5:25 PM

Yeah, there's more to it than just the fees. Currently the way it works, only the cheapest work is added to the pool irrespective of the prover. Since a block has a max capacity on the number of transactions it can include, having multiple provers would take up more slots and therefore not include enough user transactions. But if we were to include proofs from fewer provers even if that meant paying a lil extra then we'd be have space for more transactions and therefore net block reward could be higher

nholland94 Yesterday at 5:27 PM

But if we were to include proofs from fewer provers even if that meant paying a lil extra then we'd be have space for more transactions and therefore net block reward could be higher

Yeah, I think this will be an important weight in the algorithm we will want for selecting work in the future.

awilson Yesterday at 5:31 PM feeling like i'm missing something but how likely, in mainnet let's say, would it be for a snark worker to even keep up w/ the demand of snark work? in other words, even producing work at 0 cost, wouldn't there be a bunch of other snark jobs produced that the "irrational" worker wouldn't have gotten to

nholland94 Yesterday at 5:35 PM Not necessarily. If every actor has a different selection mechanism, and the irrational actor was not able to fully saturate snark work by themselves, then yes. Currently, all actors use the same work selection mechanism, so it typically works out that most workers are all doing the same work. We will have to come up with a solution with this before mainnet, either investing more in the snark coordinator, or allowing better, configurable work selection mechanisms.

awilson Yesterday at 5:35 PM ah got it

conner Yesterday at 6:01 PM @awilson there is a concrete formula that describes the number of CPUs you'd need to do SNARKs for a certain TPS, I'll see if I can find it IIRC the curve was steep Deepthi so you have any idea RE: the equation?

Deepthi Yesterday at 6:06 PM

The number of snark workers process required (where each worker produces one snark work within a slot duration) is the equal to the transaction capacity per block

conner Yesterday at 7:05 PM

Gotcha so to get 1 TPS with a theoretical slot time of 2m, a proving time of <2m, and 128 Transactions in a block we could meet demand for SNARKs with ~128 Snark Worker Processes, is that an accurate statement Deepthi?

Deepthi Yesterday at 7:28 PM

Yes and each of those snark workers need to complete one snark work within 2m Oh I guess by proving time you meant transaction snark proving time and not blockchain proving time, in which case, that is an accurate statement

[deepthi]

hello! I got notified because I was tagged in this issue. I believe the correct person is @deepthiskumar

[yourbuddyconner]

Thanks @deepthi, sorry bad copy-paste!

[deepthi]

Thanks @deepthi, sorry bad copy-paste!

No worries at all!

[Schmavery]

@yourbuddyconner we discussed this in product standup (which is where the issue came from) and agreed that this isn't really a bug but could be mitigated in the testnet context with a better-crafted challenge.

Namely one suggestion was to incentivize both individual earnings from snark work as well as group snark work earnings. For instance, having both of these challenges at the same time:

• Top 5 people with the highest amount earned from selling snark work gets 1000 points
• If the entire network has a combined coda earned from selling snark work of over xxx coda then everyone who produced a snark gets 500 points. (Alternatively, having an average snark fee > n)

The idea would be to incentivize points over snarks (preventing 0-cost snarks being valuable) and disincentivize the strategy where someone races to be the first snark sold and then floods the network with 0-cost snarks in order to block others from being able to sell any snarks.

There may still be some loopholes.. but the idea is the give the snark earnings value again. Another option would be to award points to whoever has the most coda at the end.

[yourbuddyconner]

Yeah I think this does it nicely @Schmavery

[jkrauska]

I believe that snark flooding at 0 fee moves all the economic power in to block production. (maximizing coinbase return).

Because of this, I believe that snark fees should be limited to be a function of the coinbase and transactions per block. Eg. If the Coinbase is 200 (as it is now) and the effective txns per block is ~6 , then you need ~8 snarks completed per block to maximize txns.. So the Min snark fee should be 200 / ~8 * R

Where R is a desired minimum ratio of 'profit sharing' between block producers and snark workers.
Eg 25% (snark workers should get a minimum of 25% of coinbases)

Keep in mind that block producers also receive txn fees, so you may want to skew R to favor snark work.

Fixing minimums limits abuse of the 'free market'. See also 'minimum wage'.

[yourbuddyconner]

@jkrauska see Nathan's argument against this, I generally agree with him in that we should keep the "free market" free barring a more concrete economic argument.

What would be the incentive for setting zero-fee SNARKs? Seems like you would only lose money doing so. IMO, it's actually not bad to have 0 fee SNARKs because it enables to extra market play wrt block producers internally producing SNARK proofs to offset what they would have to pay with the network. Some may see that as a behavior that should be discouraged, but I also don't see allowing people to have different choices for how they optimize their profits to be an issue. The goal is that snark workers would set their fees just enough such that they are providing a cheaper alternative to buy through them, just from the perspective of not having to maintain your own extra compute nodes and infrastructure. If we disallow market practices like that, then there isn't much of a force to drive the fees to be competetive at that level. That said, I'm not an economist, I just lean towards "keep the market free" in general, and can't see a major issue with 0 fee SNARKs from that perspective.

If somebody decides to produce free SNARKs, it's not a bad thing for the chain, only for other SNARK workers. I guess the big downside there is that it could erase the snarketplace temporarily, at the benefit to block producers. But it would just be someone burning money to do this, so it doesn't fully make sense.

SNARK Work is fully in service of Block Production, it's not designed to provide a completely separate revenue stream IMO.

[jkrauska]

@yourbuddyconner I think I just gave an actual macro economic argument.
https://en.wikipedia.org/wiki/Minimum_wage

I also feel that it should be a global network tunable that can be adjusted as things change. (compute costs go down ,etc) (just like coinbase)

I also feel like introducing a minimum snark fee during testnets will also be instructive. We know what happens when minimum is set to 0, lets try something else next net.

[jkrauska]

@nholland94 replace "bad thing for other snark workers" with "bad experience for other testnet participants" and see if you feel the same way?

[yourbuddyconner]

@jkrauska what do you think about the challenges @Schmavery described? I believe these will have a positive affect on testnet experience, makes it more collaborative in that it aligns incentives for the testnet participants to work together without modifying the protocol at a deep level.

[jkrauska]

@yourbuddyconner can you still do those challenges AND set a minimum snark wage

[zmanian]

My theory of mainnet SNARK work economics is that validators might bundle free SNARK work if they receive a threshold amount of delegation.

[pkrasam]

Testnet If one of things we are trying to measure is the ability to generate valid snarks irrespective of their fee, then is it possible to instantiate a shadow snarketplace for the purposes of catching valid snarks and attributing credits/incentives to the snark-workers?

And when a rock-bottom or lowest fee snark is generated, we promote it to the real snarketplace where block-producers can bid/purchase from.

Mainnet Assuming our game theory and economic theory is right, we might be able to switch-off the shadow snarketplace when we transition to mainnet.

[nholland94]

Hey @jkrauska. Long time no chat. Hope your doing well.

I believe that snark flooding at 0 fee moves all the economic power in to block production.

I think this statement requires some justification. The economic power structure doesn't actually change at all. Whether fees are 0 or there is a minimum fee, block producer still makes all the decision regarding how the block is produced. The only thing that happens differently at 0 fee is that the block producer can make more profit. The real difference here is that (in a real scenario with proper monetary incentives) a majority of snark workers are giving their work away for free, at their own detriment. Even in this world, an actor behaving under this pattern could not block all other snark workers from getting fees unless they could actually saturate the entire queue of snark work every single block (which would actually be a great thing for the network, but would be extremely expensive). Right now, we see things playing out differently, because not only is the necessary economic incentive missing, but also, there is a single algorithm for snark selection, meaning everyone is doing the same work. This will most certainly not be the case at mainnet when there is a real snarketplace.

I don't believe macro economic arguments based on minimum wage are really applicable here. Minimum wage for people in society is a very different system than minimum wage of a specific role in the computation of a blockchain which is independent from consensus, correctness, or even controlling the blockchain in any meaningful way (unlike block producers). What you are suggesting is more akin to setting a minimum price which a good can be sold for on a market, which defeats the point of a market and it's ability to adapt the price of goods to meet supply/demand/production cost. Anyone who is selling snarks below the production cost (compute cost) is losing money and cannot sustain that position on the market unless they are reaping some kind of benefit from a side effect of changing that market.

@nholland94 replace "bad thing for other snark workers" with "bad experience for other testnet participants" and see if you feel the same way?

I disagree that snark fee of 0 implies a "bad experience for other testnet participants". Actually, it basically means the opposite. Zero snark fees allow block producers to include more txns in blocks, and they allow block producers to make more money. So it's good for users and it's good for block producer's income.

I also feel like introducing a minimum snark fee during testnets will also be instructive. We know what happens when minimum is set to 0, lets try something else next net.

Totally down for this. I think setting a minimum snark fee, or enforcing that snark fees be randomized and not directly settable during testnets, is something we should experiment with in the short term. It will allow us to reduce the annoyances with interactions between this and testnet challenges, and let us see what the behavior differences are.

[jkrauska]

@nholland94 -- miss you man!

My rationale about the power differential between Block Production (BP) and Snark Work (SW) is that BP has a fixed coinbase (200 in this testnet), while SW is a "snarketplace". Why does BP get a fixed return when SW is variable?

I do feel there is a reasonable analogy of Block Production to Capital and Snark Work to Labor. (@o1brad didn't you give a talk on the history of Capital?) Block Production is literally based on the % of stake you own. (@yourbuddyconner they are connected -- but neither can operate without the other -- and ANYONE with a few cores and 60-90s can produce a snark, where realistic BP requires an investment or operating as a professional delegatee)

I think one additional twist would be to allow for block production acceptance (in event of block collision) would be to allow a BP to 'sell' that block at a variable coinbase. Then both behaviors would fluctuate with the 'markets'.

[pkrasam]

In reading both recent comments, it does feel like the playfield is un-even between a BP and SW. If the same individual/company is operating both, they might be able to offset the loss of selling 0-fee Zk. Whereas if the parties are different then the BP has the upper hand on the profits than the SW.

Also, why did we limit the transactions to 6 in testnet?

I really like the idea of being able to resell a block at collision at a variable cost.

Depending on the time differential on when a SW generates a Zk and when it gets purchased/included by a BP in a block, I reckon there is an opportunity for including a price distribution on the Zk such that the SW can make some additional BIPS based on the demand for such Zk in the snarketplace.

Anyhoo, it feels like we need to open up the testnet to be able to experiment on all the above and other hypothesis.

And other other consideration for the CODA-core-team is to be more active on the discord -- it feels like your MIA for the most part.

Do feel free to push new binaries w/in a testnet phase, otherwise the current phase 3.2b seems to be long drawn.

[nholland94]

My rationale about the power differential between Block Production (BP) and Snark Work (SW) is that BP has a fixed coinbase (200 in this testnet), while SW is a "snarketplace". Why does BP get a fixed return when SW is variable?

It's true that BP gets a fixed coinbase, but there is another layer to the separation between BP and SW in terms of economic, which is the required resources/position to actually profit in either role. As a BP, my ability to profit has little to do with my computational resources, and everything to do with my stake (position) in the market. By comparison, a SW does not have to have any position in the market (subject to change; we may require an account, which would mean they would have a minimal position). SWs can participate in the marketplace using just their computational resources, and the amount of money they make is determined by what the market determines that computational resource to cost. A big difference between a wage market and the snarketplace, in my mind, is that in a wage market, everyone needs to receive a wage. While you can see wages sort of as a market, the dynamics that drive wages in economies at scale seems to be fundamentally different from the pricing of goods in a buyer/seller market, which is what the BP-SW marketplace is. If someone is finding that the market on SW is not profitable to them (because the cost of compute is greater than the fees reaped), they will back out of the market. If they own physical compute, they will move it to another marketplace on another chain, and if they have cloud compute or are renting, then they just stop paying.

If the same individual/company is operating both, they might be able to offset the loss of selling 0-fee Zk.

True, but they only receive the benefit of this if they produce the work for their blocks only. That would mean, in this scenario, a rational actor would not even submit this work to the network, because if another BP includes the work, then they can't in their block. This is also very difficult, because while you will know when you will produce a block, you don't know what work will be on the chain when you produce that. You can try and produce a bunch of snark work ahead of time, but there is a good chance that it won't be available by the time your block window comes up. It's more likely that an actor operating under this model would try and spin up a bunch of compute work shortly before their block.

Also, why did we limit the transactions to 6 in testnet?

This is because there was a regression with our snark coordinator. We will be fixing this for future testnets, we just had to turn down TPS for this testnet in order to get it out the door.

And other other consideration for the CODA-core-team is to be more active on the discord -- it feels like your MIA for the most part.

I apologize that it has been feeling like that. We have been very heads down on stabilizing the protocol and creating better tools to have confidence of the protocol's stability moving forward. We are beginning a new rotation internally which aims to help with this lack of community interface.

[jkrauska]

https://minaexplorer.com/snarketplace

[jkrauska]

@bkase @aneesharaines In the spirit of transparency, could this discussion be made public? It's a very community-focused outcome and I feel could be an excellent case for wider/open policy discussions.