Author

Topic: How many transactions can a node validate in a second? (Read 182 times)

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
Can you share how to perform the benchmark? I'd like to try run the benchmark, but i didn't find command used to perform benchmark (i already build it without problem).
I ran Bitcoin Core with a -debug=bench flag.

Thanks, i tried it and able to see the result on debug.log

I didn't try to build the benchmark from the git, doesn't seem to want to build on my server. I'll have to find a way around that.

For reference, i found out there are 4 excitable file called bench_ecmult, bench_internal, bench_sign & bench_verify. Weird there's no mention the build process also produce benchmark executable.

Edit: here's an example of benchmark result from bench_verify

Code:
ecdsa_verify: min 48.5us / avg 48.9us / max 49.3us

ecdsa_verify_openssl: min 400us / avg 408us / max 417us
legendary
Activity: 2954
Merit: 4158
Can you share how to perform the benchmark? I'd like to try run the benchmark, but i didn't find command used to perform benchmark (i already build it without problem).
I ran Bitcoin Core with a -debug=bench flag.

I didn't try to build the benchmark from the git, doesn't seem to want to build on my server. I'll have to find a way around that.
legendary
Activity: 2954
Merit: 4158
Sigops stands for signature operations. Bitcoin transactions can contain multiple signature operations depending on the complexity of the script, P2SH output for example could allow you to pad to a fairly high number of sigops but keep in mind that current standardness limits keeps it under 15. Current consensus limits sets it at 80,000 sigops per block.

I saw your topic a few days ago but unfortunately I couldn't come up with any concrete numbers so I didn't comment on it. That being said, here is what I've experimented with so far, do take it with a grain of salt though.

I've run two instances of Bitcoin Core (0.21.0), and the results were fairly similar, this is from my run which I downloaded from scratch. From what I've observed, the timing will vary significantly if you choose to select assumevalid.

   - Connect postprocess: 0.00ms [1.67s (111.43ms/blk)]
 - Connect block: 8429.91ms [341.49s (22766.07ms/blk)]
   - Load block from disk: 5.00ms [0.01s]
     - Sanity checks: 1.00ms [0.00s (0.13ms/blk)]
     - Fork checks: 0.00ms [0.00s (0.00ms/blk)]
       - Connect 2075 transactions: 10465.00ms (5.043ms/tx, 1.571ms/txin) [350.14s (21883.62ms/blk)]
     - Verify 6661 txins: 10465.00ms (1.571ms/txin) [350.14s (21883.75ms/blk)]
     - Index writing: 3.00ms [0.06s (3.84ms/blk)]
     - Callbacks: 0.00ms [0.00s (0.06ms/blk)]
   - Connect total: 10470.01ms [350.21s (21888.03ms/blk)]
   - Flush: 4.00ms [0.08s (5.00ms/blk)]
   - Writing chainstate: 0.00ms [0.00s (0.00ms/blk)]

I think that the IDB download would be far more accurate considering that the transactions are not relayed first to the node but it's verified with the received block. The former would probably have majority of the transactions being in the mempool first and would have been verified already. The numbers can and will be misleading. A single P2SH input can contain multiple Sigops and I can't find a way to benchmark individual transactions or transactions with a single sigops only.

The results would vary quite wildly across different systems, considering the fact that the process is not purely CPU bound but would also involve your RAM with the UTXO set being stored on it, depends on how much dbcache you have. You can try running the secp256k1 benchmark as well: https://github.com/bitcoin-core/secp256k1.
legendary
Activity: 3472
Merit: 10611
Interesting question and I think the only way to answer it is to run an actual benchmark with a code that is designed to measure this because generally speaking transactions can take different time to be validated.
For example a legacy transaction with a lot of inputs takes a longer time to verify compared to a SegWit transaction with the same large number of inputs due to the way sig-hashes are computed.
Obviously the number of inputs and number of signatures each input has (eg. multi-sig) also affect the time since you have to compute more hashes and verify more ECDSA.
Script type can also affect the time, some non-standard ones could take a significant amount of time more than the standard ones.

This is why we focus on "sigops" which is basically the time it takes to run an OP_CHECKSIG while OP_CHECKMULTISIG is considered more than one sigop depending on its settings.

P.S. Bitcoin core has are some benchmarks, you may want to look into them.
legendary
Activity: 4354
Merit: 3260
I don't know the answer, but perhaps you could get a estimate by dividing the amount of time it takes to synch your node by the number of transactions in the blocks you synched. As long as your are well-connected, then most of the time spent synching is spent validating the transactions.

Keep in mind that it depends a lot on your node's hardware, of course.
member
Activity: 79
Merit: 28
How many transactions can a node receive and validate in a second? I guess bitcoind uses multi threading and I saw there's an option to adjust the amount of cores you want to use. But are there known any numbers for a usual desktop pc?
In a reddit thread someone said that with an 20k computer you could make over 500k Sig Ops per second. Means sig ops, validation of transactions?

I reposted this here since I got no answer in the technical discussion board (posted yesterday). I'm new here, so what's the max time to except for an answer?
Jump to: