Block time: constraints on lowering it

Blockchain Architecture
1

There was some good discussion in Telegram recently about Neptune Cash’s block time and whether it could be adjusted. Thorkil suggested bringing it to the forum, and I couldn’t find an existing thread on the topic, so here is one.

The immediate motivation is that this question comes up some what regularly, gets answered in a chat, and then disappears. Quoting the exchange below so it’s on the record, and so anyone who wants to make the case for a change has something concrete to engage with.

Cryptus:

I have done a ton of research on the block speed security trade off situation I’d like to hear opinions as well. do you think 2 or 3 minute blocks on npt is sufficient enough while at the same time not compromising too much on the security of the protocol?

E:

Lower block times would be great. There is at least one non-security related constraint though, and that is the tx proving time. It takes quite a bit of time to create even ProofCollection, so lowering the block time to 2 min range would prevent these lower-end devices from making txs.

Alan:

Bitcoin mining lands in a fragile equilibrium where the dominant strategy is to accept the new block as quickly is possible because a) everyone else is following that strategy, and b) mining is a Poisson process so switching costs nothing. The composer-guesser split we have in Neptune Cash, specifically the composing step, is not a Poisson process, and therefore relocates the equilibrium. It might make sense to continue a half-finished proof because b) restarting from scratch is costly, and a) you can no longer take for granted that everyone else will immediately accept the new block, thereby making block races started late more winnable. We set the block time to what it is so that the disturbance to the game theory equilibrium caused by the composer-guesser split, is limited to the concretely small fraction of time spent composing to block time. Your proposal increases that disturbance by a factor 3.

2 Likes
Neptune Bulletin: a community roundup of what is happening across the project
2

One pushback against E’s pushback above. The current RPC endpoints and p2p endpoints require all transactions to be synced when they arrive, so they are currently rejected if the proof relates to an older block than the current tip. But we could change that to allow a transactions to be synced against any of the n last blocks, and not be a double spending transaction. Both the RPC endpoint and the p2p protocol would need to be changed the same way, since the transaction needs to propagate on the network until it hits a proof upgrader.

So not impossible, but challenging.

2 Likes
3

This would be great UX improvement, since the wallet wouldn’t need to redo the proofs if a block arrives mid-proving. That becomes more likely the lower the block time, so this is good to hear, and it would keep lower-end devices (laptops, phones) usable even at a shorter interval.

1 Like
4

The double spending check needs to be possible on nodes that do not store all blocks but just store the last n blocks. So the check would be:

  1. Is the transaction synced correctly to any of the last n blocks?
  2. Have the absolute indices that the transaction would set been set in the last n blocks?

Specifically: this check must not assume the presence of an archival mutator set, as only archival nodes maintain that. And the point of succinctness is of course that non-archival nodes can be full nodes :slight_smile:

2 Likes