bench: benchmarking operation cost of BTCStaking module

[SebastianElvis]

Fixes https://babylon-chain.atlassian.net/browse/BM-1161

This PR introduces benchmark tests for the operation cost of BTC staking, more specifically its BeginBlock function. The benchmark test generates X finality providers, each with Y BTC delegations, then benchmarks BeginBlock.

To run the benchmark, do go test -benchmem -run=^$ -bench=. github.com/babylonchain/babylon/x/btcstaking/keeper.

Results

The tests are run on a computer with following spec

➜  babylon git:(bench-btcstaking) ✗ lscpu                                               
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 7 7735HS with Radeon Graphics
    CPU family:          25
    Model:               68
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            1
    CPU max MHz:         4829.0000
    CPU min MHz:         400.0000
    BogoMIPS:            6388.71
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht sys
                         call nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperf
                         mperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdr
                         and lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tc
                         e topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibp
                         b stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_
                         ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsavee
                         rptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists
                          pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid over
                         flow_recov succor smca fsrm
Virtualisation features: 
  Virtualisation:        AMD-V
Caches (sum of all):     
  L1d:                   256 KiB (8 instances)
  L1i:                   256 KiB (8 instances)
  L2:                    4 MiB (8 instances)
  L3:                    16 MiB (1 instance)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-15
Vulnerabilities:         
  Gather data sampling:  Not affected
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Not affected
  Spec rstack overflow:  Mitigation; safe RET, no microcode
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affecte
                         d
  Srbds:                 Not affected
  Tsx async abort:       Not affected

Then we get the following results (1st variable is the number of finality providers, 2nd variable is the number of BTC delegations under each finality provider)

BenchmarkBeginBlock_10_1-16                  398           2955465 ns/op          234058 B/op       4297 allocs/op
BenchmarkBeginBlock_10_10-16                  49          23703374 ns/op         1151194 B/op      23637 allocs/op
BenchmarkBeginBlock_10_100-16                  5         227371262 ns/op        10283580 B/op     215486 allocs/op
BenchmarkBeginBlock_100_1-16                  38          30710833 ns/op         2257204 B/op      40789 allocs/op
BenchmarkBeginBlock_100_10-16                  5         246222241 ns/op        11480028 B/op     234334 allocs/op
BenchmarkBeginBlock_100_100-16                 1        2642083604 ns/op        104106224 B/op   2152946 allocs/op

The conclusion is that BTC staking module has scalability issue -- with 1000 BTC delegations, the BeginBlock will take 0.25 second.

The next step is to identify bottleneck and optimise it.

[SebastianElvis]

Attached the profiling result of BeginBlock. Marshaling/unmarshaling BTC delegations (especially BTC PKs) is the performance hotspot.

profile001.pdf

[gitferry]

The benchmarking looks good to me. Generally I don't see the beginBlocker as a bottleneck. In a case where we have 100 * 10 delegations, the time spent in beginBlocker is only 0.25 seconds.

[gitferry]

Should the defer appear before the error handling?

[SebastianElvis]

Not really, if there is an error then f won't be opened and the program will exit at L76 directly. Same for the below comment

[gitferry]

same here

[SebastianElvis]

The benchmarking looks good to me. Generally I don't see the beginBlocker as a bottleneck. In a case where we have 100 * 10 delegations, the time spent in beginBlocker is only 0.25 seconds.

I remember @KonradStaniec mentioned that in Ethereum if executing a block takes more than this time then this might affect chain liveness? Also imagine if we have 100000 delegations this number becomes >2s

[KonradStaniec]

I remember @KonradStaniec mentioned that in Ethereum if executing a block takes more than this time then this might affect chain liveness?

It won't affect liveness. I think liveness will only be affected if block execution will take more than 12s, as one ethereum slot is 12s.

I mentioned that execution of block in geth currently take 0.2s, and we are talking about chain which database have over 1tb of data, and 100s transactions per block.

So having one begin block to take more than 0.25s seems worrying.