Can team advise the total time given in 3g to submit a proof? I understand it’s 750ms for 3f, but given diff is 8x higher in 3g, what is time given for 3g?

Proof of time specification has `BLOCK_AUTHORING_DELAY`

parameter set to 4 slots, which is ~4 seconds. This means farmer who produced a solution will have to wait 4 more slots before they can actually send it to the network.

This delay reduces performance difference between farmers since it no longer matters how quickly farmer can produce a solution, as long as it is less than 4 seconds, it is good enough and will make no difference.

For 3f farmer had ~750ms to audit, prove and propose (primarily sign) a block. In 3g farmer has 4 seconds to audit and prove, proposing is still ~750ms, but farmer does less work there now.

Thank you very much. So am I understanding correctly that:

Audit, provide and propose (primarily sign): must be done within 750ms

Produce a solution: must be done within 4s

This rule is applied for both block reward and vote reward? Reason I ask is that I’m not really sure if a farmer has to produce/submit a solution in case of only a vote reward (lower diff).

thanks.

No, I literally wrote the opposite in last message.

Yes.

If they don’t produce a solution, how does the on-chain logic verify if they won?

Sorry but your paragraph here confuse me

I now understand that the proof fetch is given 4s in 3g (given only 750ms in 3f). If audit is not done across all the plots within 750ms, how can the farmer propose within 750ms?

My understanding now is it has 2 phases:

- Audit and propose (only primarily sign, i.e. notifying the network that farmer has the proof): ASAP and within 750ms (otherwise it’ll be considered as late/invalid)
- Proof producing: will be sent at 4th slot, i.e. max. 4s can be used to fetch proof

Is that accurate now?

No, you reordered them randomly comparing to what I wrote and what actually happens in reality.

I wrote “audit and prove” because those are two things that are happening on the farmer first:

- farmer audits plots for solution candidates
- for each candidate it’ll try to generate proofs and if proof generation succeeded it will be sent to node in the form of a
`Solution`

After 4 seconds all the `Solution`

s that were collected from all farmers are used to propose a new block or submit corresponding votes as unsigned extrinsics depending on solution quality.

Thanks, and the given time is below, correct?

- farmer audits plots for solution candidates: 750ms
- for each candidate it’ll try to generate proofs and if proof generation succeeded it will be sent to node in the form of a
`Solution`

: 4s

One more question on this topic. If a farmer has more than one eligible solution candidates, will it try to generate proofs for all? Or it only picks up the best ‘solution candidate’ and generate proof for that one?

Absolutely not, you turned it upside down again. Please read this carefully:

It will try to prove all, in the order of decreasing quality.

I’m not sure why it is so difficult to understand. It’s so funny if you know who I am in real life and how many emails and stakeholders I have to deal with across many countries in my daily work.

You said “In 3g farmer has 4 seconds to audit and prove, proposing is still ~750ms, but farmer does less work there now.”.

So “proposing is still 750ms”, where is it in the 2 tasks below?

- farmer audits plots for solution candidates
- for each candidate it’ll try to generate proofs and if proof generation succeeded it will be sent to node in the form of a
`Solution`

Thanks again.

It is a separate step from those two, it happens afterwards.

Thanks. So it’s very little chance to be late in 3g. Only when the plot size is really big, and the eligible sector is at the end of that plot.

You shouldn’t have too many solutions on the same machine for that to become an issue in production network anyway. And quad-core machine from 2015 is able to audit ~15TiB plot from my testing, 13900K can audit over 100TiB plots, so you shouldn’t really have issues either way unless you’re still plotting.