5

Does block verification time (by all nodes in the network) takes up a large portion of the total block propagation time? What is the percentage, on average?

Danny
  • 103
  • 5

1 Answers1

7

It depends significantly if you're asking about the average, N-th percentile time, or a worst case including the possibility of maliciously constructed blocks.

Nodes use the first copy of a block they receive, obviously. A consequence of this is that block propagation along a slower path will be outpaced by block propagation on a faster path. As a result, overall propagation time depends mostly on the behavior of fastest paths and there are many optimizations in the Bitcoin network to make the fastest paths usually quite fast.

On the vast majority of blocks >99% of the transactions in the block are known in advance and already validated. With validation already cached the only further validation required are trivial tests such as preventing double-spends within a block and verifying that block time/height are consistent with transaction lock-times.

On blocks consisting of known transactions relay among BIP152 HB-mode peers occurs without most of the validation (only POW and the hash root are checked, which takes under 1ms on a typical fast host). Similarly, fibre forwarding doesn't need to wait for validation (or complete reception, for that matter) even when many transactions aren't known in advance.

As a result on average the amount of time used for validation in propagation in the network today is probably closer to 0% than to 1%. I would expect based on data from matt's relay network that the 99.9th percentile would have a couple percent in validation.

In the worst case, however, no transactions would be known or already validated and, also in the worst case, a block could require minutes of processing to validate. Fibre would still forward fairly quickly though still several times slower than typical due to the additional data needed. In such a worst case situation the vast majority of the propagation time would be spent on validation, even where Fibre propagation is used (which doesn't need to wait for validation even when the data is unknown), just due the final receiving node's own validation.

This other answer may be of interest to you: https://bitcoin.stackexchange.com/a/80928/52021

The community has spent a fair amount of effort optimizing the non-malicious block case both because it was clear what needed to be done there and because providing equitable access to very fast propagation is essential to avoiding creating an advantage for larger miners. Arguably, however, for many concerns the worst case performance is more critical. Fibre makes some advance on the non-validation related worst case performance, and not making the worst case worse was a major design goal in segwit but the worst case remains a more difficult and somewhat less well addressed problem.

G. Maxwell
  • 7,727
  • 2
  • 20
  • 47
  • Thanks for this great answer. What is a maliciously constructed block? – James C. Jan 28 '19 at 10:05
  • 3
    A block that instead of processing normal transactions is stuffed full of transactions which are specifically created to be expensive for the network to deal with. For example, by containing transactions which were not previously relayed to eliminate caching gains, expensive script operations, or quadratic sig-hashing. – G. Maxwell Jan 28 '19 at 10:12
  • Maybe one advantage of having an optimal average case is that it makes the adversarial case stand out that much more? Everybody will very quickly know that something is up and take their precautions. There's no hiding in the noise or plausible deniability for the adversary. Even if he's still anonymous. – Jannes Jan 29 '19 at 01:32
  • Great answer. ">99% of the transactions in the block are known in advance and already validated." You mean they are already known by nodes that received them earlier? But a node that just received the block still need to validate all tx on it, right? BTW, isn't it often claimed that blockchain scalability issue arises because all nodes need to verify all tx? – Danny Jan 29 '19 at 09:27
  • 3
    Most transactions are relayed on the network, received, and validated on most nodes before they end up in blocks. They don't need to be validated again except for trivial consistency checks. They all have to validate them, but usually they are no longer on the critical path for block validation. Security depends on the worst case, however, which would be when they are not known in advance, so processing delays are still important but they're important even though on average they don't take any time during propagation. – G. Maxwell Jan 29 '19 at 10:04
  • @G.Maxwell, A rough idea to increase scalability, not sure if it will work: let the number of nodes to verify a tx depend on the number of past transactions between the two addresses within that tx. If the two addresses transacted a lot in the past (all verified transactions), the less number of nodes is required to verify their mutual transactions in the future. – Danny Jan 30 '19 at 09:12
  • @G.Maxwell, Let's say two addresses transacted a lot in the past, their next tx will only be verified by 20% of the nodes (or, for each node, their probability of verifying the tx is 20%). If this time their tx become malicious, the protocol will ask the 20% verifying nodes (after finding out the tx is indeed malicious) to send msg to the remaining 80% nodes to start verifying on that tx. They will drop that tx or blocks containing that tx, thus ensuring security. – Danny Jan 30 '19 at 09:20
  • @G.Maxwell Do you think the idea will work? I think it will and Bitcoin should implement it. If not, I might create a startup doing that. :) – Danny Feb 14 '19 at 08:49
  • 1
    Attacker spins up 1,000,000 'nodes', and as a result any 20% you select will almost always be attacker nodes. If that sort of thing worked there would be no reason for mining in Bitcoin at all. – G. Maxwell Feb 15 '19 at 03:39
  • @G.Maxwell The PoW mining part still exists and remain the same, only the subsequent process of transaction verification is modified. The problem you mention also exist in other layer-1 scalability solution such as Sharding. It is highly unlikely that ALL 20% is malicious. Even if there is one non-malicious node checking it and found fault it will tell to others to verify it (if they not done it before), spreading throughout the network. – Danny Feb 20 '19 at 07:29
  • @G.Maxwell Also, if an address is involved in one malicious behaviour the next time they appear in another transaction, the number of nodes required to verify it quickly escalates to, say 95%. – Danny Feb 20 '19 at 07:33