We know the aggregate publickey of a fully participating sync committee.
Because participation is typically very high (>95%), it is faster to
start from that aggregate publickey and subtract the individual keys of
non-participants, than summing up all the participating pubkeys.
With the gnosis binary, building all targets sometimes exceeds the 40m.
Bump timeout to 50m.
```
Cancelling nested steps due to timeout
Sending interrupt signal to process
gcc: fatal error: Terminated signal terminated program lto1
compilation terminated.
make[2]: *** [/tmp/cctcWxAN.mk:134: /tmp/cciCtCWJ.ltrans44.ltrans.o] Error 1
make[2]: *** Waiting for unfinished jobs....
gcc: fatal error: Terminated signal terminated program lto1
compilation terminated.
make[2]: *** [/tmp/cctcWxAN.mk:155: /tmp/cciCtCWJ.ltrans51.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [nimcache/release/nimbus_beacon_node_gnosis/nimbus_beacon_node_gnosis.makefile:3148: build] Error 1
make: *** [Makefile:699: gnosis-build] Error 2
```
To obtain the correct `transactions_root` and `withdrawals_root`,
it is necessary to process execution block header. Light client updates
don't contain the correct MPT roots.
Port 9952 sometimes seems blocked, maybe by another Status project
being tested on the same host, or by UPS process, or maybe it needs
SO_REUSEPORT as well?
Switch to 9962 for now to see if that improves things.
```
{"lvl":"DBG","ts":"2023-08-06 13:44:56.834+03:00","msg":"Initializing ELManager","topics":"beacnde","tid":231629305,"file":"el_manager.nim:1823","depositContractBlockNumber":1,"depositContractBlockHash":"00000000"}
{"lvl":"ERR","ts":"2023-08-06 13:44:56.834+03:00","msg":"Could not create HTTP server instance","topics":"beacnde","tid":231629305,"file":"server.nim:50","address":{"family":"IPv4","address_v4":[127,0,0,1],"port":9952},"serverIdent":"nim-presto/0.0.3 (arm64/macosx)","serverFlags":["NotifyDisconnect","QueryCommaSeparatedArray"],"socketFlags":["ReuseAddr"],"serverUri":{"scheme":"","username":"","password":"","hostname":"","port":"","path":"","query":"","anchor":"","opaque":false,"isIpv6":false},"maxConnections":-1,"backlogSize":100,"bufferSize":4096,"httpHeadersTimeout":"15250w1d23h47m16s854ms775us807ns","maxHeadersSize":131072,"maxRequestBodySize":16777216,"err":"(48) Address already in use"}
{"lvl":"NOT","ts":"2023-08-06 13:44:56.835+03:00","msg":"Rest server could not be started","topics":"beacnde","tid":231629305,"file":"nimbus_binary_common.nim:370","address":"127.0.0.1:9952","reason":"Could not create HTTP server instance"}
```
Using `create` with objects containing managed objects is broken:
https://github.com/nim-lang/Nim/issues/22341
Switch to a safer pattern based on `new+GC_ref`/`GC_unref` instead.
* async batch verification
When batch verification is done, the main thread is blocked reducing
concurrency.
With this PR, the new thread signalling primitive in chronos is used to
offload the full batch verification process to a separate thread
allowing the main threads to continue async operations while the other
threads verify signatures.
Similar to previous behavior, the number of ongoing batch verifications
is capped to prevent runaway resource usage.
In addition to the asynchronous processing, 3 addition changes help
drive throughput:
* A loop is used for batch accumulation: this prevents a stampede of
small batches in eager mode where both the eager and the scheduled batch
runner would pick batches off the queue, prematurely picking "fresh"
batches off the queue
* An additional small wait is introduced for small batches - this helps
create slightly larger batches which make better used of the increased
concurrency
* Up to 2 batches are scheduled to the threadpool during high pressure,
reducing startup latency for the threads
Together, these changes increase attestation verification throughput
under load up to 30%.
* fixup
* Update submodules
* fix blst build issues (and a PIC warning)
* bump
---------
Co-authored-by: Zahary Karadjov <zahary@gmail.com>
This PR removes a few hundred thousand temporary seq allocations during
state transition - in particular, the flag seq was allocated per
validator while committees are computed per attestation.
Split up the `ShufflingRef` acceleration logic into generically usable
parts and attester shuffling specific parts. The generic parts could be
used to accelerate other purposes, e.g., REST `/states/xxx/randao` API.
henridf
Jacek Sieka
Etan Kissling
tersec
andri lim
Miran